이런 분이 읽으면 좋습니다
요약: MCP(Model Context Protocol)는 AI 에이전트와 외부 도구·데이터를 연결하는 개방형 표준이다. 2024년 11월 Anthropic이 공개한 뒤 OpenAI·Google을 포함한 주요 벤더가 채택하면서, “에이전트에 도구를 붙이는 방법”의 기본값이 됐다. 이 글은 MCP의 구조(Host–Client–Server), 세 가지 프리미티브, 전송 방식 선택, 직접 API 통합 대비 트레이드오프, 그리고 도입 전에 반드시 짚어야 할 보안 리스크까지 실무 관점으로 정리한다.
이 글은 에이전트에 사내 시스템·외부 서비스를 연결해야 하는 개발자와, MCP 도입 여부를 판단해야 하는 기술 리더를 위해 썼다. SDK 튜토리얼이 아니라 구조와 판단 기준에 집중한다.
왜 지금 MCP인가: N×M 통합 문제
2023~2024년의 에이전트 개발은 통합 지옥이었다. 도구가 N개, 에이전트(또는 LLM 앱)가 M개면 통합 코드는 N×M개 필요했다. Slack 연동을 Claude 앱용으로 한 번, 사내 챗봇용으로 또 한 번, IDE 어시스턴트용으로 또 한 번 — 같은 API를 감싸는 코드가 팀마다 조금씩 다르게 중복됐다.
MCP는 이 구조를 **“서버 N개 + 표준 프로토콜 1개”**로 바꾼다. 도구 제공자는 MCP 서버를 한 번만 만들고, MCP를 지원하는 모든 클라이언트(Claude, IDE, 사내 에이전트 런타임)가 그 서버를 그대로 쓴다. USB-C가 주변기기 연결을 표준화한 것과 같은 구도라서 “AI의 USB-C”라는 비유가 정착했다.
채택 속도가 이 표준의 실질을 증명한다. 2024년 11월 공개 이후 2025년 상반기에 OpenAI와 Google DeepMind가 연이어 지원을 발표했고, 주요 IDE·에이전트 런타임이 클라이언트를 내장했다. 공개 MCP 서버는 수천 개 규모로 늘었고, 공식 레지스트리가 등장하면서 서버 배포·발견도 표준화되는 중이다. 2026년 현재 “이 도구, 에이전트에서 쓸 수 있나요?”라는 질문은 사실상 “MCP 서버 있나요?”와 같은 뜻이 됐다.
MCP의 구조: Host, Client, Server
MCP를 처음 볼 때 가장 흔한 혼동이 “클라이언트 = 내 앱”이라는 오해다. MCP의 역할 구분은 세 층이다.
- Host: 사용자를 마주하는 애플리케이션이다. LLM 호출, 대화 관리, 그리고 “어떤 서버를 붙일지”의 정책 결정을 소유한다.
- Client: Host 안에 살면서 서버와의 1:1 연결을 유지하는 프로토콜 계층이다. 서버가 3개면 클라이언트도 3개다.
- Server: 도구·데이터를 노출하는 쪽이다. 좋은 서버는 하나의 도메인(GitHub, Postgres, 사내 CRM)을 좁고 깊게 감싼다.
이 구분이 실무에서 중요한 이유는 신뢰 경계 때문이다. Host는 사용자를 신뢰하고, Server는 자기 뒤의 시스템을 신뢰하지만, Host가 Server를 무조건 신뢰해서는 안 된다. 이 경계 설정은 뒤의 보안 절에서 다시 다룬다.
세 가지 프리미티브 — 그리고 역방향 두 가지
서버가 클라이언트에 제공하는 것은 세 종류로 정리된다.
| 무엇인가 | 제어 주체 | 대표 예시 | |
|---|---|---|---|
| Tools | 모델이 호출하는 실행 가능한 함수 | LLM이 판단해 호출 (사용자 승인 게이트 권장) | 이슈 생성, 쿼리 실행, 메시지 발송 |
| Resources | 모델에 제공되는 읽기 전용 컨텍스트 데이터 | Host/사용자가 선택해 주입 | 파일 내용, DB 스키마, 문서 |
| Prompts | 서버가 제공하는 재사용 프롬프트 템플릿 | 사용자가 명시적으로 선택 (슬래시 커맨드 등) | 코드 리뷰 템플릿, 정형 보고 양식 |
| Sampling (역방향) | 서버가 클라이언트의 LLM에 생성 요청 | 클라이언트가 승인·과금 통제 | 서버 내부 로직에 LLM 추론이 필요할 때 |
| Elicitation (역방향) | 서버가 사용자에게 추가 입력 요청 | 클라이언트가 UI로 중개 | 작업 중 확인·선택지 질문 |
설계 관점의 함정 하나: 모든 것을 Tool로 만들지 말 것. “문서를 읽어오는 tool”은 모델이 매번 호출을 판단해야 하지만, 같은 데이터를 Resource로 노출하면 Host가 컨텍스트에 미리 실어줄 수 있다. 호출 판단 비용과 컨텍스트 설계의 문제로 보면, tool 남발은 에이전트의 판단 부담을 늘리는 안티패턴이다.
또 하나 — tool의 출력은 자유 텍스트가 아니라 구조화된 결과로 반환하는 편이 후속 처리에 압도적으로 유리하다. 이 주제는 LLM 구조화 출력 가이드에서 자세히 다뤘다.
전송 방식: stdio vs Streamable HTTP
MCP는 전송 계층을 추상화해 뒀고, 실무 선택지는 둘이다.
| stdio | Streamable HTTP | |
|---|---|---|
| 실행 형태 | 클라이언트가 서버를 로컬 서브프로세스로 실행 | 독립 HTTP 서비스로 배포, 원격 접속 |
| 인증 | 프로세스 권한 상속 (별도 인증 없음) | OAuth 2.1 기반 — 스펙이 인증 흐름을 규정 |
| 적합한 경우 | 개발 도구, CLI, 로컬 파일·개인 환경 접근 | 팀 공유 서비스, SaaS 연동, 멀티테넌트 |
| 운영 부담 | 배포 없음 — 바이너리·스크립트 배포만 | 일반 웹 서비스와 동일 (TLS, 스케일링, 모니터링) |
| 주의점 | 서버가 사용자 로컬 권한을 그대로 가짐 | 세션 관리·재연결 처리, 초기 HTTP+SSE 방식과의 호환 |
판단 기준은 단순하다. “이 서버가 내 머신의 권한으로 도는 게 맞나?” — 맞으면 stdio, 여러 사람·여러 호스트가 공유해야 하면 Streamable HTTP다. 원격 서버로 가는 순간 인증·권한·감사 로그가 일반 API 서비스와 동일한 수준으로 필요해진다는 점이 운영 비용의 실체다.
직접 API 통합 vs MCP: 언제 무엇을 쓰나
MCP가 표준이 됐다고 해서 모든 통합을 MCP로 바꿔야 하는 것은 아니다. 프레임워크의 함수 호출(function calling)로 도구를 직접 정의하는 방식은 여전히 유효하다.
경험적으로 가장 좋은 중간 지점은 마지막 줄이다. 도구의 실제 로직을 프로토콜과 무관한 순수 함수로 유지하면, 직접 호출로 시작했다가 클라이언트가 늘어나는 시점에 MCP 어댑터만 추가하는 전환이 며칠 단위로 끝난다. 반대로 로직을 특정 프레임워크의 tool 정의에 녹여버리면 전환 비용이 눈덩이처럼 불어난다.
보안: 편리함의 뒷면
2025년 이후 보안 연구에서 반복적으로 보고된 MCP 리스크는 세 가지로 압축된다.
1. Tool poisoning — 서버가 노출하는 도구 설명(description) 자체에 악성 지시를 심는 공격이다. 모델은 도구를 쓰기 위해 설명을 읽어야 하므로, 설명이 곧 프롬프트 인젝션 벡터가 된다. 서드파티 서버를 붙이는 행위는 “그 서버 작성자의 텍스트를 내 모델의 컨텍스트에 넣는 행위”와 같다.
2. 데이터 경유 프롬프트 인젝션 — 도구가 반환하는 데이터(이슈 본문, 이메일, 웹 페이지)에 심긴 지시를 모델이 따라가는 고전적 인젝션이다. MCP가 만든 문제는 아니지만, 도구 연결이 쉬워질수록 노출면이 정직하게 넓어진다.
3. 권한 과잉과 confused deputy — 서버 하나에 광범위한 토큰을 쥐여주면, 모델이 속았을 때 피해 범위가 토큰 범위만큼 커진다. 여러 시스템의 권한이 한 서버에 모이면 “누구의 권한으로 실행됐는가”가 흐려진다.
흔한 실수 4가지
1. “있는 API를 전부 tool로” — REST 엔드포인트 30개를 tool 30개로 옮기면 모델의 선택 정확도가 무너진다. 에이전트의 작업 단위(과업)에 맞춰 5~10개로 재설계하는 쪽이 항상 이긴다.
2. 도구 설명을 대충 쓰기 — description은 문서가 아니라 모델이 읽는 인터페이스다. 언제 쓰는지, 언제 쓰면 안 되는지, 인자의 제약이 무엇인지가 설명 품질의 전부다.
3. 에러를 사람 언어로 반환하지 않기 — “500 Internal Server Error”를 그대로 돌려주면 모델은 같은 호출을 반복한다. “인증 만료 — 사용자에게 재로그인을 요청하라”처럼 다음 행동이 담긴 에러가 에이전트 루프를 살린다.
4. 로컬 stdio 감각으로 원격 서버 운영 — 원격 MCP 서버는 인증·세션·버전 호환·감사 로그가 필요한 진짜 서비스다. 팀에 배포하는 순간부터 개발 프로세스의 정식 운영 대상으로 취급해야 한다.
결론: 프로토콜은 정해졌고, 설계는 남았다
“에이전트에 도구를 어떻게 연결할 것인가”라는 질문에서 프로토콜 선택의 불확실성은 사실상 사라졌다. MCP는 충분히 채택됐고, 스펙은 원격·인증·상호작용 방향으로 계속 정비되고 있다.
남은 것은 언제나 그렇듯 설계다. 도구를 과업 단위로 묶는 감각, Resource와 Tool을 구분하는 판단, 신뢰 경계와 승인 게이트의 위치 — 이것들은 프로토콜이 대신해 주지 않는다. MCP가 표준화한 것은 연결이지 판단이 아니다. 그리고 에이전트 시스템의 품질은 결국 그 판단들의 합이다.
다음에 읽을 글
- 하네스 엔지니어링: 프롬프트에서 런타임 제어까지 — 도구 연결 다음 단계, 에이전트 런타임 전체를 설계하는 관점
- LLM 구조화 출력: JSON 모드 vs 함수 호출 vs 제약 디코딩 — tool 출력을 신뢰 가능한 데이터로 만드는 방법
- RAG 파이프라인 설계: 청킹부터 검색 품질 모니터링까지 — MCP 서버 뒤에 숨길 검색 계층의 설계