AI 에이전트의 91%가 프로덕션에서 실패하는 이유 (그리고 상위 9%는 무엇이 다른가)

지금 모두가 AI 에이전트(AI agents)를 만들고 있습니다. 인간의 개입(human in the loop) 없이 추론하고, 계획하며, 행동하는 자율 시스템 말입니다. 코드를 작성하고, 워크플로우를 관리하며, 데이터를 분석하고, 의사결정을 내리는 에이전트들입니다. 데모는 놀랍습니다. 열기는 귀가 먹먹할 정도입니다. 하지만 아무도 이야기하지 않는 사실이 있습니다. 구축된 AI 에이전트의 91%는 프로덕션(production) 환경에 성공적으로 진입하지 못한다는 것입니다. 데모에서는 작동하지만, 실제 세상에서는 실패합니다. 그리고 그 이유는 거의 모델 때문이 아닙니다.

진짜 문제는 지능이 아니라 인프라(Infrastructure)입니다.

에이전틱 AI(agentic AI)를 구축하는 대부분의 팀은 에너지의 90%를 에이전트 자체에 집중합니다. 프롬프트(prompts), 추론 체인(reasoning chain), 도구 선택(tool selection), 에이전트 아키텍처(agent architecture) 같은 것들 말이죠. 그러고 나서 제품을 출시한 뒤, 왜 2주 만에 무너지는지 의아해합니다. 문제는 에이전트 주변의 모든 것입니다. 컨퍼런스에서 아무도 이야기하고 싶어 하지 않는, 지루하고 매력적이지 않은 시스템 엔지니어링(systems engineering) 말입니다. 좋은 데모를 만들어주지는 않지만, 에이전트가 30일, 90일, 365일째에도 실제로 작동할지를 결정하는 요소들입니다. 제가 말하는 것은 MLOps입니다. 더 넓게는 AI 시스템을 프로덕션에서 신뢰할 수 있게 만드는 규율(discipline)을 의미합니다. 그리고 여기서 중요한 점은, 에이전틱 AI가 당신이 마주할 수 있는 가장 어려운 MLOps 문제라는 것입니다. 왜 그런지 설명하겠습니다.

전통적인 ML vs 에이전틱 AI: 시스템 엔지니어링의 격차

전통적인 ML(Machine Learning) 시스템은 비교적 단순합니다. 입력이 들어가고, 모델이 예측을 수행하며, 출력이 나옵니다. 예측 품질을 모니터링하고, 드리프트(drift)가 발생하면 재학습시키면 끝입니다. 에이전틱 시스템은 근본적으로 다릅니다. 하나의 모델이 하나의 예측을 하는 것이 아닙니다. 여러 모델이 루프(loop) 안에서 서로 연결되어 있습니다. 에이전트는 추론하고, 계획하고, 행동하고, 결과를 관찰하고, 다시 추론합니다. 각 단계는 이전 단계에 의존합니다. 오류는 복리로 쌓입니다. 이것이 실무에서 의미하는 바는 다음과 같습니다.

실패 모드(Failure modes)가 배가됩니다. 전통적인 ML 시스템에서의 잘못된 예측은 단일한 잘못된 출력일 뿐입니다. 하지만 에이전트의 잘못된 행동은 연쇄 반응(cascade)을 일으킬 수 있습니다. 잘못된 단계를 밟고, 잘못된 결과를 관찰하며, 잘못된 문맥(context)으로부터 추론하고, 또 다른 잘못된 단계를 밟게 됩니다.

당신이 알아차릴 때쯤이면, 에이전트는 이미 몇 시간 동안 자신 있게 실수를 저지르고 난 후일 것입니다. 모니터링(Monitoring)은 더 어려워집니다. 전통적인 모델의 경우, 예측 분포(prediction distributions)와 정확도(accuracy)를 모니터링합니다. 하지만 에이전트의 경우, 행동 품질(action quality), 루프 탐지(loop detection), 작업당 비용(cost per task), 도구 실패율(tool failure rates), 그리고 에이전트가 올바른 목표를 추구하고 있는지 여부를 모니터링해야 합니다. 버전 관리(Versioning)는 폭발적으로 늘어납니다. 전통적인 모델은 하나의 가중치(weights) 세트를 가집니다. 반면 에이전트는 여러 개의 모델 버전, 프롬프트 버전, 도구 설정(tool configurations), 그리고 오케스트레이션 로직(orchestration logic)을 가집니다. 이 모든 것들을 함께 버전 관리하고 추적해야 합니다. 드리프트(Drift)는 예측 불가능해집니다. 전통적인 데이터 드리프트(data drift)는 점진적입니다. 즉, 입력 분포(input distributions)가 천천히 변화합니다. 에이전트 드리프트(agent drift)는 갑작스러울 수 있습니다. 도구 API가 변경되거나, 새로운 엣지 케이스(edge case)가 나타나거나, 에이전트가 작동하는 환경이 진화할 수 있기 때문입니다. 이것이 바로 에이전트형 AI(agentic AI)에 더 적은 것이 아니라 더 많은 MLOps 규율이 필요한 이유입니다. 그리고 왜 대부분의 팀이 자신들이 만들고 있는 것을 지탱할 수 없는 기반 위에서 구축하고 있는지를 보여줍니다.

프로덕션에서 에이전트를 죽게 만드는 5가지 실패 모드(Failure Modes)
저는 저 자신의 실패를 포함하여 프로덕션 ML 실패 사례들을 연구해 왔습니다. 동일한 다섯 가지 패턴이 반복해서 나타납니다. 이것은 모델의 문제가 아닙니다. 시스템의 문제입니다.

1. 모니터링 부재 — 눈을 가리고 비행하기
   이것이 가장 큰 문제입니다. 대부분의 에이전트 데모에는 프로덕션 모니터링이 전혀 없습니다. 에이전트는 실행되고, 팀은 사용자가 불만을 제기하거나 비즈니스 지표가 하락할 때서야 무언가 잘못되었다는 것을 알게 됩니다. 그때는 이미 너무 늦습니다. 프로덕션 에이전트에는 다음과 같은 항목에 대한 실시간 모니터링이 필요합니다: 행동 성공률(action success rates), 오류 패턴(error patterns), 작업당 비용(cost per task), 지연 시간(latency), 그리고 무엇보다도 에이전트가 실제로 의도한 결과(intended outcome)를 달성하고 있는지 여부입니다. 볼 수 없다면, 고칠 수 없습니다.

2. 버전 관리 부재 — 일회성 결과
   에이전트가 한 번 작동했습니다. 아주 멋지게 작동했죠. 하지만 모델 버전, 프롬프트 버전, 도구 설정, 오케스트레이션 로직과 같은 정확한 구성(configuration)을 아무도 기록하지 않았습니다. 2주 후, 무언가가 변했습니다. 에이전트의 성능이 저하됩니다. 그리고 팀은 마지막으로 확인된 정상 상태(last known good state)를 재현할 수 없기 때문에 무엇이 망가졌는지 전혀 알 수 없습니다.

모든 것을 버전 관리(Versioning)하세요. 코드, 데이터, 모델 가중치(Model weights), 프롬프트(Prompts), 설정(Configuration), 환경(Environment)까지 전부 다요. 재현할 수 없다면 디버깅할 수 없습니다.

3. 가드레일(Guardrails) 부재 — 경계 없는 동작
   가드레일이 없는 에이전트는 피해를 입히기만을 기다리는 에이전트와 같습니다. 저는 다음과 같은 에이전트들을 목격했습니다:

• 속도 제한(Rate limits)에 걸려 서비스를 다운시킬 때까지 실패하는 도구(Tool)를 계속해서 재시도하는 경우.
• 토큰 예산(Token budgets)을 모두 소진할 정도로 점점 더 장황한 응답을 생성하는 경우.
• 중단하고 에스컬레이션(Escalation)해야 할 시점을 지나 목표를 계속 추구하는 경우.
  가드레일은 선택 사항이 아닙니다. 서킷 브레이커(Circuit breakers), 비용 제한(Cost limits), 재시도 예산(Retry budgets), 인간 참여(Human-in-the-loop) 체크포인트 — 이것들이 데모와 프로덕션 시스템을 구분 짓는 요소입니다.

4. 훈련-서빙 왜곡 (Training-Serving Skew) — 존재하지 않는 쌍둥이
   에이전트는 샌드박스(Sandbox)에서 테스트되었습니다. 하지만 프로덕션 환경은 다릅니다. 도구 지연 시간(Tool latencies)은 더 길고, 데이터 형식은 약간 다르며, 에러 메시지도 다르게 보입니다. 테스트에서 완벽하게 작동했던 에이전트가 프로덕션에서 예측 불가능하게 행동하는 이유는 실제 환경을 대상으로 테스트되지 않았기 때문입니다. 이는 전통적인 머신러닝 (ML) 모델을 망가뜨리는 것과 동일한 문제이지만, 에이전트에게는 훨씬 더 치명적입니다. 에이전트는 일련의 의사결정(Sequences of decisions)을 내리기 때문입니다. 각 단계에서의 작은 왜곡이 마지막에는 커다란 편차로 누적됩니다.

5. 롤백(Rollback) 불가 — 잘못된 버전에 갇힘
   프로덕션에서 에이전트의 성능이 저하되기 시작합니다. 팀은 무언가 잘못되었다는 것을 알지만, 이전 버전으로 빠르게 되돌릴 방법이 없습니다. 사용자들에게 영향을 미치는 동안 라이브 시스템을 디버깅하며 허우적거려야 합니다. 모든 프로덕션 에이전트에는 즉각적인 롤백 기능이 필요합니다. 단 한 번의 명령으로 마지막으로 확인된 정상 상태(Last known good version)로 돌아가야 합니다. 논쟁의 여지가 없습니다.

상위 9%가 다르게 하는 것
에이전트형 AI (Agentic AI)를 프로덕션에 성공적으로 출시하는 팀들이 더 똑똑한 것은 아닙니다. 더 나은 모델을 사용하는 것도 아니고, 더 뛰어난 프롬프트 엔지니어(Prompt engineers)인 것도 아닙니다. 그들은 단지 AI 시스템 엔지니어링을 '시스템 엔지니어링 (Systems engineering)'으로 취급할 뿐입니다. 그들은 인프라를 먼저 구축합니다. 모니터링(Monitoring), 버전 관리(Versioning), 가드레일(Guardrails), 롤백(Rollback) 말이죠. 에이전트가 인상적이기 전에, 먼저 신뢰할 수 있어야 합니다. 그들은 첫날부터 노트북(Notebook)이 아닌, 프로덕션과 유사한 환경에서 테스트합니다.

데모가 아니라, 실제 세상과 유사하게 보이고 느껴지는 환경에서 말입니다. 그들은 드리프트 탐지 (Drift detection)를 설정합니다. 그들은 세상이 변한다는 것을 알고 있으며, 그들의 에이전트가 이에 적응해야 한다는 점을 이해합니다. 그들은 새로운 버전을 프로덕션에 반영하기 전에 검증하는 자동 재학습 파이프라인 (Automated retraining pipelines)을 구축합니다. 그들은 중요한 것을 측정합니다. 단순히 "에이전트가 작동하는가?"가 아니라, "에이전트가 시간이 지나도 일관되게, 안전하게, 그리고 비용 효율적으로 작동하는가?"를 측정합니다.

실제 사례: 자가 치유형 ML 파이프라인 (Self-Healing ML Pipeline) 구축

최근 저는 한 통신사를 위해 고객 이탈 예측 시스템을 구축했습니다. 겉보기에는 어떤 고객이 떠날지 예측하는 단순한 이진 분류 (Binary classification) 문제처럼 보입니다. 하지만 저는 이를 자가 치유형 시스템으로 설계했습니다. 왜냐하면 그렇지 않으면, 유지 관리 팀이 평소보다 더 많은 고객을 잃고 있다는 사실을 알아차릴 때까지 모델이 소리 없이 성능이 저하될 것임을 알고 있었기 때문입니다. 그 구조는 다음과 같습니다:

자동 드리프트 탐지 (Automated drift detection). 매일 시스템은 유입되는 고객 데이터를 학습 기준점 (Training baseline)과 비교합니다. 만약 피처 분포 (Feature distributions)가 임계값을 넘어 이동하면 — 예를 들어, 회사가 새로운 요금제를 출시하여 고객 행동이 변하는 경우 — 시스템이 이를 알립니다.

자동 재학습 (Automated retraining). 드리프트가 감지되면 시스템은 최신 데이터로 모델을 자동으로 재학습합니다. 사람이 재학습을 결정하는 것이 아닙니다. 시스템이 필요성을 감지하고 파이프라인을 트리거합니다.

품질 게이트 (Quality gates). 새로운 모델은 단순히 재학습되었다고 해서 바로 라이브로 배포되지 않습니다. 새로운 모델은 F2-score, 재현율 (Recall), 그리고 거짓 양성률 (False positive rate) 측면에서 현재 프로덕션 모델을 능가해야 합니다. 만약 그렇지 못하면 기존 모델이 유지되며 팀에 알림이 전송됩니다.

즉각적인 롤백 (Instant rollback). 승인된 모델의 성능이 떨어지기 시작하면, 단 한 번의 명령으로 이전 버전으로 되돌릴 수 있습니다. 다운타임이 없으며, 압박감 속에서 디버깅할 필요도 없습니다.

완전한 관측 가능성 (Full observability). 모든 예측은 로그로 기록됩니다. 모든 재학습 실행은 추적됩니다. 모든 드리프트 보고서는 저장됩니다. 문제가 발생하면 디버깅을 위해 전체 이력을 확인할 수 있습니다.

이것은 에이전트형 AI (Agentic AI) 시스템에 필요한 것과 동일한 규율입니다. 규모는 다르지만, 원칙은 동일합니다.

체크리스트: 당신의 에이전트는 프로덕션 준비가 되었는가? 에이전트를 프로덕션 (Production) 환경에 배포하기 전에, 다음 질문들에 솔직하게 답해 보십시오:

[ ] 에이전트의 행동 품질 (Action Quality)을 실시간으로 모니터링할 수 있는가?
[ ] 과거의 실행 결과(코드 + 데이터 + 설정 + 환경)를 정확하게 재현할 수 있는가?
[ ] 에이전트가 경로를 벗어났을 때 이를 중단시킬 서킷 브레이커 (Circuit Breakers)가 있는가?
[ ] 에이전트가 프로덕션과 일치하는 환경에서 테스트되었는가?
[ ] 60초 이내에 이전 버전으로 롤백 (Rollback)할 수 있는가?
[ ] 환경이 변할 때 알림을 주는 드리프트 탐지 (Drift Detection) 기능이 있는가?
[ ] 품질이 낮은 버전이 라이브로 배포되는 것을 방지하는 자동화된 품질 게이트 (Quality Gates)가 있는가?
[ ] 기술적 지식이 없는 이해관계자에게 에이전트가 무엇을 왜 했는지 설명할 수 있는가?

만약 이 중 두 개 이상의 질문에