AI 클라우드, 이제 "얼마나 쓰는가"보다 "무엇이 결정하는가"를 먼저 물어야 한다

2026년 4월 현재, 많은 기업의 클라우드 청구서는 예산 담당자가 이해할 수 없는 언어로 쓰여 있다. 줄줄이 나열된 항목들—추론 호출, 벡터 검색, 오케스트레이션 이벤트, 이그레스 트래픽—은 분명히 누군가가 "AI 클라우드를 쓰겠다"고 결정했을 때 시작됐다. 그런데 그 결정이 어디서, 누가, 언제 내렸는지를 추적하는 것은 이미 불가능에 가까워졌다. 문제는 비용이 아니다. 비용을 만들어내는 결정 구조 자체가 바뀌었다는 것이다.

"누가 승인했는가"라는 질문이 더 이상 작동하지 않는 이유

전통적인 클라우드 거버넌스는 단순한 인과 사슬 위에 세워졌다.

요청 → 승인 → 배포 → 비용 → 책임자

이 구조는 인간이 모든 의사결정 노드에 있을 때 작동한다. 개발자가 EC2 인스턴스를 켜면, 그 인스턴스의 비용은 특정 팀의 비용 센터에 귀속된다. 누가 켰는지, 왜 켰는지, 얼마나 쓸 건지—모두 추적 가능하다.

AI 툴이 이 사슬을 끊는 방식은 극적이지 않다. 오히려 조용하고, 합리적이고, 점진적이다.

예를 들어보자. 한 기업이 내부 문서 검색을 위해 RAG(Retrieval-Augmented Generation) 기반 어시스턴트를 파일럿으로 도입한다. 처음엔 하루 수십 건의 쿼리. 비용은 미미하다. 그런데 이 툴은 쿼리 하나를 처리하면서 스스로 결정한다: 어떤 벡터 인덱스를 얼마나 깊이 검색할지, 결과가 불확실하면 재시도를 몇 번 할지, 로그를 어느 수준으로 남길지, 외부 API를 호출할지. 이 결정들은 아무도 승인하지 않았다. 툴의 아키텍처가 기본값으로 내린 결정이다.

사용자가 늘어나면서 이 "기본값들"이 만들어내는 청구 이벤트는 기하급수적으로 증가한다. 그리고 어느 날 CFO가 묻는다: "이 비용, 누가 승인한 거야?" 아무도 손을 들지 못한다. 승인한 사람이 없기 때문이 아니라, 승인이라는 행위 자체가 이 아키텍처에는 존재하지 않기 때문이다.

AI 툴이 "결정"을 내리는 세 가지 구조적 경로

AI 클라우드 환경에서 툴이 인간의 개입 없이 결정을 내리는 경로는 크게 세 가지로 분류할 수 있다.

1. 런타임 파라미터 선택

LLM 오케스트레이션 레이어(LangChain, LlamaIndex, AutoGen 등)는 런타임에 어떤 모델을 쓸지, 컨텍스트 윈도우를 얼마나 채울지, 검색 깊이를 어떻게 설정할지를 동적으로 결정한다. 이 결정 하나하나가 청구 이벤트다. 그리고 이 결정은 어떤 거버넌스 문서에도 등장하지 않는다.

2. 에러 처리와 재시도 로직

AI 툴은 실패를 스스로 처리하도록 설계되어 있다. 외부 API 호출이 실패하면 재시도한다. 벡터 검색 결과가 낮은 신뢰도를 보이면 다른 인덱스를 추가로 검색한다. 이 재시도 로직은 정상적인 엔지니어링 관행처럼 보이지만, 동시에 아무도 승인하지 않은 추가 비용을 자동으로 생성한다.

3. 관찰 가능성(Observability) 인프라의 자동 확장

AI 툴은 자체 모니터링을 위해 로그, 트레이스, 메트릭을 대규모로 생성한다. 이 데이터는 어딘가에 저장되고, 저장은 비용이다. 더 중요한 것은, 이 관찰 가능성 인프라가 종종 원래 워크로드보다 더 많은 스토리지와 이그레스 비용을 만들어낸다는 점이다. 그리고 이 인프라를 끄면 디버깅 능력이 사라진다—그래서 아무도 끄지 않는다.

two hands touching each other in front of a blue background

Photo by Igor Omilaev on Unsplash

"결정 감사(Decision Audit)"가 새로운 거버넌스 언어가 되어야 한다

기존의 클라우드 거버넌스 프레임워크—태깅 정책, 비용 센터 배분, 예산 알림—는 인간이 결정을 내리고 시스템이 실행한다는 전제 위에 설계됐다. AI 클라우드 환경에서는 이 전제가 역전된다. 시스템이 결정을 내리고, 인간은 청구서를 받는다.

이 역전을 다루기 위해 필요한 것은 새로운 거버넌스 레이어다. 나는 이것을 "결정 감사(Decision Audit)" 라고 부르고 싶다. 비용이 얼마나 발생했는가를 추적하는 것이 아니라, 어떤 결정이 그 비용을 만들었는가를 추적하는 것이다.

실무적으로 이것은 다음을 의미한다:

툴 수준의 결정 로그: 오케스트레이션 레이어가 런타임에 내린 모든 파라미터 선택을 로깅. 단순한 API 호출 로그가 아니라, "왜 이 모델을, 이 깊이로, 이 횟수만큼 호출했는가"를 기록.
기본값 명시화: AI 툴의 기본 설정(재시도 횟수, 검색 깊이, 로그 보존 기간)을 아키텍처 문서가 아닌 거버넌스 문서로 관리. 기본값은 설정이 아니라 정책이다.
결정 경계 정의: 툴이 자율적으로 결정할 수 있는 범위와 인간 승인이 필요한 범위를 명시적으로 구분. 예를 들어, "재시도 3회 이상은 자동 알림", "외부 API 신규 호출은 사전 승인" 같은 규칙.

Caterpillar의 Monarch Tractor 인수 사례에서도 비슷한 패턴이 보인다. AI 자율화가 장비 제어 레이어에 스며들면서, "누가 이 결정을 내렸는가"라는 질문이 물리적 세계에서도 동일하게 제기되고 있다. AI의 결정 권한 범위를 사전에 정의하지 않으면, 나중에 책임 소재를 찾는 것은 불가능에 가까워진다.

스타트업이 더 위험한 이유

대기업은 느리지만 거버넌스 인프라가 있다. 법무팀, 조달팀, IT 보안팀이 존재한다. AI 툴이 계약 외 인프라를 조용히 확장하더라도, 언젠가는 누군가의 레이더에 걸린다.

스타트업은 다르다. 5명짜리 팀이 Claude API, OpenAI, Pinecone, LangSmith를 동시에 쓰면서 각 툴이 내리는 결정을 추적할 여력이 없다. 그리고 이 툴들은 서로 연결되어 있다—하나의 에이전트가 다른 에이전트를 호출하고, 그 호출이 또 다른 벡터 검색을 트리거한다. 이 연쇄 결정의 끝에서 청구서가 나온다.

더 심각한 것은 의존성의 비대칭이다. 스타트업이 AI 클라우드 툴에 의존하는 속도는 그 툴이 만들어내는 결정 구조를 이해하는 속도보다 훨씬 빠르다. 6개월 후에 "이 툴 없이는 프로덕션이 돌아가지 않는다"는 상황이 되어서야, 그 툴이 어떤 결정을 어떤 기준으로 내리고 있었는지를 처음으로 들여다보게 된다.

Gartner의 클라우드 비용 최적화 보고서에 따르면, 클라우드 지출의 상당 부분이 계획되지 않은 자동화에서 발생한다고 지적한다. AI 오케스트레이션이 보편화된 지금, 이 비율은 더 높아졌을 가능성이 있다.

AI 클라우드 거버넌스의 실질적 체크리스트

이론보다 실무가 중요하다. 지금 당장 팀에서 적용할 수 있는 체크리스트를 정리한다.

1. 우리 AI 툴의 기본값을 아는가?

각 오케스트레이션 레이어의 기본 재시도 횟수, 검색 깊이, 컨텍스트 윈도우 설정을 문서화했는가?
이 기본값을 바꾸려면 어떤 승인 프로세스가 필요한가?

2. 결정 경계를 정의했는가?

AI 에이전트가 자율적으로 내릴 수 있는 결정의 범위를 명시했는가?
외부 API 신규 호출, 데이터 저장소 확장, 새로운 모델 호출—이 중 어떤 것이 자동이고 어떤 것이 승인 필요인가?

3. 비용의 원인을 역추적할 수 있는가?

이번 달 청구서의 상위 5개 항목이 어떤 에이전트 결정에서 비롯됐는지 30분 안에 답할 수 있는가?
답할 수 없다면, 현재의 로깅 구조는 결정 감사에 적합하지 않다.

4. 의존성 지도를 그렸는가?

현재 프로덕션에서 돌아가는 AI 툴 중 "끄면 안 되는" 것들의 목록이 있는가?
그 목록이 6개월 전과 달라졌다면, 그 변화를 누가 승인했는가?

5. 기본값 변경 이력을 추적하는가?

AI 툴의 설정 변경이 코드 변경과 동일한 수준의 리뷰와 이력 관리를 받고 있는가?

결정이 곧 인프라다

클라우드 거버넌스의 역사는 항상 기술이 먼저 달리고 정책이 뒤쫓는 패턴이었다. 가상화가 퍼지고 나서야 VM 관리 정책이 생겼고, 컨테이너가 보편화된 후에야 쿠버네티스 보안 정책이 논의됐다.

AI 클라우드는 이 패턴을 더 빠르고 더 불투명하게 반복하고 있다. 차이가 있다면, 이번에는 결정 권한 자체가 시스템 안으로 이전됐다는 점이다. 이전까지의 거버넌스 문제는 "누가 잘못된 결정을 내렸는가"였다. 지금의 문제는 "결정이 어디서 내려졌는지조차 알 수 없다"는 것이다.

비용 예측이 어렵다는 것은 증상이다. 진짜 병은 결정 가시성의 부재다. 그리고 이 병을 치료하는 처방은 더 많은 모니터링 대시보드가 아니다. AI 툴이 내리는 결정을 거버넌스의 첫 번째 객체로 인식하는 사고방식의 전환이다.

"얼마나 쓰는가"를 묻기 전에, "무엇이 결정하는가"를 먼저 물어야 한다. 그 질문에 답할 수 없다면, 청구서는 언제나 놀라움으로 끝날 것이다.

이 글은 2026년 4월 17일 기준의 AI 클라우드 거버넌스 환경을 분석한 것입니다. 개별 툴의 기본 설정과 요금 구조는 플랫폼별로 상이하며, 실무 적용 시 각 벤더의 최신 문서를 참조하시기 바랍니다.

김테크의 칼럼을 구독하고 계신다면, 이 글이 지금까지 이어온 AI 클라우드 거버넌스 시리즈의 연장선에 있다는 것을 눈치채셨을 겁니다. 오늘은 조금 다른 각도—"결정이 곧 인프라"라는 명제를 실무에서 어떻게 다룰 것인가—로 마무리를 짓겠습니다.

그래서, 다음 주에 무엇을 해야 하는가

체크리스트는 출발점이다. 하지만 많은 팀이 체크리스트를 완성하고 나서 멈춘다. 진짜 질문은 "점검 후 무엇이 바뀌어야 하는가"다.

세 가지를 제안한다.

첫째, 결정 로그를 코드 저장소 수준으로 관리하라. AI 에이전트가 내린 결정—어떤 API를 호출했는가, 몇 번 재시도했는가, 어떤 데이터 저장소에 접근했는가—은 현재 대부분 로그 파일 어딘가에 흩어져 있다. 이것을 코드 커밋처럼 추적 가능한 형태로 구조화하지 않으면, 사후 감사는 불가능하다. 결정 로그는 디버깅 도구가 아니라 거버넌스 문서다.

둘째, "기본값 검토"를 분기별 아키텍처 리뷰에 포함하라. AI 툴의 기본값은 조용히 바뀐다. 벤더가 모델을 업데이트하거나 오케스트레이션 레이어를 개선할 때, 재시도 로직이나 컨텍스트 윈도우 크기가 슬그머니 달라지는 경우가 있다. 이를 분기별로 명시적으로 검토하지 않으면, 팀은 자신이 승인한 적 없는 기본값 위에서 프로덕션을 운영하게 된다.

셋째, "AI 결정 범위 문서"를 팀의 온보딩 자료에 넣어라. 새로운 엔지니어가 팀에 합류했을 때, 그 사람이 가장 먼저 이해해야 할 것은 코드베이스가 아니라 "우리 시스템에서 AI가 자율적으로 결정할 수 있는 범위"다. 이 문서가 없다면, 신규 팀원은 자신도 모르게 기존의 결정 경계를 넘는 코드를 작성할 수 있다.

거버넌스는 제약이 아니라 속도다

마지막으로 한 가지만 덧붙이겠다.

거버넌스라는 단어를 들으면 많은 스타트업 팀이 반사적으로 "우리는 아직 그 단계가 아니다"라고 반응한다. 이해한다. 빠르게 움직여야 하는 팀에게 승인 프로세스는 브레이크처럼 느껴진다.

하지만 AI 클라우드 거버넌스는 속도를 줄이는 것이 아니다. 예측 불가능한 충격을 줄이는 것이다. 청구서 폭탄, 보안 감사 실패, 컴플라이언스 위반—이것들이야말로 팀의 속도를 실질적으로 멈추게 하는 사건들이다. 거버넌스는 그 충격을 미리 흡수하는 완충재다.

결정이 인프라라면, 거버넌스는 그 인프라의 설계도다. 설계도 없이 집을 짓는 팀은 빠르게 시작하지만, 언젠가 반드시 벽을 허물어야 하는 순간을 맞는다.

AI 클라우드는 지금 그 벽을 조용히, 그리고 빠르게 쌓고 있다.

다음 글에서는 AI 에이전트가 조직 내 역할 경계를 어떻게 재정의하고 있는지—거버넌스의 다음 전선—를 다룰 예정입니다.

궁금한 점이나 현장에서 겪고 있는 사례가 있다면 댓글로 남겨주세요. 실제 사례가 가장 좋은 분석 재료입니다.

NOCODE TECH STACKER