AI 클라우드, 이제 "청구서를 이해한다"는 것이 왜 불가능해졌는가

AI 클라우드 환경에서 청구서는 더 이상 읽히는 문서가 아니다. 숫자는 있지만 의미가 없고, 항목은 있지만 원인이 없다. 이 글은 왜 AI 도구 도입 이후 클라우드 비용의 해석 가능성 자체가 붕괴했는지를 다룬다.

지난 몇 년간 기업들이 AI 도구를 클라우드 환경에 도입하면서 이상한 현상이 반복되고 있다. 분명히 "AI 사용량을 줄였다"고 보고했는데 다음 달 청구서는 오히려 늘었다. FinOps 팀이 비용 최적화 작업을 마쳤다고 선언했는데, 두 달 후 예상치 못한 항목이 다시 솟아났다. 담당자에게 물어보면 돌아오는 대답은 대개 비슷하다. "저도 잘 모르겠어요."

이건 무능의 문제가 아니다. 구조의 문제다.

AI 클라우드 청구서가 "읽을 수 없는" 이유

전통적인 클라우드 청구서는 나름의 논리가 있었다. EC2 인스턴스를 몇 시간 켰고, S3에 몇 GB를 저장했고, 데이터 전송이 얼마였다. 복잡하긴 해도 원인과 결과가 이어졌다.

AI 도구가 들어오면서 이 연결고리가 끊어졌다.

사용자가 AI 어시스턴트에게 질문 하나를 던지는 순간, 백엔드에서는 동시에 여러 청구 차원이 활성화된다. 토큰 처리 비용, 벡터 DB 조회, 오케스트레이션 레이어의 API 호출, 재시도(retry) 로직, 텔레메트리 로그 저장, 그리고 에이전트가 외부 도구를 호출할 경우 추가 컴퓨팅까지. 이 모든 것이 단 하나의 사용자 요청에서 파생되지만, 청구서에는 각각 다른 카테고리, 다른 서비스명, 다른 리전 항목으로 흩어진다.

"One user request fragments across many billing dimensions at once, making the cost signature structurally illegible for standard FinOps."

이것이 핵심이다. 비용이 숨어있는 게 아니라, 비용의 서명(cost signature) 자체가 표준 FinOps 도구로는 판독 불가능한 형태로 분산되어 있다는 것.

토큰, 에이전트, 라우팅, 재시도 — 숨겨진 변수들

AI 워크로드를 구성하는 요소들은 기존 클라우드 자원 모델과 근본적으로 다르게 작동한다.

토큰 비용은 요청의 복잡도에 따라 비선형적으로 증가한다. 같은 기능을 쓰더라도 컨텍스트 창이 길어지면 비용이 수배로 뛴다. 그런데 이 컨텍스트 창 길이는 사용자가 아니라 에이전트 오케스트레이션 레이어가 결정한다.

에이전트 시스템은 더 복잡하다. 단일 요청이 여러 하위 에이전트로 분기되고, 각 에이전트가 외부 도구를 호출하고, 그 결과를 다시 취합하는 과정에서 API 호출 횟수는 기하급수적으로 늘어난다. 사용자는 버튼 하나를 눌렀지만, 백엔드에서는 수십 개의 청구 이벤트가 발생했을 수 있다.

라우팅 로직은 또 다른 변수다. 멀티모델 환경에서 어떤 모델로 요청이 라우팅되느냐에 따라 비용이 10배 이상 차이날 수 있다. 그리고 이 라우팅 결정은 대부분 자동화되어 있어 사람이 개입하지 않는다.

재시도(retry)는 가장 과소평가된 비용 요소다. AI 추론 파이프라인에서 타임아웃이나 오류가 발생하면 자동으로 재시도가 발생한다. 이 재시도는 정상 요청과 동일한 비용을 발생시키지만, 청구서에는 원래 요청과 구분 없이 기록된다.

a close up of a server's nameplates on the side of a

Photo by Marc PEZIN on Unsplash

"AI" 항목이 없는 AI 비용

더 아이러니한 건, 이 모든 비용이 "AI" 라는 라벨 없이 청구서에 기록된다는 점이다.

토큰 처리 비용은 "Compute"로 잡힌다. 벡터 DB는 "Storage"로 잡힌다. 오케스트레이션 API 호출은 "API Gateway"로 잡힌다. 텔레메트리 로그는 "Logging/Monitoring"으로 잡힌다. 각각의 항목을 보면 평범한 인프라 비용처럼 보인다. 하지만 그 총합이 AI 도구 도입 이전과 비교했을 때 30~50% 증가했다면, 그 원인을 어느 항목에서도 찾을 수 없다.

이것이 FinOps 팀이 직면한 현실이다. 비용이 늘었다는 건 알지만, 어디서 왜 늘었는지를 기존 도구와 방법론으로는 추적할 수 없다.

AI 클라우드 비용의 새로운 속성: 아키텍처 레벨의 불투명성

문제는 단순히 "항목이 많다"는 게 아니다. AI 도구가 만들어내는 비용은 아키텍처 레벨에서 발생하는 구조적 불투명성을 가진다.

기존 클라우드 아키텍처는 팀이 설계하고 승인한 구성 요소들로 이루어진다. 각 구성 요소는 명확한 소유자가 있고, 비용 센터가 있고, 최적화 책임자가 있다. 하지만 AI 도구는 이 구조를 우회한다.

파일럿 프로젝트로 시작한 AI 도구가 프로덕션 워크플로우에 편입되면, 그 도구가 의존하는 인프라 레이어들(벡터 DB, 임베딩 서비스, 캐시 레이어, 로그 파이프라인)도 함께 프로덕션 수준으로 격상된다. 이 과정에서 공식 승인 없이 아키텍처가 재편된다. 그리고 이렇게 재편된 아키텍처에서 발생하는 비용은 기존의 비용 귀속(cost attribution) 모델로는 포착되지 않는다.

한 가지 비유를 들자면, 이것은 마치 건물 도면에 없는 전기 배선이 벽 안에 깔리는 것과 같다. 전기는 분명히 쓰이고 있고 요금도 나오지만, 어느 방에서 어떤 용도로 쓰이는지를 도면만 보고는 알 수 없는 상황이다.

실무에서 이미 벌어지고 있는 일들

이 현상은 이론적 우려가 아니다. 이미 여러 기업에서 반복적으로 관찰되는 패턴이 있다.

패턴 1: 비용 귀속 공백(Attribution Void) AI 도구 도입 후 클라우드 비용이 증가했지만, 어느 팀의 예산에서 처리해야 할지 결정하지 못해 수개월간 미처리 상태로 남는 경우. 엔지니어링 팀은 "우리 서비스가 아니라 AI 플랫폼 비용"이라 하고, AI 팀은 "우리는 API만 호출했을 뿐"이라 한다.

패턴 2: 플랫폼 번들링의 함정 클라우드 벤더가 AI 기능을 기존 서비스에 번들로 포함시키면서, "AI를 쓰지 않아도" 이미 AI 관련 인프라 비용이 발생하는 구조가 만들어진다. 예를 들어, Azure OpenAI를 사용하지 않더라도 Microsoft 365 Copilot을 구독하는 순간 백엔드에서 일정한 인프라 비용이 발생할 수 있다.

패턴 3: 재시도 폭탄 프로덕션 환경에서 AI 추론 서비스의 레이턴시가 높아지거나 오류율이 증가할 때, 자동 재시도 로직이 비용을 수배로 증폭시키는 사례. 이 비용은 모니터링 대시보드의 "오류율" 지표에는 잡히지만 비용 대시보드에는 정상 요청과 구분 없이 합산된다.

그렇다면 무엇을 해야 하는가

현실적인 처방은 "더 좋은 FinOps 도구를 쓰자"가 아니다. 도구의 문제가 아니라 모델의 문제이기 때문이다. 기존 FinOps 모델은 AI 워크로드의 비용 구조를 전제하지 않고 설계되었다.

지금 당장 실무에서 적용 가능한 접근법은 세 가지다.

첫째, 비용 귀속 단위를 "서비스"에서 "요청 흐름(request flow)"으로 바꿔라. AI 워크로드에서 의미 있는 비용 단위는 개별 클라우드 서비스가 아니라, 하나의 사용자 요청이 거치는 전체 처리 경로다. 이 경로를 추적할 수 있는 분산 트레이싱(distributed tracing)을 AI 파이프라인에 적용하는 것이 출발점이다.

둘째, "AI 사용량 감소"를 비용 지표로 쓰지 마라. 앞서 언급한 연결세(Connection Tax) 구조 때문에, AI 도구 사용을 줄여도 그 도구가 의존하는 인프라 비용은 계속 발생한다. 의미 있는 비용 지표는 "AI 도구 호출 횟수"가 아니라 "AI 관련 인프라의 총 운영 비용(Total Cost of AI Infrastructure)"이어야 한다.

셋째, 재시도와 라우팅 로직을 비용 거버넌스 대상으로 포함하라. 대부분의 기업에서 재시도 정책과 모델 라우팅 로직은 엔지니어링 팀의 기술적 결정으로만 취급된다. 하지만 이 결정들이 비용에 미치는 영향은 인프라 사이징 결정 못지않게 크다. 이 로직들을 FinOps 검토 대상에 포함시켜야 한다.

AI 클라우드 거버넌스의 다음 전선

비용 해석 가능성의 붕괴는 단순히 재무 문제가 아니다. 이것은 거버넌스 문제이자 아키텍처 문제다.

청구서를 이해할 수 없다는 것은, 무엇이 얼마나 실행되고 있는지를 파악할 수 없다는 뜻이다. 그리고 그것을 파악할 수 없다면, 무엇을 끄고 무엇을 유지할지도 결정할 수 없다. 결국 AI 클라우드 환경에서 비용의 불투명성은 운영 통제력의 상실로 이어진다.

구윤철의 뉴욕 로드쇼에서 드러난 코리아 프리미엄 논쟁이 한국 경제의 신뢰 가능성 문제를 다루듯, AI 클라우드 거버넌스 역시 결국은 "이 시스템을 신뢰할 수 있는가"라는 질문으로 귀결된다. 청구서를 이해할 수 없는 시스템은 신뢰할 수 없는 시스템이다.

Gartner의 클라우드 비용 관리 연구에 따르면 기업들은 클라우드 예산의 평균 30% 이상을 낭비하고 있는 것으로 추정되는데, AI 워크로드가 확산되는 지금 이 수치는 더 높아질 가능성이 있다.

앞으로 AI 클라우드 거버넌스의 핵심 역량은 "AI를 얼마나 많이 쓰느냐"가 아니라 "AI가 만들어내는 비용의 흐름을 얼마나 읽어낼 수 있느냐" 로 재정의될 것이다. 그 역량을 갖춘 기업과 그렇지 못한 기업 사이의 격차는, 지금 이 순간에도 조용히 벌어지고 있다.

이 글은 현재 관찰되는 패턴과 업계 동향을 바탕으로 작성되었으며, 일부 수치와 예측은 추정치일 수 있습니다.

지금까지의 내용을 읽은 독자라면 자연스럽게 이런 질문을 던질 것이다. "그래서 지금 당장 우리 조직은 무엇을 해야 하는가?"

이 질문에 답하기 위해, 나는 한 가지 비유를 들고 싶다.

1990년대 말 인터넷이 기업 내부로 들어오던 시절을 기억하는가. 당시 IT 부서는 "인터넷 사용량"을 관리하려 했다. 하지만 진짜 문제는 사용량이 아니었다. 인터넷이 기업의 커뮤니케이션 구조 자체를 바꾸고 있다는 사실이었다. 사용량을 줄인다고 해서 이미 인터넷에 의존하게 된 업무 흐름이 사라지지는 않았다. 지금 AI 클라우드가 정확히 같은 궤적을 밟고 있다.

비용 해석 가능성, 이제는 경쟁력의 문제다

솔직히 말하자. 지금 대부분의 기업 FinOps 팀은 AI 워크로드 앞에서 당혹스러운 상황에 처해 있다. 대시보드는 있다. 숫자도 있다. 그런데 그 숫자가 무엇을 의미하는지 설명할 수 있는 사람이 없다.

이것은 도구의 문제가 아니다. 프레임의 문제다.

기존 FinOps 프레임은 "서비스를 배포하면 비용이 발생하고, 서비스를 끄면 비용이 멈춘다"는 선형 논리 위에 세워져 있다. 하지만 AI 워크로드는 이 논리를 무너뜨린다. 하나의 사용자 요청이 토큰 처리, 에이전트 라우팅, 재시도, 벡터 검색, 로그 저장으로 쪼개지는 순간, 비용은 더 이상 단일 원인에 귀속되지 않는다.

이 구조적 비가시성을 방치하면 어떻게 되는가. 세 가지 결과가 순서대로 찾아온다.

첫 번째는 예산 불신이다. 엔지니어링 팀은 "우리는 AI 사용을 줄였다"고 보고하고, 재무팀은 "그런데 왜 청구서는 늘었느냐"고 묻는다. 둘 다 틀리지 않았다. 단지 서로 다른 현실을 보고 있을 뿐이다. 이 간극이 쌓이면 조직 내 신뢰가 무너진다.

두 번째는 의사결정 마비다. 어떤 AI 워크로드가 실제로 비용 대비 가치를 만들어내는지 판단할 근거가 없어지면, 경영진은 "일단 다 유지하자"거나 "일단 다 줄이자"는 극단적 선택만 남는다. 둘 다 전략이 아니다.

세 번째는 보안 리스크의 증폭이다. 비용을 추적할 수 없다는 것은 곧 무엇이 실행되고 있는지를 추적할 수 없다는 뜻이다. 이전 글에서 다룬 "아키텍처 점유" 문제와 맞물리면, 승인받지 않은 AI 워크로드가 핵심 인프라에 조용히 뿌리를 내리고 있어도 이를 감지할 방법이 없어진다.

지금 당신의 조직이 물어야 할 세 가지 질문

거창한 로드맵보다 먼저, 현재 상태를 진단하는 것이 우선이다. 다음 세 가지 질문에 답할 수 있는지 확인해 보라.

1. 우리 조직의 AI 관련 클라우드 비용 중, "AI를 쓰지 않아도 발생하는 비용"이 얼마인가?

이것이 바로 연결세(Connection Tax)다. 벡터 데이터베이스 유지 비용, 임베딩 저장소, 오케스트레이션 레이어의 상시 운영 비용이 여기에 해당한다. 이 숫자를 모른다면, 비용 최적화 논의 자체가 모래 위의 집이다.

2. 지난 한 달간 가장 많은 클라우드 비용을 발생시킨 AI 워크로드의 재시도율(retry rate)은 얼마인가?

재시도는 단순한 엔지니어링 파라미터가 아니다. 재시도율 5%와 15%의 차이는 같은 서비스를 운영하는 데 드는 실질 비용을 수십 퍼센트 단위로 바꿔놓을 수 있다. 이 숫자를 FinOps 팀이 보고 있지 않다면, 비용 거버넌스에 구멍이 뚫려 있는 것이다.

3. 우리 조직에서 AI 워크로드를 "종료(sunset)"한 사례가 있는가? 있다면, 그 이후 관련 인프라 비용이 실제로 줄었는가?

이 질문이 가장 핵심이다. AI 도구를 끈 이후에도 비용이 계속 발생하고 있다면, 그것은 연결세가 이미 구조화되어 있다는 신호다. 그리고 그 구조를 해체하는 것은 단순한 클릭 한 번으로 해결되지 않는다.

결론: 청구서를 읽을 수 있는 조직이 살아남는다

AI 클라우드 시대의 FinOps는 이제 숫자를 집계하는 일이 아니다. 숫자가 만들어지는 구조를 이해하는 일이다.

토큰이 어떻게 비용으로 전환되는지, 에이전트 라우팅이 어떤 청구 항목을 만들어내는지, 재시도 로직이 월말 청구서에 어떻게 반영되는지를 읽어낼 수 있는 역량. 이것이 앞으로 AI 클라우드 거버넌스의 핵심 리터러시가 될 것이다.

기술은 항상 우리가 준비한 것보다 빠르게 움직인다. 인터넷이 그랬고, 모바일이 그랬고, 클라우드가 그랬다. AI도 다르지 않다. 다만 이번에는 한 가지가 다르다. AI는 단순히 새로운 서비스를 추가하는 것이 아니라, 기존 인프라가 작동하는 방식과 비용이 발생하는 논리 자체를 바꾸고 있다.

그 변화를 인식하고 있는 조직과 그렇지 않은 조직의 차이는, 지금 당장 청구서 한 장에서 시작된다. 당신의 조직은 오늘 받은 클라우드 청구서를 설명할 수 있는가.

그 질문에 자신 있게 "예스"라고 답할 수 있을 때, 비로소 AI 클라우드 거버넌스의 출발선에 선 것이다.