AI 코딩 에이전트가 같은 실패를 반복할 때, 새 대화가 필요한 순간

오류 로그를 보여 줘도 AI는 방금 실패한 수정을 또 제안한다. 같은 대화를 계속 붙잡을지, 새 대화로 다시 시작할지는 무엇을 보고 정할까?

AI 코딩 에이전트가 같은 실패를 반복할 때, 새 대화가 필요한 순간
세 줄 요약
  • 같은 수정과 실패가 반복된다면 원인 가설이 바뀌고 있는지부터 살펴야 한다.
  • 최근 에이전트 연구는 결과물을 보존하면서 탐색 기록을 버리는 방법으로 정체를 줄였다.
  • 새 대화, 기록 요약, 파일 원복은 효과가 서로 다르다.

환경이 막혔는지, 같은 가설에 갇혔는지부터 본다

AI 코딩 에이전트가 실패한 수정을 되풀이한다면 작업 파일을 보존한 채 새 대화에서 다른 접근을 시도할 수 있다. 그러나 패키지가 없거나 인증이 실패하는 상황이라면 먼저 그 조건을 해결해야 한다. 대화 기록을 비우는 것만으로 실행 환경이 바뀌지는 않는다.

예를 들어 API 응답 형식이 잘못됐는데 패키지 버전만 계속 바꾸는 상황과, 필요한 패키지를 실제로 설치하지 못하는 상황은 다르다. 전자는 원인 가설을 다시 잡아야 하고 후자는 설치 실패의 원인을 찾아야 한다. 이 구별 없이 “다시 해봐”를 보내면 다음 시도에서 무엇이 달라져야 하는지가 남지 않는다.

VS Code의 에이전트 복구 지침도 실패 명령·첫 오류·진단 근거를 보고하게 하고 작업 경로, 의존성, 실행 중이어야 할 서비스와 권한을 확인하도록 권한다. 잠시 출력이 없다는 이유만으로 반복 실패라고 판단해서도 안 된다. 질문에 대한 응답이나 아직 끝나지 않은 명령을 기다리는 상태일 수 있다.

더 오래 실행하는 것과 새 해법을 찾는 것은 다르다

Drew Breunig는 10월 24일 공개한 컨텍스트 엔지니어링 글에서 에이전트가 이미 버려야 할 가설이나 하위 목표를 계속 좇는 현상을 ‘컨텍스트 관성’이라고 불렀다. 긴 기록에는 도움이 되는 사실뿐 아니라 실패한 추론도 쌓인다는 문제의식이다.

Fork-and-Flush 연구는 이를 탐색 구조의 문제로 다뤘다. 에이전트가 만든 작업 환경을 보존하면서 대화 맥락은 비운 여러 분기를 실행하고, 점수가 가장 좋은 분기에서 작업을 이어 갔다. 연구 대상은 장시간 연구·공학 과제 13개다. 채팅 창 하나를 초기화한 효과만 측정한 실험이 아니라, 새 맥락과 병렬 탐색·결과 선택을 결합한 방법이다.

Scaling Discovery Requires Forgetting도 기록이 쌓이면서 에이전트의 수정이 점점 작아지는 현상을 보고했다. 이 연구에서는 세션과 후보 이력을 버리고 가장 좋은 후보에서 탐색을 다시 시작했다. 두 연구에서 보존하는 것은 유효한 결과물이며, 계속 이어 붙이지 않는 것은 그 결과에 이른 전체 탐색 기록이다.

요약은 기록을 줄이고, 새 대화는 출발점을 바꾼다

기존 접근이 유효하고 오래된 로그만 많다면 요약이 맞다. 반대로 서로 모순되는 지시와 잘못된 가설이 계속 되살아난다면 새 대화가 더 적합하다. 코드 변경 자체를 취소해야 한다면 파일 복구를 별도로 선택해야 한다.

상태선택
방향은 맞지만 탐색·출력 기록이 길다유지할 사실을 지정해 대화를 요약한다.
기존 가설을 반복하며 다른 원인을 검토하지 않는다현재 파일과 검증 결과를 넘겨 새 대화를 시작한다.
이미 반영한 코드가 잘못됐다변경 내역을 검토하고 필요한 파일을 복구한다.

새 채팅을 지원하는 VS Code 세션에서 대화를 추가하면 이전 채팅의 기록은 이어받지 않지만 폴더와 코드 변경은 공유한다. 저장된 사용자 지침이나 지속 메모리까지 없어지는 것은 아니다. 새 대화를 열어도 같은 잘못된 지침을 다시 읽는다면 그 지침부터 바로잡아야 한다.

인계에는 결론과 가설을 나눠 남긴다

새 대화에 긴 실패 기록을 통째로 복사하면 이전 접근을 다시 끌고 들어갈 수 있다. 다음은 목표·현재 상태·미확인 가설·검증 방법을 나눠 전달하는 인계 예시다.

목표: API 응답 형식은 유지하면서 페이지네이션 오류를 고친다.
현재 상태: 수정 파일과 테스트 결과는 작업 폴더에 남아 있다.
확인된 사실: 기존 페이지네이션 테스트가 같은 입력에서 실패한다.
아직 가설: 패키지 버전 문제라는 추정은 입증되지 않았다.
다음 작업: 현재 코드를 읽고 실패 원인을 새로 설명한 뒤 수정한다.
완료 조건: 기존 API 테스트 전체를 통과하고 변경 이유를 설명한다.

‘20만 토큰이 되면 무조건 초기화’ 같은 숫자보다 중요한 것은 다음 시도가 새로운 근거를 얻는가다. 유효한 수정은 남기고, 실패한 가설은 사실과 분리하며, 같은 오류가 환경 문제라면 그 원인을 해결해야 한다.