Molayo

© 2026 Molayo

Dev.to헤드라인2026. 05. 27. 04:40

모델별 AI 에이전트 비용을 추적하느라 예산을 탕진 중인 Slack 채널을 놓쳤던 경험

요약

AI 에이전트 인프라 운영 시 모델이나 토큰 단위의 비용 추적을 넘어, 워크플로우 및 작업 단위별 비용 관리가 필요함을 강조합니다. 단순한 API 사용량 확인이 아닌 실제 비즈니스 가치를 창출하는 단위별 비용 분석의 중요성을 다룹니다.

핵심 포인트

  • 모델/토큰 단위가 아닌 워크플로우 단위의 비용 추적이 필수적임
  • Slack 채널, 고객, 자동화 실행 등 작업 단위별 비용 분석 필요
  • 제공자 대시보드는 조달용이며, 운영을 위한 실행 가능한 데이터는 별도로 필요함
  • 재시도 및 도구 루프가 비용 급증의 주요 원인이 될 수 있음

저는 많은 팀이 그러하듯 AI 비용을 다음과 같은 방식으로 살펴보곤 했습니다:

  • OpenAI 대시보드
  • 모델별 지출
  • 토큰 수 (token counts)
  • 상황이 심각해지면 API 키별로 트래픽 분할

이 방식은 당신의 "단일 챗봇"이 실제 에이전트 인프라 (agent infrastructure)로 변하기 전까지만 유효합니다.

이제 봇은 Slack, Telegram, n8n, OpenClaw, 몇 가지 내부 도구, 그리고 백그라운드에서 여전히 재시도 중이라는 사실조차 잊어버린 일부 워크플로우 (workflow)에 연결되어 있습니다.

그 시점이 되면, 모델 수준의 가격 책정은 더 이상 유용한 지표가 아닙니다.

당신에게 실제로 필요한 것은 워크플로우당 비용 (cost per workflow)입니다.

다음과 같은 것이 아니라:

  • 모델당 비용 (cost per model)
  • 제공자당 비용 (cost per provider)
  • 토큰 버킷당 비용 (cost per token bucket)

다음과 같은 것입니다:

  • Slack 채널당 비용 (cost per Slack channel)
  • 고객당 비용 (cost per customer)
  • 자동화 실행당 비용 (cost per automation run)
  • 대화당 비용 (cost per conversation)
  • 워크플로우 실행당 비용 (cost per workflow execution)

이러한 차이는 조용히 돈을 불태우고 있는 단 하나의 채널이나 워크플로우를 놓치기 전까지는 사소하게 들립니다.

숨겨진 문제를 수면 위로 끌어올린 Reddit 게시물

에이전트 비용에 관한 논의를 파헤치던 중, SigNoz에서 Slack 채널 또는 Telegram 토픽당 비용을 추적하는 방법에 관한 r/openclaw의 스레드를 발견했습니다.

한 가지 제안은 평소와 다름없는 답변이었습니다: 채널마다 별도의 API 키를 사용하라는 것이었죠.

원문 작성자는 즉시 그 제안을 거절했습니다:

"문제는 새로운 채널에 봇을 추가할 때 새로운 API 키를 추가하지 않고도 Slack 채널당 비용을 추적해야 한다는 점입니다."

그것이 진짜 문제입니다.

"어떤 모델이 비싼가?"가 아닙니다.

"토큰을 얼마나 사용했는가?"도 아닙니다.

진짜 질문은 이것입니다:

어떤 작업 단위 (unit of work)가 지출을 유발하고 있는가?

이러한 관점으로 생각하기 시작하면, 많은 인기 있는 AI 가격 책정 조언들이 불완전해 보입니다.

제공자 대시보드는 진실을 말하면서도 여전히 당신에게 거짓말을 하고 있습니다

저는 여전히 제공자 대시보드를 원합니다.

배포 후 GPT-5 사용량이 급증한다면, 저는 그것을 알고 싶습니다.
Claude Opus 4.6의 비용이 갑자기 두 배로 뛴다면, 저는 그것을 알고 싶습니다.
Grok 4.20이 나타나지 말아야 할 트레이스 (traces)에 나타나기 시작한다면, 저는 그것을 알고 싶습니다.

하지만 이러한 대시보드들은 주로 조달 (procurement) 관련 질문에 답해줍니다.

운영자 (operator)의 질문에는 답해주지 않습니다.

만약 하나의 OpenClaw 봇이 다음을 서비스한다면:

  • 40개의 Slack 채널
  • 12개의 Telegram 토픽
  • n8n 내 3개의 고객 자동화 (customer automations)

를 서비스한다면, "이번 주 Claude 비용이 이만큼 들었다"라는 정보는 흥미롭긴 하지만, 실행 가능한 (actionable) 수준은 아닙니다.

제가 실제로 원하는 것은 다음과 같습니다:

  • 어떤 Slack 채널이 가장 비용이 많이 발생하는가?
  • 어떤 고객 계정이 재시도 (retries)와 도구 루프 (tool loops)를 유발하는가?
  • 어떤 n8n 워크플로 (workflow)가 1번의 모델 호출 대신 5번의 모델 호출로 확산 (fans out)되는가?
  • 어떤 자동화가 검색 (retrieval) 기능을 추가한 후 더 비싸졌는가?

이것이 바로 운영 (operations)입니다.

그리고 에이전트가 다단계 시스템 (multi-step systems)이 되면, 단순한 모델 지출액보다 운영이 더 중요해집니다.

에이전트가 실전에 투입되자마자 모델별 보고가 무용지물이 되는 이유

단일 LLM 호출 (LLM call)은 에이전트 실행 (agent run)과 동일하지 않습니다.

당연한 소리처럼 들리겠지만, 팀들은 여전히 이 둘을 교체 가능한 것으로 간주하고 예산을 책정합니다.

하지만 이 둘은 다릅니다.

실제 에이전트 실행은 다음과 같을 수 있습니다:

  1. 메시지 분류 (classify)
  2. 컨텍스트 검색 (retrieve context)
  3. 이전 대화 요약 (summarize)
  4. 도구 호출 (call a tool)
  5. 응답 생성 (generate a response)
  6. Slack용 출력 형식 재구성 (reformat output)
  7. 첫 번째 도구 호출 실패로 인한 재시도 (retry)

이것이 하나의 비즈니스 이벤트 (business event)입니다.

하지만 내부적으로는 여러 모델, 여러 번의 재시도, 그리고 여러 도구를 호출할 수 있습니다.

그래서 누군가 "그냥 모델 지출액을 추적하세요"라고 말한다면, 저의 첫 번째 반응은 이렇습니다. "정확히 무엇을 위해서 말인가요?"

왜냐하면 비즈니스 이벤트는 다음과 같은 것이 아니기 때문입니다:

  • GPT-5가 18k 토큰을 사용함
  • Claude Opus 4.6이 생성을 처리함
  • 어떤 프록시 (proxy)가 저렴한 호출을 기록함

비즈니스 이벤트는 다음과 같아야 합니다:

  • 지원 에스컬레이션 (support escalation) 워크플로가 두 번 실패하여 1.18달러가 소모됨
  • #enterprise-deals 채널의 영업 지원 (sales-assist) 봇 비용이 갑자기 지난주보다 4배 더 많이 나옴
  • 온보딩 (onboarding) 워크플로가 기존 1회의 모델 호출에서 이제 3회의 모델 호출을 사용함

이것이 바로 엔지니어와 운영자가 조치를 취할 수 있는 정보입니다.

제가 가장 먼저 사용할 지표: 완료된 워크플로당 비용 (cost per completed workflow)

에이전트를 프로덕션 (production) 환경에서 운영한다면, 저의 주관적인 견해는 간단합니다:

여러분의 주요 비용 지표는 '완료된 워크플로당 비용 (cost per completed workflow)'이어야 합니다.

그런 다음, 여러분의 시스템에 맞는 차원 (dimensions)별로 이를 세분화하십시오.

실제로 중요한 차원들

다음은 제가 모든 LLM 요청에 포함시키고 싶은 필드들입니다:

  • workflow_id (워크플로우 ID)
  • customer_id (고객 ID)
  • channel (채널)
  • stage (단계)
  • feature (기능)
  • user_id (사용자 ID)
  • conversation_id (대화 ID)
  • environment (환경)

예시:

  • workflow_id=support_triage_v3
  • channel=slack:#sales
  • customer_id=acct_1284
  • stage=retrieval (검색)
  • feature=thread_summary (스레드 요약)
  • environment=production (운영 환경)

이 지점에서 소위 LLM 비용 최적화(LLM cost optimization)라고 불리는 많은 것들이 잘못된 방향으로 흐릅니다.

팀들은 Claude에서 Qwen으로, 혹은 GPT-5에서 Llama로 옮길지 여부를 두고 몇 주 동안 토론하지만, 여전히 다음 질문에는 답하지 못합니다:

어떤 워크플로우가 그 비용을 지불할 가치가 있는가?

이것이 모델 선택을 주도해야 하는 질문이지, 그 반대가 되어서는 안 됩니다.

실질적인 예시: 나중에 추측하는 대신 요청에 태그 달기

만약 OpenAI 호환 클라이언트(OpenAI-compatible client)를 사용하고 있다면, 가장 깔끔한 패턴은 요청 시점에 메타데이터(metadata)를 첨부하는 것입니다.

다음은 LiteLLM 스타일의 예시입니다:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:4000", api_key="sk-local")
...

이 단 한 번의 변화가

  • 어떤 워크플로 (workflow)가 해당 호출을 생성했는지
  • 그것이 재시도 루프 (retry loop)의 일부였는지
  • 어떤 고객이나 채널에 속해 있었는지
  • 해당 호출이 유용했는지 아니면 낭비되었는지

맥락이 없는 정확한 수치는 여전히 취약한 텔레메트리 (telemetry)입니다.

Helicone과 Langfuse는 동일한 해답을 가리키고 있습니다

이것은 어떤 생소한 패턴이 아닙니다.

도구는 이미 존재합니다.

Helicone은 대화 (conversation), 앱 (app), 환경 (environment) 및 기타 요청 메타데이터 (metadata)와 같은 사용자 정의 속성 (custom properties)에 대해 매우 명시적입니다.

예시:

Helicone-Property-Conversation: support_issue_2
Helicone-Property-App: mobile
Helicone-Property-Environment: production

이것이 바로 다음과 같은 질문에 답하는 방식입니다:

  • 왜 어제 모바일 지원 비용이 비싸졌는가?
  • 왜 운영 (production) 환경이 스테이징 (staging) 환경보다 4배 더 많은 비용을 쓰고 있는가?
  • 어떤 대화 유형이 긴 에이전트 루프 (agent loops)를 유발하는가?

Langfuse 역시 트레이스 (traces), 태그 (tags), 사용자 ID (user IDs), 롤업 (rollups)을 통해 동일한 지점에 도달합니다.

패턴을 한 번 보고 나면 공통적인 패턴은 명확합니다:

모든 모델 호출에 비즈니스 맥락 (business context)을 부착하세요.

그런 다음 비용을 집계할 때 모델 중심이 아닌, 워크플로 또는 대화 중심으로 먼저 집계하십시오.

OpenAI 사용량 API가 할 수 있는 것과 할 수 없는 것

OpenAI의 사용량 및 비용 API는 이전보다 개선되었습니다.

다음과 같은 항목으로 그룹화하는 것은 진정으로 유용합니다:

  • project_ids
  • user_ids
  • api_key_ids
  • models

하지만 여기에는 명확한 한계가 있습니다.

만약 다섯 개의 워크플로가 모두 하나의 프로젝트와 하나의 API 키를 공유한다면, OpenAI는 귀하의 내부 비즈니스 작업 단위를 추론할 수 없습니다.

OpenAI는 다음 사항을 알 수 없습니다:

  • #support-enterprise가 비용이 많이 드는 Slack 채널이라는 사실
  • lead_enrichment_v3가 너무 많이 재시도하고 있다는 사실
  • 특정 테넌트 (tenant)가 지출의 대부분을 발생시키고 있다는 사실

그러한 정보는 귀하의 스택 (stack)을 통해 전달될 때만 존재합니다.

따라서 네, 제공업체 네이티브 리포팅 (provider-native reporting)을 사용하십시오.

다만, 그것이 스스로 워크플로 경제성 (workflow economics) 문제를 해결해 줄 것이라고 기대하지는 마십시오.

토큰 차트를 오해하게 만드는 교묘한 비용 카테고리들

많은 팀이 여전히 비용을 다음과 같이 판단합니다:

  • 입력 토큰 (input tokens)
  • 출력 토큰 (output tokens)

이는 실제 에이전트 시스템 (agent systems)을 다루기에는 이미 너무 단순합니다.

설정 방식에 따라 다음과 같은 요소들도 비용 동작 (cost behavior)에 영향을 미칠 수 있습니다:

  • 캐시된 토큰 (cached tokens)
  • 오디오 토큰 (audio tokens)
  • 이미지 토큰 (image tokens)
  • 재시도 (retries)
  • 도구 호출 루프 (tool-call loops)
  • 제공업체별 가격 계층 (provider-specific pricing tiers)
  • 모델 간의 라우팅 결정 (routing decisions between models)

이는 토큰 총량이 유사한 두 워크플로 (workflows)라 할지라도 실제 비용 프로필 (cost profiles)은 매우 다를 수 있음을 의미합니다.

그래서 누군가 "이번 주에 800만 토큰을 사용했습니다"라고 말하면, 저의 반응은 보통 이렇습니다. "알겠습니다, 그런데 돈이 실제로 어디에 쓰였나요?"

저는 차라리 다음과 같은 정보를 알고 싶습니다:

  • 댓글 중재 (comment moderation) 비용은 항목당 $0.004
  • 엔터프라이즈 지원 에스컬레이션 (enterprise support escalation) 비용은 인시던트당 $0.19
  • 인보이스 대조 (invoice reconciliation) 비용은 성공적인 실행당 $0.11

이것들이 바로 최적화 (optimize)할 수 있는 숫자들입니다.

모든 요청에 메타데이터 (metadata)를 전파하지 않는다면, 전체 시스템은 부패합니다

이 부분이 짜증 나는 지점입니다.

워크플로 수준의 귀속 (Workflow-level attribution)은 엔지니어들이 규율을 지킬 때만 작동합니다.

만약 하나의 서비스가 다음 항목들을 전달하는 것을 잊는다면:

  • workflow_id
  • channel
  • customer_id
  • stage

여러분의 차트 (charts)는 서서히 허구가 되어갑니다.

그렇기 때문에 저는 메타데이터 전파 (metadata propagation)를 '있으면 좋은 것'이 아니라 '계약 (contract)의 일부'로 취급해야 한다고 생각합니다.

제가 실제로 배포할 구성 방식

만약 제가 내일 당장 이를 구현해야 한다면, 다음과 같이 할 것입니다:

1. 하나의 주요 비용 단위 선택

다음 중 하나를 선택하세요:

  • 워크플로 실행 (workflow run)
  • 대화 (conversation)
  • 고객 상호작용 (customer interaction)
  • 자동화 실행 (automation execution)

주요 단위를 다섯 개나 선택하지 마세요.

2. 필수 메타데이터 필드 정의

예시:

{
  "workflow_id": "support_triage_v3",
  "customer_id": "acct_1284",
...

3. 미들웨어 (middleware)에서 강제 적용

이미 OpenAI 호환 레이어 (OpenAI-compatible layer)를 사용 중이라면, 이곳이 요청 형태 (request shape)를 강제하기에 좋은 장소입니다.

의사 코드 (Pseudo-code):

function assertCostMetadata(meta: Record<string, string>) {
  const required = [
    "workflow_id",
...

4. 워크플로 우선 집계, 모델은 그다음

이 순서가 중요합니다.

순서를 뒤집으면, 하나의 워크플로가 운영 환경 (production)에서 계속 폭발적으로 비용을 발생시키는 동안 모델 선택에서 몇 푼 아끼는 데 급급하게 됩니다.

5. 제공업체 대시보드 (provider dashboards)를 보조적인 관점으로 활용

유용한 경우:

  • 이상 탐지 (anomaly detection)
  • 제공업체 비교 (provider comparisons)
  • 조달 논의 (procurement discussions)
  • 잘못된 배포 포착 (catching bad deploys)

불충분한 경우:

  • 워크플로우 경제성 (workflow economics)
  • 채널별 귀속 (per-channel attribution)
  • 고객 수준 수익성 (customer-level profitability)

정액제 인프라가 더 합리적으로 느껴지기 시작하는 지점

이것이 바로 에이전트 팀들에게 정액제 AI 인프라 (flat-rate AI infrastructure)가 점점 더 흥미롭게 다가오는 이유이기도 합니다.

n8n, Make, Zapier, OpenClaw 또는 커스텀 워크플로우 (custom workflows)를 통해 에이전트가 24시간 내내 실행되기 시작하면, 토큰당 과금 (per-token billing) 방식은 기묘한 사고 모델을 형성하게 됩니다.

추가되는 모든 분기(branch), 재시도(retry), 또는 도구 호출(tool call)이 마치 재정적 리스크처럼 느껴지기 때문입니다.

이는 팀들을 방어적인 행동으로 내몹니다:

  • 토큰 과도 모니터링 (over-monitoring tokens)
  • 성급한 모델 다운그레이드 (prematurely downgrading models)
  • 비용 예측 불가능성으로 인한 유용한 자동화 기피
  • 더 낮은 비용 항목을 쫓기 위한 끊임없는 제공업체 교체

이것이 Standard Compute와 같은 제품들이 에이전트 빌더들에게 매력적인 이유 중 하나입니다.

만약 여러분의 스택이 이미 OpenAI API를 사용하고 있다면, 월정액 요금제를 제공하는 드롭인 교체(drop-in replacement) 방식은 최적화 문제의 성격을 완전히 바꿔 놓습니다.

모든 토큰에 집착하는 대신, 다음과 같은 사항에 집중할 수 있습니다:

  • 워크플로우당 비용 (cost per workflow)
  • 처리량 (throughput)
  • 지연 시간 (latency)
  • 신뢰성 (reliability)
  • 자동화를 실행할 가치가 있는지 여부

이것이 프로덕션 에이전트 (production agents)를 운영하는 더 건강한 방식입니다.

특히 여러분의 워크로드(workload)가 어차피 여러 모델과 도구에 걸쳐 있다면 더욱 그렇습니다.

마침내 깨달은 점

가장 짧게 요약하자면 이렇습니다.

프롬프트를 한 번 실행한다면, 모델 수준의 가격 책정 (model-level pricing)으로도 충분합니다.

하지만 에이전트를 실행한다면, 워크플로우당 비용 (cost per workflow)이 진짜 청구서입니다.

이것이 핵심적인 전환점입니다.

이 관점을 깨닫고 나면

오늘부터 모든 LLM 요청에 비즈니스 메타데이터 (business metadata)를 첨부하기 시작하세요.

최소한 다음과 같은 항목들이 포함되어야 합니다:

workflow_id
customer_id
channel
...

그다음, 모델당 비용 (cost per model)이 아닌 워크플로우당 비용 (cost per workflow)을 중심으로 리포팅 (reporting) 체계를 구축하세요.

이 단 한 번의 변화가 토큰 차트 (token charts)를 일주일 내내 쳐다보는 것보다 당신의 에이전트 시스템 (agent system)에 대해 더 많은 것을 알려줄 것입니다.

만약 당신의 팀이 토큰당 과금 방식 (per-token pricing) 자체에 지쳤다면, 모든 에이전트 실행이 예산 문제로 이어지지 않으면서도 기존의 OpenAI 호환 워크플로우 (OpenAI-compatible workflow)를 그대로 유지할 수 있게 해주는 인프라 (infrastructure)를 살펴보는 것도 가치가 있습니다.

그것이 바로 대부분의 팀이 실제로 원하는 부분입니다: 복잡한 과금 게임은 줄이고, 더 유용한 자동화 (automation)를 구현하는 것 말입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0