AI 비용은 이제 클라우드 비용이다: 왜 FinOps가 AI 지출을 위한 새로운 플레이북인가

지난 18개월 동안 재무 대시보드 내부에서 조용히 변화가 일어났습니다. AI 도구 항목은 과거에 작고 예측 가능했습니다. 하지만 이제는 클라우드 청구서 바로 옆에 위치하며, 누구도 완전히 예측하지 못한 속도로 성장하고 있으며, 2015년의 AWS 모습과 의심스러울 정도로 유사해 보입니다.

이것은 우연이 아닙니다. AI 코딩 어시스턴트(AI coding assistants), 모델 API, 그리고 에이전트 플랫폼(agent platforms)은 모두 사용량에 따라 비용을 청구합니다. 이들은 가변적입니다. 헤비 유저(power users)에 의해 편향됩니다. 그리고 대부분의 팀은 누가, 어떤 모델을 사용하여, 어떤 프로젝트를 위해 무엇을 소비하고 있는지에 대한 가시성이 거의 없습니다.

이 가이드에서 여러분은 왜 AI 지출이 클라우드 인프라(cloud infrastructure) 지출과 정확히 똑같이 작동하는지, 어떤 FinOps 교훈이 직접적으로 적용되는지, 그리고 엔지니어링 팀의 속도를 늦추지 않으면서 이번 분기에 AI 비용을 통제하기 위해 사용할 수 있는 실질적인 프레임워크가 무엇인지 배우게 될 것입니다.

오늘날의 AI 지출이 초기 클라우드 청구서와 동일해 보이는 이유
10년 전, 대부분의 재무 팀은 클라우드를 단일 항목으로 취급했습니다. 엔지니어링 팀이 주도권을 쥐었습니다. 지출은 조용히 증가하다가 어느 순간 폭발했고, 그때서야 모두가 허둥지둥 대처했습니다.

AI는 더 빠른 속도로 이와 정확히 일치하는 패턴을 반복하고 있습니다.

몇 가지 요인이 그 이유를 설명합니다:

• AI 도구들이 2년도 채 되지 않아 고정 좌석제 가격 책정(fixed-seat pricing)에서 사용량 기반 가격 책정(usage-based pricing)으로 전환되었습니다.
• 헤비 유저 편향(Power-user skew)이 심각합니다. 소수의 개발자가 종종 대부분의 소비를 주도합니다.
• 가격대가 매우 다른 여러 모델이 조용한 비용 차이를 만들어냅니다.
• 에이전트 워크플로우(Agentic workflows)는 세션이 종료된 후에도 오랫동안 지속되는 방식으로 토큰 비용(token cost)을 축적합니다.
• 코딩하는 동안 비용을 생각하도록 인센티브를 받는 엔지니어는 없습니다.

McKinsey의 State of AI 시리즈 연구에 따르면, 기업 내 생성형 AI(generative AI) 도입은 단 1년 만에 두 배 이상 증가했습니다. 이러한 성장 곡선은 탄력성(elastic)이 규모가 커짐에 따라 비싸다는 것을 팀들이 깨닫기 시작했던 초기 AWS 시대와 닮아 있습니다.

결론은 간단합니다. AI 지출은 새로운 괴물이 아닙니다. 그것은 클라우드 비용 관리의 다음 장이며, EC2와 S3에 효과적이었던 플레이북은 이미 토큰(tokens)과 프롬프트(prompts)에도 적용됩니다.

기업에 수백만 달러의 손실을 조용히 입히고 있는 가시성 격차(Visibility Gap)
대부분의 엔지니어링 조직에 들어가서 간단한 질문 하나를 던져보십시오.

"지난주에 어떤 팀이 AI에 가장 많은 비용을 썼나요?"

보통 침묵이 흐릅니다. 혹은 누군가 총 사용자 수와 총 토큰(tokens) 수만 보여주는 벤더 대시보드를 띄우겠지만, 그 이면의 유용한 정보는 아무것도 없습니다.

이는 10년 전 클라우드 팀들이 겪었던 것과 동일한 격차입니다. 청구서가 도착하고, 총액은 올라가지만, 정확히 왜 그런지는 아무도 모릅니다.

일반적인 사각지대(blind spots)는 다음과 같습니다:

• 어떤 개발자가 가장 큰 지출을 담당하고 있는가
• 지출이 입력 토큰(input tokens), 출력 토큰(output tokens), 캐시된 토큰(cached tokens) 사이에서 어떻게 나뉘는가
• Claude, GPT, Gemini 및 오픈 소스(open-source) 제품군 중에서 어떤 모델이 비용을 유발하는가
• 지출이 주로 자동 완성(autocomplete) 때문인지, 아니면 주로 장시간 실행되는 에이전트(agent) 세션 때문인지
• 지출이 실제 엔지니어링 산출물과 어떻게 상관관계가 있는가

Gartner는 조직 내에서 성장하는 섀도 IT(shadow IT)에 대해 수년 동안 경고해 왔습니다. 그 새로운 버전이 바로 섀도 AI(shadow AI)입니다. 개발자들이 도구를 찾아 사용하고 비용을 처리하면, 재무 부서는 3분기 후에 통합 인보이스(consolidated invoice)가 도착해서야 그 사실을 알게 됩니다.

해결책은 새로운 기술이 아닙니다. 해결책은 가시성(visibility)이며, 이는 수년 전 클라우드 비용 관리 프로그램들이 구축했던 것과 동일한 종류입니다.

AI에 직접 적용 가능한 5가지 FinOps 원칙
FinOps 재단(FinOps Foundation)은 훌륭한 클라우드 비용 관리가 어떤 모습인지 체계화하는 데 수년을 보냈습니다. 그 중 대부분은 AI로 깔끔하게 전이됩니다.

바로 가져다 쓸 가치가 있는 5가지 원칙은 다음과 같습니다:

1. 통제에 앞서 가시성이 우선되어야 한다. 볼 수 없는 것은 관리할 수 없습니다. 먼저 데이터를 확보하십시오.
2. 지출을 팀, 프로젝트, 결과물에 할당하십시오. 총액(Top-line totals)은 무용지물이며, 팀 단위의 세부 내역(breakdowns)이 실행 가능합니다.
3. 단순 지출액이 아닌 단위 경제성(unit economics)을 측정하십시오. PR당 달러, 티켓(ticket)당 달러, 배포(deploy)당 달러를 측정하십시오.
4. 이상 징후를 조기에 감지하십시오. 월 단위가 아닌 일 단위 또는 주 단위의 리듬(cadence)을 사용하십시오.
5. 엄격한 상한선(hard caps)이 아닌 정보에 기반한 가드레일(guardrails)을 사용하십시오. 엔지니어를 차단하지 말고 교육하십시오.

여기서 나타나는 패턴은 기술적인 것이 아니라 문화적인 것입니다. 재무와 엔지니어링은 동일한 숫자를 공유해야 합니다.

AI를 위한 태깅(Tagging) 및 할당(Allocation): 토큰을 EC2 시간처럼 취급하십시오

클라우드 비용 관리 작업에서 태깅(Tagging)은 기초입니다. 태깅 없이는 할당(Allocation)이 불가능합니다.

AI 지출은 실제로 대부분의 클라우드 서비스보다 더 나은 귀속(Attribution) 데이터를 가지고 있습니다. 모든 API 요청에는 일반적으로 다음 항목이 포함됩니다:

• 사용된 모델 (Model)
• 입력 및 출력 토큰 수 (Input and output token counts)
• 지연 시간(Latency) 및 요청 메타데이터 (Request metadata)
• 선택적 사용자 정의 메타데이터 필드 (Optional custom metadata fields)
• API 키가 적절히 범위가 지정된 경우, 호출자 식별 정보 (Caller identity)

가공되지 않은 신호(Raw signal)는 풍부합니다. 과제는 이를 기술적이지 않은 이해관계자가 실제로 사용할 수 있는 무언가로 변환하는 것입니다.

간단한 매핑 예시는 다음과 같습니다:

가공되지 않은 AI 데이터 (Raw AI Data)	비즈니스 번역 (Business Translation)
2.3M Opus 입력 토큰, dev_id 472	결제 팀 리팩토링, 14주 차
에이전트 실행 시 800K 캐시된 토큰	문서 팀 마이그레이션, 진행 중
1.1M 출력 토큰, GPT 제품군	지원 티켓 분류 자동화
50K 토큰, Haiku 모델	인라인 자동 완성, 전체 엔지니어링

이러한 종류의 세부 분석은 단일 송장을 재무 부서가 이해할 수 있는 이야기로, 그리고 엔지니어링 부서가 책임질 수 있는 예산으로 바꿔줍니다.

조직에 이미 클라우드 비용 할당 워크플로(Workflow)가 있다면, 처음부터 시작할 필요는 없습니다. AI를 또 다른 차원(Dimension)을 가진 또 다른 제공업체로 추가하고, 동일한 보고서에 반영하십시오.

만약 아직 클라우드 할당 역량을 구축하는 단계라면, opslyft 블로그에서 AI 지출 관리로 자연스럽게 전환할 수 있는 태깅 전략을 다루고 있습니다.

단위 경제성 (Unit Economics): 실제로 중요한 지표

단순한 지출 수치는 AI 투자가 제대로 작동하고 있는지 알려주지 않습니다. 단위 경제성 (Unit economics)이 알려줍니다.

두 팀을 가정해 보겠습니다.

• 팀 A는 AI 도구에 매월 $4,000를 지출하고 80개의 PR(Pull Request)을 완료합니다.
• 팀 B는 AI 도구에 매월 $4,000를 지출하고 35개의 PR(Pull Request)을 완료합니다.

지출은 동일합니다. 하지만 효율성은 매우 다릅니다. 단위 경제성 (Unit economics) 없이는 대시보드가 동일해 보일 것입니다.

가장 중요한 지표에는 다음이 포함됩니다:

병합된 PR당 비용 (Cost per PR merged). 코드 한 단위를 배포하는 데 AI 토큰 비용이 얼마나 드는가?
종결된 티켓당 비용 (Cost per ticket closed). 계획된 작업 한 단위를 해결하는 데 비용이 얼마나 드는가?
배포당 비용 (Cost per deploy). 프롬프트부터 프로덕션(Production)까지 전체 파이프라인에 걸쳐 측정됨.
스프린트당 개발자별 AI 비용 (AI cost per developer per sprint). 팀이 숙련됨에 따라 활용도가 높아지고 있는가?
AI 지원 기능당 비용 (Cost per AI-assisted feature). 리뷰와 재작업을 포함한 엔드 투 엔드 (End-to-end) 비용.

이를 계산하려면 두 가지 데이터 소스를 연결해야 합니다. 비용 측면은 AI 제공업체(Anthropic, OpenAI, Cursor, GitHub Copilot 등)에서 발생합니다. 출력 측면은 GitHub, GitLab, Linear, Jira 또는 CI 파이프라인에서 발생합니다.

이 데이터들을 결합하면 대화의 주제가 바뀝니다. AI 비용이 왜 증가하는지 묻는 대신, 각 달러가 지난 분기보다 더 많은 결과물을 만들어내고 있는지 묻게 됩니다.

이는 재무(Finance) 부서와 엔지니어링(Engineering) 부서가 실제로 함께 답할 수 있는 질문입니다.

청구서가 나오기 전에 이상 징후 탐지하기
사용량 기반 지출은 예상치 못한 상황을 만들어냅니다. 클라우드가 우리에게 가르쳐준 교훈입니다. AI도 다르지 않습니다.

흔히 발생하는 AI 비용 급증 사례는 다음과 같습니다:

• 개발자가 제어되지 않는 재시도 루프(Runaway retry loop)가 포함된 에이전트 세션(Agentic session)을 밤새 켜두었을 때
• 팀이 낮은 등급의 모델에서 높은 등급의 모델로 전환하여, 아무도 모르는 사이에 비용이 10배로 뛰어오를 때
• 실행 시간이 긴 에이전트가 컨텍스트(Context)를 축적하여, 매 턴마다 발생하는 비용이 첫 번째 턴보다 5배 비싸질 때
• 자동화된 워크플로우가 예외 케이스(Edge case)에 부딪혀 수백 번 재시도할 때
• 새로운 기능이 장황한 프롬프트(Verbose prompts)와 함께 배포되어 요청당 비용을 조용히 3배로 늘릴 때

이 중 대부분은 월간 청구서가 도착할 때까지 눈에 보이지 않습니다. 그때는 이미 피해가 발생한 후입니다.

이상 탐지(Anomaly detection)는 클라우드에서와 동일한 방식으로 작동합니다. 기준선(Baseline)을 설정하고, 일간 또는 주간 단위로 모니터링하며, 편차를 표시하고, 적절한 팀 소유자에게 이를 알리십시오. 탐지 로직은 동일합니다. 패턴만 다를 뿐입니다.

즉시 설정할 수 있는 몇 가지 빠른 승리(Quick wins) 전략은 다음과 같습니다:

2배 임계값(threshold)을 적용한 개발자 1인당 일일 지출 기준선(baseline)
전월 대비 비교를 포함한 팀별 주간 트렌드
프리미엄 모델 사용량이 일정 비율을 초과할 때 알림을 보내는 모델 믹스(model mix) 경고
단일 에이전트 세션(agentic session)이 토큰 임계값을 초과할 때 표시하는 세션 길이 경고
이 중 어떤 것도 화려한 머신러닝 (Machine Learning)을 필요로 하지 않습니다. 단순한 임계값만으로도 비용 급증 사례의 대다수를 잡아낼 수 있습니다.

강제 상한선(Hard Caps)이 실패하는 이유와 그 대안
클라우드 비용 관리 업무에서 얻은 가장 뼈아픈 교훈 중 하나는 무딘 통제 방식은 역효과를 낸다는 것이었습니다.

인스턴스 유형을 제한하면 엔지니어들은 더 큰 인스턴스를 덜 생성하는 대신, 상한선이 절약하려 했던 것보다 더 많은 컴퓨팅 자원을 사용하는 경우가 많습니다. 지출을 엄격한 한도로 제한하면 월말 마지막 주에 프로젝트 전체가 중단되기도 합니다.

AI에서도 마찬가지입니다.

개발자의 고품질 모델 접근을 차단하면, 그들은 더 저렴한 모델로 돌아가게 되고, 결과적으로 제품 출시가 늦어지며, 그 과정에서 더 많은 총 토큰을 소모하게 됩니다. 도구 도입을 정당화했던 생산성 향상 효과가 증발해 버리는 것입니다.

더 나은 대안은 다음과 같습니다:

• 알림 기능이 포함된 소프트 예산(Soft budgets). "남은 기간 2주 동안, 평소 월간 지출의 80%에 도달했습니다"라는 메시지는 유용합니다. 차단은 유용하지 않습니다.
• 작업 인지형 모델 가이드 (Task-aware model guidance). 복잡한 추론(reasoning)에는 프리미엄 모델이 필요합니다. 인라인 자동 완성(inline autocomplete)에는 필요하지 않습니다. 이를 명시적으로 구분하십시오.
• 실시간 세션 비용 가시성. 세션이 실행되는 동안 개발자에게 해당 세션에 비용이 얼마나 들고 있는지 보여주십시오.
• 쉬운 에스컬레이션(escalation)을 동반한 저렴한 모델 기본 설정. 작업을 수행할 수 있는 가장 저렴한 모델을 사용하되, 필요할 때 업그레이드할 수 있는 명확한 경로를 제공하십시오.
• 제한보다는 교육. 모델 선택에 관한 짧은 내부 가이드는 그 어떤 상한선보다 효과적입니다.

여기서의 패턴은 클라우드에서 효과적이었던 방식과 동일합니다. 엔지니어를 신뢰하고, 그들에게 데이터를 제공하며, 그들이 정보에 기반한 결정을 내릴 수 있도록 하십시오.

기업들이 AI에 돈을 낭비하는 세 가지 실제 시나리오
엔지니어링 및 재무 리더들과의 대화에서 반복적으로 나타나는 몇 가지 패턴이 있습니다.

1. 잊혀진 에이전트 (The Forgotten Agent) 개발자가 금요일 오후에 서비스를 리팩토링하기 위해 에이전트 (Agent)를 실행합니다. 그리고 퇴근합니다. 에이전트는 불안정한 테스트 (Flaky test)에 부딪히고, 재시도하고, 컨텍스트 (Context)를 확장하고, 다시 재시도하며 주말 내내 실행됩니다. 월요일 아침이 되면, 단 한 명의 개발자가 한 달 동안 사용한 비용이 팀 전체의 비용과 맞먹는 상황이 발생합니다.

해결책: 개발자당 한도가 아닌, 세션 길이 알림 (Session-length alert) 및 세션당 예산 상한 (Per-session budget cap) 설정.

1. 조용한 모델 업그레이드 (The Silent Model Upgrade) 벤더 (Vendor) 업데이트 이후 팀의 툴링 (Tooling) 기본 설정이 변경됩니다. 이전에는 저렴한 모델을 호출하던 것이 이제 프리미엄 모델을 호출하게 됩니다. 출력 품질은 올라갑니다. 하지만 인보이스 (Invoice)가 도착하기 전까지는 비용이 8배나 증가했다는 사실을 아무도 알아차리지 못합니다.

해결책: 주간 단위 트렌드 알림 (Week-over-week trend alert)을 포함한 모델 믹스 모니터링 (Model mix monitoring).

1. 컨텍스트 비대화 세션 (The Context-Bloat Session) 에이전트가 대규모 코드베이스 (Codebase)에서 작업합니다. 매 턴 (Turn)마다 더 많은 컨텍스트가 추가됩니다. 40번째 턴에 이르면, 단 한 번의 메시지 비용이 세션의 첫 한 시간 전체 비용보다 더 커집니다. 생산성은 정상적으로 느껴지지만, 비용은 기하급수적으로 증가합니다.

해결책: 실시간 세션당 비용 시각화 (Real-time per-session cost surfacing) 및 컨텍스트를 언제 초기화해야 하는지에 대한 가이드 제공.

이것들은 예외적인 사례가 아닙니다. 새로운 표준 (New normal)입니다. 규모 있게 AI 도구를 운영하는 모든 팀은 첫 1년 이내에 이 중 어떤 형태로든 반드시 직면하게 될 것입니다.

opslyft가 기업의 AI 및 클라우드 비용을 통합 관리하는 방법
오늘날 AI 지출을 관리하려는 대부분의 기업은 익숙한 문제에 직면합니다. 데이터가 여러 곳에 흩어져 있다는 점입니다. Cursor에는 하나의 대시보드 (Dashboard)가 있고, Anthropic에는 또 다른 것이 있으며, OpenAI에는 또 다른 것이 있습니다. AWS에는 50개가 있습니다. 이 중 어느 것도 서로 통신하지 않습니다.

opslyft는 이러한 데이터 소스들을 단일 뷰 (Single view)로 가져오고, 비용 할당 (Cost allocation)을 적용하며, 지출을 엔지니어링 산출물 (Engineering output)과 연결합니다. 이 플랫폼은 클라우드 비용 관리 (Cloud cost management)를 위해 구축되었으며, AI를 통합된 FinOps 프로그램 내의 또 다른 제공업체로 취급함으로써 AI 도구로 자연스럽게 확장됩니다.

구체적인 기능은 다음과 같습니다:

클라우드 제공업체, AI 도구 및 개발자 플랫폼 전반에 걸친 다중 소스 통합 (Multi-source integration)
팀, 프로젝트, 환경 및 개발자별 비용 배분 (Cost allocation)
지출을 PR(Pull Request), 티켓, 배포(Deploy)와 연결하는 단위 경제성 (Unit economics) 대시보드
일간 및 주간 단위의 이상 탐지 (Anomaly detection)
생산성을 보호하는 소프트 예산 (Soft budgets) 및 정보에 기반한 가드레일 (Guardrails)
측정 가능한 절감 효과를 제공하는 최적화 권장 사항
읽기 전용 액세스 패턴 및 SOC 2 통제를 통한 보안 우선 배포

원리는 클라우드에서 작동했던 것과 동일합니다. 가시성 확보가 우선이며, 그다음은 배분, 단위 경제성, 그리고 타겟팅된 조치 순입니다. AI는 단지 목록에 추가된 다음 제공업체일 뿐입니다.

결론
AI 지출은 새로운 문제가 아닙니다. 이는 재무 및 엔지니어링 팀이 지난 10년 동안 해결해 온 클라우드 비용 이야기의 다음 장일 뿐입니다.

AI를 FinOps 프로그램 내의 또 다른 제공업체로 취급하는 기업은 더 빠르게 움직이고, 더 스마트하게 지출하며, 다른 모든 이들을 당황하게 만드는 예산 충격을 피할 것입니다.