클라우드 청구서를 열어본 적이 있는 엔지니어라면 한 번쯤 이런 경험을 했을 것이다. 분명히 아무것도 바꾼 게 없는데 이번 달 청구액이 지난달보다 30% 늘어 있다. 담당자에게 물어보면 "AI 툴이 자동으로 뭔가를 했나 봐요"라는 대답이 돌아온다. AI 클라우드 환경에서 이제 비용의 발생 지점은 더 이상 "사람이 무엇을 배포했는가"가 아니다. "무엇이 런타임에서 스스로 결정을 내렸는가"가 청구를 만드는 진짜 원인이 되고 있다.

이것이 단순한 비용 관리 문제로 보인다면, 한 겹 더 들어가 볼 필요가 있다. 비용은 증상이다. 그 아래에는 거버넌스 구조 자체의 붕괴가 있다.

---

AI 클라우드에서 "청구 이벤트"를 만드는 건 이제 사람이 아니다

전통적인 클라우드 아키텍처에서 청구 이벤트는 명확한 인과 관계를 따랐다. 사람이 인프라를 설계하고, 승인을 받고, 배포하면 그에 따라 비용이 발생했다. 책임의 흐름이 선형이었다.

그런데 AI 오케스트레이션 레이어가 끼어들면서 이 흐름이 무너졌다. LLM 기반 에이전트는 런타임 중에 스스로 다음과 같은 결정을 내린다.

• 벡터 검색을 몇 번 호출할 것인가
• 실패한 API 요청을 몇 번 재시도할 것인가
• 어떤 외부 서비스를 추가로 연결할 것인가
• 로그를 어느 수준까지 기록할 것인가
• 텔레메트리 데이터를 어느 범위까지 수집할 것인가

이 결정들 하나하나가 클라우드 청구 이벤트를 만들어낸다. 그리고 이 결정들 중 어느 것도 조달 팀, 법무팀, IT 거버넌스 담당자의 명시적 승인을 거치지 않는다.

Gartner의 2024년 클라우드 거버넌스 보고서에 따르면, AI 워크로드를 운영하는 기업의 60% 이상이 "예측 불가능한 클라우드 비용 급등"을 경험했으며, 그 원인의 상당 부분이 AI 에이전트의 자율적 런타임 동작에서 비롯된 것으로 분석되었다.

---

"기본값"이 계약이 되는 세계

여기서 더 근본적인 문제가 등장한다. AI 툴의 기본 설정(default configuration)이 사실상 인프라 계약의 조건을 결정하고 있다는 점이다.

예를 들어, 어떤 AI 오케스트레이션 프레임워크가 기본적으로 "실패 시 최대 5회 재시도"를 설정해 놓았다고 가정하자. 이 설정은 누군가가 의도적으로 선택한 것이 아니라, 그냥 설치했을 때 딸려 오는 값이다. 그런데 이 기본값이 트래픽이 많은 순간에 작동하면, 외부 API 호출이 5배로 늘어나고, 그에 따른 청구도 5배가 된다.

더 심각한 것은 이 재시도 로직이 외부 유료 API(예: 임베딩 생성 API, 검색 증강 API)를 향하고 있을 때다. 아무도 "이 API를 5회 호출하는 데 동의합니다"라고 서명한 적이 없다. 하지만 청구서는 날아온다.

이전에 내가 다뤘던 AI Cloud, 이제 "무엇을 실행하는가"보다 "누가 멈출 수 있는가"가 더 위험하다라는 글에서도 지적했듯이, AI 툴이 일단 실행을 시작하면 그것을 멈추는 주체와 권한이 불명확해지는 구조적 문제가 있다. 청구 문제는 바로 그 "멈출 수 없음"의 재정적 결과다.

---

AI 클라우드 청구 구조의 세 가지 취약 지점

실무에서 관찰되는 AI 클라우드 청구 거버넌스의 취약점은 크게 세 가지로 정리할 수 있다.

1. 오케스트레이션 레이어의 "조용한 확장"

LangChain, AutoGen, CrewAI 같은 AI 오케스트레이션 프레임워크는 에이전트가 작업을 수행하는 과정에서 필요하다고 판단되는 도구(tool)를 자율적으로 호출한다. 이 호출 체인이 얼마나 깊어질지는 사전에 정확히 예측하기 어렵다. 에이전트가 "정보가 부족하다"고 판단하면 검색 호출을 추가하고, 그 결과가 충분하지 않으면 또 다른 API를 연결한다. 이 과정은 로그에 남지만, 청구 승인 프로세스와는 완전히 단절되어 있다.

2. 텔레메트리와 관찰 가능성의 자동 확장

AI 운영팀은 모델 성능을 모니터링하기 위해 다양한 텔레메트리 도구를 사용한다. 문제는 이 도구들이 기본적으로 최대 수준의 로깅을 활성화해 놓는 경향이 있다는 점이다. 프롬프트 입출력, 토큰 수, 레이턴시, 오류 스택 등 모든 것이 기록된다. 이 데이터는 클라우드 스토리지에 저장되고, 분석 파이프라인을 통해 처리되며, 대시보드로 시각화된다. 각 단계마다 비용이 발생한다. 그리고 이 비용을 "누가 승인했는가"를 추적하는 것은 사실상 불가능에 가깝다.

3. 컨텍스트 보존과 세션 메모리의 누적

AI 에이전트가 장기 작업을 수행할 때, 컨텍스트 윈도우를 넘어서는 정보는 벡터 데이터베이스나 캐시에 저장된다. 이 저장 공간은 세션이 끝난 후에도 명시적으로 삭제하지 않으면 그대로 남아 있다. 시간이 지나면서 이 "죽은 메모리"들이 누적되고, 그에 따른 스토리지 비용도 조용히 쌓인다. 누가 이 데이터를 보존하기로 결정했는가? 대부분의 경우, 아무도 결정하지 않았다. 그냥 기본값이 그렇게 되어 있을 뿐이다.

---

왜 기존 FinOps 방법론이 작동하지 않는가

클라우드 비용 최적화를 위한 FinOps(Financial Operations) 방법론은 지난 몇 년간 기업 IT의 표준 관행으로 자리 잡았다. 그런데 AI 클라우드 환경에서는 이 방법론의 전제가 흔들린다.

FinOps의 핵심 전제는 "비용 발생의 주체를 식별할 수 있다"는 것이다. 태그(tag)를 붙이고, 팀별로 예산을 할당하고, 초과 사용을 추적한다. 이 모든 것은 "사람이 결정하고 사람이 실행한다"는 가정 위에 서 있다.

하지만 AI 에이전트가 런타임에서 스스로 API를 호출하고, 스스로 재시도하고, 스스로 데이터를 저장하는 환경에서는 비용 발생의 주체가 모호해진다. 에이전트가 호출한 API의 비용은 어느 팀의 예산에서 차감해야 하는가? 에이전트를 "배포한" 팀인가, 에이전트에게 작업을 "요청한" 사용자인가, 아니면 에이전트가 자율적으로 연결한 외부 서비스의 계약을 맺은 팀인가?

이 질문에 명확히 답할 수 있는 기업은 아직 많지 않은 것으로 보인다.

---

실질적으로 지금 당장 할 수 있는 것

거버넌스 구조를 하루아침에 바꿀 수는 없다. 하지만 지금 당장 적용할 수 있는 실질적인 접근법은 존재한다.

런타임 결정 감사(Runtime Decision Audit) 도입

AI 에이전트가 런타임에서 내리는 결정(API 호출, 재시도, 외부 서비스 연결)을 청구 이벤트와 연결해서 기록하는 별도의 감사 레이어를 도입해야 한다. 이것은 단순한 로그가 아니다. "이 청구 이벤트는 어떤 에이전트 결정에서 비롯되었는가"를 역추적할 수 있는 구조가 필요하다.

기본값 감사(Default Audit) 주기적 실시

조직에서 사용하는 모든 AI 오케스트레이션 프레임워크와 툴의 기본 설정값을 정기적으로 검토해야 한다. 특히 재시도 횟수, 텔레메트리 수준, 컨텍스트 보존 기간은 비용에 직접적인 영향을 미치는 파라미터다. 이 값들이 "아무도 결정하지 않은 채로" 운영되고 있는 것은 없는지 확인해야 한다.

에이전트별 비용 상한선(Cost Ceiling) 설정

에이전트 단위로 일일/월간 비용 상한선을 설정하고, 이를 초과할 경우 자동으로 실행을 중단하거나 인간의 승인을 요청하는 메커니즘을 구현해야 한다. 이것은 기술적으로 어렵지 않다. 하지만 놀랍게도 이를 실제로 구현하고 있는 조직은 아직 소수인 것으로 보인다.

조달-IT-법무 간 "AI 청구 책임 매트릭스" 수립

AI 툴이 자율적으로 외부 서비스를 호출할 때 발생하는 비용의 책임 소재를 사전에 명확히 정의한 책임 매트릭스가 필요하다. 이것은 거버넌스 문서이지만, 동시에 기술 아키텍처 결정이기도 하다. 조달, IT, 법무가 함께 앉아서 만들어야 하는 문서다.

---

청구서는 거버넌스의 거울이다

결국 AI 클라우드 청구서는 단순한 비용 명세서가 아니다. 그것은 조직의 거버넌스 구조가 얼마나 AI 시대에 맞게 업데이트되었는가를 보여주는 거울이다.

"누가 이것을 배포했는가"라는 질문으로 책임을 추적하던 시대는 끝나가고 있다. 이제는 "무엇이 이 청구를 만들었는가", "그 결정을 내린 것은 사람인가 에이전트인가", "그 결정에 누가 어떤 권한으로 동의했는가"를 물어야 한다.

이 질문들에 답할 수 없다면, 청구서는 계속 예측 불가능하게 늘어날 것이다. 그리고 그것은 단순히 돈의 문제가 아니라, AI 시스템에 대한 신뢰와 통제력의 문제다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 하지만 그 도구가 스스로 계약서를 쓰기 시작했다면, 우리는 도구를 다시 설계할 책임이 있다. 청구서가 그 시작점이 될 수 있다.

---

이 글과 관련하여 AI 클라우드 거버넌스의 또 다른 측면인 AI Cloud, 이제 "무엇을 실행하는가"보다 "누가 멈출 수 있는가"가 더 위험하다도 함께 읽어보시길 권한다.

저는 위의 내용이 이미 완결된 글임을 확인했습니다. 결론("청구서는 거버넌스의 거울이다")과 관련 글 링크까지 포함되어 있어, 이 글 자체는 완성된 상태입니다.

혹시 다음 편 글을 새로 작성하길 원하시나요? 아니면 이 글의 특정 섹션을 보완하거나 확장하길 원하시나요?

현재까지 다루신 주제들을 보면:

누가 멈출 수 있는가 무엇이 연결되어 있는가 누가 소유권을 갖는가 무엇을 잊기로 결정하는가 아키텍처를 누가 선택하는가 청구를 누가 만드는가 (이번 글)

아직 다루지 않은 새로운 각도로 쓸 수 있는 주제를 제안드릴 수도 있습니다. 방향을 알려주시면 바로 시작하겠습니다.