월 클라우드 청구액이 3,000만 원에서 4,000만 원으로 늘었다는 사실만으로 비용 효율이 나빠졌다고 말할 수는 없다. 같은 기간 주문이 두 배로 늘었다면 주문 한 건을 처리하는 비용은 오히려 낮아졌을 수 있다. 반대로 청구액은 그대로인데 활성 고객이나 처리 작업 수가 줄었다면 비용 구조는 악화됐을 가능성이 크다.
월 Cloud Bill은 비용의 총량만 보여준다. 제품이 성장할 때 비용이 어떤 속도로 늘어나는지 이해하려면 비용을 고객·주문·거래·작업 같은 Value Metric으로 나눠야 한다.
가장 단순한 형태는 다음과 같다.
클라우드 단위 비용
= 같은 기간·같은 범위에 포함한 클라우드 비용
÷ 같은 기간·같은 범위에서 발생한 유효 가치 단위가정:
비용과 가치 단위가 동일한 제품·기간·환경을 가리킨다.
비용 Currency와 환율 기준이 일치한다.
성공·중복·취소 조건을 적용한 유효 단위만 분모에 포함한다.
제외:
회계상 매출원가나 영업비용 전체
범위가 다른 제품·기간의 비용
정의되지 않은 테스트·재시도·내부 사용량
식은 간단하지만 실제 작업은 분자와 분모를 정의하는 데 있다. FinOps Foundation도 모든 조직에 적용되는 하나의 Unit Metric은 없으며 Metric은 가능한 한 사용자의 실제 Workflow와 가까워야 한다고 설명한다.
먼저 무엇을 한 단위로 볼지 정한다
고객당 비용이 항상 가장 좋은 Metric은 아니다. 고객마다 사용량 차이가 큰 B2B SaaS에서 고객 수만 분모로 사용하면 대형 고객과 소형 고객의 비용 차이가 사라진다. 주문당 비용도 주문 완료 전 발생한 검색·장바구니·결제 실패 비용을 어떻게 다룰지 정하지 않으면 해석하기 어렵다.
Value Metric은 현재 내려야 할 결정에서 출발해야 한다.
| 사업·업무 | Value Metric 후보 | 성공 단위의 예 | 함께 봐야 할 보조 지표 |
|---|---|---|---|
| 구독형 SaaS | 활성 고객, 활성 Tenant, 성공한 핵심 Workflow | 해당 월에 핵심 기능을 실제 사용한 유료 Tenant | Tenant별 작업 수, 저장량, 사용자 수 |
| 커머스 | 결제 완료 주문, 출고 완료 주문, 거래액 | 중복·취소를 제외한 출고 완료 주문 | 주문당 품목 수, 반품률, 트래픽 |
| 결제·핀테크 | 승인 거래, 정산 거래, 성공 거래 | 시스템 책임 범위에 맞는 성공 거래 | 승인 실패, 재시도, 거래 금액 구간 |
| 데이터 플랫폼 | 완료된 Job, 처리한 GB, 성공한 Query | 오류 없이 종료한 Production Job | Scan Byte, CPU Time, 지연시간 |
| 업무 자동화 | 완료된 업무, 처리된 문서, 해결된 Case | 사람이 다시 처리하지 않아도 되는 완료 작업 | 예외·재작업·Human Review 비율 |
| AI 서비스 | 수용된 응답, 완료된 Agent Action, 해결된 Case | 품질 조건을 충족해 사용된 결과 | Token, Model Call, Retry, Tool Call |
Token당 비용이나 GB당 비용은 엔지니어링 최적화에 유용한 Resource Efficiency Unit Metric이다. 고객당·거래당·해결된 Case당 비용은 제품과 경영 판단에 가까운 Business Unit Metric이다. AI도 초기에는 Token당 비용을 보더라도, 궁극적으로는 수용된 결과나 완료된 작업당 비용으로 확장하는 편이 실제 가치와 가깝다.
Metric Contract를 먼저 작성한다
Value Metric을 정할 때는 이름보다 계산 계약이 중요하다.
YAML
metric_id: ORDER_FULFILLED_V1
decision_question: 주문 증가에 따라 인프라 비용이 효율적으로 확장되는가
scope: commerce-product-a / production / KR
denominator_name: 출고 완료 주문
business_event: order_fulfilled
success_condition: fulfillment_status = completed
dedupe_key: order_id
denominator_exclusions:
- 취소 주문
- 테스트 주문
- 중복 Event
- 내부 운영 계정
- Fraud로 확정된 주문
period: calendar_month
timezone: Asia/Seoul
late_event_policy: 다음 월 3영업일까지 이전 기간 재산정
owner:
business_definition: Product
event_quality: Data Engineering
cost_definition: FinOps 또는 Platform유효 가치 단위 = 성공 조건을 충족한 고유 Business Event 수
가정:
dedupe_key가 동일한 단위를 안정적으로 식별한다.
Event의 성공 상태가 기간 종료 후 확정된다.
늦게 도착한 Event를 재산정하는 정책이 있다.
제외:
단순 API 호출 수
자동 재시도
중복 메시지
테스트와 내부 Traffic
성공 여부를 아직 확정할 수 없는 Event
분모 정의가 바뀌면 과거 값도 같은 버전으로 다시 계산하거나, Metric Version을 분리해야 한다.
청구서 금액과 운영 비용 기준을 분리한다
2026년 8월 22일 기준 최신 FOCUS Specification은 1.4다. FOCUS는 공급자마다 다른 Billing Data의 용어와 Schema를 정규화한다. 현재 네 개 Dataset을 정의하지만 단위 비용 계산의 중심은 Cost and Usage Dataset이다.
단위 비용의 Numerator에는 보통 두 가지 관점이 있다.
BilledCost
실제 Invoice와 맞춰 보기 위한 비용이다. 청구서 검증, 지급액, 월별 현금 지출을 설명할 때 적합하다.
EffectiveCost
리소스가 사용되거나 약정 비용이 소비된 시점에 맞춰 비용을 배분한 값이다. 선결제·약정 비용을 실제 사용 Row에 반영할 수 있어 제품별 비용 배부와 소비 추세 분석에 더 적합하다.
이 글의 기본 규칙은 다음과 같다.
| 분석 목적 | Cost Metric | Period 기준 |
|---|---|---|
| 제품·서비스의 운영 단위 비용 | EffectiveCost | ChargePeriodStart/End |
| Invoice·지급액 정합 | BilledCost | BillingPeriodStart/End |
| Commitment·Unused 분석 | EffectiveCost와 Commitment 상태 | Charge Period |
| 회계 보고 | Finance가 승인한 별도 Mapping | 회계 정책에 따름 |
EffectiveCost를 사용한다고 해서 그 값이 자동으로 재무제표의 발생주의 비용이나 매출원가가 되는 것은 아니다. FOCUS는 운영·Billing 분석을 위한 표준이며 기업의 회계 정책을 정하지 않는다.
또한 최신 FOCUS Version과 실제 CSP Export Version은 구분해야 한다. 현재 공식 Adoption 정보에서는 AWS·Azure·Google Cloud가 주로 FOCUS 1.2 수준을 지원한다. 내부 Data Model에는 다음 값을 반드시 보존하는 편이 안전하다.
YAML
source_provider:
source_export_name:
source_focus_version:
ingested_at:
charge_period_start:
charge_period_end:
billing_period_start:
billing_period_end:
billed_cost:
effective_cost:
billing_currency:
service_category:
service_name:
resource_id:
sub_account_id:
region:
tags:
allocated_method_id:
allocated_resource_id:FOCUS 1.4를 내부 Canonical Schema의 목표로 사용할 수는 있지만 원본에 존재하지 않는 1.4 Field를 이미 수집한 것처럼 채워서는 안 된다.
비용을 Direct·Shared·Idle·Unallocated로 나눈다
비용 Row를 분류할 때는 두 축을 섞지 않는 것이 중요하다.
첫 번째 축은 누구에게 귀속되는가다.
Direct
Shared
Idle
Unallocated
Excluded
두 번째 축은 어떤 종류의 기술 비용인가다.
Compute
Storage
Data·Network
Database
AI·Accelerator
Observability·Security
기타 Platform
예를 들어 Database 비용은 Direct일 수도 있고 Shared일 수도 있다. AI API 비용도 특정 고객 요청과 직접 연결될 수 있고 여러 제품이 함께 사용하는 공통 Model Endpoint 비용일 수도 있다.
Database·Network·AI를 Direct·Shared 비용에 추가로 더하는 식으로 계산하면 같은 비용이 두 번 포함될 수 있다. 각 비용 Row는 귀속 상태 하나와 기술 범주 하나를 가져야 한다.
| 귀속 상태 | 정의 | 예 | 기본 처리 |
|---|---|---|---|
| Direct Cost | 특정 제품·Tenant·주문·작업에 직접 연결할 수 있는 비용 | 전용 DB, Tenant별 Storage, Event ID가 있는 Model Call | 해당 대상에 직접 귀속 |
| Shared Cost | 여러 제품이나 고객이 함께 소비하는 비용 | 공용 Cluster, Load Balancer, Shared DB, Logging | 사용량 또는 Proxy로 배부 |
| Idle Cost | 비용은 발생했지만 현재 가치 단위 처리에 사용되지 않은 용량 | 미사용 약정, 빈 Node, Orphan Resource | 별도 Pool로 표시한 뒤 정책 결정 |
| Unallocated Cost | Owner·제품·배부키가 없어 귀속하지 못한 비용 | Tag 누락, 미확인 Account, Mapping 실패 | 숨기지 않고 비율과 금액 공개 |
| Excluded Cost | 이 Metric의 목적상 의도적으로 제외한 비용 | Tax, 직원 SaaS, Migration 일회성 비용 | 제외 이유와 별도 합계 기록 |
분석 범위의 총비용 = Direct + Shared + Idle + Unallocated + Excluded
가정:
각 비용 Row는 귀속 상태 하나에만 포함된다.
모든 금액은 같은 기간·Currency·Cost View를 사용한다.
Credit·Refund·Correction이 같은 정책으로 반영돼 있다.
제외:
Billing Export 밖에 존재하는 인건비·결제 수수료·감가상각
아직 수집되지 않은 다른 Vendor 비용
다른 제품이나 환경의 비용
이 식은 Billing Data가 손실되지 않았는지 확인하는 Reconciliation 식이다. 단위 비용 분자에 모든 항목을 자동으로 넣으라는 뜻은 아니다.
귀속 단위 비용과 정합 단위 비용을 나눠서 본다
배부 가능한 비용만 포함한 값과 미배부 비용까지 정책적으로 분산한 값을 하나로 섞지 않는 편이 좋다.
귀속 비용 = Direct Cost + Allocated Shared Cost + Included Idle Cost 귀속 단위 비용 = 귀속 비용 ÷ 유효 가치 단위
가정:
공유비와 유휴비의 포함 정책이 문서화돼 있다.
비용과 가치 단위의 Scope가 같다.
분모가 0인 기간은 계산하지 않고 별도 상태로 표시한다.
제외:
아직 배부 기준이 없는 Unallocated Cost
명시적으로 제외한 비용
회계상 COGS에만 포함되는 비클라우드 비용
귀속 단위 비용은 제품·엔지니어링 팀이 현재 설명할 수 있는 비용을 보여준다.
미배부 비용은 다음 비율로 따로 관리한다.
미배부율 = Unallocated EffectiveCost ÷ 분석 범위의 Total EffectiveCost
가정:
분자와 분모가 같은 Cost View와 Scope를 사용한다.
Excluded Cost는 Total EffectiveCost 분모에서 제외한다.
Tag·Owner Mapping 실패를 Unallocated로 일관되게 분류한다.
제외:
정책적으로 중앙 예산에 남기기로 한 Shared Cost
Invoice에만 존재하는 Tax
Billing Export 외부 비용
FinOps Foundation도 분류·배부할 수 없는 비용의 비율을 Cost Allocation KPI로 관리하도록 제시한다.
모든 비용을 제품별로 합산해야 하는 보고서가 필요하다면 별도의 정합 값을 만든다.
정합 단위 비용
= (귀속 비용 + 정책상 배부한 Unallocated Cost)
÷ 유효 가치 단위가정:
Unallocated Cost의 배부 결정과 책임자가 기록돼 있다.
배부 전후 전체 금액이 일치한다.
과거 기간에도 같은 정책을 적용하거나 Version을 분리한다.
제외:
원인을 모른 채 임의로 균등 분배한 비용
다른 조직·제품의 비용
Excluded Cost
귀속 단위 비용과 정합 단위 비용을 함께 보여주면 비용 효율과 Allocation Data Quality를 분리해서 볼 수 있다.
Shared Cost는 편한 기준보다 원인에 가까운 기준으로 배부한다
Shared Cost의 기본 배부식은 다음과 같다.
대상별 Shared Cost 배부액
= Shared Cost Pool× 대상의 Allocation Key ÷ 모든 대상의 Allocation Key 합
가정:
Allocation Key가 실제 비용 발생과 합리적으로 연결된다.
모든 대상의 Key가 같은 기간과 단위로 수집된다.
한 Shared Pool의 전체 배부 비율 합이 100%다.
제외:
Key가 존재하지 않는 대상
수집 누락이 큰 기간
배부해도 의사결정 가치가 거의 없는 중앙 공통비
FinOps Foundation은 Account·Project·Tag 같은 Billing Metadata 외에도 CMDB, Observability, Utilization Data를 활용해 공유비를 더 세밀하게 배부할 수 있다고 설명한다. 고정 비율, 비례 배부, Proxy 방식이나 중앙 예산 유지도 Shared Cost별로 선택할 수 있다.
| Cost Pool | 우선 고려할 Allocation Key | 피해야 할 단순화 |
|---|---|---|
| 공용 Compute·Container | CPU-seconds, Memory GB-seconds, Request Runtime | Request 수만 균등 적용 |
| Shared Database | Query CPU, I/O Byte, Storage Byte-month, Query Runtime | Connection 수만 사용 |
| Network·Data Transfer | 전송 Byte, Source-Destination 경로, Request 수 | 전체 Cloud Spend 비율만 사용 |
| Object Storage | GB-month, Read·Write Operation, Retrieval Byte | 파일 개수만 사용 |
| Logging·Tracing | Log Ingest Byte, Span 수, Metric Cardinality | 서비스 개수 균등 배부 |
| Shared Security | 보호 대상 Request, Host, Endpoint, Traffic | 전체 제품 균등 배부 |
| Managed AI API | Model별 Input·Output·Cached Token, Call, Retry | API Call 수만 사용 |
| GPU·Accelerator | Accelerator-seconds, Allocated Memory, Batch Runtime | Job 수만 균등 적용 |
| 공통 Support·Platform | 직접비 비율, 활성 Workload, 합의된 고정 비율 | 근거 없는 임의 비율 |
Data·Network Cost
Network 비용은 단순히 전송량만 보면 부족할 수 있다. Internet Egress, 리전 간 이동, 가용영역 간 이동, NAT·Gateway Processing, CDN Origin Transfer처럼 경로에 따라 비용이 달라질 수 있기 때문이다.
가능하면 다음 Grain을 남긴다.
YAML
source_scope:
destination_scope:
traffic_class:
bytes_transferred:
request_count:
transfer_cost:
processing_cost:
business_event_id:주문·거래와 직접 연결할 수 없는 대량 Batch나 Replication Traffic은 주문 수로 나누기보다 해당 Job이나 데이터 제품에 먼저 귀속해야 한다.
Database Cost
Tenant 전용 Database는 Direct Cost로 처리하기 쉽다. Shared Database는 Query 수만으로 나누면 가벼운 조회와 대규모 Scan이 같은 비용을 소비한 것처럼 보일 수 있다.
가능하면 Query Runtime, CPU, Read·Write I/O, Storage, Backup, Replica 사용량을 조합한다. 관측 비용이 배부 정확도보다 커진다면 주요 비용 Driver만 선택하고 그 한계를 기록한다.
AI·Accelerator Cost
Managed Model API에서는 Model, Input Token, Output Token, Cached Token, Retry와 Batch 여부가 비용 Driver가 될 수 있다. 자체 GPU에서는 Accelerator 점유 시간, 실제 연산 시간, Memory 할당, Batch Throughput과 유휴 시간을 나눠야 한다.
AI 기능의 전체 단위 비용에는 Model Call만 넣지 않는다. 해당 업무에 필요한 Embedding, Vector Database, Retrieval, Tool Call, Moderation, Logging과 재시도 비용도 범위에 따라 포함해야 한다.
다만 Token은 자원 소비 단위다. 최종 Business Metric은 성공한 상담, 수용된 문서, 완료된 Agent Action처럼 결과에 가까운 단위를 함께 두는 편이 낫다.
Idle Cost를 모두 낭비라고 부르지 않는다
사용되지 않은 용량이 모두 제거 대상은 아니다.
장애나 Traffic Burst를 견디기 위한 Headroom
복구를 위한 Warm Standby
약정 사용량 중 실제로 쓰지 못한 부분
Scale-out 최소 Node
개발·검증 환경의 기본 용량
Owner가 사라진 Orphan Resource
이 중 Headroom과 Warm Standby는 Reliability 요구사항 때문에 발생한 계획된 비용일 수 있다. 반면 미사용 약정이나 Orphan Resource는 별도의 개선 대상으로 볼 수 있다. FOCUS는 CommitmentDiscountStatus = Unused 같은 상태를 활용해 사용하지 못한 약정 비용을 식별할 수 있도록 한다.
Idle Cost에는 세 가지 정책 중 하나를 적용할 수 있다.
| 정책 | 적합한 상황 | 표시 방법 |
|---|---|---|
| 제품 귀속 | 해당 제품의 신뢰성·복구 요구 때문에 확보한 용량 | Included Idle Cost |
| 중앙 효율 Pool | 여러 제품이 공동으로 책임져야 하는 미사용 약정 | 별도 Idle KPI |
| 원인 Owner 귀속 | 특정 Team·제품의 과다 Provisioning이 명확함 | 해당 대상에 배부 |
정책을 정하지 못한 Idle Cost를 조용히 주문이나 고객 수에 나누면 실제 제품 효율과 조직의 구매·용량 계획 문제가 섞인다.
Fixed·Variable·Step-fixed를 구분한다
클라우드가 사용량 기반 과금이라고 해서 모든 비용이 완전한 Variable Cost인 것은 아니다.
Variable Cost: 요청, 실행 시간, 전송량, Token처럼 단위 증가에 비교적 연속적으로 반응
Step-fixed Cost: DB Instance, 최소 Node, 전용 Cluster처럼 일정 구간까지 고정되고 임계점에서 증가
Period-fixed Cost: 해당 기간의 기본 지원료나 고정 Platform 비용
One-time Cost: Migration, 초기 Backfill, 대규모 Reindex처럼 반복되지 않는 비용
Variable Unit Cost
= Variable Cost
÷ 유효 가치 단위Fixed Cost Absorption = (Period-fixed Cost + Step-fixed Cost) ÷ 유효 가치 단위 Total Unit Cost = Variable Unit Cost + Fixed Cost Absorption
가정:
비용의 행동 유형이 같은 기간에 유지된다.
Step-fixed 용량이 어떤 임계점에서 증가하는지 기록한다.
One-time Cost는 반복 비용과 분리한다.
제외:
다음 증설 시점 이후의 미래 단가
아직 계약되지 않은 할인
회계상 고정비·변동비 분류
평균 단위 비용과 다음 주문 한 건의 한계비용도 같지 않다. 이미 여유 용량이 있는 구간에서는 주문이 늘어도 비용이 거의 변하지 않다가, Node나 DB Tier를 올리는 순간 단위 비용이 다시 뛸 수 있다.
성장 구간의 변화를 볼 때는 다음 보조식을 사용할 수 있다.
증분 단위 비용
= 기간 간 Included Cost 증가분
÷ 기간 간 유효 가치 단위 증가분가정:
두 기간의 Architecture·가격·Allocation Version이 비교 가능하다.
가치 단위 증가분이 0보다 크다.
Correction과 환율 효과를 별도로 제거하거나 설명한다.
제외:
Migration·대규모 재처리 같은 One-time Cost
제품 Mix가 크게 바뀐 기간
Reliability 수준이나 품질 조건이 달라진 기간
월별 비교에서는 Period를 정규화한다
단위 비용이 계산됐더라도 기간 기준이 다르면 추세를 오해할 수 있다.
| 항목 | 정규화 규칙 |
|---|---|
| 시간대 | 비용과 Business Event를 같은 Timezone으로 변환 |
| 부분 월 | 완전한 날짜만 비교하거나 Partial Period 표시 |
| Charge와 Billing Period | 운영 분석은 Charge Period, Invoice 정합은 Billing Period |
| Currency | 하나의 통화로 변환하고 FX Source·Date 기록 |
| Credit·Refund | 원 사용 기간에 Restate할지 발생 월에 반영할지 결정 |
| 늦은 Event | 재산정 마감일과 Snapshot Version 기록 |
| Commitment | 구매 시점의 BilledCost와 소비 시점의 EffectiveCost를 혼합하지 않음 |
| One-time 작업 | 반복 Run-rate와 분리 |
| 세금 | 기본 Cloud Unit Cost 포함 여부를 명시 |
| 품질 | 성공률·지연·오류율의 변화와 함께 해석 |
FOCUS 1.4는 Correction Handling과 Billing Period 상태를 명시적으로 다루지만 실제 공급자 Export의 지원 범위는 Version과 구현에 따라 다를 수 있다. 원본의 Correction 방식과 Data Completeness를 수집 단계에서 확인해야 한다.
성장과 Cohort를 함께 보지 않으면 평균이 속일 수 있다
전체 고객당 비용이 낮아졌더라도 저사용량 고객이 많이 유입됐기 때문일 수 있다. 반대로 단위 비용이 높아졌더라도 대규모 고객이나 고비용 기능 사용이 늘어난 결과일 수 있다.
최소한 다음 Cohort를 분리해 보는 편이 좋다.
| Cohort 축 | 확인하려는 질문 |
|---|---|
| 신규·기존 고객 | Onboarding과 초기 데이터 적재 비용이 높은가 |
| 요금제·고객 규모 | 대형 고객의 사용량과 비용이 가격에 반영되는가 |
| Region | 데이터 이동과 지역별 Architecture 차이가 있는가 |
| 제품 Version | 신규 기능이 단위 비용을 바꿨는가 |
| 사용량 구간 | 소규모 고객과 Heavy User의 비용 Driver가 다른가 |
| AI Model·품질 Tier | 고성능 Model 선택이 결과 개선과 균형을 이루는가 |
여러 Cohort의 단위 비용을 단순 평균하면 안 된다.
전체 단위 비용
= 모든 Cohort 비용 합
÷ 모든 Cohort 유효 단위 합가정:
Cohort들이 중복 없이 전체 Scope를 구성한다.
모든 Cohort가 같은 Metric Definition을 사용한다.
Cost View·Currency·Period가 일치한다.
제외:
Cohort별 Unit Cost의 산술 평균
분모가 서로 다른 Metric의 합산
다른 성공 조건을 사용한 Cohort
FinOps Foundation도 전체 조직 간 단순 비교보다 제품·Cohort·정의된 Scope 안에서 단위 비용의 시간 추세를 관리하는 방식을 제시한다.
단위 비용 변화는 다음 Driver로 나눠 설명할 수 있다.
공급자 Rate·Discount 변화
단위당 사용량 변화
고객·제품 Mix 변화
Architecture 변화
Idle·Headroom 변화
Shared Cost Allocation 변경
Tag·Business Event Data Quality 변화
비용이 낮아졌다는 사실만으로 최적화가 성공했다고 판단해서도 안 된다. 지연시간, 오류율, 가용성, 보안, 결과 품질과 같은 Guardrail이 함께 유지되어야 한다.
Cloud Unit Economics Template
Metric Contract
YAML
metric_id:
metric_version:decision_question:
target_reader:
scope:
product:
environment:
region:
customer_segment:
included_services:value_metric:
denominator_name:
business_event:
success_condition:
dedupe_key:
exclusions:
late_event_policy:period:
grain: daily | weekly | monthly
timezone:
charge_period_rule:
billing_period_rule:cost_view:
operational_numerator: EffectiveCost
invoice_numerator: BilledCost
source_focus_version:
billing_currency:
fx_policy:cost_inclusions:
direct:
shared:
idle:
data_network:
database:
ai_accelerator:cost_exclusions:
tax:
one_time:
non_cloud:
other:allocation:
version:
shared_pool_rules:
idle_policy:
unallocated_policy:restatement:
correction_handling:
close_date:
historical_recalculation:guardrails:
availability:
latency:
error_rate:
quality:
security:owners:
business_metric:
billing_data:
allocation:
approval:Cost Pool Register
| pool_id | 비용 범주 | 기술 범주 | 금액 기준 | Fixed 성격 | Allocation Key | 포함 여부 | 가정 | 제외·한계 |
|---|---|---|---|---|---|---|---|---|
| CP-001 | Direct | Compute | EffectiveCost | Variable | direct tag | INCLUDE | ||
| CP-002 | Shared | Database | EffectiveCost | Step-fixed | query CPU·I/O | INCLUDE | ||
| CP-003 | Shared | Network | EffectiveCost | Variable | transferred bytes | INCLUDE | ||
| CP-004 | Idle | Compute | EffectiveCost | Step-fixed | reliability policy | REVIEW | ||
| CP-005 | Unallocated | Mixed | EffectiveCost | Mixed | none | DISCLOSE | ||
| CP-006 | Excluded | Tax·One-time | BilledCost 또는 별도 원장 | Mixed | none | EXCLUDE |
기간별 결과 Dataset
csvperiod, scope, cohort, metric_version, valid_value_units, direct_effective_cost, allocated_shared_cost, included_idle_cost, attributed_cost, unallocated_cost, excluded_cost, total_effective_cost, attributed_unit_cost, reconciled_unit_cost, variable_unit_cost, fixed_cost_absorption, unallocated_rate, allocation_version, source_focus_version, currency, availability_guardrail, latency_guardrail, quality_guardrail, data_closed_at 10-4. 필수 정합성 검사
| 검사 | 통과 조건 |
|---|---|
| Cost Reconciliation | Direct + Shared + Idle + Unallocated가 Total EffectiveCost와 일치 |
| Shared Allocation | 각 Shared Pool의 배부 비율 합이 100% |
| Metric Completeness | Event Source와 집계된 유효 단위 수가 일치 |
| Scope Alignment | 비용과 분모의 Product·Environment·Region이 일치 |
| Period Alignment | Cost와 Event가 같은 기간·Timezone 사용 |
| Version Control | Metric·Allocation·FOCUS Source Version 기록 |
| Unallocated Disclosure | 미배부 금액과 비율을 숨기지 않음 |
| Guardrail | 비용 개선 전후 Reliability·Quality 조건 비교 |
| Restatement | Correction 이후 과거 값 변경 여부 기록 |
가상 계산 예시
다음은 IXC 또는 특정 기업의 실제 데이터가 아닌 계산 구조 설명용 가상 값이다.
YAML
period: 2026-07
scope: Product A / Production / KR
value_metric: 출고 완료 주문
valid_value_units: 120000direct_effective_cost: 18000000 KRW
allocated_shared_cost: 5400000 KRW
included_idle_cost: 1200000 KRW
unallocated_effective_cost: 1800000 KRW
excluded_invoice_items: 600000 KRW귀속 비용 = 18,000,000 + 5,400,000 + 1,200,000 = 24,600,000원 귀속 주문당 Cloud Unit Cost = 24,600,000원 ÷ 120,000건 = 주문당 205원
가정:
모든 비용은 2026년 7월 Charge Period의 EffectiveCost다.
주문은 Asia/Seoul 기준 같은 기간의 출고 완료 주문이다.
중복·취소·테스트 주문을 제외했다.
Shared Cost 배부 비율은 사전 승인된 Allocation Version을 사용했다.
제외:
1,800,000원의 미배부 비용
600,000원의 Invoice-only 제외 항목
인건비·결제 수수료·고객지원 비용
회계상 COGS 조정
미배부율 = 1,800,000원 ÷ 26,400,000원 ≈ 6.8%
가정:
Total EffectiveCost는 Direct·Shared·Idle·Unallocated의 합인 26,400,000원이다.
Invoice-only 제외 항목은 분모에 넣지 않았다.
제외:
세금과 비클라우드 비용
다른 제품·환경의 비용
Finance·Product·Engineering이 미배부 1,800,000원을 이 제품에 모두 배부하기로 승인했다면 다음 정합 값을 별도로 계산할 수 있다.
정합 주문당 Cloud Unit Cost
= 26,400,000원 ÷ 120,000건
= 주문당 220원귀속 값 205원과 정합 값 220원을 함께 제시하면 제품의 설명 가능한 운영 비용과 Allocation Data Quality 문제를 구분할 수 있다.
Cloud Unit Cost와 회계상 원가를 섞지 않는다
Cloud Unit Cost는 기술 비용을 제품 가치 단위로 연결한 운영·관리 지표다. 제품 가격이나 수익성 분석에 중요한 입력이 될 수 있지만 그 자체가 회계상 매출원가나 매출총이익은 아니다. FinOps Foundation도 Cloud Unit Economics가 Margin·Pricing·Forecasting 판단을 지원한다고 설명하지만 별도의 재무 지표와 역할을 구분한다.
회계상 원가에는 기업의 정책에 따라 다음 항목이 추가되거나 다른 방식으로 인식될 수 있다.
고객지원·운영 인건비
결제·메시징·외부 SaaS 수수료
자체 장비의 감가상각
무형자산·개발비
계약상 Credit·Commitment 처리
세금
공통 관리비
따라서 재무팀의 승인 없이 Cloud Unit Cost를 COGS per Customer나 Gross Margin으로 이름만 바꿔 사용해서는 안 된다.
두 지표를 연결해야 한다면 다음처럼 Mapping을 별도로 둔다.
YAML
operational_metric: Cloud Unit Cost
finance_metric: Cloud COGS per Unit
mapping_status: Finance approval required
cloud_cost_source: FOCUS EffectiveCost
additional_cogs_items:
excluded_cloud_items:
accounting_period:
accounting_policy_owner:월 청구액보다 단위 비용의 변화 이유를 본다
Cloud Unit Economics의 목표는 모든 클라우드 비용을 무조건 낮추는 것이 아니다.
주문당 비용이 올라갔다면 원인이 Model 품질 개선인지, 대형 고객 증가인지, Database 비효율인지, Network 경로인지, 미사용 약정인지 구분할 수 있어야 한다. 비용이 늘더라도 더 많은 가치가 더 높은 품질로 제공됐다면 합리적인 투자일 수 있다. 반대로 청구액이 줄었지만 오류율이나 지연시간이 악화됐다면 좋은 최적화라고 보기 어렵다.
처음부터 전사 비용을 완벽하게 배부할 필요는 없다. 한 제품과 하나의 Value Metric, 한 달의 데이터로 시작해도 된다. 대신 네 가지는 처음부터 지켜야 한다.
분모의 성공·중복·제외 조건을 문서화한다.
Direct·Shared·Idle·Unallocated를 구분한다.
배부되지 않은 비용을 숨기지 않는다.
비용 추세를 Growth·Cohort·Reliability와 함께 본다.
단위 비용은 하나의 숫자가 아니라, 제품의 성장과 인프라 비용이 어떻게 연결되는지를 설명하는 운영 모델이다.