2026년 현재, AI 클라우드 자동화의 파도는 이미 인프라의 깊숙한 곳까지 밀려들었다. 컴플라이언스, 배포, 재해복구, 네트워크 접근제어에 이어, 이번에는 클라우드 비용의 심장부 — 오토스케일링(Auto-scaling) 이다. AI 도구들은 이제 "언제, 얼마나, 어떤 방향으로 리소스를 확장하거나 축소할지"를 정책 범위 안에서 자율적으로 결정하고 있다. 문제는 그 결정이 재무팀의 예산 승인 프로세스와 완전히 분리된 채로 실행된다는 점이다.

---

오토스케일링은 원래 "자동"이었는데, 뭐가 달라진 건가

기존의 클라우드 오토스케일링은 단순했다. CPU 사용률이 80%를 넘으면 인스턴스를 2개 추가하고, 50% 아래로 내려가면 1개를 줄인다. 규칙 기반(rule-based) 시스템이었고, 그 규칙은 엔지니어가 명시적으로 작성했다. 재무팀도 이 규칙을 이해할 수 있었고, 최악의 경우 지출 한도(spending cap)를 걸어두면 됐다.

그런데 2024년 후반부터 주요 클라우드 벤더와 서드파티 FinOps 플랫폼들이 내놓은 AI 기반 스케일링 엔진은 다르다. 이들은 단순한 임계값 규칙이 아니라, 과거 트래픽 패턴, 비즈니스 이벤트 캘린더, 외부 데이터(날씨, 마케팅 캠페인 일정, 경쟁사 가격 변동) 까지 학습해 "이 시점에 이 규모로 스케일링하는 것이 최적"이라는 판단을 내리고, 그 판단을 즉시 실행한다.

예측 스케일링(predictive scaling)이라고 불리는 이 기능은 AWS, GCP, Azure 모두 이미 일반 공개(GA) 상태다. 그리고 여기에 AI 레이어가 얹히면서, 정책 범위 내에서 실행되는 결정의 복잡성과 불투명성이 급격히 높아졌다.

---

"정책 범위 내 실행"이라는 말의 함정

AI 스케일링 도구들이 공통적으로 내세우는 논리가 있다.

"모든 결정은 사전에 승인된 정책 범위(policy envelope) 안에서만 실행됩니다."

표면적으로는 맞는 말이다. 최대 인스턴스 수, 최대 월 지출 한도, 특정 인스턴스 타입 제한 — 이런 상한선들이 설정돼 있다. 그런데 여기서 거버넌스의 공백이 생긴다.

정책 범위는 설정 시점에 한 번 승인된다. 이후 AI가 그 범위 안에서 내리는 수백 개의 개별 결정은 누구의 승인도 받지 않는다. 재무팀 입장에서는 "월 최대 $50,000까지 쓸 수 있다"고 승인한 것이지, "매주 화요일 새벽 2시에 r6g.4xlarge 인스턴스를 12개 스핀업하는 것"을 승인한 게 아니다. 하지만 AI는 그 결정을 정책 범위 내 실행으로 처리한다.

이 구조는 마치 회사가 임원에게 "연간 예산 내에서 자유롭게 집행하라"고 위임했는데, 그 임원이 매달 다른 항목에 예산을 쓰면서 보고는 연말에 한 번만 하는 것과 같다. 합법이지만, 거버넌스라고 부르기 어렵다.

---

실제로 어떤 일이 벌어지는가

가상의 시나리오가 아니다. 2025년 하반기부터 국내외 여러 기업의 FinOps 담당자들이 비슷한 패턴을 보고하고 있다.

시나리오 A — 마케팅 이벤트 연동 스케일링

한 이커머스 기업이 AI 스케일링 엔진에 마케팅 캘린더를 연동했다. 엔진은 대규모 프로모션 이벤트 전날 자동으로 인프라를 확장하도록 학습했다. 그런데 마케팅팀이 캘린더에 "테스트용 내부 이벤트"를 등록했고, AI는 이를 실제 프로모션으로 해석해 불필요한 스케일업을 실행했다. 재무팀은 해당 월 클라우드 비용이 전월 대비 23% 증가한 것을 청구서가 나온 뒤에야 확인했다.

시나리오 B — 축소 타이밍의 오판

AI 스케일링 도구가 트래픽 감소를 감지하고 야간에 인스턴스를 대폭 축소했다. 그런데 그 시간대에 배치 데이터 처리 작업이 예정돼 있었다. 작업은 실패했고, 데이터 파이프라인이 멈췄다. 엔지니어링팀은 아침에 출근해서야 이를 발견했다. AI는 "정책 범위 내에서 최적 결정을 내렸다"고 로그에 남겼다.

시나리오 C — 스팟 인스턴스 전략의 자율 변경

AI 도구가 비용 최적화를 위해 온디맨드 인스턴스 비율을 줄이고 스팟 인스턴스 비율을 높이는 결정을 내렸다. 스팟 인스턴스는 AWS가 용량이 필요할 때 언제든 회수할 수 있다. 이 변경은 정책 범위 내였지만, 재무팀과 SRE팀 모두 이 변경이 언제 이뤄졌는지 알지 못했다. 이후 스팟 인스턴스가 대규모로 회수되는 상황이 발생했고, 서비스 가용성에 영향을 미쳤다.

세 시나리오의 공통점은 하나다. 결정은 AI가 내렸고, 인간은 결과가 나타난 뒤에야 알았다.

---

AI 클라우드 스케일링이 만드는 새로운 거버넌스 공백

이 문제를 단순히 "AI가 실수했다"는 프레임으로 보면 안 된다. 더 구조적인 문제가 있다.

1. 의사결정의 원자화(Atomization)

기존에는 스케일링 결정이 드물게, 명시적으로 이뤄졌다. AI 시대에는 하루에도 수십, 수백 번의 미세 결정이 자동으로 실행된다. 각각의 결정은 정책 범위 내이지만, 그 결정들이 누적되면 전혀 다른 비용 구조가 만들어진다. 재무팀이 분기 말에 보는 숫자는 수천 개의 AI 결정이 쌓인 결과물이다.

2. 감사 가능성(Auditability)의 실종

"왜 이 시점에 이 규모로 스케일링했는가"라는 질문에 AI 도구가 주는 답은 대부분 "모델이 최적이라고 판단했습니다"다. 머신러닝 모델의 결정 이유를 사후에 완전히 재현하는 것은 현실적으로 어렵다. 감사팀이 필요로 하는 "명확한 의사결정 기록"이 존재하지 않는다.

3. 책임의 분산

스케일링 결정에 관여한 주체가 누구인가? AI 도구를 도입한 엔지니어링팀? 정책 범위를 설정한 FinOps팀? 벤더? 아무도 개별 결정에 대한 책임을 지지 않는다. 이 책임의 공백은 사고가 났을 때 가장 크게 드러난다.

영업팀의 팔로업이 AI로 자동화된다면: 코드 없이 CRM을 바꾸는 흐름이 의미하는 것에서도 비슷한 문제를 다룬 바 있다. AI 자동화가 업무 프로세스에 깊이 들어올수록, "누가 이 결정을 내렸는가"라는 질문의 답이 점점 흐릿해진다. 클라우드 스케일링은 그 흐릿함이 재무적 손실로 직결되는 영역이다.

---

왜 재무팀과 엔지니어링팀의 시각이 다른가

엔지니어링팀은 AI 스케일링을 "효율성 도구"로 본다. 실제로 잘 작동할 때는 수동 개입 없이 트래픽 급증을 처리하고, 야간에 불필요한 비용을 줄여준다. 성공 사례는 눈에 잘 보인다.

재무팀은 다른 것을 본다. 예산을 세울 때 "AI가 어떤 결정을 내릴지"를 예측할 수 없다. 클라우드 비용 예측 모델이 AI의 자율 결정 변수를 수용하지 못한다. Gartner의 2025년 FinOps 현황 보고서에 따르면, AI 기반 클라우드 비용 최적화 도구를 도입한 조직의 41%가 도입 첫 해에 예상치 못한 비용 변동을 경험했다고 보고했다.

이 간극은 기술적 문제가 아니라 거버넌스 설계 문제다. 두 팀이 서로 다른 언어로 같은 시스템을 바라보고 있다.

---

AI 클라우드 스케일링 거버넌스를 위한 실질적 접근

이 문제를 해결하기 위한 완벽한 답은 아직 없다. 하지만 지금 당장 적용할 수 있는 접근법들이 있다.

① 정책 범위를 "비용 한도"가 아닌 "결정 범주"로 재정의하라

현재 대부분의 정책 범위는 "최대 인스턴스 수 X개, 최대 월 비용 $Y"처럼 수량적 상한선으로 구성된다. 여기에 결정 범주(decision category) 개념을 추가해야 한다. 예를 들어 "스팟 인스턴스 비율을 30% 이상 변경하는 결정은 자율 실행 불가, 인간 승인 필요"처럼 결정의 성격에 따른 승인 트리거를 설계하는 것이다.

② 비용 변동 알림을 "청구 후"가 아닌 "실행 시점"에 받아라

AI 스케일링 도구의 로그를 재무팀이 실시간으로 볼 수 있는 대시보드를 구성하라. 기술적으로는 어렵지 않다. AWS Cost Anomaly Detection, GCP Budget Alerts, Azure Cost Management 모두 웹훅(webhook) 연동을 지원한다. 문제는 이 알림을 재무팀이 아닌 엔지니어링팀만 받도록 설정된 경우가 대부분이라는 점이다.

③ AI 결정 로그를 감사 가능한 형태로 저장하라

"모델이 최적이라고 판단했습니다"는 감사 기록이 아니다. 최소한 어떤 입력 데이터를 기반으로, 어떤 결정을, 언제 실행했는지를 구조화된 로그로 남겨야 한다. 일부 도구들은 이미 decision log 기능을 제공하지만, 기본값으로 활성화돼 있지 않은 경우가 많다. 반드시 확인하고 켜두어야 한다.

④ 분기 단위 "AI 결정 리뷰" 프로세스를 만들어라

AI 스케일링 도구가 지난 분기에 내린 주요 결정들을 재무팀, 엔지니어링팀, FinOps팀이 함께 리뷰하는 정례 프로세스를 만들어라. 이는 사후 감사가 아니라, 정책 범위를 현실에 맞게 조정하는 피드백 루프다. AI의 자율 결정을 완전히 막을 수는 없지만, 그 결정이 조직의 의도와 얼마나 일치하는지를 주기적으로 점검할 수 있다.

⑤ 스케일링 이벤트에 "비즈니스 컨텍스트 태그"를 붙여라

모든 스케일링 이벤트에 트리거 이유를 태그로 기록하라. "마케팅 캠페인 대응", "야간 배치 처리", "이상 트래픽 감지" 같은 태그가 붙으면, 재무팀이 비용 변동의 원인을 사후에 추적하기 훨씬 쉬워진다. 이 태그 체계는 AI 도구와 협력해 자동으로 붙일 수도 있고, 엔지니어링팀이 수동으로 정의한 이벤트 카테고리를 기반으로 매핑할 수도 있다.

---

이 문제의 본질은 "AI의 실패"가 아니다

강조하고 싶은 것이 있다. AI 스케일링 도구가 나쁜 것이 아니다. 실제로 잘 설계된 AI 스케일링은 수동 운영보다 훨씬 효율적이고, 비용 절감 효과도 크다. 문제는 도구가 아니라 그 도구를 둘러싼 거버넌스 아키텍처다.

기술은 빠르게 발전했지만, 조직의 의사결정 구조와 책임 체계는 그 속도를 따라가지 못했다. AI 클라우드 도구가 정책 범위 안에서 자율적으로 결정을 내리는 순간, 거버넌스는 "각 결정을 누가 승인하는가"에서 "정책 범위를 누가, 언제, 어떤 기준으로 설정하는가"로 이동한다. 그리고 대부분의 조직은 아직 이 이동을 인식하지 못하고 있다.

기술이 인간의 삶을 풍요롭게 하는 도구가 되려면, 그 도구가 내리는 결정에 대한 책임 구조가 명확해야 한다. AI 클라우드 스케일링이 분기 결산 이후에야 재무팀의 레이더에 잡히는 구조라면, 그것은 자동화의 성공이 아니라 거버넌스의 실패다.

지금 당신의 조직에서 AI 스케일링 도구가 실행한 지난 한 달간의 결정 로그를 재무팀이 볼 수 있는가? 이 질문에 "예"라고 답할 수 있는 조직이 얼마나 될지, 솔직히 낙관하기 어렵다.