실제로 중요한 4가지 비용 범주

항상 켜져 있는(always-on) AI 에이전트는 SaaS 구독처럼 가격이 책정되지 않습니다. 이는 인프라(infrastructure)처럼 가격이 책정된다는 것을 의미하며, 즉 청구 금액은 동시에 실행되는 여러 개의 독립적인 계측기(meters)의 합계라는 뜻입니다. 월간 지출을 추정하기 전에, 비용을 다음과 같은 범주(buckets)로 나누어야 합니다:

• 모델/API 토큰 (Model/API tokens) — 모든 프롬프트(prompt), 도구 호출(tool call), 응답은 토큰을 소비하며, 이는 단순히 사용자에게 보여지는 출력뿐만 아니라 에이전트의 내부 추론(internal reasoning)이 얼마나 "수다스러운지"에 따라 확장됩니다.
• 도구 및 API 호출 (Tool and API calls) — 검색 API, 코드 실행 샌드박스(code execution sandboxes), 브라우저 자동화, 제3자 데이터 제공업체 등은 각각 호출당 또는 분당 가격 책정 방식이 다릅니다.
• 호스팅 및 오케스트레이션 (Hosting and orchestration) — 에이전트 루프(agent loop)를 계속 실행하는 서버 또는 서버리스 함수(serverless function), 그리고 에이전트에게 장기적인 문맥(long-term context)이 필요한 경우 벡터 데이터베이스(vector database) 또는 메모리 저장소(memory store)가 포함됩니다.
• 관측 가능성 및 재시도 (Observability and retries) — 로깅(logging), 트레이싱(tracing), 그리고 조용히 재실행되는 실패한 시도들에 대한 토큰 비용이 포함됩니다.

대부분의 비용 추정치는 첫 번째 범주만을 고려하기 때문에 실패합니다. 실제로 도구 호출과 재시도는 핵심 모델 호출보다 청구 금액에서 더 크고 예측 불가능한 비중을 차지하는 경우가 많습니다.

토큰 비용이 잘못된 첫 번째 질문인 이유

에이전트 배포를 처음 접하는 팀들은 보통 "GPT-X의 100만 토큰당 비용이 얼마인가"라는 질문으로 시작하고 거기서 멈춥니다. 이는 두 가지 이유로 잘못된 진입점입니다.

첫째, 에이전트의 토큰 소비는 사용자 활동과 선형적으로 비례하지 않습니다. 단일 사용자 요청이 여러 번의 내부 추론 단계, 도구 호출, 그리고 자기 수정(self-corrections)을 트리거할 수 있으며, 이 과정 각각에서 문맥(context)을 다시 전송합니다. 200토큰 정도의 사용자 질문은 에이전트의 계획(planning) 및 도구 응답 수집(tool-response ingestion)을 계산하면 실제 모델 사용량이 수천 토큰으로 쉽게 늘어날 수 있습니다.

둘째, 컨텍스트 윈도우 (context window) 습관은 표면적인 가격보다 더 중요합니다. 매 턴마다 전체 대화 기록과 도구 출력값 (tool outputs)을 다시 전송하는 에이전트는 모델의 토큰당 가격과는 거의 상관없이, 컨텍스트가 어떻게 관리되는지에 따라 토큰을 소모하게 됩니다. 이전 대화 내용을 요약하거나, 도구 출력값이 컨텍스트로 다시 들어오기 전에 다듬고(trimming), 반복되는 시스템 프롬프트를 캐싱(caching)하는 기술(제공업체가 프롬프트 캐싱을 지원하는 경우)은 일반적으로 어떤 모델을 선택하느냐보다 비용 제어에 더 큰 영향을 미칩니다.

추측 없이 월간 지출액 추정하기

에이전트의 작업 부하는 대개 작업 중심(task-driven)이므로, "사용자당 비용" 모델보다는 "작업당 비용" 모델을 구축하는 것이 실행 가능한 추정 방법입니다.

1. 몇 가지 대표적인 작업을 도구화(instrument)하여 실제 토큰 사용량, 도구 호출(tool calls), 지연 시간(latency)을 기록하세요. 문서만 보고 이를 추정해서는 안 됩니다.
2. 여기에 예상되는 일일 작업량을 곱하고, 다시 30을 곱한 뒤, 정상적인 경로(happy path)보다 더 많은 추론 단계가 필요한 재시도(retries) 및 예외 상황을 위해 버퍼(보통 20~40%)를 추가하세요.
3. "항상 켜져 있는" 호스팅 비용(대략 고정적인 비용)과 "작업당" 비용(사용량에 따라 확장되는 비용)을 분리하여, 청구서의 어느 부분이 도입에 따라 증가하고 어느 부분이 그렇지 않은지 확인할 수 있도록 하세요.

또한, 몇 달 전에 외운 숫자에 의존하기보다 실제 가격 변동을 추적하는 것이 가치 있는 지점입니다. 모델 및 API 가격은 매우 자주 변동되므로, hashtag.org의 세부 내역과 같이 주기적으로 업데이트되는 참조 자료가 일회성 계산보다 더 유용합니다.

팀들이 과소평가하는 부분

예산 책정 시 가장 흔히 발생하는 실수는 실패 경로(failure paths)의 비용을 무시하는 것입니다. 즉, 루프(loop)에 빠지거나, 재시도하거나, 불확실할 때 더 비싼 모델로 에스컬레이션(escalate)하는 에이전트의 비용을 간과하는 것입니다. 작업의 "성공 경로" 비용만을 위해 예산을 책정하면 실제 지출을 지속적으로, 때로는 상당히 과소평가하게 됩니다. 왜냐하면 실패 및 재시도 경로가 바로 토큰 및 도구 호출 사용량이 급증하는 지점이기 때문입니다.

핵심 요약 (Takeaway): (사용자당 비용이 아닌) 작업당 에이전트 비용을 추산하고, 예산을 확정하기 전에 실제 사용량을 계측(instrument)하며, 첫날부터 재시도 및 실패에 대비한 버퍼(buffer)를 구축하십시오.

자세한 내용은 hashtag.org에서 확인하실 수 있습니다.