CFO의 질문에 답하지 못하는 AI 지출 관리의 구조적 한계

경영진은 AI 투자 확대를 밀어붙이고 있다. 예산은 세 배로 불어났고 도입률도 가파르게 오르고 있다. 그런데 어느 날 CFO가 이사회에서 불편한 질문 하나를 꺼낸다. “이 중에 실제로 돈이 되는 건 무엇인가?”

대다수 기업은 이 질문에 답하지 못한다. 비용 가시성이 부족해서가 아니라, 보유한 비용 데이터 자체가 그 답을 도출하도록 설계된 적이 없기 때문이다.

클라우드 지출 관리에서 얻은 교훈을 AI ROI 문제에 적용한다고 해결되지 않는다. 물론 클라우드는 지난 세대의 CFO에게 비즈니스 맥락 없는 청구서는 의미 없는 잡음이라는 사실을 가르쳤다. 클라우드 ROI를 산출하기 위해 CFO들은 두 가지 데이터 소스를 결합했다. 비용 데이터와 비즈니스 데이터다. AWS는 어느 계정, 어느 리전, 어느 태그, 어느 리소스인지를 보여준다. 여기에 고객·제품 매핑을 덧씌우면 클라우드 지출의 ROI가 윤곽을 드러낸다.

하지만 AI는 더 복잡하다. 비용, 비즈니스, 그리고 텔레메트리라는 세 가지 데이터 소스가 필요하기 때문이다. 텔레메트리는 분산된 소스에서 데이터를 자동 수집해 무슨 일이 왜 일어났는지 전체 그림을 파악하게 해주는 방식이다. 임원이나 엔지니어링 리더는 AI 청구서와 고객 매출 데이터에 모두 접근할 수 있다. 하지만 두 데이터를 비즈니스 가치로 연결할 방법이 없다. 오픈AI 청구서의 토큰 수는 어느 고객이 어떤 호출을 유발했는지, 어떤 기능에 쓰였는지, 프롬프트가 비즈니스 성과를 냈는지 명시하지 않는다. 업체 청구 시스템에는 그 데이터가 존재하지 않는다.

AI 업체가 해결해 줄 수 없는 문제

AI 업체는 비용을 기업에 귀속시키는 사업을 하는 곳이 아니기 때문에, 이 상황은 당분간 바뀌지 않을 것이다. AI 업체의 사업은 토큰 판매다. 업체가 노출하는 데이터 세분성은 업체 청구 시스템이 필요로 하는 수준이지, CFO가 필요로 하는 수준이 아니다.

납득이 안 된다면 AWS가 내놓는 데이터와 AI 업체가 내놓는 데이터를 비교해 보라.

AWS 청구 시스템은 리소스 ID, 계정 계층 구조, 리전, SKU, 태그 메타데이터, 분 단위 사용량을 공개한다. 태그만 올바르게 설정돼 있다면 모든 비용을 워크로드, 팀, 고객 세그먼트에 귀속할 수 있다. 데이터가 충분히 풍부해, 성숙한 핀옵스 팀은 수년 전부터 그 위에 단위 경제학 모델을 구축해왔다.

AI 업체 청구서에는 모델별 토큰 소비량이 API 키 단위 묶음 옵션과 함께 표시된다. 이것이 데이터의 전부다. 요청 수준의 귀속 정보도, 고객 ID도, 기능 매핑도, 프롬프트 결과도, 재시도 식별 정보도 없다. 여러 단계로 구성된 에이전트 워크플로는 토큰 수 하나로 뭉개진다. 대형 은행이 매달 수백만 달러 규모의 AI 청구서를 받는다고 가정해 보자. 비즈니스 어느 부문이 비용의 어느 부분을 유발했는지 가시성이 없으니, 비용 배분도 불가능하다.

기업이 어떤 AI 비용이 어떤 고객이나 기능에서 발생했는지 파악하려면, 호출이 애플리케이션을 떠나기 전에 애플리케이션 내부에서 직접 데이터를 수집해야 한다.

세 가지 필수 데이터 소스

AI ROI 측정 체계를 구축하려면 세 가지 데이터 소스를 단일 모델로 통합해야 한다.

1. 업체 간 정규화된 비용 데이터. AI 업체마다 비용 구조가 다르다. 오픈AI는 한 가지 분류 체계로, 앤트로픽은 또 다른 체계로 청구서를 발행하며, 파인튜닝 전문 업체와 추론 플랫폼은 각자의 방식을 따른다. 클라우드 GPU 비용은 AWS 또는 애저 청구서에 반영되고, 벡터 데이터베이스 전문 업체 파인콘(Pinecone)이나 스노우플레이크 청구서에도 잡힌다. 기본적으로 어느 것도 상호운용되지 않는다. 정규화는 필요조건이지만 충분조건이 아니다. 모든 AI 비용을 하나의 스키마에 담을 수는 있어도, 그 비용이 무엇을 산출했는지는 알 수 없다.

2. 애플리케이션 계층 텔레메트리. 대부분 기업이 놓치고 있는 데이터 소스이며, AI ROI를 클라우드 ROI와 구조적으로 다르게 만드는 요소다. 여섯 가지 범주에 걸쳐 애플리케이션 내 AI 호출을 계측해야 한다. 고객 또는 세션 ID에 연결된 요청 수준 추적, 호출을 유발한 제품 화면에 연결된 기능 귀속, 다단계 워크플로를 위한 에이전트 단계 캡처, 복구 비용이 기본 호출에 귀속되지 않도록 하는 재시도 및 폴백 식별, 선택된 모델과 선택 이유를 기록하는 모델 선택 로깅, 각 호출을 비즈니스 가치 창출 여부와 연결하는 결과 캡처다. 이 데이터 중 어느 것도 업체 청구 시스템에는 존재하지 않는다. 모두 호출 시점에 캡처해 비용 데이터와 통합 가능한 시스템에 저장해야 한다.

3. 비즈니스 데이터. 매출, 고객 세그먼트, 제품 계층 구조, 기능 사용량이다. CRM과 분석 스택에 이미 공급되고 있는 비즈니스 데이터를, 텔레메트리 계층이 호출을 귀속시키는 고객과 기능에 매핑한 것이다.

세 가지 소스를 통합하면 현재 모든 AI 투자 결정에 필요한 단위 경제학 지표를 산출할 수 있다. 고객 인터랙션당 비용, 기능별 마진, 에이전트 워크플로별 수익성, 모델 선택별 ROI다. 이 중 어느 것도 청구 데이터만으로는 계산할 수 없다. 텔레메트리만으로도 계산할 수 없다. 비용을 성과와 연결하는 방식으로 세 가지 소스를 함께 모델링해야 한다.

비용 복잡성과 계측 공백의 위기

단건 추론 환경에서는 비용 귀속이 어렵지 않다. 요청·비용·고객·성과가 일대일로 연결되는 구조이기 때문이다.

에이전트 워크플로는 다르다. 에이전트는 작업을 여러 단계로 분해한다. 각 단계는 모델을 호출한다. 첫 번째 모델이 실패하면 다른 모델로 폴백하는 단계도 있다. 결과가 불량하면 재시도하는 단계도 있다. 그 자체로 비용이 발생하는 외부 도구를 호출하는 단계도 있다. 사용자 요청 하나가 여러 업체에 걸쳐 수십 건의 추론 호출을 유발할 수 있으며, 업체 청구서로는 분해할 수 없는 방식으로 비용이 누적된다.

텔레메트리가 에이전트 단계 세분성을 캡처하지 않으면, 어느 단계가 수익성이 있는지 아무도 알 수 없다. 집계 비용은 3주 후 청구서에 반영된다. 그 시점이면 워크플로는 이미 규모를 키워 운영 중이고, 고객은 온보딩됐으며, 수익성 없는 경로는 수천 번 재시도된 뒤다.

에이전트가 호출을 담당하면, 비즈니스 맥락 없이 발생하는 비용 이벤트의 양이 한 자릿수 규모로 늘어난다. 감당 불가능해지기 전에 계측 체계를 갖출 수 있는 시간이 좁아지고 있다.

세 가지 소스를 통합했을 때 달라지는 것

세 가지 소스를 통합하면 AI 투자 논의의 성격 자체가 달라진다.

동일한 AI 기능을 구현하는 다양한 접근법 사이의 실질적 차이가 비로소 보이기 시작한다. 성과 지표상으로는 고만고만해 보여도, 비용은 최대 10배까지 갈린다. 팀은 유사한 비즈니스 성과를 5분의 1 비용으로 달성하는 접근법을 선택할 수 있다. 차이를 비로소 볼 수 있기 때문이다. 제품 팀은 출시 후 예산 검토 단계가 아닌 아키텍처 단계부터 마진을 고려해 기능을 설계한다. 엔지니어링 팀은 레이턴시·품질과 함께 성과당 비용 데이터를 갖고 모델 아키텍처를 선택한다. 경영진은 AI 이니셔티브를 다른 자본 배분과 동일한 방식으로, 즉 인게이지먼트 차트가 아닌 단위 경제학 기준으로 평가한다. 집계 청구서는 고객 인터랙션당 비용을 추적한다. 인게이지먼트 지표는 기능별 마진을 드러낸다. 직관에 의존하던 모델 선택이 실제 성과당 비용 데이터와 대조된다.

몇 초 안에 어떤 AI 기능이 수익성이 있는지, 어떤 기능을 확장해야 하는지, 어떤 기능을 폐기해야 하는지 누구나 확인할 수 있다. 모두가 찾고 있는 인사이트가 바로 이것이며, 이를 달성한 기업이 AI의 이점을 극대화할 것이다.

직접 구축의 함정

AI에 드는 비용은 지금 이 순간에도 누적되고 있다. 이사회는 내부 프로젝트가 프로덕션에 도달하기까지 18개월을 기다리지 않는다.

그럼에도 직접 구축하려는 유혹은 어느 때보다 강하다. AI 코딩 도구 덕분에 소규모 엔지니어링 팀이 한 분기에 출시할 수 있는 범위가 크게 늘었다. 계측 레이어는 다룰 수 있어 보인다. 비용 정규화는 주말 프로젝트처럼 보인다. 시맨틱 모델은 시니어 엔지니어가 한 스프린트 만에 초안을 잡을 수 있을 것처럼 느껴진다.

그러나 이것은 함정이다. 이유는 세 가지다.

첫 번째는 규모다. 프로덕션 AI 환경은 시간당 수백만 건의 텔레메트리 이벤트를 생성하며, 에이전트 도입이 확산될수록 규모도 커진다. 그 규모에서의 실시간 수집·상관관계 분석·귀속은 오후 한나절에 프로토타입을 바이브 코딩하는 것과 차원이 다른 문제다. 매 순간 정확하게 작동해야 하는 영구적인 운영 시스템이다.

두 번째는 업체 생태계다. 비용 데이터는 상호운용되지 않는 스키마를 가진 업체로부터 지연된 청구 주기로 도착한다. 스키마는 예고 없이 변경된다. 매달 새로운 AI 업체가 시장에 진입하며, 각자 고유한 분류 체계와 과금 방식을 갖고 있다. 시스템은 한 번 구축하고 끝나는 것이 아니다. 대다수 내부 릴리즈 주기보다 빠르게 움직이는 이동 표적을 상대로 계속 유지보수해야 한다.

세 번째는 앞선 두 가지가 합산된 결과다. 비즈니스 핵심 인프라라는 점이다. CFO와 이사회는 이 시스템이 산출하는 데이터를 바탕으로 자본 배분 결정을 내린다. 스키마 드리프트가 2주 동안 감지되지 않을 때, 에이전트 텔레메트리 스트림이 청구 API를 조용히 변경한 업체와 상관관계를 잃을 때, 오류의 대가는 한 스프린트의 정리 작업이 아니다. 잘못 배분된 한 분기의 자본이다.

엔지니어링 리더에게 ‘직접 구축할 것인가, 외부 솔루션을 쓸 것인가’라는 질문의 핵심이 바뀌었다. ‘만들 수 있느냐’는 더 이상 쟁점이 아니다. 만들 수 있다. 진짜 질문은 따로 있다. 가장 뛰어난 엔지니어들의 시간을 비용 데이터·텔레메트리·비즈니스 성과를 한데 꿰는 작업에 써야 하는가, 아니면 그 비용 데이터가 측정하는 매출을 실제로 만들어내는 AI 제품 개발에 써야 하는가다.

그 역량은 몇 주 만에 재현 가능하다. 선택은 앞으로의 18개월을 구축에 쓸 것인지, 활용에 쓸 것인지다.
dl-itworldkorea@foundryco.com ...