이 글에서 정리하는 내용
AI 에이전트가 실패할 때 원인을 모델 성능에서만 찾으면 같은 문제가 반복됩니다. 장기 작업에서는 사용자 의도, 현재 단계, 중간 결과물, 실패 원인, 재개 지점을 따로 저장해야 합니다. 이 글은 에이전트 품질을 프롬프트가 아니라 상태 관리 구조로 보는 기준을 정리합니다.
- 똑똑한 모델인데도 에이전트가 반복해서 실패하는 장면
- 대화 기록과 작업 상태는 같은 것이 아니다
- 에이전트 상태를 네 종류로 나누기
- 체크포인트와 재시도 정책이 필요한 이유
- 바로 적용할 수 있는 상태 관리 체크리스트
똑똑한 모델인데도 에이전트가 반복해서 실패하는 장면
AI 에이전트를 써보면 모델은 꽤 똑똑한데 작업은 이상하게 흔들릴 때가 있습니다. 파일을 수정하고 테스트를 돌린 뒤 실패 원인을 봤는데, 다음 단계에서 방금 본 오류를 잊은 것처럼 같은 수정을 반복합니다. 사용자가 “아까 그 방식 말고 다른 방식으로 해봐”라고 말해도 어떤 방식이 실패했는지 명확히 복구하지 못합니다.
이 문제는 단순히 모델이 부족해서만 생기지 않습니다. LLM은 현재 입력을 해석하는 데 강하지만, 장기 작업의 상태 저장소는 아닙니다. 대화 기록이 길게 남아 있어도 지금 작업이 어느 단계인지, 어떤 산출물이 확정됐는지, 어떤 툴 호출이 실패했는지, 다시 시작한다면 어디서 이어가야 하는지는 별도 구조로 관리해야 합니다.
특히 개발 자동화에서는 이 차이가 크게 드러납니다. 코드 수정, 테스트 실행, 로그 분석, 재시도, 문서 업데이트가 이어지는 동안 에이전트는 대화 내용뿐 아니라 작업 상태를 계속 갱신해야 합니다. 관련 도구 흐름을 볼 때는 VS Code Copilot 디버깅처럼 로그를 확인하는 방식도 중요하지만, 로그만으로는 현재 작업의 의사결정 상태를 대신할 수 없습니다.
대화 기록과 작업 상태는 같은 것이 아니다
에이전트 설계에서 자주 생기는 착각은 “대화 기록을 많이 넣으면 기억을 잘할 것”이라는 생각입니다. 물론 최근 대화는 필요합니다. 하지만 대화 기록은 비정형 문장이고, 작업 상태는 재개와 검증을 위한 정형 정보입니다. 둘을 섞으면 에이전트가 매번 긴 문맥을 다시 읽고 추론해야 해서 실수 여지가 커집니다.
작업 상태에는 최소한 네 가지가 들어가야 합니다. 사용자가 원하는 목표, 현재 실행 단계, 중간 산출물, 실패 기록입니다. 예를 들어 “블로그 글을 작성한다”는 목표만 저장하면 부족합니다. 기획을 읽었는지, HTML을 만들었는지, 이미지가 첨부됐는지, 검증에서 어떤 항목이 실패했는지까지 분리되어야 다음 실행이 안전해집니다.
{
"taskId": "blog-write-2026-05-08",
"goal": "기획 글을 작성 DB에 1~7단계로 생성",
"currentStep": "html-template-validation",
"artifacts": ["html", "wordpressJson", "images"],
"lastError": null,
"resumeFrom": "validate-html"
}이런 작은 상태 스키마가 있으면 에이전트는 “무엇을 했는지”를 대화에서 다시 추측하지 않아도 됩니다. 실패해도 resumeFrom을 기준으로 이어갈 수 있고, 사람이 확인할 때도 현재 병목이 어디인지 바로 볼 수 있습니다.
에이전트 상태를 네 종류로 나누기
첫 번째는 사용자 의도입니다. 사용자가 원하는 최종 결과, 완료 조건, 하지 말아야 할 일을 저장합니다. “글 작성”처럼 넓은 표현보다 “Notion 작성 DB에 1~7단계 토글을 만들고, 이미지 3장을 첨부하고, HTML 템플릿 검증까지 통과한다”처럼 성공 조건을 함께 둬야 합니다.
두 번째는 현재 단계입니다. 에이전트가 지금 수집 중인지, 작성 중인지, 검증 중인지, 외부 반영 중인지 구분합니다. 이 구분이 없으면 실패 후 재시도할 때 이미 끝난 작업을 다시 하거나, 반대로 꼭 필요한 검증을 건너뛰기 쉽습니다.
세 번째는 중간 결과물입니다. 생성된 HTML, JSON, 이미지 파일, 테스트 로그, Notion 페이지 ID 같은 값입니다. 중간 결과물은 대화 안에만 두지 말고 파일이나 데이터베이스에 남기는 편이 안전합니다. AI 하네스 파일 사용법처럼 작업 지침과 산출물 위치를 분리해두면 다음 실행에서 훨씬 덜 흔들립니다.
네 번째는 실패 기록입니다. 실패 기록은 단순 에러 메시지가 아니라 “무엇을 시도했고 왜 실패했는지”를 담아야 합니다. 같은 명령을 다시 실행하면 해결되는 일인지, 입력이 잘못된 일인지, 권한이나 외부 API 제한인지 구분해야 재시도 정책이 달라집니다.
체크포인트와 재시도 정책이 필요한 이유
에이전트가 안정적으로 보이려면 잘하는 순간보다 실패한 뒤의 행동이 중요합니다. 툴 호출이 실패했을 때 바로 같은 요청을 반복할지, 입력을 바꿔 다시 시도할지, 사람에게 확인을 요청할지 결정해야 합니다. 이 기준이 없으면 자동화는 빠르게 움직이지만 예측하기 어려운 시스템이 됩니다.
체크포인트는 “여기까지는 확정됐다”는 표시입니다. 예를 들어 기획 읽기, 초안 작성, 이미지 생성, HTML 검증, Notion 반영을 각각 체크포인트로 나누면 중간 실패 후에도 전체를 다시 만들 필요가 없습니다. 업무 자동화 관점에서는 업무 자동화 도구 비교에서 다루는 도구 선택보다 이런 복구 지점 설계가 더 먼저일 때가 많습니다.
재시도 정책도 작게 정해야 합니다. 네트워크 오류는 짧게 재시도할 수 있지만, 검증 실패는 같은 작업을 반복한다고 해결되지 않습니다. 검증 실패는 원인을 기록하고 수정 단계로 돌아가야 합니다. 권한 문제나 외부 공개 반영처럼 영향이 큰 작업은 자동 재시도보다 사람 확인이 더 안전합니다.
바로 적용할 수 있는 상태 관리 체크리스트
에이전트를 만들거나 도입할 때는 먼저 목표와 성공 조건을 분리해 저장합니다. 목표는 “무엇을 할 것인가”이고, 성공 조건은 “언제 끝났다고 볼 것인가”입니다. 성공 조건이 없으면 에이전트는 산출물을 만들고도 검증 없이 완료했다고 말할 수 있습니다.
그다음 단계별 산출물을 남깁니다. 생성한 파일 경로, 외부 페이지 ID, 테스트 결과, 검증 결과를 기록하면 다음 실행이 이어받을 수 있습니다. 마지막으로 실패 원인을 분류합니다. 입력 오류, 도구 오류, 권한 오류, 검증 오류를 구분하면 재시도 방식이 달라지고, 사람에게 물어야 할 때도 질문이 짧아집니다.
상태 관리는 거창한 플랫폼이 아니어도 시작할 수 있습니다. 작은 자동화라면 체크리스트 파일 하나, 작업별 JSON 하나, 실패 로그 한 줄만 있어도 효과가 납니다. 중요한 것은 모델에게 모든 것을 기억하라고 맡기지 않고, 사람이 나중에 확인할 수 있는 형태로 목표와 진행 상황을 남기는 것입니다. 이렇게 해두면 에이전트가 중간에 멈춰도 다음 실행은 같은 질문을 반복하지 않고 검증 지점에서 이어갈 수 있습니다.
좋은 에이전트는 더 긴 프롬프트에서만 나오지 않습니다. 더 안정적인 상태 저장, 작은 체크포인트, 실패 후 복구 가능한 구조에서 나옵니다. 모델 성능은 계속 좋아지겠지만, 작업을 끝까지 책임지는 구조는 제품과 팀이 따로 설계해야 합니다.