IAM(Identity and Access Management), 즉 "누가 어떤 자원에 접근할 수 있는가"는 클라우드 보안의 가장 근본적인 질문이다. 그런데 지금 이 질문에 대한 답을 AI클라우드가 조용히 대신 내리고 있다. 권한 부여, 역할 추천, 정책 자동 최적화까지 — AI가 IAM의 핵심 판단을 자율적으로 수행하기 시작했고, 정작 IAM팀과 보안 담당자는 그 결정이 내려진 뒤에야 사실을 파악하는 구조가 일상이 되고 있다.

이 시리즈에서 나는 AI클라우드가 스스로 결정하는 영역들 — 어디에 데이터를 저장할지, 누구에게 알릴지, 언제 스케일을 올릴지, 어떤 벤더와 계약할지, 보안 정책을 어떻게 바꿀지 — 을 하나씩 짚어왔다. 오늘 다룰 IAM 자동화는 그 중에서도 가장 조용하고, 가장 위험한 영역이다. 왜냐하면 접근 권한은 모든 보안 사고의 출발점이기 때문이다.

---

AI가 IAM을 "관리"하는 게 아니라 "결정"하기 시작했다

전통적인 IAM 거버넌스는 단순했다. 누군가 새로운 권한이 필요하면 티켓을 열고, 승인자가 검토하고, IAM팀이 적용한다. 느리고 번거롭지만, 그 느림 속에 인간의 판단과 책임이 담겨 있었다.

AI클라우드 환경에서는 이 구조가 근본적으로 바뀌었다.

AWS IAM Access Analyzer, Google Cloud의 IAM Recommender, Microsoft Entra ID의 AI 기반 조건부 액세스 정책 엔진은 이제 단순한 "추천" 도구가 아니다. 이 도구들은 실제 사용 패턴을 분석해 "과도한 권한"을 탐지하고, 자동으로 최소 권한 원칙(Least Privilege)에 맞게 역할을 재조정하거나, 비활성 계정을 비활성화하고, 새로운 서비스 계정에 역할을 자동 배정한다.

기술적으로는 합리적이다. 실제로 대부분의 클라우드 환경에서 IAM 정책은 처음에 넓게 설정되고 이후 좁혀지는 법이 없다. AWS의 자체 보고에 따르면 클라우드 환경 내 권한의 상당 비율이 실제로 사용되지 않는 과잉 권한 상태다. AI가 이를 자동으로 정리해준다면 효율적으로 들린다.

문제는 "효율"과 "거버넌스"가 충돌하는 지점에서 시작된다.

---

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

시나리오 1: 자동화된 역할 축소가 프로덕션을 멈춘다

한 금융 서비스 기업의 사례를 생각해보자. AI 기반 IAM 최적화 도구가 특정 서비스 계정이 지난 90일간 S3 특정 버킷에 접근하지 않았다는 사실을 탐지했다. 도구는 "미사용 권한"으로 분류하고 해당 접근 권한을 자동 제거했다. 그 버킷은 분기 말 재무 보고 배치 작업에서만 접근하는 버킷이었다. 배치가 실행되는 날, 프로덕션 파이프라인이 멈췄다.

IAM팀이 원인을 파악하는 데 걸린 시간: 4시간. 그 사이 분기 보고 마감은 지연됐다.

시나리오 2: "조건부 액세스" 정책이 조용히 바뀐다

Microsoft Entra ID의 AI 기반 조건부 액세스 엔진은 로그인 패턴, 디바이스 상태, 위치 정보를 분석해 정책을 동적으로 조정할 수 있다. 특정 사용자 그룹의 접근이 "비정상적"으로 탐지되면 MFA 요구 수준을 높이거나, 특정 앱 접근을 일시 차단하는 결정을 자동으로 내린다.

이 자동화 자체는 보안적으로 유효하다. 그런데 이 결정이 CAB(변경자문위원회) 승인 없이 이루어진다면? 그리고 그 "비정상" 판단이 실제로는 해외 출장 중인 임원의 정상 로그인이었다면? 보안팀은 차단 사실을 알지만, 그 결정이 어떤 AI 모델의 어떤 가중치에 의해 내려졌는지 감사 로그에서 추적하기 어렵다.

시나리오 3: 자동 역할 추천이 컴플라이언스 경계를 넘는다

Google Cloud IAM Recommender는 주기적으로 "이 서비스 계정에 이 역할을 부여하면 효율적"이라는 추천을 생성하고, 일부 설정에서는 자동 적용이 가능하다. 문제는 이 추천이 데이터 레지던시 요건이나 직무 분리(Segregation of Duties) 원칙을 인식하지 못한 채 이루어질 수 있다는 점이다.

GDPR이나 금융감독원 규정상 특정 데이터에 접근 가능한 역할은 명시적 승인 절차를 거쳐야 한다. AI가 "효율적"이라고 판단해 자동 부여한 역할이 이 경계를 넘는다면, 그 사실은 외부 감사에서야 드러난다.

---

왜 이 문제가 다른 AI 자동화 문제보다 더 심각한가

AI클라우드가 스케일링을 자동으로 결정하면 비용 청구서에서 드러난다. 벤더를 자동으로 선택하면 계약서에서 드러난다. 그런데 IAM 결정은 다르다.

접근 권한의 변경은 조용하다. 권한이 잘못 부여되거나 잘못 제거되어도, 그 영향은 즉각적으로 나타나지 않을 수 있다. 잘못 부여된 권한은 내부자 위협이나 계정 탈취 시 폭발적 피해로 이어지고, 잘못 제거된 권한은 특정 배치 작업이나 비상 절차가 실행될 때야 드러난다.

더 심각한 것은 감사 가능성(Auditability)의 문제다. 전통적인 IAM 변경은 티켓 번호, 승인자, 변경 이유가 남는다. AI가 자동으로 내린 결정은 "IAM Recommender에 의해 자동 적용됨"이라는 한 줄 로그만 남는다. 왜 그 결정이 내려졌는지, 어떤 데이터를 기반으로 했는지, 그 결정을 누가 책임지는지는 로그에 없다.

AI 용어집이 경제 교과서가 된 시대: AGI와 AI 에이전트가 바꿀 노동시장의 진짜 문법에서도 다뤘듯, AI 에이전트가 자율적 판단을 내리는 영역이 넓어질수록 "누가 책임지는가"라는 질문은 점점 더 대답하기 어려워진다. IAM은 그 질문이 가장 날카롭게 꽂히는 영역이다.

---

AI클라우드 IAM 자동화의 거버넌스 공백, 어디서 생기는가

1. "정책 범위 내 실행"이라는 면죄부

AWS, Google Cloud, Microsoft Azure 모두 AI 기반 IAM 도구의 자동화 범위를 "관리자가 설정한 정책 내에서만 작동"한다고 설명한다. 기술적으로는 맞다. 그런데 그 "정책"은 대개 클라우드 엔지니어링팀이 초기 설정 시 정의한 파라미터다. 법무팀이 검토했는가? CISO가 승인했는가? 컴플라이언스팀이 데이터 레지던시 요건을 반영했는가? 대부분의 경우 그렇지 않다.

정책 범위 내 실행이라는 기술적 사실이, 거버넌스 승인을 대체하지는 않는다.

2. 자동화의 속도와 거버넌스 프로세스의 속도 불일치

IAM Recommender는 수백 개의 역할 변경 추천을 하루에 생성할 수 있다. 전통적인 CAB 프로세스는 주 1회 회의를 통해 변경을 검토한다. 이 속도 차이 자체가 거버넌스 공백을 만든다. 자동 적용이 켜져 있다면 CAB가 회의를 열기도 전에 수십 개의 권한 변경이 이미 완료된다.

3. "추천"과 "자동 적용"의 경계가 불분명하다

많은 조직이 AI IAM 도구를 "추천 모드"로 시작한다. 그러다 운영 부담을 줄이기 위해 "자동 적용"으로 전환하는 결정이 엔지니어링팀 레벨에서 이루어진다. 이 전환 결정 자체가 보안 정책 변경임에도, CISO나 컴플라이언스팀에 공식 보고되지 않는 경우가 많다.

AI취업 시대의 졸업장: 학위가 더 이상 입장권이 아닌 이유에서 다뤘던 것처럼, AI 도구의 확산은 조직 내 의사결정 구조 자체를 바꾼다. IAM 자동화는 그 변화가 가장 조용하고 위험하게 진행되는 사례다.

---

실질적으로 무엇을 해야 하는가

이 문제를 인식하는 것만으로는 충분하지 않다. 지금 당장 적용 가능한 거버넌스 프레임을 제안한다.

① AI IAM 결정의 "자동 적용" 범위를 명시적으로 정의하라

모든 AI 기반 IAM 도구에 대해, 자동 적용이 허용되는 변경의 범위를 문서화하라. 예를 들어:

• 자동 적용 허용: 90일 이상 미사용 권한 제거 (단, 배치 전용 계정 제외)
• 추천만 허용, 수동 승인 필수: 신규 역할 부여, 관리자급 권한 변경
• 자동화 금지: 컴플라이언스 데이터 접근 역할, 직무 분리 관련 정책

이 문서는 엔지니어링팀이 아닌 CISO와 컴플라이언스팀이 공동으로 승인해야 한다.

② AI IAM 변경 로그를 기존 감사 체계에 통합하라

AI가 내린 IAM 결정은 별도의 로그가 아니라, 기존 변경관리 시스템(ServiceNow, Jira Service Management 등)에 자동으로 티켓이 생성되도록 연동해야 한다. 이 티켓에는 AI가 변경을 결정한 근거 데이터(사용 패턴, 적용된 정책 파라미터)가 포함되어야 한다.

NIST의 AI 위험 관리 프레임워크(AI RMF)는 AI 시스템의 결정에 대한 투명성과 설명 가능성을 핵심 요건으로 제시한다. IAM 자동화 역시 이 원칙을 적용해야 한다.

③ 배치 전용 계정과 비상 접근 계정을 AI 자동화 범위에서 명시적으로 제외하라

AI는 "사용 빈도"를 기준으로 미사용 권한을 탐지한다. 그러나 분기 말 배치, 재해복구 절차, 규제 보고용 계정은 의도적으로 드물게 사용된다. 이 계정들을 AI 자동화 대상에서 명시적으로 제외하는 태그 체계(예: iam-automation: exclude)를 도입해야 한다.

④ 분기별 AI IAM 결정 검토를 컴플라이언스 캘린더에 포함하라

AI가 지난 분기 동안 자동으로 내린 IAM 결정 전체를 IAM팀, 보안팀, 컴플라이언스팀이 함께 검토하는 프로세스를 만들어야 한다. 이 검토는 단순한 로그 확인이 아니라, "이 결정들이 우리의 컴플라이언스 요건과 충돌하는 부분이 있는가"를 판단하는 실질적 감사여야 한다.

---

거버넌스의 진짜 의미를 다시 생각할 때

AI클라우드가 스케일링을 결정하고, 벤더를 선택하고, 보안 정책을 바꾸고, 이제 "누가 무엇에 접근할 수 있는가"까지 결정하는 시대에, 거버넌스의 의미가 근본적으로 재정의되고 있다.

기술은 단순히 기계가 아니라, 인간의 삶과 조직의 구조를 바꾸는 강력한 요소다. AI가 IAM을 자동화하는 것 자체가 문제가 아니다. 문제는 그 자동화가 조직의 책임 구조와 컴플라이언스 요건을 인식하지 못한 채 진행될 때다.

IAM은 보안의 가장 기본적인 질문 — "누가 신뢰받는가" — 에 대한 답이다. 그 답을 AI에게 완전히 위임하기 전에, 우리는 먼저 "그 AI의 결정을 누가 책임지는가"라는 질문에 명확히 답해야 한다.

지금 당장 자신의 조직 클라우드 환경에서 AI 기반 IAM 도구가 "추천 모드"인지 "자동 적용 모드"인지 확인해보라. 그리고 그 설정을 누가, 언제, 어떤 승인을 거쳐 바꿨는지 추적해보라. 그 답을 찾는 과정 자체가, 지금 여러분의 조직이 직면한 거버넌스 공백의 크기를 알려줄 것이다.