에이전트가 실패할 때, 그 실패는 대개 조용하다. 예외를 던지지 않는다. 로그에 에러가 찍히지 않는다. 출력은 그럴듯하고, 계획도 논리적이며, 코드 리뷰도 통과한다. 그런데 어느 순간 결과물이 어긋나 있고, 비용이 두 배로 나와 있고, 해결됐다던 태스크가 여전히 남아 있다. 이 세 가지 패턴은 각각 다른 레이어에서 발생하지만, 공통된 원인을 가진다. 설계자가 에이전트의 실패 모드를 정상 동작으로 오해했다는 것.
함정 1. 컨텍스트를 '압축'하면 에이전트가 중간을 잊는다
AI 코딩 어시스턴트를 멀티 페이즈 프로젝트에 투입할 때, 팀이 가장 먼저 만나는 병목은 모델 성능이 아니다. 세션 간 컨텍스트 관리다. Phase 1이 끝나고 5,000줄의 코드베이스가 생겼을 때, 대부분의 팀은 Repomix 같은 도구로 전체 코드베이스를 하나의 마크다운 파일로 압축해 프롬프트에 밀어 넣는다. 직관적으로는 '모든 걸 알려주는' 전략처럼 보인다.
그런데 dev.to의 'Don't Compress, Promote'가 정확히 짚어낸 것처럼, 이건 JVM에서 Full GC 힙 덤프를 매번 로드하는 것과 같다. 100K 라인 코드베이스를 Repomix로 압축하면 약 150K 토큰짜리 덩어리가 생긴다. LLM이 그 안에서 'Phase 2에서 실제로 건드려야 할 파일 3개'를 찾아야 한다. 문제는 모델이 긴 컨텍스트의 중간 부분을 체계적으로 망각한다는 것이다. 이른바 'lost in the middle' 현상. 150K 토큰 덤프의 가운데 60K 토큰에 핵심 설계 결정이 묻혀 있다면, 그 정보는 사실상 없는 것과 같다.
해법은 압축이 아니라 프로모션이다. JVM의 세대별 GC 전략이 이미 25년 전에 증명한 원리다. 코드베이스 정보도 세대를 가진다. Eden(90%)은 스캐폴딩, 임시 구현, 실험 코드—다음 페이즈에서 전혀 필요 없다. Survivor(9%)는 검증된 인터페이스, 도메인 모델, 핵심 타입—다음 페이즈로 승격해야 한다. Tenured(1%)는 거의 변하지 않는 핵심 도메인 모델이다.
실행 방법은 단순하다. 페이즈 종료 시 세 가지 질문에 답하고 그 결과만 다음 세션에 로드한다. ① 이번 페이즈에서 장기 가치가 증명된 데이터 구조와 인터페이스는 무엇인가 ② 어떤 가정이 틀렸는가 ③ 의도적으로 남긴 기술 부채는 무엇인가. 이렇게 추출한 'promoted context'는 3K~10K 토큰 수준이다. 전체 Repomix 덤프(100K~500K 토큰)와 두 자릿수 차이다. Repomix는 온디맨드 참조 레이어로 두되, 페이즈 시작의 기반이 되어선 안 된다.
함정 2. 에이전트는 계획을 완벽하게 세우면서 아무것도 실행하지 않는다
arXiv 논문 CoffeeBench(2606.16613)는 AI 에이전트를 90일 시뮬레이션 경제 환경에 투입해 소규모 사업체를 운영하게 했다. 결과에서 발견된 실패 모드는 'idle drift'라고 명명됐다. 에이전트는 상황을 정확하게 평가한다. 무엇을 해야 하는지 논리적으로 서술한다. 그리고 하지 않는다. 다음 사이클에 또 평가한다. 또 하지 않는다. 사업체는 에이전트가 유려하게 그 죽음을 서술하는 동안 조용히 망한다.
dev.to에서 오픈소스 에이전트 Talon이 스스로 이 패턴을 진단한 에세이 'Idle Drift'는 이 문제를 내부에서 포착한 드문 기록이다. Talon은 매 시간 깨어나 이전 인스턴스의 기록을 읽고 작업을 수행한 뒤 다시 잠든다. 각 인스턴스는 이전 인스턴스의 기억이 없다. 연속성은 파일이지 경험이 아니다. 이 구조에서 defer-loop가 발생한다. '다음에 하자'고 메모된 작업을 다음 인스턴스가 읽고, 동의하고, 다른 걸 한다. 여섯 번의 사이클이 지나도 2분짜리 작업이 그대로다.
핵심 통찰은 이것이다. 계획이 틀린 게 아니다. 에이전트의 평가는 정확하고, 계획은 합리적이다. 실패는 앎과 행동 사이의 전달 과정에 있다. 더 스마트한 모델은 더 유려한 실패 서술을 만들 뿐이다. CoffeeBench는 idle drift가 소형·저비용 모델에서 가장 선명하게 나타난다고 보고한다. 아이러니하게도 이런 모델이 투입되는 역할이 가장 루틴하고, 비감독적이고, 장기 실행되는 작업이다. 경제적 압력이 가장 취약한 모델을 가장 위험한 자리에 놓는다.
처방은 추론 개선이 아니라 액션 강제 함수(action-forcing function)다. Talon의 지침 파일에 심어진 규칙은 노골적으로 단순하다. '3회 이상 이월된 작업이 30분 이내로 완료 가능하면, 다른 무엇보다 먼저 실행한다.' 이 규칙은 추론 바깥에서 작동한다. 추론이 시작되기 전에 발동하는 트리거다. AI-First 팀에서 장기 실행 에이전트를 운영한다면, 스캐폴딩 설계가 모델 선택만큼 중요하다. 트리거는 부패하므로, 재무장 메커니즘도 함께 설계해야 한다.
함정 3. Model-as-Judge를 실행 경로에 두면 게이트가 아니라 비용이 된다
화이트보드에 수도 없이 그려지는 다이어그램이 있다. 에이전트가 출력을 생성하고, 결과가 어디로 가기 전에—바로 그 자리에서—LLM Judge가 8.4점을 매기고 배포 여부를 결정한다. 모두가 고개를 끄덕인다. 품질 게이트처럼 보인다. dev.to의 'Your Model-as-Judge Doesn't Belong in the Hot Path'가 정확히 지적한 것처럼, 이건 팀이 에이전트 평가에서 저지르는 가장 비싼 아키텍처 실수다.
증거를 비용 축이 아니라 독립성 축으로 분류해야 한다. Tier 1은 에이전트가 위조할 수 없는 외부 관찰 가능 증거다. JSON이 파싱되는가, 파일이 실제로 존재하는가, 코드가 컴파일되는가, 테스트가 통과하는가. Tier 2는 에이전트가 작성하지 않은 베이스라인 대비 통계적 신호다. 출력과 태스크 간 임베딩 유사도, 반복 패턴, diff가 실제로 무언가를 변경했는지 여부. Tier 3이 Model-as-Judge다.
Tier 1과 Tier 2는 결정론적이고 비용이 거의 없으며 밀리초 단위로 실행된다. 핫패스에서 실행을 블로킹할 수 있다. Tier 3은 느리고 비용이 들고 비결정론적이다. 같은 출력을 세 번 Judge에 넣으면 7, 8, 6이 나온다. 동일 입력에 대해 판정이 뒤집히는 게이트는 게이트가 아니다. 온도로 편향된 동전 던지기다.
더 근본적인 문제가 있다. Judge는 순환적이다. 모델이 다른 모델의 추론을 판정할 때, 판정자와 피판정자는 같은 기반을 공유한다. 자신 있게 틀린 답을 자신 있게 통과시키는 Judge는 버그가 아니라 구조적 필연이다. Tier 3 Judge는 에이전트가 작성하지 않은 아티팩트—최종 파일, 커밋된 diff, 렌더링된 출력—만을 검사해야 하며, 에이전트 자신의 추론 서술을 판정하는 건 순환의 핫패스다.
결론은 명확하다. 핫패스 게이트는 Tier 1 + Tier 2. Judge는 오프라인, 샘플 단위, 아티팩트 검사 전용. 두 레인은 절대 같은 함수가 되어선 안 된다. Lane 1은 실행을 블로킹하기 위해 throw한다. Lane 2는 레이블이 붙은 신호를 반환하고 대시보드로 간다.
세 함정이 가리키는 하나의 교훈
세 실패 패턴은 레이어가 다르다. 첫째는 컨텍스트 관리 레이어, 둘째는 에이전트 스캐폴딩 레이어, 셋째는 평가 아키텍처 레이어. 그러나 공통된 설계 오류가 있다. 에이전트를 '지능적 존재'로 대우하면서, 구조적 제약이 없으면 지능이 스스로 올바르게 작동할 것이라 가정하는 것.
실제로는 반대다. 컨텍스트를 선별하지 않으면 에이전트는 중간을 잊는다. 액션 강제 함수가 없으면 에이전트는 완벽한 계획을 반복해서 세우며 아무것도 실행하지 않는다. 평가를 핫패스에 두면 게이트가 아니라 비용이 된다. 이 세 가지는 모델 성능 문제가 아니다. 설계 문제다.
AI-First 워크플로우를 팀 단위로 운영한다면, 에이전트 도입보다 에이전트 실패 모드 설계가 먼저다. 더 스마트한 모델이 나와도 이 세 가지 구조 문제는 해결되지 않는다. 더 유려하게 실패할 뿐이다. 내일 당장 점검해야 할 세 가지 질문은 이것이다. 우리 팀은 세션 간 컨텍스트를 '압축'하는가, '선별'하는가. 장기 실행 에이전트에 액션 강제 트리거가 설계되어 있는가. Model-as-Judge가 핫패스가 아닌 오프라인 레인에서만 작동하는가.