지난 1년 동안 기업의 거의 40%가 AI 에이전트 파일럿 (pilot)을 실행했습니다. 하지만 그 파일럿 중 극히 일부만이 프로덕션 (production) 단계에 도달했습니다. 이 격차는 모델의 문제가 아닙니다. GPT급 및 Claude급 모델들은 관련된 추론 (reasoning)을 수행할 능력이 충분합니다. 격차는 아키텍처 (architectural)의 문제입니다.

실패 패턴

팀들은 계속해서 똑같은 실수를 반복하고 있습니다. 그들은 기존의 망가지고 파편화된 프로세스 — 세 개의 서로 다른 티켓팅 시스템과 두 번의 수동 인계가 수년간 임시방편으로 이어 붙여온 바로 그 프로세스 — 를 가져와서 그 위에 에이전트를 덧붙입니다.

에이전트는 파편화를 해결하지 못합니다. 그것은 파편화를 자동화 (automates the fragmentation) 할 뿐이며, 기존에 예외 상황 (edge cases)을 잡아내던 인간보다 더 빠르고 더 적은 감독 하에 수행합니다.

기존 프로세스 (망가짐)          기존 프로세스 + 에이전트 (여전히 망가짐)
────────────────────────         ──────────────────────────────────────
수동 분류 (Manual triage) → 3개 시스템        에이전트 분류 (Agent triage) → 3개 시스템
...

기저에 깔린 워크플로우 (workflow)에 명확한 입력값, 명확한 책임 소재, 그리고 명확한 성공 기준이 없다면, 이를 LLM으로 감싸는 것은 지능을 더하는 것이 아니라 이미 불안정한 시스템에 확률적인 행위자 (probabilistic actor)를 추가하는 것일 뿐입니다.

해결책: 자동화하기 전에 도메인을 재설계하라

에이전트를 프로덕션에 성공적으로 안착시키는 팀들은 최고의 프롬프트 (prompts)를 가진 팀들이 아닙니다. 그들은 IT Ops, Sales Ops, 1단계 지원 분류(tier-1 support triage)와 같이 엄격하게 관리되는 도메인 (tight, governed domain) 을 선택하고, 단 하나의 에이전트 노드 (agent node)를 작성하기 전에 프로세스의 경계를 재구축한 팀들입니다.

그것은 다음을 의미합니다:

• 암묵적인 집단 지식이 아닌 명시적인 상태 (Explicit state). 워크플로우의 모든 입력과 출력은 누군가의 기억 속에 있는 Slack 스레드가 아니라, 스키마 (schema)로 정의됩니다.
• 제한된 권한 (Bounded authority). 에이전트는 허용된 범위 내의 도구 세트와 시스템 세트만을 사용하며, 그 이상의 권한은 갖지 않습니다.
• 되돌릴 수 없는 작업 전의 체크포인트 (A checkpoint). 환불, 배포, 자격 증명 변경과 같은 작업은 반드시 인간의 승인 단계 (human gate)를 거쳐야 합니다.

이것이 바로 LangGraph나 CrewAI와 같은 프레임워크가 수행하는 역할입니다. 이들은 에이전트를 더 똑똑하게 만드는 것이 아니라, 프로세스의 경계를 코드로 강제합니다.

그래프로 본 모습

LangGraph에서 이러한 패턴을 프로덕션 환경에 맞게 최소한으로 구현하면, 되돌릴 수 없는 모든 작업에 대해 실행 경로에 직접 인간 참여 (human-in-the-loop, HITL) 노드를 배치합니다:

from langgraph.graph import StateGraph, END

def classify(state):
...

중요한 것은 코드가 아니라, 코드가 무엇을 _강제하는가_입니다. 조건부 엣지 (conditional edge)는 강력한 아키텍처 경계입니다. 라우팅 결정권이 모델에게 있지 않기 때문에, 그 어떤 프롬프트 엔지니어링 (prompt engineering)으로도 이를 우회할 수 없습니다.

실제로 중요한 지표

에이전트 파일럿을 평가할 때 "그럴듯해 보이는 출력을 생성했는가"로 측정하는 것을 멈추십시오. 대신 다음을 측정하기 시작하십시오:

지표	의미
작업 완료율 (Task completion rate)	에이전트가 단순히 그에 관한 텍스트를 생성하는 것을 넘어, 작업을 처음부터 끝까지 완수했는가
...

이 중 어떤 것도 더 화려한 모델을 요구하지 않습니다. 이 모든 것에는 이미 재설계한 프로세스 주변에 내구성이 있는 상태 (durable state), 제한된 도구 (bounded tools), 그리고 명시적인 체크포인트 (explicit checkpoint)라는 하네스 (harness)가 필요합니다.

결론

에이전트의 현실 점검은 "에이전트가 아직 작동하지 않는다"가 아닙니다. 에이전트는 당신이 부여한 프로세스의 형태를 그대로 물려받는다는 점입니다. 프로세스의 경계(process boundary)를 먼저 수정하십시오. 좁은 도메인 (tight domain), 명시적인 상태 (explicit state), 제한된 권한 (bounded authority), 그리고 되돌릴 수 없는 모든 작업에 대한 인간의 승인 단계 (human gate)를 구축하십시오. 그러면 에이전트가 프로덕션 (production)에 도달할 실질적인 기회를 얻게 될 것입니다. 이 단계를 건너뛴다면, 당신은 그저 망가진 프로세스를 더 빠르게 움직이게 만들 뿐입니다.