왜 대부분의 AI 에이전트는 프로덕션에서 실패하는가

Source: Dev.to

대부분의 AI 에이전트는 데모에서는 잘 작동합니다. 하지만 실제 운영에서는 문제가 발생합니다.

MIT의 2025 State of AI in Business 보고서(Fortune 요약)에 따르면 기업 AI 파일럿의 95 %가 측정 가능한 비즈니스 수익을 보여주지 못한다고 합니다. 같은 연구에서는 더 의미 있는 결과도 밝혀냈는데, 벤더의 도구를 구매해 만든 파일럿은 **약 67 %**의 성공률을 보이는 반면, 내부에서 직접 만든 파일럿은 대략 5개 중 1개 정도만 성공한다는 것입니다.

이 격차는 우리가 매주 목격하는 상황과 일치합니다. 팀이 다섯 개 사례 샘플에 대해서는 잘 작동하는 무언가를 구축합니다. 실제 볼륨이 들어오는 첫 주에 바로 무너집니다.

실패는 무작위가 아닙니다. 채용, 의료 백오피스, 법률 검토, 재무 조정, 공급망 등 다양한 분야에서 이러한 현상을 관찰한 결과, 두 가지 패턴이 거의 모든 실패를 설명합니다.

Reliability and governance

대부분의 프로토타입은 데모용으로 만들어집니다. 데모는 한 가지 질문을 합니다: 에이전트가 작업을 한 번 완료할 수 있는가?

프로덕션은 다른 질문을 합니다:

• 누군가 지켜보지 않을 때, 연속으로 천 번 작업을 약간 다른 입력으로 완료할 수 있는가?
• 문제가 발생했을 때, 누군가가 에이전트가 본 것, 결정한 것, 수행한 것을 재구성할 수 있는가?
• 인간이 결과적인 단계들을 사전에 승인할 수 있는가, 사후가 아니라?
• 감사자가 지난 분기에 우리가 실행한 내용을 물어볼 때, 문서 기록이 존재하는가?

대부분의 프로토타입은 이 질문들에 답하지 못합니다. 그렇게 만들지 않았기 때문입니다.

AI 에이전트는 비결정론적 결정을 내립니다. 단계별 감사 로그가 없으면 잘못된 실행을 디버깅할 수 없습니다. 되돌릴 수 없는 행동에 대한 명시적인 승인 게이트가 없으면, 에이전트가 실제 데이터에 처음으로 실행되는 순간이 파일을 읽는 것과 돈을 이체하는 것의 차이를 처음으로 알게 되는 순간이 됩니다. 접근 제어, 비밀 관리, 보존 정책이 없으면 실제 기업이 요구하는 기준을 충족하지 못합니다.

무언가 포기해야 할 상황에서는 신뢰성이 승리해야 합니다. “빠르고 깨진”을 의식적으로 선택하는 사람은 없지만, 모든 프로토타입에는 암묵적인 속도 기본값이 있습니다: 짧은 타임아웃, 재시도 없음, 검증 단계 없음. 이러한 기본값은 누군가 재설계하지 않는 한 프로덕션에 그대로 남습니다. 30초가 걸리더라도 정확한 실행은 5초가 걸리면서 10% 정도 틀리는 실행보다 항상 더 가치가 있습니다.

성공하는 팀은 신뢰성과 거버넌스를 아키텍처로 간주하며, 마지막에 끼워 넣는 기능이 아닙니다. 그들은 “에이전트”를 만드는 것이 아니라 모델을 활용하는 작은 운영 시스템을 구축하고 있습니다. 모델 자체는 쉬운 부분입니다.

표준, 맞춤형이 아닌

프로토타입을 배포하는 것이 그 어느 때보다 쉬워졌습니다. 창업자, 분석가, 채용 담당자—누구든지 주말에 Claude나 ChatGPT와 함께 “바이브‑코드”로 워크플로를 만들 수 있습니다. 이는 프로토타입 단계에서 실제 생산성 향상입니다.

그 워크플로가 회사가 무언가를 수행하는 방식이 되어야 할 순간, 맞춤형 버전이 문제가 됩니다.

• 팀에 다섯 명이 같은 작업을 해야 합니다. 각자 약간씩 다른 흐름을 갖게 됩니다.
• 한 사람의 버전은 단계를 건너뛰고, 다른 사람은 허가되지 않은 공급자를 추가하고, 또 다른 사람은 조용히 오래된 API를 사용합니다.
• 모두가 독립적으로 작업합니다. 그 어느 것도 프로세스가 아닙니다.

단일 진실의 원천이 없습니다. 흐름은 누군가의 채팅 기록, 문서, 혹은 GitHub gist에 있는 스크립트에 존재합니다. 관리자가 “우리는 이걸 어떻게 하나요?”라고 물으면, 약간씩 오래된 답변이 다섯 개 나옵니다.

업스트림 API나 정책이 변경되면, 그 변경을 다섯 곳에 모두 적용해야 합니다. 보통 두 곳에만 적용되고 나머지는 점점 달라집니다. 한 달 뒤면 팀 절반이 옛 버전을 사용하고 있다는 사실을 아무도 모릅니다.

수백 개의 약간씩 다른 워크플로 사본을 배포하고 이를 프로덕션이라고 부를 수 없습니다. 프로덕션은 하나의 정규 버전을 의미합니다—버전 관리되고, 공유되며, 관찰 가능하고, 한 곳에서 업데이트되는 버전. 수백 개의 채팅 세션에서 바이브‑코드된 흐름은 그와 정반대입니다.

무엇을 해야 할까

• 신뢰성을 v1 요구사항으로 간주하고, v2 정리 작업이 아니라 처음부터 감사 로그를 배포하세요. 액션을 만들기 전에 승인 게이트를 구축하세요. 에이전트가 실행할 자격 증명을 갖기 전에 파괴적 작업에 대한 가드레일을 정의하세요. 초기 비용은 몇 시간에 불과하지만, 나쁜 실행 후에 보완하는 데는 몇 달과 신뢰가 필요합니다.
• 속도와 신뢰성을 의식적으로 선택하세요. 일부 워크플로는 빠른 베스트‑에포트 에이전트가 유리하지만, 대부분의 엔터프라이즈 워크플로는 그렇지 않습니다. 작업이 재무 데이터, 고객 기록, 혹은 규제 대상이 되는 경우라면 기본적으로 신뢰성을 선택하고 지연 비용을 감수하세요.
• 워크플로 정의를 중앙화하세요. 각 자동화를 코드처럼 다루세요: 모든 사람이 볼 수 있는 시스템에 하나의 정식 버전과 버전 히스토리를 유지합니다. Vibe 코딩은 첫 번째 버전을 프로토타이핑할 때는 좋지만 운영 버전으로는 재앙입니다. 하나에서 다른 것으로 전환하는 것이 작업입니다.
• 거버넌스를 누군가의 업무로 만들고, 아무도 아닌 사람은 없게 하세요. 배포하는 에이전트에 대한 접근 제어, 감사, 예외 처리를 한 사람이 담당합니다. 이것은 매력적이지 않지만 필수적입니다.
• 프로덕션 기준에 대해 솔직해지세요. “데모에서는 작동했다”는 데모에 대한 사실일 뿐, 에이전트에 대한 사실이 아닙니다. 실제 볼륨과 실제 데이터로 작업을 실행하고, 실패 모드가 어떻게 나타나는지 관찰하고 수정하세요. 이 단계는 에이전트를 처음 만드는 시간보다 오래 걸리는 경우가 많습니다. 이는 정상입니다.

이것이 실제 의미하는 바

병목 현상은 모델이 아닙니다. 현재 모델들은 충분히 능력이 있습니다. 병목 현상은 감사 기록, 가드레일, 진실의 원천, 거버넌스, 운영 규율에 있습니다.

이는 좋은 소식입니다. 문제를 해결할 수 있음을 의미합니다. 이러한 계층에 투자하는 팀은 다음 벤치마크 모델을 쫓는 팀보다 훨씬 더 큰 가치를 창출합니다.

mark.

If you are building an AI workflow that runs unattended on real work, take reliability seriously before you take speed seriously. Standardize the process before you scale it.

The teams that do are the ones we see succeed.