💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> "비용은 비기능 요구사항이 아니다. 2026년에는 가장 중요한 기능 요구사항이다." — 어느 FinOps 리드

이번 글은 **2026년 5월 기준 FinOps 시장 지도**다. 2023년부터 GenAI 워크로드가 폭증하면서 클라우드 청구서가 갑자기 두세 배로 뛰는 일이 흔해졌고, 그 결과 FinOps는 "있으면 좋은 것"에서 "없으면 회사가 망하는 것"으로 바뀌었다. FinOps Foundation이 발표한 **FOCUS(FinOps Open Cost and Usage Specification)** 1.0이 2024년 GA가 됐고, 2025년부터 AWS/GCP/Azure 모두 FOCUS 포맷의 청구서를 정식 지원한다. 즉 멀티 클라우드 비용 비교가 처음으로 같은 어휘로 가능해졌다.

이 글은 비용 가시성 SaaS(Vantage, CloudZero, Cloudability), 오픈소스 가시성(OpenCost, Infracost, Komiser, Cloud Custodian), Kubernetes 전용(Kubecost, Densify), 자동 최적화(Spot.io, ProsperOps, Granulate), 이상 탐지(Anodot, Yotascale), 미드마켓(FinOut)을 모두 비교한다. 마지막에는 한국의 토스/카카오, 일본의 Mercari/Cybozu 사례를 짚고 "우리 회사는 어떤 FinOps 도구를 골라야 하는가"라는 의사결정 가이드로 마무리한다.

1. 2026년 FinOps 지도 — 왜 다시 비용 관리인가

FinOps라는 단어는 2019년 LinuxFoundation 산하 FinOps Foundation이 창립되면서 본격적으로 쓰이기 시작했다. 핵심 아이디어는 단순하다. **클라우드 비용은 엔지니어링, 재무, 비즈니스 세 팀의 공동 책임**이며, 이를 위해 공통 언어, 공통 데이터, 공통 프로세스를 만들자는 운동이다.

2023년까지 FinOps는 "비용을 보여주고 줄이자" 정도였다. 그런데 2024년부터 GenAI 워크로드가 폭증했다. OpenAI 청구서가 월 수십만 달러를 넘기는 스타트업이 흔해졌고, 자체 모델을 돌리는 회사는 H100 GPU 한 장당 시간당 4달러를 8개씩 24시간 쓰면서 월 2만 달러 단위의 GPU 비용을 부담하게 됐다. CFO가 갑자기 "AWS 청구서가 분기마다 30%씩 오르는데 매출은 그만큼 안 오른다"고 따지는 일이 일상이 됐다.

2026년 FinOps 시장은 크게 다섯 부류다.

- **멀티 클라우드 가시성 SaaS**: Vantage, CloudZero, Cloudability(Apptio→IBM), FinOut

- **오픈소스 가시성**: OpenCost(CNCF), Infracost, Komiser

- **Kubernetes 전용**: Kubecost(IBM), Densify

- **자동 최적화**: Spot.io(NetApp), ProsperOps, Granulate(Intel)

- **이상 탐지/예측**: Anodot, Yotascale

- **정책 엔진**: Cloud Custodian(Capital One OSS)

Gartner는 2026년까지 글로벌 100대 기업의 80%가 전담 FinOps 팀을 갖출 것이라고 예측했고, FinOps Foundation 자체 조사에서는 회원사가 1만 곳을 돌파했다.

2. FinOps Foundation + FOCUS 표준

FinOps Foundation은 2019년 Linux Foundation 산하로 출범했다. 처음에는 베스트 프랙티스 공유 커뮤니티 정도였지만, 2023년 **FOCUS(FinOps Open Cost and Usage Specification)** 사양 작업을 시작하면서 사실상 산업 표준 제정 기구가 됐다.

FOCUS의 핵심은 단순하다. AWS는 청구서를 CUR(Cost and Usage Report)로, GCP는 Billing Export로, Azure는 Cost Management Export로, Oracle은 OCI Usage로 내놓는데, **컬럼 이름과 의미가 전부 다르다**. 같은 "리소스 ID"도 AWS는 `resource_id`, GCP는 `resource.name`, Azure는 `ResourceId`로 부른다. 멀티 클라우드 회사는 이걸 매번 정규화해야 했다.

FOCUS는 이 컬럼 어휘를 합의한 사양이다. 1.0이 2024년 GA됐고, 2025년부터 주요 클라우드가 FOCUS 포맷을 정식 출력한다. 핵심 컬럼:

FOCUS 1.0 핵심 컬럼 일부

BilledCost: 실제 청구된 금액 (할인/크레딧 적용 후)

EffectiveCost: 약정 할인 분배 후의 단위 비용

ListCost: 정가 비용

ServiceName: 정규화된 서비스 이름 (예: Amazon EC2)

ServiceCategory: 카테고리 (Compute, Storage, AI/ML 등)

ChargeCategory: Usage / Purchase / Tax / Adjustment / Credit

ChargeFrequency: One-time / Recurring / Usage-based

ResourceId: 리소스 식별자

ResourceType: 리소스 종류

SkuId: SKU 식별자

PricingUnit: 가격 단위 (GB-Mo, vCPU-Hour 등)

FOCUS의 의미는 단순히 "포맷 통일"이 아니다. **벤더 락인이 줄어든다는 뜻**이다. Vantage에서 CloudZero로 갈아탈 때, 과거에는 데이터 파이프라인을 처음부터 다시 짜야 했지만, 이제는 FOCUS 데이터셋만 통째로 옮기면 된다. 또 자체 데이터 웨어하우스(Snowflake/BigQuery)에 FOCUS 포맷으로 비용 데이터를 적재하는 회사도 빠르게 늘었다. "비용 분석은 SQL로 한다"가 다시 유행하는 이유다.

3. Vantage — 멀티 클라우드 가시성의 강자

Vantage는 2020년 미국에서 시작했고, 창업자가 DigitalOcean 출신이라는 점에서 시작부터 "개발자가 만드는 FinOps"를 표방했다. 2024년 Series B를 마감하면서 멀티 클라우드 가시성 SaaS의 사실상 리더로 올라섰다.

Vantage의 강점:

- **30개 이상의 통합**: AWS, GCP, Azure, Oracle, Alibaba, Snowflake, Databricks, Datadog, MongoDB Atlas, Confluent, Fastly, Linode, DigitalOcean 등. 즉 "클라우드뿐 아니라 SaaS도 한 곳에서 본다"가 차별화다.

- **Cost Reports** 기능이 직관적이다. SQL 안 짜고 GUI로 "지난 90일 EC2 비용을 리전별/팀 태그별로 분해" 같은 쿼리를 만들 수 있다.

- **Active Discounts**: 미사용 RI/SP, 잘못 할당된 약정을 자동 탐지

- **Cost Anomaly Detection**: 임계값 기반 + ML 기반 둘 다 제공

- 가격이 투명하다 (월 비용의 일정 비율 + 최소 사용료)

Vantage의 약점:

- 자동 최적화 액션은 제한적. "찾아주지만 직접 줄이려면 다른 도구나 수동 작업 필요"

- 엔터프라이즈 RBAC/SSO는 상위 플랜에서만 제공

- Kubernetes 비용은 별도 통합이 필요 (Vantage가 OpenCost를 사용)

**누가 써야 하나**: 50-500명 규모 엔지니어링 조직, 멀티 클라우드 사용 중, SaaS 비용도 한 곳에서 보고 싶은 곳. 토스, Figma, Snap, PagerDuty 등이 사용자로 알려져 있다.

4. Infracost — IaC PR에서 비용 차이 보기

Infracost는 2021년 영국에서 시작한 오픈소스다. 다른 FinOps 도구들이 "**이미 쓴** 비용을 보여주는" 반면, Infracost는 **"앞으로 쓸 비용"을 PR 시점에 보여주는** 거의 유일한 도구다.

작동 방식:

1. 개발자가 Terraform/Pulumi/CloudFormation PR을 올림

2. GitHub Action으로 Infracost가 돌고

3. PR 코멘트로 "이 변경은 월 $1,840 늘립니다" 같은 다이프를 붙임

Infracost 기본 사용

infracost breakdown --path=terraform/

출력 예시:

Project: my-infra/terraform

Name Monthly Qty Unit Monthly Cost

aws_instance.web_app

├─ Instance usage (m5.large) 730 hours $70.08

├─ EBS volume (gp3) 30 GB-month $2.40

└─ EBS snapshots 5 GB-month $0.25

Project total $72.73

CI 통합 예시(GitHub Actions):

.github/workflows/infracost.yml

name: Infracost

on: [pull_request]

jobs:

infracost:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- uses: infracost/actions/setup@v3

with:

api-key: $INFRACOST_API_KEY

- run: infracost breakdown --path=. --format=json --out-file=/tmp/base.json

- uses: actions/checkout@v4

with: { ref: $GITHUB_HEAD_REF }

- run: |

infracost diff --path=. \

--compare-to=/tmp/base.json \

--format=github-comment \

--out-file=/tmp/comment.md

- uses: infracost/actions/comment@v3

with: { path: /tmp/comment.md }

Infracost의 의미는 "비용을 코드 리뷰 사이클에 넣었다"는 데 있다. 개발자가 RDS 인스턴스 타입을 `db.r5.4xlarge`로 잡고 PR을 올리면, 리뷰어가 "월 $1,400 추가인데 이만큼 필요한가?"를 묻기 시작한다. **비용 관련 의사결정의 위치를 production 발견 시점에서 PR 시점으로 이동**시킨 것이다.

Infracost Cloud(SaaS)는 정책 자동화, 조직 대시보드, 가드레일을 추가로 제공한다. 오픈소스 CLI는 무료, Cloud는 시트당 월 단가.

**누가 써야 하나**: Terraform/Pulumi를 진지하게 쓰는 모든 팀. 특히 IaC PR이 하루 수십 개씩 올라오는 플랫폼 팀.

5. OpenCost (CNCF) — 표준 Kubernetes 비용

OpenCost는 Kubecost가 2022년 CNCF에 기증한 오픈소스 프로젝트다. 2024년 CNCF Incubating에 진입했고, Kubernetes 비용 가시성의 사실상 표준이다.

작동 방식:

- 클러스터 안에 OpenCost Pod 하나를 띄움

- Prometheus와 연동해 노드/Pod/네임스페이스 단위로 CPU/메모리/GPU/스토리지/네트워크 사용량을 수집

- 클라우드 가격표(AWS/GCP/Azure)와 곱해서 비용을 산출

- 결과를 Prometheus 메트릭으로 노출

OpenCost 설치 (Helm)

helm repo add opencost https://opencost.github.io/opencost-helm-chart

helm install opencost opencost/opencost \

--namespace opencost \

--create-namespace \

--set opencost.prometheus.internal.serviceName=prometheus-server

핵심 메트릭(Prometheus 노출):

opencost_node_total_hourly_cost # 노드별 시간당 비용

opencost_load_balancer_cost # LoadBalancer 비용

opencost_pv_cost # PV(영구 볼륨) 비용

opencost_namespace_total_cost # 네임스페이스 총 비용

opencost_workload_cost_running # 워크로드 단위 비용

OpenCost는 "비용을 본다"까지만 한다. **줄여주지는 않는다**. 그래서 OpenCost + Grafana 대시보드 + Slack 알림 조합을 만든 뒤, 줄이는 것은 다른 도구(Karpenter, KEDA, Spot.io)에 맡기는 패턴이 흔하다.

벤더 채택 상황:

- **Vantage**, **CloudZero**, **Datadog Cloud Cost Management**, **Grafana Cloud**가 모두 OpenCost를 backend로 사용

- 즉 OpenCost를 직접 설치하지 않아도 위 도구를 쓰면 OpenCost 위에서 동작 중인 것

**누가 써야 하나**: Kubernetes 운영 중인 모든 팀. 무료고 락인 없으니 일단 깔아두는 게 합리적이다.

6. Kubecost — IBM 인수 (2024)

Kubecost는 2019년 미국에서 시작한 Kubernetes 비용 SaaS다. 위에서 본 OpenCost를 만들어 CNCF에 기증한 본가다. **2024년 IBM이 인수했고**, 현재는 IBM Cloud Paks 포트폴리오의 일부로 운영된다.

OpenCost와 Kubecost의 관계:

- OpenCost = 무료 코어, CNCF 인큐베이팅

- Kubecost = OpenCost 위에 UI/대시보드/멀티 클러스터/이상 탐지/추천 엔진을 얹은 상용 제품

Kubecost의 차별화 기능:

- **Multi-cluster aggregation**: 수십 개 클러스터 비용을 한 화면에 모음

- **Allocation views**: 네임스페이스/레이블/디플로이먼트/팀/제품 단위 비용 분해

- **Savings recommendations**: 적정 사이즈 추천, 미사용 노드 탐지, Spot 전환 가능 워크로드 식별

- **Budget alerts**: 팀별/네임스페이스별 예산 초과 알림

- **Cluster Right-Sizing**: 노드 풀 구성 추천

IBM 인수의 영향:

- IBM Cloud / OpenShift와의 통합이 빠르게 강화됨

- 엔터프라이즈 가격 정책이 일부 바뀜 (기존 Kubecost Free Tier는 유지)

- 로드맵이 "Kubernetes only"에서 "OpenShift + IBM Cloud 우대"로 일부 기울어진다는 평이 있음

**누가 써야 하나**: 100노드 이상의 멀티 클러스터, 네임스페이스를 팀/제품 경계로 쓰는 조직, 비용을 chargeback 하고 싶은 곳.

7. CloudZero — unit cost economics

CloudZero는 2018년 미국에서 시작했다. 다른 FinOps 도구들이 "총비용을 줄이자"에 집중할 때, CloudZero는 **"단위 비용(unit cost)"** 개념을 전면에 내세웠다.

unit cost란 무엇인가? 예시:

- "고객 1명당 월 인프라 비용" = $0.42

- "API 호출 1000건당 비용" = $0.018

- "분석 쿼리 1건당 비용" = $0.07

- "AI 추론 1000토큰당 비용" = $0.0012

총비용은 줄어들지 않더라도, **단위 비용이 줄어들면 비즈니스는 건강해진다**. CloudZero의 핵심 메시지는 "CFO가 보고 싶은 건 총액이 아니라 단위 비용이고, 단위 비용이 매출과 함께 움직여야 한다"이다.

기술적으로 CloudZero는:

- AWS/GCP/Azure/Snowflake/Databricks/Kubernetes(OpenCost)를 통합

- **CostFormation™**이라는 자체 DSL로 임의의 비용 분배 규칙을 정의 (어떤 비용을 어떤 제품/고객/팀에 얼마나 분배할지)

- AI/ML 비용 카테고리를 별도로 분리 (GenAI 워크로드 분석에 강함)

- 단위 비용 트렌드를 매출/사용량 메트릭과 함께 표시

가격은 공개되어 있지 않고, 일반적으로 연간 클라우드 지출 규모에 비례한다. 미드마켓~엔터프라이즈 타겟이고, 시트 기반이 아니다.

**누가 써야 하나**: SaaS 회사로 "ARR 대비 cloud cost ratio"가 보드 미팅에 올라가는 조직. AI 회사로 "토큰당 추론 비용을 분기마다 줄이고 있다"를 증명해야 하는 곳.

8. Cloudability (Apptio/IBM) — 엔터프라이즈

Cloudability는 2011년에 시작한 1세대 FinOps SaaS다. 2019년 Apptio가 인수했고, **2023년 IBM이 Apptio를 인수하면서** Cloudability도 IBM 산하로 들어왔다.

Cloudability의 위치:

- 가장 오래된 FinOps 도구 중 하나, 엔터프라이즈에서 압도적 점유율

- IBM Apptio 포트폴리오와 묶여서 ITFM(IT Financial Management) 통합 솔루션으로 판매됨

- 가격은 엔터프라이즈 협상 기반, 일반적으로 비싼 편

기능 측면:

- AWS/Azure/GCP/Oracle/OpenShift 전체 커버리지

- True Cost (정가 vs 실제 비용) 분석이 정교함

- Rightsizing 추천이 머신러닝 기반

- 약정 관리(RI/Savings Plans) 최적화 기능 강함

- True Up: 약정 만료 시점 자동 알림

신생 SaaS(Vantage, CloudZero) 대비 약점:

- UI/UX가 무겁고 학습 곡선이 있음

- 셋업과 설정에 컨설팅이 필요한 경우 많음

- 변화 속도가 느림 (엔터프라이즈 요구사항이 우선)

**누가 써야 하나**: 클라우드 연간 지출 1000만 달러 이상, 이미 Apptio ITFM을 쓰는 곳, IBM과의 엔터프라이즈 계약이 있는 조직.

9. Spot.io (NetApp) — 스팟 인스턴스 자동화

Spot.io의 전신은 **Spotinst**다. 2015년 이스라엘에서 시작했고, **2020년 NetApp이 인수**했다. 핵심 가치 제안: "스팟 인스턴스의 리스크를 관리해줄게, 너는 60-90% 비용 절감만 가져가".

작동 원리:

- Spot Elastigroup이 AWS Spot, Azure Spot VM, GCP Preemptible VM을 오케스트레이션

- 가격 변동/회수(reclamation) 예측을 ML로 수행

- 회수 신호가 오면 미리 새 인스턴스를 띄워서 워크로드를 옮김

- 평균적으로 "온디맨드의 30% 가격"을 광고

Spot.io의 제품군:

- **Elastigroup**: 일반 워크로드(EC2/VMSS) 스팟 자동화

- **Ocean**: Kubernetes 노드 풀의 스팟 자동화. 사실상 Karpenter의 상용 경쟁자

- **Eco**: 약정(RI/SP) 관리. ProsperOps의 경쟁자

- **CloudCheckr**: 2021년 인수, FinOps 가시성 추가

2024-2025년 흐름:

- AWS Karpenter가 오픈소스로 빠르게 성장하면서 Ocean의 명분이 일부 약해짐

- 그래도 "Karpenter 운영 인력이 없는 조직"에는 Ocean이 여전히 유효

- NetApp 내부에서 BlueXP 브랜드 아래 재편 중

**누가 써야 하나**: 스팟 인스턴스를 쓰고 싶지만 회수 처리 코드를 직접 짜기 싫은 조직. Karpenter 운영 인력이 없는 미드마켓.

10. Densify / ProsperOps / FinOut / Anodot / Yotascale — 그 외

**Densify**는 캐나다 토론토에서 2010년부터 시작한 베테랑이다. 강점은 **Kubernetes/VM 라이트사이징** 추천. ML 기반으로 워크로드 패턴을 분석해 "이 디플로이먼트는 CPU 1코어가 아니라 0.3코어면 충분합니다, 메모리는 512Mi → 384Mi" 같은 PR을 자동 생성한다. Terraform/Helm 출력도 지원.

**ProsperOps**는 2018년 미국 시작. 한 가지에 집중한다: **AWS RI/Savings Plans 자동 관리**. 사람 손으로 약정 포트폴리오를 관리하던 영역을 알고리즘으로 대체했다. 매주 자동으로 SP를 사고 팔아 "effective savings rate"를 최대화한다. 수수료는 절감액의 일정 비율(통상 15-25% 수준)이다.

**FinOut**은 2021년 텔아비브 시작. 미드마켓 SaaS로 자리잡았다. 강점은 **"비용을 비즈니스 단위로 분해"하는 dashboard 빌더**. CloudZero 대비 가격이 더 합리적이라는 평이 있고, "10명 미만 스타트업에 무료"라는 정책도 있다.

**Anodot**은 2014년 이스라엘 시작. 원래는 비즈니스 메트릭 이상 탐지 SaaS였고, 클라우드 비용에도 같은 ML 엔진을 적용했다. **이상 탐지가 가장 정교한 도구 중 하나**로 평가받는다. "어제 EC2 비용이 갑자기 23% 뛰었는데, 원인은 us-east-1 r5.large 100대 추가"를 자동으로 찾아준다.

**Yotascale**은 2015년 미국 시작. 비용 분배(allocation) 규칙 정의가 매우 유연한 게 강점. 엔지니어링 매니저가 SQL을 안 짜고도 "지난 30일간 검색팀이 ML 추론에 쓴 비용"을 GUI로 만들 수 있다.

도구 선정 매트릭스(요약):

| 도구 | 강점 | 약점 | 가격 |

|---|---|---|---|

11. Komiser / Cloud Custodian — OSS 인벤토리 + 정책

**Komiser**는 Tailwarden(원래 Mlabs)이 만든 오픈소스 클라우드 리소스 인벤토리 도구다. 2024년부터 SaaS 버전(Tailwarden)도 제공한다.

작동:

- AWS/GCP/Azure/DigitalOcean/Linode/OCI에 read-only 권한으로 접근

- 모든 리소스를 인벤토리화

- 비용/태그/소유자/이상 탐지를 한 화면에 시각화

- "태그 없는 EC2 47개", "stopped 상태로 30일 지난 EBS 12개" 같은 인사이트 제공

Komiser CLI 빠른 시작

docker run -d -p 3000:3000 \

-v $HOME/.aws:/root/.aws:ro \

tailwarden/komiser:latest

http://localhost:3000 으로 접속

**Cloud Custodian**은 Capital One이 2016년에 오픈소스로 공개한 정책 엔진이다. CNCF Incubating 단계. "YAML로 클라우드 가버넌스 규칙을 짜고, 위반 리소스에 자동 조치를 실행"하는 도구다.

Cloud Custodian 정책 예시 - 태그 없는 EC2 30일 후 자동 종료

policies:

- name: ec2-untagged-stop-30d

resource: aws.ec2

filters:

- State.Name: running

- "tag:Owner": absent

- type: instance-age

days: 30

op: gt

actions:

- type: notify

to: [costops@example.com]

template: untagged-instance.html

subject: "Untagged EC2 - will stop in 7 days"

- type: mark-for-op

op: stop

days: 7

- type: stop

Cloud Custodian의 가치는 "정책을 코드로 관리"한다는 것이다. "리전당 비용 한도", "태그 없는 리소스 금지", "7일 이상 idle한 RDS 정지" 같은 규칙을 Git으로 관리하고 PR로 변경한다.

Custodian 사용자: Capital One 본인들, FINRA, HBO Max, eBay 등 대규모 엔터프라이즈가 다수.

**누가 써야 하나**: Komiser는 모두에게 추천(무료, 셋업 5분). Cloud Custodian은 보안/거버넌스 팀이 있고 정책을 코드로 관리하는 문화가 있는 조직.

12. Granulate (Intel) — 워크로드 최적화

Granulate는 2018년 이스라엘에서 시작한 워크로드 자동 최적화 회사다. **2022년 Intel이 6억 5천만 달러에 인수**했다. 다른 FinOps 도구들이 "리소스 사이즈를 줄이자"에 집중할 때, Granulate는 **"같은 인프라에서 같은 워크로드를 더 빠르게 돌려서 결과적으로 비용을 줄이자"**라는 다른 길을 갔다.

작동 원리:

- 호스트에 Granulate 에이전트를 설치

- JVM/Python/Node.js/Spark/PostgreSQL/MySQL/NGINX 등 런타임을 분석

- OS 스케줄러, GC 정책, 컨테이너 cgroup 파라미터를 워크로드별로 자동 튜닝

- 평균 20-40%의 CPU 절감을 광고 (사례별 편차 큼)

대표 사용 사례:

- **gProfiler**(오픈소스 부산물): 컨테이너 호스트에서 지속적 프로파일링. Pyroscope/Polar Signals와 경쟁

- **Granulate Continuous Optimization**: 상용 제품

- **Optimizer for Spark**: Databricks/EMR Spark 잡 자동 튜닝

- **Optimizer for K8s**: 워크로드별 cgroup/스케줄링 튜닝

Intel 인수 이후:

- Intel Tiber Cloud Optimization으로 브랜드 재편

- Granulate gProfiler는 계속 오픈소스로 유지

- Spark/Databricks 최적화 사례가 늘었음 (분석 워크로드에서 효과가 큼)

**누가 써야 하나**: JVM/Spark/Python 같은 무거운 런타임을 대규모로 돌리는 조직. 라이트사이징은 이미 했고 "더 줄일 게 있나"를 찾는 단계.

13. showback vs chargeback / reserved capacity / savings plans

FinOps 운영 모델에는 두 가지 큰 갈래가 있다.

**showback**: "당신 팀이 지난 달 5만 달러 썼습니다"를 보여주기만 함. 청구는 회사가 통째로 부담.

**chargeback**: 위 5만 달러를 실제로 팀 예산에서 차감. 팀이 P&L 책임을 짐.

대부분의 조직은 **showback에서 시작**한다. 비용을 정확히 분배할 수 있는 태깅/카탈로그가 갖춰지지 않은 상태에서 chargeback을 시작하면 "내 비용이 아니다"라는 항의가 폭주한다. 보통 6-12개월 showback으로 데이터 신뢰도를 쌓은 뒤 chargeback으로 전환한다.

태깅 표준(흔한 패턴):

비용 분배 태그 표준 예시

team: payments # 책임 팀

service: payment-api # 서비스 이름

env: production # 환경

cost-center: 12345 # 회계 비용 센터

business-unit: consumer # 사업부

project: checkout-redesign # 프로젝트 (선택)

owner: yj.kim@example.com # 담당자

**Reserved Instances(RI)와 Savings Plans(SP)**는 AWS의 약정 할인 제도다. 1년 또는 3년 약정으로 일정 사용량을 약속하면 30-72% 할인을 받는다. RI는 인스턴스 패밀리/리전에 묶이지만, SP(특히 Compute SP)는 훨씬 유연하다. 2026년 베스트 프랙티스는 "기본 워크로드의 70-80%는 1년 Compute SP로 커버, 나머지는 온디맨드/스팟"이다.

GCP의 **CUD(Committed Use Discounts)**와 Azure의 **Reserved VM Instances / Savings Plan**도 비슷한 구조다. 멀티 클라우드에서는 각 클라우드별로 별도 관리해야 한다.

14. 한국 / 일본 — 토스, 카카오, Mercari, Cybozu

**토스**(Toss)는 2022년경부터 본격적인 FinOps 팀을 운영 중이다. 자체 비용 대시보드를 사내에 구축했고, 일부 영역에서 Vantage를 병행 사용한다. 토스가 공개한 자료에 따르면 "Spark 클러스터 라이트사이징과 RI 최적화만으로 분기당 수억원 단위의 절감"을 달성했다. 한국 핀테크 특성상 데이터 분석/AI 워크로드 비중이 크고, BigQuery/Snowflake 비용 관리에 많은 자원을 투입한다.

**카카오**(Kakao) 그룹은 카카오엔터프라이즈/카카오뱅크/카카오페이가 각자 다른 FinOps 접근을 취한다. 카카오뱅크는 자체 데이터 웨어하우스에 비용 데이터를 적재하고 사내 SQL/BI로 분석한다. 카카오엔터프라이즈는 자사 클라우드(KC) 사용량을 직접 관리한다. 공통적으로 "오픈소스 + 자체 구축" 비중이 높고, 상용 SaaS 의존도는 글로벌 기업 대비 낮은 편이다.

**Mercari**(메루카리)는 일본에서 FinOps 사례를 가장 활발히 공개하는 회사 중 하나다. Mercari Engineering 블로그에 OpenCost 활용기, GCP BigQuery 비용 절감 사례, Kubernetes 멀티 테넌시에서의 비용 분배 사례 등을 정기적으로 게시한다. 자체 비용 대시보드(Mercari Cost Dashboard)를 사내에서 운영한다.

**Cybozu**는 일본 SaaS 회사로 Kintone/Garoon을 운영한다. 비용 운영을 "프로덕션 SRE 팀의 역할 일부"로 정의하고, OpenCost + Datadog Cloud Cost Management 조합을 공개적으로 사용 사례로 발표했다. CyberAgent CIU(Cyber Infrastructure Unit)도 비슷한 접근으로 사내 비용 가시성 플랫폼을 직접 운영한다.

한국/일본 공통 패턴:

- 상용 SaaS는 비싼 편이라 자체 구축 선호

- OpenCost + Infracost + 자체 BigQuery/Snowflake 적재 조합이 흔함

- 약정(RI/SP)은 재무팀과 인프라팀의 공동 의사결정 영역

- chargeback까지 가는 사례는 드물고, 대부분 showback에서 멈춤

15. 누가 무엇을 골라야 하나 — 의사결정 가이드

조직 규모와 워크로드에 따라 추천 조합이 다르다.

**시드/Series A 스타트업(엔지니어 1-20명, 클라우드 월 비용 < $5K)**

- AWS Cost Explorer + GCP Billing Console + Azure Cost Management로 충분

- Infracost OSS는 무료라 일단 깔자

- 비용이 갑자기 뛰면 그때 Vantage 무료 티어 시작

**Series B-C 스타트업(엔지니어 20-100명, 클라우드 월 비용 $5K-$100K)**

- Vantage 또는 FinOut. Vantage는 SaaS도 같이 보고 싶으면 선호

- Infracost는 CI에 박아둠

- Kubernetes 있으면 OpenCost 추가

- 스팟 인스턴스 쓰고 싶으면 Karpenter(OSS) → 안 되면 Spot.io Ocean

**미드마켓(엔지니어 100-500명, 클라우드 월 비용 $100K-$1M)**

- Vantage 또는 CloudZero (unit cost가 중요하면 CloudZero)

- Infracost Cloud로 가버넌스

- OpenCost + Kubecost 콤보

- ProsperOps로 RI/SP 자동 관리

- 이상 탐지에 Anodot 검토

**엔터프라이즈(엔지니어 500명+, 클라우드 월 비용 $1M+)**

- Cloudability(Apptio)가 사실상 표준, 또는 CloudZero/Vantage Enterprise

- Cloud Custodian으로 정책 자동화

- Densify로 라이트사이징 자동화

- Granulate로 워크로드 최적화 (분석 워크로드 많으면 ROI 큼)

- 자체 데이터 웨어하우스(Snowflake/BigQuery)에 FOCUS 포맷으로 적재

**Kubernetes-only 조직**

- OpenCost가 기본

- 대시보드/멀티 클러스터 필요하면 Kubecost

- 라이트사이징은 Densify 또는 자체 VPA

- 스팟 자동화는 Karpenter (OSS) 또는 Spot.io Ocean

**AI/ML 회사**

- CloudZero가 GenAI 비용 분리에 가장 강함

- GPU 클러스터는 OpenCost + 자체 분석

- 추론 비용은 단위 비용(per-token, per-request)으로 추적

- Granulate로 학습 잡 최적화 검토

도구 선정에서 가장 중요한 의사결정은 도구 자체가 아니라 **"우리 회사가 어떤 비용 의사결정을 누구에게 맡길 것인가"**의 정치적 합의다. 합의가 없으면 어떤 도구를 사도 대시보드만 늘어난다.

FinOps는 도구의 문제가 아니라 **조직의 문제**다. 2026년의 차이점은 GenAI로 인해 비용이 더 이상 "엔지니어링의 부수적 관심사"가 아니라는 점이고, FOCUS 표준이 멀티 클라우드 비용 분석의 어휘를 통일했다는 점이다. 도구 시장은 그 결과로 다섯 부류로 정리됐다. 어떤 도구를 고르든 시작은 단순하다. **OpenCost를 깔고, Infracost를 CI에 박고, 태깅 표준을 정하고, 한 분기간 showback 데이터를 모은다**. 그다음에 SaaS를 살지, chargeback으로 갈지를 결정하면 된다.

참고 / References

- FinOps Foundation — https://www.finops.org

- FOCUS Specification — https://focus.finops.org

- Vantage — https://www.vantage.sh

- Infracost — https://www.infracost.io

- Infracost GitHub — https://github.com/infracost/infracost

- OpenCost (CNCF) — https://www.opencost.io

- OpenCost GitHub — https://github.com/opencost/opencost

- Kubecost — https://www.kubecost.com

- IBM Acquires Kubecost (2024) — https://www.ibm.com/blog/announcement/ibm-to-acquire-kubecost/

- CloudZero — https://www.cloudzero.com

- Cloudability (Apptio/IBM) — https://www.apptio.com/products/cloudability/

- Spot.io (NetApp) — https://spot.io

- Densify — https://www.densify.com

- ProsperOps — https://www.prosperops.com

- FinOut — https://www.finout.io

- Anodot — https://www.anodot.com

- Yotascale — https://www.yotascale.com

- Komiser — https://www.komiser.io

- Cloud Custodian (CNCF) — https://cloudcustodian.io

- Granulate (Intel) — https://granulate.io

- AWS Karpenter — https://karpenter.sh

- Datadog Cloud Cost Management — https://www.datadoghq.com/product/cloud-cost-management/

- State of FinOps 2025 — https://www.finops.org/insights/the-state-of-finops-2025/

- Mercari Engineering Blog — https://engineering.mercari.com/en/blog/

- Cybozu Tech Blog — https://blog.cybozu.io

- CyberAgent CIU Blog — https://developers.cyberagent.co.jp/blog/archives/category/infrastructure/

- Toss Tech Blog — https://toss.tech