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

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

프롤로그 — "왜 청구서가 또 늘었지?"는 2026년에도 끝나지 않았다

2026년이 됐는데도 매달 첫째 주 화요일이면 같은 대화가 반복된다. 재무팀은 "지난달 AWS 청구서가 18% 늘었는데 이유가 뭐냐"라고 묻고, 엔지니어링은 "트래픽이 늘어서요"라고 답하고, CFO는 "우리가 트래픽 1% 늘 때마다 비용 18% 느는 회사인가?"라고 되묻는다. 그러면 누군가가 Kubecost 대시보드를 열어보지만 어떤 네임스페이스가 비싼지 보일 뿐, **왜** 비싼지는 안 보인다.

이게 2026년 클라우드 비용의 본질이다. **데이터는 넘치는데 의사결정이 안 된다.** AWS Cost Explorer, GCP Recommender, Azure Cost Management, Kubecost, OpenCost, Vantage, Cloudability(Apptio), Spot.io(NetApp), CAST AI, PerfectScale, Densify — 도구는 너무 많고, 각자 다른 단위로 청구서를 자른다. 그래서 2024년 FinOps Foundation이 발표한 **FOCUS 1.0** 사양이 2026년 산업 표준이 됐다. AWS·GCP·Azure·Oracle·Snowflake가 동일한 스키마로 청구서를 내보내기 시작했고, FinOps Foundation은 Linux Foundation 산하로 들어가서 거버넌스가 안정됐다.

거기에 한 가지가 더 터졌다. **LLM GPU 비용.** 2025년 한 해 동안 OpenAI·Anthropic·Cohere API 청구서를 분석한 회사들이 "어 이거 EC2보다 크다"라는 사실을 깨달았다. 그래서 2026년의 FinOps는 단순히 EC2 RI 사기, 미사용 EBS 지우기가 아니라, **per-token 경제학**과 **GPU 활용률**이 핵심 지표가 됐다.

이 글은 그 지도를 그린다. FinOps Foundation 프레임워크부터, Kubecost·OpenCost·Vantage 같은 도구의 위치, Karpenter vs Cluster Autoscaler, Spot.io·CAST AI의 자동화, 그리고 LLM 추론 비용까지.

1장 · FinOps 라이프사이클 — Inform · Optimize · Operate

FinOps Foundation의 공식 프레임워크는 3단계 라이프사이클로 구성된다. 2026년 버전(FinOps Framework v2)에서 도메인과 capability가 정리됐다.

- **Inform (정보화)**: 누가, 무엇을, 왜 쓰는지 보이게 한다. 태깅, 할당, 청구서 분해, 단위 경제학.

- **Optimize (최적화)**: 보이는 것에 기반해 실제로 깎는다. RI/SP 구매, 미사용 자원 제거, right-sizing, 스팟 활용.

- **Operate (운영화)**: 최적화를 일회성 이벤트가 아니라 일상 운영으로 만든다. 정책, 가드레일, 비용 SLO, 부서 차지백.

흔한 실수: **Optimize부터 시작한다.** Reserved Instance를 사놓고 정작 어떤 워크로드가 어디서 도는지 모른다. 그러면 RI utilization이 60%대로 떨어지고, 절감액보다 미사용 RI 손실이 더 커진다. 순서는 항상 **Inform → Optimize → Operate**.

도메인 레벨에서는 여섯 가지: Understand Usage and Cost, Quantify Business Value, Manage the FinOps Practice, Optimize Usage and Cost, Manage Anomalies, Forecast. 2026년 추가된 capability는 **Sustainability**(탄소 측정과 비용을 같이 본다)와 **Onboarding Workloads**(새 워크로드가 FinOps 체계 안에 들어오는 프로세스)다.

2장 · FOCUS 1.0 — 클라우드 청구서의 공통 언어

FOCUS(FinOps Open Cost and Usage Specification) 1.0은 2024년 6월에 GA가 됐고, 2026년 현재 1.2 로드맵이 논의 중이다. 핵심은 **모든 클라우드의 청구서를 동일한 컬럼 스키마로 만든다**는 것이다.

| 컬럼 | 의미 |

| --- | --- |

| `BilledCost` | 실제 청구된 비용 (RI/SP 할인 반영 후) |

| `EffectiveCost` | 약정·선결제를 기간 안분한 후의 실제 단가 |

| `ListCost` | 할인 전 정가 |

| `ContractedCost` | 약정 단가 |

| `ServiceCategory` | Compute / Storage / Networking / AI and Machine Learning ... |

| `ChargeCategory` | Usage / Purchase / Tax / Credit / Adjustment |

| `BillingPeriodStart/End` | 청구 기간 |

| `ResourceId`, `ResourceType` | 리소스 식별자 |

| `Tags` | k=v 페어 (정규화된) |

| `SkuId`, `SkuPriceId` | SKU 식별자 |

2026년 의미는 이렇다. AWS CUR(Cost and Usage Report), GCP BigQuery Billing Export, Azure Cost Management Export가 전부 FOCUS 1.0으로 출력 가능하다. 즉 **하나의 SQL 쿼리로 세 클라우드를 보는 게 가능해졌다**. Vantage·Cloudability·Anodot·Finout 같은 SaaS는 더 이상 "공급사별 파서"를 유지하지 않아도 된다.

-- FOCUS 1.0 통합 쿼리 — 멀티클라우드 비용 Top-10 서비스

SELECT

ServiceCategory,

ServiceName,

ProviderName,

SUM(EffectiveCost) AS cost_usd

FROM focus_billing

WHERE BillingPeriodStart >= '2026-05-01'

AND BillingPeriodEnd < '2026-06-01'

GROUP BY 1, 2, 3

ORDER BY cost_usd DESC

LIMIT 10;

3장 · Kubecost — 쿠버네티스 비용을 namespace/pod까지 쪼개기

Kubecost는 2024년 IBM에 인수된 후에도 OSS 버전이 유지되고 있다. 핵심은 **쿠버네티스 비용을 cluster → namespace → deployment → pod 단위로 할당**하는 것이다.

배포는 단순하다.

helm repo add kubecost https://kubecost.github.io/cost-analyzer/

helm install kubecost kubecost/cost-analyzer \

--namespace kubecost --create-namespace \

--set kubecostToken="$(echo helm-install@kubecost.com | base64)"

설치하면 다음이 들어온다.

- `cost-analyzer` (UI + API)

- `kube-state-metrics`, `prometheus`, `node-exporter` (메트릭 수집)

- Network Costs Daemonset (선택 — 클러스터 내·외 트래픽 비용)

Allocation API 호출 예시:

지난 7일 동안 namespace별 비용

curl -G "http://kubecost.local/model/allocation" \

--data-urlencode "window=7d" \

--data-urlencode "aggregate=namespace" \

--data-urlencode "accumulate=true" \

| jq '.data | to_entries | map({name:.key, cost:.value.totalCost}) | sort_by(.cost) | reverse'

핵심 컨셉:

- **Allocation**: 어떤 워크로드가 얼마를 썼나 (cpuCost, ramCost, gpuCost, pvCost, networkCost).

- **Asset**: 클러스터에 실제로 청구된 리소스 (노드, 디스크, LB).

- **Cloud Integration**: 클라우드 청구서를 가져와 노드의 실제 단가로 보정. 미설정 시 on-demand list price 사용 → 실제 청구서와 차이.

자주 놓치는 부분: **idle cost**(노드는 떠 있지만 파드가 안 도는 시간)와 **shared cost**(kube-system, monitoring 같은 공용 비용)의 분배 정책이다. Kubecost는 4가지 정책을 제공한다 — `evenly` (균등 분배), `proportional` (사용량 비례), `weighted` (가중치), `none` (분배 안 함).

4장 · OpenCost — Kubecost의 OSS 코어, CNCF Sandbox

OpenCost는 Kubecost의 비용 할당 엔진을 CNCF에 기증한 프로젝트다. 2022년 출범 후 2024년 Incubating 단계로 승격됐다. 2026년 현재 `kubectl cost` 플러그인까지 안정화됐다.

Kubecost와의 관계:

- OpenCost = 알고리즘 + 메트릭 + API.

- Kubecost = OpenCost + UI + 멀티클러스터 + 리포팅 + 알람 + SaaS.

Prometheus exporter로 동작하므로 Grafana 대시보드를 직접 만들 수 있다.

네임스페이스별 시간당 비용 (USD)

sum by (namespace) (

node_namespace_pod_container:container_cpu_usage_seconds_total:sum_irate

* on(node) group_left

node_cpu_hourly_cost

)

+ sum by (namespace) (

container_memory_working_set_bytes / 1024 / 1024 / 1024

* on(node) group_left

node_ram_hourly_cost

)

OpenCost의 의의는 **벤더 종속이 없는 비용 표준**이다. AWS·GCP·Azure 가격표를 OpenCost가 들고 있고, Kubecost·Vantage·CAST AI 같은 상용 도구도 내부적으로 OpenCost 메트릭을 따른다.

5장 · Vantage — 멀티클라우드 비용의 통합 UI

Vantage는 2020년 출범한 SaaS다. 강점은 **UI/UX**와 **빠른 통합**이다. AWS·GCP·Azure·Snowflake·Datadog·MongoDB Atlas·Databricks·Fastly까지 청구서를 한 화면에 모은다.

핵심 기능:

- **Cost Reports**: 슬라이스/다이스가 직관적. dimension(account, service, region, tag)을 추가하고 시계열 그래프로 본다.

- **Active Resources**: 실제로 청구를 발생시키는 리소스만 보여준다. 빈 EBS 같은 자원 정리에 유용.

- **Anomalies**: 비정상 비용 스파이크 감지. 알람을 Slack/PagerDuty로 보낸다.

- **Autopilot**: AWS Compute Savings Plans 자동 구매·관리 (선택적, 수수료 모델).

- **Network Flow Reports**: 데이터 전송 비용 분석. 어디서 어디로 얼마나 나가는지 보인다.

2026년에 추가된 큰 기능은 **FOCUS 1.0 네이티브 뷰**와 **AI Cost** 대시보드 (OpenAI/Anthropic/Bedrock 통합)다.

가격은 사용량에 따른 % 모델 (관리 비용의 ~0.5-2% 수준).

6장 · Cloudability (Apptio·IBM) — 엔터프라이즈 FinOps의 노장

Cloudability는 2011년 출범한 가장 오래된 클라우드 비용 SaaS다. 2019년 Apptio가 인수, 2024년 IBM이 Apptio를 인수. 즉 현재는 IBM 산하 제품이다.

특징:

- **TBM(Technology Business Management)** 통합. IT 자산을 비즈니스 가치 단위로 매핑하는 IBM·Apptio 방법론.

- **Containers (Cloudability Containers)**: Kubecost와 유사한 컨테이너 비용 할당. EKS/AKS/GKE 지원.

- **Rightsizing 추천**: ML 기반 EC2/RDS 다운사이즈.

- **Reserved Instance Planner**: RI/SP 시뮬레이션. 1년·3년, 부분/전체 선결제 옵션 비교.

- **True Cost**: 직접 비용 + 간접 비용(엔지니어 인건비, 라이선스) 합산.

언제 Cloudability를 쓰나: **연 $1M 이상 클라우드 지출**과 **여러 BU/cost center**를 관리하는 엔터프라이즈. 차지백·쇼백·예산 워크플로우가 강하다. 반대로 스타트업·중견기업은 Vantage 쪽이 가성비.

7장 · Spot.io (NetApp) — 스팟 자동화의 원조 Ocean

Spot.io는 2020년 NetApp이 인수했다. 핵심 제품 두 가지.

- **Elastigroup**: EC2/GCE/Azure VM의 스팟·온디맨드 믹스 자동 관리. 인터럽션 예측 ML 모델로 워크로드를 자동 마이그레이션.

- **Ocean**: 쿠버네티스 노드 자동 관리. Cluster Autoscaler 대체.

Ocean의 동작:

1. 파드의 요청(CPU/메모리/GPU)을 분석.

2. 가장 비용 효율적인 인스턴스 타입을 선택해 노드를 띄움.

3. 스팟 활용률을 극대화 (목표 % 설정 가능).

4. 인터럽션 임박 시 워크로드를 다른 노드로 미리 옮김(Spot Interruption Predictor).

차별점: **headroom 자동 관리**, **right-sizing 추천을 직접 적용**(Ocean Rebalance), **VNG(Virtual Node Group)**로 워크로드별 분리 관리.

2026년 현재 Karpenter가 부상하면서 Ocean의 점유율은 정체지만, **멀티클라우드 + 비-Kubernetes**도 자동화하려는 팀에게는 여전히 강력한 선택지다.

8장 · CAST AI — 자동 리밸런싱과 Commitments

CAST AI는 2019년 출범, 빠르게 성장한 후발 주자다. 강점은 **자동화의 적극성**과 **클라우드 추상화**.

핵심 기능:

- **Autoscaler**: Karpenter와 유사하게 파드 요구를 직접 보고 노드를 띄움. Cluster Autoscaler 대체.

- **Rebalancer**: 주기적으로 클러스터를 분석, 더 싼 인스턴스로 워크로드를 옮긴다. 다운타임 없이.

- **Spot Automation**: 스팟·온디맨드 자동 믹스. 인터럽션 핸들링 내장.

- **Commitments Engine**: RI/SP 자동 구매 추천 + 자동 매니지먼트.

- **Multi-cloud**: AWS/GCP/Azure 동일 UI.

설정 예 (CAST AI 클러스터 연결 후 Helm):

castai-cluster-controller values.yaml

apiKey:

key: $CAST_AI_API_KEY

clusterID: $CAST_AI_CLUSTER_ID

autoscaling:

enabled: true

unschedulablePods:

enabled: true

nodeDownscaler:

enabled: true

emptyNodes:

delaySeconds: 60

spotInstances:

enabled: true

spotDiversityEnabled: true

spotInterruptionPredictionsEnabled: true

2026년 차별점은 **AI Workload Optimizer** — GPU 워크로드의 utilization 측정과 right-sizing 추천을 자동화한다. NVIDIA DCGM 메트릭을 활용.

9장 · Karpenter vs Cluster Autoscaler — 2026년의 표준은 누구

Cluster Autoscaler(CA)는 쿠버네티스 표준 노드 오토스케일러다. **Auto Scaling Group을 통해** 노드를 늘리고 줄인다. 단점: ASG는 인스턴스 타입이 고정. 워크로드가 다양하면 여러 ASG를 만들고, 각 ASG에 priority를 줘야 한다.

Karpenter는 AWS가 2021년 출범, 2024년 v1.0 GA. 2026년 현재 **EKS의 기본 오토스케일러로 자리 잡았고, Azure(AKS Karpenter Provider)와 GCP에도 포팅됐다.**

차이는 본질적이다:

| 차원 | Cluster Autoscaler | Karpenter |

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

| 동작 | 미리 만든 ASG 스케일 | 파드 요구에 맞춰 노드 직접 프로비저닝 |

| 인스턴스 선택 | 단일/제한적 | 광범위 (다양성 = 가용성 + 비용) |

| 스팟 대응 | ASG mixed instances 정책 | 네이티브 |

| 통합 추상화 | ClusterAutoscaler CR | NodePool + EC2NodeClass |

| 노드 시작 시간 | ~3-4분 | ~40초 |

| 단편화 정리 | 어렵다 (drift) | consolidation이 자동 |

NodePool 예시:

apiVersion: karpenter.sh/v1

kind: NodePool

metadata:

spec:

template:

metadata:

labels:

intent: apps

spec:

requirements:

- key: kubernetes.io/arch

operator: In

values: ["amd64", "arm64"]

- key: kubernetes.io/os

operator: In

values: ["linux"]

- key: karpenter.sh/capacity-type

operator: In

values: ["spot", "on-demand"]

- key: karpenter.k8s.aws/instance-category

operator: In

values: ["c", "m", "r"]

- key: karpenter.k8s.aws/instance-generation

operator: Gt

values: ["5"]

nodeClassRef:

group: karpenter.k8s.aws

kind: EC2NodeClass

limits:

cpu: 1000

memory: 1000Gi

disruption:

consolidationPolicy: WhenEmptyOrUnderutilized

consolidateAfter: 30s

핵심은 `consolidationPolicy: WhenEmptyOrUnderutilized` — 미사용 노드를 자동으로 정리한다. CA에선 직접 만들기 어려운 기능이다.

2026년의 선택은: **AWS EKS면 Karpenter**, **GCP GKE면 GKE Autopilot 또는 Karpenter GCP**, **AKS면 Karpenter Provider**, **자동화를 더 원하면 CAST AI/Ocean**.

10장 · 스팟 인스턴스 — 인터럽션을 디자인에 녹이기

스팟 인스턴스는 평균 70-90% 할인이다. 단점: 2분(AWS)·30초(GCP preemption)·30초(Azure)에 회수당할 수 있음.

스팟 디자인 원칙:

1. **인스턴스 다양화**. 한 타입에 몰지 말 것. AWS는 "spot allocation strategy: price-capacity-optimized"가 표준.

2. **graceful shutdown**. PreStop hook, terminationGracePeriodSeconds, in-flight 요청 drain.

3. **체크포인트**. 장시간 잡은 진행 상황을 S3에 주기적으로 저장.

4. **AZ 다양화**. 한 AZ에서 spot이 마르면 다른 AZ로.

5. **스테이트풀 워크로드는 신중하게**. RDS·OpenSearch는 RI. Kafka·Cassandra는 가능하지만 인터럽션 핸들링 필수.

6. **Interruption Handler**. AWS Node Termination Handler(NTH), GKE의 spot preemption handler.

NTH 배포:

helm repo add eks https://aws.github.io/eks-charts

helm install aws-node-termination-handler eks/aws-node-termination-handler \

--namespace kube-system \

--set enableSpotInterruptionDraining=true \

--set enableRebalanceMonitoring=true \

--set enableRebalanceDraining=true \

--set queueURL=$NTH_SQS_QUEUE_URL

2026년 통계: 잘 디자인된 스팟 클러스터는 비용을 60-80% 깎는다. 잘못 디자인하면 인터럽션으로 SLA를 깬다. 그래서 **batch·CI·dev·stateless API는 스팟, 데이터베이스·세션 스토어·결제는 온디맨드**가 일반적 분할이다.

11장 · Reserved Instance vs Savings Plans vs Spot — 약정의 3종 비교

AWS는 세 가지 할인 옵션이 있다. 2026년 현재 정리.

| 옵션 | 할인 | 약정 단위 | 유연성 | 양도 |

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

| Convertible RI | 최대 54% | 인스턴스 패밀리 교환 가능 | 중간 | 불가 |

| EC2 Instance Savings Plan | 최대 72% | 인스턴스 패밀리 + 리전 | 낮음 | 불가 |

2026년의 실전 권고:

- **베이스라인은 Compute Savings Plan**. 유연성이 가장 크다.

- **장기 고정 워크로드 (DB, control plane) 는 Standard RI 1년 또는 3년**.

- **버스트와 dev/CI/batch는 Spot**.

- **GPU 워크로드는 SP Compute 또는 Capacity Block**.

GCP는 Committed Use Discounts(CUD)와 Sustained Use Discounts, Azure는 Reservation과 Savings Plan으로 비슷한 모델. FOCUS 1.0의 `CommitmentDiscountType` 컬럼이 이 셋을 통합한다.

12장 · 쿠버네티스 리소스 right-sizing — request·limit의 미신

흔한 misconception: "limit을 높게 두면 안전하다." 실제로는 reverse — **limit이 높으면 노드 패킹이 비효율적**이 되어 비용이 늘어난다. 그리고 CPU limit은 throttling을 일으켜 latency를 망친다.

2026년의 right-sizing 권고:

1. **CPU limit은 두지 마라** (Tim Hockin의 오랜 입장). throttling은 latency 살인. 노드 패킹은 request로 한다.

2. **Memory limit은 둬라**. 메모리 누수 보호. request = limit이 가장 안전.

3. **request는 P95-P99 실제 사용량 기준**. Prometheus에서 90일 데이터로 산정.

4. **VPA in `Off` mode for recommendations**, **VPA in `Auto` mode는 위험**. 재시작이 발생함.

PerfectScale·Densify·CAST AI의 right-sizing 추천은 이 데이터를 자동으로 본다.

VPA recommendation 추출:

kubectl get vpa my-app -o jsonpath='{.status.recommendation}'

{"containerRecommendations":[{"containerName":"app",

"lowerBound":{"cpu":"50m","memory":"100Mi"},

"target":{"cpu":"100m","memory":"200Mi"},

"upperBound":{"cpu":"200m","memory":"400Mi"}}]}

13장 · LLM/GPU 비용 — per-token 경제학

2026년 가장 빠르게 성장하는 비용 카테고리는 LLM 추론이다. 자체 GPU(EKS H100, GCP a3-highgpu, Azure ND H100 v5)냐, API(OpenAI, Anthropic, Bedrock, Vertex AI)냐.

API 가격 (2026년 5월 시점 대표값):

| 모델 | input $/1M tok | output $/1M tok |

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

| GPT-5 (OpenAI) | $5.00 | $15.00 |

| Claude Opus 4.7 | $15.00 | $75.00 |

| Claude Sonnet 4.6 | $3.00 | $15.00 |

| Gemini 2.5 Pro | $2.50 | $10.00 |

| GPT-4o-mini | $0.15 | $0.60 |

자체 호스팅 비용 (H100 SXM):

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

| AWS p5.48xlarge | 8xH100 | $98.32 | ~$70 |

| GCP a3-highgpu-8g | 8xH100 | $88.50 | ~$60 |

| Azure ND H100 v5 | 8xH100 | $91.00 | ~$65 |

per-token 경제학 공식:

$/1M tok (셀프 호스팅) = (시간당 비용 / 시간당 처리 토큰) * 1M

시간당 처리 토큰 = throughput tok/s * 3600

vLLM·SGLang·TensorRT-LLM의 throughput을 측정해 break-even point를 찾아야 한다. 일반적으로 **`<10M tok/일` = API**, **`10M-1B tok/일` = 하이브리드**, **`>1B tok/일` = 셀프 호스팅 검토** 정도.

비용 가시화:

- **Helicone**, **Langfuse**, **LangSmith**가 API 호출별 비용을 추적.

- **OpenAI Usage Dashboard**가 프로젝트·API key별 토큰 사용량 분리.

- **Kubecost GPU Allocation**이 셀프 호스팅 GPU 활용률을 namespace로 분배.

14장 · S3 스토리지 클래스 — 정책 한 줄로 60% 절감

S3 비용은 두 가지: 스토리지 + 요청·전송. 스토리지 클래스 정책을 안 짜면 누적된다.

2026년 S3 스토리지 클래스 (USD/GB-month, 대표값):

| 클래스 | 가격 | 액세스 패턴 |

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

| Standard | $0.023 | 빈번 |

| Standard-IA | $0.0125 | 월 1회 이하 |

| One Zone-IA | $0.01 | 비중요·복원 가능 |

| Intelligent-Tiering | $0.023 + 모니터링비 | 패턴 불명 |

| Glacier Instant Retrieval | $0.004 | 분기 1회 |

| Glacier Flexible Retrieval | $0.0036 | 연 1회, 분-시간 단위 복원 |

| Glacier Deep Archive | $0.00099 | 7-10년 보관 |

라이프사이클 정책 예시:

{

"Rules": [

{

"ID": "logs-lifecycle",

"Status": "Enabled",

"Filter": { "Prefix": "logs/" },

"Transitions": [

{ "Days": 30, "StorageClass": "STANDARD_IA" },

{ "Days": 90, "StorageClass": "GLACIER_IR" },

{ "Days": 365, "StorageClass": "DEEP_ARCHIVE" }

"Expiration": { "Days": 2555 }

{

"ID": "incomplete-mpu-cleanup",

"Status": "Enabled",

"AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }

}

]

}

흔한 누수 두 가지: (1) **incomplete multipart upload** — 업로드 실패 잔여물이 스토리지 비용에 잡힌다. 위 규칙으로 7일 후 삭제. (2) **버전 관리 켜놓고 만료 정책 없음** — 옛 버전이 무한히 쌓인다.

15장 · 데이터 egress — 숨은 비용의 1등

데이터 송신(egress)은 청구서를 보기 전에는 안 보인다. 그런데 잘못 디자인하면 컴퓨트보다 비싸진다.

대표 단가 (2026년):

| 경로 | $/GB |

| --- | --- |

| AWS → 인터넷 | $0.09 (첫 10TB) |

| AWS 리전 간 | $0.02 |

| AWS AZ 간 | $0.01 |

| GCP → 인터넷 | $0.12 |

| GCP 리전 간 | $0.01-0.08 |

| Azure → 인터넷 | $0.087 |

| CloudFront → 인터넷 | $0.085 (북미·유럽) |

설계 원칙:

1. **데이터를 같은 AZ에 두라**. RDS·EKS·캐시가 다른 AZ면 AZ 간 트래픽 비용이 누적.

2. **VPC Endpoint (PrivateLink)**. S3·DynamoDB는 Gateway Endpoint로 무료. SNS·SQS는 Interface Endpoint($0.01/hr).

3. **CDN을 최대한 활용**. CloudFront, Cloudflare, Fastly의 origin egress 할인.

4. **Cross-region replication은 비용 인지**. S3 CRR은 동일 클래스로 복제 시 transfer + storage 이중.

5. **VPC Flow Logs로 monitoring**. AWS Cost Explorer는 source를 안 줘서 어디서 가는지 모름. Flow Logs로 source IP 분석.

Kubecost의 Network Costs Daemonset이 이 영역을 클러스터 안에서 자동 측정한다.

16장 · RDS 비용 — RI 수학과 read replica 함정

RDS 비용은 인스턴스 + 스토리지 + IOPS + 백업 + 데이터 전송이다. 약정으로 50-70% 깎을 수 있다.

RI 수학 예시 — db.r6g.4xlarge (us-east-1):

- 온디맨드: $1.36/hr → 3년 = $35,750

- 1년 No Upfront RI: $0.85/hr → $7,446

- 3년 All Upfront RI: $0.43/hr → $11,300 (선결제), break-even ~17개월

권고:

- **프로덕션 DB는 항상 약정**. on-demand RDS는 stage·dev에만.

- **3년 All Upfront**가 가장 큰 할인이지만, **워크로드 안정성을 보고 결정**.

- **read replica도 RI 적용 가능**. write/read 둘 다 약정.

- **Aurora I/O-Optimized vs Standard**: I/O 헤비면 I/O-Optimized로 전환하면 IOPS 청구 사라짐.

- **Reserved Capacity (Aurora Serverless v2 → Aurora Capacity Units, ACU)** — 2026년 ACU에도 1년 약정 옵션이 들어옴.

- **Blue/Green 배포로 DB 업그레이드**. EOL 인스턴스는 가격이 오른다.

17장 · 비용 거버넌스 — OPA·Kyverno로 가드레일

비용을 "본다"에서 "막는다"로 가려면 정책이 필요하다. 2026년 표준은 OPA(Open Policy Agent) 또는 Kyverno.

Kubernetes Gatekeeper 예 — limit 없는 파드를 막는다.

apiVersion: constraints.gatekeeper.sh/v1beta1

kind: K8sRequiredResources

metadata:

spec:

match:

kinds:

- apiGroups: [""]

kinds: ["Pod"]

namespaces: ["prod", "stage"]

parameters:

requests: ["cpu", "memory"]

limits: ["memory"]

Terraform-level 정책 — 비싼 인스턴스 차단 (OPA Conftest):

package terraform.cost

deny[msg] {

resource := input.resource.aws_instance[name]

blocked := {"p5.48xlarge", "p4d.24xlarge"}

resource.instance_type == blocked[_]

not has_approval_tag(resource)

msg := sprintf("Instance %s requires CostApprover tag", [name])

}

has_approval_tag(r) {

r.tags.CostApprover != ""

}

조직 수준의 가드:

- **태깅 강제**. CostCenter·Project·Environment·Owner.

- **예산 알람**. AWS Budgets, GCP Budgets, Azure Cost Alerts.

- **Anomaly Detection**. AWS Cost Anomaly Detection, Vantage Anomalies.

- **Auto-shutdown for dev**. 야간·주말 dev 환경 정지.

18장 · 단위 경제학 — $/request, $/user, $/feature

FinOps의 궁극 지표는 **단위 경제학**이다. 청구서 절대값은 의미가 적다 — "사용자 1명을 서빙하는 데 얼마인가"가 의미다.

흔한 단위:

- **$/request**: API 비용을 호출 수로 나눔.

- **$/user**: 월간 활성 사용자 1명당 인프라 비용.

- **$/transaction**: 결제·주문 같은 핵심 비즈니스 트랜잭션당.

- **$/feature**: 한 기능을 운영하는 데 드는 비용 (멀티 서비스 분배 필요).

- **$/1M token**: LLM 워크로드.

대시보드 설계:

[추세] 월별 $/MAU ── 단위 경제학이 좋아지는지

[분해] 서비스별 $/request ── 어디서 비효율

[알람] 단위 경제학이 +20% 시 ── 회귀 감지

이게 안 되면 트래픽 증가에 비용이 선형으로 따라간다. 잘 되면 트래픽 2배에 비용 1.3배 (규모의 경제) 같은 그래프가 나온다.

19장 · 한국 사례 — 우아한형제들·라인·카카오

한국 빅테크의 FinOps 사례.

- **우아한형제들**: 2023년부터 FinOps 팀을 별도 운영. Kubecost 사내 포크 + 자체 단위 경제학 대시보드(주문 1건당 인프라 비용)를 구축. 2024년 컨퍼런스에서 "주문 1건당 비용을 30% 깎았다"라고 발표.

- **라인 (LINE Plus)**: 글로벌 메시지 트래픽이 거대 → 자체 PoP + 클라우드 하이브리드. 2025년부터 LLM 추론 비용 가시화를 위해 자체 토큰 트래커 구축, Helicone/Langfuse 패턴 차용.

- **카카오**: 멀티클라우드 (AWS+GCP+Naver Cloud) → FOCUS 1.0 도입으로 통합 청구서. 사내 BigQuery에서 단일 SQL로 본다.

- **쿠팡**: AWS 헤비. Reserved Instance·Savings Plan 자동 매니지먼트 SaaS 도입 후 RI utilization 95%+ 유지.

- **토스**: Karpenter 조기 도입(2022년), 스팟 비율 80%+. 결제는 온디맨드, 그 외는 스팟.

공통점: (1) FinOps를 재무가 아니라 **엔지니어링 KPI**로 본다. (2) 단위 경제학 대시보드를 갖춘다. (3) 가시성 → 자동화 순서.

20장 · 일본 사례 — NTT Docomo·楽天·LINE

일본의 FinOps도 빠르게 자리잡고 있다.

- **NTT Docomo**: 통신 백엔드의 대규모 AWS 사용. 2024년 FinOps Foundation 일본 챕터에서 사례 발표 — "태깅·차지백을 강제하니 미사용 RI가 40% 줄었다."

- **楽天 (Rakuten)**: 오랜 자체 데이터센터에서 GCP·AWS 멀티클라우드로 이동 중. Cloudability(Apptio) + 자체 도구 조합.

- **LINE 도쿄**: 한국 LINE Plus와 별개로 일본 LINE은 NHN·소프트뱅크 그룹의 워크로드와 통합. Spot.io Ocean을 광범위 활용.

- **CyberAgent**: 광고 플랫폼이 대규모 BigQuery 사용 → Vantage로 BigQuery 슬롯 비용 가시화 + 워크로드 스케줄링.

- **メルカリ (Mercari)**: GKE 헤비. GKE Autopilot 적극 활용, Kubecost로 namespace 단위 차지백.

문화 차이: 일본 기업은 **차지백·예산 거버넌스**에 더 무게. 한국 기업은 **자동화·right-sizing**에 더 빠르다는 평. 둘 다 2026년에는 FOCUS 1.0 도입이 표준.

21장 · 오픈소스 vs SaaS FinOps 도구 — 선택 기준

| 항목 | 오픈소스 (OpenCost+Grafana, Komiser) | SaaS (Kubecost SaaS, Vantage, Cloudability) |

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

| 초기 비용 | 0 | $1k-50k/mo |

| 운영 비용 | 엔지니어 시간 | 라이선스 |

| 셋업 시간 | 1-2주 | 1-2일 |

| 멀티클라우드 | 직접 통합 | 내장 |

| 차지백 워크플로우 | 직접 구현 | 내장 |

| 알람·anomaly | 직접 구축 | 내장 ML |

| 데이터 보안 | 자체 인프라 | 외부 SaaS (선택 사항) |

권고:

- **연 클라우드 지출 `<$500k`**: 오픈소스로 시작 — OpenCost + Grafana + 클라우드 네이티브 (Cost Explorer/Recommender/Cost Mgmt) 조합.

- **연 `$500k-3M`**: Vantage 같은 SaaS — 운영 부담 vs 라이선스 비교.

- **연 `>$3M`**: Cloudability/Anodot/Apptio 같은 엔터프라이즈 + 자동화(CAST AI, Spot.io).

여기서 함정: **도구를 산다고 비용이 깎이지 않는다.** 도구는 가시화만 한다. 깎는 건 사람의 결정. 그래서 FinOps Foundation은 항상 "도구 < 문화"를 강조한다.

22장 · 안티패턴 — FinOps가 실패하는 7가지 이유

현장에서 자주 보는 실패 패턴.

1. **태깅이 자율**. CostCenter 태그가 옵션이면 50%가 누락된다. 강제하지 않으면 안 된다.

2. **재무팀만 본다**. 엔지니어가 비용 대시보드에 접근 안 하면 의사결정이 안 된다.

3. **RI를 먼저 산다**. workload pattern 모른 채 산 RI는 흑자가 안 된다.

4. **right-sizing만 한다**. 60% 절감은 right-sizing 아니라 아키텍처(스팟, 캐시, S3 클래스).

5. **anomaly alarm을 무시한다**. 알람이 너무 많아서 끄는 순간 진짜 누수도 놓친다.

6. **단위 경제학을 안 본다**. 절대 비용만 보면 트래픽 증가가 비용 증가로 보일 뿐.

7. **GPU·LLM을 다른 카테고리로 본다**. 2026년에는 AI 비용이 인프라 비용의 30-50%다. 별도 관리 안 하면 폭발.

23장 · 90일 FinOps 도입 로드맵

처음 FinOps를 시작하는 팀을 위한 단계.

**Days 1-30 (Inform)**

1. CUR/Billing Export → BigQuery/Snowflake/S3로 파이프라인.

2. FOCUS 1.0 컬럼으로 정규화.

3. 핵심 dimension 정의 (Account, Service, Environment, Team).

4. 태깅 정책 발표, 미태깅 비율 측정.

5. Kubecost/OpenCost 설치 → Kubernetes 비용 가시화.

6. 주간 비용 리뷰 미팅 시작.

**Days 31-60 (Optimize)**

1. Top-10 비용 워크로드 식별.

2. right-sizing 추천 검토 (VPA·CAST AI·PerfectScale).

3. 미사용 자원 정리 (빈 EBS, idle ELB, 오래된 스냅샷).

4. S3 라이프사이클 정책 도입.

5. RI/SP 첫 구매 (보수적, 1년 약정).

6. dev/CI 환경의 야간 자동 정지.

**Days 61-90 (Operate)**

1. 비용 알람 (Anomaly Detection, 단위 경제학 회귀).

2. OPA/Kyverno로 정책 시행.

3. 차지백/쇼백 리포팅 BU별 발송.

4. KPI 정의 (`$/MAU`, `$/request`, RI utilization 목표).

5. FinOps 챔피언 임명 (각 팀당 1명).

6. 분기 비용 OKR로 통합.

24장 · 2027년 전망 — AI 워크로드와 sustainability

향후 1-2년의 트렌드.

1. **AI 비용이 1번 카테고리가 된다**. 2027년에는 많은 기업에서 AI 청구서 > 일반 컴퓨트 청구서.

2. **per-token SLO**. 응답 시간 SLO처럼 "사용자당 토큰 비용" SLO가 일반화.

3. **FOCUS 1.x → 2.0**. 1.1에서는 commitment 모델 표준화, 2.0에서는 carbon 메트릭 통합.

4. **Sustainability 통합**. 비용 = $ + CO2. AWS Customer Carbon Footprint, GCP Carbon Footprint, Azure Emissions Impact의 FOCUS 통합.

5. **자율 FinOps (autonomous FinOps)**. CAST AI·Spot.io 같은 자동화가 더 깊어진다 — 사람의 승인 없이 클러스터를 재배치.

6. **AI 에이전트 기반 FinOps 분석**. "왜 지난주 비용이 늘었어?"를 LLM이 데이터 분석으로 답.

7. **Edge·CDN 비용의 부상**. 엣지 컴퓨팅과 AI 추론이 엣지로 이동하면서 새로운 비용 카테고리.

마무리: 2026년 FinOps는 더 이상 "재무팀이 비용 보고서를 만든다"가 아니다. **엔지니어링 조직의 가드레일이고, 단위 경제학이 회사 OKR**이다. 도구는 OpenCost·Vantage·CAST AI 같은 좋은 옵션이 충분하다. 부족한 건 항상 **문화와 실행**이다.

References

- FinOps Foundation Framework — [https://www.finops.org/framework/](https://www.finops.org/framework/)

- FOCUS Specification — [https://focus.finops.org/](https://focus.finops.org/)

- Kubecost — [https://www.kubecost.com/](https://www.kubecost.com/)

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

- Vantage — [https://www.vantage.sh/](https://www.vantage.sh/)

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

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

- CAST AI — [https://cast.ai/](https://cast.ai/)

- Karpenter — [https://karpenter.sh/](https://karpenter.sh/)

- Kubernetes Cluster Autoscaler — [https://github.com/kubernetes/autoscaler](https://github.com/kubernetes/autoscaler)

- AWS Cost Explorer — [https://aws.amazon.com/aws-cost-management/aws-cost-explorer/](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)

- AWS Savings Plans — [https://aws.amazon.com/savingsplans/](https://aws.amazon.com/savingsplans/)

- GCP Recommender — [https://cloud.google.com/recommender](https://cloud.google.com/recommender)

- Azure Cost Management — [https://azure.microsoft.com/en-us/products/cost-management/](https://azure.microsoft.com/en-us/products/cost-management/)

- PerfectScale — [https://www.perfectscale.io/](https://www.perfectscale.io/)

- Densify — [https://www.densify.com/](https://www.densify.com/)

- AWS Node Termination Handler — [https://github.com/aws/aws-node-termination-handler](https://github.com/aws/aws-node-termination-handler)

- Open Policy Agent (Gatekeeper) — [https://open-policy-agent.github.io/gatekeeper/](https://open-policy-agent.github.io/gatekeeper/)

- Kyverno — [https://kyverno.io/](https://kyverno.io/)

- vLLM — [https://docs.vllm.ai/](https://docs.vllm.ai/)

- Helicone — [https://www.helicone.ai/](https://www.helicone.ai/)

- Langfuse — [https://langfuse.com/](https://langfuse.com/)