MCP(Model Context Protocol) 완전 가이드: AI 도구 통합의 USB-C

이 글은 방대한 원문/자료를 그대로 옮기지 않고, 실무자가 빠르게 이해·적용할 수 있게 핵심만 구조화했다. MCP는 “AI용 USB-C 포트”라는 비유처럼 에이전트와 외부 도구/데이터를 표준화된 방식으로 연결한다. 문서 끝의 참고문헌은 축약했고, 각 섹션은 바로 응용에 필요한 관점 중심으로 정리했다.

1. 왜 MCP인가? (N×M 문제 → 표준 포트)

• AI 에이전트가 똑똑해지려면 외부 세계와 연결되어야 한다. 하지만 현실은 복잡하다. AI 모델(ChatGPT, Claude 등)마다, 그리고 연결하려는 도구(Jira, Slack, 데이터베이스 등)마다 각자의 연결 방식이 달라, 개발팀은 매번 새로운 ‘어댑터’를 만들어야 했다.
• 전통적 방식: AI 시스템 N개 × 도구 M개 → 연결용 어댑터 N×M 개 직접 제작 → 유지보수 비용 폭발, 보안 및 관리 규칙 혼란.
• 모델 5개와 도구 20개를 연결하려면 이론상 100개의 어댑터가 필요하다. 이는 곧 기술 부채가 되고, 작은 변경 하나에도 여러 곳을 수정해야 하는 ‘통합 지옥’을 연다.

1.1 MCP 등장 목적: 통합 지옥을 끝낼 표준 규격

¹

• MCP(Model Context Protocol)는 이 혼란을 끝내기 위해 등장한 ‘통합 표준 규격’이다. 마치 수많은 기기의 충전 단자를 USB-C 하나로 통일한 것처럼, AI와 도구 간의 상호작용을 하나의 약속(프로토콜)으로 표준화한다.
• 지금까지 개별적으로 처리되던 아래의 필수 기능들을 공통 언어로 묶는다.

1. 기능 발견(Discovery): “저 도구는 어떤 기능을 가졌지?”
2. 호출 규격(Schema) 교환: “그 기능을 쓰려면 어떤 정보를 줘야 해?”
3. 상태 및 컨텍스트 전달: “이전 대화 내용을 참고해서 작업해 줘.”
4. 실시간 상호작용: 중간 결과물을 실시간으로 주고받기.
5. 보안 및 권한 설정: “이 도구는 읽기만 가능하고, 저 도구는 쓰기도 가능해.”
6. 사용 기록 추적(Auditability): “누가, 언제, 어떤 기능을 사용했는지” 기록.

• 이는 수많은 개발 환경(IDE)과 프로그래밍 언어의 조합을 ‘LSP(Language Server Protocol)’라는 단일 규약으로 표준화하여 플러그인 개발 지옥을 끝낸 것과 같은 원리다.
• 핵심 요약: “MCP는 AI 에이전트와 외부 시스템이 ‘의미, 실행, 맥락’을 안전하게 교환하기 위한 최소한의 공용어다.”

2. 핵심 아키텍처: Host – Client – Server

• MCP는 세 가지 구성요소로 역할을 명확히 나눈다. 이는 기능과 보안의 경계를 뚜렷하게 만드는 효과적인 설계다.

구성	역할	비유
Host	사용자 인터페이스/에이전트 실행 환경 (예: Claude Desktop, IDE)	브라우저/IDE
Client	Host 내부의 프로토콜 어댑터. 한 서버와 1:1 상태 연결	브라우저 탭 세션
Server	실제 기능/데이터/API를 외부에 제공	API 제공자 (Stripe, Jira 등)

2.1 구조적 특징: 격리를 통한 보안과 확장성

• 역할과 보안 경계의 분리: Host는 사용자와 상호작용하며 여러 Client를 관리한다. 각 Client는 정확히 하나의 Server와 연결되어, 하나의 독립된 작업 공간(세션)처럼 작동한다. 덕분에 권한과 로그 기록이 명확하게 분리(격리)된다.
• 횡적 이동(Lateral Movement) 방지: 만약 한 서버가 해킹(예: 프롬프트 인젝션 공격)당하더라도, 다른 서버로 피해가 번지는 ‘횡적 이동’ 위험을 크게 줄일 수 있다. 각 연결이 독립된 방처럼 격리되어 있기 때문이다.

• 모듈식 확장: 기존에는 새 기능을 추가하려면 전체 시스템을 수정해야 하는 ‘모놀리식(Monolithic)’ 방식이었다면, MCP는 기능을 독립적인 서버로 만들어 ‘플러그인’처럼 쉽게 추가하고 제거할 수 있다. 이는 팀 간 독립적인 개발, 배포, 버전 관리를 가능하게 한다.

• Client ↔ Server 는 1:1 관계: 세션, 권한, 보안이 명확히 격리된다.
• Host는 여러 Client를 조율: 여러 도구(서버)를 조합한 복잡한 작업이 가능하다.
• 기능은 ‘내장’이 아닌 ‘외부 플러그인’ 형태: 이는 소프트웨어 개발 패러다임이 ‘모놀리식’에서 ‘마이크로서비스’로 전환된 것과 유사한 구조적 변화다.

3. MCP 동작 원리: 간단한 예시

¹

• MCP의 동작 원리는 ‘카페 주문’ 과정에 비유하면 쉽게 이해할 수 있다.

• 손님 (Host): 최종 사용자 또는 AI 에이전트. “아이스 아메리카노 한 잔 주세요”라고 요청한다.
• 점원 (Client): 손님의 주문을 받아 바리스타에게 전달하는 중간 매개체.

• 바리스타 (Server): 커피를 만드는 실제 기술(Tool)을 가진 전문가.

• 이 과정을 MCP의 7단계 흐름으로 살펴보자.

1. 연결 (Connection)
   • 손님(Host)이 카페에 들어와 점원(Client)과 연결된다. 점원은 바리스타(Server)와 통신할 준비를 한다.
   • MCP: Host가 특정 Server와 통신할 Client를 생성하고 연결한다.
2. 메뉴판 요청 (Discovery)
   • 손님: “여기 뭐 팔아요?”
   • 점원이 메뉴판(사용 가능한 기능 목록)을 가져다준다.
   • MCP: Client가 Server에게 mcp/list 메시지를 보내 사용 가능한 Tool, Resource, Prompt 목록을 요청한다.
3. 메뉴 확인 (Schema Exchange)
   • 손님: “아이스 아메리카노는 어떻게 주문하나요?”
   • 점원: “원두 종류와 샷 추가 여부를 알려주시면 됩니다.”
   • MCP: Client가 특정 기능(예: add Tool)의 상세 정보(파라미터, 설명 등)를 Server로부터 받는다.
4. 주문 (Execution)
   • 손님: “산미 있는 원두로, 샷 추가해서 한 잔 주세요.”
   • 점원이 주문 내용을 정확히 바리스타에게 전달한다.
   • MCP: Host의 요청에 따라 Client가 Server에게 tool/execute 메시지를 보내 특정 Tool의 실행을 요청한다.
5. 제조 (Processing)
   • 바리스타가 주문에 맞춰 커피를 만든다.
   • MCP: Server가 요청받은 Tool을 실행하고 결과를 생성한다.
6. 결과 전달 (Response)
   • 바리스타가 완성된 커피를 점원에게 건네고, 점원은 손님에게 가져다준다.
   • MCP: Server가 실행 결과를 Client에게 반환하고, Client는 이를 다시 Host에게 전달한다.
7. 추가 요청 (Elicitation - 고급 기능)
   • 바리스타: “시럽은 얼마나 넣어드릴까요?”
   • 점원이 손님에게 다시 물어본다.
   • MCP: Server가 작업 중 추가 정보가 필요할 때, Client를 통해 Host에게 되물을 수 있다.

• 이처럼 MCP는 각자의 역할이 명확히 분리된 구성요소들이 표준화된 약속(프로토콜)에 따라 메시지를 주고받으며 협력하는 방식으로 동작한다.

4. 전송 방식과 프로토콜: 유연한 연결

• MCP는 ‘메시지 형식’과 ‘물리적 전송 방식’을 의도적으로 분리했다. 이는 필요에 따라 최적의 연결 방식을 선택할 수 있는 유연성을 제공한다.

계층	채택 기술	주된 용도
메시지 형식	JSON-RPC 2.0	안정적인 원격 호출 구조, 표준 에러 처리 등 상호운용성 확보.
전송 방식 (로컬)	stdio (표준 입출력)	내 컴퓨터 안에서 개발할 때 가장 간단하고 빠른 방식.
전송 방식 (원격)	Streamable HTTP / SSE	인터넷을 통해 원격 서버와 통신할 때 사용. 실시간 데이터 스트리밍에 유리.

• 핵심 포인트: 메시지의 ‘의미(무엇을 보낼지)’와 ‘전송(어떻게 보낼지)’을 분리했다. 덕분에 나중에 gRPC나 WebSocket 같은 새로운 통신 기술이 등장해도, 메시지 구조는 그대로 둔 채 전송 방식만 갈아 끼울 수 있다. 이를 ‘전송 다형성’이라 부르며, 장기적인 호환성을 보장하는 전략이다.

5. 세 가지 기본 요소: Tool, Resource, Prompt

• 기존의 함수 호출은 ‘실행’에만 초점이 맞춰져 있었다. MCP는 이를 넘어, 외부 세계와의 상호작용을 세 가지 유형으로 명확히 구분한다.

기본 요소	성격	HTTP 비유	예시
Tool	실행 (시스템에 변경을 일으킴)	POST / PUT	이슈 생성, Slack 메시지 전송
Resource	읽기 전용 데이터	GET	파일 내용 조회, 설정값 읽기
Prompt	재사용 가능한 템플릿 작업	Stored Procedure	정해진 형식의 보고서 요약, 분석 패턴 호출

• 이렇게 역할을 나누면 뭐가 좋을까?

• 세분화된 관리: ‘쓰기 기능(Tool)은 사용자 확인 필수’, ‘외부에 공개된 데이터(Resource)는 일부 내용 가리기’처럼 유형별로 다른 보안 정책을 적용하기 쉬워진다.
• 효율성 증대: 읽기 전용인 Resource는 결과를 캐시(임시 저장)하여 재사용하고, 비용이 비싼 Tool의 호출 횟수를 제한하는 등 최적화가 용이하다.
• 재사용성: Prompt를 독립적인 요소로 다루면(1급 시민), 자주 쓰는 프롬프트 패턴을 하나의 부품처럼 여기고 재사용, 버전 관리, 변경 이력 추적이 가능해진다.

6. 고급 양방향 기능: 단순 호출을 넘어선 대화

• 많은 개발자가 “도구는 그냥 호출해서 결과만 받으면 되는 것 아닌가?”라고 생각하지만, 실제 업무 자동화는 훨씬 더 복잡한 상호작용을 필요로 한다.

• MCP는 도구(서버)가 역으로 AI(호스트)에게 무언가를 요청할 수 있는 ‘양방향 소통’ 기능을 제공한다.

• 샘플링 (Sampling): 서버가 자체적인 AI 모델 없이, “이 부분은 네가 좀 더 잘하니, 이어서 글을 완성해 줘”라고 AI에게 작업을 위임하는 기능이다. 예를 들어, 서버는 데이터만 제공하고, 보고서의 특정 단락 생성은 호스트의 고성능 LLM에게 맡길 수 있다.
• 추가 정보 요청 (Elicitation): 사용자의 요청이 불분명하거나(예: “매출 리포트를 뽑아줘” → “어느 기간의 매출을 원하시나요?”), 민감한 작업을 수행하기 전(예: “정말로 데이터를 삭제하시겠습니까?”)에 사용자에게 추가 확인을 요청하는 기능이다. 안전성과 사용자 경험(UX)을 크게 향상시킨다.

• 접근 범위 제한 (Roots): 서버가 접근할 수 있는 파일이나 데이터의 범위를 미리 지정하여, 허용된 영역(allow-list) 밖으로는 절대 접근하지 못하도록 원천 차단하는 보안 기능이다.

• 이러한 양방향 기능 덕분에, MCP는 단순한 원격 호출의 나열을 넘어 ‘사람 ↔ AI ↔ 여러 도구’가 서로 대화하며 협력하는 복잡한 워크플로우를 만들 수 있다.

7. RAG / 함수 호출과의 비교: 각자의 역할

항목	RAG (검색 증강 생성)	함수 호출 (Function Calling)	MCP
주요 목적	외부 지식을 참고해 답변 생성	특정 기능(함수)을 실행	도구/데이터/프롬프트의 표준화된 연결
상태 관리	주로 없음 (매번 새로 검색)	없음 (단발성 호출)	세션(Client) 기반으로 상태 유지
상호작용	단방향 (검색 → 생성)	단방향 (호출 → 결과)	양방향 (대화형 워크플로우 가능)
확장성	도구 결합에 한계	N×M 연결 문제 발생	공용 프로토콜로 확장 용이

• RAG(Retrieval-Augmented Generation)는 AI가 더 정확한 답변을 하도록 외부 문서를 참고하게 하는 ‘지식 보강’ 기술이다.

• 함수 호출(Function Calling)은 AI가 특정 기능을 실행하도록 하는 단발성 명령이다.

• MCP는 이 둘을 대체하는 것이 아니라, 그보다 한 단계 위에서 이들을 포함한 다양한 도구와 데이터를 표준화된 방식으로 묶어주는 ‘조정 계층(Orchestration Layer)’ 역할을 한다. 즉, RAG의 검색 기능도 MCP 서버의 Resource와 Tool 조합으로 만들어 포함시킬 수 있다.

• 결론: MCP는 RAG를 대체하는 것이 아니라, AI의 ‘행동과 작업 흐름’을 표준화하는 더 큰 개념이다.

8. 개발자 생태계: fastmcp & langchain-mcp-adapters

• 실무에서는 보통 ‘도구나 데이터를 제공하는 백엔드 팀’과 ‘그것을 활용해 AI 서비스를 만드는 애플리케이션 팀’이 나뉘어 일한다. MCP 생태계의 핵심 도구인 fastmcp와 langchain-mcp-adapters는 각 팀의 생산성을 극대화한다.

구분	fastmcp	langchain-mcp-adapters
역할	MCP 서버를 쉽게 만들기 (제공자용)	MCP 서버를 LangChain/LangGraph에서 쉽게 쓰기 (소비자용)
사용법	Python 함수에 데코레이터(@mcp.tool) 추가	MultiServerMCPClient로 서버 연결 후 도구 로드
주 대상	백엔드/시스템 통합 개발자	AI 에이전트/워크플로우 설계자

• 이 구조 덕분에 ‘서버 → 어댑터 → 에이전트’로 이어지는 파이프라인이 느슨하게 연결된다. 백엔드 팀이 새로운 도구를 추가하거나 버전을 업데이트해도, 애플리케이션 팀은 최소한의 코드 수정만으로 이를 즉시 반영할 수 있다.

8.1 fastmcp 최소 예시

8.2 LangChain에서 소비 예시

9. 결론: AI용 표준 포트를 향해

• 패러다임의 전환: MCP는 단순한 기술 사양이 아니라, AI가 외부 세계와 상호작용하는 방식을 근본적으로 바꾸는 ‘AI용 USB-C’와 같다. Anthropic이 시작하고 OpenAI, Google, Microsoft 등 거대 기업들이 빠르게 동참하며, 고질적인 ‘N×M 통합 문제’를 해결할 표준으로 자리 잡고 있다.
• 개발 생태계의 성숙: fastmcp와 langchain-mcp-adapters 같은 도구들은 MCP 생태계가 이미 개발자 친화적인 단계에 접어들었음을 보여준다. 이들은 ‘도구 제공자’와 ‘소비자’의 역할을 명확히 분리하여, AI 시스템의 모듈성과 확장성을 크게 향상시킨다.

• 보안의 중요성: 그러나 강력한 기능은 프롬프트 인젝션, 공급망 공격 등 새로운 보안 위협을 동반한다. 따라서 MCP의 성공적인 도입은 각 도구 호출을 개별적으로 검증하는 ‘제로 트러스트(Zero Trust)’ 보안 모델을 채택하는 것에 달려 있다.

• 결국 MCP는 ‘외부 세계와 연결된 AI’를 당연하게 만드는 첫 단추다. 표준 포트가 열린 지금, 우리에게 남은 과제는 자신만의 도구를 어떻게 안전하게 연결하고, 그 위에 어떤 혁신적인 경험을 쌓아 올릴지 고민하는 것이다.

References

1. What is the Model Context Protocol (MCP)? ↩ ↩²