Model Context Protocol(MCP) 아키텍처 심층 분석: 클라이언트-서버 통신 규격과 보안 샌드박스

AI 글을 읽다 보면 MCP라는 말이 빠지지 않고 나옵니다. 그런데 설명을 찾아 읽으면 “MCP 서버는 MCP를 구현한 서버입니다” 같은 문장에 막히기 쉽습니다. 정확히 그 답답함을 쓴 글이 있었습니다. 서버가 무슨 서버냐고 묻는 신입 이야기입니다.

관련 글 13편을 읽고 겹치는 내용을 정리했습니다. 앞서 쓴 AI 에이전트 운영 설계 글이 “맡긴 뒤 어떻게 통제하나”였다면, 이번 글은 그 손발에 해당하는 “도구를 어떻게 연결하나”입니다.

Model Context Protocol(MCP)의 개념 정의와 표준화 의의

여러 글이 같은 비유를 사용했습니다. AI에 달린 USB-C 단자입니다. 프린터는 이 단자, 카메라는 저 단자로 제각각이던 시절에 USB라는 공통 규격이 생긴 것처럼, AI와 외부 서비스를 잇는 방식을 하나로 맞춘 것입니다. Model Context Protocol의 줄임말이고, 2024년 11월에 Anthropic이 공개한 규격이라고 여러 글이 적었습니다.

한 글은 이 비유의 한계도 짚었습니다. 물리적인 케이블이 아니라 소프트웨어끼리 “어떤 도구가 있는지, 어떻게 부르는지, 무엇을 돌려주는지”를 주고받는 약속이라는 것입니다. 비유로 시작하되 “소프트웨어 사이의 공통 대화 규칙”까지 가서 이해하라는 조언이었습니다.

파편화된 독자 도구 프로토콜의 한계와 통합 규격의 필요성

한 글은 곱셈과 덧셈으로 설명했습니다. AI 서비스가 M개, 연결하고 싶은 도구가 N개면 서로 맞추는 개발이 M×N 번 필요합니다. 공통 규격이 있으면 도구는 MCP 서버를 한 번, AI는 MCP 클라이언트를 한 번 만들면 되니까 M+N이 된다는 것입니다. 그 글의 예로 AI 4개와 도구 5개면 20번이 9번으로 줄어듭니다.

호스트-클라이언트-서버 3계층 아키텍처 토폴로지

세 글이 거의 같은 구조를 소개했습니다.

이름	하는 일	예
호스트	사용자가 만지는 AI 앱 본체. 대화와 승인 화면을 맡습니다	Claude Desktop, Cursor, VS Code
클라이언트	호스트 안에서 서버 하나와 일대일로 연결을 유지합니다	앱 안의 접속 부품
서버	도구와 데이터를 내놓는 쪽입니다	파일, GitHub, Notion, DB 창구

서버가 AI에게 내놓는 건 세 가지입니다. 도구(AI가 불러서 일을 시키는 기능), 리소스(참조할 수 있는 자료), 프롬프트(서버가 마련한 정형 요청)입니다. 실제로 가장 많이 쓰는 건 도구라고 Claude Code를 직접 실험한 글이 적었습니다.

여기서 이름이 헷갈리는 이유를 파헤친 글이 재미있었습니다. 이 글에 따르면 “프로토콜”은 원래 외교 의례를 뜻하던 말이고, 거기에 “서버”가 붙으면서 “서버”는 상자가 아니라 응대 역할의 이름이 되었습니다. 그래서 내 PC 안에서 잠깐 실행되는 작은 프로그램도, 인터넷 건너편의 서비스도 같은 “MCP 서버”로 불립니다. “서버를 세워야 하나?“라는 의문은 정상이고, 로컬에서는 세운다기보다 실행하는 경우가 많다는 이야기입니다.

Stdio 파이프라인 vs SSE 원격 웹소켓 전송 계층 비교

보안 관점의 글이 두 방식을 이렇게 구분했습니다.

• stdio(로컬): 앱이 서버를 하위 프로그램으로 띄워 표준 입출력으로 대화합니다. 별도 인증이 없고, 띄운 사람의 권한과 환경 변수를 그대로 물려받습니다.
• 스트리머블 HTTP(원격): 독립된 서버와 HTTP로 통신하고, 요청마다 토큰으로 인증하고 출처를 검증합니다.

“stdio는 띄운 사람의 권한을 그대로 쓰고, HTTP는 매번 토큰을 확인한다”로 외우면 정리가 쉽다고 했습니다. 그래서 로컬 서버를 받아 쓸 때는 그 프로그램이 내 계정의 힘을 통째로 쓴다는 점을 의식해야 합니다.

기존 확장 인터페이스(API, Skills, 플러그인) 대비 차별점

입문 시리즈를 쓴 한 필자가 가장 헷갈리는 두 가지를 갈랐습니다.

• API와는: API는 서비스의 창구입니다. MCP가 API를 없애는 게 아니고, MCP 서버 뒤에서 API를 부르는 경우가 다수 존재합니다. 흐름으로 쓰면 AI → MCP → API → 서비스입니다. 레스토랑에 비유한 글은 API가 주방의 주문 규칙이고, MCP는 AI와 여러 주방 사이의 공통 웨이터라고 했습니다.
• Skills와는: 한 필자는 “Skill은 어떻게 일하나, MCP는 무엇으로 일하나”로 줄였습니다. 회의록을 쓰는 일이라면, 순서와 서식은 Skill에, 드라이브에서 파일을 가져오는 접속은 MCP에 속합니다.
• 플러그인과는: 위 요소를 묶어 한 번에 설치하게 한 꾸러미입니다. 플러그인이 MCP를 꼭 쓰는 것은 아니고 Skill만 든 것도 있습니다. 설치했다고 외부 서비스에 자동으로 들어가는 건 아니고, 인증과 권한 부여는 따로 필요하다고 합니다.

또 한 글은 MCP와 AGENTS.md, Agent Skills가 모두 Linux Foundation 산하의 Agentic AI Foundation(AAIF)이라는 중립 재단으로 모이고 있다고 전했습니다. 이 글에 따르면 Agent Skills는 2026년 10월에 기부가 발표됐고 70개 이상의 에이전트 플랫폼이 통합했다고 합니다. 다만 필자도 “실행 환경 차이로 모든 스킬이 그대로 돌지는 않는다”고 단서를 달았습니다.

클라이언트 런타임별 MCP 서버 연결 및 환경 구성

데스크톱 애플리케이션 환경의 MCP 설정 파이프라인

공식 도움말 세 개를 분해한 글이 선택 기준을 명확히 제공했습니다.

선택	이런 도구에	쓸 수 있는 곳
원격 커넥터	로그인하는 클라우드 서비스(Slack, Notion, GitHub 등)	웹, 모바일, 데스크톱, Claude Code 등 어디서나
데스크톱 확장	내 PC의 파일, localhost DB, 데스크톱 앱처럼 OS 접근이 필요한 것	Claude Desktop과 Claude Code만

기본은 원격 커넥터이고, 디렉터리에서 찾아 연결하고 안내에 따라 인증하면 됩니다. 이 글이 강조한 대목이 있습니다. 서비스에 연결하면 내 계정 권한 범위에서 Claude가 데이터를 읽고 바꿀 수 있게 되니, 믿을 수 있고 필요한 서비스만 연결하라는 공식 당부입니다. 각 커넥터의 소개 페이지에서 읽기만 되는지 쓰기도 되는지를 먼저 보라는 조언도 실용적이었습니다.

CLI 코딩 에이전트 환경의 MCP 도구 바인딩

Claude Code를 Windows 11에서 직접 실험했다는 필자가 정리한 내용입니다.

• 세 가지 방식: HTTP(공식 권장), stdio(내 PC에서 실행), SSE(옛 방식, 비권장).
• 명령은 claude mcp add 한 줄이고, stdio에서는 서버를 띄우는 명령 전체를 -- 뒤에 두어야 합니다. 서버에 넘길 인자를 앞에 쓰면 Claude Code 자신의 옵션으로 오해합니다.
• 범위(scope): local(기본, 나만·이 프로젝트), project(팀이 공유하는 .mcp.json), user(내 모든 프로젝트). 같은 이름이면 local, project, user 순으로 우선합니다.
• 키는 설정 파일에 직접 쓰지 말고 환경 변수로 넘기라고 권합니다.

실행 방법은 도구와 버전마다 바뀌니 적용 전에 공식 문서를 확인해 주시기 바랍니다. 한 글은 자기 환경에서 서버를 추가하고, 목록에서 연결을 확인하고, “도구를 써 줘”라고 시켜 호출되는 것까지 확인했다고 밝혔습니다.

SDK를 활용한 커스텀 MCP 서버 구현 및 JSON-RPC 핸들링

Python으로 서버를 만드는 법을 다룬 글의 첫 경고가 유용했습니다. 공식 Python SDK가 2026년 7월 28일에 v2로 올라가면서 예전 글에 자주 나오는 FastMCP가 MCPServer로 이름이 바뀌었고, 옛 방식으로 import하면 오류가 난다는 것입니다. 이 필자는 AI에게 서버 코드를 시킬 때 학습 시기에 따라 옛 쓰임이 나올 수 있으니 import 줄부터 확인하라고 했습니다. 규격과 SDK가 빠르게 바뀌는 만큼 예전 예제를 그대로 믿지 말라는 교훈입니다.

서버 권한 스코프 및 파일 시스템 접근 제어 감사

이 대목이 글들의 무게중심이었습니다.

한 글은 생성형 AI와 에이전트의 차이를 “답의 정확성”에서 “실행한 조작의 영향”으로 옮겨 놓았습니다. 말만 하던 AI가 도구를 부르면 위험의 종류가 바뀝니다. 오답이 아니라 잘못된 상태 변경이 되고, 보낸 메일이나 지운 데이터는 취소가 안 될 수 있습니다. 이유도 세 가지로 정리했습니다. 참조 범위가 넓어지고, 할 수 있는 조작이 늘고, 한 서버에서 얻은 맥락이 다른 도구 실행의 근거로 번집니다.

그 글이 소개한 실무 사례도 있었습니다. ZOZO의 보안 운영팀이 알림 초기 대응에 AI를 쓰면서 세 가지로 조작을 제한했다는 것입니다. 연결 토큰은 읽기 권한만 주고, 도구를 쓰기 직전 훅(PreToolUse Hook)에서 쓰기성 질의를 막고, 토큰은 설정 파일에 쓰지 않고 1Password CLI로 실행할 때만 꺼내 쓴다는 구성입니다. 이 사례는 그 글이 인용한 회사 블로그의 내용입니다.

MCP 서버 배포 전 10대 보안 검증 체크리스트

권한 점검 체크를 제안한 글이 실용적이었습니다. 연결한 서버를 다섯 개까지 적고 각각에 대해 이 항목을 채우라는 것입니다.

항목	질문
발급처	인증 화면과 토큰이 정말 예상한 발급처에서 왔는지 살펴봅니다
범위(Scope)	읽기만 하면 되는데 쓰기 권한까지 있지 않는지 검토합니다
클라이언트	개인 앱인지, 사내 에이전트인지, 클라우드인지
신원	내 이름으로 움직이는지 분석합니다, 에이전트 전용 신원으로 움직이는지 분석합니다
부작용	호출하면 무엇이 바뀌나요(파일, 이슈, 발송, 삭제, 결제)

글은 “OAuth를 썼으니 안전하다”가 아니라고 못 박았습니다. 범위가 넓으면 권한도 넓은 그대로기 때문입니다. 마지막 한 줄 질문이 인상적이었습니다. “이 서버가 탈취되거나 에이전트가 오조작했을 때 지금 권한으로 어디까지 할 수 있는지 살펴봅니다?” 답을 모르겠다면 도구를 늘리기 전에 범위와 신원부터 확인하라는 것입니다.

동적 도구 호출 승인 게이트 및 위험 명령어 차단 메커니즘

• 한 글은 Codex가 지문 인증(Touch ID)으로 MCP 요청을 확인하게 하는 기능을 소개하면서 못을 박았습니다. 이건 “본인이 거기 있다”를 확인할 뿐 “그 조작이 안전한지”는 판단해 주지 않는다는 것입니다. 그러니 어떤 서비스를, 어떤 순서로, 어느 권한까지 연결하느냐가 먼저입니다.
• 사내 게이트웨이를 다룬 글은 개별 앱마다 모델과 MCP에 직접 연결하면 인증, 권한, 비용, 감사 로그가 흩어지니 한 입구로 모아 “누가 무엇을 어디까지 쓸 수 있는가”를 공통 관리하라고 합니다. 이 글은 필자가 책을 소개하는 입장이라 그 점을 감안해서 분석했습니다.
• 긴 시간 에이전트를 돌리는 도구를 다룬 글은 의외의 함정을 짚었습니다. 역할을 나눠도 사용자의 기존 MCP 설정을 각 역할이 암묵적으로 물려받으면, 읽기 전용이어야 할 검사 역할에 쓰기 권한이 있는 도구가 보일 수 있다는 것입니다. 그래서 명시한 설정만 읽게 하는 옵션을 넣었다고 합니다. 역할 분리는 프롬프트의 직함만으로는 성립하지 않는다는 교훈입니다.

MCP 도입 적합성 평가 모델

해당하는 항목을 눌러 확인하시기 바랍니다. 제가 만든 가벼운 참고용이고 정답은 아닙니다.

Model Context Protocol의 3대 핵심 프리미티브: Resources, Prompts, Tools

Anthropic이 오픈소스로 공개한 MCP(Model Context Protocol)는 기존의 난립하던 파편화된 도구 연동 규격들을 단 하나의 통일된 프로토콜로 통합한 표준 명세입니다. MCP는 시스템의 기능을 세 가지 직교하는 프리미티브(Primitives)로 명확히 분리합니다.

• Resources (자원): 파일 시스템, 데이터베이스 레코드, 외부 API 응답과 같이 에이전트가 읽을 수 있는 정적·동적 데이터 스트림입니다. URI 스키마(postgres://db/tables/users, file:///logs/app.log)를 통해 주소화되며 MIME 타입을 가집니다.
• Prompts (프롬프트 템플릿): 서버가 클라이언트에게 추천하는 정형화된 작업 지시서 모음입니다. “이 저장소의 버그를 분석하는 표준 워크플로우”와 같이 매개변수화된 프롬프트를 에이전트에게 사전 제공합니다.
• Tools (도구): 에이전트가 시스템에 실질적인 연산을 지시하거나 데이터를 변경할 수 있는 실행 가능한 함수입니다. 엄격한 JSON Schema 규격에 따라 입력 매개변수와 반환 타입을 선언합니다.

// MCP 서버의 표준 Tools 목록 선언 응답 (JSON-RPC 2.0 규격)
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "execute_database_query",
        "description": "PostgreSQL 데이터베이스에 읽기 전용 SQL 쿼리를 실행합니다.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": { "type": "string", "description": "실행할 SELECT SQL 쿼리문" },
            "timeout_ms": { "type": "integer", "default": 3000 }
          },
          "required": ["query"]
        }
      }
    ]
  }
}

전송 계층 비교: Stdio 파이프 vs SSE 웹소켓 vs 분산 gRPC

MCP 클라이언트와 서버가 물리적으로 데이터를 교환하는 전송 계층(Transport Layer)은 실행 환경에 따라 엄격한 보안과 성능 트레이드오프를 가집니다.

• 표준 입출력 파이프(Stdio Transport): 로컬 CLI 도구(Claude Code, 데스크톱 에이전트)에서 서브프로세스를 스폰하여 표준 입출력(stdin/stdout)을 통해 바이트 스트림을 통신합니다. 네트워크 포트를 열지 않으므로 외부 침투에 면역이지만 동일 로컬 머신 내로 실행 범위가 한정됩니다.
• Server-Sent Events 및 HTTP(SSE Transport): 클라우드 원격 서버나 마이크로서비스 환경에서 실행되는 MCP 서버와 통신할 때 사용됩니다. HTTP/2 또는 HTTP/3 기반의 장기 지속 연결을 수립하여 양방향 비동기 통신을 수행하며, TLS 암호화와 OAuth 2.0 베어러 토큰 인증이 결합됩니다.
• 보안 샌드박싱 필수 수칙: 원격 MCP 서버를 연결할 때는 해당 서버가 에이전트의 로컬 파일 시스템 전체에 접근하지 못하도록 도커 컨테이너나 리눅스 AppArmor 프로파일로 chroot 마운트 격리를 적용해야 합니다.

MCP 도입이 가져오는 소프트웨어 생태계의 거대한 변화

MCP의 등장은 소프트웨어 엔지니어링 패러다임을 “API 중심”에서 “에이전트 컨텍스트 중심”으로 이동시킵니다. 이제 소프트웨어 벤더들은 인간용 대시보드나 REST API뿐 아니라 자사 제품의 MCP 서버를 공식 배포하기 시작했습니다. 깃허브, 슬랙, 노션, 포스트그레스 등 모든 개발 도구가 표준 MCP 플러그인으로 연결되는 순간, AI 에이전트는 진정한 의미의 유니버설 소프트웨어 조작자로 완성됩니다.

MCP 서버 보안 아키텍처와 컨테이너 격리 샌드박싱

외부 커뮤니티나 제3자가 제작한 오픈소스 MCP 서버를 로컬 머신이나 프로덕션 환경에 연결할 때 가장 경계해야 할 위협은 악성 MCP 도구를 통한 호스트 시스템 탈취입니다.

MCP 서버는 기본적으로 에이전트의 지시에 따라 셸 명령을 실행하거나 로컬 파일을 읽고 쓸 수 있는 막강한 권한을 가집니다. 만약 검증되지 않은 MCP 서버가 내부적으로 악성 스크립트를 내장하고 있다면, 에이전트 연결 즉시 개발자의 SSH 키나 브라우저 세션 쿠키가 털릴 수 있습니다.

• 루트리스(Rootless) 도커 컨테이너 격리: 모든 원격 및 로컬 MCP 서버는 호스트 OS 권한이 완전히 박탈된 루트리스 도커 컨테이너 내부에서만 실행되어야 합니다.
• 볼륨 마운트 화이트리스트: 프로젝트에 꼭 필요한 특정 디렉토리만을 명시적으로 읽기 전용(:ro)으로 마운트하고, /etc, /home과 같은 시스템 민감 경로는 마운트 대상에서 철저히 배제합니다.
• 네트워크 이그레스(Egress) 방화벽: MCP 서버가 외부 임의 IP로 비인가 연결을 수립하지 못하도록 인가된 도메인을 제외한 모든 아웃바운드 인터넷 트래픽을 iptables로 차단합니다.

# docker-compose.yml: 보안 격리된 로컬 MCP 서버 샌드박스 구성
version: '3.8'
services:
  postgres-mcp-server:
    image: mcp/postgres-inspector:v1.2
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    networks:
      - internal-sandbox
    volumes:
      - /app/schema.sql:/data/schema.sql:ro
    environment:
      - DATABASE_URL=postgres://readonly_user@db:5432/analytics

이와 같은 방어적 샌드박스 격리가 전제될 때, 개발자는 수백 가지의 다양한 오픈소스 MCP 생태계 도구들을 시스템 보안 침해의 위협 없이 안심하고 통합할 수 있습니다.

MCP와 Agent Skills의 하이브리드 결합 아키텍처

소프트웨어 아키텍트들이 직면하는 또 다른 질문은 “MCP와 기존의 Agent Skills 중 무엇을 언제 써야 하는가”입니다. 두 기술은 상호 배타적인 것이 아니라 완벽한 보완재입니다.

• Agent Skills: 경량 스크립트, 마크다운 기반의 워크플로우 가이드, 특정 프로젝트 전용의 로컬 도구 모음으로, 별도의 서버 프로세스 없이 에이전트의 컨텍스트에 즉각 주입되는 유연한 룰셋입니다.
• Model Context Protocol(MCP): 데이터베이스 커넥션 풀 유지, 장기 지속 소켓 통신, 엄격한 타입 검증과 권한 격리가 요구되는 대규모 엔터프라이즈 인프라 연동에 최적화된 백엔드 프로토콜입니다.

최고 수준의 엔지니어링 팀은 전체 시스템의 표준 백엔드 연동은 견고한 MCP 서버로 통일하고, 세부 프로젝트별 비즈니스 로직과 컨벤션은 Agent Skills로 경량 주입하는 하이브리드 듀얼 레이어 아키텍처를 표준으로 채택하고 있습니다.

엔지니어링 결론: MCP 표준이 이끄는 차세대 에이전틱 웹의 미래

Model Context Protocol(MCP)은 파편화되어 있던 인공지능과 기존 소프트웨어 인프라 사이의 간극을 메우는 가장 우아하고 강력한 표준 가교입니다. 기계와 기계가 표준화된 언어로 대화하고 안전한 샌드박스 내에서 상호작용하는 이 아키텍처적 도약이야말로, 차세대 자율 엔지니어링 생태계를 완성하는 가장 확실한 기술적 주춧돌이 될 것입니다. Model Context Protocol(MCP)의 등장은 과거 인터넷이 TCP/IP 표준을 통해 전 세계 컴퓨터를 하나의 거대한 정보망으로 연결했던 것처럼, 파편화되어 있던 인공지능과 엔터프라이즈 소프트웨어를 하나의 지능형 실행망으로 묶어내는 중대한 역사적 전환점입니다. 이를 적극적으로 도입하고 표준 규격에 맞추어 인프라를 개방하는 기술 조직만이 차세대 에이전틱 웹의 거대한 물결 속에서 독보적인 경쟁력을 유지하게 될 것입니다.