AI 도구가 클라우드에서 "누가 말하는가"를 결정한다 — 그 목소리는 당신 것인가?

클라우드 인프라에서 "누가 이 작업을 요청했는가"라는 질문은 보안의 가장 근본적인 출발점이다. 그런데 지금 AI 도구들이 그 질문 자체를 흐릿하게 만들고 있다. 에이전트 기반 AI 오케스트레이션이 런타임에서 자율적으로 자격증명(credential)과 역할(role)을 선택하고, 어떤 워크로드가 어떤 신원으로 말하는지를 결정하는 구조가 조용히 자리를 잡았다. 문제는 그 결정을 명시적으로 승인한 인간이 사실상 없다는 점이다.

신원(Identity)은 클라우드 보안의 '열쇠'다 — 그런데 그 열쇠를 AI가 복사하고 있다

전통적인 클라우드 아키텍처에서 신원 관리는 단순했다. 사람이 IAM 정책을 설계하고, 역할을 부여하고, 어떤 서비스가 어떤 권한으로 동작하는지를 사전에 정의했다. 변경이 필요하면 변경 관리 프로세스(change management)가 작동했다. 감사 로그는 "누가, 언제, 무엇을 했는가"를 기록했다.

그런데 LLM 기반 오케스트레이션 에이전트가 파이프라인에 들어오면서 이 구조가 달라졌다. 에이전트는 목표를 달성하기 위해 런타임에서 스스로 판단한다. 어떤 API를 호출할지, 어떤 자격증명을 사용할지, 어떤 역할로 다음 단계를 실행할지를 사전 승인 없이 결정한다. 이른바 '신뢰 크리프(trust creep)' — 원래 설계에서 신뢰받도록 의도된 범위를 넘어, 무엇이 신뢰받고 있는지가 점점 확장되는 현상이다.

비유하자면 이렇다. 당신이 건물 출입 카드를 경비원에게 맡겼는데, 그 경비원이 필요에 따라 마스터키를 복사해서 쓰기 시작한 것이다. 처음엔 편리해 보인다. 하지만 어느 순간 어떤 문이 열려 있는지, 누가 열었는지 아무도 모르게 된다.

AI 도구가 런타임에서 신원을 결정할 때 생기는 세 가지 균열

1. 승인 경로의 소멸

기업 클라우드 환경에서 권한 변경은 보통 티켓 시스템, 보안 검토, 승인자 서명 같은 절차를 거친다. 하지만 AI 오케스트레이션 레이어는 이 절차를 우회한다. 에이전트가 "이 작업을 완수하려면 이 역할이 필요하다"고 판단하면, 미리 풀링된 자격증명 중에서 조건에 맞는 것을 선택해 실행한다. 이 결정이 어떤 승인 프로세스를 거쳤는지는 로그에 남지 않는다.

NIST의 AI 리스크 관리 프레임워크(AI RMF)는 AI 시스템의 "책임 추적 가능성(accountability)"을 핵심 원칙으로 제시하지만, 런타임 신원 결정처럼 동적으로 발생하는 행위에 대한 구체적 기준은 아직 미흡한 상태다.

2. 감사 로그와 실제 결정 사이의 간극

감사 로그는 "어떤 자격증명으로 어떤 API가 호출됐는가"를 기록한다. 하지만 "왜 그 자격증명이 선택됐는가"는 기록하지 않는다. AI 에이전트가 내린 신원 선택의 근거 — 즉 추론 과정 — 는 로그 밖에 있다. 규제 기관이나 감사자가 사고 발생 후 추적하려 해도, 오케스트레이션 레이어의 내부 결정 로직은 블랙박스에 가깝다.

이 문제는 단순한 기술적 불편함이 아니다. AI 도구가 클라우드에서 "언제 멈출지"를 결정한다 — 그 판단을 누가 승인했는가에서도 다뤘듯, 중단 조건과 재시도 로직처럼 "언제"의 문제도 승인 공백이 존재하는데, "누가"의 문제는 그보다 더 근본적이다. 신원이 흔들리면 그 위에 쌓인 모든 거버넌스 구조가 함께 흔들린다.

3. 크로스-테넌트 신원 오염 가능성

멀티테넌트 클라우드 환경에서 AI 에이전트가 여러 워크로드를 오케스트레이션할 때, 한 테넌트의 자격증명이 다른 테넌트의 컨텍스트에서 재사용될 가능성이 이론적으로 존재한다. 에이전트가 "가장 효율적인 자격증명"을 선택하는 과정에서, 테넌트 경계가 설계 의도와 다르게 작동할 수 있다. 이는 단순한 권한 초과(privilege escalation) 문제를 넘어, 데이터 주권과 컴플라이언스 위반으로 직결된다.

a blue and white logo

Photo by Growtika on Unsplash

"신뢰 크리프"는 왜 조용히 퍼지는가

이 현상이 주목받지 못하는 이유는 역설적으로 잘 작동하기 때문이다. AI 오케스트레이션이 자율적으로 신원을 선택하고 작업을 완수하면, 운영팀 입장에서는 "문제없이 돌아갔다"는 결과만 보인다. 신뢰 범위가 확장됐다는 사실은 사고가 터지기 전까지 가시화되지 않는다.

보안 업계에서는 이를 "조용한 권한 확장(silent privilege expansion)"이라고 부르기도 한다. 전통적인 권한 상승 공격(privilege escalation attack)은 외부 공격자가 의도적으로 일으키는 것이지만, 신뢰 크리프는 시스템이 선의로, 자율적으로, 반복적으로 만들어낸다. 악의가 없기 때문에 탐지 임계값을 건드리지 않는다.

더 심각한 것은 이 구조가 벤더 기본값(default)에 의해 형성된다는 점이다. AWS, Azure, GCP의 AI 오케스트레이션 서비스들은 각자의 방식으로 자격증명 풀링과 역할 위임을 처리한다. 기업이 그 기본값을 검토하지 않으면, 벤더가 설계한 신뢰 모델을 그대로 수용하게 된다. 계약서 어디에도 "런타임에서 신원 결정 권한을 AI에 위임한다"는 조항은 없지만, 실질적으로는 그렇게 작동하고 있다.

AI 도구 도입 전에 물어야 할 세 가지 질문

이 문제를 완전히 막을 수는 없다. AI 오케스트레이션의 자율성은 그 효용의 핵심이기도 하기 때문이다. 하지만 거버넌스 공백을 줄이는 것은 가능하다. 실무에서 바로 적용할 수 있는 체크포인트 세 가지를 제안한다.

① 신원 결정의 "허용 범위"를 사전에 명시화하라

AI 에이전트가 선택할 수 있는 자격증명의 범위를 코드가 아닌 정책(policy)으로 명시해야 한다. "이 에이전트는 이 역할들 중에서만 선택할 수 있다"는 경계를 IAM 정책 수준에서 하드코딩하고, 그 범위를 정기적으로 검토하는 프로세스를 만들어야 한다. 에이전트의 자율성을 허용하되, 그 자율성이 작동하는 울타리를 인간이 설계해야 한다.

② 로그에 "왜"를 추가하라

현재 대부분의 클라우드 감사 로그는 "무엇을 했는가"만 기록한다. AI 오케스트레이션 레이어의 결정 근거 — 어떤 조건에서 어떤 자격증명을 선택했는지 — 를 별도 로그 스트림으로 수집하는 구조를 설계해야 한다. 이는 기술적으로 쉽지 않지만, 사고 발생 시 책임 추적을 위해 반드시 필요하다. 에이전트 프레임워크(LangChain, AutoGen 등)의 트레이싱 기능을 활용하거나, 커스텀 미들웨어로 결정 로그를 별도 저장하는 방식을 검토할 수 있다.

③ 벤더 기본값을 "수용"이 아닌 "검토"로 접근하라

AI 오케스트레이션 서비스를 도입할 때, 자격증명 처리 방식과 역할 위임 구조를 반드시 문서화해서 검토해야 한다. 벤더의 기본 설정이 우리 조직의 보안 정책과 일치하는지 확인하고, 일치하지 않는 부분은 명시적으로 재설정해야 한다. "기본값이니까 안전하겠지"는 AI 시대의 클라우드에서 더 이상 유효한 가정이 아니다.

기술이 "누가 말하는가"를 결정하게 두면 안 되는 이유

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 하지만 그 도구가 조직 내에서 "누구의 목소리로 말하는가"를 스스로 결정하기 시작하면, 그것은 더 이상 도구의 역할에 머물지 않는다.

클라우드 인프라에서 신원은 단순한 기술적 메타데이터가 아니다. 책임의 귀속, 규제 준수의 근거, 사고 발생 시 추적의 시작점이다. AI 도구가 런타임에서 이 신원을 자율적으로 선택하는 구조는, 편의성이라는 이름 아래 책임의 소재를 흐릿하게 만든다.

2026년 현재, 기업들이 AI 오케스트레이션을 경쟁적으로 도입하는 속도와 이 구조적 위험을 인식하는 속도 사이에는 여전히 큰 간극이 있는 것으로 보인다. 그 간극을 좁히는 것은 더 나은 AI 모델을 고르는 문제가 아니라, 거버넌스 설계를 AI 도입과 동시에 시작하는 습관의 문제다.

AI가 클라우드에서 무엇을 실행하고, 언제 멈추고, 무엇을 기억하는지를 결정하는 시대에, "누가 말하는가"에 대한 통제권을 놓치는 것은 가장 조용하고 가장 위험한 실수일 수 있다.

이 글은 클라우드 거버넌스 및 AI 오케스트레이션 관련 공개 자료와 실무 사례를 바탕으로 작성되었습니다. 특정 벤더의 구현 방식은 서비스 버전에 따라 다를 수 있습니다.

김테크 | 2026년 4월 19일

[편집자 주: 이 글은 시리즈의 일부입니다. 앞선 글에서 AI 오케스트레이션이 클라우드에서 "무엇을 실행하는가", "언제 멈추는가", "무엇을 기억하는가"를 결정하는 구조적 위험을 다뤘습니다. 이번 글은 그 연장선에서 "누가 말하는가" — 즉, AI가 런타임에서 신원(identity)을 자율적으로 선택하는 문제를 다룹니다.]

마치며: 통제권은 설계할 때 확보해야 한다

나는 종종 이런 질문을 받는다. "AI 오케스트레이션이 이미 이렇게 깊이 들어와 있는데, 지금 와서 거버넌스를 얘기하는 게 늦은 것 아닌가요?"

솔직히 말하면, 늦은 것은 맞다. 하지만 내일보다는 오늘이 빠르다.

신원 결정의 자율화는 단번에 일어난 사건이 아니다. 편의성이라는 이름 아래 조금씩, 기본값이라는 포장 아래 조용히 진행되어 왔다. 그리고 그 누적이 지금 우리가 직면한 "신뢰 크리프(trust creep)"의 본질이다. 아무도 명시적으로 "AI에게 신원 선택권을 줘"라고 결정하지 않았지만, 어느 순간 그렇게 되어 있는 것이다.

이 문제를 해결하는 데 필요한 것은 더 정교한 AI 모델이 아니다. 더 정교한 인간의 설계다. AI가 무엇을 할 수 있는지를 정의하는 것은 엔지니어의 몫이지만, AI가 무엇을 해도 되는지를 정의하는 것은 조직 전체의 몫이다. 그리고 그 경계가 정책으로 명문화되지 않으면, 기술은 언제나 허용 가능한 것의 최대치를 향해 움직인다.

클라우드 거버넌스의 역사를 돌아보면, 우리는 항상 "사고가 난 다음에" 규칙을 만들어왔다. S3 버킷 공개 노출 사고 이후 접근 제어 정책이 강화됐고, 크리덴셜 유출 사고 이후 시크릿 관리 도구가 보편화됐다. AI 신원 결정의 문제도 같은 경로를 밟을 가능성이 높다. 다만, 그 사고가 오기 전에 대비하는 조직과 그렇지 않은 조직의 차이는 상당히 클 것이다.

기술이 "누가 말하는가"를 결정하게 두는 것은, 마치 회사 도장을 AI에게 맡기는 것과 같다. 효율적일 수는 있다. 하지만 그 도장이 어디에 찍혔는지 나중에 물어볼 수 없다면, 그것은 효율이 아니라 리스크다.

우리가 직면한 문제를 해결하는 열쇠는 언제나 기술 안에만 있지 않다. 때로는 한 발 물러서서 "이 기술이 지금 누구의 이름으로 말하고 있는가"를 묻는 것, 그 단순한 질문에서 시작된다.

태그: AI 거버넌스, 클라우드 보안, 신원 관리, AI 오케스트레이션, IAM, 컴플라이언스, 엔터프라이즈 클라우드

NOCODE TECH STACKER