AI 클라우드, 이제 "누가 이 데이터에 접근할 수 있는지"도 스스로 결정한다 — IAM 자동화가 무너뜨리는 최후의 보루

클라우드 보안의 세계에서 오랫동안 신성불가침의 원칙이 하나 있었다. "접근 권한은 반드시 사람이 승인한다." 제로 트러스트(Zero Trust)든, 최소 권한 원칙(Principle of Least Privilege)이든, 모든 보안 프레임워크의 근저에는 이 전제가 깔려 있다. 그런데 지금 AI 클라우드 도구들이 바로 그 전제를 조용히, 그러나 체계적으로 해체하고 있다.

2025년 말부터 2026년 현재까지, AWS IAM Access Analyzer, Google Cloud의 Policy Intelligence, Azure의 Entra ID Governance 같은 도구들은 단순한 '접근 이상 탐지'를 넘어, 권한 부여·축소·폐기를 AI가 자율적으로 실행하는 단계로 진입했다. 권고가 아니라 실행이다. 그리고 그 실행에 "누가 승인했는가"라는 흔적은 점점 희미해지고 있다.

AI 클라우드가 IAM을 장악하는 방식

IAM(Identity and Access Management)은 클라우드 인프라의 가장 민감한 레이어다. 누가 어떤 리소스에 접근할 수 있는지를 정의하는 이 계층은, 잘못되면 데이터 유출이나 내부자 위협으로 직결된다.

전통적인 IAM 운영 모델은 단순했다. 누군가 접근 권한을 요청하면, 관리자가 검토하고, 승인하거나 거부한다. 변경이 발생하면 변경 티켓이 생성되고, 감사 로그에 '승인자'가 기록된다. 이 흐름이 SOC 2, ISO 27001, HIPAA, GDPR 같은 규제 프레임워크의 핵심 증거 체계다.

그런데 AI 기반 IAM 자동화는 이 흐름을 다음과 같이 바꿔버린다.

탐지: AI가 90일간 사용되지 않은 권한을 식별한다.
분석: 해당 권한이 현재 워크로드 패턴에 불필요하다고 판단한다.
실행: 권한을 자동으로 축소하거나 폐기한다.
기록: "AI 정책 최적화에 의해 변경됨"이라는 로그가 남는다.

3번과 4번 사이에 사람이 없다. 승인자가 없다. 비즈니스 맥락을 이해한 인간의 판단이 없다.

"90일 미사용"이 전부가 아닌 이유

AI가 권한을 판단할 때 주로 사용하는 기준은 사용 이력(usage history)이다. 90일, 혹은 180일간 특정 API를 호출하지 않았다면, 그 권한은 "불필요"로 분류된다. 논리적으로 들린다.

그러나 현실의 클라우드 환경은 이 논리보다 훨씬 복잡하다.

DR(재해복구) 권한: 평소에는 절대 사용하지 않는다. 재해가 발생했을 때만 필요하다. AI는 이 권한을 "미사용"으로 분류하고 폐기할 가능성이 있다. 정작 재해가 발생했을 때 복구 팀은 접근 권한이 없다는 사실을 알게 된다.
감사 전용 계정: 연간 또는 반기 감사 때만 활성화된다. 나머지 기간에는 완전히 유휴 상태다. AI가 이를 폐기하면, 다음 감사 때 감사인은 시스템에 접근할 수 없다.
규제 대응 계정: 특정 규제 기관의 요청이 있을 때만 사용된다. 요청이 없는 기간에는 사용 이력이 전혀 없다.

이런 맥락은 사용 패턴 데이터에 담기지 않는다. 오직 그 권한이 왜 존재하는지를 아는 사람만이 판단할 수 있다. AI는 그 '왜'를 모른다.

규제가 요구하는 것과 AI가 남기는 것의 간극

GDPR 제5조는 개인정보 처리에 대한 책임성(accountability)을 명시한다. SOC 2의 CC6.1은 "논리적 접근 제어가 승인된 프로세스에 따라 관리됨"을 요구한다. HIPAA의 164.312(a)(2)(i)는 "고유 사용자 식별 및 접근 승인"을 규정한다.

이 모든 규제의 공통 전제는 하나다. 접근 권한의 변경에는 책임 있는 인간의 승인이 있어야 한다.

그런데 AI 자동화가 IAM을 운영하면, 감사인이 "이 권한은 왜 폐기되었습니까?"라고 물었을 때 돌아오는 답은 이것이다.

"AI 정책 최적화 엔진이 사용 패턴을 분석하여 자동으로 처리하였습니다."

이것은 감사 증거가 아니다. 감사인이 원하는 것은 "누가, 언제, 어떤 비즈니스 근거로 승인했는가"다. 알고리즘의 결정 로그는 그 질문에 답하지 못한다.

NIST의 SP 800-207 제로 트러스트 아키텍처 가이드라인은 접근 결정의 지속적 검증을 강조하지만, 동시에 정책 관리자(Policy Administrator)의 역할을 인간 책임 구조 안에 명시적으로 위치시킨다. AI가 그 역할을 대체할 때, 이 구조는 무너진다.

AI 클라우드 IAM 자동화가 만드는 새로운 공격 표면

거버넌스 문제만이 아니다. AI 기반 IAM 자동화는 새로운 보안 취약점을 만들어낼 가능성도 있다.

공격자가 AI의 권한 판단 로직을 이해한다면, 이를 역이용할 수 있다. 예를 들어, 특정 권한이 AI에 의해 폐기되도록 유도하기 위해 해당 계정의 사용 패턴을 의도적으로 조작하는 것이다. 합법적인 접근 권한을 가진 계정을 "미사용"으로 보이게 만들면, AI가 그 권한을 폐기한다. 이는 내부 시스템에 대한 일종의 서비스 거부(DoS) 공격이 될 수 있다.

반대 방향도 가능하다. AI가 "필요하다"고 판단하도록 사용 패턴을 조작하여, 과도한 권한이 자동으로 부여되도록 유도하는 것이다. 이 경우 공격자는 명시적인 승인 없이 권한 상승(privilege escalation)을 달성할 수 있다.

이 취약점은 IAM 자동화 도구 자체의 버그가 아니다. AI가 판단의 주체가 되는 구조 자체에서 발생하는 설계적 취약점이다.

현장에서 벌어지는 일: 자동화의 속도와 검토의 속도

실제 엔터프라이즈 클라우드 환경에서 IAM 정책 변경이 얼마나 자주 발생하는지 생각해보자. 수백 개의 서비스 계정, 수천 개의 역할(role), 수만 개의 권한 항목이 있는 환경에서, AI 자동화 도구는 하루에도 수십, 수백 건의 변경을 실행할 수 있다.

인간 검토팀이 이 속도를 따라갈 수 없다는 것은 자명하다. 바로 그래서 자동화를 도입했으니까. 그런데 이 속도의 비대칭이 문제다.

AI가 권한을 폐기하는 속도: 밀리초
인간이 그 폐기가 잘못됐음을 인지하는 속도: 해당 권한이 필요한 순간이 올 때까지 알 수 없음
복구에 걸리는 시간: 케이스에 따라 수 시간에서 수 일

더 심각한 것은, 자동화된 IAM 변경이 다른 자동화 시스템들과 연쇄 반응을 일으킬 수 있다는 점이다. 이전 글에서도 다뤘듯이, AI 클라우드가 운영 전반의 의사결정을 자율화하는 과정에서 IAM 변경은 네트워크 접근 정책, 데이터 암호화 키 접근, 복구 절차 실행 권한 등 여러 도메인에 동시에 영향을 미친다.

하나의 자동화 결정이 연쇄적으로 다른 자동화 결정을 촉발하고, 그 결과 시스템 전체가 예측 불가능한 상태로 수렴할 수 있다.

"AI가 결정했다"는 말이 법정에서 통할까

2026년 현재, 이 질문이 실제로 제기되기 시작했다. 유럽의 DORA(디지털 운영 회복력법)는 금융 기관의 ICT 리스크 관리에서 "의사결정 과정의 문서화"를 명시적으로 요구한다. EU AI Act는 고위험 AI 시스템에 대해 인간 감독(human oversight)을 법적 의무로 규정한다.

IAM 자동화가 "고위험 AI 시스템"에 해당하는지에 대한 법적 해석은 아직 진행 중이다. 그러나 IAM 결정이 개인정보 접근, 금융 데이터 처리, 의료 기록 접근과 직결된다는 점에서, 규제 당국이 이를 고위험 범주로 분류할 가능성은 상당히 높아 보인다.

만약 그렇게 된다면, AI가 자율적으로 실행한 IAM 변경은 EU AI Act 위반이 된다. 그리고 그 책임은 도구를 만든 클라우드 벤더가 아니라, 그 도구를 기본 설정으로 활성화한 기업이 질 가능성이 크다.

지금 당장 할 수 있는 것들

이 문제는 AI 자동화를 포기하자는 이야기가 아니다. 자동화는 필요하고, 효율적이며, 인간이 처리할 수 없는 규모의 문제를 해결한다. 핵심은 자동화의 범위와 인간 감독의 경계를 명확히 설계하는 것이다.

1. 권한을 분류하라: 자동화 가능 vs. 인간 승인 필수

모든 IAM 변경이 동일한 위험 수준을 가지지 않는다. 다음과 같은 분류 체계를 구축할 것을 권장한다.

자동화 가능: 완전히 미사용된 임시 자격증명 폐기, 만료된 세션 토큰 정리
AI 추천 + 인간 승인: 서비스 계정 권한 축소, 역할 정책 변경
인간 승인 필수: DR 계정, 감사 계정, 규제 대응 계정의 모든 변경

2. "비즈니스 컨텍스트 태그"를 IAM 리소스에 붙여라

AWS의 경우 IAM 역할에 태그를 붙일 수 있다. purpose: disaster-recovery, review-cycle: annual, auto-remediation: disabled 같은 태그를 통해 AI 자동화 도구가 특정 권한을 건드리지 못하도록 정책을 설계할 수 있다.

3. 변경 전 알림 파이프라인을 구축하라

AI가 IAM 변경을 실행하기 전에 슬랙(Slack)이나 이메일로 알림을 보내고, 일정 시간(예: 24시간) 내에 이의가 없으면 실행되는 구조를 만들어라. 이것이 완전한 인간 승인은 아니지만, 최소한의 검토 기회를 제공한다.

4. AI 결정 로그를 감사 가능한 형식으로 보존하라

"AI 자동화에 의해 변경됨"이라는 로그는 감사 증거가 되지 않는다. AI가 어떤 데이터를 근거로, 어떤 정책 규칙에 따라, 어떤 대안을 검토한 후 결정했는지를 구조화된 형식으로 기록해야 한다. 이는 단순한 기술 로그가 아니라, 감사인이 읽을 수 있는 의사결정 근거 문서여야 한다.

신뢰의 문제

기술적 해결책보다 더 근본적인 것이 있다. IAM은 신뢰의 문제다. 누가 이 시스템을 신뢰할 수 있는 사람인가, 그 신뢰는 어떻게 부여되고 검증되는가. 이 질문은 본질적으로 인간의 판단과 책임을 요구한다.

네트워크 디지털 트윈이 인프라 경제학을 바꾸는 방식을 보면, 복잡한 인프라 결정에서도 인간의 맥락 이해가 얼마나 중요한지 알 수 있다. IAM은 그보다 훨씬 더 민감하다. 접근 권한은 단순한 인프라 설정이 아니라, 조직의 신뢰 구조 그 자체이기 때문이다.

AI 클라우드 도구들이 IAM을 자율화하는 속도는 우리의 거버넌스 설계 속도보다 빠르다. 이 간극이 좁혀지지 않으면, 다음 대형 데이터 유출 사고의 사후 조사에서 누군가는 이런 말을 하게 될 것이다.

"AI가 그 권한을 폐기했습니다. 아니면 부여했습니다. 정확히 왜 그랬는지는 저도 모릅니다."

그 말이 규제 당국 앞에서 얼마나 설득력이 있을지, 지금부터 진지하게 생각해야 할 때다.

이 글은 2026년 5월 5일 기준으로 작성되었습니다. AI 기반 IAM 자동화 도구의 기능과 관련 규제 해석은 빠르게 변화하고 있으므로, 각 클라우드 벤더의 최신 문서와 규제 기관의 가이드라인을 병행하여 확인하시기 바랍니다.

그래서, 지금 당신의 조직은 어디에 있는가?

글을 마무리하기 전에, 독자들에게 한 가지 간단한 자가 진단을 권하고 싶다.

지금 당신의 클라우드 환경에서 다음 질문에 답할 수 있는가?

지난 30일간 IAM 역할이나 정책이 변경된 건수는?
그 중 인간이 명시적으로 승인한 건수는?
AI 자동화 도구가 단독으로 실행한 건수는?
그 AI 결정에 대해 "왜"를 설명할 수 있는 문서가 존재하는가?

이 네 가지 질문에 모두 자신 있게 답할 수 있다면, 당신의 조직은 이미 상당히 성숙한 IAM 거버넌스를 갖추고 있는 것이다. 축하한다. 하지만 솔직히 말하면, 내가 지난 몇 달간 국내외 클라우드 운영 팀들과 대화하면서 이 네 가지를 모두 답할 수 있었던 팀은 손에 꼽을 정도였다.

대부분의 팀은 첫 번째 질문에서 이미 막힌다.

규제는 이미 움직이고 있다

한 가지 더 짚고 넘어가야 할 것이 있다. 많은 기업들이 "규제가 아직 명확하지 않으니 일단 지켜보자"는 태도를 취하고 있다. 그러나 2026년 현재, 이 태도는 점점 더 위험해지고 있다.

유럽의 EU AI Act는 고위험 AI 시스템에 대한 인간 감독 요건을 명시하고 있으며, 접근 제어와 인증 관련 자동화는 이 범주에 포함될 가능성이 높다. 미국 NIST의 AI RMF(AI Risk Management Framework)는 자율 시스템의 책임 소재 추적 가능성을 핵심 요건으로 제시하고 있다. 국내에서도 개인정보보호위원회와 금융당국이 AI 기반 자동화 시스템의 의사결정 투명성에 대한 가이드라인을 강화하는 방향으로 움직이고 있다.

규제 당국이 묻는 질문은 단순하다.

"이 시스템이 이 결정을 내렸을 때, 책임 있는 인간이 그것을 알고 있었는가?"

AI가 IAM을 자율 관리하는 구조에서 이 질문에 "예"라고 답하기는 구조적으로 어렵다. 그리고 "모르겠습니다"는 규제 환경에서 면책의 근거가 되지 않는다. 오히려 관리 소홀의 증거가 된다.

마지막으로: AI에게 열쇠를 맡기기 전에

나는 AI 자동화를 반대하는 사람이 아니다. 오히려 잘 설계된 자동화는 인간의 실수를 줄이고, 보안 수준을 높이며, 운영 효율을 극적으로 개선할 수 있다고 믿는다. IAM 영역에서도 마찬가지다.

그러나 "자동화가 가능하다"는 것과 "자동화해야 한다"는 것은 다른 이야기다. 특히 IAM처럼 조직 전체의 신뢰 구조와 직결된 영역에서는, 자동화의 편의성이 거버넌스의 공백을 정당화하는 이유가 될 수 없다.

집 열쇠를 스마트 잠금장치에 맡기는 것과, 그 잠금장치가 스스로 판단해서 특정 사람의 출입 권한을 추가하거나 삭제하도록 내버려두는 것은 전혀 다른 문제다. 전자는 편리함이고, 후자는 통제권의 포기다.

AI 클라우드 도구들은 지금 조용히, 그러나 빠르게 후자의 방향으로 이동하고 있다. 그 열쇠가 당신의 것인지, AI의 것인지를 지금 확인하지 않으면, 나중에는 확인할 기회조차 없을 수 있다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 그러나 도구가 도구로 남으려면, 그것을 쥔 손이 인간의 손이어야 한다. IAM 거버넌스에서 그 손을 놓지 않는 것, 그것이 지금 우리에게 필요한 가장 중요한 기술적 결정이다.

관련 글: [AI 클라우드, 이제 "규정 준수를 어떻게 할지"도 스스로 결정한다 — 그리고 감사인은 전화할 사람이 없다] | [AI 클라우드, 이제 "누가 이 시스템을 관리하는지"도 스스로 결정한다] | [AI Tools Are Now Deciding How Your Cloud Thinks — The Autonomous Decision Layer Nobody Audited]

Tags: AI 클라우드, IAM 거버넌스, 접근 제어 자동화, 클라우드 보안, 규제 컴플라이언스, 자율 의사결정

NOCODE TECH STACKER