인공지능(AI) 모델은 놀라울 정도로 똑똑해졌지만, 여전히 치명적인 단점이 하나 있다. 바로 ‘고립’되어 있다는 점이다. 아무리 뛰어난 AI라도 내 컴퓨터에 저장된 엑셀 파일을 직접 열어보거나, 회사의 사내 데이터베이스에 접속하여 실시간 매출 현황을 분석하는 것은 쉽지 않다. 지금까지 우리는 필요한 데이터를 일일이 복사해서 프롬프트 창에 붙여넣거나, 복잡한 API를 개발해야만 했다. 하지만 이제 그 번거로움이 사라질 전망이다.
앤스로픽(Anthropic)이 공개한 MCP(Model Context Protocol)가 바로 그 해답이다. “AI를 위한 USB-C 포트”라고 불리는 이 기술은 AI 모델과 외부 데이터 시스템을 연결하는 표준화된 규약이다. 왜 개발자들과 테크 기업들은 이 기술에 열광하는 것일까? 오늘은 고립된 AI를 진정한 ‘비서(Agent)’로 진화시키는 핵심 열쇠, MCP의 개념부터 작동 원리, 그리고 활용 방법까지 상세하게 알아보겠다.
MCP의 정의와 등장 배경: AI 연결의 표준화
MCP(Model Context Protocol)는 대규모 언어 모델(LLM)이 외부 데이터나 도구(Tool)와 안전하고 쉽게 소통할 수 있도록 만든 오픈 표준 프로토콜이다. 2024년 말, 클로드(Claude)의 개발사 앤스로픽이 오픈소스로 공개하며 세상에 알려졌다.
이해를 돕기 위해 컴퓨터의 역사와 비교해 보자. 과거에는 프린터, 마우스, 키보드의 연결 단자가 제각각이었다. 하지만 USB라는 표준이 등장하면서 어떤 기기든 포트에 꽂기만 하면 바로 작동하게 되었다. MCP가 바로 AI 생태계의 USB 역할을 한다.
- 기존의 문제점 (Silo): 이전에는 AI를 슬랙(Slack), 구글 드라이브(Google Drive), 깃허브(GitHub)와 연결하려면 각각의 서비스마다 별도의 통합 코드를 작성해야 했다. 이는 개발자에게 엄청난 유지보수 부담을 안겨주었다.
- MCP의 해결책: 데이터를 제공하는 쪽(서버)과 AI 모델(클라이언트) 사이에 공통된 언어(프로토콜)를 정의함으로써, 한 번만 연결 통로를 만들어두면 어떤 AI 모델이든 자유롭게 해당 데이터를 가져다 쓸 수 있게 되었다.
MCP의 아키텍처와 작동 원리
MCP의 구조는 크게 세 가지 요소로 구성된다. 이 구조를 이해하면 어떻게 내 로컬 컴퓨터의 파일을 AI가 읽을 수 있는지 알게 된다.
1. MCP 호스트 (Host)
사용자가 실제로 상호작용하는 AI 애플리케이션이다. 대표적인 예로 ‘클로드 데스크톱 앱(Claude Desktop App)’이나 ‘Cursor’, ‘Zed’ 같은 IDE(통합 개발 환경)가 있다. 호스트는 사용자의 요청을 받아 MCP 클라이언트를 통해 필요한 정보를 찾아오라고 지시한다.
2. MCP 클라이언트 (Client)
호스트와 서버 사이를 이어주는 중개자 역할을 한다. 호스트 애플리케이션 내부에 탑재되어 있으며, 서버와 1:1로 통신하며 데이터를 요청하고 응답을 받아온다.
3. MCP 서버 (Server)
실제 데이터가 있는 곳과 연결되는 다리다. 여기가 핵심이다.
- 파일시스템 서버: 내 컴퓨터의 특정 폴더를 AI가 읽을 수 있게 해준다.
- 데이터베이스 서버: PostgreSQL이나 SQLite 같은 DB에 AI가 직접 쿼리를 날릴 수 있게 해준다.
- API 통합 서버: 슬랙, 깃허브, 구글 맵 등의 외부 서비스와 연결한다.
[구체적인 활용 예시]
사용자가 클로드 데스크톱 앱(호스트)에서 “내 프로젝트 폴더에 있는 main.py 파일의 버그를 찾아서 고쳐줘”라고 입력한다고 가정해 보자.
- MCP 클라이언트가 로컬 파일시스템에 연결된 ‘MCP 서버’에게 해당 파일의 내용을 요청한다.
- 서버는 안전한 경로 내에서 파일을 읽어 텍스트 형태로 클라이언트에게 전달한다.
- 클로드(AI)는 이 내용을 읽고 분석하여 수정된 코드를 제안한다.이 모든 과정이 데이터를 복사-붙여넣기 할 필요 없이 대화만으로 이루어진다.
MCP 도입의 장단점과 필수 주의사항
MCP는 강력하지만, 아직 초기 단계의 기술이므로 장단점이 명확하다.
장점 (Pros)
- 확장성(Scalability): 개발자는 한 번만 MCP 서버를 구축하면, 클로드뿐만 아니라 향후 MCP를 지원하는 모든 AI 모델(오픈AI, 제미나이 등)에서 해당 데이터를 사용할 수 있다.
- 보안(Security): 데이터를 클라우드에 업로드하지 않고, 로컬(Local) 환경에서 AI와 연결할 수 있다. 이는 기업의 민감한 데이터를 다룰 때 매우 큰 강점이다.
- 에이전트(Agent)화 가속: 단순히 정보를 읽는 것을 넘어, 코드를 실행하거나 파일을 생성하는 등 실질적인 ‘행동’을 하는 AI를 구축하기가 훨씬 쉬워졌다.
단점 및 주의사항 (Cons & Caution)
- 초기 설정의 복잡성: 현재 시점에서는 GUI(그래픽 인터페이스) 설정보다는 JSON 설정 파일을 직접 수정하거나 터미널 명령어를 사용해야 하는 경우가 많아 일반 사용자에게는 진입 장벽이 있다.
- 권한 관리의 중요성: AI에게 내 컴퓨터의 파일 시스템 접근 권한이나 코드 실행 권한을 부여하는 것이므로, 신뢰할 수 없는 MCP 서버를 설치하면 보안 사고로 이어질 수 있다. 검증된 소스(Official Repository)의 서버만 사용해야 한다.
- 호환성: 아직은 앤스로픽의 클로드 데스크톱이 가장 완벽하게 지원하며, 다른 플랫폼들의 지원은 점차 확대되는 추세다.
실제로 붙여 본 MCP 프로토콜
개념만으로는 감이 안 오니 참조 서버에 직접 붙어 주고받는 메시지를 확인했습니다. MCP 는 JSON-RPC 2.0 위에 올라가 있어서, 표준 입출력으로도 손으로 붙일 수 있습니다.
연결과 협상
첫 메시지는 initialize 입니다. 클라이언트가 지원하는 프로토콜 버전을 제시하고 서버가 자기 능력을 알려줍니다.
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
"protocolVersion":"2025-06-18",
"capabilities":{},
"clientInfo":{"name":"probe","version":"1.0"}}}돌아온 응답입니다.
협상된 protocolVersion: 2025-06-18
serverInfo: {'name': 'mcp-servers/everything',
'title': 'Everything Reference Server', 'version': '2.0.0'}
서버 capabilities 키: ['completions', 'logging', 'prompts',
'resources', 'tasks', 'tools']capabilities 협상이 프로토콜의 핵심입니다. 서버가 무엇을 제공하는지 먼저 선언하고, 클라이언트는 그 안에서만 요청합니다. 그래서 서버 구현이 부분적이어도 클라이언트가 깨지지 않습니다.
협상이 끝나면 클라이언트가 notifications/initialized 알림을 보냅니다. 이 알림에는 id가 없습니다 — 응답을 기대하지 않는 단방향 메시지입니다.
도구 목록 — 스키마가 함께 온다
{"jsonrpc":"2.0","id":2,"method":"tools/list"}tools/list: 13개
- echo Echoes back the input string required=['message']
- get-env Returns all environment variables required=None
- get-resource-links Returns up to ten resource links required=None각 도구가 JSON Schema 형태의 inputSchema를 함께 보냅니다. 이것이 MCP 가 “AI 가 도구를 쓸 수 있게” 하는 방식입니다 — 모델이 문서를 읽고 추측하는 게 아니라 기계가 읽을 수 있는 스키마를 받습니다. 필수 인자, 타입, 설명이 모두 구조화돼 있습니다.
도구 호출
{"jsonrpc":"2.0","id":3,"method":"tools/call",
"params":{"name":"echo","arguments":{"message":"안녕하세요"}}}{
"content": [
{ "type": "text", "text": "Echo: 안녕하세요" }
]
}결과가 content 배열입니다. type이 있어서 텍스트뿐 아니라 이미지나 리소스 참조도 같은 형식으로 돌려줄 수 있습니다.
오류는 JSON-RPC 에러가 아니다
여기서 구현할 때 헷갈리는 부분이 있습니다. 필수 인자를 빼고 호출해 봤습니다.
{"jsonrpc":"2.0","id":3,"method":"tools/call",
"params":{"name":"echo","arguments":{}}}{
"result": {
"content": [
{ "type": "text",
"text": "MCP error -32602: Input validation error: Invalid arguments for
tool echo: Invalid input: expected string, received undefined at message" }
],
"isError": true
},
"jsonrpc": "2.0",
"id": 3
}JSON-RPC 의 error 필드가 아니라 result 안에 isError: true 로 옵니다. 도구 실행 실패는 프로토콜 오류가 아니라 정상 응답이라는 설계입니다.
이유가 있습니다. 도구가 실패한 사실을 모델이 읽고 판단해야 하기 때문입니다. 프로토콜 오류로 처리하면 클라이언트 라이브러리가 예외를 던지고 끝나지만, isError 로 오면 모델이 오류 메시지를 보고 인자를 고쳐 다시 시도할 수 있습니다. MCP 서버를 만들 때 도구 내부 예외를 프로토콜 에러로 던지지 말아야 하는 이유입니다.
전송 방식 — SSE 는 폐기됐다
참조 서버가 지원하는 전송 방식을 보면 현재 상황이 드러납니다.
$ npx -y @modelcontextprotocol/server-everything --help
Usage: node ./index.js [stdio|sse|streamableHttp]
Default transport: stdio| 전송 | 용도 | 현재 상태 |
|---|---|---|
stdio | 로컬 프로세스로 실행되는 서버 | 표준. 로컬 도구는 이것을 쓴다 |
streamableHttp | 원격 서버 | 신규 원격 서버는 이것을 쓴다 |
sse | 원격 서버 (구 방식) | 폐기. 2024-11 사양의 HTTP+SSE 는 더 이상 쓰지 않는다 |
2026년 중반부터 주요 MCP 클라이언트가 SSE 지원을 끊었습니다. 지금 원격 MCP 서버를 새로 만든다면 Streamable HTTP 가 유일한 선택입니다. SSE 기준으로 작성된 예제를 보고 따라 만들면 클라이언트가 붙지 못합니다.
원격 서버라면 인가가 필수다
stdio 로 로컬에서 돌리면 인가가 필요 없습니다. 프로세스 경계가 곧 신뢰 경계입니다. 하지만 원격 서버는 다릅니다. MCP 인가 사양은 OAuth 2.1 기반이고 클라이언트에 PKCE(S256) 구현을 의무화합니다.
특히 인가 서버 메타데이터에 code_challenge_methods_supported 가 없으면 진행을 거부하라고 명시합니다. 자세한 내용은 OAuth 2.1 변경점 정리에 정리해 두었습니다 — MCP 가 왜 하필 OAuth 2.1 을 골랐는지, 혼동된 대리인 문제와 어떻게 연결되는지도 함께 다룹니다.
직접 붙여 보는 방법
설치 없이 참조 서버로 프로토콜을 확인할 수 있습니다.
# 참조 서버를 stdio 로 실행하고 표준 입력으로 JSON-RPC 를 던진다
npx -y @modelcontextprotocol/server-everything stdio
# 첫 줄에 이것을 붙여넣으면 initialize 응답이 돌아온다
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1.0"}}}메시지는 줄바꿈으로 구분된 JSON 한 줄씩입니다. 이 구조를 한 번 손으로 보면 어떤 언어로 서버를 만들어도 헤매지 않습니다.
이 절의 요청·응답은 @modelcontextprotocol/server-everything 2.0.0 에 stdio 로 직접 접속해 받은 실제 메시지입니다(2026년 9월, 협상된 프로토콜 버전
2025-06-18). MCP 사양은 개정이 빠르므로 구현 전 최신 사양 날짜를 확인하세요.
정리
지금까지 AI 연결성의 혁명이라 불리는 MCP(Model Context Protocol)에 대해 알아보았다. 요약하자면, MCP는 AI가 우리 컴퓨터의 파일, 데이터베이스, 그리고 각종 업무 툴과 직접 대화할 수 있게 해주는 ‘공용 통역기’이자 ‘연결 표준’이다.
필자의 견해로는, 앞으로 “AI를 얼마나 잘 쓰는가”는 “MCP 서버를 얼마나 잘 구성하여 내 데이터를 연결하는가”에 달려 있다고 본다. 이제 더 이상 텍스트를 복사하느라 시간을 낭비하지 말자. 개발자라면 지금 당장 깃허브에서 MCP SDK를 다운로드하여 나만의 서버를 구축해 보고, 일반 사용자라면 클로드 데스크톱을 설치하여 로컬 파일 연동의 편리함을 경험해 보기를 강력히 추천한다. AI는 이제 채팅창을 넘어, 당신의 워크스테이션 깊숙한 곳까지 도와줄 준비가 되었다.
“MCP(Model Context Protocol)란? AI와 데이터를 연결하는 차세대 표준 가이드”에 대한 1개의 생각