50번의 데모가 완벽했다. 그리고 첫 번째 실사용자가 이력서를 올린 순간, 에이전트는 존재하지 않는 학위와 직책을 만들어냈다. dev.to에 공개된 Abdul Rehman의 프로덕션 AI 파이프라인 분석이 전하는 이 사례는 단순한 해프닝이 아니다. 팀이 AI 에이전트를 프로덕션에 올릴 때 반드시 부딪히는 구조적 실패의 전형이다.
루프가 깨지는 세 가지 지점
에이전트가 데모에서 프로덕션으로 넘어갈 때 무너지는 지점은 거의 항상 같다. 첫째, 스키마가 거짓말을 강요한다. LLM은 주어진 스키마를 만족시키려는 경향이 있다. education 필드가 필수로 지정되어 있으면, 데이터가 없어도 채운다. 모델이 나쁜 게 아니다. 모델이 없는 걸 '없다'고 말할 수 있는 설계가 없었던 것이다. Rehman이 제안하는 해법은 단순하다. confidence 필드와 has_insufficient_data 플래그를 스키마에 넣어, 모델이 거절할 수 있는 경로를 만들어주는 것이다.
둘째, 루프에 경계가 없다. Mano-AFK 팀이 dev.to에서 공개한 분석에 따르면, 3~5스텝 루프는 잘 작동한다. 문제는 50~100스텝으로 늘어날 때다. 에이전트는 잘못된 판단을 내리고도 그것을 인지하지 못한 채 다음 스텝을 밟는다. 잘못 구성된 필드 하나가 빌드 실패를 유발하고, 에이전트는 이를 의존성 문제로 해석해 패키지 재설치를 시작한다. 10스텝 뒤, 에이전트는 원래 목표에서 완전히 멀어져 있다. Mano-AFK 팀은 이 문제를 적대적 리뷰어(adversarial reviewer)로 해결했다. 메인 에이전트의 결정을 매 스텝마다 독립적으로 평가하는 별도 에이전트 인스턴스를 두고, 목표에서 이탈하면 강제로 재시도하게 만드는 구조다. 더 강한 모델로 교체하는 것보다 이 메커니즘 하나가 안정성에 훨씬 더 큰 영향을 줬다고 그들은 밝힌다.
셋째, LLM이 LLM을 심판하는 구조 자체가 틀렸다. dev.to에서 여섯 개의 실험을 통해 이를 분석한 zxpmail의 글은 냉정하다. 어휘 중복은 의미와 다르고(50% 오분류), temperature 0은 결정론적 결과를 보장하지 않으며(70% 일관성), 강한 모델은 false positive를 줄이는 대신 valid한 작업의 75%를 거부했다. LLM 품질 게이트는 정밀도-재현율 트랩에서 벗어날 수 없다.
결정론적 라우팅이 답이 되는 이유
그렇다면 대안은 무엇인가. zxpmail이 제안하는 구조는 단순하지만 근본적으로 다른 전제에서 출발한다. 정확성을 판단하지 말고 리스크를 판단하라. 태스크를 출력 유형에 따라 네 가지로 분류한다. 컴파일하거나 스키마로 검증 가능한 것(코드, JSON, SQL)은 그 검증 자체가 게이트다. LLM 심판이 필요 없다. 금전, 법적, 개인정보 관련 고위험 작업은 에이전트가 실행하지 않는다. 초안만 제공하고 인간이 결정한다. 내부 브리프나 브레인스토밍 같은 저위험 콘텐츠는 'draft' 태그를 달아 자동 릴리즈한다. 클라이언트 이메일처럼 중간 리스크인 경우에는 전체 텍스트 판단 대신 diff 리뷰만 한다. 변경된 부분만 보여주고 '이 변경이 오류를 만드는가?'라는 단 하나의 질문만 남긴다. 인지 부하가 극적으로 줄어든다.
이 구조에서 또 하나 주목할 것은 통계적 프로세스 제어(SPC)다. 시맨틱 클러스터링이 실패하는 이유는 서로 다른 주제의 콘텐츠는 잘못 거부되어도 임베딩 공간에서 가까이 붙지 않기 때문이다. 대신 실행 스텝 수, 툴 콜 횟수, 출력 길이, 특수문자 비율 같은 행동 특성으로 이상 감지를 한다. 출력 길이가 0이거나 특수문자가 100%인 경우는 내용을 이해하지 않아도 LLM 없이 잡아낼 수 있다. 단, SPC가 못 잡는 것도 명확하다. 포맷은 정상인데 내용이 틀린 경우다. 이건 샘플링으로 커버한다. 신뢰도 점수 대신 고정 비율 샘플링(5~20%)을 쓰는 이유는 수학적 특성이 알려져 있기 때문이다. 피드백 루프 없이 보정이 필요한 신뢰도 점수보다 훨씬 운영하기 쉽다.
팀에게 실제로 의미하는 것
이 모든 분석이 수렴하는 지점은 하나다. 에이전트 루프의 실패는 대부분 모델 문제가 아니라 설계 문제다. Mano-AFK 팀이 발견한 것처럼, 컨텍스트 윈도우가 충분해도 모델은 20~30스텝 이후 초기 제약조건에 대한 집중력을 잃는다. 이를 파일시스템에 중간 상태를 명시적으로 직렬화함으로써 해결했다. 루프가 50스텝에서 크래시 나면 처음부터 다시가 아니라 그 지점부터 재개할 수 있어야 프로덕션이 된다.
내일 당장 팀에 적용할 수 있는 체크리스트는 세 가지다. 첫째, 모든 LLM 스키마에 모델이 '모른다'고 말할 수 있는 경로를 만든다. confidence 필드와 has_insufficient_data 플래그가 없는 스키마는 hallucination을 강요하는 구조다. 둘째, 에이전트 루프에 반드시 반복 횟수 상한을 건다. 루프가 N회를 넘으면 부분 결과라도 반환하고 멈춰야 한다. 에이전트가 무한정 돌 수 있는 구조는 프로덕션이 아니다. 셋째, 태스크를 리스크 기준으로 분류하고, 고위험 태스크는 에이전트 실행 경로에서 아예 빼낸다. LLM이 잘하는 것(생성)과 못하는 것(시맨틱 판단)을 분리하는 게 설계의 출발점이다.
전망
모델은 계속 좋아진다. 하지만 Mano-AFK의 58% 엔드투엔드 자율 완료율이 보여주는 것처럼, 벤치마크의 단일 스텝 정확도와 실제 루프 완주율은 전혀 다른 문제다. 더 강한 모델을 기다리는 것은 자연스러운 반응이지만, 루프 구조 설계, 독립 리뷰 배치, 장기 상태 영속화, 오류 캐스케이드 차단은 파라미터 수가 늘어도 자동으로 해결되지 않는 엔지니어링 문제다. 팀이 지금 해야 할 일은 더 나은 모델을 기다리는 것이 아니라, 현재 모델이 안전하게 실패할 수 있는 루프를 설계하는 것이다.