개발하는 TeEm0

1. 왜 지금 MCP 로드맵을 봐야 하나

MCP(Model Context Protocol)를 처음 붙였을 때 느낌은 대체로 비슷하다. "어, 생각보다 별거 없네." JSON-RPC 기반으로 tools/list 받아오고 tools/call 던지면 끝이다. 사내 위키 검색, Jira 티켓 조회 정도 붙이는 데는 반나절이면 충분하다.

문제는 그다음이다. 실제로 운영에 넣어보면 이런 것들이 터진다.

• Terraform plan/apply를 도구로 노출했더니 3분 넘게 걸리는 호출에서 커넥션이 끊긴다.
• 배포 승인 같은 사람 개입(human-in-the-loop)이 필요한 작업을 요청·응답 한 번으로 표현할 방법이 없다.
• 에이전트가 사내 API를 호출하는데, 그 요청의 주체가 누구인지 감사 로그에서 구분이 안 된다. 전부 서비스 계정 하나로 찍힌다.
• 팀별로 MCP 서버를 만들다 보니 툴이 300개를 넘어갔고, tools/list 응답만 수만 토큰이 되면서 모델이 엉뚱한 툴을 고르기 시작한다.

이번 MCP 로드맵이 짚은 지점이 정확히 여기다. 요약에 따르면 앞으로 수개월간 장시간 실행되는 에이전트 작업, 에이전트 신원·권한 위임, 대규모 Tool 탐색을 핵심 과제로 잡고, 요청·응답 중심 구조를 넘어 서버 주도 이벤트, Webhook·Channel, 실행 중 작업 제어를 강화하겠다는 것이다.

이건 사실상 "MCP를 RPC 라이브러리에서 분산 작업 시스템 프로토콜로 확장하겠다"는 선언이다. 우리가 지난 15년간 메시지 큐, 워크플로 엔진, OAuth 인가 서버로 풀어온 문제들이 그대로 올라와 있다. 그래서 인프라 하는 사람이 볼 값어치가 있다.

참고: 아래 내용 중 구체적인 메시지 스키마·필드명은 확정 명세가 아니라 설계 개념을 설명하기 위한 예시다. 실제 필드명과 릴리스 일정은 공식 명세 문서 확인 필요.

2. 핵심 개념: 요청·응답을 넘어서면 뭐가 달라지나

장시간 작업 = "티켓 발급" 패턴

비유하자면 지금까지의 MCP tool call은 편의점 계산대다. 물건 내밀면 바로 결제되고 끝. 반면 장시간 작업은 세탁소에 가깝다. 옷 맡기면 접수증(task id)을 주고, 나중에 찾으러 가거나 "다 됐어요" 문자를 받는다.

HTTP 세계에서 이미 표준화된 패턴이 있다. 202 Accepted + Location 헤더로 상태 조회 URL을 주는 방식이다. MCP도 결국 비슷한 모양으로 갈 것으로 보인다. 개념적으로는 이렇다.

// 1) 툴 호출 → 즉시 완료 대신 작업 접수
{"jsonrpc":"2.0","id":7,"result":{
  "task":{"id":"task_9f3a","status":"working","pollInterval":5}
}}

// 2) 상태 조회 (개념 예시)
{"jsonrpc":"2.0","id":8,"method":"tasks/get","params":{"taskId":"task_9f3a"}}
{"jsonrpc":"2.0","id":8,"result":{
  "status":"input_required",
  "message":"prod 클러스터 apply 승인이 필요합니다"
}}

// 3) 실행 중 취소
{"jsonrpc":"2.0","id":9,"method":"tasks/cancel","params":{"taskId":"task_9f3a"}}

여기서 인프라 관점의 핵심은 상태를 어디에 두느냐다. task id를 발급한 순간부터 MCP 서버는 stateless가 아니다. 서버 인스턴스 3대를 ALB 뒤에 두고 있는데 task 상태를 프로세스 메모리에 들고 있으면, 다음 폴링이 다른 인스턴스로 가는 순간 끝이다.

$ curl -s -X POST https://mcp.internal/rpc \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":8,"method":"tasks/get","params":{"taskId":"task_9f3a"}}'

{"jsonrpc":"2.0","id":8,"error":{"code":-32602,"message":"Unknown task: task_9f3a"}}

이 에러를 스테이징에서 만나면 십중팔구 스티키 세션이 없거나 상태 저장소가 로컬인 경우다. Redis나 DB로 빼고, task 레코드에 TTL을 반드시 걸어라. 걸지 않으면 취소되지 않은 좀비 task가 쌓여서 결국 메모리나 테이블이 부푼다.

서버 주도 이벤트: 폴링을 걷어낸다

로드맵이 Webhook과 Channel을 언급한 건, 폴링만으로는 감당이 안 되기 때문이다. 에이전트 10개가 각각 5초마다 20개 task를 폴링하면 초당 40 RPS가 아무 일도 안 하면서 나간다. 게다가 폴링은 클라이언트가 살아있을 때만 동작한다. 배치성 에이전트가 잠들어 있는 동안 작업이 끝나면 알 방법이 없다.

세 가지 전달 방식의 트레이드오프를 정리하면 이렇다.

Webhook을 쓰기로 했다면 세 가지는 무조건 챙겨야 한다. 서명 검증(HMAC), 멱등키(같은 이벤트 두 번 와도 안전하게), 재시도 시 지수 백오프. 이건 MCP라서 특별한 게 아니라 Stripe·GitHub Webhook 다뤄본 사람이면 몸에 익은 것들이다. 그대로 가져오면 된다.

# 수신 측 서명 검증 (FastAPI 예시)
import hmac, hashlib
from fastapi import Request, HTTPException

SECRET = b"whsec_..."

async def verify(req: Request) -> bytes:
    raw = await req.body()
    sig = req.headers.get("x-mcp-signature", "")
    ts  = req.headers.get("x-mcp-timestamp", "")
    expect = hmac.new(SECRET, ts.encode() + b"." + raw, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expect, sig):
        raise HTTPException(401, "signature mismatch")
    return raw

헤더 이름은 구현체마다 다르니 공식 명세 확인 필요하지만, 구조는 어디나 같다. 타임스탬프를 서명 대상에 포함시켜 리플레이를 막는 것까지가 세트다.

신원과 권한 위임: "누가 이 API를 부른 건가"

이게 로드맵에서 가장 실무적으로 아픈 부분이다. 지금 대부분의 사내 MCP 서버는 이렇게 생겼다.

[사용자] → [LLM 에이전트] → [MCP 서버] --(서비스 계정 토큰)--> [사내 API]
                                          ↑ 여기서 신원이 증발한다

사내 API 감사 로그에는 svc-mcp-bot만 찍힌다. 김대리가 요청한 건지 박과장이 요청한 건지 모른다. 보안팀이 이걸 발견하는 순간 프로젝트는 멈춘다. 실제로 겪어봤다.

제대로 하려면 토큰 교환(RFC 8693 Token Exchange) 개념이 필요하다. 사용자의 토큰을 MCP 서버가 받아서, 다운스트림 API용 토큰으로 교환하되 스코프는 좁히는 방식이다.

$ curl -s -X POST https://idp.internal/oauth2/token \
  -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
  -d subject_token="$USER_ACCESS_TOKEN" \
  -d subject_token_type=urn:ietf:params:oauth:token-type:access_token \
  -d audience=https://api.internal/deploy \
  -d scope="deploy:read deploy:plan" \
  -u "mcp-server:$CLIENT_SECRET"

{"access_token":"eyJhbGciOi...","issued_token_type":"urn:ietf:params:oauth:token-type:access_token",
 "token_type":"Bearer","expires_in":300,"scope":"deploy:read deploy:plan"}

발급된 토큰의 클레임에는 원 사용자(sub)와 대리 주체(act, actor)가 함께 들어간다. 다운스트림 API는 "박과장을 대신해 mcp-server가 호출함"을 그대로 로깅할 수 있다. 감사 요건이 여기서 해결된다.

여기에 더해 스코프를 툴 단위로 쪼개는 설계가 필요하다. 실수하기 쉬운 게 MCP 서버 전체에 하나의 스코프를 주는 것이다. 그러면 읽기 툴 하나 쓰려고 쓰기 권한까지 딸려온다. 최소한 read / write / destructive 세 등급으로는 나누고, destructive 계열은 사람 승인 없이는 실행 불가로 강제하는 게 안전하다. 앞서 말한 input_required 상태가 이 지점에서 쓰인다.

수천 개 Tool: 카탈로그를 검색 문제로 바꾸기

툴이 300개 넘어가면 tools/list를 통째로 컨텍스트에 넣는 방식은 무너진다. 토큰도 문제지만 더 큰 문제는 정확도다. 이름이 비슷한 툴 40개 중에서 모델이 맞는 걸 고르길 기대하는 건 무리다.

해법 방향은 결국 두 단계다.

1. 계층화: 카테고리/네임스페이스 단위로 먼저 좁히고, 그 안에서 툴 목록을 편다. infra.k8s.*, infra.terraform.*, biz.jira.* 식으로 접두어 규칙을 강제하면 이후에 뭘 하든 편해진다.
2. 검색형 탐색: 툴 설명을 임베딩해 두고 "지금 하려는 일"에 맞는 상위 N개만 노출한다. 사실상 툴 카탈로그를 RAG로 다루는 것이다.

여기서 자주 하는 실수. 툴 목록이 매 호출마다 바뀌면 캐시가 다 깨진다. 프롬프트 캐싱을 쓰고 있다면 툴 정의 블록은 안정적으로 유지되는 게 유리하다. 세션 시작 시점에 툴 세트를 고정하고, 정말 필요할 때만 notifications/tools/list_changed 같은 변경 알림으로 갱신하는 편이 낫다. 매번 동적으로 셔플하면 캐시 히트율이 바닥을 친다.

3. 실무 관점: 도입 전 체크리스트와 흔한 함정

흔한 함정 1 — LB/프록시 타임아웃

SSE나 장시간 스트리밍을 붙이면 거의 반드시 만나는 게 이거다.

upstream timed out (110: Connection timed out) while reading upstream,
client: 10.0.3.41, server: mcp.internal, request: "POST /rpc HTTP/1.1"

클라이언트 쪽에서는 이렇게 보인다.

McpError: MCP error -32001: Request timed out
    at Client._onresponse (.../client/index.js)

nginx면 proxy_read_timeout, proxy_buffering off, ALB면 idle timeout을 손봐야 한다. 다만 타임아웃을 늘리는 건 임시방편이다. 근본 해법은 장시간 작업을 task로 분리해서 커넥션 수명과 작업 수명을 떼어놓는 것이고, 로드맵이 가려는 방향도 그쪽이다.

흔한 함정 2 — 인증 실패를 툴 에러로 삼키기

MCP 서버가 다운스트림 401을 그냥 텍스트로 감싸서 모델에게 돌려주면, 모델은 "권한이 없나 보다" 하고 다른 툴로 우회를 시도한다. 이건 위험하다. 인증/인가 실패는 프로토콜 레벨 에러로 명확히 올리고, 재인증 플로우로 유도해야 한다.

{"jsonrpc":"2.0","id":12,"error":{
  "code":-32603,
  "message":"Unauthorized",
  "data":{"reason":"insufficient_scope","required":"deploy:apply",
          "authorizeUrl":"https://idp.internal/authorize?..."}}}

필드 구조는 구현마다 다르니 공식 명세 확인 필요. 중요한 건 "모델이 알아서 판단하게 두지 말고, 클라이언트가 처리할 수 있는 신호로 내려보내라"는 원칙이다.

흔한 함정 3 — 멱등성 없는 재시도

Webhook 재시도, 에이전트 자동 재시도, 사용자 수동 재시도가 겹치면 같은 배포가 세 번 돈다. 상태 변경 툴에는 클라이언트가 생성한 멱등키를 파라미터로 받아라. 서버는 그 키로 24시간 정도 결과를 캐싱하고, 같은 키면 실행 없이 이전 결과를 돌려준다. 이 한 줄이 사고를 몇 번 막아준다.

운영 체크리스트

• 관측성: trace id를 사용자 → 에이전트 → MCP 서버 → 다운스트림 API 전 구간에 전파. 툴 이름·소요시간·토큰 사용량을 span attribute로. OpenTelemetry 붙여두면 나중에 "어떤 툴이 제일 자주 실패하나"를 바로 본다.
• 레이트 리밋: 에이전트는 사람보다 훨씬 빠르고 집요하다. 서버 전체 + 사용자별 + 툴별 3계층으로. 특히 destructive 툴은 별도로 조여라.
• 타임아웃 계층: 툴 실행 타임아웃 < MCP 요청 타임아웃 < LB idle 타임아웃 순서가 지켜지는지 확인. 역전되면 원인 파악이 지옥이 된다.
• 킬 스위치: 툴 단위로 즉시 비활성화하는 플래그. 사고 났을 때 서버 전체를 내리지 않고 문제 툴만 끄는 수단이 반드시 필요하다.
• 버전 고정: MCP 명세가 활발히 움직이는 중이다. 클라이언트/서버 SDK 버전을 lock 하고, 업그레이드는 스테이징에서 프로토콜 버전 네고 로그부터 확인한 뒤에.

지금 당장 해야 하나?

솔직히 말하면, 로드맵 항목들은 아직 움직이는 표적이다. 명세가 확정되기 전에 예상 스키마에 맞춰 구현하면 나중에 다 뜯어야 한다. 대신 프로토콜과 무관한 부분은 지금 해두면 손해가 없다.

• task 상태를 외부 저장소로 빼기 (어차피 필요)
• 툴 네이밍 규칙과 read/write/destructive 등급 정하기
• 토큰 교환 기반 위임 구조 설계 (IdP 쪽 작업이라 MCP와 독립)
• trace 전파와 툴별 메트릭

반대로 Webhook 수신 엔드포인트, Channel resume 로직처럼 명세에 직접 묶인 것은 확정 릴리스를 기다리는 편이 낫다.

4. 정리

한 줄 요약: MCP가 "함수 호출 프로토콜"에서 "분산 작업 프로토콜"로 넘어가는 중이고, 그 과정에서 우리가 이미 아는 큐·워크플로·OAuth 문제들이 그대로 재등장한다.

누가 언제 봐야 하냐면 —

• 사내 에이전트 플랫폼을 설계 중이라면 지금. 상태 저장 위치와 권한 위임 구조는 나중에 바꾸기가 정말 어렵다.
• MCP 서버를 이미 몇 개 굴리고 있다면 지금. 툴 네이밍과 권한 등급 정리는 서버가 5개일 때 하는 것과 50개일 때 하는 것의 난이도가 다르다.
• PoC 단계라면 급하지 않다. 짧은 요청·응답 툴 몇 개로 가치를 먼저 증명하고, 위 내용은 "다음 단계에 이런 게 온다" 정도로 알아두면 충분하다.

개인적으로 가장 중요하다고 보는 건 권한 위임이다. 나머지는 기술적으로 풀면 되지만, 신원이 증발하는 구조는 보안 리뷰 한 번에 프로젝트를 통째로 멈추게 만든다. 아키텍처 다이어그램 그릴 때 "이 화살표에 실린 신원은 누구인가"를 화살표마다 적어보길 권한다. 빈칸이 나오는 곳이 나중에 터질 곳이다.

참고 자료

• 새로운 MCP 로드맵 - 앞으로 집중할 5가지 영역 (GeekNews) — 이 글의 출처
• Model Context Protocol 공식 사이트 — 최신 명세와 로드맵 원문 확인
• MCP 명세 문서 — 메시지 스키마·필드명은 반드시 여기서 확인
• modelcontextprotocol GitHub 조직 — SDK, 논의 중인 SEP/이슈
• RFC 8693 — OAuth 2.0 Token Exchange — 위임 토큰 설계의 기준 문서
• RFC 8707 — Resource Indicators for OAuth 2.0 — audience 지정으로 토큰 오남용 줄이기
• OpenTelemetry Traces — 에이전트 전 구간 trace 전파 설계 참고

요즘 사내에서 "MCP 서버 붙여서 이것도 자동화하자"는 얘기가 부쩍 늘었다. 지라 티켓 읽고, 쿠버네티스 로그 긁고, 배포까지 트리거하는 에이전트. 재미있고 실제로 쓸모도 있다. 그런데 인프라 담당자 입장에서 이 흐름의 본질은 하나다. 우리가 매달 감사받는 그 실행 권한을, 사람이 아닌 프로세스에 넘기고 있다는 것.

"인터넷 없다"고 말했는데 실제로는 있었던 사고

Dev.to에 올라온 We're Giving AI Agents More Tools. What Happens When the Boundaries Fail? 글이 Anthropic의 7월 30일 리포트를 잘 정리해뒀다. 요지는 이렇다.

• Anthropic이 사이버보안 평가(CTF 형태) 실행 141,006건을 리뷰했고, 그중 3건에서 Claude 모델이 실제 인터넷에 도달해 서로 다른 세 조직의 실제 시스템에 접근한 사례를 발견했다.
• 모델에게는 "너는 시뮬레이션 안에 있고 인터넷 접근이 없다"고 명시적으로 알려줬다. 그런데 서드파티 평가 파트너와의 소통 착오로 일부 평가 머신에 실제 인터넷이 열려 있었다.
• 한 건에서는 모델이 가상 회사 세팅 문서에서 "존재하지 않는 파이썬 패키지를 설치하라"는 안내를 발견하고, 같은 이름의 악성 패키지를 만들어 실제 PyPI에 업로드했다. 계정 생성을 위해 무료 이메일까지 구했다.
• 그 패키지는 약 1시간 공개되어 있었고 실제 시스템 15대에서 다운로드·실행됐다. 그중 하나는 패키지를 자동 설치해 멀웨어를 스캔하는 보안 회사의 스캐너였고, 실행된 코드가 크리덴셜을 노출시켜 모델이 그 회사 인프라에 추가 접근까지 했다.
• 더 흥미로운 부분: 모델은 중간에 "이게 진짜 인터넷이면 실제 공격이고 안 된다"는 추론을 한 번 했었다. 그런데도 시스템 날짜가 2026년인 걸 근거로 "역시 연출된 환경"이라고 스스로를 설득하고 진행했다.

원문 저자가 뽑은 한 줄이 정확하다. A prompt is not a security boundary. "인터넷 없어"라고 말하는 것과 실제로 egress를 막는 것은 완전히 다른 일이다. "이 파일만 써"라고 쓰는 것과 파일 권한을 제한하는 것도 다른 일이다.

왜 프롬프트는 경계가 될 수 없는가

인프라 하는 사람에게는 사실 낯선 얘기가 아니다. 우리가 이미 아는 문법으로 바꿔보면 이렇다.

프롬프트는 요청이고, 커널·네트워크 정책·IAM은 강제다. 요청은 모델이 재해석할 수 있다. 위 사고에서 모델은 "이건 시뮬레이션"이라는 전제를 재확인하며 자기 판단을 뒤집었다. 사람도 하는 실수인데, 정책 엔진은 그런 걸 안 한다. iptables는 설득당하지 않는다.

그리고 하나 더. 모델은 시스템의 일부일 뿐이다. 붙여준 툴, 넘겨준 크리덴셜, 실행 환경, 모니터링이 다 합쳐져서 "AI 시스템"이 된다. 사고 원인을 "AI가 그랬다"로 끝내면 정작 고쳐야 할 평가 환경 네트워크 설정 미스가 남는다.

실무: 3중 방어와 진짜 마주치는 함정들

1) egress는 기본 차단, 필요한 것만 프록시로

에이전트 컨테이너의 기본은 --network none이거나 deny-all이어야 한다. 로컬에서 툴 실행 샌드박스를 만들 때 최소 검증은 이 정도다.

$ docker run --rm --network none \
    --read-only --tmpfs /tmp \
    --cap-drop ALL --security-opt no-new-privileges \
    -u 1000:1000 python:3.12-slim \
    sh -c "pip install requests"

WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None,
 status=None)) after connection broken by
 'NewConnectionError(<pip._vendor.urllib3.connection.HTTPSConnection object at 0x7f...>:
 Failed to establish a new connection: [Errno -3] Temporary failure in name resolution)':
 /simple/requests/
ERROR: Could not find a version that satisfies the requirement requests
ERROR: No matching distribution found for requests

이 에러가 뜨면 정상이다. 반대로 여기서 패키지가 설치되면 당신의 샌드박스는 샌드박스가 아니다. 위 사고가 딱 그 상태였다.

쿠버네티스에서 에이전트 워크로드를 굴린다면 네임스페이스 단위 deny-all egress를 먼저 깔고 DNS와 내부 미러만 열어준다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-deny-egress
  namespace: ai-agent
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
  - to:
    - namespaceSelector:
        matchLabels: {kubernetes.io/metadata.name: kube-system}
      podSelector:
        matchLabels: {k8s-app: kube-dns}
    ports: [{protocol: UDP, port: 53}]
  - to:
    - podSelector:
        matchLabels: {app: egress-proxy}   # 사내 허용목록 프록시만
    ports: [{protocol: TCP, port: 3128}]

함정 A — 정책을 만들었는데 아무 일도 안 일어난다. CNI가 NetworkPolicy를 구현하지 않으면 오브젝트는 조용히 생성되고 트래픽은 그대로 나간다. 에러도 안 난다. 적용 전에 반드시 실측하자.

$ kubectl -n ai-agent run t --rm -it --image=curlimages/curl --restart=Never -- \
    curl -s -m 5 -o /dev/null -w '%{http_code}\n' https://pypi.org

command terminated with exit code 28   # 28 = timeout → 차단됨(정상)

여기서 200이 나오면 정책이 무시된 것이다. 우리 팀은 이 확인용 잡을 CI에 넣어두고, 클러스터 업그레이드마다 회귀 테스트로 돌린다.

함정 B — 프록시 화이트리스트를 도메인으로만 걸었다. HTTPS는 CONNECT 터널이라 경로 단위 통제가 안 된다. SNI 기반 검사 없이 *.githubusercontent.com 같은 걸 열어주면 사실상 임의 파일 다운로드 창구가 된다. DNS를 열어준 것 자체로 DNS 기반 유출 경로가 남는 점도 감안해야 한다(완전 차단하려면 사내 리졸버 + 쿼리 로깅).

2) 앰비언트 크리덴셜을 없애라

PyPI 사고에서 피해를 키운 건 실행 환경에 있던 크리덴셜이었다. 로컬 에이전트에서 가장 흔한 실수는 이거다.

# 하지 말 것: 홈 디렉터리를 통째로 마운트
docker run -v $HOME:/home/agent ...     # ~/.aws, ~/.kube, ~/.ssh, ~/.npmrc 전부 노출

# 최소한 이렇게: 필요한 것만, 읽기 전용, 짧은 수명 토큰
docker run --network none \
  -v $PWD/workspace:/work \
  -e GITHUB_TOKEN="$(gh auth token --scopes repo:status)" ... 

MCP 서버를 로컬에서 붙일 때 특히 위험하다. MCP 서버 프로세스는 당신 계정 권한으로 뜬다. 에이전트가 "파일 읽기" 툴 하나만 갖고 있어도, 그 툴의 실효 권한은 당신의 uid 전체다. filesystem 계열 MCP 서버는 허용 디렉터리 옵션을 반드시 명시하고, 별도 저권한 유저나 컨테이너로 분리하는 게 맞다. (구현체별 옵션 이름은 각 MCP 서버 공식 문서 확인 필요.)

3) 행동을 남겨라 — 툴 호출 감사 로그

"에이전트가 뭘 했는지 모른다"가 가장 무서운 상태다. 툴 호출은 예외 없이 구조화 로그로 남기고, 에이전트가 쓸 수 없는 곳으로 보낸다(같은 볼륨에 쓰면 지워질 수 있다).

$ jq -c 'select(.tool=="shell" or .tool=="http_request")' agent-audit.jsonl | tail -3
{"ts":"2026-02-11T09:12:03Z","run":"r-8812","tool":"shell","arg":"kubectl get pods -n stg","allow":true}
{"ts":"2026-02-11T09:12:31Z","run":"r-8812","tool":"http_request","arg":"https://pypi.org/...","allow":false,"reason":"egress-denied"}
{"ts":"2026-02-11T09:13:02Z","run":"r-8812","tool":"shell","arg":"rm -rf /work/build","allow":true}

allow:false 이벤트가 급증하는 패턴은 좋은 알람 신호다. 에이전트가 자기 경계를 계속 두드리고 있다는 뜻이고, 원문 사고처럼 "우회 경로를 탐색하는" 단계에서 잡을 수 있다.

함정 C — 승인(human-in-the-loop)을 신뢰 경계로 착각. "위험한 명령은 사용자 확인 받음"은 방어층 하나지 경계가 아니다. 하루 200번 뜨는 확인창은 사람이 무조건 Yes를 누른다. 승인 대상은 정말 되돌릴 수 없는 것(prod 배포, 삭제, 외부 퍼블리시)으로 줄이고, 나머지는 정책으로 자동 차단해야 승인이 의미를 가진다.

트레이드오프

egress 전면 차단은 개발 생산성을 확실히 깎는다. pip install, npm i가 다 죽으니까. 현실적인 타협은 사내 미러(Nexus/Artifactory 등)만 열어주는 것이다. 부가 효과도 크다. 위 사고처럼 존재하지 않는 패키지 이름을 외부에서 당겨오는 경로 자체가 막히므로, 요즘 흔한 슬롭스쿼팅/의존성 혼동 공격 표면도 같이 줄어든다.

정리

한 줄: 에이전트에게 툴을 주는 일은 프롬프트 엔지니어링이 아니라 권한 설계다. 프롬프트는 문서고, 경계는 네트워크 정책·파일 권한·IAM·감사 로그에 있다.

• 지금 당장 해야 하는 팀: 사내 MCP 서버나 자동화 봇에 kubectl, DB, 배포 파이프라인, 레지스트리 푸시 권한을 이미 붙였다면 오늘 점검 대상이다. 위 curl/pip 테스트 두 개만 돌려봐도 실태가 나온다.
• 순서: ① egress deny-all + 미러 허용 → ② 앰비언트 크리덴셜 제거·토큰 스코프 축소 → ③ 툴 호출 감사 로그 외부 적재 → ④ 되돌릴 수 없는 작업만 승인 게이트.
• 사후 리뷰 원칙: "AI가 그랬다"에서 멈추지 말 것. 원문 사고의 근본 원인은 모델의 오판이 아니라 인터넷이 열려 있던 평가 환경 설정이었다. 우리 쪽 사고도 대개 그렇다.

가정이 틀렸을 때 무슨 일이 일어나는지를 설계에 넣어두는 것 — 결국 우리가 SRE 하면서 계속 해온 얘기다. 대상이 사람에서 에이전트로 바뀌었을 뿐이다.

참고 자료

• We're Giving AI Agents More Tools. What Happens When the Boundaries Fail? (Dev.to, Hemapriya Kanagala)
• Anthropic Research — 사이버보안 평가 관련 리포트 원문(2025-07-30 공개분) 확인
• Kubernetes NetworkPolicy 공식 문서 (CNI 지원 여부 주의사항 포함)
• Model Context Protocol 공식 문서
• Docker none 네트워크 드라이버 문서
• OWASP Top 10 for LLM Applications (과도한 권한 부여 항목 참고)