- Published on
데이터·AI FinOps 2025 완전 정복: Snowflake·Databricks·BigQuery 비용 해부, 웨어하우스 튜닝으로 50% 절감, LLM·GPU 비용 관리, Reserved vs On-Demand, Showback·Chargeback, OpenCost·Vantage·CloudZero 비교, 탄소발자국
- Authors

- Name
- Youngju Kim
- @fjvbn20031
프롤로그 · 돈 쓰는 법을 모르면 가장 먼저 잘린다
2023년 말부터 시작된 SaaS·빅테크 긴축은 2024-2025년 내내 이어졌다. 가장 먼저 타격을 받은 조직은 어디였나?
"ROI 입증이 어려운 데이터·AI 조직."
2025년 4월 현재, 한국과 미국 모두 같은 현상이 관찰된다.
- 대기업 CDO 조직 축소·CTO 산하 통합
- 스타트업 데이터팀 50% 감축, 일부 해체
- "분석가"부터 감축, DE·Platform 엔지니어는 상대적 안전
- Snowflake·Databricks 월 비용이 경영진 회의의 주요 안건
- AI 비용 폭발 (월 수억 → 십수억) 관리 실패 사례 속출
이 중 살아남은 팀의 공통점은 하나다.
"비용을 가치와 연결해 설명할 수 있는 팀."
FinOps(Financial Operations)는 클라우드·SaaS·AI 시대의 필수 역량이 됐다. 이번 글은 그 실전 지침.
1장 · FinOps의 3단계 성숙도 모델
FinOps Foundation은 조직의 성숙도를 3단계로 구분한다.
(1) Crawl (기어가기)
- 비용 가시성 불완전, 월말 청구서 보고 놀람
- 부서·프로젝트별 비용 분리 안 됨
- 태깅 체계 부재
- "비싼가?"만 아는 수준
(2) Walk (걷기)
- 비용 태깅·할당이 대부분 되어 있음
- Showback(부서별 비용 공개)은 되나 Chargeback(실제 청구)은 안 됨
- Reserved Instance 일부 활용
- 월간 비용 리뷰 회의 존재
(3) Run (달리기)
- 비용이 엔지니어 일상 KPI의 일부
- 자동 이상치 탐지·경보
- Chargeback 운영
- Unit Economics 기반 의사결정 ("쿼리 1개당 비용", "사용자당 인프라 비용")
- 엔지니어가 코드 배포 전 비용 영향 예측
2025년 한국 기업의 대부분은 Crawl-Walk 사이. 성숙한 스타트업(토스·당근 등)은 Walk-Run 경계.
2장 · Snowflake 비용 해부 — 왜 갑자기 월 7억이 나오는가
Snowflake는 가장 유명한 "비용 폭발" 사례. 구조를 알아야 방어할 수 있다.
Snowflake 비용의 3요소
- Compute (가장 큰 비중, 보통 70-85%)
- Virtual Warehouse 크기 × 실행 시간 × 크레딧 단가
- 크기: XS(1 credit/hr) → 6XL(512 credit/hr)
- 크레딧 단가는 지역·Edition별 다름 (Standard ~3, Business Critical ~$4)
- Storage (보통 5-15%)
- S3 기준 월 ~20/TB (capacity)
- Data Transfer (보통 5-10%)
- Cross-region·Cross-cloud 이동
- Snowflake Cortex·AI 기능은 별도 과금
비용 폭발의 전형적 원인
원인 1: Auto-Suspend 미설정 또는 길게 설정
- 기본 10분이 많으나, 5분 / 60초로 줄이면 큰 절감
- 단, 자주 재시작하면 Warm Cache 날아감 → 성능 저하
- 권장: 사용 패턴 분석 후 1-5분
원인 2: Over-provisioned Warehouse
- 작은 쿼리를 L(Large) 웨어하우스로 실행
- XS로 충분한 쿼리를 M/L로 돌리는 습관
- 해결: 쿼리별 실행 시간·스캔 데이터 분석 → Right-sizing
원인 3: 스케줄된 dbt/ETL의 불필요한 재빌드
- 매시간 full refresh vs incremental
- 해결: dbt incremental materialization,
ON_SCHEDULE
원인 4: 무한 반복 대시보드
- Tableau 대시보드가 5분마다 Refresh. 보는 사람은 0명
- 해결: 대시보드 사용량 감사, 자동 캐싱
원인 5: Zero-Copy Clone 남발
- "일단 테스트용으로 복제" → 스토리지 증가
- 해결: TTL 정책, 자동 정리 스크립트
실전 절감 기법 (50% 감축 케이스)
케이스 연구 (한국 중견 SaaS, 월 25k):
- Auto-Suspend 10분 → 60초: -15%
- 쿼리 Tagging + 크기 조정: -20%
- Transient Table 도입 (Fail-Safe 제거): -5%
- Storage 압축 (cluster key 재설계): -5%
- 사용 안 하는 Warehouse 제거: -5%
Snowflake 전용 도구
- SELECT (select.dev): 실시간 비용·쿼리 프로파일
- Keebo: AI 기반 자동 웨어하우스 최적화
- Capital One Slingshot: 내부용이었으나 오픈소스화
- Mountebank: 비용 이상치 탐지
3장 · Databricks 비용 해부
Databricks는 구조가 다르다. DBU(Databricks Unit) × 클라우드 VM 비용 조합.
비용 요소
- DBU 비용: Databricks Platform 자체 사용료
- Workflow, DLT, SQL Warehouse, ML, Photon 등 워크로드별 단가 다름
- Cloud VM 비용: AWS EC2 / Azure VM / GCP Compute Engine
- Databricks가 실제 돌아가는 VM 비용
- Storage: Lakehouse(Delta/Iceberg) on S3/ADLS/GCS
주요 최적화 포인트
(1) Photon 사용 여부
- Photon은 2-3배 빠르지만 DBU 단가 2-2.5배
- 쿼리 성능과 비용 비교 필수
(2) Job Cluster vs All-Purpose Cluster
- Job Cluster: 작업마다 생성, 종료 (DBU 저렴)
- All-Purpose: 인터랙티브, 종일 유지 (DBU 비쌈)
- 규칙: Production ETL = Job Cluster
(3) SQL Warehouse 스케일링
- Serverless SQL Warehouse가 2024년 기본 옵션
- Auto-stop 1분 설정 가능
- Cluster size t-shirt 사이즈로 조절
(4) Spot Instance 활용
- AWS Spot / Azure Spot VM을 워커 노드로 사용
- 최대 70% 저렴, 그러나 중단 위험 있음
- ETL에 적합, Streaming엔 부적합
(5) DLT (Delta Live Tables)
- Serverless DLT가 2024-2025 기본 추천
- Auto-scaling으로 오버프로비저닝 방지
- 그러나 자체 DBU 과금 별도
Databricks 전용 도구
- Unity Catalog Cost Attribution (2024 신기능)
- System Tables (2024) — 사용량·비용 자체 분석
- Overwatch (오픈소스) — Databricks 사용량 대시보드
4장 · BigQuery 비용 해부
BigQuery는 또 다른 모델. On-Demand(스캔량) vs Editions(용량 예약).
On-Demand 모델
- 쿼리별 스캔 데이터 TB당 $5 (Standard Edition)
- 장점: 사용량 0일 땐 비용 0
- 단점: 예측 불가능, 폭주 쿼리 한 번이 월 $10k 가능
Editions 모델 (2023 이후)
- Standard / Enterprise / Enterprise Plus
- Slot 단위 예약 (Flex, 1년, 3년 약정)
- 장점: 비용 예측 가능
- 단점: 미사용 Slot 낭비 가능
2025년 주요 최적화
(1) 파티션·클러스터링 재설계
- 날짜 파티션 안 되어 있으면 무조건 설정
- 자주 필터링되는 컬럼에 클러스터링
(2) SELECT * 금지
- BigQuery는 컬럼 스토어, 실제 읽는 컬럼만 과금
SELECT *는 전체 스캔 → 비용 폭발
(3) Materialized View 적극 사용
- 자주 쓰는 집계를 미리 만들어 둠
- 자동 증분 갱신 (2024 개선)
(4) BI Engine 활용
- 대시보드 쿼리 캐싱
- Looker Studio·Tableau 성능·비용 동시 최적화
(5) Query Reservation Scheduling
- 낮엔 분석 Slot, 밤엔 ETL Slot
- 시간대별 용량 재분배
BigQuery 전용 도구
- INFORMATION_SCHEMA.JOBS — 쿼리별 스캔·비용 조회
- BigQuery Cost Analyzer (Google 공식)
- dbt-bigquery 비용 프로파일링 패키지
5장 · Storage 계층화와 Iceberg 절감
컴퓨트뿐 아니라 스토리지도 관리 대상. 대용량일수록 체감 크다.
클라우드 스토리지 티어
| 티어 (AWS S3 기준) | 단가 ($/GB/월) | Access 비용 | 용도 |
|---|---|---|---|
| Standard | 0.023 | 낮음 | 자주 접근 |
| Standard-IA | 0.0125 | 중간 | 월 1-2회 |
| Glacier Instant | 0.004 | 낮은 즉시 | 분기 1회 |
| Glacier Flexible | 0.0036 | 복원 지연 | 년 1회 |
| Glacier Deep | 0.00099 | 복원 수 시간 | 컴플라이언스 |
Iceberg로 절감하기
Iceberg 테이블은 여러 절감 기능 내장.
(1) Snapshot Expiration
- 오래된 스냅샷 자동 제거
VACUUM TABLE x OLDER_THAN 7 DAYS
(2) Compaction (작은 파일 병합)
- 수많은 작은 Parquet → 적은 수의 큰 파일
- 쿼리 성능 개선 + 메타데이터 비용 감소
(3) 컬럼 정렬·Z-Ordering
- 실제 접근 패턴 기반 파일 정렬
- 쿼리 스캔량 ↓ → 컴퓨트 비용 ↓
(4) Partition Evolution
- 사용량 변화에 따라 파티션 스키마 변경 가능
- 전체 재작성 없이
실전 사례
한국 대기업 사례 (월 S3 35k):
- Standard → Intelligent-Tiering 자동 이관: -30%
- Iceberg 테이블 도입, 이전 Parquet 테이블 아카이브: -15%
- 오래된 파티션 Glacier로 이동: -10%
6장 · Reserved Capacity vs On-Demand — 언제 무엇을
On-Demand
- 장점: 유연, 초기 비용 0, 사용량 급변에 대응
- 단점: 20-60% 비쌈
Reserved (1년/3년)
- 장점: 20-60% 할인
- 단점: 약정 묶임, 사용 안 해도 비용 발생
실전 규칙
(1) 안정적 베이스라인 60-80%는 Reserved
- 과거 6-12개월 사용량 Percentile 20 파악
- 이 수준까지 Reserved 커버
(2) 변동 부분은 On-Demand
- 계절성, 실험, 신규 워크로드
(3) Spot/Preemptible 활용 (Databricks, EMR 등)
- 재시작 내성 있는 작업에만
- 60-80% 저렴
(4) Savings Plans (AWS) 하이브리드
- Compute Savings Plans는 EC2·Fargate·Lambda 통합 할인
- 1년 약정으로 시작이 안전
Cloud별 주요 상품
- AWS: Reserved Instance, Savings Plans, Spot
- GCP: Committed Use Discount (CUD), Flex CUD, Spot VM
- Azure: Reserved Instances, Savings Plan, Spot VM
- Snowflake: Capacity Storage, Capacity Credit Pre-Purchase
- Databricks: DBCU(Databricks Commit Units) 약정
7장 · AI·LLM 비용 관리 — 2024-2025년의 새로운 전쟁
2024년 이후 폭발적으로 증가한 비용. 많은 조직이 완전히 관리 실패.
LLM API 비용 폭발의 원인
원인 1: Chain-of-Thought과 Agent Loop
- 한 사용자 질문에 LLM이 10-50번 호출
- 예상의 20-50배 비용
원인 2: 긴 Context Window 남용
- GPT-4o 128k context 전체를 매번 전송
- 프롬프트 Token 과금이 출력 Token보다 큰 경우 다수
원인 3: Caching 부재
- 같은 질문·같은 컨텍스트 반복
- Anthropic Prompt Caching, OpenAI Prompt Caching 활용 안 함
원인 4: 모델 선택 무계획
- 간단한 분류에 GPT-4를 써서 10배 비용
- Small·Medium·Large 모델 라우팅 없음
실전 절감 기법
(1) Prompt Caching 적극 활용
- Anthropic: 시스템 프롬프트 캐시 시 90% 할인
- OpenAI: 자동 캐싱 (2024-)
- 캐시 TTL 고려한 설계
(2) Model Routing / Cascading
- 질문 난이도 분류 → 작은 모델 먼저 → 실패 시 큰 모델
- Martian, NotDiamond, LiteLLM 같은 라우터 활용
(3) Batch API
- OpenAI Batch API: 실시간 대비 50% 저렴
- 대량 분석·요약에 적합
(4) Fine-tuned Small Models
- 자주 쓰는 태스크는 GPT-4o-mini·Claude Haiku·Llama 3 8B를 파인튜닝
- API 비용의 1/10-1/50
(5) Self-Hosting (큰 규모)
- 월 LLM 비용 $50k+ 넘으면 vLLM·TGI로 자체 호스팅 검토
- Llama 3.3 70B, Mistral Large, Qwen 계열
- GPU 비용 고려해 break-even 계산 필수
(6) Output Token 제한
max_tokens엄격 설정- 구조화 출력(JSON Schema)으로 출력 크기 예측
모니터링 도구
- LangFuse, LangSmith, Helicone, Phoenix: LLM 호출 로깅·비용 대시보드 (Ep 8 참고)
- OpenLLMetry (Traceloop): OpenTelemetry 기반 표준
- Portkey, Vellum: LLM Gateway와 비용 정책
Korean 시장 사례
- 토스·카카오뱅크는 LLM 비용을 거래당 비용으로 관리 (건당 수 원)
- 네이버 하이퍼클로바X는 토큰당 단가가 GPT-4보다 저렴하지만 품질 고려 병행
- 국내 공공·금융은 on-prem GPU 클러스터 구축 (데이터 반출 금지)
8장 · GPU·Kubernetes FinOps
AI 학습·서빙 인프라의 비용 관리.
GPU 비용의 현실
| GPU | 시간당 요금 (AWS On-Demand) | 용도 |
|---|---|---|
| T4 | $0.53 | 추론, 소규모 학습 |
| A10 | $1.00 | 중규모 추론 |
| A100 80GB | $3.06 | LLM 파인튜닝 |
| H100 | 10 | 대규모 학습 |
| H200 | 15 | 초대형 모델 |
연간 환산: H100 1장 on-demand = 90k. 클러스터 8장이면 700k/년.
GPU FinOps 핵심 전략
(1) Reserved/Commit 우선
- AWS Capacity Block, GCP Compute Reservation
- H100 1년 약정 시 30-40% 할인
- Lambda Labs·CoreWeave 등 GPU 전문은 더 저렴
(2) Fractional GPU
- NVIDIA MIG(Multi-Instance GPU): A100을 7개로 분할
- 추론에 적합, 비용 7배 효율
(3) Spot GPU
- 학습에 체크포인트 설계 필수
- 2025년 AWS H100 Spot 가용성 크게 개선
(4) Batch Inference
- 실시간 서빙 대비 7-10배 처리량
- NVIDIA Triton Dynamic Batching, vLLM Continuous Batching
(5) 모델 양자화·증류
- 70B → 4-bit 양자화 = VRAM 1/4, 속도 2-3배
- AWQ, GPTQ, bitsandbytes
Kubernetes FinOps
- OpenCost: CNCF 오픈소스, Kubernetes 비용 할당 표준
- Kubecost: OpenCost 상용화 버전
- Goldilocks (Fairwinds): Vertical Pod Autoscaler 추천
- Request/Limit 최적화만으로도 20-40% 절감
- Karpenter로 노드 자동 스케일, Bin Packing
9장 · FinOps 플랫폼·도구 비교
2025년 엔드투엔드 FinOps 플랫폼 지형.
엔터프라이즈 SaaS
- Apptio Cloudability: 가장 오래된, 대기업 표준, 가격 높음
- Flexera: IT 포트폴리오 통합, 라이선스 관리 강점
- CloudHealth by VMware: 종합 클라우드 관리
클라우드 네이티브 FinOps
- Vantage: 모던 UI, 스타트업·중견 선호, 한 곳에 AWS·Azure·GCP·Snowflake·Datadog 통합
- CloudZero: Unit Economics 강점, 제품별 비용 할당 특화
- Zesty: AWS Reserved Instance 자동 거래
오픈소스
- OpenCost (CNCF): Kubernetes 비용 할당 표준
- Komiser: 멀티 클라우드 가시성
- Infracost: Terraform PR에서 비용 영향 예측
Cloud Native (벤더 자체)
- AWS Cost Explorer + Cost Anomaly Detection
- GCP Cloud Billing + Active Assist
- Azure Cost Management + Azure Advisor
선택 기준
- 30명 미만 스타트업: 벤더 내장 + Infracost 정도로 충분
- 100-500명: Vantage 또는 CloudZero
- 500명+ 또는 복잡한 멀티 클라우드: Apptio·Flexera·CloudHealth
10장 · Showback vs Chargeback — 실전
Showback (보여주기)
- 각 팀/제품에 비용을 공개만 함
- 청구는 중앙 IT/플랫폼 팀이
- 장점: 저항 낮음, 가시성부터 시작
- 단점: 행동 변화 약함
Chargeback (청구하기)
- 각 팀/제품에 실제 청구
- 예산에 직접 영향
- 장점: 강력한 행동 유도
- 단점: 정치적 저항, 허수 경제
전환 전략
- 1단계 (3-6개월): 태깅 강제 (Tag Policy, Lambda 자동 거부)
- 2단계 (6-12개월): Showback 대시보드, 팀별 월간 리뷰
- 3단계 (12-24개월): Chargeback 시작. 예산 편성 시 반영
- 4단계: Unit Cost 대화 ("거래당 0.08")
태깅 Best Practice
필수 태그:
team(누구 비용인가)env(prod/staging/dev)project(어떤 프로젝트)owner(이메일·Slack)cost-center(Finance 코드)
자동 강제 방법:
- AWS Tag Policy, GCP Label Manager, Azure Policy
- IaC 레벨 (Terraform) 기본값
- CI/CD에서 태그 없으면 배포 차단
11장 · Green FinOps — 탄소발자국 관리
2024-2025 주요 트렌드. EU CSRD, SEC Climate Disclosure 등 규제화.
왜 중요해졌나
- 규제: EU CSRD 2024 시행, 모든 대기업 탄소 공시 의무
- 투자자: ESG 평가에 IT 인프라 탄소 포함
- 공공 입찰: 탄소 감축 로드맵 요구
- MZ 인재 채용: 지속가능성이 선택 요인
주요 도구
- AWS Customer Carbon Footprint Tool: 무료, 간단
- Google Cloud Carbon Footprint: 리전별 세부
- Azure Emissions Impact Dashboard: 자세한 분석
- Cloud Carbon Footprint (오픈소스): 멀티 클라우드
절감 기법
- 저탄소 리전 선택: us-west-2(Oregon)·europe-north-1(Stockholm)는 재생에너지 비중 높음
- 쿨다운 타임 활용: 비실시간 배치를 탄소 집약도 낮은 시간대로 (Carbon-aware SDK)
- 워크로드 통합: 여러 작업을 같은 클러스터에 → 활용률 ↑ → 와트/TB ↓
- Archive·Delete 정책: 쓰지 않는 데이터 유지 = 탄소 비용
- CDN/캐시: 반복 트래픽 줄임
연결된 트렌드
- **탄소 예산(Carbon Budget)**을 FinOps와 병행 관리
- FinOps Foundation이 2024년 Sustainability를 공식 도메인으로 편입
12장 · 2025년 경기 불황 속 데이터팀 예산 생존 전략
글로벌 긴축기. 데이터팀이 살아남으려면.
Defensive Strategy (방어)
(1) 퀵윈(Quick Wins) 패키징
- 3-6개월 내 20-40% 절감 가능한 항목 공개
- CFO·CEO 대상 분기 리뷰
(2) Unit Economics 보고
- 매출당 데이터 비용, 사용자당 분석 비용
- 업계 벤치마크 비교
(3) 제품팀 임팩트 가시화
- "실험 플랫폼이 Q1 매출 5% 기여"
- "Recommender 모델 업그레이드로 리텐션 3% ↑"
Offensive Strategy (공격)
(4) 수익 직결 프로젝트 우선
- 비용 절감 자동화, 사기 탐지, Upsell 모델
- 매출에 직접 연결되는 AI/데이터 프로젝트
(5) AI 기반 내부 효율화
- 데이터팀 자체에 LLM 도입 (문서화·쿼리 작성 자동화)
- "우리도 AI로 30% 빨라졌다"는 스토리
(6) 외부 수익화
- 데이터 제품(Data Product)을 사내 사용을 넘어 B2B 판매
- "내부 투자가 매출로 전환되는 구조"
생존한 팀의 공통점 (2024-2025 관찰)
- 소수 정예 (15명 → 8명 슬림화, 시니어 유지)
- 플랫폼화 (개별 요청 대응에서 자산화로 전환)
- C-Suite와 직접 소통
- Unit Cost 언어 사용
13장 · 안티패턴 10
- 태깅 없이 비용 관리: 원인 파악 불가, 개선 불가
- Auto-Suspend 기본값 유지: Snowflake 기본 10분은 거의 항상 너무 길다
- Reserved 100% 약정: 변동 대응 못 함, 남는 용량 낭비
- "Production == All-Purpose Cluster": Databricks에서 가장 비싼 실수
- 실시간 서빙에 On-Demand GPU: 예약/스팟 없이 24/7 운영
- LLM 호출에 모니터링 없음: 어느 순간 월 $100k 돌파 후 발견
- Chargeback 없이 분배: 행동 유도 안 됨, 남의 돈으로 쓰는 문화
- FinOps를 Finance에만 맡김: 엔지니어 참여 없이는 최적화 한계
- 탄소 무시: 2025년 이후 규제·평판 리스크
- Cost = Value 착각: 싸다고 좋은 게 아님, Value/Cost 비율이 핵심
14장 · 다음 글 예고 — Season 5 Ep 12: "데이터 보안과 프라이버시"
비용 이후엔 보안. Ep 12는 데이터 보안·프라이버시의 현주소.
- 데이터 암호화: At-rest, In-transit, In-use (CMEK, BYOK, HSM)
- 접근 제어: RBAC vs ABAC vs PBAC, Row/Column-level Security
- 망분리 환경의 데이터 운영 (금융·공공)
- Differential Privacy, K-anonymity, PII 마스킹
- Zero Trust 데이터 아키텍처
- Confidential Computing (SGX, TDX, Nitro Enclaves)
- AI/LLM의 새로운 보안 위협 (Prompt Injection, Data Exfiltration)
- Multi-tenant SaaS 격리 설계
- 개인정보보호법·GDPR·HIPAA 기술적 구현
- Bug Bounty·Red Team 운영
"데이터는 가장 큰 자산이자, 가장 큰 책임."
다음 글에서 만나자.
에필로그 · 체크리스트 12
- 모든 비용 리소스가 5가지 표준 태그로 태깅되어 있는가?
- 팀별·제품별 Unit Cost 지표가 존재하는가?
- Reserved/Spot 비율이 사용 패턴에 맞게 최적화되어 있는가?
- Snowflake/Databricks/BigQuery의 오래된 쿼리/대시보드가 정기 정리되는가?
- LLM 사용량·비용이 실시간 가시화되는가?
- Prompt Caching·Model Routing이 활용되는가?
- GPU 클러스터 사용률이 70% 이상 유지되는가?
- Showback 또는 Chargeback이 운영되는가?
- Cost Anomaly 자동 경보가 설정되어 있는가?
- 탄소발자국이 측정·보고되는가?
- FinOps 전담자 또는 Champion이 각 팀에 있는가?
- Unit Economics로 경영진·Finance와 분기 리뷰가 되는가?
"비용은 엔지니어링의 일부이다. 코드가 동작하느냐만큼, 얼마로 동작하느냐가 중요하다."
— Season 5 Ep 11, Fin.