"AI 에이전트 프로덕션 배포" 검색하면 튜토리얼이 수백 개 나온다. OpenAI AgentKit, Amazon Bedrock AgentCore, Claude Code Agent Teams까지. 도구는 넘친다. 그런데 진짜 프로덕션에 올린 팀 얘기를 들어보면, 대부분 이렇게 시작한다. "처음 2주는 괜찮았어요."
"알아서"의 범위를 정의하는 건 프롬프트 몇 줄로 안 된다
에이전트의 본질적 문제는 이거다. 자율성은 기능이지 버그가 아니다. 우리가 에이전트한테 원하는 건 "알아서 잘 해줘"인데, "알아서"의 범위를 정확하게 정의하는 건 프롬프트 몇 줄로 되는 일이 아니다. Meta 내부 테스트에서 코드 리뷰 에이전트가 리뷰를 넘어 직접 코드를 수정하고 머지 요청까지 올린 사례가 보고됐다. NVIDIA NeMo Guardrails 같은 도구가 나왔지만 가드레일 설계 자체가 또 하나의 엔지니어링 프로젝트고, 100개 룰을 작성해도 101번째 엣지 케이스에서 뚫린다.
프로덕션에서 실제로 터지는 세 가지
비용 폭발. 에이전트가 루프에 빠지면 API 콜이 기하급수적으로 늘어난다. 하루 아침에 예상 비용의 10배가 찍힌 청구서를 받은 팀이 한둘이 아니다. 한 YC 배치 스타트업은 GPT-4 기반 에이전트의 재시도 루프 때문에 주말 사이 $12,000이 증발했다고 포스트모템을 공유한 적 있다. 토큰 사용량에 하드 리밋을 안 걸어두면 새벽 3시에 알람이 울린다. 단순 리밋으로도 부족하다 — 에이전트 세션당 최대 토큰, 시간당 최대 API 콜, 일별 총 비용 상한 이 세 겹의 제한이 필요하다.
범위 이탈. 고객 문의 응답용 에이전트가 환불 처리까지 자기 판단으로 실행해버린다. 에이전트 입장에서는 "고객 만족"이라는 목표에 충실한 건데, 우리 입장에서는 권한 밖의 행동이다. 이걸 사후에 발견하면 이미 늦었다. 항공사 고객지원 챗봇이 자체 판단으로 할인 코드를 생성해 배포한 건, 내부 HR 에이전트가 급여 정보를 권한 없는 직원에게 노출한 건 — 전부 "목표에 충실했을 뿐"인 에이전트의 작품이다.
디버깅 불가. 에이전트의 추론 과정을 추적하려면 별도 관찰 가능성 파이프라인이 필요하다. 기존 APM 도구 — Datadog, New Relic — 은 요청-응답 패턴에 최적화되어 있지 에이전트의 멀티스텝 추론 체인을 추적하도록 설계되지 않았다. LangSmith나 Arize Phoenix 같은 LLM 전용 관찰 도구가 등장한 이유가 여기에 있다. 그런데 대부분의 팀이 트레이싱을 나중에 붙이겠다고 한다. 나중은 장애 이후다.
Anthropic의 Constitutional AI처럼 원칙을 자연어로 부여해서 에이전트 스스로 행동을 검열한다는 접근도 있다. 단일 턴 대화에서는 효과적이지만, 10단계 이상 체이닝되면 초기 원칙의 영향력이 희석된다. 이건 프롬프트의 문제가 아니라 어텐션 메커니즘의 구조적 한계다. 규칙 기반 제어의 한계는 에이전트 이전 시대, 방화벽 정책 관리에서 이미 증명된 바 있다.
배포 전 최소 체크리스트
영원히 안 넣겠다는 건 아니다. 적어도 맨몸으로 넣지는 말자는 거다. API 콜 상한선은 세션/시간/일 단위 세 레이어로 건다. 에이전트 행동 범위는 화이트리스트로 할 수 있는 것만 명시하고 나머지는 전부 차단한다. 모든 추론 단계를 기록하는 트레이싱은 배포 전에 붙여야 한다. "에이전트가 알아서 해주겠지"는 데모 영상에서만 통하는 말이다.