토큰과 클라우드 비용 사이의 누락된 지표

문제는 AI 팀이 비용 데이터를 부족해 하는 것이 아니라, 토큰 대시보드와 클라우드 청구서가 서로 다른 시스템을 설명하고 있으며, 서로 다른 팀이 소유하고 있어 이를 연결할 신뢰할 만한 방법이 없다는 점이다.

지원 담당자는 모델 호출 5회, 검색 단계, 도구 호출 2회, 재시도 등을 거쳐 하나의 티켓을 해결할 수 있다. 비즈니스는 하나의 완료된 사례를 기록하고, 인프라스트럭처는 요청, 파드, 메모리, 가속기 사용 시간 및 공유 서비스의 산재를 기록한다. 이 기록들이 맞물리기 전까지 비용 최적화는 부분적으로 추측에 의존한다.

왜 토큰 메트릭과 클라우드 청구서는 서로 다른 이야기를 하는가?

토큰 수는 유용하다. 모델이 받은 및 반환한 텍스트 양을 보여주며, 팀이 프롬프트, 모델, 라우팅 선택을 비교하는 데 도움을 준다. 그러나 모델 호출 주변에 무슨 일이 일었는지, 검색 및 도구 사용을 지원한 컴퓨팅 양, 먼저 발생한 실패 시도 횟수, 최종 결과가 실제로 유용했는지는 알려주지 않는다.

The State of FinOps 2026은 AI가 일반 FinOps 업무에 얼마나 빠르게 진입했는지를 보여준다: 응답자의 98%가 현재 AI 비용을 관리하고 있으며, 2025년에는 63%였다. 그러나 예산 항목이 커졌다고 해서 어느 워크플로우가 비용을 소모했는지 또는 그 이유를 알려주지는 않는다. 

두 개의 문서 처리 작업은 대략 동일한 토큰 수를 사용할 수 있다. 하나는 단일 모델 요청으로 끝날 수 있지만, 다른 하나는 여러 저장소에서 컨텍스트를 검색하고 외부 서비스를 호출하며, 다른 모델로 대체하고, 사용자가 보지 못하는 실패한 검증 검사를 통과한 후 문서를 다시 실행할 수 있다. 토큰 총량은 비슷해 보이지만 실행 경로는 다르다.

Unite.ai는 이미 왜 token counts don’t automatically represent business value를 조사했다. 다음 단계는 해당 토큰 수를 이를 생성한 워크로드와 연결하는 것이다. 그렇지 않으면 팀은 토큰당 비용을 개선하면서 완료된 작업당 비용을 악화시킬 수 있다.

완전한 비용 체인은 어떻게 보이는가?

유용한 비용 체인은 비즈니스가 중요하게 여기는 결과에서 시작한다. 이는 해결된 지원 사례, 처리된 문서, 승인된 코드 변경, 혹은 완료된 에이전트 워크플로우일 수 있다. 그 아래 모든 요소는 시스템을 통해 추적할 수 있는 식별자를 필요로 한다.

애플리케이션 레이어가 첫 연결을 제공한다. 요청 ID, 트레이스 ID, 워크플로우 이름 또는 대화 ID는 여러 모델 및 도구 작업을 하나의 작업에 연결할 수 있다. 이 흐름이 없으면 관련된 열 이벤트가 서로 무관한 청구처럼 보인다.

The OpenTelemetry conventions for GenAI agents는 이 레이어를 위한 새로운 어휘를 제공한다. 여기에는 작업, 제공자, 요청된 모델, 에이전트, 대화, 토큰 사용량, 도구 실행, 오류 및 워크플로우가 포함된다. 이 컨벤션은 아직 개발 중으로 표시되어 있어 팀이 완성된 보편 표준으로 간주해서는 안 된다. 연관성 문제를 구체화하는 데 유용하다.

Then comes infrastructure. AWS’s split cost allocation data for EKS는 공유 컴퓨팅 및 메모리 비용을 Kubernetes 파드에 할당하고 클러스터, 네임스페이스, 배포, 노드, 워크로드 이름 및 유형과 같은 세부 정보를 노출한다. 지원되는 가속 인스턴스에 대해서는 데이터가 GPU, Trainium 및 Inferentia 예약도 포함한다.

That’s the other half of the chain. A trace can explain what the application tried to do; Kubernetes allocation can show which resources carried the work. Unite.ai’s guide to deploying and monitoring LLMs on Kubernetes는 리소스 할당, 확장 및 가시성을 포함한 보다 넓은 프로덕션 컨텍스트를 제공한다.

The join won’t happen by accident. Teams need a stable identifier that survives long enough to connect application telemetry with workload labels, allocation records, or another mapping layer. Customer data doesn’t belong in Kubernetes tags. Teams should decide which low-cardinality identifiers can safely connect a workflow category, service, or feature to the resources it consumed.

Once that application context is in place, teams can start tracking Kubernetes costs by workload and connect namespace, CPU, memory, and GPU usage back to the work being performed. This still doesn’t tell you whether the workflow created business value, but it gives the infrastructure side of the calculation something concrete to attach to. 

비즈니스가 신뢰해야 할 단위 메트릭은 무엇인가?

모든 팀이 사용해야 할 단일 AI 비용 메트릭은 존재하지 않는다. 토큰당 비용은 모델 소비에 대한 질문에 답하고, 파드당 비용은 인프라 할당에 대한 질문에 답한다. 어느 것도 제품 소유자에게 해당 기능이 비용 대비 가치를 창출하고 있는지는 알려주지 않는다.

가장 좋은 분모는 보통 비즈니스가 명확히 정의할 수 있고 제품 팀이 영향을 미칠 수 있는 가장 작은 결과이다. 지원 운영은 해결된 사례당 비용을 추적할 수 있고, 문서 시스템은 성공적으로 처리된 파일당 비용을 사용할 수 있으며, 코딩 어시스턴트는 제안당 비용이 아니라 승인된 변경당 비용을 검토할 수 있다.

Success changes the math.

시도당 비용이 낮은 워크플로우라도 실패가 잦고, 반복 검증을 유발하거나 인간 검토에 너무 많은 사례를 보내면 비용이 많이 들 수 있다. 따라서 팀은 시도당 비용과 완료당 비용을 구분하고, 가능하면 승인된 결과당 비용을 별도 계산해야 한다. 마지막 수치는 시스템이 생성했지만 비즈니스가 활용하지 못한 작업을 포함하기 때문에 가장 유용한 경우가 많다.

Agent systems make this harder because their paths can change from one run to the next. Unite.ai’s analysis of the economics of scaling agentic AI workloads는 라우팅, 도구 호출, 재시도 및 워크플로우 수준의 귀속을 다룬다. 이러한 행동은 최종 사용자가 하나의 답변만 보더라도 자원을 소비할 때 단위 메트릭에 포함되어야 한다.

The metric still won’t be perfect. Shared services, cached results, batch jobs, and delayed processing can blur attribution. A decision-useful estimate is better than false precision, especially when it tells engineers which layer deserves investigation.

숫자는 누가 소유하는가?

가장 어려운 부분은 조직적 측면일 수 있다. ML 팀은 모델 호출 및 평가를 이해하고, 플랫폼 팀은 워크로드와 클러스터 동작을 이해하며, FinOps는 청구 데이터와 할당 규칙을 이해한다. 제품 팀은 어떤 결과가 중요한지 안다.

No one team owns the full chain.

이는 어느 대시보드가 올바른지에 대한 예측 가능한 논쟁을 만든다. ML 팀은 토큰 사용량 감소를 지적할 수 있고, 플랫폼 팀은 GPU 사용 시간이 증가했으며, 제품 팀은 이전보다 완료된 작업이 감소했음을 본다. 세 관찰은 동시에 모두 사실일 수 있다. 공유 메트릭은 이들 사이의 관계를 설명해야 한다.

실용적인 시작점은 명확한 완료 이벤트가 있는 하나의 프로덕션 워크플로우이다. 안정적인 식별자를 부여하고, 해당 컨텍스트를 모델 및 도구 트레이스에 전달하여 Kubernetes에서 실행 중인 서비스 또는 워크로드에 매핑하고, 하나의 비즈니스 분모를 선택한다. 그런 다음 숫자가 예상치 못하게 변할 때 팀을 모아야 한다.

그 검토는 다듬어진 대시보드보다 더 중요하다. 갑작스러운 증가 요인은 더 긴 프롬프트, 새로운 대체 경로, 미사용 GPU 용량, 변경된 자동 스케일링 정책, 혹은 AI 기능을 통해 더 많은 작업을 보내는 제품 결정일 수 있다. 각 원인은 다른 소유자에게 속한다.

Automation should come later. A recommendation engine can only act on the labels and thresholds it receives, and a bad denominator can make an efficient system look wasteful or reward a cheap workflow that users reject. Teams need enough shared visibility to distinguish model behavior from application design and infrastructure allocation before they let a system act on the result. Otherwise, an automated cost fix can reduce capacity, raise latency, and move the expense somewhere less visible.

비용 체인은 공유되어야 한다

각 팀이 자신이 볼 수 있는 레이어만 최적화하는 한 AI 비용 관리는 계속 단편화될 것이다. 토큰, 트레이스, 파드, 가속기 및 청구서는 경쟁 관계의 측정이 아니라 동일한 비용 체인의 조각이다.

이를 연결하는 기업들은 첫날에 완벽한 수치를 얻지는 못한다. 중요한 것은 팀이 높은 청구서를 초래한 워크플로우로 추적하고, 무엇이 변했는지 파악한 뒤, 그 결과가 비용을 정당화했는지 판단할 수 있는가이다.