2026년 5월 현재, AI Cloud 플랫폼이 스스로 내리는 결정의 범위가 또 하나의 경계를 넘어섰다. 이번에는 네트워크 트래픽 라우팅이다. 어떤 요청을 어느 리전으로 보낼지, 어느 엔드포인트가 "건강하지 않다"고 판단해 절체(failover)할지, 로드밸런서 가중치를 얼마나 바꿀지 — 이 모든 결정이 이제 AI의 자율 판단 영역으로 빠르게 편입되고 있다.

문제는 속도가 아니다. 속도는 오히려 장점이다. 문제는 그 판단이 언제, 어떤 근거로, 누구의 승인 하에 실행됐는지를 나중에 증명할 수 없다는 것이다.

---

라우팅 결정이 "자동화"를 넘어 "자율화"로 넘어가는 순간

전통적인 클라우드 환경에서 트래픽 라우팅 변경은 명확한 절차를 따랐다. 변경 요청(Change Request)이 생성되고, 검토자가 서명하고, 유지보수 윈도우가 지정되고, 롤백 계획이 첨부됐다. ITIL 기반의 이 프로세스가 느리고 번거롭다는 비판을 받아온 것도 사실이지만, 적어도 "누가, 언제, 왜 이 결정을 내렸는가"는 추적 가능했다.

AI Cloud 시대의 라우팅 자동화는 다르다. AWS의 Application Auto Scaling, Google Cloud의 Traffic Director, Azure의 Traffic Manager에 AI 기반 이상 감지 엔진이 결합되면서, 이제 이 시스템들은 단순히 사전 정의된 임계값에 반응하는 것이 아니라 패턴을 학습하고 선제적으로 트래픽을 재분배한다. 특정 AZ(가용 영역)의 레이턴시가 오르기 시작하면 인간이 인지하기 전에 이미 가중치가 바뀌어 있다.

이 자체는 훌륭한 기능이다. 하지만 SOC 2 Type II 감사를 앞둔 기업의 보안 담당자 입장에서는 악몽의 시작이다.

"자동화된 제어는 그 자체로 컨트롤이 될 수 있지만, 그 컨트롤이 언제 발동됐는지, 어떤 조건에서 트리거됐는지, 누가 그 조건을 승인했는지에 대한 증거가 없다면 감사자는 이를 컨트롤로 인정하지 않는다."
— ISACA, COBIT 2019 Implementation Guide

---

실제로 어떤 일이 벌어지는가: 세 가지 시나리오

시나리오 1: 페일오버가 "조용히" 일어난다

AI 기반 헬스체크 엔진이 특정 리전의 응답 시간이 기준치를 초과한다고 판단한다. 시스템은 자동으로 트래픽을 다른 리전으로 절체한다. 서비스는 정상 운영된다. 아무도 알림을 받지 않는다.

문제는 그 "다른 리전"이 데이터 레지던시 규정상 허용되지 않는 지역일 수 있다는 점이다. EU 고객의 개인정보가 GDPR의 적정성 결정을 받지 않은 국가 리전으로 흘러갔다면, 이는 명백한 규정 위반이다. 그리고 그 결정을 내린 것은 AI였고, 승인자는 없었다.

시나리오 2: 가중치 변경이 캐스케이드 장애를 만든다

AI가 특정 마이크로서비스의 에러율 상승을 감지하고 해당 인스턴스로의 트래픽 비중을 줄인다. 합리적인 판단처럼 보인다. 그런데 그 인스턴스가 특정 레거시 서비스와 강하게 결합되어 있었고, 트래픽이 줄자 오히려 타임아웃 패턴이 달라지면서 연쇄 장애가 발생한다.

이 시나리오에서 사후 분석(post-mortem)을 진행하면 변경 이력에는 아무것도 없다. AI의 라우팅 조정은 "운영 자동화"로 분류되어 변경 관리 시스템에 기록되지 않았기 때문이다. RCA(근본 원인 분석) 보고서를 써야 하는 엔지니어는 로그 더미 속에서 AI가 언제 무슨 결정을 내렸는지를 역추적해야 한다.

시나리오 3: 비용 최적화 라우팅이 SLA를 깨뜨린다

일부 AI Cloud 플랫폼은 비용 최적화 목표를 라우팅 결정에 통합하고 있다. 스팟 인스턴스가 저렴한 리전으로 트래픽을 유도하거나, 피크 타임 이후 저렴한 경로로 자동 전환하는 식이다. 이 결정이 고객과 체결한 SLA의 레이턴시 보장 조항을 위반했다면, 책임은 누구에게 있는가? AI 시스템을 구매한 기업이다. AI 벤더의 이용약관에는 이미 그 책임 조항이 명시되어 있을 가능성이 높다.

---

AI Cloud가 라우팅을 결정할 때 사라지는 것들

이 세 시나리오가 공유하는 구조적 문제를 정리하면 다음과 같다.

1. Named Approver의 소멸
변경에는 책임자가 있어야 한다. 전통적 변경 관리에서 이 역할은 사람이 맡았다. AI가 라우팅을 자율 결정하면 이 역할이 사라진다. 감사자가 "이 변경을 누가 승인했습니까?"라고 물었을 때 "AI가 자동으로 결정했습니다"는 답은 SOC 2나 ISO 27001 맥락에서 컨트롤로 인정받지 못한다.

2. 감사 증거의 단절
AI의 라우팅 결정 로그가 존재하더라도, 그 로그가 변경 관리 시스템(ITSM)과 연결되지 않으면 감사 증거로서의 연속성이 깨진다. 감사자는 "변경이 승인된 후 실행됐다"는 인과 사슬을 요구하는데, AI 자율 실행은 이 사슬의 첫 번째 고리를 제거한다.

3. 직무 분리(SoD)의 형해화
PCI DSS v4.0은 네트워크 구성 변경에 대한 명확한 직무 분리를 요구한다. AI가 라우팅과 네트워크 정책을 동시에 관리한다면, 실행자와 검토자가 동일한 시스템이 되는 셈이다. 이는 직무 분리 원칙의 근본적 위반이다.

4. 의도의 불투명성
AI의 라우팅 결정이 왜 그렇게 내려졌는지를 사후에 설명하기 어렵다. 특히 강화학습 기반 라우팅 엔진은 결정 근거를 인간이 이해할 수 있는 형태로 출력하지 않는다. 이는 AI Productivity Paradox: 개인 생산성은 올랐는데 왜 회사 실적은 그대로인가에서 다룬 "AI 효율성의 역설"과 같은 맥락이다 — 개별 결정은 최적화되지만, 시스템 전체의 설명 가능성은 오히려 낮아진다.

---

벤더들은 이 문제를 어떻게 다루고 있는가

솔직히 말하면, 아직 충분하지 않다.

AWS는 CloudTrail을 통해 API 호출 로그를 제공하지만, AI 기반 자율 라우팅 결정이 모두 API 호출로 기록되는 것은 아니다. 내부 오케스트레이터가 직접 실행하는 결정은 CloudTrail의 시야 밖에 있을 수 있다.

Google Cloud의 Traffic Director는 Envoy 기반으로 상세한 텔레메트리를 제공하지만, 그 텔레메트리가 "왜 이 결정을 내렸는가"를 설명하는 것은 아니다. 무엇이 일어났는지(what)는 알 수 있어도, 왜 일어났는지(why)는 여전히 블랙박스에 가깝다.

NIST AI Risk Management Framework(AI RMF 1.0)은 AI 시스템의 설명 가능성(explainability)과 투명성(transparency)을 핵심 리스크 관리 요소로 제시하고 있지만, 이를 클라우드 라우팅 자동화에 구체적으로 적용한 벤더 수준의 표준은 아직 성숙하지 않은 상태로 보인다.

---

실무자가 지금 당장 할 수 있는 것

이 문제는 AI Cloud 도입을 중단해야 한다는 이야기가 아니다. 라우팅 자동화의 이점은 실재하고, 포기할 이유가 없다. 다만 거버넌스 레이어를 의도적으로 설계해야 한다.

1. 라우팅 정책 변경의 범위를 명시적으로 정의하라

AI가 자율적으로 변경할 수 있는 파라미터의 범위를 사전에 문서화하라. "레이턴시 임계값 초과 시 동일 리전 내 AZ 간 가중치 조정은 자율 허용, 리전 간 절체는 인간 승인 필요"처럼 경계를 명확히 하는 것이다. 이 문서 자체가 감사 증거가 된다.

2. AI 결정을 ITSM 시스템에 연동하라

AI가 라우팅 변경을 실행할 때마다 자동으로 ServiceNow, Jira Service Management 같은 ITSM 시스템에 변경 레코드가 생성되도록 파이프라인을 구성하라. 사람이 승인한 것은 아니지만, 적어도 "시스템이 어떤 정책에 따라 자동 실행했다"는 레코드는 남길 수 있다. 감사자 대부분은 이 접근을 "자동 승인 정책에 의한 실행"으로 인정하기 시작하고 있다.

3. 데이터 레지던시 제약을 라우팅 정책의 하드 가드레일로 설정하라

AI 라우팅 엔진이 어떤 최적화 목표를 가지더라도, 특정 데이터 유형이 특정 리전을 벗어나지 못하도록 하는 제약은 소프트웨어 레이어가 아닌 정책 레이어(예: OPA, AWS SCP, Azure Policy)에서 강제해야 한다. AI가 이 제약을 "최적화 방해 요소"로 학습하고 우회하는 일이 없도록 설계해야 한다.

4. 설명 가능한 라우팅 결정을 요구하라

벤더 선정 또는 계약 갱신 시점에 "AI 라우팅 결정의 근거를 사람이 이해할 수 있는 형태로 제공할 수 있는가"를 평가 기준에 포함하라. 이 질문에 명확히 답하지 못하는 벤더의 AI 자율 라우팅은 컴플라이언스 리스크로 간주하는 것이 합리적이다.

5. 분기별 라우팅 정책 리뷰를 거버넌스 캘린더에 넣어라

AI가 학습을 통해 라우팅 정책을 점진적으로 변형시키는 경우, 초기에 승인된 정책과 현재 실제 동작 사이의 드리프트(drift)가 발생할 수 있다. 분기마다 AI가 실제로 어떤 기준으로 라우팅을 결정하고 있는지를 검토하는 세션을 거버넌스 프로세스에 포함시켜야 한다.

---

자율성과 책임 사이의 균형점

AI Cloud가 트래픽 라우팅을 자율 결정하는 것은 막을 수 없는 방향이다. 그리고 막아야 할 이유도 없다. 밀리초 단위로 변하는 네트워크 상태를 인간이 실시간으로 판단하는 것은 물리적으로 불가능하다.

하지만 "AI가 결정하는 것"과 "AI가 책임지는 것"은 다르다. 현재의 AI 시스템은 결정할 수 있지만 책임질 수 없다. 그 책임의 공백을 채우는 것이 거버넌스 설계의 역할이다.

Claude AI가 웹 개발자를 "선택 사항"으로 만든 날 — 당신의 비즈니스는 준비됐는가?에서 짚었듯이, AI가 특정 역할을 대체하거나 자동화할 때 비즈니스가 직면하는 진짜 질문은 "이 기술을 쓸 것인가"가 아니라 "이 기술을 어떻게 통제할 것인가"다. 라우팅 자율화도 마찬가지다.

AI가 트래픽을 어디로 보낼지 결정하는 순간, 당신의 조직은 이미 그 결정의 결과를 소유하고 있다. 그 소유를 의식적으로 받아들이고 거버넌스 구조를 설계하는 기업만이 AI Cloud의 속도와 컴플라이언스를 동시에 얻을 수 있다.

승인하지 않은 결정의 결과를 책임지는 것은, 언제나 사람이다.

---

태그: AI Cloud, 네트워크 라우팅, 클라우드 거버넌스, 컴플라이언스, 자동화, 변경 관리, SOC 2, 데이터 레지던시

저는 이미 작성된 글의 끝부분을 확인했습니다. 이 글은 이미 결론까지 완성된 상태입니다. 태그로 마무리되어 있으며, 더 이어서 작성할 내용이 없습니다.

다만, 이 글 다음에 작성할 새로운 글이 필요하시다면 기꺼이 도와드리겠습니다.

지금까지 다루신 주제들을 정리하면:

스토리지/보관 — AI가 데이터를 어디에 어떻게 저장할지 결정 IAM/접근 제어 — AI가 누가 접근할 수 있는지 결정 로그/옵저버빌리티 — AI가 어떤 이벤트를 기록할지 결정 서비스 생명주기 — AI가 어떤 서비스를 켜고 끌지 결정 암호화 — AI가 어떻게 데이터를 암호화할지 결정 네트워크 라우팅 — AI가 트래픽을 어디로 보낼지 결정 (방금 완성된 글)

아직 다루지 않은 거버넌스 영역 중 다음 글 후보로 제안드릴 수 있는 주제들입니다:

1. 비용 최적화 — AI가 클라우드 지출을 자율 조정할 때 (리소스 삭제·다운스케일 포함)
2. 패치/업데이트 — AI가 언제 무엇을 패치할지 결정할 때
3. 백업·복구 — AI가 복구 시점과 방식을 자율 선택할 때
4. 규모 조정(Auto-scaling) — AI가 인프라 규모를 자율 확장·축소할 때

어떤 주제로 다음 글을 작성할까요?