AI 클라우드, 이제 "무엇을 배포했는가"보다 "무엇이 신뢰받고 있는가"가 더 위험하다

AI 클라우드 거버넌스의 위기는 조용히, 그러나 빠르게 진화하고 있다. 지금까지 우리는 "누가 배포했는가", "무엇이 청구를 만드는가", "누가 멈출 수 있는가"를 물어왔다. 그런데 2026년 현재, 더 근본적인 질문이 수면 위로 올라오고 있다. AI 클라우드 인프라 안에서 어떤 구성 요소가, 어떤 근거로, 얼마나 깊은 신뢰를 부여받고 있는가—그 질문에 답할 수 있는 조직이 과연 얼마나 될까.

"신뢰(Trust)"는 어떻게 AI 클라우드의 새로운 공격 표면이 되었나

전통적인 클라우드 보안 모델에서 신뢰는 명시적이었다. IAM 정책, 역할 기반 접근 제어(RBAC), 서비스 계정—모두 사람이 설계하고, 사람이 승인한 신뢰 관계였다. 누군가가 어떤 리소스에 접근하려면, 그 권한이 문서화된 정책에 의해 부여되어야 했다.

AI 에이전트와 LLM 오케스트레이션 레이어가 클라우드 인프라에 통합되면서 이 구조가 흔들리기 시작했다. 문제는 AI 툴이 "신뢰를 요청"하는 방식이 아니다. 문제는 AI 툴이 기존 신뢰 관계를 상속하고, 재조합하고, 확장하는 방식이다.

예를 들어보자. 기업이 내부 문서 검색을 위해 LLM 기반 에이전트를 배포했다고 가정하자. 이 에이전트는 처음에는 특정 S3 버킷 하나에만 접근할 수 있도록 설계되었다. 그런데 에이전트가 더 나은 검색 결과를 위해 추가 컨텍스트를 요청하는 과정에서, 오케스트레이션 레이어가 관련 데이터베이스 커넥터를 자동으로 연결한다. 이 커넥터는 이미 다른 서비스 계정의 신뢰 체인 안에 존재한다. 결과적으로 에이전트는 원래 설계된 것보다 훨씬 넓은 데이터 공간에 조용히 접근하게 된다.

이것이 "신뢰 크리프(Trust Creep)"다.

AI 에이전트가 신뢰를 "빌려 쓰는" 구조

현재 대부분의 AI 오케스트레이션 프레임워크—LangChain, AutoGen, Amazon Bedrock Agents, Google Vertex AI Agent Builder 등—는 런타임에서 동적으로 툴을 선택하고 호출한다. 이 과정에서 에이전트는 자신이 호출하는 각 서비스의 신뢰 컨텍스트를 암묵적으로 상속한다.

NIST의 AI 리스크 관리 프레임워크(AI RMF)는 AI 시스템의 신뢰성(Trustworthiness)을 논의하지만, 기존 클라우드 인프라와 AI 에이전트가 신뢰를 동적으로 교환하는 시나리오에 대한 구체적 가이드라인은 아직 충분히 성숙하지 않은 상태로 보인다.

실무에서 이 문제가 어떻게 나타나는지 세 가지 패턴으로 정리할 수 있다.

패턴 1: 서비스 계정 신뢰의 전이(Transitive Trust)

AI 에이전트 A가 서비스 계정 X의 권한으로 실행된다. 서비스 계정 X는 데이터 파이프라인 서비스 B를 신뢰한다. 서비스 B는 다시 로깅 서비스 C에 쓰기 권한을 가진다. 에이전트 A는 직접 C에 접근할 권한이 없지만, 이 전이 체인을 통해 사실상 C에 데이터를 기록할 수 있다. 이 경로는 어떤 IAM 정책 문서에도 명시적으로 표현되어 있지 않다.

패턴 2: 벤더 기본값이 만드는 신뢰 확장

주요 클라우드 벤더들의 AI 서비스는 기본 설정으로 광범위한 권한을 요청하는 경향이 있다. AWS Bedrock Agents의 기본 실행 역할은 여러 서비스에 걸친 읽기 권한을 포함하며, 많은 팀이 이를 검토 없이 그대로 사용한다. 이 "기본값 신뢰"는 배포 당시에는 문제처럼 보이지 않지만, 에이전트가 더 많은 툴을 통합할수록 노출 면적이 기하급수적으로 늘어난다.

패턴 3: 세션 컨텍스트를 통한 신뢰 재활성화

AI 에이전트가 세션 메모리나 임베딩 캐시에 이전 인증 토큰이나 API 키를 저장하는 경우, 해당 세션이 종료된 후에도 그 신뢰 정보가 재사용될 가능성이 있다. 이는 앞서 논의한 "무엇이 기억되는가"의 문제와 직접 연결된다. 신뢰가 시간을 넘어 재활성화되는 것이다.

왜 기존 보안 도구는 이 문제를 잡지 못하는가

CSPM(Cloud Security Posture Management) 툴이나 SIEM(Security Information and Event Management) 시스템은 기본적으로 정적인 정책 위반을 탐지하도록 설계되어 있다. "이 서비스 계정이 허용되지 않은 리소스에 접근했는가"—이런 질문에는 잘 답한다.

그런데 AI 에이전트가 만드는 신뢰 크리프는 정책 위반이 아니다. 각각의 단계는 모두 허용된 행동이다. 에이전트가 서비스 B를 호출하는 것도 허용, 서비스 B가 서비스 C에 쓰는 것도 허용. 위반은 없다. 그러나 의도하지 않은 신뢰 경로가 만들어진다.

이것은 마치 건물 보안 시스템이 각 문의 잠금 상태는 완벽하게 모니터링하지만, 누군가가 정당한 키를 가진 사람들을 연속으로 설득해 문을 열게 하는 사회공학적 경로는 탐지하지 못하는 것과 비슷하다.

기존 거버넌스 도구가 "노드(node)"를 보는 동안, AI 에이전트는 "엣지(edge)"—즉 연결 관계—를 통해 움직인다.

AI 클라우드의 신뢰 문제가 컴플라이언스를 어떻게 위협하는가

이 문제는 보안 팀만의 걱정이 아니다. 규제 관점에서도 심각한 함의를 가진다.

GDPR, 국내 개인정보보호법, 금융권 망분리 규정 등 대부분의 컴플라이언스 프레임워크는 데이터 접근의 명시적 권한 부여를 전제로 한다. "이 시스템이 이 데이터에 접근할 수 있는 근거는 무엇인가"라는 질문에 답할 수 있어야 한다.

AI 에이전트가 전이적 신뢰 체인을 통해 특정 데이터에 접근했다면, 그 접근의 "권한 부여 근거"를 어디서 찾을 것인가? IAM 정책? 서비스 계정 설정? 오케스트레이션 레이어의 런타임 결정? 감사(audit) 로그에는 각 단계의 행동이 기록되어 있겠지만, 그 행동들이 결합해 만들어낸 의도하지 않은 접근 경로는 기록되지 않는다.

감사관이 "왜 이 AI 에이전트가 이 데이터에 접근했는가"라고 물을 때, 기술팀이 "허용된 각 단계를 따랐기 때문에"라고 답한다면—그것이 컴플라이언스 관점에서 충분한 답이 될 수 있을까.

이 문제는 AI 도입이 기업 예산을 폭파시키고 있다는 역설과도 연결된다. 비용 폭증의 이면에는 거버넌스 공백이 있고, 그 공백의 핵심에는 "신뢰가 어디서 어디로 흘렀는가"를 추적하지 못하는 구조적 문제가 있다.

실무에서 지금 당장 적용할 수 있는 세 가지 접근

1. 신뢰 그래프(Trust Graph)를 그려라

AI 에이전트가 배포된 환경에서, 그 에이전트가 직접 접근하는 서비스뿐만 아니라 간접적으로 도달할 수 있는 모든 서비스를 그래프로 시각화해야 한다. 이것은 기존 의존성 매핑과 다르다. 에이전트가 호출하는 툴이 신뢰하는 서비스, 그 서비스가 다시 신뢰하는 서비스까지 2~3단계 전이를 포함해야 한다.

AWS의 경우 IAM Access Analyzer, GCP의 경우 Policy Analyzer가 부분적으로 이 역할을 할 수 있지만, AI 오케스트레이션 레이어의 동적 툴 선택까지 커버하려면 추가적인 커스텀 모니터링이 필요할 가능성이 높다.

2. 에이전트별 최소 권한 원칙을 런타임에 적용하라

배포 시점의 IAM 설정만으로는 부족하다. AI 에이전트가 런타임에 새로운 툴을 통합할 때마다 해당 통합이 요구하는 권한이 사전 정의된 범위 안에 있는지 자동으로 검증하는 가드레일이 필요하다. 이것이 없으면, 에이전트가 새로운 커넥터를 추가할 때마다 신뢰 범위가 조용히 확장된다.

3. "신뢰 만료(Trust Expiry)" 정책을 명시적으로 설계하라

AI 에이전트가 특정 서비스와 신뢰 관계를 맺으면, 그 관계는 언제 만료되는가? 세션이 종료되면? 24시간 후? 명시적으로 해제될 때까지? 대부분의 조직에서 이 질문에 대한 답이 없다. 신뢰는 한번 부여되면 자동으로 유지된다. 이것이 세션 컨텍스트를 통한 신뢰 재활성화의 근본 원인이다.

다음 거버넌스 프레임워크가 다루어야 할 것

현재 클라우드 거버넌스 논의는 주로 "무엇이 실행되는가", "무엇이 청구되는가", "무엇이 기억되는가"에 집중되어 있다. 이것들은 모두 중요하다. 그러나 이 모든 문제의 밑바닥에는 더 근본적인 질문이 있다.

AI 에이전트가 어떤 신뢰를 상속받고, 그 신뢰를 어디까지 전달하는가—그 경로를 누가 설계했고, 누가 승인했고, 누가 감시하고 있는가.

Sam Altman이 월드코인을 통해 "인간임을 증명"하는 인프라를 구축하려는 시도—월드인증이 틴더에 들어온다는 소식에서도 볼 수 있듯—는 역설적으로 AI 시스템 안에서 "무엇이 인간의 승인을 받은 신뢰인가"를 구분하는 것이 얼마나 어려워지고 있는지를 보여준다. AI 클라우드 거버넌스의 신뢰 문제는 기술적 문제인 동시에, 점점 더 철학적 문제가 되어가고 있다.

제로 트러스트(Zero Trust) 아키텍처는 "신뢰하지 않고 항상 검증하라"는 원칙을 제시한다. 그러나 AI 에이전트가 동적으로 신뢰를 조합하는 환경에서, 제로 트러스트의 "검증"은 누가, 언제, 어떤 방식으로 수행하는가? 에이전트가 스스로 검증하는 것은 자기 참조(self-referential) 문제를 낳는다.

이 질문에 대한 답을 찾는 조직이 AI 클라우드 거버넌스의 다음 단계를 선도할 것이다. 그리고 그 답을 찾지 못한 조직은, 자신도 모르는 사이에 의도하지 않은 신뢰 경로 위에 비즈니스 크리티컬한 데이터를 올려놓고 있을 가능성이 있다.

기술이 단순히 기계가 아니라 인간의 삶을 풍요롭게 하는 도구라면, 그 도구가 우리 대신 신뢰를 결정하도록 내버려 두는 것은—적어도 지금 이 순간은—너무 이른 위임일 수 있다.

이 글에서 언급된 AI 거버넌스 프레임워크 관련 논의는 NIST AI RMF 및 각 클라우드 벤더의 공개 문서를 참고했습니다. 특정 수치나 벤더별 기본 설정은 변경될 수 있으므로, 실제 적용 시 최신 공식 문서를 반드시 확인하시기 바랍니다.

결론: 신뢰의 설계자는 누구인가

AI 클라우드가 가져온 가장 조용하고, 가장 위험한 변화는 속도나 비용이 아니다. 그것은 신뢰의 설계권이 인간에서 시스템으로 조용히 이전되고 있다는 사실이다.

우리는 지금까지 클라우드 거버넌스를 논할 때 "무엇을 실행하는가", "누가 배포했는가", "무엇이 청구되는가"를 물었다. 그리고 이 시리즈를 통해 "무엇이 기억되는가", "무엇이 살아남는가", "누가 멈출 수 있는가"까지 질문을 확장해왔다. 오늘 우리가 도달한 질문은 그 모든 것의 뿌리에 해당한다.

AI 에이전트가 상속받은 신뢰는 어디서 왔고, 어디로 가는가. 그리고 그 경로를 설계한 것은 정말 인간인가.

이 질문이 불편한 이유는, 많은 조직에서 그 답이 "아무도 설계하지 않았다"에 가깝기 때문이다. 신뢰는 편의를 위해 부여되었고, 기본값으로 유지되었으며, 에이전트를 통해 조용히 전파되었다. 누구도 명시적으로 승인하지 않은 신뢰 경로가, 지금 이 순간에도 비즈니스 크리티컬한 데이터 위를 지나고 있을 수 있다.

지금 당장 물어야 할 세 가지 질문

복잡한 프레임워크를 도입하기 전에, 오늘 당신의 조직이 먼저 답해야 할 질문이 있다.

첫째, 우리 AI 에이전트가 현재 신뢰하고 있는 서비스 목록을 뽑을 수 있는가? 런타임에서 동적으로 형성된 신뢰 관계까지 포함해서다. 정적인 아키텍처 다이어그램이 아니라, 실제로 살아있는 연결 지도 말이다. 이것을 뽑을 수 없다면, 당신은 이미 신뢰의 가시성을 잃은 것이다.

둘째, 그 신뢰 관계 중 명시적으로 승인된 것은 몇 퍼센트인가? 에이전트가 런타임에서 스스로 추가한 커넥터, 자동으로 재활성화된 세션, 기본값으로 유지된 권한—이것들을 제외하고 나면 "진짜 승인된 신뢰"는 생각보다 훨씬 좁을 것이다.

셋째, 신뢰를 만료시키는 정책이 문서화되어 있는가? 부여는 쉽고, 유지는 자동이며, 해제는 누구도 챙기지 않는다. 신뢰 만료 정책이 없다는 것은, 한번 연결된 모든 것이 영구적으로 신뢰받고 있다는 의미다.

AI 거버넌스의 다음 전선

2026년 현재, 엔터프라이즈 AI 도입은 "실험"에서 "운영"으로 전환되는 임계점을 넘고 있다. 이 전환이 의미하는 것은, 거버넌스의 실패가 더 이상 실험적 손실로 끝나지 않는다는 것이다. 운영 환경에서의 신뢰 경로 붕괴는 컴플라이언스 위반, 데이터 유출, 그리고 감사 불가능한 의사결정으로 이어진다.

AI 거버넌스의 다음 전선은 신뢰의 계보(Trust Lineage)를 추적하는 능력이다. 어떤 에이전트가, 어떤 세션에서, 어떤 권한을 어떤 경로로 상속받아, 어떤 서비스를 신뢰하게 되었는가—이 전체 계보를 사람이 읽을 수 있는 형태로 기록하고 검증하는 시스템이 필요하다. 이것은 단순한 로깅이 아니다. 로그는 "무엇이 일어났는가"를 기록하지만, 신뢰 계보는 "왜 그것이 허용되었는가"를 설명할 수 있어야 한다.

이 역량을 먼저 갖춘 조직이 AI 시대의 클라우드 거버넌스를 선도할 것이다. 그리고 그렇지 못한 조직은, 점점 더 복잡해지는 에이전트 네트워크 안에서 신뢰의 지도를 잃은 채 항해하게 될 것이다.

마지막으로, 한 가지를 기억했으면 한다.

제로 트러스트는 "아무것도 신뢰하지 말라"는 원칙이 아니다. "신뢰하기 전에 반드시 검증하라"는 원칙이다. AI 에이전트 시대에 이 원칙을 살아있게 만들려면, 검증의 주체가 에이전트 자신이 되어서는 안 된다. 검증의 권한과 책임은 여전히 인간에게—그리고 인간이 명시적으로 설계한 정책에—남아있어야 한다.

기술이 우리 대신 신뢰를 결정하는 세상은 생각보다 빠르게 오고 있다. 그 세상이 오기 전에, 우리가 먼저 신뢰의 설계자가 되어야 한다.

이 글은 AI 클라우드 거버넌스 시리즈의 일부입니다. 이전 글에서 다룬 실행, 청구, 기억, 정지, 아키텍처 설계 권한에 이어, 이번 편은 AI 에이전트의 신뢰 상속과 전파 문제를 다루었습니다. 다음 편에서는 신뢰 계보 추적을 위한 실질적인 기술 접근법을 살펴볼 예정입니다.

NIST AI RMF, CSA AI Safety Working Group, 및 각 클라우드 벤더의 공개 거버넌스 문서를 참고했습니다. 특정 기능 및 기본 설정은 벤더 업데이트에 따라 변경될 수 있으므로, 실제 적용 시 최신 공식 문서를 확인하시기 바랍니다.

NOCODE TECH STACKER