에이전트 반복 실패에서 정보와 잘못된 전제 분리하기

같은 명령을 같은 환경에서 반복 실행해도 원인 후보가 줄지 않는다면 재시도의 근거를 확인해야 합니다. 실패한 명령의 형식을 그대로 따르고 있는지, 새로 확인한 조건을 다음 호출에 반영했는지 비교합니다.

Hanako의 글은 실패에서 얻은 정보와 실패한 출력의 형태를 구분하자고 제안합니다. 실패한 호출을 계속 입력에 넣으면 모델이 같은 형식을 반복할 수 있다는 가설입니다. 이 설명만으로 모든 반복 실패의 원인을 확정할 수는 없습니다. 물론 재시도 코드의 오류, 사용할 수 없는 서비스, 권한 부족도 원인이 될 수 있습니다. 실제 실행 결과를 분류한 뒤 다음 시도에 남길 정보를 선택합니다.

실패한 실행에서 얻은 사실

명령이 실패했다면 실행 전 거절됐는지, 실행한 프로그램이 오류를 반환했는지 확인합니다. 두 경우에는 필요한 대응이 다릅니다. 실행 정책에서 명령을 거절했다면 프로그램 내부 오류를 조사하기 전에 거절한 명령과 정책 조건을 확인합니다.

다음 시도에 필요한 기록은 명령과 환경, 오류의 의미, 이번 결과로 배제한 가정입니다. 긴 로그 전체가 항상 필요한 것은 아닙니다. 다만 정확한 오류 원문과 진단 위치는 보존해야 해석이 틀렸을 때 다시 확인할 수 있습니다.

예를 들어 데이터베이스 연결이 거절됐다면 다음처럼 상태를 정리할 수 있습니다.

확인: 지정한 주소에서 연결을 거절함
아직 미확인: 서버 실행 여부와 실제 수신 포트
배제하지 못함: 주소 오류, 프로세스 종료, 접근 제한
다음 확인: 프로세스 상태와 수신 포트

연결 거절의 원인이 아직 확정되지 않은 상태를 기록한 예시입니다. 기록에는 비밀번호 오류로 단정하지 않고 서버 실행 여부와 수신 포트를 다음 검사 대상으로 적었습니다.

직접 만든 오류 조사 표식입니다. 그림에는 연결 거절이라는 관찰과 아직 확인하지 않은 비밀번호 오류 추정을 구분하고, 다음에 확인할 서버·포트·주소를 표시했습니다.

잘못된 경로와 구현의 전제

잘못된 경로의 명령을 생성했다면 실제 경로를 읽기 전용으로 확인하고 그 결과로 명령을 다시 구성합니다. 이전 명령과 오류는 원인 분석을 위해 보존하되, 다음 호출에는 확인한 경로를 전달합니다.

코드 작성에서도 같은 구분을 적용할 수 있습니다. 실패한 구현을 계속 조금씩 고치기 전에 원래 요구사항과 실제 데이터 흐름을 다시 확인합니다. 함수의 책임을 잘못 이해했다면 한 줄씩 패치해도 같은 문제가 다른 위치에서 나타날 수 있습니다.

조건이 바뀐 뒤의 재시도

다시 실행하기 전에는 어떤 조건을 바꿨는지 확인합니다. 서버를 시작했거나, 경로를 확인했거나, 잘못된 옵션을 제거했거나, 입력을 수정했다면 바뀐 조건으로 다시 실행해 결과를 비교할 수 있습니다.

환경과 명령이 그대로라면 같은 오류를 반복 확인해도 원인 후보가 줄지 않습니다. 일시적 오류라는 근거가 없다면 오류 원문, 공식 문서, 사용 버전의 동작을 조사합니다. 보안 제한을 낮추거나 위험한 행동을 다른 실행 방식으로 숨기지 않습니다.

추정으로 시작했던 원인 기록

긴 작업에서는 처음 떠올린 원인이 나중에 사실처럼 남을 수 있습니다. “권한 오류로 보임”과 “권한 검사에서 거절됐음을 확인”을 구분해서 기록합니다. 틀린 추정이 확인됐다면 기존 기록을 현재 사실에 맞게 수정합니다.

연결 거절을 다시 조사하는 시점에는 서버 실행 상태, 실제 수신 포트, 지정한 주소 중 무엇을 확인했는지 남깁니다. 확인 결과가 바뀌었을 때 새 명령을 실행하면 재시도의 이유와 아직 남은 원인 후보를 추적할 수 있습니다.

재시도 기록에는 변경한 조건과 새 실행 결과를 함께 남깁니다. 조건이 바뀌지 않았다면 같은 명령을 다시 실행할 이유부터 확인합니다.