프로덕션에 AI 에이전트를 올렸다. 동작한다. 청구서도 온다. 그런데 청구서 숫자가 왜 그 숫자인지 설명할 수 없다면, 당신의 에이전트는 지금 조용히 돈을 태우고 있는 것이다.
dev.to에 올라온 두 편의 글이 이 문제를 정면으로 건드렸다. 하나는 30일간 에이전트 트레이싱을 켜놓고 월 토큰 비용의 47%를 잡아먹던 병목 네 가지를 찾아낸 경험담이고, 다른 하나는 Claude Code와 Codex 사이에서 메시지를 손으로 복붙하던 개발자가 그 루프를 끊기 위해 agmsg를 만든 이야기다. 겉보기에 다른 문제처럼 보이지만 본질은 같다. 에이전트를 배포한 이후에 발생하는 숨겨진 운영 비용이다.
집계 지표는 왜 문제를 숨기나
월 520만 토큰. 80개 PR. 숫자가 맞지 않는다. PR당 14,000토큰이라면 80개면 112만 토큰이어야 한다. 나머지 400만 토큰은 어디 갔나. 기존 로그는 "PR-1234 리뷰 완료, 3턴, 14k 토큰"이라고만 말한다. 에이전트가 성공적으로 완료했으니 아무 문제도 없어 보인다.
이게 집계 지표의 구조적 한계다. "턴당 평균 토큰", "일별 총 비용" 같은 대시보드 숫자는 비용이 오르고 있다는 사실은 알려줘도, 어떤 행동이 비용을 만들었는지는 절대 말해주지 않는다. 병목은 대부분 "이 턴 자체가 비싸다"가 아니라 "이런 패턴의 턴이 너무 많다"는 형태로 나타나는데, 집계는 그 패턴을 설계상 지워버린다.
네 가지 침묵하는 병목
OpenTelemetry와 GenAI 시맨틱 컨벤션으로 LLM 호출 단위 스팬을 켠 뒤 한 달, 네 가지 병목이 드러났다.
첫째, 툴 재시도 루프(18%). Stripe MCP 서버가 429를 반환하면 에이전트는 최대 7번 재시도했다. 재시도마다 14,000토큰 컨텍스트를 전부 다시 보냈다. 7회 재시도 = 100,000토큰. 에이전트 로그엔 "완료"로만 찍혔다. 백오프 로직 6줄로 18% 감소.
둘째, 턴마다 컨텍스트 재패치(14%). CLAUDE.md, README, OWNERS, style.md를 매 턴 새로 읽었다. PR 한 건에 14턴이면 읽기 전용 파일 4개 × 14 = 56번 패치. Anthropic의 프롬프트 캐싱 API를 세션당 1회로 제한하자 14% 감소.
셋째, 서브에이전트 중복 컨텍스트(9%). 아키텍처/보안/성능 리뷰어 세 서브에이전트가 동일한 PR diff를 각자 독립적으로 받았다. 3,000토큰 × 3 = 9,000토큰 낭비가 PR마다 반복됐다. 부모 컨텍스트에 diff를 한 번 올리고 캐시 블록을 참조하게 바꾸자 9% 감소.
넷째, 아첨성 서문(6%). 응답의 40%가 "정말 좋은 질문이에요"로 시작했다. 턴당 120토큰, 월 1,100턴, 출력 토큰 단가. 시스템 프롬프트에 "답변부터 시작할 것" 한 줄로 6% 감소.
네 병목을 합치면 월 47%. 코드 리뷰 에이전트가 실제로 하는 일은 하나도 바꾸지 않고 청구서를 절반으로 줄였다.
인간이 메신저가 될 때 생기는 다른 종류의 낭비
토큰 비용과는 다른 종류의 낭비도 있다. Claude Code가 작성한 코드를 복사해 Codex에 붙여 리뷰를 받고, Codex의 피드백을 복사해 Claude Code에 붙여 수정을 요청하는 루프. 하루에 수십 번. 개발자가 두 AI 사이의 인간 릴레이가 된다.
agmsg는 이 루프를 끊기 위해 만들어졌다. SQLite WAL 모드로 에이전트 간 메시지를 중개하고, Claude Code의 Monitor 훅을 이용해 메시지가 도착하는 순간 대화를 인터럽트한다. 데몬 없음, 네트워크 없음, bash와 sqlite3만 있으면 동작한다. Claude Code와 Codex가 서로 다른 훅·설정 모델을 갖고 있다는 이기종 에이전트 문제를 monitor/hook 두 가지 전달 방식으로 흡수했다.
흥미로운 건 이게 단순한 편의 기능이 아니라는 점이다. Claude Code와 Codex를 같은 팀에 묶고 monitor 모드를 켜면 두 에이전트가 인간 개입 없이 자율적으로 대화를 이어간다. 틱택토를 두게 했더니 끝까지 혼자 게임을 완료했다. 장난감 같지만, 이 패턴이 의미하는 건 AI 에이전트가 인간 없이 작업을 넘기는 워크플로우의 실제 구현 가능성이다.
프로덕션 에이전트 운영의 진짜 레이어
두 사례가 함께 가리키는 지점은 명확하다. 에이전트를 배포하는 것과 운영하는 것은 전혀 다른 문제다. 배포는 동작 여부를 검증하는 일이고, 운영은 보이지 않는 비용과 병목을 지속적으로 측정하고 끊는 일이다.
지금까지 이 시리즈에서 다룬 도구 선택, 규칙 설계, 코드 품질 검증, 보안 거버넌스는 에이전트를 배포하기 위한 레이어였다. 트레이싱과 에이전트 간 통신 자동화는 그 다음 레이어다. 프로덕션에서 에이전트가 실제로 어떤 행동을 하고, 그 행동이 얼마나 비용을 만드는지, 그리고 인간이 개입해야 하는 루프를 어디서 끊을 수 있는지를 다룬다.
실행 관점에서 최소 두 가지를 지금 당장 할 수 있다. 첫째, LLM 호출 단위 스팬을 켜라. 비용이 오르고 있다면 어디서 오르는지 알아야 고칠 수 있다. Logfire, Helicone, Langfuse 모두 무료 티어가 있고 GenAI 시맨틱 컨벤션은 지금 가장 널리 합의된 표준이다. 둘째, 멀티 에이전트 워크플로우에서 인간이 메시지 릴레이를 하고 있다면 그 루프 자체를 자동화 대상으로 봐라. agmsg처럼 단순한 SQLite 기반 구현으로도 루프를 끊을 수 있다.
앞으로 어떻게 될까
에이전트 관찰성(Observability)은 빠르게 표준화되고 있다. OpenTelemetry GenAI 시맨틱 컨벤션은 올해 안에 주요 LLM 프레임워크 대부분에서 기본값이 될 가능성이 높다. 에이전트 간 통신 프로토콜도 마찬가지다. MCP가 툴 레이어를 표준화하고 있다면, 에이전트 간 메시지 레이어도 곧 표준 논의가 시작될 것이다.
그때 가서 시작하면 늦다. 지금 프로덕션에 에이전트를 운영하고 있다면, 청구서가 왜 그 숫자인지 설명할 수 있어야 한다. 설명할 수 없다면 아직 에이전트를 운영하는 게 아니라 에이전트가 운영되도록 놔두고 있는 것이다.