IAM(Identity and Access Management), 즉 "누가 어떤 자원에 접근할 수 있는가"는 클라우드 보안의 가장 근본적인 질문이다. 그런데 AI 클라우드 환경에서 이 질문에 대한 답이 더 이상 사람의 손에만 있지 않다. AI 도구들이 접근 정책을 실시간으로 조정하고, 권한을 부여하거나 회수하고, 심지어 예외 처리를 자율적으로 실행하기 시작했다. 변경 티켓도, 명시적 승인자도, 감사 가능한 판단 근거도 없이.

이 변화는 조용하다. 그래서 더 위험하다.

---

"접근 제어"는 원래 가장 엄격하게 관리되던 영역이었다

전통적인 클라우드 거버넌스 프레임워크에서 IAM 정책 변경은 가장 높은 수준의 통제를 받는 영역 중 하나였다. SOC 2, ISO 27001, PCI-DSS, HIPAA 등 주요 컴플라이언스 프레임워크들은 공통적으로 다음을 요구한다.

• 최소 권한 원칙(Principle of Least Privilege): 필요한 최소한의 권한만 부여
• 직무 분리(Separation of Duties): 권한을 부여하는 사람과 사용하는 사람의 분리
• 감사 추적(Audit Trail): 누가 언제 어떤 이유로 접근 권한을 변경했는지의 기록
• 명시적 승인(Explicit Approval): 변경 전 담당자의 서명 또는 티켓 승인

이 네 가지 원칙은 수십 년간 기업 IT 거버넌스의 기둥이었다. 그런데 AI 기반 IAM 자동화 도구들이 이 기둥들을 하나씩 흔들고 있다.

---

AI가 접근 권한을 "추천"하는 것과 "실행"하는 것은 다르다

문제는 AI가 IAM에 관여하기 시작했다는 사실 자체가 아니다. AI가 "이 계정의 권한이 과도합니다. 축소를 권장합니다"라고 제안하는 것은 오히려 환영할 만한 일이다. 문제는 그 다음 단계, 즉 AI가 그 권장 사항을 스스로 실행하기 시작했을 때다.

AWS IAM Access Analyzer, Google Cloud의 Policy Intelligence, Microsoft Entra ID의 Access Reviews 등 주요 클라우드 벤더들의 IAM 도구들은 이미 "자동 수정(Auto-remediation)" 기능을 제공하고 있다. 설정에 따라 이 도구들은 미사용 권한을 자동으로 회수하고, 비정상적인 접근 패턴을 감지하면 계정을 자동으로 차단하며, 정책 드리프트를 감지하면 기준 상태로 되돌린다.

기술적으로는 훌륭하다. 거버넌스 관점에서는 악몽이다.

왜냐하면 이 "자동 수정"이 실행되는 순간, 다음 질문들에 대한 답이 시스템 어딘가에 묻혀버리기 때문이다.

• 이 권한 회수는 의도된 것인가, 아니면 AI의 오판인가?
• 이 계정 차단을 승인한 사람은 누구인가?
• 이 정책 변경의 비즈니스 근거는 무엇인가?
• 이 결정에 이의를 제기하려면 누구에게 가야 하는가?

---

AI 클라우드의 IAM 자동화가 만들어내는 세 가지 구조적 결함

결함 1: 의도된 예외와 정책 위반의 경계가 사라진다

모든 기업에는 "공식 정책"과 "실제 운영"의 간극이 존재한다. 예를 들어, 특정 개발팀이 프로젝트 마감 전 임시로 확장된 권한을 부여받는 경우, 또는 외부 감사 기간 동안 감사인에게 특별 읽기 권한을 주는 경우가 그렇다. 이런 예외들은 사람이 맥락을 이해하고 승인하기 때문에 "위반"이 아닌 "의도된 예외"로 관리된다.

AI 자동화 시스템은 이 맥락을 모른다. 시스템이 보기에 "정책 기준을 벗어난 권한"은 모두 교정 대상이다. 그 결과, 비즈니스 운영에 필수적인 임시 예외가 예고 없이 회수되고, 중요한 작업이 갑자기 중단되는 상황이 발생할 수 있다.

더 심각한 것은 그 반대의 경우다. 실제 보안 위반이나 내부자 위협에 의한 비정상적 권한 확장을, AI가 "자동화 파이프라인의 정상적인 서비스 계정 활동"으로 오분류하여 방치하는 시나리오는 이미 보안 연구 커뮤니티에서 반복적으로 논의되고 있다.

결함 2: 감사 증거의 품질이 근본적으로 달라진다

컴플라이언스 감사에서 IAM 관련 질문은 항상 같다. "이 권한 변경은 누가 승인했습니까?" 전통적인 환경에서 이 질문의 답은 명확하다. 티켓 번호, 승인자 이름, 승인 시각, 변경 이유가 있다.

AI 자동화 환경에서 이 질문의 답은 이렇게 된다. "AI 정책 엔진이 자동으로 실행했습니다. 판단 근거는 모델의 내부 추론입니다."

이것이 감사인에게 어떻게 들릴지는 굳이 설명하지 않아도 알 것이다. AI 클라우드가 백업과 복구 결정을 자율적으로 내릴 때 발생하는 감사 공백과 정확히 같은 구조적 문제가 IAM 영역에서도 재현되고 있다.

NIST의 AI Risk Management Framework(AI RMF)는 AI 시스템의 결정에 대한 설명 가능성과 투명성을 핵심 요구 사항으로 명시하고 있다. 그러나 현재 대부분의 클라우드 IAM 자동화 도구들은 이 기준을 충족하는 감사 로그를 기본으로 생성하지 않는다.

결함 3: 보안 대응 속도와 거버넌스 속도의 충돌

AI 기반 IAM 자동화를 도입하는 가장 강력한 논거는 속도다. 사람이 이상 징후를 감지하고 권한을 회수하는 데 걸리는 시간이 수 시간이라면, AI는 수 초 만에 처리할 수 있다. 실제 침해 사고에서 이 속도 차이는 피해 규모를 결정할 수 있다.

이 논거는 틀리지 않았다. 문제는 이 속도 우선 논리가 거버넌스 프로세스 전체를 우회하는 정당화로 사용된다는 점이다.

"보안 긴급 상황이니 승인 없이 실행했다"는 논리는 보안팀에서 한 번쯤 들어봤을 것이다. 그런데 AI 자동화 시스템이 이 논리를 24시간 365일 모든 결정에 적용하기 시작하면, 사실상 거버넌스 프레임워크는 유명무실해진다.

---

실제로 어떤 일이 일어나고 있는가

몇 가지 패턴이 현장에서 반복적으로 관찰되고 있다.

서비스 중단 사례: AI IAM 도구가 "비정상적으로 높은 API 호출 빈도"를 감지하고 서비스 계정의 권한을 자동으로 회수한 결과, 프로덕션 환경의 마이크로서비스 간 통신이 중단된 사례들이 보고되고 있다. 해당 API 호출은 사실 정상적인 트래픽 스파이크였지만, AI 모델의 학습 데이터에 없는 패턴이었다.

컴플라이언스 감사 실패: 금융권 기업들에서 AI가 자동 회수한 권한 변경 내역이 "승인된 변경 관리 프로세스를 거치지 않은 무단 변경"으로 분류되어 감사 지적 사항이 된 사례가 있다. 아이러니하게도 보안을 강화하려던 자동화 조치가 컴플라이언스 위반으로 기록된 것이다.

권한 크리프의 역설: AI 시스템이 정책 드리프트를 교정하는 과정에서, 원래 정책 자체가 불완전하거나 현실과 괴리가 있는 경우, AI가 "올바른 기준"으로 되돌린 상태가 오히려 더 많은 권한을 부여하는 결과를 낳는 사례도 보고되고 있다. AI는 기준 정책이 옳다고 가정하지만, 기준 정책 자체가 틀릴 수 있다.

---

AI 클라우드 IAM 거버넌스를 다시 설계하는 법

이 문제의 해법은 AI 자동화를 포기하는 것이 아니다. 자동화의 속도와 거버넌스의 책임성을 동시에 확보하는 설계가 필요하다.

1. 자동화 범위를 명시적으로 정의하라

모든 IAM 자동화 결정을 동일하게 취급하지 말아야 한다. 다음과 같은 계층적 접근이 필요하다.

• 완전 자동화 허용: 명백히 미사용 상태인 서비스 계정의 비활성화 알림 발송 (실행은 사람이)
• 조건부 자동화: 임계값 이하의 저위험 권한 조정은 자동 실행하되 즉시 알림 + 24시간 내 이의 제기 창구 보장
• 반드시 인간 승인: 프로덕션 환경 서비스 계정, 관리자 권한, 크로스-테넌트 접근 정책 변경

이 계층을 문서화하고, AI 도구의 설정에 명시적으로 반영해야 한다.

2. AI 결정에 대한 "설명 가능한 로그"를 의무화하라

AI가 IAM 결정을 실행할 때, 단순한 "변경 실행됨" 로그가 아닌 다음 정보가 포함된 구조화된 로그가 필요하다.

• 어떤 신호를 감지했는가 (트리거 조건)
• 어떤 정책 기준과 비교했는가 (판단 근거)
• 대안적 조치는 무엇이었는가 (왜 이 조치를 선택했는가)
• 영향을 받는 리소스와 서비스의 범위

이것이 완벽한 감사 증거는 아닐 수 있지만, "AI가 했습니다"보다는 훨씬 감사 가능한 형태다.

3. 인간 승인 루프를 "선택 사항"이 아닌 "기본값"으로 설정하라

많은 AI IAM 도구들이 자동 실행을 기본값으로, 사람 승인을 옵션으로 제공한다. 이 기본값을 뒤집어야 한다. 자동 실행은 명시적으로 허용한 범위에서만, 나머지는 기본적으로 사람의 검토를 거치도록 설계해야 한다.

Hilary Mason이 지적했듯이, AI 제품의 진짜 어려움은 기술 자체가 아니라 인간의 신뢰와 책임 구조를 어떻게 설계하느냐에 있다. IAM 자동화는 이 통찰이 가장 직접적으로 적용되는 영역 중 하나다.

4. 컴플라이언스 팀을 도구 선정 단계부터 참여시켜라

현실에서는 보안팀이나 인프라팀이 AI IAM 도구를 도입한 후, 컴플라이언스팀이 감사 준비 과정에서 문제를 발견하는 경우가 많다. 이미 운영 중인 시스템을 거버넌스 요구 사항에 맞게 되돌리는 것은 처음부터 설계에 반영하는 것보다 훨씬 비용이 크다.

---

이것은 기술 문제가 아니라 조직 문제다

AI 클라우드 IAM 자동화가 만들어내는 거버넌스 공백은 기술적으로 해결 불가능한 문제가 아니다. 오히려 기술적 해결책은 이미 존재한다. 문제는 조직이 이 변화를 인식하지 못하거나, 인식하더라도 "일단 편리하니까"라는 이유로 거버넌스 설계를 미루는 데 있다.

"기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구입니다." 그러나 도구가 스스로 "누가 무엇에 접근할 수 있는지"를 결정하기 시작할 때, 우리는 그 도구가 우리의 의도를 대리하고 있는지, 아니면 우리의 권한을 대체하고 있는지를 물어야 한다.

클라우드 인프라에서 AI가 자율적으로 결정하는 영역은 이제 치유(self-healing), 스케일링, 패치, 네트워킹, 비용, 백업, 스토리지에 이어 접근 제어까지 확장되었다. 각각의 영역에서 같은 질문이 반복된다. "그 판단은 당신이 승인했는가?"

이 질문에 명확하게 "예"라고 답할 수 없다면, 지금 당장 AI 도구의 설정 화면을 열어볼 시간이다.

---

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

위의 내용을 보니, 이 글은 이미 완성된 상태입니다. 결론부("이것은 기술 문제가 아니라 조직 문제다")와 태그까지 포함되어 있어, 실질적으로 이어 쓸 내용이 없습니다.

다만, 글의 완성도를 높이기 위해 현재 결론 이후에 추가할 수 있는 보완 섹션을 제안드릴 수 있습니다. 예를 들어:

• 독자 액션 체크리스트 ("지금 당장 확인해야 할 5가지")
• 관련 글 시리즈 안내 (이전 AI 클라우드 거버넌스 시리즈 연결)
• 편집자 주 또는 업데이트 노트

원하시는 방향이 있으시면 말씀해 주세요. 아니면 혹시 다른 글의 미완성 부분을 붙여넣으신 건 아닌지 확인 부탁드립니다. 제가 이어 써야 할 내용이 잘린 채로 끝나는 부분이 있다면 정확한 텍스트를 다시 공유해 주시면 바로 이어서 작성해 드리겠습니다.