데모는 통과했는데, 프로덕션에서 죽었다
RAND Corporation 연구에 따르면 AI 프로젝트의 80~90%가 PoC 단계를 넘지 못한다. AI 에이전트는 그보다 더하다. 단순히 틀린 답을 내놓는 게 아니라 틀린 행동을 한다. 고객 ID를 환각하고, 같은 API를 40번 루프 돌리고, 월 예산을 하루 오후에 소진하고, 재현 불가능한 에러와 함께 크래시한다. 그리고 로그는 없다.
나는 이 실패가 "AI가 아직 준비 안 됐다"는 기술 성숙도 문제가 아니라고 단언한다. 대부분은 설계 실패다. 그리고 설계 실패엔 알려진 해법이 있다.
실패 패턴 1: God Agent 안티패턴
가장 흔한 실수는 하나의 에이전트에 모든 것을 욱여넣는 것이다. 이메일, 캘린더, 데이터 분석, 코드 생성을 하나의 에이전트에 붙이다 보면 시스템 프롬프트는 10,000 토큰이 되고, 등록된 툴은 20개를 넘는다. dev.to의 분석에 따르면 5개 툴 에이전트의 라우팅 정확도가 95%라면, 25개 툴 에이전트는 70%까지 떨어진다. 이 30% 오류율이 멀티스텝 워크플로우에서 복리로 쌓인다.
해법은 전문가 에이전트 분해(decomposition)다. 이메일 에이전트, 리서치 에이전트, 코드 에이전트를 각각 3~5개 툴과 500토큰 이내 시스템 프롬프트로 운영하고, 라우터가 4개 선택지 사이에서만 결정을 내리게 한다. 20개 툴 중 고르는 문제를 4개 에이전트 중 고르는 문제로 단순화하는 것만으로 라우팅 정확도를 95% 이상으로 유지할 수 있다. 팀에서 에이전트 설계를 시작한다면, 첫 번째 질문은 "이 에이전트가 몇 개의 툴을 갖고 있나"여야 한다.
실패 패턴 2: Happy Path 함정과 Context 파산
두 번째 실패는 에러 복구 없이 배포하는 것이다. 실제 프로덕션 데이터를 보면 브라우저 자동화 태스크의 약 30%가 페이지 로드 이슈로 실패하고, API 집약적 워크플로우의 20~25%에서 레이트 리밋이 발생한다. 에러 복구가 없는 에이전트는 API 타임아웃 하나에 전체 멀티스텝 워크플로우가 죽는다.
서킷 브레이커 패턴이 처방이다. 일시적 실패엔 지수 백오프 재시도, 지속적 실패엔 서킷을 열어 연쇄 장애를 차단하고, 폴백 경로를 항상 확보한다. 폴백의 최후 수단이 "지금 이 작업을 수행할 수 없습니다"라는 메시지라도, 조용히 크래시하는 에이전트보다 무한히 유용하다.
세 번째 실패인 Context Window 파산은 더 교묘하다. 메시지, 툴 결과, 체인오브소트가 쌓이면 에이전트는 시스템 프롬프트 제약을 "잊고", 툴 이름을 환각하고, 이전 지시와 모순된 답을 내놓기 시작한다. 이를 막으려면 3계층 메모리 구조가 필요하다. 항상 컨텍스트에 있는 작업 메모리, 요약·정리되는 세션 메모리, 필요할 때만 조회하는 장기 메모리로 분리하고 오래된 메시지를 주기적으로 압축해야 한다.
실패 패턴 3: 인간 판단이 필요한 10%를 AI 혼자 처리하려 할 때
에이전트가 잘 처리하는 90%에 집중하다 보면, 나머지 10%가 파이프라인 전체를 멈추게 한다. 콘텐츠 모더레이션, 환불 결정, 주관적 품질 평가, 엣지 케이스—AI가 확신을 갖고 결정할 수 없는 영역이다. Erik Anderson이 개발한 HumanRail은 이 문제를 MCP(Model Context Protocol) 기반으로 해결한다.
개념은 단순하다. AI 에이전트가 판단이 불확실한 태스크에 부딪히면 create_task()로 인간 작업자에게 에스컬레이션하고, wait_for_task()로 검증된 결과를 기다린다. 6단계 검증 파이프라인(스키마 검증, 중복 확인, 이상 탐지, 부정 스코어링)을 통과한 결과만 에이전트에게 돌아온다. 개발자가 직접 human-in-the-loop 인프라를 구축할 필요 없이, Claude 설정 파일에 몇 줄만 추가하면 된다.
이 아이디어의 핵심은 에스컬레이션 자체를 설계하는 것이다. AI가 스스로 "모른다"고 말하고 인간에게 넘기는 구조를 에이전트 아키텍처에 명시적으로 포함시키는 것—이게 빠진 에이전트는 틀린 결정을 자신있게 내린다.
실전 도구: 터미널에서 에이전트 팀을 운영한다
이론이 정립되면 도구 선택이 남는다. Dev-Crew는 이 문제를 CLI 레벨에서 접근한다. 24개 전문가 에이전트(코드 리뷰어, 버그 픽서, 보안 감사, 테스트 생성, DB 아키텍트, DevOps 가이드 등)를 터미널에서 바로 호출할 수 있는 구조다.
dev-crew interactive 모드에서 review @src/app.ts 또는 is there any security issue in src/api?처럼 자연어로 입력하면, 스택을 자동 감지하고 관련 파일 최대 15개, 80K 문자 이내로 컨텍스트를 압축해 프롬프트 토큰을 40~70% 절감한다. Claude Code, OpenAI, Copilot, Ollama 등 멀티 프로바이더를 지원하며, AI가 설치되지 않은 환경에서는 시뮬레이션 모드로 시연도 가능하다.
눈여겨볼 점은 이 도구 자체가 앞서 언급한 God Agent 안티패턴의 반면교사를 실천한다는 것이다. 하나의 만능 코딩 에이전트 대신 24개 좁은 스코프의 전문가 에이전트를 두고, 컨텍스트 압축으로 토큰 파산을 예방한다.
팀 리드가 지금 당장 해야 할 것
세 소스가 수렴하는 지점을 정리하면 이렇다. 실패 패턴은 반복된다. God Agent, Happy Path 함정, Context 파산, 에러 복구 부재, 인간 판단 공백—이 다섯 가지는 서로 다른 팀이 서로 다른 에이전트를 만들어도 같은 방식으로 나타난다. 아키텍처 문제이기 때문이다.
내가 팀에 권하는 에이전트 배포 전 체크리스트는 세 가지다. 첫째, 툴 수를 세어라. 에이전트당 툴이 7개를 넘으면 분해를 검토한다. 둘째, 서킷 브레이커와 폴백을 설계에 포함시켜라. 외부 API 호출이 하나라도 있으면 실패 경로가 반드시 필요하다. 셋째, 에스컬레이션 조건을 명시하라. AI가 자신없을 때 무엇을 해야 하는지 시스템 프롬프트에 적어두지 않으면, 에이전트는 자신있게 틀린 결정을 내린다.
에이전트 생존율을 높이는 것은 AI의 능력이 아니라 설계 규율이다
AI 에이전트의 프로덕션 실패율이 높은 건 LLM이 부족해서가 아니다. 우리가 에이전트를 소프트웨어가 아니라 마법처럼 취급하기 때문이다. 재시도, 서킷 브레이커, 메모리 관리, 에스컬레이션—이것들은 분산 시스템에서 10년째 써온 패턴이다. 에이전트에도 똑같이 적용된다.
앞으로 에이전트는 더 많은 자율성을 갖게 될 것이고, 실패의 파급 범위도 커질 것이다. 지금 이 패턴들을 팀의 설계 표준으로 굳히지 않으면, 더 강력한 에이전트가 더 빠르게 더 큰 문제를 일으킬 뿐이다. 도구가 좋아질수록 설계 규율이 더 중요해진다.