클라우드 비용 최적화 & FinOps 2026 — Kubecost·OpenCost·Vantage·Cloudability·Spot.io·CAST AI·Karpenter 심층 가이드

프롤로그 — "왜 청구서가 또 늘었지?"는 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 로드맵이 논의 중이다. 핵심은 모든 클라우드의 청구서를 동일한 컬럼 스키마로 만든다는 것이다.

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에도 포팅됐다.

차이는 본질적이다:

NodePool 예시:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
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
        name: default
  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년 현재 정리.

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월 시점 대표값):

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

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, 대표값):

라이프사이클 정책 예시:

{
  "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년):

설계 원칙:

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:
  name: must-have-requests-limits
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 도구 — 선택 기준

권고:

• 연 클라우드 지출 <$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/
• FOCUS Specification — https://focus.finops.org/
• Kubecost — https://www.kubecost.com/
• OpenCost CNCF Project — https://www.opencost.io/
• Vantage — https://www.vantage.sh/
• Cloudability (Apptio/IBM) — https://www.apptio.com/products/cloudability/
• Spot.io by NetApp — https://spot.io/
• CAST AI — https://cast.ai/
• Karpenter — https://karpenter.sh/
• Kubernetes Cluster Autoscaler — https://github.com/kubernetes/autoscaler
• AWS Cost Explorer — https://aws.amazon.com/aws-cost-management/aws-cost-explorer/
• AWS Savings Plans — https://aws.amazon.com/savingsplans/
• GCP Recommender — https://cloud.google.com/recommender
• Azure Cost Management — https://azure.microsoft.com/en-us/products/cost-management/
• PerfectScale — https://www.perfectscale.io/
• Densify — https://www.densify.com/
• AWS Node Termination Handler — https://github.com/aws/aws-node-termination-handler
• Open Policy Agent (Gatekeeper) — https://open-policy-agent.github.io/gatekeeper/
• Kyverno — https://kyverno.io/
• vLLM — https://docs.vllm.ai/
• Helicone — https://www.helicone.ai/
• Langfuse — https://langfuse.com/