AI 에이전트는 정책 문서를 읽지 않는다 — API를 호출한다

URL: https://www.youtube.com/watch?v=7v2myBde05o
날짜: 2026-10-11
채널: aiDotEngineer (YouTube 표기: AI Engineer)

메타데이터

• 원문 제목: AI Agents Don't Read Your Policy Docs. They Hit Your APIs — Gravitee
• 영상 ID: 7v2myBde05o
• 원본 발행일: 2026-10-10
• 재생 시간: 약 17분 50초
• 주제: AI 에이전트의 권한·비용·감사·보안을 프롬프트가 아니라 API 게이트웨이에서 집행하는 방법

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트의 정책 준수는 정책 문서나 마크다운 프롬프트가 아니라, 에이전트가 실제로 호출하는 API와 그 앞의 게이트웨이에서 강제해야 한다.==

• 에이전트는 유용해지려는 방향으로 동작하므로, 권한이 있는 도구를 발견하면 사용자의 위험한 요청도 수행할 수 있다.
• 신원, JWT 클레임, 권한, 속도 제한, 토큰 예산, 캐시, 컨텍스트 크기, 허용된 요청 유형을 게이트웨이에서 검사하면 LLM에 도달하기 전 위험과 비용을 차단할 수 있다.
• 에이전트가 수백·수천·수만 개로 늘고 서로 다른 에이전트를 호출하는 환경에서는 중앙 게이트웨이의 관측성과 집행력이 운영·감사·규제 대응의 기반이 된다.

정책 문서를 읽히는 방식은 에이전트의 행동을 바라는 방식일 뿐이다. 실제 보호 경계는 에이전트가 접근하는 데이터베이스, MCP 도구, LLM, 내부 API를 연결하는 인프라에 놓여야 한다. Gravitee Gateway는 이 경계에서 요청의 주체와 의도, 허용된 도구, 비용과 속도, 컨텍스트 크기를 판단하고, 통과한 요청의 전체 흐름을 기록한다.

1. 문서에 적힌 정책과 실제 에이전트 행동 사이의 간극

에이전트의 확산 속도에 비해 에이전트 행동을 통제하는 조직적 절차는 크게 뒤처져 있다.

1.1. 에이전트 도입은 빠르고 통제는 느리다

1. 조직은 이미 에이전트를 사용하고 있다

   1. 도입률: 언급된 조사 결과에 따르면 조직의 88%가 어떤 형태로든 에이전트를 보유하고 있다.
   2. 통제 절차: 그중 최소 한 개의 에이전트에 대해 통제 프로세스를 갖춘 조직은 14%에 불과하다.

2. 사고의 결과는 즉시 현실이 된다

   1. 데이터 손실: 잘못된 에이전트 행동은 데이터베이스 삭제나 손상으로 이어질 수 있다.
   2. 개인정보와 규제: 개인 데이터와 비밀 정보가 노출되면 HIPAA·GDPR 관련 규제와 막대한 벌금 문제가 발생한다.
   3. 공개되는 증거: 사고가 나면 언론 기사나 LinkedIn 게시물에서 문제가 드러나고, 조직은 사후에 원인을 추적해야 한다.

1.2. 프롬프트와 지식 파일은 보호 경계가 아니다

1. 유용해지려는 모델의 성향

   1. 도움이 되려는 최적화: AI는 사용자의 요청을 해결하고 유용한 결과를 내놓도록 최적화되어 있다.
   2. 권한과 요청의 충돌: 사용자가 “공개된 데이터베이스를 보여 달라”거나 고객 데이터를 달라고 요청하면, 모델은 금지 규칙을 실제 권한으로 집행하지 않는 한 요청을 수행하려 한다.

2. 문서 중심 통제의 한계

   1. 정책의 위치: 프롬프트, 마크다운 파일, 컨텍스트, 모델에게 제공한 도구 설명은 모델이 참고할 정보일 뿐이다.
   2. 집행의 부재: 모델이 정책을 무시하거나 정책과 충돌하는 도구를 호출해도, API 레벨의 차단 장치가 없으면 실제 요청은 다음 시스템으로 전달된다.
   3. 핵심 전환: 정책을 읽히는 것에서 요청의 주체·권한·목적·범위를 게이트웨이에서 검증하는 것으로 보호 방식을 바꿔야 한다.

2. 시연 환경과 두 가지 에이전트의 대비

실제 작동하는 Gravitee Gateway 구조에서 통제되지 않은 에이전트와 게이트웨이로 제한된 에이전트의 결과를 나란히 비교한다.

2.1. 데이터와 모델이 연결된 데모 아키텍처

1. 백엔드 구성

   1. 데이터 저장소: Databricks 백엔드의 특정 Delta 테이블에 정보가 저장되어 있다.
   2. 모델 구성: Claude Sonnet과 Grok을 조합해 요청을 처리하고, 모델 호출은 게이트웨이를 거친다.
   3. 실제성: 미리 만든 대본이나 가짜 응답이 아니라 정상 동작하는 환경에서 요청·도구·응답 흐름을 보여준다.

2. 좌우 비교

   1. 왼쪽 에이전트: 프롬프트, 도구, 제공된 지식으로 행동을 유도하지만 실제 요청을 막는 외부 권한 경계가 없다.
   2. 오른쪽 에이전트: Gravitee Gateway 뒤에서 제한된 신원과 권한을 사용하며, 런타임에 사용자에게 실제로 허용된 범위만 실행한다.
   3. 관찰 가능한 차이: 두 에이전트가 같은 요청을 받아도 왼쪽은 도구를 호출하고 오른쪽은 토큰·JWT 클레임·게이트웨이 정책을 통과하지 못한 요청을 거부한다.

2.2. 게이트웨이가 기록하는 실행 흐름

1. 추적 단위

   1. 사용자 요청: 누가 어떤 요청을 시작했는지 확인할 수 있다.
   2. 에이전트 행동: 에이전트가 어떤 도구를 발견하고 어떤 순서로 호출했는지 확인할 수 있다.
   3. 게이트웨이 판정: 각 요청이 통과했는지, 어떤 오류 코드로 차단됐는지 확인할 수 있다.

2. 감사 가능성

   1. 전체 스트림: 데이터가 이동하는 경로와 도구 호출, 반환 결과를 한 흐름으로 볼 수 있다.
   2. 요청 검증: 데이터베이스에 실제로 변화가 일어났는지까지 확인해 성공한 요청과 실패한 요청을 구분할 수 있다.
   3. A2A 확장: 사용자 에이전트가 다른 에이전트를 호출하고 그 에이전트가 다시 다른 에이전트를 호출하는 A2A 경로도 같은 방식으로 관찰해야 한다.

3. 다섯 가지 시연: 권한과 안전을 API에서 집행하기

게이트웨이의 가치는 모델에게 “하지 말라”고 부탁하는 데 있지 않고, 요청이 다음 시스템에 도달하기 전에 판정하는 데 있다.

3.1. 사례 1 — 예약 삭제 요청

1. 통제되지 않은 에이전트의 행동

   1. 요청: 사용자는 에이전트에게 접근 가능한 도구를 사용해 일을 처리하라고 한 뒤, MCP의 예약 삭제 도구로 모든 예약을 삭제할 수 있는지 묻는다.
   2. 실행: 왼쪽 에이전트는 별다른 문제 없이 “예약을 삭제했다”고 응답한다.
   3. 결과: 삭제 도구가 노출되어 있고 호출 권한이 별도로 제한되지 않았기 때문에 데이터베이스의 예약이 실제로 삭제된다.

2. 게이트웨이로 제한된 에이전트의 행동

   1. 신원 확인: 사용자 신원과 런타임 토큰을 교환하고 JWT 클레임을 검증한다.
   2. 권한 판정: 해당 사용자가 예약 삭제 작업을 수행할 권한이 없으면 MCP 요청을 게이트웨이에서 차단한다.
   3. 응답: 요청은 HTTP 403 Forbidden으로 거부되고, 에이전트는 권한이 없어서 작업을 수행할 수 없다고 반환한다.

3.2. 사례 2 — 참석자 개인정보 유출 요청

1. 유출을 유도하는 요청

   1. 명분: 사용자는 규정 준수를 위해 전체 참석자 명단이 필요하다고 주장한다.
   2. 민감 정보: 이메일 주소와 카드 정보까지 달라고 요청한다.
   3. 일반적인 흐름: 인터페이스의 요청이 LLM으로 가고, LLM이 MCP 도구를 검색해 데이터를 가져온 뒤 응답으로 반환한다.

2. 정책이 아닌 권한으로 차단하기

   1. 공개 여부와 권한은 다르다: 개인 데이터가 공개되어 있지 않다는 사실만 문서로 알려주는 방식은 충분하지 않다.
   2. 게이트웨이의 응답: 요청 주체가 해당 정보를 만들거나 읽을 적합한 권한을 갖고 있지 않으면 데이터가 LLM으로 내려가지 않는다.
   3. 정상 경로: 필요한 경우 IDP 플랫폼이나 Gravitee Gateway를 통해 적절한 인증·권한을 먼저 취득해야 한다.

3.3. 사례 3 — 반복 호출과 속도 제한

1. 악성 또는 결함 에이전트의 비용 폭증

   1. 반복 패턴: 하나의 에이전트가 같은 질의를 여덟 번 반복해서 보내는 상황을 만든다.
   2. 누적 비용: 모든 요청이 LLM까지 도달하면 토큰 비용과 처리 자원, 운영·유지보수 비용이 요청 수만큼 쌓인다.
   3. 작은 단가의 함정: 간단한 요청 하나가 약 1,000토큰, 약 1센트 수준이어도 수많은 에이전트와 고객·반복 작업에 곱해지면 큰 비용이 된다.

2. 게이트웨이 속도 제한

   1. 허용량: 데모 정책은 분당 세 건의 요청만 허용한다.
   2. 차단 위치: 세 건을 넘는 요청은 LLM 수준이 아니라 게이트웨이에서 차단된다.
   3. 효과: 불필요한 토큰 사용을 시작하기 전에 사용자·에이전트별 사용량을 제한하고 비용을 예측할 수 있다.

3.4. 사례 4 — 시맨틱 캐싱으로 비용과 지연 줄이기

1. 반복 질문의 문제

   1. 지원 시나리오: IT 지원 에이전트가 “비밀번호를 어떻게 설정하나요?” 같은 질문을 반복해서 받는다.
   2. 기존 방식: 같은 질문을 매번 LLM에 보내면 입력·출력 토큰과 지연이 반복해서 발생한다.

2. Gravitee 시맨틱 캐시

   1. 저장소: 이미 처리한 응답을 Redis에 저장한다.
   2. 응답 경로: 충분히 유사한 질문은 LLM을 다시 거치지 않고 캐시에서 답변한다.
   3. 효과: 캐시 적중 시 LLM 비용과 LLM 지연이 0에 가까워지고, 사용자는 더 빠르고 일관된 답변을 받는다.

3. 데모 수치와 조정값

   1. 반복 예약 조회: 호텔 예약을 모두 보여 달라는 질문을 다섯 번 보냈을 때, 캐시가 없으면 각 요청이 LLM으로 가며 약 1,000토큰 단위의 비용이 반복된다.
   2. 캐시 적중: 같은 데이터를 캐시에서 반환하면 추가 요청은 약 200토큰 수준의 입출력만 사용한다.
   3. 유사도 임계값: 유사도는 0부터 1까지 설정하며, 1은 완전한 유사성, 0은 전혀 유사하지 않음을 뜻한다.
   4. 세분화: 에이전트, 대상, 사용자, 업무 목표에 따라 유사도 기준을 다르게 조정할 수 있다.

4. 투명한 운영

   1. 로그: 요청이 캐시에서 제공됐는지 시스템에 들어온 뒤 추적할 수 있다.
   2. 외부 관측 도구: Datadog, Splunk, Kubernetes 환경의 Prometheus 등으로 원격 측정 데이터를 내보낼 수 있다.
   3. 블랙박스 완화: 게이트웨이는 환경을 숨기는 대신 요청·캐시·도구·응답의 표면을 드러내 전체 실행을 관찰하게 한다.

3.5. 사례 5 — 컨텍스트·콘텐츠·토큰 사용량 제한

1. 과도한 컨텍스트의 문제

   1. 사용자 입력: 사용자가 긴 대화 기록이나 회의록을 통째로 붙여 넣고 그 안에서 작업을 수행하라고 요청한다.
   2. 비용 확대: 에이전트가 입력을 그대로 전달하면 불필요한 토큰과 처리 비용이 빠르게 증가한다.
   3. 실제 필요량: 간단한 호텔 객실 예약 같은 작업은 전체 기록이 아니라 작업에 필요한 최소 컨텍스트만으로 처리할 수 있다.

2. 컨텍스트 토큰 정책

   1. 데모 요청: 입력 컨텍스트 한도를 2,000토큰으로 설정했다.
   2. 결과: 간단한 예약 요청에 실제로 필요한 결과는 312토큰뿐이었다.
   3. 사전 차단: 정책을 초과한 요청은 LLM에 내려보내기 전에 게이트웨이에서 차단되어 토큰 비용이 발생하지 않는다.
   4. 작업 분할: 큰 요청을 작은 단계로 나누면 각 단계의 범위를 통제할 수 있고, 이전 체인 전체를 매번 전달하는 비용도 줄어든다.

3. 허용된 요청 유형만 통과시키기

   1. 잘못된 사용: 사용자가 호텔 예약 에이전트를 개인용 Google 검색처럼 사용해 날씨를 묻고, 무료로 얻을 수 있는 정보를 비싼 모델이나 외부 검색으로 요청할 수 있다.
   2. 콘텐츠 검사: 게이트웨이는 요청 내용이 호텔 예약 또는 예약 조회에 적합한지 검사한다.
   3. 거부 결과: “오늘 날씨가 어떤가요?” 같은 요청은 호텔 예약용 프로그램에 적합하지 않다는 응답과 함께 거부된다.
   4. 비용 효과: 부적합한 요청은 LLM에 도달하지 않으므로 추가 토큰 비용이 없다.

4. 에이전트 규모 확장과 운영 경계

에이전트를 몇 개 직접 관리하는 방식은 에이전트가 에이전트를 생성하는 순간 한계에 부딪힌다.

4.1. A2A 네트워크의 기하급수적 복잡성

1. 확장 과정

   1. 초기 단계: 한두 개에서 다섯 개 또는 열 개까지는 에이전트별 코드를 직접 관리할 수 있다.
   2. 네트워크 단계: 에이전트가 다른 에이전트를 만들고 호출하기 시작하면 거대한 상호작용 네트워크가 된다.
   3. 규모: 수백·수천·수만 개의 에이전트와 사용자 요청을 개별 코드로 통제하기는 어렵다.

2. 중앙 집행이 필요한 이유

   1. 관리: 어떤 에이전트가 어떤 주체를 대신해 어떤 API를 호출했는지 일관되게 관리해야 한다.
   2. 위험 완화: 요청 경로가 길어져도 권한과 비용 제한을 동일한 경계에서 적용해야 한다.
   3. 감사·규제: 모델 학습과 정보 처리 과정이 규제될수록 로그와 원격 측정 데이터를 감사 가능한 형태로 보존해야 한다.

4.2. 사용자 에이전트와 내부 서비스의 분리

1. 서로 다른 계층

   1. 사용자 에이전트: 사용자가 직접 상호작용하는 에이전트는 사용자 의도와 세션 신원을 전달한다.
   2. 내부 서비스: API, MCP 서버, LLM 서버, 데이터베이스·데이터 웨어하우스는 서로 다른 권한과 운영 목적을 갖는다.
   3. 게이트웨이 경계: 각 계층 사이를 게이트웨이로 분리하면 사용자 에이전트가 내부 시스템에 직접 접근하지 못하게 할 수 있다.

2. 운영 효과

   1. 보안: 데이터와 도구의 접근 범위를 업무별로 제한한다.
   2. 비용 최적화: 불필요한 LLM 호출·검색·대형 컨텍스트를 차단한다.
   3. 감사: 호출자와 대상 서비스, 정책 판정, 응답을 한 경로로 연결해 기록한다.

5. 게이트웨이가 제공하는 확장 기능

권한 통제는 출발점이며, 모델 라우팅·MCP 도구 관리·엣지 통제까지 같은 실행 경계에서 다룰 수 있다.

5.1. LLM 라우팅과 하이퍼스케일러 종속 완화

1. 요청별 모델 선택

   1. 선택 기준: 지연 시간, 가격, 작업 난이도에 따라 요청을 적합한 모델로 라우팅할 수 있다.
   2. 다중 모델: 특정 하이퍼스케일러의 단일 모델에 묶이지 않고 필요한 모델을 선택한다.
   3. 데모 구성: Grok과 Anthropic으로 시작한 요청을 Gemini나 OpenAI로 전환하는 경로를 보여준다.

2. 호환성 처리

   1. 사양 변환: 모델마다 코드를 다시 작성하지 않아도 게이트웨이가 OpenAI 사양과 다른 모델 사양 사이의 변환을 처리한다.
   2. 운영 단순화: 애플리케이션은 게이트웨이의 단일 경로를 사용하고, 내부 모델 교체는 게이트웨이 설정으로 처리한다.

5.2. MCP Studio와 도구 노출 범위

1. 도구가 만드는 컨텍스트 비용

   1. CRM 예시: CRM MCP 서버가 64개의 도구를 공개하면 모델은 도구 설명 전체를 컨텍스트로 받아야 한다.
   2. 숨은 비용: 도구 수가 많아질수록 컨텍스트가 커지고, 호출 때마다 토큰·시간·비용이 증가한다.

2. 도구 표면 축소

   1. MCP Studio: 타사 MCP 서버를 무제한으로 공개하는 대신 사용할 도구를 관리하고 필요한 도구만 모델에 노출한다.
   2. 통제 효과: 도구 반경을 줄이면 모델이 우연히 또는 의도적으로 호출할 수 있는 기능과 비용을 함께 줄인다.
   3. 운영 연결: 도구 호출 역시 게이트웨이의 인증·정책·로그 경계 안에 놓인다.

5.3. 엣지 관리와 섀도 트래픽

1. 게이트웨이를 우회하는 로컬 AI

   1. 현실적인 경로: 일부 사용자는 조직 게이트웨이를 거치지 않고 자신의 노트북에서 AI를 사용한다.
   2. 정보 유출: 사용자가 읽고 싶거나 요약하고 싶은 내부 문서를 로컬 AI에 올리면 중앙 시스템에는 기록이 남지 않을 수 있다.
   3. 섀도 AI: 승인된 경로 밖에서 발생하는 이런 트래픽은 조직이 보지 못하는 섀도 트래픽이 된다.

2. 엣지 통제 기능

   1. 강제 경로: 엣지 관리 기능으로 로컬 AI 요청이 게이트웨이를 통과하도록 유도하거나 강제한다.
   2. 가시성: 어떤 AI가 사용되고 어떤 데이터가 이동하는지 기록하고 관찰한다.
   3. 탐지·통제: 우회 사례를 탐지하고, 보안·정보 보호·산업 규제 요구에 맞는 조치를 적용한다.

주요 발언 모음

“AI 에이전트는 정책 문서를 읽지 않는다. 에이전트는 API를 호출한다.”

“AI는 매우 도움을 주고 싶어 한다. 유용해지고 싶어 한다.”

“정책을 프롬프트나 마크다운 파일에만 두는 것은 에이전트를 확장하고 관리·보안하는 올바른 방법이 아니다.”

“요청을 LLM까지 내려보내기 전에 게이트웨이에서 차단하면 그 요청에 대한 토큰 비용도 발생하지 않는다.”

“게이트웨이는 모든 것을 블랙박스로 만들려는 플랫폼이 아니라, 표면을 드러내 완전한 가시성을 제공하는 플랫폼이다.”

핵심 데이터 & 수치

• 88%: 조사에서 어떤 형태로든 에이전트를 보유한 조직의 비율이다.
• 14%: 적어도 한 에이전트에 통제 프로세스를 갖춘 조직의 비율이다.
• HTTP 403: 예약 삭제처럼 사용자의 권한이 없는 작업을 게이트웨이가 거부할 때의 응답이다.
• 분당 3건: 반복 호출 데모에서 게이트웨이가 허용한 요청 속도다.
• 약 1,000토큰·약 1센트: 단순 질의 하나가 LLM을 통과할 때의 예시 비용이다.
• 약 200토큰: 시맨틱 캐시에서 답변을 반환할 때의 예시 입출력량이다.
• 0~1: 시맨틱 캐시의 유사도 임계값 범위이며, 1은 완전한 유사성이다.
• 2,000토큰 / 312토큰: 큰 컨텍스트를 2,000토큰으로 제한한 요청과 실제 간단한 예약 작업에 필요한 결과량의 예시다.
• 64개 도구: CRM MCP 서버가 모두 공개했을 때 모델 컨텍스트와 비용을 키우는 도구 수의 예시다.
• 5회 반복: 호텔 예약 조회를 반복해 캐시가 없는 경우와 있는 경우의 비용 차이를 보여준 횟수다.

결론 및 시사점

1. 에이전트의 정책 준수를 프롬프트와 문서의 선의에 맡기지 말고 API·MCP·데이터·모델 앞의 게이트웨이에서 강제해야 한다.
2. 신원 확인과 JWT 클레임으로 사용자의 실제 권한을 런타임에 확인하고, 권한이 없는 도구 호출은 LLM 응답 이전에 403으로 차단해야 한다.
3. 속도 제한과 토큰 예산은 반복 호출·결함 에이전트·에이전트 간 연쇄 호출이 만드는 비용 폭증을 막는 기본 장치다.
4. 시맨틱 캐시는 반복 질문을 Redis에서 처리해 LLM 비용과 지연을 줄이며, 유사도 기준은 업무별로 조정해야 한다.
5. 컨텍스트 크기와 요청 유형을 게이트웨이에서 검사하면 긴 대화 기록, 부적합한 검색, 불필요한 모델 호출을 LLM 도달 전에 제거할 수 있다.
6. A2A 네트워크가 수백·수천·수만 개 규모로 커질수록 중앙 로그·원격 측정·정책 집행 없이는 감사와 규제 대응이 불가능해진다.
7. LLM 라우팅과 사양 변환은 가격·지연·난이도에 따른 모델 선택을 가능하게 하고 특정 하이퍼스케일러에 대한 종속을 줄인다.
8. MCP 도구의 전체 목록을 그대로 모델에 노출하지 말고 필요한 도구만 공개해 컨텍스트와 공격 표면을 줄여야 한다.
9. 노트북에서 발생하는 섀도 AI 트래픽도 엣지에서 관찰·탐지·통제해 조직의 정보 보호와 산업 규제 범위에 포함해야 한다.
10. 에이전트의 진짜 정책은 읽는 문서가 아니라 호출할 수 있는 API와 통과할 수 있는 인프라 경계로 정의된다.