클라우드 환경에서 AI 도구가 자율적으로 내리는 결정의 범위가 조용히, 그러나 빠르게 확장되고 있다. 비용 최적화, 배포 자동화, 컴플라이언스 재구성에 이어, 이제 AI 도구는 "누가 어떤 네트워크 리소스에 접근할 수 있는지"까지 스스로 판단하고 실행한다. 문제는 이 결정이 보안팀의 시야 밖에서 이루어진다는 점이다.

2026년 현재, 클라우드 네트워크 관리 영역에서 AI 자동화는 단순한 트래픽 분석이나 이상 탐지를 넘어섰다. 방화벽 규칙 수정, 보안 그룹 업데이트, VPC 피어링 설정 변경까지 "정책 범위 내 실행(execution within policy bounds)"이라는 이름 아래 자율적으로 처리되고 있다. 그리고 보안팀은 대개 사고가 터진 뒤에야 그 사실을 알게 된다.

---

왜 네트워크 거버넌스가 가장 위험한 사각지대인가

AI 기반 클라우드 자동화가 만들어내는 거버넌스 공백은 여러 영역에 걸쳐 있다. 그런데 네트워크 접근 제어 영역은 그중에서도 특히 위험한 이유가 있다.

하나의 잘못된 설정이 수많은 워크로드에 조용히 영향을 미친다.

패치 관리나 배포 자동화의 실수는 대개 즉각적인 오류 메시지나 서비스 중단으로 가시화된다. 반면 네트워크 설정 오류는 다르다. 잘못 열린 포트, 의도치 않게 확장된 보안 그룹, 실수로 허용된 인바운드 규칙은 수주, 수개월 동안 아무런 경보 없이 존재할 수 있다. 공격자에게 문이 열려 있어도 정상적인 트래픽처럼 보이기 때문이다.

AWS, Azure, GCP 같은 주요 클라우드 플랫폼의 네이티브 AI 운영 도구들, 그리고 그 위에 올라타는 서드파티 AIOps 솔루션들은 이미 네트워크 레이어에서 자율 실행 권한을 갖고 있다. "트래픽 패턴 최적화"나 "보안 정책 자동 강화"라는 이름으로 방화벽 규칙이 수정되고, 그 변경 이력은 자동화 로그 어딘가에 묻힌다.

---

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

구체적인 시나리오를 생각해보자. 한 핀테크 스타트업이 클라우드 비용 최적화와 보안 강화를 동시에 목표로 AI 기반 클라우드 관리 플랫폼을 도입했다고 가정하자. 초기 설정 단계에서 보안팀은 "내부 데이터베이스 서브넷은 외부 접근 차단"이라는 정책을 정의했다. 합리적인 정책이다.

몇 달 후, AI 도구는 특정 마이크로서비스들의 레이턴시 문제를 감지하고, 이를 해결하기 위해 서브넷 간 라우팅 규칙을 조정했다. 정책 문서 어디에도 "레이턴시 최적화를 위한 라우팅 변경 금지"라는 조항은 없었다. AI 입장에서는 정책 범위 내 합법적 실행이었다. 그러나 그 변경이 의도치 않게 내부 데이터베이스 서브넷으로의 접근 경로를 일부 열어버렸다.

이런 시나리오가 가상의 이야기만은 아니다. Verizon의 2025 Data Breach Investigations Report에 따르면, 클라우드 환경에서의 침해 사고 중 상당 비율이 잘못된 구성(misconfiguration)에서 비롯되며, 그 탐지까지 걸리는 시간은 평균 수개월에 달한다. 자동화 도구가 만들어낸 구성 변경은 수동 변경보다 추적이 더 어렵다는 점에서, AI 자율 실행이 이 숫자를 악화시킬 가능성이 있다.

---

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

이 시리즈에서 반복적으로 다뤄온 핵심 문제가 여기서도 등장한다. AI 도구들이 자율 실행의 정당성으로 내세우는 "정책 범위 내 실행"이라는 개념은, 실제로는 초기 설정 시점에 거버넌스가 완결된다는 가정을 내포한다.

하지만 네트워크 보안 정책의 맥락은 끊임없이 변한다.

• 새로운 규제가 생기면 데이터 레지던시 요건이 바뀐다
• 새로운 서비스가 배포되면 접근 제어 경계가 달라진다
• 인수합병이 발생하면 신뢰할 수 있는 네트워크의 정의 자체가 변한다
• 내부 직원의 역할이 바뀌면 접근 권한 기준도 달라져야 한다

AI 도구는 이 맥락 변화를 실시간으로 반영하지 못한다. 정책은 문서로 존재하지만, 그 정책이 작성된 당시의 맥락과 현재의 맥락 사이의 간극을 AI는 인식하지 못한다. 결과적으로 "정책 범위 내"라는 판단 자체가 이미 낡은 기준 위에 서 있는 경우가 많다.

더 심각한 문제는 감사 가능성(auditability)의 소멸이다. 인간이 방화벽 규칙을 변경할 때는 변경 요청서, 승인자, 변경 이유가 기록된다. AI가 변경할 때는 자동화 로그에 "policy_optimization_event: network_rule_updated"라는 한 줄이 남는다. 나중에 감사팀이나 보안팀이 "왜 이 규칙이 바뀌었나"를 추적하려 해도 의사결정 근거를 재구성하기가 극히 어렵다.

---

AI 도구가 네트워크를 건드리는 세 가지 주요 경로

현재 클라우드 환경에서 AI 도구가 네트워크 접근 제어에 개입하는 경로는 크게 세 가지로 나눌 수 있다.

1. AIOps 플랫폼의 자율 치유(Self-Healing) 기능

Dynatrace, Datadog, New Relic 등의 AIOps 플랫폼은 이상 탐지 후 자율 치유 액션을 실행하는 기능을 제공한다. 이 중 일부는 네트워크 레이어 설정 변경을 포함한다. 트래픽 이상이 감지되면 특정 IP 대역을 차단하거나, 특정 포트의 접근을 일시 제한하는 식이다. 이 결정이 정당한 트래픽을 차단할 수도 있고, 반대로 실제 공격 트래픽을 정상으로 오인할 수도 있다.

2. 클라우드 네이티브 보안 서비스의 자동 응답

AWS Security Hub, Azure Defender, Google Security Command Center는 모두 "자동 수정(auto-remediation)" 기능을 제공한다. 공개된 S3 버킷을 자동으로 비공개로 전환하거나, 과도하게 허용된 IAM 정책을 자동으로 축소하는 기능이 대표적이다. 문제는 이 자동 수정이 운영 중인 서비스의 의존성을 고려하지 않을 때 발생한다. 보안 강화 목적으로 변경된 설정이 연결된 서비스를 조용히 끊어버리는 경우가 실제로 보고되고 있다.

3. 인프라 코드(IaC) AI 어시스턴트의 자동 적용

Terraform, Pulumi 등의 IaC 도구에 통합된 AI 어시스턴트들은 보안 모범 사례를 기반으로 네트워크 설정을 자동으로 제안하고, 경우에 따라 CI/CD 파이프라인을 통해 자동 적용한다. 개발팀은 "AI가 보안을 강화해줬다"고 생각하지만, 그 변경이 프로덕션 네트워크 토폴로지에 어떤 영향을 미치는지 보안팀은 파이프라인 로그를 뒤지기 전까지 알 수 없다.

---

보안팀이 지금 당장 해야 할 것들

이 문제는 AI 도구를 쓰지 말자는 이야기가 아니다. AI 자동화가 가져오는 운영 효율성은 실질적이고 포기하기 어렵다. 문제는 자동화의 범위와 거버넌스 구조가 맞지 않는다는 것이다. 몇 가지 즉시 적용 가능한 접근법을 제안한다.

① 네트워크 변경에 대한 "자율 실행 금지 목록"을 명시적으로 정의하라

모든 AI 자동화 도구의 정책 설정에는 허용 범위만 정의하는 경향이 있다. 반대로 "이것만큼은 AI가 자율 실행해서는 안 된다"는 명시적 금지 목록을 만들어야 한다. 보안 그룹 규칙 변경, 방화벽 정책 수정, VPC 피어링 설정 변경은 최소한 인간 검토 단계를 거치도록 설계해야 한다.

② 네트워크 설정 변경에 대한 별도 감사 로그를 구성하라

자동화 플랫폼의 일반 로그에 네트워크 변경 이벤트가 묻히지 않도록, 네트워크 접근 제어 관련 변경만을 별도로 집계하는 감사 로그 스트림을 구성하라. AWS CloudTrail, Azure Monitor, GCP Audit Logs를 활용해 보안팀이 실시간으로 이 변경을 인지할 수 있어야 한다.

③ 정책 문서를 "살아있는 문서"로 관리하라

AI 도구의 정책 설정은 초기 한 번 작성하고 잊어버리는 문서가 아니다. 조직의 변화(신규 서비스 배포, 규제 변경, 인수합병)가 발생할 때마다 정책 맥락을 재검토하고 업데이트하는 프로세스를 만들어야 한다. 분기마다 정책 리뷰 세션을 보안팀, 인프라팀, 컴플라이언스팀이 함께 진행하는 것을 권장한다.

④ "폭발 반경(blast radius)"을 기준으로 자율 실행 권한을 등급화하라

하나의 결정이 영향을 미칠 수 있는 범위가 클수록, 인간 승인의 필요성이 높아진다. 단일 인스턴스의 설정 변경과 전체 VPC에 영향을 미치는 네트워크 정책 변경은 같은 수준의 자율 실행 권한을 가져서는 안 된다. 폭발 반경을 기준으로 한 자율 실행 권한 등급화 체계를 도입하라.

---

거버넌스 공백은 기술 문제가 아니라 설계 문제다

AI 클라우드 자동화가 만들어내는 거버넌스 공백을 단순히 "AI가 아직 완벽하지 않아서"라고 보는 시각은 문제의 본질을 놓친다. 이것은 기술의 한계가 아니라 설계의 선택이다.

AI 도구들은 자율 실행 범위를 넓히도록 설계되어 있다. 그것이 이 도구들의 가치 제안이기 때문이다. 문제는 그 설계 선택이 조직의 거버넌스 구조와 어떻게 맞물리는지를 도구를 도입하는 조직이 충분히 고민하지 않는다는 점이다.

AI가 비용을 최적화하고, 장애를 예측하고, 컴플라이언스를 유지하고, 배포를 자동화하고, 이제는 네트워크 접근까지 관리하는 세계에서, 보안팀과 인프라팀의 역할은 "직접 실행"에서 "설계와 감시"로 이동해야 한다. 이 전환을 의도적으로 설계하지 않으면, 팀은 AI가 만든 결정의 결과를 사후에 수습하는 역할로 전락한다.

AI 거버넌스와 사이버보안의 교차점에 대해 더 넓은 시각이 필요하다면, AI 사이버보안 시장의 패권 다툼이 어떤 구조로 전개되고 있는지를 분석한 글도 함께 읽어볼 만하다. 기술의 자율화가 가속될수록, 그 기술을 둘러싼 권력 구조와 책임 소재가 어디에 있는지를 이해하는 것이 점점 더 중요해진다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 그러나 그 도구가 "누가 무엇에 접근할 수 있는지"를 결정하기 시작했을 때, 우리는 도구를 설계한 사람이 아니라 도구에 의해 설계되는 상황에 놓이게 된다. 지금 필요한 것은 더 강력한 AI 도구가 아니라, 그 도구의 결정 범위를 의도적으로 설계하는 인간의 판단이다.