클라우드 AI가 인프라를 자율적으로 조정하는 시대, 이제 그 자율성은 "누가 무엇에 접근할 수 있는가"라는 가장 민감한 영역까지 침범하기 시작했다. IAM(Identity and Access Management), 즉 신원 및 접근 관리는 오랫동안 보안 아키텍처의 핵심 축이었다. 그런데 AI 기반 클라우드 도구들이 이 영역에서도 조용히, 그러나 근본적으로 거버넌스의 전제를 흔들고 있다.

---

클라우드 AI가 "접근 권한"을 스스로 조정하기 시작했다

전통적인 IAM 모델은 단순하다. 누군가가 어떤 리소스에 접근하려면, 사전에 정의된 정책(Policy)이 있어야 하고, 그 정책은 명시적으로 승인된 변경 절차를 통해 만들어진다. 보안 팀이 검토하고, 담당자가 서명하고, 변경 티켓이 남는다. SOC 2, ISO 27001, GDPR이 요구하는 "최소 권한 원칙(Principle of Least Privilege)"과 "접근 통제 감사 추적"은 이 구조 위에 세워진 규범이다.

그런데 2025년 전후로 주요 클라우드 벤더들이 내놓은 AI 기반 IAM 도구들은 이 구조를 조용히 우회하기 시작했다. AWS IAM Access Analyzer의 ML 기반 정책 추천, Google Cloud의 Recommender API를 통한 권한 축소 자동화, Microsoft Entra ID의 AI 기반 조건부 접근(Conditional Access) 동적 정책 — 이 도구들은 처음에는 "추천"으로 시작했지만, 점점 "자동 적용(auto-remediation)"으로 진화하고 있다.

문제는 그 경계가 어디인지 명확하지 않다는 점이다.

---

"추천"에서 "실행"으로 — 그 한 걸음이 거버넌스를 무너뜨린다

AWS의 공식 문서에 따르면, IAM Access Analyzer는 사용되지 않는 권한을 탐지하고 정책 축소를 "제안"한다. 그러나 이를 AWS Config 규칙, Lambda 자동화, 또는 Security Hub와 연동하면 이 "제안"은 자동 실행 루프로 전환된다. 실무에서는 이 연동이 점점 기본값(default)에 가깝게 설정되는 추세다.

Microsoft의 Entra ID는 한발 더 나아간다. 조건부 접근 정책에서 AI가 로그인 패턴, 디바이스 상태, 위치 정보를 실시간으로 분석해 접근 허용 여부를 동적으로 판단한다. 이 판단은 사전에 정의된 규칙의 "실행"처럼 보이지만, 실제로는 AI 모델의 리스크 스코어링이 최종 결정에 개입한다. 그 스코어링 로직은 불투명하고, 변경 티켓도 없으며, 특정 결정에 대해 "왜 이 사용자의 접근이 차단됐는가"를 사후에 설명하기 어렵다.

이것이 단순한 기술적 편의의 문제가 아닌 이유는, 감사(Audit)의 전제가 "결정이 기록된다"는 것이 아니라 "결정이 설명 가능하다"는 것이기 때문이다. 로그가 남아도, AI가 왜 그 판단을 내렸는지 설명할 수 없다면 그 로그는 규제 목적의 감사 증거로 기능하지 못할 가능성이 있다.

---

실제로 무슨 일이 벌어지고 있는가

몇 가지 구체적인 시나리오를 살펴보자.

시나리오 1: 과도한 권한 자동 회수 한 금융 서비스 기업이 AWS IAM Access Analyzer와 Config 자동화를 연동해 "90일 이상 미사용 권한 자동 회수" 정책을 적용했다. 어느 날 분기 말 감사를 위해 접근이 필요한 외부 감사인의 계정 권한이 자동으로 회수됐다. 변경 티켓도 없었고, 승인자도 없었다. 감사 일정은 지연됐고, 규제 기관에 제출해야 할 보고서도 늦어졌다. "AI가 최적화했다"는 설명은 규제 기관에게 납득 가능한 근거가 되지 않았다.

시나리오 2: 동적 조건부 접근과 차별 리스크 Microsoft Entra ID의 AI 기반 리스크 스코어링이 특정 지역이나 디바이스 유형에서 접속하는 사용자를 반복적으로 고위험으로 분류해 MFA를 강제하거나 접근을 차단한다면, 이는 GDPR의 자동화된 의사결정 조항(제22조)과 충돌할 수 있다. 특히 그 판단 근거를 사용자에게 설명할 수 없다면, 이는 단순한 보안 이슈가 아니라 법적 리스크다.

시나리오 3: 멀티클라우드 환경에서의 권한 드리프트 기업이 AWS, Azure, GCP를 동시에 사용하는 멀티클라우드 환경에서, 각 플랫폼의 AI IAM 도구가 각자의 로직으로 권한을 조정하면 전체 접근 통제 정책의 일관성이 무너진다. A 플랫폼에서는 허용된 접근이 B 플랫폼에서는 차단되고, 그 불일치를 설명할 단일한 감사 기록이 존재하지 않는다.

---

왜 이것이 기존 거버넌스 프레임워크와 충돌하는가

SOC 2의 CC6(논리적 접근 통제) 요건은 접근 권한의 부여, 변경, 회수가 승인된 절차에 따라 이루어져야 한다고 명시한다. ISO 27001의 A.9(접근 통제)는 접근 권한 관리에 대한 공식적인 절차와 기록을 요구한다. GDPR 제22조는 자동화된 의사결정이 개인에게 중대한 영향을 미칠 경우 설명 요구권을 보장한다.

이 모든 프레임워크의 공통 전제는 "사람이 승인하고, 그 승인이 기록되며, 사후에 설명 가능해야 한다"는 것이다. AI 기반 IAM 자동화는 이 세 가지 전제를 동시에 흔든다.

• 승인: AI가 실행하므로 명시적 인간 승인이 없다
• 기록: 로그는 남지만 "왜 이 결정을 내렸는가"에 대한 설명 가능한 기록이 없다
• 설명 가능성: 모델의 리스크 스코어링 로직은 블랙박스에 가깝다

fal.ai가 AI 추론 속도 경쟁의 새로운 기준을 세운 방식을 분석한 바 있는데, 추론 속도가 빨라질수록 AI의 자율적 판단 속도도 빨라진다는 역설이 여기서도 적용된다. 결정이 빠를수록 인간이 개입할 여지는 줄어든다.

---

클라우드 AI 시대, IAM 거버넌스를 어떻게 재설계해야 하는가

이 문제는 AI 도구를 사용하지 말라는 결론으로 이어지지 않는다. 오히려 반대다. AI 기반 IAM은 인간이 처리할 수 없는 속도와 규모로 이상 접근을 탐지하고 대응하는 데 실질적인 가치가 있다. 문제는 그 가치를 취하면서도 거버넌스의 핵심 전제를 유지하는 설계가 필요하다는 것이다.

1. "자동 실행"과 "자동 추천"의 경계를 명시적으로 설계하라

모든 AI IAM 도구에는 두 가지 모드가 존재해야 한다. 하나는 AI가 판단하고 인간이 승인하는 "추천 모드", 다른 하나는 사전에 명시적으로 승인된 범위 내에서만 AI가 자율 실행하는 "제한적 자동화 모드"다. 이 경계를 설계 단계에서 명확히 정의하지 않으면, 운영 편의를 위해 경계는 점점 흐려진다.

실무적으로는 AWS Config의 자동 교정(Auto-remediation) 범위를 정책 문서로 명시하고, 해당 문서를 변경 관리 절차에 포함시키는 방식이 현실적이다. "AI가 자동으로 처리할 수 있는 권한 변경의 범위"를 사전에 인간이 승인한 문서로 남기는 것이다.

2. AI 결정에 대한 "설명 가능한 감사 로그"를 별도로 설계하라

일반적인 클라우드 로그(CloudTrail, Azure Monitor 등)는 "무엇이 변경됐는가"를 기록하지만, "왜 AI가 그 결정을 내렸는가"를 기록하지 않는다. 규제 감사를 위해서는 후자가 필수다.

이를 위해 AI 도구의 결정 시점에 해당 결정의 입력값(리스크 스코어, 탐지된 패턴, 적용된 정책 버전)을 별도의 감사 전용 스토리지에 기록하는 파이프라인을 구축해야 한다. 이는 추가적인 엔지니어링 비용이 들지만, 규제 위반 시 발생할 수 있는 비용과 비교하면 투자 가치가 분명하다.

3. "AI가 변경한 것"을 정기적으로 인간이 검토하는 루프를 만들어라

AI의 자율적 판단을 완전히 차단할 수 없다면, 최소한 그 판단을 주기적으로 인간이 검토하는 프로세스를 의무화해야 한다. 예를 들어, AI가 지난 30일간 자동으로 회수하거나 부여한 권한 목록을 매월 보안 팀이 검토하고, 이상이 없음을 확인하는 서명 절차를 거치는 방식이다.

이것은 사후 감사처럼 보이지만, 실제로는 "AI의 판단에 대한 인간의 주기적 승인"이라는 새로운 형태의 변경 관리다. 기존 변경 관리가 "사전 승인"이었다면, 이는 "사후 검증 및 승인"의 형태로 거버넌스를 재설계하는 것이다.

4. 멀티클라우드 환경에서는 단일 IAM 거버넌스 레이어를 구축하라

각 클라우드 벤더의 AI IAM 도구가 각자의 로직으로 작동하는 환경에서는, 이를 통합해서 관리하는 상위 레이어가 필요하다. Wiz, Prisma Cloud, Ermetic(현 Tenable Cloud Security)과 같은 CIEM(Cloud Infrastructure Entitlement Management) 도구들이 이 역할을 수행할 수 있다. 다만 이 도구들 자체도 AI 자동화를 내포하고 있으므로, 동일한 거버넌스 원칙이 적용되어야 한다.

---

규제 기관은 이미 움직이고 있다

NIST의 AI Risk Management Framework(AI RMF) 1.0은 AI 시스템의 투명성, 설명 가능성, 책임 추적 가능성을 핵심 원칙으로 제시한다. 특히 보안 및 접근 통제 영역에서의 AI 자동화는 "고위험 AI 시스템"으로 분류될 가능성이 높으며, 이에 상응하는 거버넌스 요건이 적용될 수 있다.

유럽의 AI Act는 2026년부터 단계적으로 시행되며, 접근 통제와 같은 중요 인프라에 적용되는 AI 시스템을 고위험으로 분류하고 있다. 이는 EU 내에서 클라우드 서비스를 운영하는 기업들에게 직접적인 컴플라이언스 의무를 발생시킨다.

AI가 과학의 판을 바꾸는 방식을 논의할 때도 강조했듯이, AI의 자율성이 커질수록 그 자율성에 대한 책임 구조를 어떻게 설계하느냐가 기술 자체보다 더 중요한 문제가 되고 있다.

---

지금 당장 해야 할 세 가지 질문

이 글을 읽는 당신이 기업의 보안 담당자, CTO, 또는 클라우드 아키텍트라면, 오늘 당장 다음 세 가지를 확인해야 한다.

첫째, 현재 사용 중인 AI IAM 도구 중 "자동 실행" 모드로 설정된 것이 있는가? 있다면 그 범위가 명시적으로 문서화되어 있고, 해당 문서가 변경 관리 절차에 포함되어 있는가?

둘째, AI가 지난 90일간 자동으로 변경한 접근 권한 목록을 지금 당장 뽑아볼 수 있는가? 그 목록에 대해 "왜 이 변경이 이루어졌는가"를 설명할 수 있는 기록이 있는가?

셋째, 다음 SOC 2 또는 ISO 27001 감사에서 AI 기반 접근 통제 결정에 대한 질문을 받는다면, 지금 준비된 답변이 있는가?

이 세 가지 질문에 모두 자신 있게 답할 수 있다면, 당신의 조직은 클라우드 AI 시대의 IAM 거버넌스를 이미 진지하게 다루고 있는 것이다. 하나라도 대답하기 어렵다면, 그 불확실성이 바로 규제 리스크가 쌓이는 지점이다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 그러나 그 도구가 "누가 무엇을 할 수 있는가"를 스스로 결정하기 시작했을 때, 우리는 그 결정에 대한 책임을 도구에게 넘길 수 없다. 클라우드 AI의 자율성이 커질수록, 그 자율성을 둘러싼 인간의 거버넌스 설계는 더 정교해져야 한다. 그것이 기술이 진정으로 인간을 위한 도구로 남을 수 있는 조건이다.