IAM(Identity and Access Management), 즉 "누가 무엇에 접근할 수 있는가"는 클라우드 보안의 심장부다. 그런데 AI클라우드 관리 도구들이 이 영역에서도 단순한 "추천"을 넘어 자율 실행으로 넘어가고 있다. 과도한 권한을 가진 계정을 자동으로 축소하고, 비활성 자격증명을 자동으로 비활성화하며, 역할(Role) 정책을 자동으로 재작성한다. 문제는 이 모든 결정에 named approver(지명된 승인자)도, 변경 티켓도, 감사 가능한 승인 근거도 없다는 점이다.

2026년 5월 현재, AWS IAM Access Analyzer, Google Cloud의 Recommender API, Azure의 Entra ID Governance 등 주요 클라우드 플랫폼은 모두 AI 기반 권한 최적화 기능을 프로덕션 환경에 배포하고 있다. 그리고 그 자동화 수준은 점점 더 깊어지고 있다.

"최소 권한 원칙"을 AI가 집행하면 생기는 일

최소 권한 원칙(Principle of Least Privilege)은 보안의 황금률이다. 사용자나 서비스 계정에는 업무에 필요한 최소한의 권한만 부여해야 한다는 것. 이론적으로 완벽하다. 실무적으로는 지키기가 극도로 어렵다. 수백 개의 마이크로서비스, 수천 개의 IAM 역할, 끊임없이 변하는 워크로드 패턴 속에서 인간이 이를 실시간으로 추적하고 조정하는 것은 사실상 불가능에 가깝다.

AI는 이 틈을 파고든다. 실제 사용 패턴을 분석해 "이 역할은 지난 90일간 S3:DeleteObject 권한을 한 번도 사용하지 않았습니다. 제거를 권장합니다"라고 알려주는 것에서 출발한 기능이, 이제는 자동으로 정책을 수정하고 적용하는 단계로 진화했다.

표면적으로는 보안이 강화된다. 실제로 과도한 권한은 침해 사고 시 폭발 반경(blast radius)을 키우는 주범이다. AI가 이를 자동으로 줄여준다면 좋은 일 아닌가?

문제는 그 다음에 일어나는 일들이다.

AI클라우드 IAM 자동화가 만드는 세 가지 거버넌스 균열

1. 변경의 '근거'가 사라진다

전통적인 IAM 변경 프로세스에는 변경 요청서(Change Request)가 있다. "왜 이 권한을 수정하는가", "누가 검토했는가", "비즈니스 영향은 무엇인가"가 문서화된다. SOC 2 Type II 감사에서 감사자가 요구하는 것이 바로 이 승인 이력과 근거다.

AI가 자율적으로 IAM 정책을 변경하면, 로그에는 변경 사실이 남는다. 하지만 왜 그 변경이 이루어졌는지, 누가 그 판단을 승인했는지는 남지 않는다. AI 모델의 추론 과정은 감사 증거로 인정되지 않는다. 적어도 현재의 규제 프레임워크에서는.

2. 직무분리(Separation of Duties)가 우회된다

PCI DSS와 ISO 27001이 공통적으로 요구하는 것 중 하나가 직무분리다. 권한을 요청하는 사람과 권한을 승인하는 사람이 달라야 한다는 원칙. AI 에이전트는 이 구조를 근본적으로 해체한다. AI는 스스로 분석하고, 스스로 결정하고, 스스로 실행한다. 요청자와 승인자가 동일한 "존재"인 셈이다.

더 아이러니한 상황도 발생한다. AI가 자신의 운영에 필요한 권한을 스스로 조정하는 경우다. AWS의 일부 자동화 워크플로우에서 AI 에이전트가 실행 역할(Execution Role)의 권한 범위를 동적으로 확장하는 패턴이 보고되고 있다. 이는 직무분리 위반을 넘어 권한 에스컬레이션(privilege escalation) 위험으로 직결된다.

3. 예상치 못한 서비스 중단이 발생한다

이것이 가장 즉각적이고 가시적인 문제다. AI가 "90일간 미사용"이라고 판단해 권한을 제거했는데, 그 권한이 분기별로 실행되는 배치 작업에 필요한 것이었다면? 또는 재해복구(DR) 시나리오에서만 활성화되는 백업 복구 스크립트에 필요한 것이었다면?

실제로 이런 사고는 이미 발생하고 있다. 대형 금융 기관의 한 SRE팀은 AI 기반 권한 최적화 도구가 레거시 배치 파이프라인의 IAM 역할을 "미사용"으로 분류해 자동 비활성화한 후, 월말 정산 작업이 전면 실패하는 사태를 경험했다고 보고한 바 있다. 해당 파이프라인은 한 달에 한 번만 실행되는 구조였기 때문에 AI의 사용 패턴 분석 윈도우(90일)에서 "안전하게 제거 가능"으로 분류된 것이다.

a blue and white logo

Photo by Growtika on Unsplash

감사자의 질문에 AI는 답할 수 없다

SOC 2, ISO 27001, PCI DSS 감사에서 감사자가 IAM 변경 이력을 검토할 때 던지는 핵심 질문은 이렇다:

"이 권한 변경을 누가, 언제, 어떤 근거로 승인했습니까?"

AI 자율 실행 환경에서 이 질문에 대한 답은 사실상 없다. CloudTrail 로그에는 변경 이벤트가 기록되지만, 그 이벤트의 주체는 자동화 서비스 계정이고, 승인자는 존재하지 않는다. "AI가 최적이라고 판단했습니다"는 감사 증거로 인정되지 않는다.

NIST SP 800-53의 AC-2(계정 관리) 통제 항목은 계정 및 권한 변경에 대한 공식 승인 프로세스를 명시적으로 요구한다. AI 자율화가 이 프로세스를 우회하면, 기업은 통제 항목 미준수 상태가 된다. 그리고 그 책임은 AI 벤더가 아닌 해당 기업에 귀속된다.

이 구조적 문제는 앞서 AI Cloud가 트래픽 라우팅을 자율 결정하는 문제에서도 동일하게 나타난다. 어떤 클라우드 운영 레이어에서든, AI가 "추천"에서 "자율 실행"으로 넘어가는 순간 감사 가능성의 전제가 무너진다.

AI클라우드 IAM 자동화, 어디까지 허용할 것인가

그렇다고 AI 기반 IAM 최적화를 전면 거부하는 것은 현실적이지 않다. 수작업으로 수천 개의 IAM 역할을 관리하는 것은 이미 인간의 능력 밖이다. 문제는 자동화의 범위와 거버넌스 구조다.

현재 업계에서 논의되는 실용적 접근법은 크게 세 단계로 나뉜다:

단계 1: 감지(Detect) — AI가 분석, 인간이 검토

AI는 과도한 권한, 미사용 자격증명, 정책 이상을 탐지하고 보고서를 생성한다. 실행은 인간이 한다. 변경 티켓이 생성되고, 승인자가 지정되며, 변경 근거가 문서화된다. 가장 안전하지만 가장 느리다.

단계 2: 조건부 자동화(Conditional Automation) — 낮은 위험도 변경만 자율 실행

위험도 분류 기준을 사전에 정의하고, 낮은 위험도(예: 30일 이상 미사용 임시 자격증명 비활성화)에 해당하는 변경만 자율 실행을 허용한다. 단, 모든 자율 실행 건은 자동으로 변경 티켓이 생성되고, 사후 검토 큐에 들어가야 한다. 이 방식은 속도와 감사 가능성 사이의 균형을 추구한다.

단계 3: 완전 자율화(Full Autonomy) — 현재로서는 컴플라이언스 위험

프로덕션 환경에서 IAM 정책의 완전 자율 변경은 현재의 규제 프레임워크 하에서 컴플라이언스 위험이 너무 크다. 이 단계는 규제 환경이 AI 자율 의사결정을 수용하는 방향으로 진화하기 전까지는 권장하기 어렵다.

실무에서 지금 당장 해야 할 것들

이론적 논의보다 중요한 것은 지금 당장 무엇을 해야 하는가다. 다음은 AI 기반 IAM 자동화를 도입했거나 도입을 검토 중인 팀을 위한 체크리스트다:

① 자율 실행 범위를 명시적으로 제한하라 AWS IAM Access Analyzer, GCP Recommender 등의 도구에서 "자동 적용(Auto-Apply)" 또는 "자동 수정(Auto-Remediate)" 옵션이 기본 활성화되어 있는지 확인하라. 많은 팀이 이 옵션이 켜져 있다는 사실조차 모르는 경우가 있다.

② 모든 IAM 변경에 대한 자동 티켓 생성 파이프라인을 구축하라 AI가 실행하든 인간이 실행하든, IAM 정책 변경은 자동으로 ITSM(ServiceNow, Jira Service Management 등)에 티켓이 생성되어야 한다. 이 티켓이 감사 증거의 기반이 된다.

③ "미사용" 판단 기준을 비즈니스 맥락과 연결하라 AI의 사용 패턴 분석 윈도우(통상 30~90일)는 분기별 배치 작업, 연간 DR 훈련, 계절성 워크로드를 놓친다. 중요 역할에는 예외 태그(exception tag)를 부여하고 자동 최적화 대상에서 제외하라.

④ 컴플라이언스 팀과 AI 자동화 범위를 공동으로 검토하라 많은 조직에서 AI 자동화 도입은 엔지니어링 팀이 주도하고, 컴플라이언스 팀은 사후에 문제를 발견한다. IAM 자동화는 반드시 컴플라이언스, 보안, 엔지니어링 팀이 공동으로 범위를 정의해야 한다.

⑤ AI 결정의 "설명 가능성" 요구사항을 벤더와 협의하라 AI가 특정 권한 변경을 결정한 근거를 기계가 읽을 수 있는 형태로 로그에 기록할 수 있는지 벤더에 확인하라. 일부 도구는 이미 "추천 근거(recommendation rationale)" 필드를 제공하고 있으며, 이를 변경 티켓에 자동으로 첨부하는 것이 가능하다.

거버넌스 없는 자동화는 보안이 아니다

AI 기반 IAM 자동화의 역설은 이렇다. 보안을 강화하려는 도구가 감사 가능성을 훼손함으로써 컴플라이언스 위험을 높인다. 권한 남용을 줄이는 동시에 변경 승인 체계를 우회한다.

이것은 AI 기술 자체의 문제가 아니다. AI를 거버넌스 구조 없이 프로덕션 환경에 배포하는 방식의 문제다. 기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 하지만 그 도구가 제대로 작동하려면 인간이 설계한 통제 구조 안에서 작동해야 한다.

데이터 주권과 통제 가능성의 문제는 클라우드 인프라를 넘어 더 넓은 맥락에서도 제기된다. 예를 들어 위성 데이터 주권 논쟁에서 볼 수 있듯, 누가 데이터와 시스템의 최종 통제권을 갖는가는 기술 영역 전반에 걸친 핵심 질문이다. AI클라우드 IAM도 같은 질문 앞에 서 있다.

AI클라우드가 "누구에게 접근을 허용할지"를 스스로 결정하는 세상에서, 우리가 진짜 물어야 할 질문은 하나다.

그 결정에 대한 책임은 누가 지는가?

지금 당신의 클라우드 환경에서 AI가 IAM 정책을 자율적으로 변경하고 있다면, 그 답이 아직 없을 가능성이 높다.

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

아래는 이전 글에서 이어지는 새로운 글입니다. 이전 글(IAM 편)의 결론부를 자연스럽게 연결하되, 새로운 주제와 각도로 전개합니다.

AI 클라우드, 이제 "누가 얼마나 쓸지"도 스스로 결정한다 — 그 판단은 당신이 승인했는가?

2026년 5월 3일 | 김테크

IAM 편에서 우리는 "누구에게 접근을 허용할지"를 AI가 결정하는 세상의 거버넌스 공백을 살펴봤다. 오늘은 그 다음 질문으로 넘어간다.

AI가 "얼마를 쓸지"까지 결정한다면?

클라우드 비용 최적화(Cost Optimization). 들으면 당연히 좋은 말처럼 들린다. 낭비를 줄이고, 예산을 아끼고, 효율을 높인다. 누가 반대하겠는가. 문제는 그 "최적화"가 인간의 승인 없이, 변경 티켓 없이, 때로는 아무도 모르게 실행된다는 점이다.

"비용 최적화 AI"는 이미 당신의 클라우드 지갑을 쥐고 있다

AWS Cost Optimizer, Google Cloud Recommender, Azure Advisor. 이름만 들으면 "추천 엔진"처럼 들린다. 하지만 2025년 하반기부터 이들 도구의 공통된 방향성은 하나다. 추천(Recommend)에서 실행(Execute)으로.

구체적으로 어떤 일이 일어나는지 살펴보자.

Reserved Instance(예약 인스턴스) 자동 구매 및 해지: AI가 사용 패턴을 분석해 1년 또는 3년 약정 RI를 자동으로 구매하거나, 기존 약정을 중도 해지하고 다른 인스턴스 타입으로 전환한다.
Savings Plans 자동 전환: 컴퓨트 Savings Plans에서 EC2 Instance Savings Plans으로, 또는 그 반대로 AI가 판단해 자동 변경한다.
유휴 리소스 자동 삭제: 30~90일 사용 이력이 없는 스냅샷, 미연결 EBS 볼륨, 유휴 로드밸런서를 AI가 "낭비"로 판단하고 자동 삭제한다.
인스턴스 타입 자동 다운사이징: CPU·메모리 사용률이 낮다는 이유로 AI가 인스턴스 타입을 자동으로 축소한다.

각각의 행위를 개별적으로 보면 합리적이다. 하지만 이 모든 결정이 "누가 승인했는가"라는 기록 없이 실행된다면, 우리는 전혀 다른 문제 앞에 서게 된다.

비용 최적화가 "재무 거버넌스"를 우회하는 방식

클라우드 비용은 단순한 IT 운영 예산이 아니다. 상장 기업이라면 클라우드 지출은 재무제표와 직결된다. 특히 Reserved Instance와 Savings Plans는 선불 약정(commitment)이기 때문에, 이를 구매하거나 해지하는 행위는 회계적으로 자본 지출(CapEx) 또는 운영 지출(OpEx) 분류에 영향을 미친다.

전통적인 기업 환경에서 이 정도 규모의 지출 결정은 반드시 구매 승인 프로세스(procurement approval)를 거친다. CFO 또는 재무 담당자의 서명이 필요하고, 변경 이력이 ERP 시스템에 기록된다.

AI 비용 최적화 도구가 이 프로세스를 우회하면 무슨 일이 벌어지는가?

시나리오를 하나 상상해보자.

한 SaaS 기업의 클라우드 비용 최적화 도구가 분기 말 어느 금요일 오후, 사용률이 낮아 보이는 3년 약정 RI 묶음을 자동으로 해지하고 온디맨드로 전환했다. AI의 판단은 기술적으로 틀리지 않았다. 해당 인스턴스들은 실제로 평균 CPU 사용률이 15% 미만이었다.

그런데 그 인스턴스들은 분기 말 배치 작업과 DR(재해복구) 훈련을 위해 예약된 리소스였다. 결과적으로 그 다음 주에 DR 훈련이 실패했고, 온디맨드 전환으로 인해 해당 분기 클라우드 비용이 예산 대비 40% 초과했다. 재무팀은 분기 보고서를 수정해야 했고, 감사인은 "이 지출 결정을 누가 승인했는가"를 물었다.

아무도 승인하지 않았다. AI가 결정했다.

FinOps가 말하지 않는 것: "자율화"의 감사 공백

FinOps(Financial Operations) 프레임워크는 클라우드 비용의 가시성, 최적화, 운영을 체계화하는 방법론이다. 최근 FinOps Foundation의 보고서에 따르면, 기업의 클라우드 낭비 비율은 평균 28~35%에 달하며, AI 기반 최적화 도구가 이를 크게 줄일 수 있다고 강조한다.

맞는 말이다. 하지만 FinOps 프레임워크가 명시적으로 다루지 않는 영역이 있다. 자율 실행(autonomous execution)이 발생했을 때의 감사 추적(audit trail)이다.

SOC 2 Type II의 CC6(논리적 접근 통제)와 CC8(변경 관리) 조항, ISO 27001의 A.12.1.2(변경 관리) 조항은 모두 공통적으로 하나를 요구한다. 변경에는 승인자가 있어야 하고, 그 근거가 기록되어야 한다.

AI 비용 최적화 도구가 RI를 자동 구매하거나 인스턴스를 자동 삭제할 때, 이 조항들을 충족하는 방식으로 기록이 남는가? 대부분의 경우, 답은 "부분적으로만" 또는 "아니오"다.

클라우드 제공자의 콘솔 로그에는 "Cost Optimizer에 의해 실행됨"이라는 기록이 남을 수 있다. 하지만 그것이 누가 이 자동화를 승인했는지, 왜 이 특정 리소스가 대상이 되었는지, 어떤 비즈니스 맥락이 검토되었는지를 설명하지는 않는다.

감사인이 원하는 것은 이벤트 로그가 아니다. 의사결정의 책임 체계(accountability chain)다.

비용 최적화 AI가 만드는 세 가지 거버넌스 공백

1. 재무 승인 체계의 우회

앞서 언급했듯, 클라우드 약정 구매는 재무적 의사결정이다. AI가 이를 자동 실행하면, 기업의 구매 정책(procurement policy)이 사실상 무력화된다. 특히 SOX(사베인스-옥슬리법) 적용 대상 기업이라면, 재무 보고에 영향을 미치는 지출 결정에 대한 내부 통제(internal control) 요건을 위반할 수 있다.

2. 삭제된 리소스의 복구 불가능성

AI가 "유휴"로 판단해 삭제한 스냅샷이나 EBS 볼륨이 실제로는 규제 요건에 따라 보존해야 하는 데이터였다면? GDPR의 데이터 보존 정책, 금융권의 5~7년 기록 보존 의무, 의료 데이터의 장기 보관 요건을 AI의 비용 최적화 로직이 알 리 없다.

삭제는 되돌릴 수 없다. 그리고 "AI가 삭제했습니다"는 규제 기관 앞에서 면책 사유가 되지 않는다.

3. 예산 예측 가능성의 붕괴

역설적이게도, 비용을 줄이려는 AI가 비용 예측을 더 어렵게 만들 수 있다. AI가 자율적으로 인스턴스 타입을 변경하고, 약정을 조정하고, 리소스를 삭제하면, 재무팀이 수립한 클라우드 예산 모델이 실제 인프라 상태와 지속적으로 어긋나게 된다. 이는 단순한 불편함이 아니라, 예산 편성과 감사의 신뢰성을 근본적으로 훼손한다.

그렇다면 우리는 어떻게 해야 하는가

비용 최적화 AI를 쓰지 말라는 이야기가 아니다. 도구는 강력하고, 잘 활용하면 실질적인 비용 절감 효과를 가져온다. 문제는 도구가 아니라, 도구를 거버넌스 구조 없이 자율 실행 모드로 배포하는 방식이다.

① 자동 실행 범위를 "추천"과 "실행"으로 명확히 분리하라 모든 비용 최적화 도구에는 "추천만 제공(Recommend Only)"과 "자동 실행(Auto-Execute)" 모드가 있다. 약정 구매·해지, 리소스 삭제, 인스턴스 타입 변경은 반드시 "추천만 제공" 모드로 운영하고, 인간 승인을 거친 후 실행하라.

② 비용 최적화 결정을 재무 승인 워크플로우에 연결하라 일정 금액 이상의 약정 변경(예: 월 $1,000 이상 영향)은 자동으로 재무팀 승인 요청이 생성되도록 파이프라인을 구성하라. 이것이 FinOps와 재무 거버넌스를 연결하는 최소한의 통제 장치다.

③ 삭제 대상 리소스에 대한 "데이터 분류 태그" 검증 단계를 추가하라 AI가 삭제를 추천하기 전에, 해당 리소스의 데이터 분류 태그(data classification tag)를 확인하는 사전 검증 로직을 구축하라. 보존 의무가 있는 데이터가 포함된 리소스는 자동 삭제 대상에서 자동 제외되어야 한다.

④ AI 결정 로그를 ITSM과 재무 시스템에 동시에 기록하라 AI가 어떤 비용 최적화 행위를 실행했는지는 클라우드 콘솔 로그에만 남겨서는 안 된다. ServiceNow나 Jira의 변경 티켓, 그리고 가능하다면 ERP의 지출 기록과도 연동되어야 한다. 감사인이 단일 시스템에서 의사결정의 전체 맥락을 확인할 수 있어야 한다.

⑤ 분기·연간 배치 작업과 DR 리소스에는 반드시 예외 태그를 부여하라 AI의 사용 패턴 분석 윈도우는 일상적 워크로드를 기준으로 설계되어 있다. 계절성 작업, DR 훈련, 규제 보고용 배치 작업에 사용되는 리소스는 명시적으로 자동 최적화 제외 대상으로 태깅하라.

효율성과 통제 가능성은 상충하지 않는다

비용 최적화 AI를 도입하는 기업들이 흔히 빠지는 함정이 있다. "효율을 높이려면 자동화를 믿어야 한다"는 논리다. 인간이 개입하면 느리고, AI가 더 정확하고, 결국 비용도 더 절감된다는 주장이다.

틀린 말은 아니다. 하지만 그 논리는 기술적 효율성만을 본다. 거버넌스, 컴플라이언스, 감사 가능성, 재무 책임이라는 차원을 빠뜨린다.

우리가 직면한 문제를 해결하는 방식은 자동화를 거부하는 것이 아니라, 자동화가 작동하는 경계를 인간이 설계하는 것이다. AI가 추천하고, 인간이 승인하고, 시스템이 기록한다. 이 세 단계가 함께 작동할 때 비로소 효율성과 통제 가능성은 상충하지 않는다.

클라우드 비용의 최종 책임은 AI에게 없다. 그 책임은 여전히 CFO의 서명란에, 감사인의 체크리스트에, 그리고 규제 기관의 질문지에 있다.

AI가 "얼마를 쓸지" 결정하는 세상에서, 그 결정에 서명할 사람은 여전히 당신이어야 한다.

태그: AI클라우드, 비용 최적화, FinOps, 클라우드 거버넌스, 컴플라이언스, 재무 통제, 자동화

NOCODE TECH STACKER

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