AI 에이전트가 프로덕션에서 계속 실패하는 이유와 이를 해결하는 프롬프트 체인

대부분의 AI 에이전트 데모는 작동합니다. 하지만 실제로 배포하여 사용하면, 이들은 같은 세 가지 실수를 반복하기 시작합니다.

1. 자신감 넘치는 오류 (Confidently wrong). 모델은 그럴듯한 답변을 반환하고, 파이프라인은 이를 신뢰하며, 잘못된 데이터가 다운스트림으로 전달됩니다.
2. 비결정적 출력 (Non-deterministic output). 한 번 실행했을 때는 JSON을 반환하지만, 다음에는 산문(prose)에 감싸진 JSON을 반환하고, 또 다른 경우에는 필수 필드를 누락합니다.
3. 조용한 실패 (Silent failure). 특정 단계가 부분적으로만 완료되고, 다음 단계는 불완전한 상태(partial state)로 실행됩니다. 이 과정에서 오류를 발생시키는 것은 사람이 발견할 때까지 아무도 모릅니다.

사람들의 본능적인 반응은 모델 탓을 하고 더 큰 모델을 찾는 것입니다. 하지만 제 경험상 문제는 거의 모델이 아닙니다. 바로 **프롬프트 체인(prompt chain)**입니다.

프롬프트와 프롬프트 체인의 차이점

프롬프트는 하나의 지시사항입니다. 반면, 프롬프트 체인은 각 단계가 다음 조건을 만족하는 제약된 일련의 단계들입니다:

• **단일 책임 (single responsibility)**을 가집니다.
• **기계 검증 출력 (machine-validated output)**을 생성합니다.
• 이전 단계의 출력이 검증될 때까지 진행할 수 없습니다.

다음은 제가 에이전트를 프로덕션에서 생존하게 만든 체인입니다:

-> 역할(role) + 경력(seniority)
-> 금지 토큰 목록(banned-token list)
-> 엄격한 JSON 스키마 출력
...

각 링크는 실제적인 작업을 수행합니다.

1. 역할 및 경력 (Role + seniority)

약함: "당신은 도움이 되는 어시스턴트입니다."

강함: "당신은 결제 시스템 마이그레이션을 검토하는 선임 백엔드 엔지니어입니다. PCI-compliant 시스템을 배포한 경험이 있습니다. 속도보다 정확성을 최적화하며, 불확실성은 명시적으로 표시해야 합니다."

경력(Seniority)은 답변의 _분포(distribution)_를 바꿉니다. '선임 엔지니어' 프롬프트는 추측을 덜 하고 더 많이 추론합니다. 이는 비용이 적게 들면서도 효과가 큰 변화입니다.

2. 금지 토큰 목록 (Banned-token list)

모델들은 같은 필러(filler)에 수렴하는 경향이 있습니다: "delve into", "in today's fast-paced world", "game-changer", "it's worth noting that".

프로덕션 파이프라인에서 이러한 필러는 순수한 노이즈일 뿐이며, 모델이 일반적인 출력으로 표류하고 있다는 신호입니다.

저는 프롬프트마다 명시적인 **음성 토큰 목록(negative token list)**을 유지합니다. 만약 모델이 금지된 토큰을 생성하면, 해당 출력은 거부되고 재시도됩니다. 이 하나의 제약 조건이 어떤 온도(temperature) 조정보다도 출력 품질을 높여주었습니다.

3. 엄격한 JSON 스키마 출력

자유 형식(Free-text) 출력은 대규모로 파싱하기 어렵습니다. 기계가 소비하는 모든 단계는 스키마에 유효성 검사를 통과하는 JSON을 반환해야 하며, 만약 유효성 검사에 실패하면 해당 단계는 '해석하려고 시도'하는 것이 아니라 실패합니다.

{
  "type": "object",
  "required": ["verdict", "reason", "confidence"],
...

스키마 우선(Schema-first) 출력을 사용하면 확률적 모델을 타입이 지정된 함수 호출로 바꿀 수 있습니다. 이는 전체 체인에서 가장 큰 신뢰성 확보 방안입니다.

4. 별도의 검증 단계 (Verification Pass)

이는 대부분의 사람들이 건너뛰는 링크이며, '자신만만한 오류'가 프로덕션에 도달하는 것을 막아주는 핵심 요소입니다.

**행동(acts)**을 하는 에이전트는 자신이 끝났다고 결코 판단하지 않습니다. 두 번째 독립적인 프롬프트가 도구 출력과 의도된 행동을 받아 스키마를 기반으로 판정(verdict)을 반환해야 합니다. 결정적으로:

• 검증자(verifier)는 작성자가 아닙니다. 모델은 자신이 작성하지 않은 계획에 대해 훨씬 더 잘 문제점을 발견합니다.
• 검증자의 출력은 유효성 검사를 거칩니다. 형식이 잘못된 판정(malformed verdict)은 차단(block)으로 처리됩니다.
• 의심스러운 경우 기본값은 allow가 아니라 needs_human입니다.

체인이 단일 메가 프롬프트보다 나은 이유

체인은 조합 가능합니다. 나머지 부분을 건드리지 않고도 하나의 링크를 업그레이드하거나, 검증 단계를 추가하거나, 인간 개입 루프(human-in-the-loop) 게이트를 삽입할 수 있습니다.

핵심 요약 (The takeaway)

만약 에이전트가 계속 오작동한다면, 모델을 업그레이드하는 것을 멈추고 **체인 자체를 제약(constraining the chain)**하기 시작해야 합니다. 역할 + 직급 지정, 금지 토큰 목록, 엄격한 스키마 출력, 그리고 독립적인 검증 단계는 저의 에이전트를 '데모에서 작동함' 수준에서 '프로덕션에서 생존함' 수준으로 끌어올렸습니다.

제가 사용하는 정확한 32개의 시스템 프롬프트(오케스트레이션, 코드 리뷰, 보안 감사, 추출, 분석, 검증), JSON 스키마, 그리고 stdlib 전용 Python 멀티 에이전트 러너를 작은 툴킷으로 패키징했습니다:

프로덕션 AI 에이전트 아키텍처 및 자율 프롬프트 체인 -> https://ancuboy.gumroad.com/l/production-ai-agent-kit

이는 실제 자율 에이전트 스택의 작동 런타임 및 프롬프트 라이브러리입니다 — 작업 디스패칭, SQLite 기반 상태 관리, 지수 백오프(exponential-backoff) 재시도, 리스 회수를 통한 워커 하트비트, 그리고 위에서 언급된 스키마 검증 패턴을 포함합니다. 외부 서드파티 패키지나 월별 SaaS 비용이 없습니다.

만약 이 글에서 단 한 가지만 가져가야 한다면: 검증(verification) 단계를 추가하세요. 이것이 데모는 잘 되지만 실제 배포(ship)하기 어려운 에이전트와, 실제로 출시할 수 있는 에이전트를 가르는 차이입니다.