당신의 에이전트가 조용히 토큰을 낭비하는 이유 (그리고 이를 방지하는 방법)

당신은 지난달에 코딩 에이전트 (coding agent)를 배포했습니다. 이 에이전트는 자율적으로 작동하며, 티켓을 가져오고, PR (Pull Request)을 제출하며, Slack 질문에 답변합니다. 진정으로 유용합니다.

그러다 청구서가 도착했습니다.

에이전트가 계획했던 것보다 더 많은 API 비용을 소비했습니다. 왜 그런지는 알 수 없습니다. 티켓 하나당 모델을 30~50회 호출합니다. 그 호출 중 일부는 느린 재시도 (retries)입니다. 일부는 불필요한 컨텍스트 재독해 (redundant context re-reads)입니다. 일부는 에이전트가 매 호출마다 시스템 프롬프트 (system prompt)나 도구 설명 (tool descriptions)을 다시 읽는 것일 수도 있습니다.

당신이 알아차렸을 때는 이미 피해가 발생한 후였습니다.

이것은 현재 프로덕션 에이전트 배포에서 제가 보는 가장 흔한 문제이며, 모델의 문제가 아닙니다. 이것은 인프라 문제 (infrastructure issue) 입니다. 모델은 의도한 대로 작동하고 있습니다. 문제는 당신의 팀이 에이전트가 무엇을 소비하고 있는지에 대한 가시성 (visibility)이 없고, 에이전트나 팀별로 비용을 격리할 방법이 없으며, 폭주하는 에이전트가 하루 만에 한 달 치 예산을 태워버리기 전에 멈출 수 있는 서킷 브레이커 (circuit breaker)가 없다는 것입니다.

조용한 비용 문제

스크립트에서 단일 API 호출을 실행할 때는 비용이 명확합니다: 1회 호출 = 1회 결제. 하지만 에이전트는 다릅니다. 에이전트는 루프 (loops)입니다:

1. 에이전트가 작업을 읽습니다.
2. 에이전트가 어떤 도구 (tool)를 호출할지 결정합니다.
3. 에이전트가 도구를 호출합니다.
4. 에이전트가 출력을 다시 읽습니다.
5. 에이전트가 다음 단계를 결정하거나 모델을 다시 호출합니다.
6. 작업당 15~50회 반복합니다.

각 단계는 LLM (Large Language Model)을 호출합니다. 각 호출은 토큰 (tokens) 비용을 발생시킵니다. 만약 당신의 에이전트가 매 턴마다 시스템 프롬프트를 다시 읽거나 (프로덕션에서 실제로 제가 보는 패턴입니다), 도구 설명을 다시 읽거나, 이전 메시지를 다시 읽는다면, 그 비용은 보이지 않게 복리로 쌓입니다. 호출당 2회의 추가 읽기를 유발하는 버그는 완료된 작업당 100회의 추가 읽기가 됩니다.

문제는 너무 늦게 표면화됩니다: 당신은 호출이 아니라 청구서를 보게 됩니다.

이것이 팀을 망치는 이유

에이전트 인프라에 집중하는 Reddit 커뮤니티들은 이 패턴을 명확하게 기록하고 있습니다. 에이전트로 수익을 창출하는 팀들 (email-to-CRM 라우팅, FAQ 지원, 이력서 파싱)은 광범위하고 다단계인 자율 시스템을 구축하는 팀들이 아닙니다. 그들은 다음과 같은 팀들입니다:

1. 첫날부터 비용 제어 (cost controls) 체계를 구축했습니다.
2. 월간 예산 상한선 (budget ceiling)을 설정하고 이를 모니터링하는 접근 방식을 취했습니다.
3. 어떤 에이전트가, 어떤 사용자에 의해, 어떤 작업 (task)을 수행할 때 각 호출 (call)이 발생했는지 기록했습니다.
4. "왜 이 작업은 $0.30이 아니라 $1.50의 비용이 들었는가?"라는 질문에 답할 수 있었습니다.

이 단계를 건너뛰는 팀들은 에이전트를 배포하고 일주일 동안은 잘 작동하는 것처럼 보이지만, 그 후 다음 중 하나의 상황을 맞이하게 됩니다:

• 루핑 (looping)을 유발하는 엣지 케이스 (edge case)를 발견함 (동일한 도구 호출을 반복하거나, 컨텍스트를 끝없이 다시 읽는 현상).
• 한 사용자가 실수로 이를 연속 100번 실행함.
• 도구 통합 (tool integration)의 버그로 인해 에이전트가 도구를 호출하고 부분적인 응답을 받은 뒤, 20번이나 재시도함.

그 시점이 되면 비용은 이미 확정된 상태입니다. 상세한 로그 (logs) 없이는 사후에 그 원인을 파악할 수 없습니다.

당신에게 필요한 것 (그리고 아마 아직은 갖추지 못한 것)

에이전트를 프로덕션 (production) 환경에서 운영하려면 다음이 필요합니다:

1. 에이전트별 비용 추적 (Per-agent cost tracking): 총 지출액이 아니라, 에이전트별, 사용자별, 작업별 지출액을 알아야 합니다. 지원 (support) 에이전트가 코딩 (coding) 에이전트보다 저렴하다면 이를 알아야 합니다. 특정 사용자의 실행 비용이 다른 사용자보다 10배 더 높다면, 그 또한 알아야 합니다.

2. 가상 키 (Virtual keys) 및 팀 격리 (team isolation): 모든 개발자에게 LLM 제공업체의 콘솔에 직접 접근할 수 있는 권한을 줄 수는 없습니다. 그들은 실험 과정에서 예산을 낭비할 것입니다. 게이트웨이 (gateway) 뒤에 위치하여 팀 단위 또는 에이전트별로 관리되는 API 키가 필요하며, 이를 통해 각 팀의 지출을 추적하고 제한할 수 있어야 합니다.

3. 예산 제어 (Budget controls): 팀별, 에이전트별, 월별 예산 상한선이 필요합니다. 에이전트가 한도에 도달하면 시스템이 중단되는 것이 아니라, 당신에게 경고 (alert)를 보내야 합니다. 엄격한 한도 (hard limits)에 도달하면 새로운 작업을 수락하는 것을 중단해야 합니다.

4. UI에서의 지출 가시성 (Spend visibility in the UI): 실시간 또는 준실시간 (near-real time)으로 다음 항목을 볼 수 있는 대시보드 (dashboard)가 필요합니다:

   • 이번 달 총 지출액
   • 에이전트별 지출액
   • 팀별 지출액
   • 작업당 평균 비용
   • 비용 추세 (비용이 증가하고 있는가? 그 이유는 무엇인가?)

5. 상세 호출 로그 (Detailed call logs): 단순히 "에이전트가 10번 실행되었다"가 아니라, "에이전트가 10번 실행되었고, 400번의 LLM 호출을 수행했으며, 실행당 평균 40회의 호출을 기록했고, 호출 유형의 분포는 다음과 같다"와 같은 정보가 필요합니다.

만약 이러한 정보 중 하나라도 놓치고 있다면, 당신은 눈을 감고 운전하는 것과 같습니다. 당신의 에이전트는 비효율적인 패턴으로 인해 예산의 50%를 낭비하고 있을 수도 있으며, 이를 알게 되는 시점은 청구서가 날아온 후일 것입니다.

프로덕션 팀이 이를 처리하는 방법

LiteLLM이 내부적으로 구축한 코딩 에이전트(엔지니어링 백로그의 30%를 처리하는 에이전트)는 다음과 같은 특정 패턴을 사용합니다:

• 두뇌(Brain) + 샌드박스(Sandbox) 분리: 추론 루프(Reasoning loop)는 지속적인 포드(Persistent pod)에서 실행됩니다. 실행은 일시적인 샌드박스(Ephemeral sandboxes)에서 이루어집니다. 이를 통해 재부팅과 컨텍스트 재읽기(Context re-reads)를 줄입니다.
• 명확한 도구 인터페이스 (Clear tool interface): 모델이 매 턴마다 다시 읽어야 하는 산문 형태의 설명이 아닌, 구조화된 도구 정의(Structured tool definitions)를 사용합니다.
• 게이트웨이에서의 비용 추적 (Cost tracking at the gateway): 모든 LLM 호출은 게이트웨이를 통해 라우팅되므로, 모든 호출은 에이전트 ID, 팀 ID, 작업 ID와 함께 기록됩니다. 나중에 추측할 필요가 없습니다.
• 에이전트별 예산 강제 적용: 에이전트는 자신의 비용 상한선(Cost ceiling)을 알고 있습니다. 작업을 맡기 전에 남은 예산을 확인할 수 있습니다.

결과적으로: 예측 가능한 비용, 관찰 가능한 동작, 그리고 작업 비용이 예상보다 많이 든 이유를 디버깅(Debug)할 수 있는 능력을 갖추게 됩니다.

인프라 격차 (The Infrastructure Gap)

이것이 에이전트 플랫폼이 존재하는 이유입니다. 이들은 단순히 에이전트 로직을 작성하기 위한 프레임워크(그것은 LangGraph나 LLM 프레임워크가 담당하는 영역입니다)가 아닙니다. 이들은 팀이 다음과 같은 작업을 수행할 수 있게 해주는 운영 계층(Operational layer)입니다:

• 통합 코드를 다시 작성하지 않고도 다양한 런타임(Runtimes)에서 에이전트를 실행합니다.
• 세션과 메모리를 관리하여 에이전트가 재시작 시 컨텍스트를 잃지 않도록 합니다.
• 비용을 추적하고 예산을 강제합니다.
• 실시간으로 무슨 일이 일어나고 있는지 확인합니다.
• 배포 없이도 폭주하는 에이전트의 액세스 권한을 취소합니다.

만약 에이전트를 구축하고 있지만 이를 수행할 방법이 없다면, 당신은 비용 폭발을 향해 달려가고 있는 것입니다. 에이전트는 문제가 생기기 전까지는 잘 작동하겠지만, 문제가 생겼을 때는 이미 회복할 수 없을 만큼 예산을 다 써버린 상태일 것입니다.

시작하는 방법

현재 프로덕션 환경에서 에이전트를 운영하고 있다면:

1. 현재 지출을 감사(Audit)하세요: 지난 한 달간의 API 청구서를 확인하세요. 에이전트 비용이 얼마나 발생했나요? 어떤 에이전트가 얼마만큼의 비용을 발생시켰는지 모른다면, 우선 가시성(Visibility)을 확보해야 합니다.

2. 모든 에이전트 호출에 비용 추적 기능을 추가하세요: 더 많은 에이전트를 배포하기 전에, 모든 모델 호출(Model call)에 에이전트 ID, 작업 ID(Task ID), 팀 ID를 포함하도록 계측(Instrument)하세요. 이것은 기초적인 작업입니다.

3. 오늘 당장 예산 상한선(Budget ceiling)을 설정하세요: "에이전트당 월 $X를 지출하겠다"라고 결정하세요. 이를 확정된 수치로 만드세요. 80% 지점에서 알림을 설정하세요. 100%에 도달하면 에이전트는 작업을 수락하는 것을 중단합니다 (시스템이 충돌하는 것이 아니라, 대기열에 머물며 승인을 기다리게 됩니다).

4. 도구 호출(Tool calls)도 기록하세요: LLM 호출뿐만 아니라, 에이전트가 어떤 도구를 트리거했는지, 그리고 그 도구가 성공했는지도 기록해야 합니다. 실패를 유발하고 재시도(Retries)를 일으키는 도구는 예산 누수의 원인이 됩니다.

5. 매주 호출 분포를 검토하세요: 매주 금요일 10분을 할애하여 다음과 같이 질문하세요. "어떤 에이전트가 가장 많은 비용을 발생시켰는가? 왜 그런가?" 만약 특정 에이전트가 작업당 평균 20회가 아닌 60회의 호출을 수행하고 있다면, 수정해야 할 패턴이 있는 것입니다.

만약 팀을 위한 프로덕션 에이전트 플랫폼을 구축 중이거나, 에이전트를 실행할 플랫폼을 평가 중이라면 다음을 질문하십시오:

• 에이전트별로 예산을 설정할 수 있는가?
• 에이전트, 팀, 작업별로 세분화된 지출 내역을 볼 수 있는가?
• 모든 개발자가 제공업체 콘솔(Provider console)에 접근하지 않도록 API 키를 격리할 수 있는가?
• 에이전트의 의사결정 루프(Decision loop)에 비용 확인 단계를 추가할 수 있는가?

이것들은 있으면 좋은(Nice-to-have) 기능이 아닙니다. 신뢰할 수 있게 작동하는 에이전트와, 어느 순간 작동을 멈춰버리는 에이전트를 가르는 인프라입니다.

조용한 비용 문제는 해결 가능합니다. 다만 첫날부터 인프라, 가시성, 그리고 규율(Discipline)이 필요할 뿐입니다.

여러분의 팀은 에이전트 비용 제어를 위해 어떤 방식을 사용하고 있나요? 여러분의 프로덕션 배포 환경에서 무엇이 효과적이었는지, 특히 "청구서 폭탄"을 맞았을 때 어떻게 해결했는지 궁금합니다.