클라우드 인프라를 운영하는 팀이라면 한 번쯤 이런 경험이 있을 것이다. 어느 날 아침 출근해보니 프로덕션 환경의 인스턴스 수가 전날 밤 대비 세 배로 늘어나 있고, 그 결정을 내린 주체는 사람이 아니라 AI 도구였다는 것을. 티켓도 없고, 승인도 없고, 알림도 없었다. 그냥 "정책 범위 내에서 최적화"가 일어난 것이다.

2026년 현재, 클라우드 자동 스케일링은 AI 도구의 가장 활발한 활동 무대가 됐다. 그리고 바로 그 지점에서 새로운 거버넌스 공백이 조용히 커지고 있다.

---

자동 스케일링은 어디서 AI 결정으로 바뀌었나

전통적인 오토스케일링은 단순했다. CPU가 80%를 넘으면 인스턴스를 추가하고, 30% 이하로 내려가면 줄인다. 규칙 기반이고, 예측 가능하며, 아키텍처팀이 설계한 임계값이 그대로 실행된다.

그런데 AWS Auto Scaling의 예측적 스케일링(Predictive Scaling), Google Cloud의 Autopilot, Azure의 KEDA(Kubernetes Event-Driven Autoscaling)에 ML 기반 예측 모델이 결합되면서 상황이 달라졌다. 이제 스케일링 결정은 단순한 임계값이 아니라 과거 트래픽 패턴, 외부 이벤트 신호, 비용 최적화 목표를 동시에 고려한 AI 추론의 결과다.

AWS 공식 문서에 따르면 예측적 스케일링은 "최대 2일 앞의 용량 수요를 예측하여 사전에 스케일 아웃"한다. 이 말을 뒤집으면, AI가 아직 발생하지 않은 미래 수요에 근거해 오늘의 인프라 규모를 결정한다는 뜻이다.

문제는 그 "예측"이 틀렸을 때 누가 책임지는가다.

---

"정책 범위 내 최적화"라는 말의 함정

AI 도구 벤더들이 자주 쓰는 표현이 있다. "정책 범위 내에서 자율적으로 최적화합니다." 듣기에는 안전하고 통제 가능한 것처럼 들린다. 하지만 실제로 이 "정책 범위"가 어디까지인지 명확하게 정의한 조직은 생각보다 드물다.

예를 들어보자. 어떤 기업이 클라우드 비용 최적화 AI 도구를 도입하면서 "월 클라우드 비용의 ±20% 범위에서 자율 조정 허용"이라는 정책을 설정했다. AI 도구는 이 정책을 충실히 따르며 스케일링을 조정한다. 그런데 이 과정에서:

• 특정 리전의 인스턴스 타입이 변경되어 레이턴시 SLA가 미묘하게 달라졌다
• 특정 시간대에 스케일 다운이 발생해 배치 작업이 큐에 쌓였다
• 예약 인스턴스 혼합 비율이 조정되어 약정 조건이 사실상 변경됐다

이 중 어느 것도 "정책 위반"이 아니다. 하지만 아키텍처팀, SLA 담당자, 구매팀 중 누구도 이 결정을 사전에 알지 못했다. 그리고 이 모든 변화의 공통점은 사람이 서명한 승인이 없다는 것이다.

---

AI 도구가 만드는 새로운 아키텍처 의사결정 구조

이 문제가 특히 까다로운 이유는, AI 도구의 스케일링 결정이 단순한 운영 결정이 아니라 아키텍처적 함의를 가지기 때문이다.

스케일링 결정은 다음과 같은 연쇄 효과를 만든다:

1. 네트워크 토폴로지 변화 인스턴스가 추가될 때 어느 가용 영역(AZ)에 배치되는지에 따라 내부 트래픽 패턴이 달라진다. AI가 비용 효율적인 AZ를 선택하면, 네트워크팀이 설계한 트래픽 분산 전략이 조용히 무력화될 수 있다.

2. 보안 정책 적용 범위 변화 새로 추가된 인스턴스가 기존 보안 그룹 정책을 자동 상속받는다고 가정하면, 그 가정이 항상 맞는지는 별도로 검증해야 한다. 특히 컨테이너 기반 환경에서는 AI가 새 노드를 스핀업할 때 해당 노드의 IAM 역할이나 네트워크 정책이 의도대로 적용됐는지 확인하는 사람이 없다.

3. 데이터 레지던시 위험 멀티 리전 환경에서 AI가 "비용 최적화"를 위해 워크로드를 다른 리전으로 이동시키면, 데이터 처리 위치가 바뀐다. GDPR이나 국내 개인정보보호법 관점에서 이것은 단순한 운영 변경이 아니라 컴플라이언스 이벤트다.

이 세 가지 모두 아키텍처팀이 사전에 검토해야 할 사안이지만, AI 도구의 스케일링 결정 속도는 인간의 검토 속도를 이미 넘어섰다.

---

실제로 어떤 일이 벌어지고 있나

가상의 시나리오가 아니다. 현장에서 들리는 이야기들을 종합하면 패턴이 보인다.

어떤 금융 서비스 기업은 AI 기반 클라우드 최적화 도구 도입 후 3개월 만에 내부 감사에서 "승인되지 않은 리전 간 데이터 처리"가 발견됐다고 한다. AI 도구가 비용 절감을 위해 특정 배치 작업을 더 저렴한 리전으로 라우팅했는데, 그 리전이 해당 데이터의 처리 허용 지역 목록에 없었다. 도구 입장에서는 "정책 위반 없음"이었지만, 컴플라이언스팀 입장에서는 명백한 위반이었다.

또 다른 사례로, 이커머스 플랫폼의 아키텍처팀은 AI 스케일링 도구가 블랙프라이데이 트래픽을 "예측"하여 사전에 대규모 스케일 아웃을 실행한 것을 발견했다. 문제는 그 예측이 과도하게 공격적이어서 실제 필요 용량의 4배를 사전 프로비저닝했고, 이로 인해 월 예산의 30%가 단 이틀 만에 소진됐다. AI 도구는 "정책 범위(±20%)" 내에서 행동했지만, 그 정책이 단기 스파이크를 제대로 다루지 못했다.

이 두 사례의 공통점은 AI 도구가 잘못 행동한 게 아니라는 것이다. AI 도구는 주어진 정책을 충실히 따랐다. 문제는 그 정책이 AI 도구의 의사결정 범위를 충분히 정의하지 못했다는 데 있다.

---

거버넌스 공백의 실체: 누가 이 결정의 주인인가

이 문제를 더 근본적으로 들여다보면, 조직 내 의사결정 소유권(ownership) 문제로 귀결된다.

전통적인 클라우드 거버넌스에서 스케일링 정책 변경은 아키텍처 리뷰 보드(ARB)나 최소한 시니어 엔지니어의 승인을 거쳤다. 하지만 AI 도구가 실시간으로 스케일링 결정을 내리는 환경에서는:

• ARB는 사후에 로그를 검토할 뿐이다
• 아키텍처팀은 AI의 결정을 역공학으로 이해하려 한다
• 보안팀은 변경 사항을 SIEM에서 발견하고 나서야 안다
• 구매팀은 청구서에서 이상 징후를 감지한다

이것은 이미 여러 글에서 다뤄온 AI 클라우드 거버넌스 위기의 연장선이다. AI 클라우드가 "누구에게 알릴지"를 스스로 결정하는 문제와 마찬가지로, 스케일링 결정의 자율화도 결국 책임 귀속의 불명확성으로 이어진다.

AI 도구가 잘못된 스케일링 결정을 내렸을 때 누가 책임을 지는가? 도구를 선택한 CTO? 정책을 설정한 클라우드 아키텍트? 도구를 판매한 벤더? 현재 대부분의 조직에서 이 질문에 명확하게 답할 수 있는 사람은 없다.

---

AI 도구 스케일링 거버넌스를 위한 실질적 접근법

그렇다면 어떻게 해야 하는가. 몇 가지 실질적인 접근법을 제안한다.

1. "정책 범위"를 다차원으로 재정의하라

현재 대부분의 AI 스케일링 정책은 단일 차원(비용, 또는 성능)으로만 정의된다. 이를 다음과 같이 다차원으로 확장해야 한다:

• 비용 차원: 월 예산 대비 허용 변동폭
• 지리 차원: 허용 리전 및 AZ 목록 (데이터 레지던시 포함)
• 인스턴스 타입 차원: 허용 인스턴스 패밀리 및 세대
• 시간 차원: 스케일링 결정이 허용되는 시간대 (예: 배치 작업 실행 중 스케일 다운 금지)
• 변화율 차원: 단위 시간당 최대 변화 허용폭

이 중 어느 하나라도 변경하려면 AI 도구가 아닌 사람의 승인이 필요하다는 규칙을 명시적으로 설정해야 한다.

2. "AI 결정 로그"를 독립적으로 관리하라

AI 도구의 스케일링 결정은 일반 운영 로그와 분리하여 별도의 감사 추적(audit trail)으로 관리해야 한다. 이 로그에는 다음이 포함돼야 한다:

• 결정 시점과 결정 내용
• 결정의 근거가 된 데이터 (어떤 예측 모델이 어떤 신호를 기반으로 했는지)
• 해당 결정이 어떤 정책 조항에 근거했는지
• 결정 이후 실제 결과와의 비교

이 로그는 ARB와 컴플라이언스팀이 주기적으로 검토해야 한다.

3. "인간 검토 트리거"를 명시적으로 설계하라

모든 스케일링 결정을 인간이 검토할 수는 없다. 하지만 특정 조건을 충족하면 반드시 인간 검토를 거치도록 설계할 수 있다:

• 예산 임계값의 X% 이상 변화
• 새로운 리전 또는 AZ 추가
• 인스턴스 타입 패밀리 변경
• 연속 N회 이상의 스케일 다운 (서비스 저하 가능성)
• 비즈니스 크리티컬 시간대(예: 월말 정산 기간) 중 대규모 변경

이 트리거들은 AI 도구의 자율성을 완전히 제거하는 게 아니라, 인간 판단이 필요한 경계를 명확히 하는 것이다.

4. 아키텍처 리뷰 보드에 "AI 결정 검토" 의제를 정례화하라

월 1회 또는 분기 1회, ARB 회의에 AI 도구의 주요 스케일링 결정을 정기적으로 검토하는 의제를 추가하라. 이것은 사후 감사가 아니라 학습과 정책 개선의 기회다. AI 도구가 내린 결정 중 인간이라면 다르게 결정했을 케이스를 식별하고, 그것을 정책 개선에 반영하는 피드백 루프를 만드는 것이다.

---

자율성과 통제 사이의 균형

AI 도구의 자율 스케일링을 전면 금지하자는 게 아니다. 그것은 클라우드 네이티브 환경의 핵심 장점을 스스로 포기하는 것이다. 실제로 AI 기반 예측 스케일링은 McKinsey의 분석에서도 클라우드 운영 효율화의 핵심 동인으로 꼽힌다.

문제는 자율성 자체가 아니라 자율성의 경계가 명확하지 않다는 것이다. AI 도구가 스스로 결정해도 되는 영역과 반드시 인간이 개입해야 하는 영역을 명확하게 구분하는 것, 그리고 그 구분을 기술적 정책뿐 아니라 조직적 책임 구조와 연결하는 것이 지금 가장 시급한 과제다.

기술은 우리가 설정한 경계 안에서만 우리를 도울 수 있다. 그 경계를 설정하는 것은 여전히 사람의 몫이다. AI 도구가 아무리 정교해져도, 그 결정의 맥락과 결과에 대한 책임은 기계가 질 수 없다. 그리고 그 책임의 귀속을 명확히 하는 것이야말로, AI 도구를 진정으로 신뢰할 수 있는 파트너로 만드는 첫걸음이다.

---

이 글은 현재 진행 중인 클라우드 거버넌스 시리즈의 일부입니다. AI가 클라우드 운영의 다양한 의사결정을 대체해가는 과정에서 발생하는 거버넌스 공백을 지속적으로 추적하고 있습니다.

태그: AI클라우드, 자동스케일링, 아키텍처거버넌스, ARB, 컴플라이언스

---

편집자 주: 이 글은 AI 기반 클라우드 자동 스케일링이 조직의 아키텍처 거버넌스 구조와 충돌하는 지점을 다룬 분석입니다. 위 본문에 이어지는 독자 질문 및 보충 분석입니다.

---

독자들이 가장 많이 물어본 것

이 글의 초고를 공유했을 때, 몇 가지 예상 가능한 반응이 돌아왔다. 그리고 그 반응들 자체가 이 문제의 핵심을 잘 보여준다.

"우리 회사는 이미 정책 문서에 AI 도구의 자율 범위를 명시해뒀는데요."

가장 많이 들은 말이다. 그런데 나는 항상 이렇게 되묻는다. 그 정책 문서가 마지막으로 업데이트된 게 언제입니까? 대부분의 경우, AI 도구의 기능은 분기마다 업데이트되지만 정책 문서는 1~2년 전 버전에 머물러 있다. 도구의 자율성이 정책의 상상력을 이미 추월한 상태인 것이다.

"스케일링 결정은 비즈니스 영향이 크지 않아서 괜찮지 않나요?"

이것은 가장 위험한 착각이다. 스케일링 결정이 비용 구조를 바꾸고, 리전 배치를 변경하고, 특정 인스턴스 패밀리로 워크로드를 이전시킬 때, 그것은 단순한 운영 최적화가 아니다. 데이터 레지던시 요건, SLA 계약, 심지어 보안 인증 범위까지 건드릴 수 있는 결정이다. "작은 스케일링"이 "큰 컴플라이언스 문제"로 이어지는 경로는 생각보다 짧다.

"그럼 결국 AI 도구를 쓰지 말라는 건가요?"

아니다. 이 질문이 나올 때마다 나는 안전벨트 비유를 쓴다. 안전벨트가 불편하다고 차에서 빼버리는 사람은 없다. 다만 안전벨트를 제대로 매는 방법을 배우는 것이다. AI 도구의 자율성을 제거하는 게 아니라, 그 자율성이 작동하는 레일을 제대로 설계하자는 것이다.

---

한 가지 더: "정책 범위 내"라는 말의 함정

AI 도구 벤더들이 가장 자주 쓰는 표현이 있다. "정책 범위 내에서만 자율 실행됩니다." 이 말은 틀리지 않는다. 하지만 절반의 진실이다.

문제는 그 "정책"이 누가, 언제, 어떤 맥락에서 설정했느냐다. 많은 조직에서 AI 도구의 초기 정책 설정은 클라우드 엔지니어 한두 명이 온보딩 과정에서 체크박스를 클릭하는 수준으로 이뤄진다. ARB의 검토도, 법무의 확인도, CFO의 승인도 없이. 그리고 그 정책은 이후 수개월, 수년간 사실상 방치된다.

AI 도구는 충실하게 그 정책을 따른다. 문제는 그 정책 자체가 처음부터 조직의 공식 의사결정 구조를 통과한 적이 없다는 것이다. "정책 범위 내"라는 말이 거버넌스의 면죄부가 되어서는 안 된다.

2026년 현재, 국내 주요 클라우드 사용 기업 중 AI 스케일링 정책을 ARB 또는 이에 준하는 공식 검토 절차를 거쳐 수립한 곳이 얼마나 될까. 내가 지난 몇 달간 대화를 나눈 엔지니어와 아키텍트들의 답은 대체로 솔직했다. "아마 많지 않을 겁니다."

---

결론: 다음 감사에서 당신은 무엇을 보여줄 수 있는가

클라우드 거버넌스의 진짜 시험대는 일상이 아니라 감사(audit)다. 내부 감사든, 외부 인증 심사든, 규제 기관의 조사든 — 그 순간에 당신이 보여줄 수 있는 것이 거버넌스의 실체다.

AI 도구가 지난 6개월간 내린 스케일링 결정 목록을 지금 당장 뽑을 수 있는가? 그 결정들이 어떤 정책 조항에 근거했는지 설명할 수 있는가? 그 정책이 누구의 승인을 받았고, 마지막으로 검토된 것이 언제인지 답할 수 있는가?

이 세 가지 질문에 자신 있게 답할 수 없다면, AI 도구는 이미 당신의 거버넌스 구조 위에서 작동하고 있는 게 아니라 그 구조를 우회하며 작동하고 있는 것이다.

자율 스케일링은 클라우드 운영의 미래다. 하지만 그 미래는 거버넌스 없이는 지속 가능하지 않다. AI 도구가 더 정교해질수록, 그것을 둘러싼 인간의 책임 구조도 함께 정교해져야 한다. 도구의 진화 속도에 거버넌스의 진화 속도가 따라가지 못할 때, 우리는 효율을 얻는 동시에 통제를 잃는다.

그리고 통제를 잃은 효율은, 결국 어느 시점에 청구서로 돌아온다. 비용 청구서가 아니라 — 책임 청구서로.

---

다음 글에서는 AI 기반 클라우드 자동화가 보안 정책 집행 영역으로 확장되면서 발생하는 거버넌스 공백을 다룰 예정입니다. CSPM(Cloud Security Posture Management) 도구가 자율적으로 보안 정책을 적용하고 워크로드를 격리할 때, CISO는 그 결정의 루프 안에 있는가 — 라는 질문에서 시작합니다.