AI 에이전트가 프로덕션 환경에서 실패하는 이유: 신뢰성 수학

대부분의 프로덕션 에이전트가 실패하는 이유는 모델이 멍청해서가 아닙니다. 대부분은 맞지만 완벽하지 않은 단계들이 사슬처럼 이어지면서, 결과적으로 대부분 틀린 결과로 곱해지기 때문이며, 고객이 알아차리기 전까지는 아무도 이를 인지하지 못합니다. 신뢰할 수 있는 에이전트를 원한다면, 가장 먼저 고쳐야 할 것은 프롬프트(Prompt)가 아닙니다. 오류가 어떻게 누적되는지에 대한 산술(Arithmetic)입니다.

저는 B2B 고객을 위한 AI 에이전트를 구축하는 팀을 운영하고 있습니다. 저희는 충분히 많은 에이전트를 출시해 보았기에 명확한 의견을 가지고 있습니다. 에이전트가 실제 트래픽과 접촉했을 때 살아남을지를 예측하는 가장 큰 단일 지표는, 신뢰성을 모델의 속성(Model property)이 아닌 시스템의 속성(System property)으로 다루었는지 여부입니다.

당신을 두렵게 만들어야 할 숫자

여기에 수학적 계산이 있습니다. 이는 예시적이지만 그 형태는 실재합니다. 에이전트 워크플로(Workflow)의 각 단계가 95% 신뢰할 수 있다고 가정해 봅시다. 매우 좋아 보입니다. 이제 10개의 단계를 연결해 보겠습니다:

0.95 ^ 10 = 0.599

개별 단계가 20번 중 19번 작동하는 워크플로는 엔드 투 엔드(End-to-end)로 성공할 확률이 약 60%에 불과합니다. 단계별 신뢰도를 90%로 낮추면 10단계 작업의 성공률은 35%로 떨어집니다. 이것이 바로 세 개의 해피 패스(Happy-path) 단계를 완벽하게 수행하는 데모가 실제 12단계의 작업을 맡기는 순간 무너지는 이유입니다. 에이전트 실패에 관한 업계 보고서들은 동일한 결론에 도달합니다. 신뢰성을 실제로 죽이는 것은 실패 모드(Failure modes)의 다양성이 아니라, 바로 오류 전파(Error propagation)라는 점입니다. 널리 인용되는 수치 중 하나는 에이전트 이니셔티브(Initiatives) 8개 중 1개 미만이 안정적인 프로덕션 단계에 도달한다는 것입니다.

해결책은 더 똑똑한 모델이 아닙니다. 단계당 97%의 신뢰도를 가진 모델이라도 체인이 충분히 길어지면 결국 무너집니다. 해결책은 (a) 각 단계를 검증 가능하게 만들고, (b) 체인을 단축하며, (c) 오류가 발생한 즉시 그 단계에서 포착하는 것, 즉 세 단계 뒤에서가 아니라 발생한 지점에서 잡는 것입니다.

침묵하는 실패가 진짜 적이다

크래시(Crash)는 오히려 선물입니다. 스택 트레이스(Stack trace), 알림, 그리고 살펴볼 곳이 생기기 때문입니다. 정말 고통스러운 실패는 조용한 실패들입니다:

에이전트가 약간 잘못된 파라미터(parameter)로 도구(tool)를 호출하고, 도구가 _무언가_를 반환하면 에이전트는 이를 성공으로 간주합니다.
검색(retrieval) 단계에서 잘못된 문서를 가져오고, 모델은 그 문서에 대해 확신을 가지고 추론(reasoning)합니다.
모델이 진실 대신 당신이 듣고 싶어 하는 말을 해줍니다.
초기의 오독(misread)이 이후의 모든 결정으로 전파되며, 각 결정은 국소적으로는 타당해 보입니다.

이 중 어느 것도 예외(throw)를 발생시키지 않습니다. 에이전트는 작업을 마치고 깨끗해 보이는 답변을 반환하지만, 결과는 틀렸습니다. Microsoft의 레드팀 분류 체계(red-team taxonomy)와 대부분의 프로덕션 사후 분석(post-mortems)에서 조용히 전파되는 오류를 목록 최상단에 두는 이유는, 바로 당신이 찾아 나서기 전까지는 보이지 않기 때문입니다.

방어책은 경계에서의 검증(verification)입니다. 도구 호출(tool call) 이후에는 모델이 이를 바탕으로 작업을 이어가게 하기 전에, 반환된 값의 형태(shape)와 타당성(plausibility)을 확인하십시오. 검색 이후에는 해당 청크(chunk)가 실제로 당신이 질문한 엔티티(entity)를 포함하고 있는지 확인하십시오. 이러한 체크는 지루합니다. 하지만 이는 60%의 워크플로(workflow)와 95%의 워크플로를 가르는 차이입니다.

모든 에이전트 구축 시 우리가 수행하는 세 가지 작업

1. 체인(chain)을 끊으십시오. 가장 저렴하게 신뢰성을 확보하는 방법은 단계를 줄이는 것입니다. 우리는 끊임없이 질문합니다: 두 번의 도구 호출을 하나로 합칠 수 있는가? 결정론적 함수(deterministic function)가 추론 단계(reasoning step)를 대체할 수 있는가? 삭제하는 모든 단계는 실패 방정식에서 제거되는 승수(multiplier)입니다. 우리는 내부 워크플로를 에이전트 "부서(departments)"로 운영하며 인수인계(handoffs)가 깨지는 것을 지켜본 후, 이 교훈의 더 광범위한 버전을 작성했습니다: 에이전트는 쉬운 부분이고, 오케스트레이션(orchestration)이 어려운 부분입니다.

2. 모든 단계가 스스로의 성공을 단언(assert)하게 하십시오. 레코드를 생성하는 도구는 생성된 레코드의 ID를 반환해야 하며, 우리는 그것이 존재하는지 확인해야 합니다. 송장을 파싱(parsed)했다고 주장하는 단계는 우리가 범위 검사(range-check)를 할 수 있는 구조화된 필드(structured fields)를 넘겨주어야 합니다. 만약 어떤 단계가 제대로 작동했음을 증명할 수 없다면, 그것은 작동하지 않은 것입니다.

3. 중대한 지점에 인간을 배치하십시오. 모든 단계가 아니라, 되돌릴 수 없는 단계에 배치해야 합니다. 돈을 송금하거나, 고객에게 이메일을 보내거나, 데이터를 삭제하거나, 프로덕션 (prod) 환경에 반영하는 작업 등이 이에 해당합니다. 에이전트가 모든 준비와 추론 (reasoning)을 수행할 수 있지만, 되돌리는 데 비용이 많이 드는 작업은 사람이 승인해야 합니다. 이것은 야망의 부족이 아닙니다. 우리가 메인 (main) 브랜치로 자동 병합 (auto-merge)을 하지 않는 것과 같은 이유입니다.

검증 격차 (verification gap)는 코드에도 적용됩니다

이 논의 전체는 소프트웨어 측면에서도 유사한 양상을 보입니다. AI 도구는 팀이 훨씬 더 많은 코드를 작성할 수 있게 해주지만, 그 코드를 검증 (verifying) 하는 비용을 낮추는 데는 아무런 기여를 하지 못했습니다. 우리는 이 비대칭성을 별도로 조사했습니다. AI가 작성한 버그를 잡아내는 QA (Quality Assurance) 계층은 에이전트의 실패를 잡아내는 검증 계층과 동일한 종류의 투자이기 때문입니다: AI가 4배 더 많은 코드를 작성합니다, 4배의 버그를 막아주는 QA 계층은 여기 있습니다. 원리는 같지만 적용되는 영역이 다를 뿐입니다. 생성 (Generation) 비용은 저렴해졌지만, 검증 (Verification) 비용은 저렴해지지 않았습니다.

핵심 요약

단계별 신뢰도는 곱연산됩니다. 단계당 95%의 신뢰도를 가진 10단계 과정은 엔드 투 엔드 (end-to-end)로 약 60%이지, 95%가 아닙니다.
조용히 전파되는 실패 (silent, propagating failures)는 아무런 경고도 주지 않기 때문에 시스템 충돌 (crash)보다 더 치명적입니다.
체인을 단축하고, 각 단계가 스스로의 성공을 검증하게 하며, 되돌릴 수 없는 작업은 인간의 승인을 거치도록 제한하십시오.
더 나은 모델은 미미한 차이에서 도움을 줄 뿐입니다. 신뢰도는 당신이 설계해야 하는 시스템 속성 (system property)입니다.

FAQ

프런티어 모델 (frontier model)을 사용하면 에이전트가 신뢰할 수 있게 되나요?
단계별 신뢰도를 높여주어 도움이 되긴 하지만, 복리 계산법 (compounding math)은 여전히 적용됩니다. 97% 신뢰도를 가진 단계들이 충분히 길게 연결되어 있다면, 엔드 투 엔드 (end-to-end)로는 여전히 신뢰할 수 없습니다. 이 지점에서는 모델 선택보다 아키텍처 (architecture)가 더 중요합니다.

어디에 검증을 가장 먼저 추가해야 하나요?
도구 호출 (tool calls) 이후와 검색 (retrievals) 이후입니다. 이 두 경계는 가장 많은 조용한 오류가 유입되는 지점이며, 확인하는 데 비용이 가장 적게 듭니다.

인간 참여 (human-in-the-loop) 방식은 에이전트의 성능이 부족하다는 신호인가요?
아니요. 그것은 당신이 어떤 작업이 되돌리는 데 비용이 많이 드는지 이해하고 있다는 신호입니다. 그런 작업들은 제한하고, 나머지는 자동화하십시오.

만약 당신이 에이전트 (agents)를 구축하면서 동일한 복합적 실패 (compounding-failure) 문제로 고군분투하고 있다면, 저는 진심으로 의견을 나누고 싶습니다. 저희는 그 과정에서 얻은 흉터(scar tissue, 시행착오의 경험)를 가지고 있으며, 이를 기꺼이 공유할 용의가 있습니다. 저희는 Shanti Infosoft에서 만나보실 수 있습니다.