모든 AI 에이전트 데모는 비슷하게 보입니다. 깨끗한 데이터, 스크립트된 작업, 그리고 에이전트가 답변하도록 설계된 질문을 정확히 던지는 협력적인 사용자. 비행기표를 예약하고, 이메일을 초안 작성하며, 티켓을 닫고, 방에 있는 모든 사람이 고개를 끄덕입니다.

하지만 실제 운영 환경(production)으로 넘어가면 무언가 달라집니다. 데모에서는 매우 뛰어나 보였던 동일한 에이전트가 지저분한 입력값 앞에서 주저하기 시작하거나, 자신감 있게 잘못된 결정을 내리거나, 자동화해야 할 워크플로우의 절반에 걸쳐 조용히 '사람에게 확인해 주세요'로 돌아가는 현상이 발생합니다.

이는 단순한 우연이 아니며, 실제로 모델 자체의 문제도 아닙니다. 이것은 프로세스(process)의 문제입니다. 그리고 그 문제는 무시하기 어려울 정도의 규모로 나타나고 있습니다. 올해 연구들은 이 점에 대해 상당히 직설적입니다. 여러 독립적인 연구들이 AI 에이전트 파일럿 프로젝트 중 약 88%가 실제 운영 단계에 도달하지 못한다는 데 수렴하고 있으며, S&P Global Market Intelligence와 McKinsey 데이터에 따르면 실제로 무언가를 출시한 기업들 사이에서도 단지 약 31%만이 운영 환경에서 에이전트를 가동하고 있습니다. Forrester는 실제로 가동되었지만 성능이 기대에 미치지 못한 에이전트 배포의 근본 원인을 분석하며, 실패의 대부분은 모델 자체가 약해서가 아니라 불분명한 성공 기준이나 충분하지 않은 도구 또는 데이터 접근성 때문이라고 지적합니다.

만약 올해 AI 에이전트를 구축했거나 구매했다면, 더 이상 확장하기 전에 이 격차를 이해할 가치가 있습니다.
GoodWorkLabs에서 저희가 가장 자주 도움을 드리는 부분은 AI/ML 엔지니어링 팀 관련 영역입니다. 이는 더 화려한 에이전트를 구축하기 위해서라기보다는, 완벽하게 작동하는 에이전트가 실제 시스템, 실제 데이터, 그리고 실제 엣지 케이스(edge cases)를 만나는 순간 왜 계속 주춤거리는지를 파악하기 위함입니다. 이러한 패턴들은 고객사들 사이에서 너무 자주 반복되어 명확하게 정리할 가치가 있습니다.

AI 에이전트 데모가 속임수처럼 쉬운 이유

데모는 설계상 통제된 환경입니다. 입력값은 깔끔하고, 시나리오는 짜여 있으며, 에이전트의 알려진 강점은 전면에 배치되는 반면 실패 모드 (failure modes)는 프레임 밖에 머뭅니다. 이것은 부정직한 것이 아니라, AI 에이전트든 CRM이든 모든 제품이 시연되는 방식일 뿐입니다.

문제는 실제 비즈니스 프로세스는 통제된 환경에서 실행되지 않는다는 점입니다. 프로세스는 서로 대화하도록 설계된 적이 없는 시스템들을 가로질러 실행되며, 데이터는 절반 정도의 시간 동안 불완전하고, 에이전트 설계자가 전혀 예상하지 못한 질문을 던지는 인간이 루프 안에 (human in the loop) 존재합니다. 데모는 에이전트가 작업을 수행할 수 있는지를 테스트합니다. 프로덕션 (Production)은 주변의 모든 것이 비협조적일 때 — 즉, 대부분의 시간 동안 — 에이전트가 작업을 수행할 수 있는지를 테스트합니다.

에이전트가 실제 워크플로우를 만날 때 실제로 무너지는 것들

상태 (State)와 컨텍스트 (context)는 단계 사이에 사라지지 않습니다. 데모는 보통 하나의 깔끔한 상호작용을 보여줍니다. 하지만 실제 프로세스, 예를 들어 고객 환불 처리와 같은 작업은 CRM, 결제 시스템, 재고 확인, 그리고 지난 분기에 변경된 컴플라이언스 규칙 (compliance rule)에 걸쳐 있습니다. 에이전트는 이 모든 과정에서 컨텍스트를 정확하게 유지해야 하며, 작은 컨텍스트 손실은 몇 단계 뒤의 잘못된 결정으로 누적됩니다.

예외 상황은 예외적인 사례 (edge case)가 아니라 대다수의 사례입니다. 데모에서 예외 상황은 구조적으로 드물게 발생합니다. 하지만 프로덕션에서는 "고객 계정이 플래그 처리됨", "송장 번호가 일치하지 않음", 또는 "API 타임아웃 발생"과 같은 상황이 하루에도 여러 번 발생하는 워크플로우 그 자체입니다. 예측 불가능한 입력값에 더해 비결정론적 출력 (Non-deterministic output)이 발생하는 지점이 대부분의 에이전트가 눈에 띄게 어려움을 겪는 부분입니다. 실제로 현재 기업 리더의 70%가 비결정론적 출력을 프로덕션 준비의 가장 큰 장벽으로 꼽고 있습니다.

기록 시스템 (Systems of record)은 접근 권한을 쉽게 허용하지 않습니다. 에이전트는 비즈니스를 운영하는 ERP, 티켓팅 (ticketing), 빌링 (billing) 시스템에 대한 실제 읽기/쓰기 (read/write) 권한이 필요합니다. 하지만 이러한 접근 권한은 대개 AI와는 전혀 무관한 보안 검토, 감사 요구 사항, IT 승인 주기와 함께 수반됩니다. 이는 에이전트 프로젝트가 정체되는 가장 자주 언급되면서도, 가장 매력적이지 않은 이유 중 하나입니다.

책임 소재는 추적 가능해야 합니다. 에이전트가 고객이나 원장 (ledger)에 영향을 미치는 결정을 내릴 때, 결국 누군가는 "왜 그렇게 했는가?"라고 묻게 됩니다. 결정을 설명하는 감사 추적 (audit trail)이 없다면, 에이전트가 평균적으로 얼마나 정확했는지와 상관없이 중요한 업무를 맡길 수 없습니다.

비용과 지연 시간 (latency)은 대규모 운영 시 다르게 작동합니다. 작업당 모델을 3~4회 호출하는 에이전트는 10개의 요청을 처리하는 데모 단계에서는 괜찮습니다. 하지만 하루에 만 건의 요청이 발생하는 상황에서는 동일한 아키텍처가 너무 느려지거나 비용이 많이 들어 경제성이 떨어질 수 있습니다.

진정한 병목 현상은 모델이 아니라 모델을 둘러싼 프로세스입니다

이 부분은 많은 엔지니어링 팀에게 불편한 사실입니다. 에이전트 배포의 실패 패턴은 근본적인 모델이 아니라 일관되게 프로세스로 거슬러 올라갑니다. 성과가 저조한 에이전트 배포에 대한 Forrester의 분석에 따르면, 실패 원인은 대략 불분명한 성공 기준 41%, 불충분한 도구 또는 데이터 접근 권한 33%, 시간이 지남에 따른 평가 범위의 드리프트 (drift) 26%로 나뉩니다. 이 중 그 어느 것도 더 나은 모델이 해결해 줄 수 있는 문제가 아닙니다.

다르게 표현하자면, 팀들은 주변 프로세스가 신뢰할 수 있는 데이터, 명확한 에스컬레이션 경로 (escalation paths), 그리고 실수가 누적되기 전에 포착할 수 있는 방법으로 실제로 지원할 수 있는 수준이 아니라, 에이전트가 가졌으면 하는 자율성 수준에 맞춰 설계하는 경향이 있습니다. 프로덕션 단계에 지속적으로 도달하는 파일럿 프로젝트들은 사전에 다음과 같은 동일한 원칙을 공유합니다. 즉, 구체적이고 좁은 유스케이스 (use case), 구축 시작 전 명확하게 정의된 성공 지표, 그리고 잘못된 결정이 큰 비용을 초래하는 정확한 지점에서의 인간 체크포인트 (human checkpoint)입니다.

에이전트를 확장하기 전 실무 체크리스트

만약 에이전트가 파일럿 단계를 넘어갈 준비가 되었는지 결정하려 한다면, 성공하는 에이전트와 그렇지 못한 에이전트를 가르는 몇 가지 질문이 있습니다.

• "정답"을 객관적으로 정의할 수 있을 만큼 작업 범위가 좁은가? 만약 두 명의 합리적인 사람이 에이전트의 출력이 맞았는지에 대해 의견이 갈린다면, 그 에이전트는 아직 자율적인 실행(autonomous execution)을 수행할 준비가 되지 않은 것입니다.
• 에이전트가 필요한 시스템에 대해 실제로 테스트된 접근 권한을 가지고 있는가? 모의 API (mocked API)가 아니라, 실제의 무질서함(messiness)을 그대로 가진 실제 운영 데이터 (production data)에 접근할 수 있어야 합니다.
• 가장 비용이 많이 발생하는 결정 지점에 인간 체크포인트 (human checkpoint)가 있는가? 그래야 실수가 고객이나 원장 (ledger)에 도달하기 전에 포착될 수 있습니다.
• 사후에 누군가 질문해야 하는 상황이 발생했을 때, 에이전트가 왜 그런 행동을 했는지 확인할 방법이 있는가?
• 빌드를 시작하기 전에 성공 지표 (success metrics)를 정의했는가? 사전에 정량화된 성공 기준을 정의한 프로젝트의 성공률은 약 54%인 반면, 이 단계를 건너뛴 프로젝트의 성공률은 약 12%에 불과합니다. 이 격차는 추가로 일주일의 계획 시간을 투자할 가치가 충분할 만큼 큽니다.

이 중 어느 것도 생소한 공학적 기술이 아닙니다. 이는 출시되는 소프트웨어와 프로토타입에 머무는 소프트웨어를 항상 구분해 온 것과 동일한 규율입니다. 다만 AI 에이전트의 경우, 데모가 어려운 부분을 이미 해결된 것처럼 보이게 만들기 때문에 이 규율이 더 자주 무시될 뿐입니다.

이것이 실제로 발생하는 상황

들어오는 티켓 (tickets)을 분류하고 해결하기 위해 에이전트를 파일럿 운영 중인 중견 기업의 고객 지원 팀을 상상해 보십시오. 데모에서는 깔끔하고 잘 구성된 티켓들을 완벽하게 처리합니다. 하지만 실제 운영 환경에서는 티켓의 3분의 1이 에이전트가 볼 수 있는 시스템에 존재하지 않는 주문 번호를 참조합니다. 그 데이터가 아무도 이전하지 않은 레거시 도구 (legacy tool)에 들어있기 때문입니다. 에이전트는 정보가 누락되었다는 사실을 알지 못하며, 그저 자신감 있게 틀린 답을 내놓을 뿐입니다.

해결책은 더 나은 모델을 사용하는 것이 아닙니다. 에이전트의 초기 범위를 데이터 접근 권한이 실제로 완전한 티켓 유형으로 좁히고, 답변을 강요하는 대신 명시적인 "정보 부족 시 에스컬레이션 (insufficient information escalate)" 경로를 추가하며, 해당 좁은 범위의 버전이 몇 주 동안 문제없이 실행된 후에만 범위를 확장하는 것입니다. 이것은 단 한 줄의 추가적인 프롬프트 엔지니어링 (prompt engineering)을 수행하기 전에 내려지는 프로세스 설계 (process design) 결정입니다.

GoodWorkLabs에서의 접근 방식

위의 체크리스트 중 어느 것도 이론적인 것이 아닙니다. 이는 파일럿 단계에서는 작동했지만 배포 전 단계에서 정체된 에이전트를 가진 고객이 우리를 찾아왔을 때, 우리 팀이 AI/ML 프로젝트의 범위를 설정하는 대략적인 방식입니다. 우리가 일관되게 고수하는 몇 가지 원칙은 다음과 같습니다.

우리는 고객이 더 넓은 범위를 원하더라도, 먼저 좁은 범위의 조각(narrow first slice)을 추진합니다. 초기에는 더 어려운 대화가 될 수 있지만, 이는 몇 주 안에 출시되는 에이전트와 6개월 후에도 여전히 "거의 준비된" 상태인 에이전트 사이의 차이를 만듭니다.

• 우리는 시스템 기록(systems-of-record)에 대한 접근을 사후 고려 사항이 아닌 별도의 워크스트림 (workstream)으로 취급합니다. 에이전트 로직이 실제로 존재하지 않는 데이터에 대한 가설 위에 구축되기 전에, 에이전트가 실제로 읽고 써야 하는 것이 무엇인지, 그리고 IT/보안 검토가 어디에서 이루어져야 하는지를 먼저 매핑합니다.

• 우리는 해피 패스 (happy path)를 구축하기 전에 에스컬레이션 경로를 구축합니다.