월 클라우드 비용을 고객·주문·거래당 비용으로 바꾸는 법

단위 비용은 청구액을 유효 가치 단위로 나눈 값이다

월 클라우드 청구액이 3,000만 원에서 4,000만 원으로 늘었다는 사실만으로 비용 효율이 나빠졌다고 말할 수는 없습니다. 같은 기간 주문이 두 배로 늘었다면 주문 한 건을 처리하는 비용은 오히려 낮아졌을 수 있습니다. 반대로 청구액은 그대로인데 활성 고객이나 처리 작업 수가 줄었다면 비용 구조는 악화됐을 가능성이 큽니다.

월 Cloud Bill은 비용의 총량만 보여 줍니다. 제품이 성장할 때 비용이 어떤 속도로 늘어나는지 이해하려면 비용을 고객·주문·거래·작업 같은 Value Metric으로 나눠야 합니다. 가장 단순한 형태는 이렇습니다. 클라우드 단위 비용 = 같은 기간·같은 범위에 포함한 클라우드 비용 ÷ 같은 기간·같은 범위에서 발생한 유효 가치 단위.

이 식의 가정은 셋입니다. 비용과 가치 단위가 동일한 제품·기간·환경을 가리킵니다. 비용 Currency와 환율 기준이 일치합니다. 성공·중복·취소 조건을 적용한 유효 단위만 분모에 포함합니다. 제외하는 것도 셋입니다. 회계상 매출원가나 영업비용 전체, 범위가 다른 제품·기간의 비용, 정의되지 않은 테스트·재시도·내부 사용량입니다.

식은 간단하지만 실제 작업은 분자와 분모를 정의하는 데 있습니다. FinOps Foundation도 모든 조직에 적용되는 하나의 Unit Metric은 없으며 Metric은 가능한 한 사용자의 실제 Workflow와 가까워야 한다고 설명합니다.^[4]

먼저 무엇을 한 단위로 볼지 정한다

고객당 비용이 항상 가장 좋은 Metric은 아닙니다. 고객마다 사용량 차이가 큰 B2B SaaS에서 고객 수만 분모로 사용하면 대형 고객과 소형 고객의 비용 차이가 사라집니다. 주문당 비용도 주문 완료 전 발생한 검색·장바구니·결제 실패 비용을 어떻게 다룰지 정하지 않으면 해석하기 어렵습니다. Value Metric은 현재 내려야 할 결정에서 출발해야 합니다.

Token당 비용이나 GB당 비용은 엔지니어링 최적화에 유용한 Resource Efficiency Unit Metric입니다. 고객당·거래당·해결된 Case당 비용은 제품과 경영 판단에 가까운 Business Unit Metric입니다. AI도 초기에는 Token당 비용을 보더라도 궁극적으로는 수용된 결과나 완료된 작업당 비용으로 확장하는 편이 실제 가치와 가깝습니다.

Metric Contract를 먼저 작성한다

Value Metric을 정할 때는 이름보다 계산 계약이 중요합니다. 예를 들어 커머스 제품의 Metric Contract는 이렇게 씁니다. 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입니다.^[6] FOCUS는 공급자마다 다른 Billing Data의 용어와 Schema를 정규화합니다. 현재 네 개 Dataset을 정의하지만 단위 비용 계산의 중심은 Cost and Usage Dataset입니다.^[2]

단위 비용의 Numerator에는 보통 BilledCost와 EffectiveCost 두 가지 관점이 있습니다. 이 글의 기본 규칙은 분석 목적에 따라 Cost Metric과 Period 기준을 짝지어 두는 것입니다. EffectiveCost를 사용한다고 해서 그 값이 자동으로 재무제표의 발생주의 비용이나 매출원가가 되는 것은 아닙니다. FOCUS는 운영·Billing 분석을 위한 표준이며 기업의 회계 정책을 정하지 않습니다.

또한 최신 FOCUS Version과 실제 CSP Export Version은 구분해야 합니다. 현재 공식 Adoption 정보에서는 AWS·Azure·Google Cloud가 주로 FOCUS 1.2 수준을 지원합니다. 내부 Data Model에는 source_provider, source_export_name, source_focus_version, ingested_at을 보존하는 편이 안전합니다. charge_period_start/end, billing_period_start/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를 이미 수집한 것처럼 채워서는 안 됩니다.

BilledCost

실제 Invoice와 맞춰 보기 위한 비용입니다. 청구서 검증, 지급액, 월별 현금 지출을 설명할 때 적합합니다.

EffectiveCost

리소스가 사용되거나 약정 비용이 소비된 시점에 맞춰 비용을 배분한 값입니다. 선결제·약정 비용을 실제 사용 Row에 반영할 수 있어 제품별 비용 배부와 소비 추세 분석에 더 적합합니다.

제품·서비스의 운영 단위 비용

EffectiveCost를 쓰고 ChargePeriodStart/End를 Period 기준으로 삼습니다.

Invoice·지급액 정합

BilledCost를 쓰고 BillingPeriodStart/End를 Period 기준으로 삼습니다.

Commitment·Unused 분석

EffectiveCost와 Commitment 상태를 Charge Period 단위로 봅니다.

회계 보고

Finance가 승인한 별도 Mapping을 쓰고 회계 정책에 따릅니다.

비용을 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 + 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로 관리하도록 제시합니다.^[1]

모든 비용을 제품별로 합산해야 하는 보고서가 필요하다면 별도의 정합 값을 둡니다. 정합 단위 비용 = (귀속 비용 + 정책상 배부한 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를 활용해 공유비를 더 세밀하게 배부할 수 있다고 설명합니다.^[1] 고정 비율, 비례 배부, Proxy 방식이나 중앙 예산 유지도 Shared Cost별로 고를 수 있습니다. Cost Pool별로 편한 기준 대신 원인에 가까운 Key를 고르는 예는 아래 표와 같습니다.

Data·Network, Database, AI·Accelerator 비용

Network 비용은 단순히 전송량만 보면 부족합니다. Internet Egress, 리전 간 이동, 가용영역 간 이동, NAT·Gateway Processing, CDN Origin Transfer처럼 경로에 따라 비용이 달라질 수 있기 때문입니다.^[3] 가능하면 source_scope, destination_scope, traffic_class, bytes_transferred, request_count, transfer_cost, processing_cost, business_event_id의 Grain을 남깁니다. 주문·거래와 직접 연결할 수 없는 대량 Batch나 Replication Traffic은 주문 수로 나누기보다 해당 Job이나 데이터 제품에 먼저 귀속해야 합니다.

Tenant 전용 Database는 Direct Cost로 처리하기 쉽습니다. Shared Database는 Query 수만으로 나누면 가벼운 조회와 대규모 Scan이 같은 비용을 소비한 것처럼 보일 수 있습니다. 가능하면 Query Runtime, CPU, Read·Write I/O, Storage, Backup, Replica 사용량을 조합합니다. 관측 비용이 배부 정확도보다 커진다면 주요 비용 Driver만 선택하고 그 한계를 기록합니다.

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, 약정 사용량 중 실제로 쓰지 못한 부분이 Idle에 들어갑니다. Scale-out 최소 Node, 개발·검증 환경의 기본 용량, Owner가 사라진 Orphan Resource가 모두 Idle에 들어갑니다.

이 중 Headroom과 Warm Standby는 Reliability 요구사항 때문에 발생한 계획된 비용일 수 있습니다. 반면 미사용 약정이나 Orphan Resource는 별도의 개선 대상으로 볼 수 있습니다. FOCUS는 CommitmentDiscountStatus = Unused 같은 상태를 활용해 사용하지 못한 약정 비용을 식별할 수 있도록 합니다.^[2]

Idle Cost에는 아래 세 가지 정책 중 하나를 적용합니다. 정책을 정하지 못한 Idle Cost를 조용히 주문이나 고객 수에 나누면 실제 제품 효율과 조직의 구매·용량 계획 문제가 섞입니다.

제품 귀속

해당 제품의 신뢰성·복구 요구 때문에 확보한 용량에 적용합니다. Included Idle Cost로 표시합니다.

중앙 효율 Pool

여러 제품이 공동으로 책임져야 하는 미사용 약정에 적용합니다. 별도 Idle KPI로 표시합니다.

원인 Owner 귀속

특정 Team·제품의 과다 Provisioning이 명확할 때 적용합니다. 해당 대상에 배부합니다.

Fixed·Variable·Step-fixed를 구분한다

클라우드가 사용량 기반 과금이라고 해서 모든 비용이 완전한 Variable Cost인 것은 아닙니다. 비용의 행동 유형을 넷으로 나눕니다.

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 수준이나 품질 조건이 달라진 기간은 제외합니다.

Variable Cost

요청, 실행 시간, 전송량, Token처럼 단위 증가에 비교적 연속적으로 반응하는 비용입니다.

Step-fixed Cost

DB Instance, 최소 Node, 전용 Cluster처럼 일정 구간까지 고정되고 임계점에서 증가하는 비용입니다.

Period-fixed Cost

해당 기간의 기본 지원료나 고정 Platform 비용입니다.

One-time Cost

Migration, 초기 Backfill, 대규모 Reindex처럼 반복되지 않는 비용입니다.

월별 비교에서는 Period를 정규화한다

단위 비용이 계산됐더라도 기간 기준이 다르면 추세를 오해하게 됩니다. 정규화할 항목은 아래 열 가지입니다.

FOCUS 1.4는 Correction Handling과 Billing Period 상태를 명시적으로 다루지만 실제 공급자 Export의 지원 범위는 Version과 구현에 따라 다를 수 있습니다.^[6] 원본의 Correction 방식과 Data Completeness를 수집 단계에서 확인해야 합니다.

시간대

비용과 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 포함 여부를 명시합니다.

품질

성공률·지연·오류율의 변화와 함께 해석합니다.

성장과 Cohort를 함께 보지 않으면 평균이 속인다

전체 고객당 비용이 낮아졌더라도 저사용량 고객이 많이 유입됐기 때문일 수 있습니다. 반대로 단위 비용이 높아졌더라도 대규모 고객이나 고비용 기능 사용이 늘어난 결과일 수 있습니다. 최소한 아래 여섯 Cohort 축을 분리해 보는 편이 좋습니다.

여러 Cohort의 단위 비용을 단순 평균하면 안 됩니다. 전체 단위 비용 = 모든 Cohort 비용 합 ÷ 모든 Cohort 유효 단위 합. Cohort들이 중복 없이 전체 Scope를 구성하고 모든 Cohort가 같은 Metric Definition을 사용하며 Cost View·Currency·Period가 일치한다는 것이 가정입니다. Cohort별 Unit Cost의 산술 평균, 분모가 서로 다른 Metric의 합산, 다른 성공 조건을 사용한 Cohort는 제외합니다. FinOps Foundation도 전체 조직 간 단순 비교보다 제품·Cohort·정의된 Scope 안에서 단위 비용의 시간 추세를 관리하는 방식을 제시합니다.^[4]

단위 비용 변화는 일곱 Driver로 나눠 설명합니다. 공급자 Rate·Discount 변화, 단위당 사용량 변화, 고객·제품 Mix 변화, Architecture 변화가 앞 네 가지입니다. 나머지는 Idle·Headroom 변화, Shared Cost Allocation 변경, Tag·Business Event Data Quality 변화입니다. 비용이 낮아졌다는 사실만으로 최적화가 성공했다고 판단해서도 안 됩니다. 지연시간, 오류율, 가용성, 보안, 결과 품질과 같은 Guardrail이 함께 유지되어야 합니다.

신규·기존 고객

Onboarding과 초기 데이터 적재 비용이 높은지 확인합니다.

요금제·고객 규모

대형 고객의 사용량과 비용이 가격에 반영되는지 확인합니다.

Region

데이터 이동과 지역별 Architecture 차이가 있는지 확인합니다.

제품 Version

신규 기능이 단위 비용을 바꿨는지 확인합니다.

사용량 구간

소규모 고객과 Heavy User의 비용 Driver가 다른지 확인합니다.

AI Model·품질 Tier

고성능 Model 선택이 결과 개선과 균형을 이루는지 확인합니다.

Cloud Unit Economics Template

Template은 Metric Contract, Cost Pool Register, 기간별 결과 Dataset, 필수 정합성 검사의 네 부분으로 이루어집니다. Metric Contract는 아래 열한 묶음의 Field를 채웁니다.

기간별 결과 Dataset은 period, 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입니다.

Metric 식별

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 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 이후 과거 값의 변경 여부를 기록해야 합니다.

계산 예시

계산 구조를 보기 위한 예시 값입니다. period는 2026-07, scope는 Product A / Production / KR, value_metric은 출고 완료 주문, valid_value_units는 120,000건입니다. direct_effective_cost 18,000,000 KRW, allocated_shared_cost 5,400,000 KRW입니다. included_idle_cost 1,200,000 KRW, unallocated_effective_cost 1,800,000 KRW입니다. excluded_invoice_items 600,000 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 판단을 지원한다고 설명하지만 별도의 재무 지표와 역할을 구분합니다.^[4]

회계상 원가에는 기업의 정책에 따라 고객지원·운영 인건비, 결제·메시징·외부 SaaS 수수료, 자체 장비의 감가상각, 무형자산·개발비, 계약상 Credit·Commitment 처리, 세금, 공통 관리비가 추가되거나 다른 방식으로 인식될 수 있습니다.^[5] 따라서 재무팀의 승인 없이 Cloud Unit Cost를 COGS per Customer나 Gross Margin으로 이름만 바꿔 사용해서는 안 됩니다.

두 지표를 연결해야 한다면 Mapping을 별도로 둡니다. 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와 함께 봅니다.

단위 비용은 하나의 숫자가 아니라 제품의 성장과 인프라 비용이 어떻게 연결되는지를 설명하는 운영 모델입니다.