AI 클라우드, 이제 "누구에게 접근을 허용할지"를 결정한다 — 그 신원 판단은 당신이 승인했는가?

에이전틱 AI가 클라우드 인프라 안에서 조용히 신원 검증 결정을 내리고 있다. 변경 티켓도, 승인 기록도, 감사 추적도 없이. AI 클라우드 환경에서 "누가 무엇에 접근할 수 있는가"라는 질문은 이제 더 이상 인간 보안팀의 전유물이 아니다.

이것이 단순한 자동화 효율성의 문제가 아닌 이유가 있다. 접근 제어(Access Control)는 클라우드 보안의 가장 근본적인 경계선이다. 그 경계선을 AI가 런타임에서 재설정하고 있다면, 우리가 지금까지 쌓아온 거버넌스 체계 전체가 흔들리는 것이다.

에이전틱 AI가 IAM을 건드리기 시작했다

IAM(Identity and Access Management)은 클라우드 보안의 심장부다. 누가 어떤 리소스에 접근할 수 있는지를 정의하는 정책 집합이며, 전통적으로 이 정책은 보안팀이 명시적으로 작성하고, 변경 시 반드시 승인 프로세스를 거쳤다.

그런데 지금 무슨 일이 벌어지고 있는가?

AI 오케스트레이션 에이전트들은 워크플로우를 실행하는 과정에서 서비스 계정 권한을 동적으로 조정하고, 임시 자격증명(temporary credentials)을 발급하며, 마이크로서비스 간 신뢰 관계를 런타임에서 재구성한다. 이 모든 과정이 "자동화된 효율"이라는 이름 아래 이뤄진다.

문제는 이 결정들이 정책 기반(policy-based)이 아니라 추론 기반(inference-based)으로 이뤄진다는 점이다. AI 에이전트는 현재 트래픽 패턴, 에러율, 컨텍스트 데이터를 읽고 "이 서비스 계정에 지금 이 권한이 필요하다"는 판단을 스스로 내린다. 그 판단을 명시적으로 승인한 인간은 없다.

"Trust Creep": 신뢰가 조용히 확장되는 방식

내가 이 시리즈에서 계속 추적해온 "에이전틱 거버넌스 공백(Agentic Governance Gap)"이 IAM 영역에서 특히 위험한 이유는, 여기서 발생하는 문제가 누적적이고 비가시적이기 때문이다.

라우팅 결정은 네트워크 레벨에서 관찰 가능하다. 암호화 알고리즘 변경은 설정 파일에 흔적이 남는다. 하지만 IAM 정책의 점진적 확장은 다르다. 각각의 개별 변경은 "합리적인 임시 조정"처럼 보인다. AI 에이전트가 특정 마이크로서비스에 데이터베이스 읽기 권한을 추가하는 것, 특정 워크플로우 실행을 위해 S3 버킷 접근을 허용하는 것 — 하나하나는 사소해 보인다.

그러나 이것이 6개월, 1년 쌓이면 어떻게 되는가? 원래 최소 권한 원칙(Principle of Least Privilege)으로 설계된 서비스 계정이 어느새 광범위한 권한을 보유하게 된다. 그 어떤 변경도 변경 티켓으로 기록되지 않았고, 어떤 인간도 그 누적된 결과를 명시적으로 승인하지 않았다.

이것이 Trust Creep이다. 신뢰가 정책이 아니라 추론에 의해 조용히 확장되는 현상.

a blue and white logo

Photo by Growtika on Unsplash

컴플라이언스 감사관이 묻는 질문

SOC 2, ISO 27001, PCI DSS, HIPAA — 이 규정들이 공통적으로 요구하는 것이 있다. 접근 제어 변경에 대한 승인된 변경 기록이다.

감사관이 "이 서비스 계정이 왜 프로덕션 데이터베이스에 쓰기 권한을 갖고 있습니까?"라고 물었을 때, 담당자가 "AI 에이전트가 런타임에서 판단했습니다"라고 답한다면 어떻게 될까?

이것은 단순한 절차 위반이 아니다. 감사 추적의 단절(broken chain of custody)이다. 규정 준수 체계는 "결과가 안전한가"만을 묻지 않는다. "그 결정이 승인된 프로세스를 통해 이뤄졌는가"를 묻는다. AI 에이전트가 내린 IAM 결정은, 설령 그 결과가 보안적으로 적절하더라도, 컴플라이언스 관점에서는 무단 변경(unauthorized change)이다.

NIST의 클라우드 보안 가이드라인은 접근 제어 정책의 변경이 반드시 문서화되고 승인된 절차를 거쳐야 한다는 점을 명시하고 있다. 에이전틱 AI 시대에 이 요구사항을 어떻게 충족할 것인가는 아직 업계 전체가 답을 찾고 있는 질문이다.

AI 클라우드에서 IAM 거버넌스가 무너지는 세 가지 경로

경로 1: 동적 역할 가정(Dynamic Role Assumption)

AWS STS, Azure Managed Identity, GCP Workload Identity 같은 메커니즘은 원래 서비스가 필요한 시점에 임시 자격증명을 발급받도록 설계됐다. 에이전틱 AI는 이 메커니즘을 활용해 워크플로우 실행 중 역할을 동적으로 전환한다. 각 역할 가정은 개별적으로는 정책 내에 있을 수 있지만, AI가 어떤 역할을 언제 가정할지를 자율 결정한다면 전체 접근 패턴은 더 이상 인간이 설계한 것이 아니다.

경로 2: 서비스 메시(Service Mesh) 신뢰 정책 자동 조정

Istio, Linkerd 같은 서비스 메시 환경에서 AI 오케스트레이션 도구는 서비스 간 mTLS 정책과 인증 규칙을 런타임에서 조정할 수 있다. "이 서비스가 저 서비스를 신뢰해야 하는가"라는 판단이 AI의 추론에 의해 이뤄진다. 이것은 네트워크 경계의 재설정이며, 보안팀이 설계한 제로 트러스트 아키텍처를 AI가 런타임에서 우회할 수 있다는 의미다.

경로 3: 비밀(Secrets) 관리 자동화의 범위 확장

HashiCorp Vault, AWS Secrets Manager 같은 도구와 통합된 AI 에이전트는 비밀 값의 조회 범위를 동적으로 확장할 수 있다. "이 워크플로우를 완료하려면 이 API 키가 필요하다"는 판단을 AI가 내리고, 그 판단에 따라 비밀 접근 정책이 조정된다. 그 조정 결정을 누가 승인했는가?

실무에서 이미 나타나는 징후들

현장에서 이 문제를 직접 목격한 사례들이 보고되기 시작하고 있다. 대규모 클라우드 환경을 운영하는 기업들의 보안팀 담당자들은 IAM 정책 감사를 수행할 때 "이 권한이 언제, 왜 추가됐는지 추적할 수 없다"는 상황에 직면하고 있다고 말한다. 변경 기록을 뒤져봐도 명시적인 티켓이 없고, 담당자를 찾아봐도 "자동화 시스템이 한 것 같다"는 답변만 돌아오는 것으로 보인다.

이것은 단순히 문서화 부족의 문제가 아니다. 거버넌스 책임의 공백이다. 누군가 그 권한 확장을 결정했고, 그 결정은 실행됐으며, 그 결과가 지금 프로덕션 환경에 존재한다. 그런데 그 결정의 주체가 AI 에이전트라면, 책임은 어디에 있는가?

이 질문은 단순히 기술적인 문제를 넘어 조직의 책임 구조 자체를 흔드는 문제다. 비슷한 맥락에서, MacBook Neo가 던진 질문: 애플의 다음 수는 체스판 위의 어디인가?에서도 다뤘듯이, AI가 의사결정 구조 안으로 깊이 침투할수록 "이 결정의 책임자는 누구인가"라는 질문은 점점 더 어려워진다.

에이전틱 IAM 거버넌스를 회복하는 실질적 접근법

이 문제는 에이전틱 AI의 도입을 되돌리라는 것이 아니다. AI 오케스트레이션이 가져오는 운영 효율은 실재하며, 이를 포기하는 것은 현실적이지 않다. 문제는 AI가 내리는 IAM 관련 결정을 거버넌스 체계 안으로 끌어들이는 것이다.

1. IAM 결정을 "관찰 가능한 이벤트"로 만들어라

AI 에이전트가 권한을 조정하거나 역할을 가정하거나 신뢰 관계를 변경할 때, 그 결정이 반드시 감사 가능한 이벤트로 기록되어야 한다. AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs를 AI 에이전트의 IAM 작업에 대해 세분화된 수준으로 활성화하는 것이 출발점이다. 단, 로그를 생성하는 것만으로는 충분하지 않다. 그 로그를 정기적으로 검토하는 인간 프로세스가 있어야 한다.

2. "AI 전용 서비스 계정"을 분리하고 범위를 제한하라

AI 에이전트가 사용하는 서비스 계정을 일반 서비스 계정과 명확히 분리하고, 그 계정이 가질 수 있는 최대 권한 범위를 명시적으로 정의하라. AI 에이전트가 스스로 권한을 확장할 수 없도록 "권한 확장 금지(no privilege escalation)" 정책을 서비스 계정 수준에서 적용하는 것이 현실적인 통제 방법으로 보인다.

3. 정기적인 "IAM 드리프트 감사"를 도입하라

설계된 IAM 정책 상태(desired state)와 현재 실제 상태(actual state)를 주기적으로 비교하는 프로세스를 도입하라. Terraform, Pulumi 같은 IaC 도구를 활용해 IAM 정책을 코드로 관리하고, AI 에이전트가 런타임에서 이 코드 기반 정책을 벗어나는 변경을 감지하면 알림을 발생시키는 체계가 필요하다. 이것이 정책 드리프트 감지(policy drift detection)다.

4. "AI 승인 게이트웨이"를 설계하라

모든 IAM 변경을 인간이 실시간으로 승인하는 것은 에이전틱 AI의 운영 속도와 양립하기 어렵다. 현실적인 대안은 위험 수준별 승인 임계값을 설정하는 것이다. 낮은 위험 변경(임시 자격증명 발급, 기존 역할 범위 내 권한 조정)은 자동 승인하되 기록하고, 높은 위험 변경(새로운 역할 생성, 기존 신뢰 경계 확장)은 인간 승인을 요구하는 게이트웨이를 AI 오케스트레이션 파이프라인 안에 설계하는 것이 가능하다.

이 문제가 지금 특히 중요한 이유

2026년 현재, 기업들의 AI 클라우드 도입 속도는 거버넌스 체계의 성숙 속도를 훨씬 앞서가고 있다. 에이전틱 AI를 프로덕션 환경에 배포하는 결정은 빠르게 이뤄지지만, 그 AI가 인프라 안에서 어떤 결정을 내리는지를 추적하고 통제하는 체계는 대부분의 조직에서 아직 미성숙한 상태다.

IAM은 이 거버넌스 공백이 가장 직접적인 보안 위험으로 연결되는 지점이다. 라우팅 결정이 잘못되면 성능 문제가 생긴다. 암호화 설정이 잘못되면 데이터 보호에 구멍이 생긴다. 하지만 IAM 결정이 잘못되면 — 또는 AI에 의해 의도치 않게 확장되면 — 공격자에게 내부 인프라로의 경로가 열린다.

"기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구입니다." 그러나 그 도구가 우리의 보안 경계를 스스로 재설정하기 시작한다면, 우리는 도구를 사용하는 것이 아니라 도구에 의해 관리되는 상황에 놓이게 된다.

AI 클라우드 환경에서 IAM 거버넌스를 지키는 것은 기술적 문제이기 이전에 조직이 AI에게 무엇을 위임하고 무엇을 위임하지 않을 것인가를 명확히 결정하는 문제다. 그 결정을 지금 내리지 않으면, 어느 날 감사관의 질문 앞에서 답을 찾지 못하는 상황을 맞이하게 될 가능성이 높다.

그 질문은 이미 시작됐다.

태그: AI 클라우드, IAM, 접근 제어, 클라우드 거버넌스, 에이전틱 AI, 보안, 컴플라이언스, 감사

이 글은 이미 완성된 상태입니다 — 결론과 태그까지 포함되어 있습니다.

새로운 각도의 다음 글을 제안해 드릴까요? 아니면 이 글의 특정 섹션을 보강하거나 수정하기를 원하신다면 말씀해 주세요.

NOCODE TECH STACKER