작년까지 클라우드 비용 회의의 주인공은 놀고 있는 EC2 인스턴스였습니다. 지금은 아무도 그 얘기를 하지 않아요. GPU 한 장이 쉬는 1시간이 CPU 코어 수백 개가 쉬는 것보다 비싸졌기 때문입니다.

그런데 정작 그 GPU가 얼마나 쉬고 있는지, 어느 팀이 태우고 있는지를 아는 조직은 많지 않습니다. 기존 클라우드 비용 관리 공식이 AI 워크로드 앞에서 왜 깨지는지, 그리고 무엇을 어떤 순서로 구현해야 하는지 정리했습니다.

AI 청구서와 계측 개념 컷 AI 청구서와 계측 개념 컷 — 출처: 자가 생성

2년 만에 31%에서 98%로

FinOps Foundation이 2026년 2월 발표한 State of FinOps 2026은 응답자 1,192명, 합산 연간 클라우드 지출 830억 달러(약 116조 원) 규모의 설문입니다. 여기서 가장 눈에 띄는 숫자는 하나예요.

AI 지출을 관리한다고 답한 실무자가 98%. 2년 전 같은 질문에 그렇다고 답한 비율은 31%였습니다.

AI 비용을 관리하는 FinOps 실무자 비율 AI 비용을 관리하는 FinOps 실무자 비율 — 출처: 자가 생성

같은 조사에서 FinOps의 관리 범위 자체가 넓어졌다는 신호도 함께 나옵니다.

관리 대상 2026년 전년
AI 98% 63%
SaaS 90% 65%
프라이빗 클라우드 57% 39%
라이선싱 64% 49%
데이터센터 48% —

조직의 무게중심도 옮겨갔습니다. 응답 팀의 78%가 CTO 또는 CIO에게 보고하고 있고, 이는 전년 대비 18%포인트 오른 수치예요. 연간 1억 달러(약 1,400억 원) 이상을 쓰는 조직은 평균 8~10명의 정규 실무자에 계약직 3~10명을 얹어 운영합니다.

AI 비용 관리는 FinOps의 선택 과목에서 전공 필수가 됐습니다

기존 공식이 깨지는 세 지점

클라우드 FinOps는 오랫동안 인스턴스를 덜 크게, 덜 오래, 더 싸게라는 세 축으로 굴러갔습니다. AI 워크로드에서는 이 세 축이 각각 다른 이유로 어긋납니다.

첫째, 놀리는 비용의 단위가 바뀌었다

유휴 CPU 코어는 시간당 몇 센트입니다. 유휴 GPU는 시간당 몇 달러예요. 같은 낭비율이어도 청구서에 찍히는 자릿수가 다릅니다.

게다가 GPU는 값이 내려가던 자산이 아니게 됐습니다. Cast AI의 2026년 리포트는 AWS가 2026년 1월 H200 Capacity Block 가격을 15% 인상했다고 지적하면서, 이를 2006년 EC2 출시 이후 20년간 이어진 관행이 깨진 사건으로 기록했어요.

둘째, 과금 단위가 시간에서 토큰으로 옮겨갔다

인스턴스는 켜져 있는 시간으로 과금됩니다. 모델 API는 주고받은 토큰으로 과금돼요. 시간 기준으로 설계된 예약 인스턴스, 세이빙 플랜, 오토스케일링 정책은 토큰 과금에 그대로 얹히지 않습니다.

셋째, 청구서에 팀 이름이 없다

이게 가장 아픕니다. 태그는 GPU 시간 카운터로 전파되지 않고, 공유 추론 엔드포인트에는 요청별 귀속 정보가 원래 없습니다. 외부 모델 제공사는 인보이스에 한 줄로 청구하고요.

결과는 대시보드 맨 아래의 커다란 미배분 항목입니다. 누가 썼는지 모르는 비용은 줄일 수도 없습니다.

병목 하나 — GPU는 사놓고 안 쓴다

Cast AI가 AWS·GCP·Azure에서 돌아가는 수만 개 프로덕션 클러스터를 최적화 적용 이전 상태로 측정한 결과입니다.

프로덕션 쿠버네티스 클러스터 자원 활용률 프로덕션 쿠버네티스 클러스터 자원 활용률 — 출처: 자가 생성

GPU 평균 활용률 5%. 프로비저닝한 용량의 95%가 어느 순간에도 놀고 있다는 뜻입니다. CPU 8%, 메모리 20%도 낮지만 GPU만큼 비싸지는 않아요.

같은 리포트에 흥미로운 대조군이 있습니다. H200 136장을 돌리면서 GPU 활용률 49%를 유지하는 클러스터가 있었어요. 평균 대비 10배입니다. 하드웨어가 아니라 운영이 만든 차이라는 얘기죠.

GPU를 쪼개는 두 방법

한 장을 통째로 한 워크로드에 주는 관행이 낭비의 큰 축입니다. 쪼개는 방법은 두 갈래예요.

방식 격리 특징 약점
MIG 하드웨어 수준 물리 GPU를 최대 7개 인스턴스로 분할, 메모리 대역폭·연산 전용 할당 정적 프로파일이라 워크로드 크기와 경계가 어긋남
타임슬라이싱 없음 CUDA 컨텍스트 전환으로 가상 복제본 생성, 설정이 간단 복제본 간 메모리 격리 없음

Cast AI는 정적 MIG 프로파일이 워크로드 크기와 잘 맞지 않아 20~30%의 용량이 남는 일이 잦다고 봅니다. 반대로 타임슬라이싱은 격리가 없어 이웃 워크로드가 메모리를 먹으면 같이 죽어요.

정답은 하나를 고르는 게 아니라 추론과 학습을 다르게 다루는 것입니다. 짧고 잦은 추론 요청은 타임슬라이싱으로 밀도를 올리고, 메모리를 오래 붙잡는 학습 잡은 MIG나 전용 노드로 격리하는 식이죠.

노드 레벨은 자동화로 넘긴다

Pod 하나가 남았다고 GPU 노드 한 대를 켜둔 채로 두는 일은 사람이 잡기 어렵습니다. nOps는 Karpenter의 연속 통합(consolidation)이 기본 Cluster Autoscaler 대비 GPU 노드 수를 35~45% 줄였다고 보고했어요. 수치는 워크로드 성격에 크게 좌우되니 자기 클러스터에서 재보는 게 맞습니다.

병목 둘 — 토큰 청구서에는 팀 이름이 없다

공유 엔드포인트 하나를 여러 팀이 쓰는 순간, 청구서는 팀 단위로 나뉘지 않습니다. 이걸 푸는 방법은 결국 자기가 계측해서 비율로 나누는 것뿐이에요.

귀속 파이프라인 개념 컷 귀속 파이프라인 개념 컷 — 출처: 자가 생성

게이트웨이에서 꼬리표를 붙인다

모델 호출이 애플리케이션에서 곧장 나가면 귀속할 방법이 없습니다. 앞에 게이트웨이를 두고 모든 요청에 팀·프로젝트 헤더를 주입하면, 그 시점부터 요청마다 주인이 생겨요. LiteLLM처럼 모델 라우팅 전용 프록시를 쓰거나 Kong·Nginx로 헤더만 강제하는 방법이 흔히 쓰입니다.

자체 호스팅은 토큰 비례로 나눈다

자체 호스팅 모델이 가장 어려운 경우입니다. GPU 시간 비용은 클러스터 단위로 발생하는데 소비는 팀별로 일어나니까요. 배분식 자체는 단순합니다.

팀 배분 비용 = (팀 토큰 수 ÷ 전체 토큰 수) × GPU 시간 비용

관건은 분자에 들어갈 토큰 수를 실제 사용량 계측기에서 가져오는 것입니다. 추정치나 팀별 신고로 채우면 그 순간 배분표는 협상 대상이 되고, 아무도 믿지 않게 됩니다.

쇼백을 먼저, 차지백은 나중에

배분표를 만들자마자 실제 예산에서 차감하기 시작하면 대개 반발이 먼저 옵니다. 커버리지가 낮은 상태에서 청구하면 미배분 항목을 누가 떠안느냐로 싸움이 나거든요.

단계 하는 일 넘어가는 조건
쇼백 팀별로 얼마인지 보여주기만 한다 귀속 커버리지 80% 이상
차지백 팀 예산·코스트센터에 실제로 전가 —

쇼백을 4~6주 돌려 커버리지가 80%를 넘긴 뒤 차지백으로 전환하는 순서가 실무에서 자주 권장됩니다. 숫자를 못 믿겠다는 말이 나오지 않을 때까지 보여주는 기간이라고 보면 됩니다.

구현 1단계 — 보이게 만들기

여기서부터가 실제로 손을 대는 부분입니다. FinOps의 고전적인 세 국면(Inform · Optimize · Operate)은 AI 워크로드에서도 그대로 쓰이는데, 각 국면에 들어가는 재료가 달라져요.

청구 데이터만으로는 부족하다

기존 FinOps는 클라우드 청구 데이터 하나로 대부분을 설명할 수 있었습니다. AI는 청구 데이터와 런타임 텔레메트리를 같이 봐야 그림이 나와요.

데이터 어디서 무엇을 답하나
청구·사용량 클라우드 CUR, 모델 제공사 인보이스 얼마 썼나
GPU 텔레메트리 DCGM, 노드 익스포터 산 걸 쓰고 있나
토큰·호출 로그 게이트웨이, 애플리케이션 누가 얼마나 썼나
모델·버전 메타 라우팅 설정 어떤 모델로 태웠나

앞의 둘만 있으면 낭비는 보이지만 주인을 못 찾습니다. 뒤의 둘만 있으면 주인은 찾는데 금액이 안 붙어요. 넷을 한 축에 조인하는 게 1단계의 전부입니다.

FOCUS — 제공사마다 다른 청구서를 한 스키마로

여기서 표준이 하나 등장합니다. FOCUS(FinOps Open Cost & Usage Specification)는 제공사마다 제각각인 청구 데이터를 공통 스키마로 정규화하는 규격이에요.

FOCUS 스펙이 AI 비용을 흡수한 경로 FOCUS 스펙이 AI 비용을 흡수한 경로 — 출처: 자가 생성

AI 비용에 직접 닿는 건 2025년 5월 비준된 1.2입니다. 토큰·크레딧 구매를 청구 데이터로 다룰 수 있게 되면서, 커밋한 물량과 실제 소진 속도를 대조하고 소진 완료 시점을 예측하는 일이 가능해졌어요. 정가 대비 할인 토큰 단가를 계산하거나, 달러·유로·토큰이 섞인 데이터를 한 통화로 정규화하는 것도 여기 들어갑니다.

2026년 6월 4일 비준된 1.4는 인보이스 대사용 데이터셋과 제공사 간 커밋먼트 비교를 보강했습니다. 데이터셋 2개, 컬럼 47개, 속성 6개, 용어 17개가 추가됐어요.

채택률도 올라왔습니다. 같은 State of FinOps 조사에서 연간 1억 달러 이상 지출 조직의 68%가 FOCUS 형식 데이터를 쓰거나 시험하고 있고, 18%가 도입을 계획 중이라고 답했습니다.

구현 2단계 — 깎기

가시성이 확보되면 레버를 당길 차례입니다. AI 비용에는 기존 클라우드에 없던 레버가 몇 개 더 있어요.

레버 하나 — 프롬프트 캐싱

같은 프리픽스를 반복해 보내는 워크로드라면 가장 효과가 큰 레버입니다. Anthropic 기준으로 캐시에서 읽은 토큰은 기본 입력 단가의 약 0.1배, 즉 90% 할인이에요.

정가와 캐시 읽기 단가 격차 정가와 캐시 읽기 단가 격차 — 출처: 자가 생성

공짜는 아닙니다. 캐시에 쓸 때 프리미엄이 붙어요.

TTL 쓰기 단가 읽기 단가 손익분기
5분 1.25배 0.1배 요청 2회
1시간 2배 0.1배 요청 3회

5분 TTL은 1.25배 + 0.1배 = 1.35배로 캐시 없이 두 번 부르는 2배보다 쌉니다. 1시간 TTL은 2배 + 0.2배 = 2.2배라 세 번은 읽어야 본전이에요. 트래픽에 긴 공백이 있는 배치성 워크로드는 1시간이 유리하고, 연속 트래픽은 5분으로 충분합니다.

여기 함정이 하나 있습니다. 캐시가 걸리는 최소 프리픽스 길이가 모델마다 다르고, 세대순으로 줄어들지도 않아요.

모델별 최소 캐시 프리픽스 길이 모델별 최소 캐시 프리픽스 길이 — 출처: 자가 생성

3,000토큰짜리 프리픽스는 Claude Opus 5에서는 캐시되고 Claude Haiku 4.5에서는 조용히 캐시되지 않습니다. 오류도 경고도 없어요. 비용 절감을 기대하고 모델을 낮췄다가 캐시가 통째로 빠지는 일이 여기서 생깁니다.

레버 둘 — 지연에 둔감한 일은 배치로

즉답이 필요 없는 작업은 배치 API로 넘기면 전 모델 50% 할인입니다. 야간 분류, 대량 요약, 백필 임베딩처럼 사람이 기다리지 않는 일이 후보예요. 응답이 몇 분에서 몇 시간 뒤에 와도 되는지가 유일한 판단 기준입니다.

레버 셋 — 모델을 일로 맞춘다

같은 일을 가장 비싼 모델로 처리하고 있지 않은지 봅니다.

모델 입력 (100만 토큰) 출력 (100만 토큰) 컨텍스트
Claude Opus 5 $5.00 (약 7,000원) $25.00 (약 3만 5천 원) 1M
Claude Sonnet 5 $3.00 (약 4,200원) $15.00 (약 2만 1천 원) 1M
Claude Haiku 4.5 $1.00 (약 1,400원) $5.00 (약 7,000원) 200K

분류나 라우팅처럼 단순하고 양이 많은 일을 상위 모델로 태우고 있었다면 하위 모델로 내리는 것만으로 단가가 5분의 1이 됩니다. 다만 품질이 떨어지면 재시도가 늘어 총비용이 되레 오를 수 있으니, 단가가 아니라 성공한 작업 1건당 비용으로 비교해야 해요.

레버 넷 — GPU 밀도

앞서 본 활용률 5%를 올리는 쪽입니다. Cast AI는 타임슬라이싱 도입만으로 20%가 즉시 절감되고, 여러 모델을 공유 인스턴스로 통합한 뒤에는 30~40%까지 올라갔다고 보고했습니다. 여기에 CPU·메모리 라이트사이징을 더해 관리형 서비스 대비 70% 이상 줄인 사례도 함께 제시했어요.

절감폭 자체는 출발점이 얼마나 나빴는지에 좌우됩니다. 활용률 5%에서 시작하면 큰 숫자가 나오고, 이미 40%대라면 여지가 훨씬 적어요.

구현 3단계 — 다시 새지 않게

한 번 깎은 비용은 가만두면 돌아옵니다. 3단계는 절감을 유지하는 장치를 붙이는 일이에요.

캐시가 실제로 걸리는지 확인한다

캐싱을 켜놓고 안 걸리는 상태로 몇 주를 보내는 일이 흔합니다. 응답의 사용량 필드를 보면 바로 알 수 있어요.

필드 의미
cache_creation_input_tokens 이번에 캐시에 쓴 토큰 (쓰기 프리미엄 발생)
cache_read_input_tokens 캐시에서 읽은 토큰 (0.1배 적용)
input_tokens 캐시가 안 걸려 정가로 처리된 나머지

동일한 프리픽스를 반복해 보내는데 읽기 값이 계속 0이면 어딘가에서 프리픽스가 매번 달라지고 있다는 신호입니다. 시스템 프롬프트에 박아둔 현재 시각, 매 요청 새로 만드는 UUID, 키 순서가 뒤집히는 JSON 직렬화가 단골 범인이에요.

대시보드가 비용을 과소 집계하는 함정

여기서 FinOps 쪽이 특히 조심할 게 하나 있습니다. 입력 토큰 필드는 프롬프트 전체가 아니라 캐시가 안 걸린 나머지일 뿐이에요.

전체 프롬프트 = input_tokens + cache_creation_input_tokens + cache_read_input_tokens

입력 토큰 필드만 집계하는 대시보드는 캐시가 잘 걸릴수록 실제보다 적은 사용량을 보고합니다. 에이전트가 몇 시간을 돌았는데 입력 토큰이 4천으로 찍힌다면 계측이 잘못된 것이지 저렴하게 돌아간 게 아닙니다.

캐시를 조용히 깨는 것들

비용 급증 알람이 울렸을 때 확인 순서를 정해두면 원인을 빨리 찾습니다.

바꾼 것 도구 캐시 시스템 캐시 대화 캐시
도구 정의 추가·삭제·순서 변경 ❌ ❌ ❌
모델 교체 ❌ ❌ ❌
시스템 프롬프트 내용 ✅ ❌ ❌
메시지 내용 ✅ ✅ ❌

도구 목록을 바꾸거나 모델을 갈아타면 캐시가 통째로 날아갑니다. 세션 도중에 모드를 바꾸겠다고 도구 세트를 갈아끼우는 설계가 비용 관점에서 특히 나쁜 이유예요.

운영 중에 조용히 캐시를 갉아먹는 함정이 두 가지 더 있습니다.

룩백 창이 첫 번째입니다. 각 캐시 지점은 뒤로 최대 20개 블록까지만 훑어요. 한 턴에 도구 호출이 20개를 넘게 쌓이는 에이전트 루프에서는 다음 요청이 이전 캐시를 못 찾고 조용히 미스가 납니다.

동시 요청이 두 번째예요. 같은 프리픽스로 N개를 한꺼번에 쏘면 아직 아무도 캐시를 다 쓰지 않은 상태라 전부 정가를 냅니다. 하나를 먼저 보내 첫 토큰이 나오기 시작한 뒤 나머지를 쏘는 편이 낫습니다.

무엇을 재는가 — 총액에서 단위로

3단계까지 갖추면 마지막 질문이 남습니다. 그래서 잘하고 있는 건가?

총액은 이 질문에 답하지 못합니다. 사용자가 두 배로 늘어 비용이 1.5배가 됐다면 그건 성공이니까요. AI FinOps가 단위 경제로 옮겨가는 이유입니다.

지표 계산 무엇을 잡아내나
요청 1건당 비용 총 모델 비용 ÷ 성공 요청 수 재시도·실패로 새는 비용
활성 사용자당 비용 총 AI 비용 ÷ 월 활성 사용자 사용자가 늘 때 비용이 같이 뛰는지
GPU 시간당 처리 토큰 처리 토큰 ÷ GPU 가동 시간 산 하드웨어를 쓰고 있는지
캐시 적중률 캐시 읽기 토큰 ÷ 전체 입력 토큰 캐싱이 살아 있는지
미배분 비율 주인 없는 비용 ÷ 총 AI 비용 귀속 파이프라인의 구멍

미배분 비율은 특히 챙길 만합니다. 이 값이 20%를 넘으면 나머지 지표가 아무리 좋아도 신뢰를 얻기 어려워요. 앞서 쇼백에서 차지백으로 넘어가는 기준이 커버리지 80%였던 것과 같은 얘기입니다.

어디서부터 손대나

한꺼번에 다 할 수는 없습니다. 순서를 정하면 이렇게 됩니다.

첫 2주 — 계측만 붙인다

게이트웨이를 세워 모든 모델 호출에 팀 헤더를 주입하고, GPU 노드에 DCGM 익스포터를 붙입니다. 이 단계에서는 아무것도 줄이지 않아요. 줄일 대상을 찾는 데 필요한 데이터를 모으는 기간입니다.

3~6주 — 쇼백을 돌린다

팀별 비용을 보여주기만 합니다. 이 기간의 목표는 절감이 아니라 커버리지 80%예요. 미배분 항목이 어디서 나오는지 추적해 계측 구멍을 메웁니다.

6주 이후 — 큰 것부터 당긴다

여기서야 레버를 당깁니다. 순서는 캐싱 → 배치 전환 → 모델 라우팅 → GPU 밀도가 무난해요. 앞의 셋은 애플리케이션 레이어에서 며칠이면 붙지만, GPU 밀도는 클러스터 구조를 건드려야 해서 회수 기간이 깁니다.

여러 매체가 구조화된 프로그램의 첫 90일에 30~60% 절감이 현실적이라고 보고합니다. 다만 이 숫자는 출발선이 나쁠수록 커지는 값이라는 점을 감안해서 읽어야 합니다. 활용률 5%에서 시작한 조직의 절감폭을 이미 정돈된 조직에 그대로 대입할 수는 없어요.

정리

AI FinOps에서 바뀐 건 도구가 아니라 질문입니다. 예전 질문은 무엇을 끄면 되나였고, 지금 질문은 누가 무엇을 위해 얼마를 태웠나예요.

그래서 순서가 중요합니다. 귀속이 안 되는 상태에서 절감부터 시작하면, 줄어든 게 성과인지 그냥 트래픽이 준 건지 구분할 수 없거든요. 계측을 먼저 붙이고, 보여주고, 그다음에 깎는 순서가 돌아가는 것처럼 보여도 결국 빠릅니다.

참고 출처