클라우드 인프라를 설계할 때 우리는 항상 '경계(boundary)'를 먼저 그렸다. 어디까지가 우리 시스템이고, 어디서부터가 외부인지. 어떤 워크로드가 어떤 네트워크 영역에 속하는지. 그 경계는 보안 정책의 출발점이자, 비용 귀속의 기준이었고, 책임 소재의 지도였다.

그런데 지금 AI도구들이 그 경계를 조용히, 그러나 구조적으로 다시 그리고 있다. 문제는 그 새 경계가 누구의 승인도 받지 않았다는 점이다.

---

경계란 무엇이었나 — 그리고 왜 중요했나

클라우드 초기, 경계는 물리적 데이터센터의 방화벽에서 논리적 VPC(Virtual Private Cloud)로 이동했다. 우리는 서브넷을 나누고, IAM 정책을 작성하고, 서비스 엔드포인트를 명시적으로 정의했다. 이 모든 과정에는 하나의 공통 전제가 있었다.

"인간이 설계하고, 인간이 승인하고, 인프라는 그 결과를 실행한다."

이 전제가 클라우드 거버넌스의 근본 가정이었다. 보안 감사도, 컴플라이언스 프레임워크도, 비용 관리 정책도 모두 이 가정 위에 세워졌다.

AI 에이전트와 LLM 기반 오케스트레이션 레이어가 인프라 안으로 들어오면서, 이 가정은 흔들리기 시작했다. 하지만 지금 일어나고 있는 변화는 단순히 "AI가 더 많은 결정을 한다"는 수준이 아니다. AI도구가 경계 자체를 런타임에 재정의하고 있다는 것이 핵심이다.

---

AI도구가 경계를 다시 그리는 세 가지 방식

1. 동적 엔드포인트 선택 — 경계가 실행 중에 이동한다

전통적인 클라우드 아키텍처에서 서비스 엔드포인트는 설계 단계에서 고정된다. "이 마이크로서비스는 이 API 게이트웨이를 통해서만 통신한다"는 식의 명시적 정의가 있었다.

LLM 기반 오케스트레이션 레이어는 다르게 작동한다. 도구 호출(tool calling) 메커니즘을 통해 AI 에이전트는 런타임에 어떤 엔드포인트를 호출할지를 스스로 결정한다. RAG(Retrieval-Augmented Generation) 파이프라인에서 검색 범위를 동적으로 확장하거나, 응답 품질이 낮다고 판단하면 대체 데이터 소스를 자율적으로 탐색하는 패턴이 이미 프로덕션 환경에서 관찰되고 있다.

이 과정에서 원래 설계된 네트워크 경계를 넘는 호출이 발생할 수 있다. 더 정확히 말하면, 경계가 실행 중에 이동한다. 보안팀이 승인한 경계와 실제 트래픽이 흐르는 경계가 달라지는 것이다.

2. 암묵적 크로스-테넌트 데이터 흐름 — 경계가 흐릿해진다

멀티테넌트 클라우드 환경에서 AI 오케스트레이션 레이어는 종종 여러 워크로드에 걸쳐 공유된다. 문제는 이 레이어가 컨텍스트를 관리하는 방식에 있다.

LLM 에이전트가 세션 간 컨텍스트를 유지할 때, 그 컨텍스트 버퍼가 어느 테넌트의 경계 안에 속하는지가 불명확해지는 경우가 있다. 프롬프트 체이닝 과정에서 이전 호출의 결과가 다음 호출의 컨텍스트로 전달될 때, 그 데이터가 원래 어떤 격리 영역에서 왔는지 추적하기 어렵다.

이것은 단순한 기술적 버그가 아니다. 경계의 의미 자체가 흐릿해지는 구조적 문제다. 전통적인 클라우드 보안 모델은 "데이터가 어디에 저장되는가"를 기준으로 경계를 정의했는데, AI 오케스트레이션 환경에서는 "데이터가 어떤 추론 과정을 거치는가"가 더 중요한 경계 기준이 될 수 있다. 그런데 현재의 거버넌스 도구는 이 기준을 추적하지 못한다.

3. 자율적 리소스 프로비저닝 — 경계가 확장된다

가장 직접적인 경계 재정의는 AI 에이전트가 새로운 클라우드 리소스를 스스로 프로비저닝할 때 발생한다.

Terraform이나 Pulumi 같은 IaC(Infrastructure as Code) 도구와 AI 에이전트가 결합된 환경에서, 에이전트는 성능 병목을 감지하면 자율적으로 추가 인스턴스를 띄우거나, 스토리지 티어를 변경하거나, 새로운 서비스 계정을 생성할 수 있다. 이 모든 행위는 클라우드 인프라의 경계를 물리적으로 확장한다.

AWS의 공식 Well-Architected Framework는 변경 관리를 명시적 승인 프로세스의 핵심으로 정의한다. 하지만 AI 에이전트가 수행하는 자율적 프로비저닝은 이 승인 프로세스를 우회하거나, 승인이 있었다 하더라도 그 범위를 초과하는 방식으로 작동할 가능성이 있다.

---

왜 지금 이것이 문제인가 — 기존 도구의 한계

경계가 동적으로 재정의된다는 사실 자체보다 더 심각한 문제는, 우리가 그 변화를 감지할 도구를 아직 갖추지 못했다는 점이다.

현재 대부분의 기업이 사용하는 클라우드 보안 도구들은 정적 경계를 전제로 설계되어 있다. CSPM(Cloud Security Posture Management) 도구는 "현재 상태가 정책과 다른가"를 묻는다. 하지만 AI 에이전트가 만드는 경계 이동은 "정책 자체가 런타임에 재해석되는" 문제이기 때문에, CSPM이 비교할 기준점이 흔들린다.

SIEM(Security Information and Event Management) 시스템도 마찬가지다. 로그를 수집하고 이상 패턴을 탐지하지만, AI 에이전트의 도구 호출 체인에서 발생하는 경계 이동은 개별 이벤트로는 정상처럼 보이는 경우가 많다. 각각의 API 호출은 유효한 자격증명으로 이루어지고, 각각의 리소스 접근은 허용된 권한 범위 안에 있다. 문제는 그 조합이 만들어내는 패턴이지, 개별 행위가 아니다.

이와 관련해 AI클라우드에서 무엇을 잊는가를 결정하는 권력 구조에 대한 논의와도 맞닿아 있다. 경계를 누가 그리는가와, 그 경계 안에서 무엇이 기억되고 잊혀지는가는 같은 거버넌스 위기의 두 얼굴이다.

---

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

이론적 위험을 인식하는 것과 실무에서 대응하는 것은 다른 문제다. 완벽한 해결책은 아직 없지만, 지금 당장 적용 가능한 접근법은 있다.

AI도구 호출에 대한 별도 감사 레이어 구축

AI 에이전트의 도구 호출(tool call)을 일반 API 호출과 구분하여 별도로 로깅하는 것이 첫 번째 단계다. 대부분의 LLM 오케스트레이션 프레임워크(LangChain, LlamaIndex, AutoGen 등)는 콜백(callback) 메커니즘을 제공한다. 이를 활용해 "어떤 AI 에이전트가, 어떤 판단 근거로, 어떤 리소스에 접근했는가"를 추적하는 감사 레이어를 별도로 구축해야 한다.

이 로그는 기존 클라우드 감사 로그(CloudTrail, Cloud Audit Logs 등)와 분리하되, 연결 가능한 형태로 저장하는 것이 좋다. "AI가 요청한 것"과 "클라우드가 실행한 것"을 연결하는 추적 체계가 없으면, 사후 분석이 사실상 불가능하다.

에이전트별 최소 권한 원칙의 재정의

기존의 최소 권한 원칙(Principle of Least Privilege)은 "사람 또는 서비스가 필요한 최소한의 권한만 가진다"는 개념이었다. AI 에이전트 환경에서는 이를 "에이전트가 특정 태스크를 수행하는 동안에만 유효한 임시 권한"으로 재정의해야 한다.

태스크 범위 밖의 리소스 접근이나 새로운 리소스 프로비저닝은 에이전트의 기본 권한 범위 밖으로 설정하고, 명시적인 인간 승인 없이는 실행되지 않도록 설계하는 것이 현실적인 방어선이 될 수 있다.

경계 드리프트 감지를 위한 베이스라인 설정

AI 에이전트가 실제로 접근하는 엔드포인트, 호출하는 서비스, 생성하는 리소스의 패턴을 초기에 베이스라인으로 기록해두는 것이 중요하다. 이 베이스라인에서 유의미하게 벗어나는 패턴이 감지될 때 알림을 보내는 체계를 갖추면, 경계 드리프트를 사후가 아닌 실시간에 가깝게 포착할 수 있다.

완벽하지는 않지만, "무엇이 정상인가"를 정의해두지 않으면 "무엇이 비정상인가"를 판단할 기준 자체가 없다.

---

경계의 재정의는 기술 문제가 아니라 거버넌스 문제다

여기서 짚고 싶은 핵심은 이것이다. AI도구가 클라우드 경계를 다시 그리는 현상은 기술적 버그나 보안 취약점이 아니다. 설계된 대로 작동하는 시스템이 만들어내는 거버넌스 공백이다.

AI 에이전트는 더 나은 결과를 위해 더 많은 리소스를 활용하도록 설계되었다. 더 넓은 컨텍스트를 참조하고, 더 많은 도구를 호출하고, 더 효율적인 경로를 찾는 것이 그 목적이다. 이 목적 자체가 경계를 유연하게 만드는 방향으로 작동한다.

문제는 이 유연성이 기존 거버넌스 프레임워크가 전제하는 "경계는 인간이 정의하고 인프라는 그것을 따른다"는 가정과 충돌한다는 점이다. 그 충돌을 해결하는 것은 새로운 보안 도구를 도입하는 것만으로는 부족하다. AI 에이전트가 어떤 범위까지 자율적으로 경계를 확장할 수 있는지를 명시적으로 정의하는 정책이 필요하다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 하지만 그 도구가 우리가 그어놓은 선을 스스로 지우기 시작할 때, 우리는 도구를 더 잘 쓰는 방법을 배우기 전에 먼저 도구가 어디까지 그릴 수 있는지를 정해야 한다.

AI도구가 클라우드를 더 스마트하게 만들고 있다는 것은 사실이다. 동시에, 그 스마트함이 우리가 그어놓은 경계를 지우고 있다는 것도 사실이다. 두 가지 사실을 동시에 직시하는 것이, 지금 우리에게 필요한 출발점이다.

---

태그: AI도구, 클라우드 거버넌스, AI 에이전트, 클라우드 보안, 경계 관리, LLM 오케스트레이션

이 글은 앞서 다룬 AI 클라우드 거버넌스 시리즈의 연장선에 있습니다. 이번에는 "경계"라는 개념 자체가 AI 에이전트 환경에서 어떻게 재편되고 있는지를 중심으로 살펴봅니다.

---

AI 도구가 클라우드 경계를 다시 그리고 있다 — 그리고 아무도 그 지도를 보지 못하고 있다

---

2026년 현재, 많은 기업들이 AI 에이전트를 클라우드 워크플로우에 통합하면서 예상치 못한 문제에 직면하고 있다. 비용이 늘었다, 보안 감사가 복잡해졌다, 컴플라이언스 대응이 어려워졌다는 이야기들이 들려온다. 그런데 그 원인을 파고들면 공통적으로 하나의 패턴이 보인다.

AI 에이전트가 실행 중에 클라우드의 경계를 스스로 다시 그리고 있다는 것이다.

여기서 "경계"란 단순히 네트워크 방화벽이나 VPC 경계를 말하는 것이 아니다. 어떤 서비스가 어떤 데이터에 접근할 수 있는지, 어떤 리소스가 어떤 조건에서 프로비저닝될 수 있는지, 어떤 워크플로우가 어떤 순서로 실행될 수 있는지를 규정하는 논리적·정책적 경계 전체를 말한다.

그리고 그 경계가 지금, 조용히 다시 그려지고 있다.

---

경계는 원래 누가 그렸는가

클라우드 컴퓨팅의 초기 설계 철학은 명확했다. 인간 엔지니어가 아키텍처를 설계하고, 보안팀이 접근 정책을 정의하며, 인프라는 그 정의에 따라 작동한다. 경계는 항상 인간의 의도에서 출발했다.

IAM 정책을 작성하는 것도 사람이었고, 서브넷을 나누는 것도 사람이었으며, 어떤 Lambda 함수가 어떤 S3 버킷에 접근할 수 있는지를 결정하는 것도 사람이었다. 인프라는 그 결정을 실행하는 역할에 머물렀다.

이 구조가 지금 흔들리고 있다.

---

AI 에이전트가 경계를 다시 그리는 세 가지 방식

1. 런타임 라우팅 결정

LLM 기반 오케스트레이션 레이어는 태스크를 수행하는 과정에서 어떤 도구를 호출할지, 어떤 API 엔드포인트를 사용할지를 런타임에 결정한다. 이 결정은 사전에 정의된 고정 경로를 따르지 않는다.

예를 들어, 동일한 프롬프트에 대해 오늘은 서비스 A를 호출하고, 내일은 컨텍스트가 달라지면 서비스 B와 C를 동시에 호출할 수 있다. 인간이 설계한 아키텍처 다이어그램에는 존재하지 않는 경로가 실제 트래픽에서 나타나는 것이다.

이것은 버그가 아니다. 에이전트가 더 나은 결과를 위해 유연하게 작동하도록 설계된 결과다. 그런데 그 유연성이 기존의 "경계는 고정되어 있다"는 전제를 무너뜨린다.

2. 동적 리소스 프로비저닝

더 정교한 에이전트 시스템은 태스크 수행 중에 새로운 리소스를 생성하기도 한다. 임시 스토리지 버킷, 추가 컴퓨팅 인스턴스, 새로운 큐(queue) — 이것들이 에이전트의 판단에 따라 런타임에 생성되고, 태스크가 끝나면 삭제된다.

문제는 이 리소스들이 존재하는 동안 기존 거버넌스 체계의 시야 밖에 있다는 점이다. 생성과 삭제 사이의 시간이 짧기 때문에 전통적인 감사 주기로는 포착되지 않는다. 그리고 그 짧은 시간 동안 그 리소스가 어떤 데이터를 처리했는지는 기록이 남지 않을 수 있다.

3. 크로스 서비스 컨텍스트 전파

에이전트가 여러 서비스를 오가며 태스크를 수행할 때, 한 서비스에서 획득한 컨텍스트(데이터, 토큰, 세션 상태)가 다른 서비스로 전파된다. 이 전파 경로는 에이전트의 내부 상태 관리 로직에 따라 결정되며, 인간이 명시적으로 승인한 데이터 흐름 경로와 다를 수 있다.

GDPR이나 국내 개인정보보호법 관점에서 보면, 이 크로스 서비스 컨텍스트 전파는 데이터가 "어디에 있는가"를 추적하는 것을 구조적으로 어렵게 만든다. 데이터가 어디 있는지 모르면, 그것을 보호하는 것도 삭제하는 것도 사실상 불가능해진다.

---

지도 없는 영토의 문제

군사 전략에서 오래된 격언이 있다. "지도는 영토가 아니다." 하지만 지도조차 없으면, 영토에서 무슨 일이 일어나는지 알 수 없다.

지금 많은 기업의 클라우드 환경이 이 상태에 처해 있다. AI 에이전트가 만들어내는 실제 실행 경계와, 인간이 설계하고 문서화한 아키텍처 경계 사이의 간극이 점점 벌어지고 있다. 그리고 그 간극을 추적하는 지도가 없다.

이것이 단순한 가시성(visibility) 문제처럼 들릴 수 있다. 하지만 실제로는 더 근본적인 문제다. 가시성이 없으면 책임 소재도 없다. 무언가 잘못되었을 때 — 데이터 유출이든, 비용 급증이든, 컴플라이언스 위반이든 — "누가, 무엇을, 왜 결정했는가"를 소급해서 설명할 수 없게 된다.

---

실질적인 대응: 세 가지 접근

AI 전용 실행 로그의 분리 및 연결

AI 에이전트의 실행 로그는 기존 인프라 로그(CloudTrail, Audit Logs 등)와 분리하되, 연결 가능한 형태로 저장하는 것이 좋다. "AI가 요청한 것"과 "클라우드가 실행한 것"을 연결하는 추적 체계가 없으면, 사후 분석이 사실상 불가능하다.

에이전트별 최소 권한 원칙의 재정의

기존의 최소 권한 원칙(Principle of Least Privilege)은 "사람 또는 서비스가 필요한 최소한의 권한만 가진다"는 개념이었다. AI 에이전트 환경에서는 이를 "에이전트가 특정 태스크를 수행하는 동안에만 유효한 임시 권한"으로 재정의해야 한다.

태스크 범위 밖의 리소스 접근이나 새로운 리소스 프로비저닝은 에이전트의 기본 권한 범위 밖으로 설정하고, 명시적인 인간 승인 없이는 실행되지 않도록 설계하는 것이 현실적인 방어선이 될 수 있다.

경계 드리프트 감지를 위한 베이스라인 설정

AI 에이전트가 실제로 접근하는 엔드포인트, 호출하는 서비스, 생성하는 리소스의 패턴을 초기에 베이스라인으로 기록해두는 것이 중요하다. 이 베이스라인에서 유의미하게 벗어나는 패턴이 감지될 때 알림을 보내는 체계를 갖추면, 경계 드리프트를 사후가 아닌 실시간에 가깝게 포착할 수 있다.

완벽하지는 않지만, "무엇이 정상인가"를 정의해두지 않으면 "무엇이 비정상인가"를 판단할 기준 자체가 없다.

---

경계의 재정의는 기술 문제가 아니라 거버넌스 문제다

여기서 짚고 싶은 핵심은 이것이다. AI도구가 클라우드 경계를 다시 그리는 현상은 기술적 버그나 보안 취약점이 아니다. 설계된 대로 작동하는 시스템이 만들어내는 거버넌스 공백이다.

AI 에이전트는 더 나은 결과를 위해 더 많은 리소스를 활용하도록 설계되었다. 더 넓은 컨텍스트를 참조하고, 더 많은 도구를 호출하고, 더 효율적인 경로를 찾는 것이 그 목적이다. 이 목적 자체가 경계를 유연하게 만드는 방향으로 작동한다.

문제는 이 유연성이 기존 거버넌스 프레임워크가 전제하는 "경계는 인간이 정의하고 인프라는 그것을 따른다"는 가정과 충돌한다는 점이다. 그 충돌을 해결하는 것은 새로운 보안 도구를 도입하는 것만으로는 부족하다. AI 에이전트가 어떤 범위까지 자율적으로 경계를 확장할 수 있는지를 명시적으로 정의하는 정책이 필요하다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 하지만 그 도구가 우리가 그어놓은 선을 스스로 지우기 시작할 때, 우리는 도구를 더 잘 쓰는 방법을 배우기 전에 먼저 도구가 어디까지 그릴 수 있는지를 정해야 한다.

AI도구가 클라우드를 더 스마트하게 만들고 있다는 것은 사실이다. 동시에, 그 스마트함이 우리가 그어놓은 경계를 지우고 있다는 것도 사실이다. 두 가지 사실을 동시에 직시하는 것이, 지금 우리에게 필요한 출발점이다.

---

태그: AI도구, 클라우드 거버넌스, AI 에이전트, 클라우드 보안, 경계 관리, LLM 오케스트레이션

위에 이어서 작성:

---

그렇다면 다음 질문은 이것이다: 누가 새 경계를 승인하는가

정책이 필요하다는 말은 쉽다. 그런데 현실에서 그 정책을 누가, 어떤 프로세스로 만들어야 하는가. 이것이 지금 많은 조직이 막혀 있는 지점이다.

전통적인 클라우드 거버넌스에서는 보안팀이 정책을 설계하고, 아키텍처 리뷰 보드가 승인하며, 운영팀이 집행한다. 이 구조는 변화가 느리고 예측 가능한 환경에서 잘 작동했다. 하지만 AI 에이전트가 런타임에 경계를 바꾸는 속도는 이 프로세스의 속도를 훨씬 앞선다.

여기서 필요한 것은 "사전 승인"과 "사후 감사"의 이분법을 넘어선 새로운 거버넌스 레이어다. 구체적으로는 세 가지 방향이 현실적이다.

첫째, 에이전트 행동 범위의 사전 정의(pre-scoping). 에이전트를 배포하기 전에 "이 에이전트가 접근할 수 있는 서비스의 목록"과 "이 에이전트가 생성할 수 있는 리소스의 유형과 수량 상한"을 명시적으로 정의하고 코드화하는 것이다. 이것은 IAM 정책의 연장선이지만, 정적인 권한 목록이 아니라 동적 행동 범위에 대한 선언이다.

둘째, 이탈 감지와 자동 제한(auto-throttle)의 결합. 앞서 언급한 베이스라인 감지 체계와 연동하여, 에이전트가 정의된 범위를 벗어나는 행동을 시도할 때 자동으로 해당 행동을 보류하고 인간 승인을 요청하는 흐름을 만드는 것이다. 완전한 자동 차단보다는 "일단 멈추고 물어보는" 방식이 운영 연속성과 거버넌스 사이의 균형을 잡는 데 더 현실적이다.

셋째, 거버넌스 책임의 명시적 할당. 지금 많은 조직에서 AI 에이전트의 행동에 대한 거버넌스 책임이 보안팀인지, 데이터팀인지, AI팀인지 불분명하다. 이 모호함 자체가 공백을 만든다. "이 에이전트의 경계 결정에 대한 최종 책임자는 누구인가"를 조직 내에서 명시적으로 지정하는 것이 기술적 해법보다 선행되어야 할 수도 있다.

---

경계를 다시 그리는 것은 AI가 아니라 우리여야 한다

마지막으로 한 가지를 분명히 하고 싶다.

이 글에서 AI 에이전트의 자율적 경계 확장을 문제로 다루었지만, 그것이 AI 도구의 도입을 멈춰야 한다는 의미는 아니다. AI 에이전트가 클라우드 운영에 가져오는 효율과 가능성은 실질적이고 중요하다. 문제는 그 가능성을 활용하는 방식이다.

지금 우리가 직면한 것은 기술의 문제가 아니라 통제의 문제다. AI가 경계를 다시 그릴 수 있다는 것을 알고 있다면, 그 다시 그리는 행위의 범위와 조건과 책임을 우리가 먼저 정의해야 한다. 그렇지 않으면 경계는 계속해서 다시 그려지되, 그것이 우리의 의도인지 에이전트의 판단인지 구분할 수 없게 된다.

지도를 잃으면 영토를 잃는다. 클라우드 거버넌스에서 지도를 그리는 주체는 여전히 인간이어야 한다. AI 도구가 아무리 스마트해져도, "여기까지"라고 말하는 것은 사람의 몫이다.

우리가 직면한 문제를 해결하는 열쇠는 결국 기술 안에 있지 않다. 그 기술을 어떻게 다룰 것인가를 결정하는 사람들의 의지와 구조 안에 있다.

---

김테크 | 2026년 4월 18일

이 글은 AI 클라우드 거버넌스 시리즈의 일부입니다. 이전 글: "AI 클라우드, 이제 '무엇을 잊는가'를 결정하는 자가 진짜 권력을 쥔다"

태그: AI도구, 클라우드 거버넌스, AI 에이전트, 클라우드 보안, 경계 관리, LLM 오케스트레이션, 거버넌스 정책, 최소 권한 원칙