AI 코딩 에이전트를 써보면 분명 계획은 그럴듯한데, 중간부터 엉뚱한 파일을 읽거나 이미 끝난 작업을 다시 하거나 방금 본 테스트 결과를 놓치는 순간이 있습니다. 이런 현상은 단순히 계획을 못 세워서가 아니라, 대개 상태를 잃어버렸기 때문에 생깁니다. 실전의 코딩 에이전트는 무엇을 하겠다고 말하느냐보다, 지금 어디까지 했고 어떤 결과가 최신인지 끝까지 추적하느냐가 더 중요합니다.
이번 글에서는 task drift, context loss, tool result reflection failure를 중심으로 왜 코딩 에이전트가 중간에 딴길로 새는지 정리해보겠습니다.
먼저 결론
코딩 에이전트의 실패는 계획 단계와 실행 단계로 나눠서 봐야 합니다. 계획 단계에서는 문제를 잘못 이해하거나 수정 방향을 잘못 잡는 일이 생기지만, 실제로 더 자주 품질을 무너뜨리는 쪽은 실행 단계입니다.
- 처음 읽은 파일 상태를 계속 최신 상태라고 믿는다
- 도구 실행 결과를 다음 판단에 제대로 반영하지 못한다
- 테스트 실패와 timeout을 구분하지 못한 채 같은 작업을 반복한다
- 일부 단계만 성공했는데 전체 실패처럼 다시 시작한다
즉 코딩 에이전트의 문제는 계획 자체보다, 실행 중 상태를 일관되게 관리하지 못할 때 더 크게 터집니다.
왜 계획이 멀쩡해 보여도 중간부터 흔들릴까
데모에서는 요구사항 이해, 파일 읽기, 코드 수정, 테스트 실행, 결과 보고 정도로 짧게 끝납니다. 하지만 실제 프로젝트는 관련 파일 탐색, 여러 파일 읽기, 수정 계획 수립, 코드 변경, 테스트 실행, 로그 확인, 실패 원인 재해석, 추가 수정, 요약 보고처럼 단계가 길어집니다.
단계가 길어질수록 중요한 것은 무엇을 하기로 했나보다 지금 무엇이 이미 끝났고 무엇이 아직 불확실한가입니다. 바로 이 지점에서 상태 관리 난도가 급격히 올라갑니다.
task drift는 대개 계획 이탈이 아니라 상태 이탈이다
많은 사람이 에이전트가 딴길로 샌다고 하면 곧바로 계획 능력을 떠올립니다. 하지만 실제로는 계획이 맞았는데도, 중간에 읽은 정보와 실행 결과가 뒤섞이면서 task drift가 커지는 경우가 많습니다.
예를 들어 로그인 오류를 세션 만료 처리 문제로 보고 관련 파일을 읽기 시작했는데, 중간에 비슷한 예외를 가진 다른 모듈과 오래된 테스트 로그까지 섞이면 에이전트는 원래의 문제 경계를 흐릴 수 있습니다. 이때 drift는 방향 감각 부족보다 최신 근거를 계속 정리하지 못해서 생깁니다.
context loss는 파일을 많이 읽을수록 더 심해진다
코딩 에이전트는 여러 파일과 긴 로그를 함께 다루기 때문에 초기 요구사항과 핵심 제약이 뒤로 밀리기 쉽습니다. 문제는 context loss가 단순히 까먹음으로 끝나지 않고, 작업 범위 확장과 잘못된 우선순위로 이어진다는 점입니다.
처음에는 로그인 실패 시 재시도 안내만 추가하는 것이 목표였는데, 중간에 인증 모듈 전체를 리팩터링하려는 방향으로 커질 수 있습니다. 그래서 긴 세션의 코딩 에이전트는 많이 읽는 능력만큼 현재 목표와 비목표를 계속 다시 고정하는 장치가 필요합니다.
tool result reflection failure는 생각보다 흔하다
에이전트가 tool을 잘 호출했다고 해서 문제가 끝나지 않습니다. 진짜 중요한 것은 그 결과를 다음 판단에 제대로 반영하느냐입니다.
- 파일 검색 도구로 관련 파일 후보를 찾는다
- 파일 읽기 도구로 내용을 확인한다
- 수정 도구로 패치를 만든다
- 테스트 도구를 실행한다
- 테스트 결과를 읽고 다음 행동을 결정한다
여기서 흔한 실패는 테스트 결과가 실패 원인을 이미 좁혀줬는데도, 에이전트가 그 내용을 다음 계획에 충분히 반영하지 못해 같은 실수를 반복하는 것입니다. 도구는 불렀지만 결과가 판단 체계 안으로 제대로 들어오지 않은 상태라고 볼 수 있습니다.
stale file read는 코딩 에이전트의 대표적인 함정이다
처음 읽은 파일 상태가 끝까지 유효하다고 믿는 순간 문제가 시작됩니다. 에이전트가 파일을 읽고 수정 계획을 세운 뒤, 그 사이 사람이나 다른 프로세스가 파일을 바꿨다면 처음 읽은 내용은 이미 낡았습니다.
- patch가 깨진다
- 이미 수정된 부분을 다시 건드린다
- 관련 없는 라인까지 덮어쓴다
이 상황은 모델이 약해서라기보다, 최신 버전 검증 없이 오래된 상태를 붙잡고 있었기 때문에 생깁니다.
retry는 복구 장치이면서 drift 증폭기다
실전 도구 호출은 항상 성공하지 않습니다. 테스트가 timeout 날 수도 있고, 파일 수정 도구가 부분 성공 상태로 끝날 수도 있고, 외부 명령 실행이 중간에 끊길 수도 있습니다. 문제는 retry가 상태 없이 붙으면 drift를 더 키운다는 점입니다.
예를 들어 테스트 명령이 timeout으로 끝났는데 실제로는 백그라운드에서 계속 돌아가고 있었다면, 에이전트가 이를 단순 실패로 해석하고 같은 테스트를 다시 여러 번 돌리면서 어느 결과가 최신인지부터 헷갈릴 수 있습니다.
partial success를 실패로 뭉개면 같은 일을 두 번 하게 된다
코딩 에이전트 작업은 일부만 성공하는 경우가 더 많습니다. 예를 들어 코드 수정은 이미 적용됐는데 마지막 요약 작성이나 테스트 보고만 실패할 수 있습니다. 이때 시스템이 전체 상태를 구분하지 못하면 다음 실행에서 처음부터 다시 수정하려고 듭니다.
그래서 코딩 에이전트는 성공과 실패 두 칸만으로는 부족하고, 어느 step까지 확정됐는지 분리해서 기록해야 합니다.
왜 상태 관리가 계획보다 더 중요해질까
- 지금 보고 있는 파일이 최신인가
- 방금 실행한 테스트가 아직 유효한가
- 이 오류 로그는 수정 전 결과인가 수정 후 결과인가
- 이 패치는 이미 적용됐는가
- 다음 행동을 정할 만큼 증거가 충분한가
이 질문에 답하지 못하면 아무리 좋은 계획도 금방 낡아버립니다. 그래서 실전에서는 계획 엔진보다 상태 장부가 더 중요해지는 순간이 자주 옵니다.
코딩 에이전트가 최소한 남겨야 할 상태
- 현재 목표와 비목표
- 현재 step
- 읽은 파일 목록과 읽은 시점
- 각 파일의 버전 정보나 마지막 확인 기준
- 실행한 명령과 실행 시각
- 테스트 결과 요약과 원문 위치
- 마지막으로 확정된 실패 원인 가설
- 이미 적용된 수정 여부
- retry count
- 사람 확인이 필요한 경계
이 정보가 없으면 에이전트는 매번 현재를 처음 보는 것처럼 행동하기 쉽습니다. 반대로 이 정보가 잘 남아 있으면 같은 모델이라도 훨씬 덜 흔들립니다.
더 안정적인 코딩 에이전트는 보통 덜 화려하다
- 수정 전 최신 파일을 다시 확인한다
- 테스트 결과를 요약만 보지 않고 실패 지점과 연결한다
- 쓰기 작업 뒤에는 실제 반영 상태를 다시 읽는다
- 모호하면 더 많은 수정 대신 clarifying question을 택한다
- 중단 후 재개할 때는 마지막 checkpoint부터 다시 확인한다
이런 구조는 시연 화면에서는 덜 인상적일 수 있지만, 실제 개발 workflow에서는 이런 보수성이 task drift를 크게 줄입니다.
이런 증상이 보이면 프롬프트보다 상태 모델을 먼저 봐야 한다
- 처음엔 맞는 방향인데 중간부터 다른 파일을 건드린다
- 같은 테스트를 여러 번 돌리면서 최신 결과를 헷갈린다
- 이미 반영된 수정을 다시 하려 든다
- 긴 로그를 읽은 뒤 원래 목표를 놓친다
- 도구 결과는 많지만 다음 판단이 계속 어긋난다
이런 문제는 대개 말재주보다 상태 구조 문제에 가깝습니다. 즉 더 잘 계획하게 만들자보다 어떤 사실을 확정 상태로 저장해야 하나를 먼저 물어야 합니다.
정리
AI 코딩 에이전트가 중간에 딴길로 새는 이유는 계획이 없어서가 아니라, 상태를 잃어버린 채 계획을 계속 밀어붙이기 때문인 경우가 많습니다.
코딩 에이전트의 품질은 멋진 계획 문장보다, 최신 상태와 실행 결과를 얼마나 일관되게 추적하고 반영하느냐에 더 크게 좌우됩니다.
관련 글로는 MCP란 무엇인가, ReAct 논문 쉽게 이해하기, AI 에이전트 planning: 왜 필요할까를 함께 보면 흐름이 더 잘 이어집니다.
주요 참고 문서는 OpenAI function calling guide, Anthropic tool use overview, LangGraph durable execution입니다.
