LLM을 위한 FinOps — 단위 경제성과 멀티 테넌트 비용 귀속(Unit Economics and Multi-Tenant Attribution)

전통적인 FinOps는 LLM 지출 앞에서 무너집니다. 비용은 자원의 가동 시간(resource-uptime)이 아니라 토큰 단위 거래(token-transaction)이고, 태그(tag)는 자산이 아니라 거래인 API 호출(API call)에 그대로 들러붙지 않습니다. 프롬프트 설계, 컨텍스트 윈도(context window), 출력 길이 같은 엔지니어링 결정 하나하나가 곧 재무적 결정이 됩니다. 2026년 플레이북(playbook)이 첫날부터 계측해야 한다고 말하는 비용 귀속(attribution) 축은 세 가지입니다. 좌석 요금제(seat pricing)와 확장 거래를 위한 사용자별(user_id) 귀속, 제품 표면(product surface)별 비용 산정과 우선순위 결정을 위한 작업별(task_id + route) 귀속, 단위 경제성(unit economics)과 갱신 협상을 위한 테넌트별(tenant_id) 귀속입니다. 토큰 계층(token layer)은 프롬프트(prompt), 도구(tool), 메모리(memory), 응답(response) 네 가지로 나뉘며, 하나의 버킷(bucket)에 합쳐 두면 지출이 어디서 새는지 보이지 않습니다. 멀티 테넌트(multi-tenant) 제품의 강제(enforcement) 사다리는 세 단계입니다. 예상 피크(peak)의 2-3배로 잡은 테넌트별 속도 제한(rate limit)으로 명확한 429 + Retry-After를 돌려주고, 계약 상한(contracted ceiling)의 1.5-3배로 잡은 일일 지출 상한(daily spend cap)으로 속도 제한 강화와 알림을 트리거하며, 지출 z-점수(z-score)가 4를 넘으면 킬 스위치(kill switch)로 자동 일시 정지(auto-pause)와 온콜(on-call) 호출을 발동합니다. 비용 귀속 패턴(attribution pattern)에는 태그 후 집계(tag-and-aggregate), 텔레메트리 조인(telemetry-joiner; trace-ID → 청구 데이터, 정확도 최상), 표본 추출과 외삽(sampling-and-extrapolation), 모델 기반 배분(model-based allocation), 이벤트 소싱(event-sourced), 실시간 스트리밍(real-time streaming)이 있습니다. 단위 지표(unit metric)는 백만 토큰당 달러($/M tokens)가 아니라 해결된 질의당 비용(cost per resolved query), 생성된 산출물당 비용(cost per generated artifact)이어야 합니다. 사후에 태깅(retroactive tagging)을 붙이면 반드시 새는 곳이 생기므로, 요청이 만들어지는 시점에 계측해야 합니다.

유형: Learn 언어: Python (stdlib, 킬 스위치가 포함된 토이 비용 귀속 시뮬레이터(toy cost-attribution simulator with kill switch)) 선수 지식: Phase 17 · 13 (관찰 가능성(Observability)), Phase 17 · 14 (캐싱(Caching)) 예상 시간: 약 60분

학습 목표

• 전통적인 FinOps(태그 + 요금 등급)가 LLM 지출 앞에서 무너지는 이유를 설명하고, 새롭게 필요한 세 가지 비용 귀속 축(per-user, per-task, per-tenant)을 말할 수 있습니다.
• 네 가지 토큰 계층(프롬프트, 도구, 메모리, 응답)을 열거하고, 단일 버킷 청구(single-bucket billing)가 비용을 가리는 이유를 설명할 수 있습니다.
• 멀티 테넌트 제품을 위한 강제 사다리(속도 제한 → 지출 상한 → 킬 스위치)를 설계할 수 있습니다.
• 백만 토큰당 달러 대신 해결된 질의당 비용, 산출물당 비용 같은 단위 지표를 고를 수 있습니다.

문제

청구서에는 $40,000라고 적혀 있는데, 다음 질문에는 답할 수 없습니다.

• 어느 테넌트(tenant)가 이 비용을 썼는지.
• 어떤 제품 기능이 비용을 끌어올렸는지.
• 특정 사용자(user)가 남용(abuse)했는지.
• 프롬프트 비대화(prompt bloat), 도구 호출(tool call), 메모리 증폭(memory amplification) 중 무엇이 진짜 원인이었는지.

공급자(provider) 쪽에서 태그를 붙이고 나중에 집계(tag-and-aggregate)하는 방식은 EC2, S3 같은 클라우드 자원에는 잘 맞습니다. 태그가 청구 라인 아이템(line item)까지 그대로 따라가기 때문입니다. 그러나 LLM API 호출은 자동으로 태그가 붙지 않습니다. 호출이 일어나는 코드 지점(call site)에서 직접 user/task/tenant를 도장 찍어(stamp) 끝까지 들고 가야 합니다. 사후에 비용을 귀속(retroactive attribution)시키려고 하면 경계 사례(edge case)는 항상 새어 나갑니다.

개념

세 가지 비용 귀속 축(attribution dimension)

사용자별(Per-user)(user_id): 누가 비용을 만드는지를 본다. 좌석 요금제(seat pricing), 확장(expansion) 거래 협상, 파워 유저(power user) 식별에 쓰인다.

작업별(Per-task)(task_id + route): 어느 제품 표면(product surface)이 비용을 얼마나 만드는지를 본다. 기능 우선순위 결정과 "비싼 기능을 죽일지 말지"를 가르는 판단에 쓰인다.

테넌트별(Per-tenant)(tenant_id): 어떤 고객이 수익성 있는지를 본다. 단위 경제성, 갱신 가격, 요금 등급(tier) 기준선을 정하는 데 쓰인다.

세 축 모두 첫날부터 호출이 일어나는 자리에서 계측해야 합니다. 사후에 붙이는 방식은 언제나 더 나쁩니다.

네 가지 토큰 계층(token layer)

네 계층을 하나의 버킷으로 묶어 두면 어디서 절감해야 할지 보이지 않습니다. 비용 귀속 스키마(attribution schema) 단계에서 분리해 두어야 합니다.

강제 사다리(enforcement ladder)

1. 테넌트별 속도 제한(Rate limit). 예상 피크의 2-3배로 잡습니다. Retry-After 헤더가 포함된 429 응답을 돌려줍니다. 테넌트는 약간의 마찰(friction)을 느끼지만 깜짝 청구서(surprise bill)는 없습니다.

2. 테넌트별 일일 지출 상한(Daily spend cap). 계약 상한의 1.5-3배로 잡습니다. 트리거 시 속도 제한을 더 조이고(tighten), 고객 성공(customer-success; CS) 팀에 알립니다.

3. 킬 스위치(Kill switch). 테넌트 기준선(baseline) 대비 지출 z-점수가 4를 넘으면 발동합니다. 테넌트를 자동으로 일시 정지(auto-pause)시키고, 온콜(on-call) 담당자를 호출(page)하며, 운영(ops)과 CS로 에스컬레이션합니다.

비용 귀속 패턴(attribution pattern)

• 태그 후 집계(Tag-and-aggregate): 메타데이터 헤더(metadata header)에 식별자를 도장 찍어 두고 나중에 집계합니다. 단순하지만 거칠게(rough) 잡힙니다.
• 텔레메트리 조인(Telemetry joiner): 추적 ID(trace ID)로 트레이스와 청구 데이터를 조인(join)합니다. 정확도가 가장 높고, 성숙한 팀(mature team)이 실제로 쓰는 방식입니다.
• 표본 추출 + 외삽(Sampling + extrapolation): 5-10%만 표본으로 뽑아 곱합니다. 대략적인 지출 파악에는 비용 효율적이지만 꼬리(tail)는 놓칩니다.
• 모델 기반 배분(Model-based allocation): 회귀(regression)로 비용 동인(cost driver)을 추정합니다. 태그가 없는 레거시(legacy) 데이터에 씁니다.
• 이벤트 소싱(Event-sourced): 비용을 스트림(Kafka / Kinesis)의 이벤트로 다룹니다. 실시간입니다.
• 실시간 스트리밍(Real-time streaming): 대시보드(dashboard)가 1초 이하로(sub-second) 업데이트됩니다.

단위 지표는 "X당 비용(Cost per X)"이다

백만 토큰당 달러($/M tokens)는 벤더(vendor)의 언어입니다. 제품 지표(product metric)는 다음과 같아야 합니다.

• 해결된 지원 티켓(resolved support ticket)당 비용.
• 생성된 기사(generated article)당 비용.
• 성공한 에이전트 작업(successful agent task)당 비용.
• 사용자 세션 분(user-session-minute)당 비용.

비용을 제품 결과(product outcome)에 묶어야 합니다. 그렇지 않으면 최적화가 기준점 없이 떠다닙니다.

비용 귀속 추적의 형태(cost attribution trace shape)

trace_id: abc123
  user_id: u_42
  tenant_id: t_7
  task_id: task_classify_doc
  route: model_haiku
  layers:
    prompt_tokens: 1800
    tool_tokens: 600
    memory_tokens: 400
    response_tokens: 150
  cost_usd: 0.0135
  cached_input: true
  batch: false

모든 호출에서 이 형태로 방출(emit)합니다. 데이터 레이크(data lake)에 저장하고, 축별로 집계합니다. 이 정보가 사는 곳은 Phase 17 · 13에서 다룬 관찰 가능성(observability) 스택입니다.

누적되는 절감 스택(compounded-savings stack)

스택 구성: 캐시(cache) + 배치(batch) + 라우팅(route) + 게이트웨이(gateway). 네 가지를 모두 켜면 다음과 같이 비용이 줄어듭니다.

• L2 캐시(Cache L2, Phase 17 · 14): 입력 비용이 약 10배 저렴해집니다.
• 배치(Batch, Phase 17 · 15): 50% 할인.
• 저렴한 모델로 라우팅(Route to cheap model, Phase 17 · 16): 비용 60% 절감.
• 게이트웨이 효율(Gateway efficiency, Phase 17 · 19): 이중화(redundancy) + 재시도(retry).

네 가지를 모두 쌓은 최선의 경우(best-case stacked)는 단순한 기준선(naive baseline)의 약 5-10% 수준입니다. 대부분의 팀은 두세 개의 레버(lever)만 당기고 있고, 네 가지를 모두 쌓는 팀은 드뭅니다.

꼭 기억해야 할 숫자

• 비용 귀속 축: 사용자별(per-user), 작업별(per-task), 테넌트별(per-tenant).
• 네 가지 토큰 계층: 프롬프트, 도구, 메모리, 응답.
• 킬 스위치 발동 기준: 지출 z-점수 > 4.
• 단위 지표: 백만 토큰당 달러가 아니라 해결된 질의당 비용.
• 누적 최적화(stacked optimization): 기준선의 약 5-10% 수준까지 가능.

사용해보기

code/main.py는 세 단계 강제 사다리(three-tier enforcement ladder)를 갖춘 멀티 테넌트 LLM 서비스를 시뮬레이션합니다. 남용 성향의 테넌트(abusive tenant)를 주입(inject)해 두고, 킬 스위치가 실제로 발동되는 것을 보여줍니다.

산출물 만들기

이 강의는 outputs/skill-finops-plan.md를 만듭니다. 제품과 규모(scale)가 주어지면 비용 귀속 스키마와 강제 사다리를 설계합니다.

연습문제

1. 쉬움: code/main.py를 실행합니다. 어느 z-점수에서 킬 스위치가 발동합니까? 그 임계값(threshold)은 어떻게 고르시겠습니까?
2. 중간: 테넌트별, 작업별 비용 대시보드(per-tenant, per-task cost dashboard)를 설계합니다. 가장 먼저 만들 다섯 개의 뷰(view)는 무엇입니까?
3. 중간: 가장 큰 테넌트가 단위 경제성 기준으로 적자(unit-economics-negative)입니다. 고객 영향이 작은 순서로 개입(intervention) 세 가지를 제안합니다.
4. 어려움: 지원 제품의 해결된 티켓당 비용(cost per resolved ticket)을 계산합니다. 티켓 한 건당 3M 토큰, 하루 약 800건, GPT-5 캐시 적용(cached) 단가를 가정합니다.
5. 어려움: 사후 태깅(retroactive tagging)이 작동할 수 있는지 논합니다. 언제는 받아들일 만(acceptable)합니까?

핵심 용어

더 읽을거리

• FinOps Foundation — FinOps for AI Overview — 2026년 FinOps 재단의 AI 워킹 그룹 개요.
• FinOps School — Cost per Unit 2026 Guide — 단위 비용 지표 설계 가이드.
• Digital Applied — LLM Agent Cost Attribution 2026 — 프로덕션 LLM 에이전트 비용 귀속 사례.
• PointFive — Managed LLMs in Azure OpenAI — 관리형 LLM 경제성 분석.