에이전트가 2시간 돌다가 틀린 결과를 자신 있게 내놓는 경험을 한 번이라도 해봤다면, 이 이야기는 당신 얘기다. Hacker News의 Claude Code 스레드에서 396 업보트를 받은 최상위 댓글은 프롬프트 기법에 관한 게 아니었다. "화려한 오케스트레이션은 대부분 낭비다. 병목은 검증이다." 커뮤니티가 독립적으로 같은 결론에 도달했다는 건, 이게 특정 팀의 운영 미숙이 아니라 구조적 문제라는 신호다.
왜 에이전트는 중간에 길을 잃는가
문제의 본질은 '컨텍스트 드리프트(context drift)'다. 에이전트가 틀린 가정을 조용히 채택하고, 오류를 트리거하지 않은 채 다음 단계로 넘어가고, 그 이후의 모든 단계가 잘못된 전제 위에 쌓인다. 모델이 환각을 일으키는 게 아니다. 작은 방향 이탈이 누적되는 것이다. 10번의 툴 콜이 지난 뒤 문제가 표면에 드러날 때, 근본 원인은 이미 흔적도 없이 묻혀 있다.
Velog에 올라온 실무 분석이 이 구조를 정확히 짚는다. 엑셀 자동화는 잘 되고 코딩 에이전트는 자꾸 꼬이는 이유는 모델 성능 차이가 아니다. 엑셀 작업은 범위가 좁고, 결과를 즉시 눈으로 검증할 수 있고, 한 세션으로 끝난다. 코딩은 반대다. 요구사항이 코드베이스 전체로 퍼지고, "빌드 성공"과 "실제로 맞음" 사이의 거리가 멀고, 맥락이 세션을 넘어 이어진다. 같은 모델인데 작업 구조가 다르면 결과가 달라진다. 그러니 '더 좋은 모델'을 기다리기 전에 '더 나은 작업 구조'를 설계하는 게 먼저다.
검증 게이트 세 개가 드리프트를 막는다
실전에서 수렴한 패턴은 명확하다. 페이즈 경계마다 검증 게이트를 세워서, 드리프트가 5단계 후가 아니라 경계에서 바로 드러나게 만드는 것이다. 구체적으로 세 개의 게이트가 작동한다.
첫 번째는 실행 전 스펙 잠금(Pre-execution Spec Lock)이다. 코드를 한 줄도 쓰기 전에 에이전트가 구조화된 포맷으로 스펙을 생성하고, 오케스트레이터가 원래 태스크와 대조해 불일치하면 실행을 멈춘다. Hacker News 커뮤니티가 독립적으로 발견한 PLAN.md 패턴이 바로 이것이다. 의도를 실행 전에 문서로 고정하면, 에이전트가 나중에 방향을 바꿔도 원점 비교가 가능해진다.
두 번째는 단계별 상태 어서션(Post-step State Assertion)이다. 각 툴 콜이나 파일 쓰기 이후, 에이전트가 현재 세계 상태에 대해 믿고 있는 것을 명시적으로 선언하고, 별도 체크가 실제 디스크/API 상태와 대조한다. PROGRESS.md가 이전 단계 검증 완료를 기록해야만 다음 단계로 넘어갈 수 있는 구조다. 이것이 강제 장치(forcing function)다.
세 번째는 크로스 에이전트 리뷰(Cross-agent Review)다. 구현한 에이전트가 검증도 맡으면 안 된다. 생성 컨텍스트는 자신의 가정에 닻을 내리고 있어서, 그 가정 위에서 생긴 오류를 잘 못 잡는다. 새 컨텍스트 윈도우에서 출력물을 읽는 별도 에이전트가 스펙과 대조해 사인오프해야만 태스크가 진행된다. Agent A가 코드를 쓰고, Agent B가 의도를 모른 채 diff를 리뷰하는 구조다.
상태 머신이 없으면 크래시가 재앙이 된다
dev.to에 공개된 Claude API 기반 전자책 자동화 파이프라인 구축 사례는 이 검증 설계를 프로덕션 코드 레벨에서 보여준다. 파이프라인의 핵심은 상태 머신이다. 챕터마다 PENDING → RUNNING → DONE → NEEDS_REVIEW 상태 전이를 SQLite에 기록하고, 크래시가 나면 마지막 RUNNING 챕터부터 재개한다. 첫 번째 실전 실행이 네트워크 타임아웃으로 챕터 4에서 죽었고, 상태 지속성이 없었다면 처음부터 다시 돌려야 했다. 상태 머신 구현 후에는 재실행이 실제로 변경이 필요한 것만 건드렸다.
코드 검증도 두 레이어로 설계됐다. ast.parse()로 구문 유효성을 먼저 검사하고, 그 다음 격리된 환경에서 실제 실행해 예외와 비정상 종료 코드를 확인했다. 이 과정이 없었다면, 문서 미리보기에서는 멀쩡해 보이지만 실제로는 정의되지 않은 변수를 참조하는 코드가 독자에게 그대로 배포됐을 것이다. 비용 계산도 현실적이다. 검증 단계는 토큰을 소비한다. 하지만 프롬프트 캐싱을 활용하면 검증 오버헤드는 전체 세션 비용의 10~15% 수준이다. 반면 2시간짜리 에이전트 실행이 틀린 결과를 자신 있게 완성하는 실패 비용은 비교가 안 된다.
팀에서 당장 적용할 수 있는 설계 원칙
이 패턴들을 팀 워크플로우에 이식하는 순서를 정리하면 이렇다.
첫째, 페이즈 경계 게이트부터 세운다. 성문화된 상태 어서션 없이는 어떤 것도 페이즈를 넘어가지 못한다는 규칙 하나만으로도 드리프트 실패의 약 70%가 차단된다는 게 실전 데이터다.
둘째, 구현자와 검증자를 분리한다. 사람 팀에서도 작성자가 자기 코드를 바로 리뷰하면 오류를 놓치는 것과 같은 원리다. 에이전트도 마찬가지다. CLAUDE.md나 팀 작업 지침에 "한 단계 작업 후 무엇을 바꿨는지, 무엇으로 검증했는지, 무엇이 아직 불확실한지를 남긴다"는 형식을 박아두는 것만으로 품질이 달라진다.
셋째, 맥락을 회수 가능한 형태로 압축한다. 어제 디버깅에서 알아낸 사실이 오늘 세션에서 사라지면, 에이전트는 항상 첫날 수준으로 돌아간다. 세션 간 행동과 판단 흔적을 자산화하는 메모리 인프라는 편의 기능이 아니라 실무 성능 인프라다.
설계로 막지 않으면 속도가 부채가 된다
결국 이 모든 패턴이 가리키는 곳은 하나다. 에이전트 품질은 모델 추론 능력만큼이나 작업 절차의 제약에 좌우된다. 빠른 생성 속도는 검증 설계 없이는 기술 부채의 속도일 뿐이다.
AI 에이전트를 잘 쓰는 팀은 에이전트를 더 믿는 팀이 아니다. 에이전트가 실패할 구간을 미리 잘라놓은 팀이다. 페이즈 경계 게이트, 역할 분리된 리뷰, 상태 머신 기반 크래시 복구—이 세 가지는 내일 당장 워크플로우에 박아 넣을 수 있는 설계 결정이다. 모델 업그레이드를 기다릴 이유가 없다.