AI 비용 관리, 2년 만에 선택에서 필수로
- 7월 8일
- 5분 분량
한여름, 에어컨을 하루 종일 켜놓고 외출한 적 있으신가요?
돌아와서 시원해진 집을 느낄 때는 아무 생각이 없다가, 전기요금 고지서를 받아보고서야 정확히 얼마를 냈는지 알게 됩니다. 그리고 고지서를 들여다보며 "내가 진짜 이만큼 썼나..." 라는 의구심이 듭니다 😅
지금 많은 기업의 인프라 담당자들이 AI 비용 청구서를 보며 똑같은 생각을 하고 있습니다. 다른 점이 있다면 청구서 액수가 훨씬 크다는점이 되겠네요. 2년 전만 해도 이 질문은 몇몇 앞서가는 팀만의 고민이었습니다. FinOps 팀 중 AI 지출을 관리 대상에 포함한 비율은 2024년 31%에 불과했습니다. 그런데 올해는 98%입니다. 거의 모든 조직이 이 청구서를 유심히 들여다보기 시작했다는 뜻입니다. 무엇이 이렇게 짧은 시간에 모두를 청구서 앞으로 불러모았을까요. 그리고 청구서를 유심히 보기 시작한 조직들은, 정말 자신이 얼마나 썼는지 정확히 알게 됐을까요. 이 글에서는 이 두 가지 질문을 따라가 봅니다.
1. 2년 만에 3분의 1에서 거의 전부로
State of FinOps 2026 리포트에 따르면, AI 지출을 관리 대상에 포함한 FinOps 팀의 비율은 2024년 31%, 2025년 63%, 2026년 98%로 집계됐습니다.
증가 패턴을 뜯어보면 두 번의 도약이 성격이 다릅니다. 2024년에서 2025년 사이의 증가(31%→63%)는 생성형 AI 기능이 파일럿 단계를 벗어나 실제 제품에 탑재되면서, 토큰 비용이 R&D 예산의 일부가 아니라 매출원가(COGS)의 일부로 편입되는 시점과 맞물립니다. 이 시기부터는 AI 비용이 반올림해서 무시할 수 있는 수준을 넘어섭니다.
2025년에서 2026년 사이의 증가(63%→98%)는 성격이 조금 다릅니다. 이 구간은 에이전틱 AI가 확산된 시기와 겹칩니다. 하나의 사용자 요청이 검색, 툴 호출, 재추론 등 수십 번의 하위 연산으로 이어지면서, 같은 트래픽 규모에서도 비용이 예측하기 어려운 폭으로 튀는 경우가 늘었습니다. 예측 불가능한 지출은 관리 대상에서 제외하기가 더 어렵습니다. 이 98%는 AI 지출을 무시해도 되던 조직 대부분이, 무시하면 예산 계획이 틀어지는 조직으로 넘어갔다는 뜻입니다. 남은 2%는 아직 그 임계점을 넘지 않은 조직일 뿐입니다.
2. FinOps가 재무팀 업무에서 기술 조직 업무로
같은 리포트는 조직 구조의 변화도 함께 보여줍니다. FinOps 조직의 78%가 이제 CTO 또는 CIO 산하로 편제되어 있습니다. 이 변화는 단순한 보고 라인 조정이 아닙니다. GPU 세대 선택, 모델 양자화 여부, 배치 크기, 오토스케일링 정책 같은 결정이 곧 비용 결정이 되면서, 비용 최적화가 순수한 조달·회계 판단만으로는 불가능해졌습니다. 아키텍처를 이해하는 사람이 비용을 결정하는 자리에 있어야 하는 구조가 된 셈이고, 그 결과 FinOps가 물리적으로 엔지니어링 조직 쪽으로 이동한 것으로 해석할 수 있습니다.
관리 범위 확장도 눈에 띕니다. SaaS 90%, 소프트웨어 라이선싱 64%, 프라이빗 클라우드 57%, 데이터센터 48%까지 FinOps 팀이 들여다보는 영역으로 편입됐습니다.
이 네 영역이 동시에 늘어난 것은 우연이 아닙니다. AI 지출은 이 네 카테고리 중 어느 하나에 속하는 새로운 항목이 아니라, 네 카테고리 전체에 걸쳐 흩어져 있는 성격을 가집니다. 같은 AI 워크로드라도 외부 모델 API를 쓰면 SaaS 청구서에, 자체 GPU를 임대해 쓰면 프라이빗 클라우드 청구서에, 직접 구매한 하드웨어를 운영하면 데이터센터 청구서에 나타납니다. 하나의 지출이 형태만 바꿔서 여러 청구서에 흩어져 있으니, FinOps 팀이 한 영역만 보고 있으면 전체 AI 지출 규모를 놓치게 됩니다. 관리 범위가 동시에 넓어진 이유는 여기에 있습니다.
3. GPU는 왜 기존 FinOps 방식으로 잡히지 않나
State of FinOps 2026은 현재 상황을 이렇게 진단합니다. 명확한 낭비는 이미 대부분 해결됐고, 이제 남은 것은 더 작고 복잡한 절감 기회를 찾는 단계라는 것입니다. 여기서 "쉬운 낭비"와 "복잡한 절감 기회"의 차이를 구체적으로 짚어볼 필요가 있습니다. 쓰지 않는 인스턴스를 끄고, 예약 인스턴스로 전환하고, 미사용 스토리지를 정리하는 작업은 한 번 손보면 끝나는 정적 최적화입니다. 담당자가 한 번 점검하고 나면 다음 점검까지 상태가 크게 바뀌지 않습니다.
GPU는 이 틀에 들어맞지 않습니다. 같은 GPU 클러스터도 시간대별 트래픽, 모델 버전, 배치 정책에 따라 초 단위로 사용 패턴이 바뀝니다. 한 번 최적화해두면 끝나는 문제가 아니라, 계속 관찰하고 계속 조정해야 하는 동적 최적화 문제입니다. 리포트가 GPU를 "복잡한 절감 기회"로 분류한 이유는 단순히 어려워서가 아니라, 문제의 종류 자체가 다르기 때문입니다.
동적 최적화가 필요한 이유를 실제 숫자로 확인할 수 있습니다. 클라우드 비용관리 플랫폼 Finout의 조사에 따르면, 엔터프라이즈 쿠버네티스 환경의 GPU 평균 활용률은 5%에 불과합니다. 활용률이 이렇게 낮은 데는 구조적인 이유가 있습니다. 응답 지연을 보장하려면 트래픽이 없을 때도 최소한의 인스턴스를 켜둬야 합니다. 콜드스타트를 피하려고 워커 수를 0으로 내리지 않는 경우가 많고, 트래픽 급증에 대비해 여유분을 미리 확보해두는 경우도 흔합니다. 이 모든 안전장치가 GPU를 "켜져 있지만 일하지 않는" 상태로 만듭니다. 그런데 과금은 활용률과 무관하게 켜져 있는 시간 전체에 대해 발생합니다. 하루 종일 켜둔 GPU가 실제로 일한 시간은 한 시간 남짓이어도, 이 격차는 어떤 청구서에도 낭비로 표시되지 않습니다.
태깅 문제는 다른 층위에서 발생합니다. VM은 한 팀이 하나를 통째로 쓰는 구조라 태그 하나만 붙이면 사용량 귀속이 끝납니다. GPU는 다릅니다. MIG(Multi-Instance GPU)나 시간 분할 방식으로 여러 팀의 요청이 하나의 물리 GPU 위에서 번갈아 처리되는 경우가 많습니다. 이 경우 자원 단위로는 태그를 붙일 대상 자체가 애매해지고, 요청·토큰 단위로 계측해야만 어느 팀이 얼마나 썼는지 알 수 있습니다. 대부분의 비용관리 도구는 이 요청 단위 계측 기능이 없습니다.
두 문제 모두 원인은 같습니다. 기존 FinOps 도구는 VM이나 스토리지처럼 상태가 정적인 자원을 전제로 설계됐습니다. GPU처럼 초 단위로 상태가 바뀌고 여러 주체가 나눠 쓰는 자원은 이 전제 자체를 벗어납니다.
4. 업계도 이미 움직이고 있다, 다만 접근 방식은 제각각이다
이 문제를 느끼는 것은 AIEEV만이 아닙니다. 클라우드 사업자들의 대응 방식을 보면 문제의 층위가 하나가 아니라는 것도 드러납니다.
AWS는 2026년 6월 9일, FinOps Agent를 퍼블릭 프리뷰로 공개했습니다. 비용 이상이 감지되면 AWS CloudTrail에 기록된 변경 이벤트와 비용 변화를 연결해 원인을 추론하고, "왜 지난달 비용이 올랐는가" 같은 자연어 질문에 답변하는 AI 에이전트입니다.
이 접근을 뜯어보면 성격이 분명해집니다. 비용이 이미 오른 뒤에, CloudTrail에 쌓여 있는 이벤트 기록을 근거로 원인을 추론하는 사후 진단형 해법입니다. 모든 API 호출을 남겨뒀기 때문에 가능한 방식이지만, 그 방대한 기록을 사람이 직접 읽고 비용 변화와 연결하기는 어려워서 AI가 대신 추론하는 단계를 끼워 넣은 것입니다. 데이터는 이미 쌓여 있었지만, 그 데이터와 비용 변화를 실시간으로 연결해서 보여주는 층위는 따로 필요했다는 뜻입니다.
GPU 클라우드 시장에서는 전혀 다른 층위의 대응이 나타납니다. 과금 단위를 더 세밀하게 쪼개는 경쟁입니다. 시간 단위로 과금하는 사업자와 분 단위로 과금하는 사업자가 공존하는데, 시간 단위 과금에서는 90초짜리 짧은 작업에도 한 시간 요금이 청구되는 구조적 낭비가 발생합니다. 이 접근도 한계가 분명합니다. 청구 단위를 시간에서 분으로 쪼개면 "얼마나 냈는지"는 더 정확해지지만, "왜 그만큼 썼는지"는 여전히 알려주지 않습니다. 정밀한 영수증과 투명한 사용 내역은 다른 문제입니다. AWS의 해법이 원인 추적을 사후 AI 추론에 맡긴 것과 마찬가지로, 과금 단위 세분화도 결국 청구서라는 한 겹 위에서만 문제를 풀고 있습니다.
5. AirCloud가 택한 접근: 사후 추론이 아니라 애초에 보이는 구조
두 사례를 나란히 놓으면 공통된 한계가 보입니다. 문제가 벌어진 지점(GPU가 왜 이렇게 쓰였는가)과 문제를 보는 지점(청구서, 로그 추론)이 분리되어 있다는 것입니다. AirCloud는 이 두 지점을 같은 화면에 놓는 방식으로 접근합니다.
대시보드에서 10분 단위로 사용량과 거래 내역을 확인할 수 있습니다. 10분이라는 간격은 임의로 정한 것이 아닙니다. 초 단위로 보면 노이즈가 너무 많아 어떤 변화가 의미 있는지 구분하기 어렵고, 일 단위로 보면 어떤 배포나 트래픽 이벤트가 비용 변화를 일으켰는지 이미 기억에서 사라진 뒤입니다. 10분은 방금 일어난 일과 비용 변화를 사람이 직접 연결할 수 있는 간격입니다.
여기에 컨테이너 로그 기반 drill-down이 더해집니다. 비용이 튄 구간을 확인한 뒤, 바로 그 시점의 컨테이너 로그를 열어 오토스케일링이 왜 발생했는지 확인할 수 있습니다. 실제 트래픽이 늘어난 것인지, 재시작 루프에 빠진 것인지, 배치 작업이 겹쳐 실행된 것인지를 로그로 직접 구분할 수 있습니다. AWS FinOps Agent가 CloudTrail 이벤트를 근거로 AI가 원인을 "추론"하는 것과 달리, 이 구조는 원인이 발생한 바로 그 자리(컨테이너 로그)에서 사람이 직접 "확인"합니다. 별도의 추론 단계가 필요하지 않습니다.
토큰 기반 오토스케일링도 같은 방향에서 작동합니다. GPU가 켜져 있는 시간이 아니라 실제로 처리한 토큰량을 기준으로 과금하기 때문에, 4장에서 짚은 활용률 문제(켜져 있지만 일하지 않는 GPU에도 과금되는 문제)가 애초에 발생하지 않습니다. 요청·토큰 단위로 처리량이 집계되기 때문에, MIG나 시간 분할 환경에서 자원 단위 태그를 억지로 붙일 필요도 없습니다. 4장의 두 문제 모두, 사후에 해결하는 것이 아니라 과금 구조 자체에서 발생하지 않도록 설계된 셈입니다. 이 방식이 유일한 답은 아닙니다. GPU 비용을 사후에 추적하는 대신 설계 단계에서부터 보이도록 만드는 접근도 가능하다는 것이, AirCloud가 보여주는 지점입니다.
마치며
AI 비용 관리는 이미 되돌릴 수 없는 흐름이 됐습니다. 그런데 지금까지 나온 해법들을 보면, 대부분 문제가 벌어진 뒤 청구서나 로그를 더 정교하게 읽는 방향으로 발전하고 있습니다. 다음 단계는 더 정밀한 청구서가 아니라, 청구서와 실행 로그를 같은 시간 축 위에서 함께 보는 것이라고 생각합니다.
당신의 조직은 이 활용률 5%를, 사후에 추적하고 있습니까, 아니면 지금 보고 있습니까.
참고 자료
FinOps Foundation, 2026.06 | https://www.nops.io/blog/state-of-finops-2026/
FinOps Foundation, 2026.06 | https://data.finops.org/
Finout, 2026.07 | https://www.finout.io/blog/why-traditional-finops-fails-when-gpu-costs-enter-the-picture
AWS, 2026.06 | https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-finops-agent-is-now-public-preview/
GMI Cloud, 2026 | https://www.gmicloud.ai/en/blog/runpod-lambda-coreweave-gmi-gpu-rental-pricing
gpu.fm, 2026 | https://www.gpu.fm/blog/cloud-gpu-providers-comparison-2026
AWS builder center, 2026 | https://builder.aws.com/content/2d3URriy1PsUqBWuHr7Jj0SVzRD/finops-without-the-walk-of-doom-meet-the-aws-finops-agent
