AI 기술 노트

Model Context Protocol MCP는 무엇을 풀려는 것인가

MCP는 공통 배선 규격입니다. AI 애플리케이션을 바깥의 데이터와 도구에 잇기 위한 것입니다. 여기서는 세 가지 역할, 제공되는 세 종류, 그리고 2026년 개정이 무엇을 뒤집었는지를 평이하게 설명합니다.

사양 개정판 2026-07-28을 기준으로

01 — 한마디로

어떤 AI 애플리케이션에서든 같은 방식으로 어떤 데이터 원본에도 이을 수 있게 한다. 그것이 MCP입니다.

정식 이름은 Model Context Protocol. Anthropic이 2024년에 제안했지만 2025년 12월부터는 Anthropic의 것이 아닙니다. 사양은 Agentic AI Foundation(Linux Foundation 아래에서 Block, OpenAI와 함께 설립)에 기증되었고, 지금은 커뮤니티가 운영합니다.

02 — 왜 필요한가

AI 애플리케이션이 4개, 잇고 싶은 곳이 5개 있다고 합시다. Google Drive, GitHub, 데이터베이스, Slack, 사내 API.

공통 규격이 없을 때

4 × 5 = 20

'앱 × 데이터 원본' 조합마다 그때그때 연결을 씁니다. 앱이 하나 늘면 5조, 데이터 원본이 하나 늘면 4조.

공통 규격이 있을 때

4 + 5 = 9

앱은 '클라이언트로 동작하는 법'을 한 번만 씁니다. 데이터 원본은 '서버로 동작하는 법'을 한 번만 씁니다.

이것이 N×M 문제입니다. MCP의 값어치는 이 한 문장에 담깁니다. 어떤 MCP 클라이언트도 어떤 MCP 서버에나 붙는다. USB와 같은 이야기입니다. 그 전에는 주변기기마다 전용 단자가 있었습니다.

03 — 세 가지 역할

MCP에는 세 가지 역할이 있습니다. 헷갈리는 것은 대개 앞의 둘입니다. 'MCP 클라이언트'라고 말할 때 머릿속에 떠오르는 것은 보통 Claude Desktop이지만, 그것은 호스트입니다.

MCP의 세 가지 역할 호스트 안에 클라이언트가 셋 있고 각각 서버 하나에 연결됩니다. 앞의 두 서버는 로컬, 세 번째는 원격입니다. 데이터베이스는 서버 바깥에 그려져 서버가 데이터 앞에 선 중개임을 보여 줍니다. HOST AI 애플리케이션 Client 1 Client 2 Client 3 Server A Server B Server C stdio(자식 프로세스) Streamable HTTP 당신의 데이터
클라이언트는 호스트 에 있고, 서버 하나당 하나입니다. 화살표는 언제나 클라이언트에서 출발합니다.
Host(호스트)
AI 애플리케이션 그 자체. Claude Desktop, VS Code, Claude Code가 모두 호스트입니다. 모델을 쥐고, 대화를 쥐고, 권한을 정합니다. 호스트란 그 '앱'입니다.
Client(클라이언트)
호스트 에 있는 연결 부품으로, 서버 하나당 하나. 앱이 아니라 앱 내부의 부품입니다. VS Code가 서버 두 개에 붙으면 클라이언트도 둘이 됩니다.
Server(서버)
도구와 데이터를 바깥에 내놓는 프로그램. 내 기계에서 돌릴 수도, 원격에 둘 수도 있습니다. 대화는 보이지 않고 다른 서버도 보이지 않습니다. 일부러 그렇게 설계했습니다.

04 — 서버가 내놓는 것

서버가 내놓는 것은 세 종류. 그 차이는 '읽기' 대 '쓰기'가 아닙니다. 거기가 가장 흔한 착각입니다.

진짜 차이는 누가 쓸지 정하는가입니다. 다음 세 장면에서 답은 각각 다릅니다.

답: Resource — 정하는 쪽은 앱

문서를 대화로 끌어다 놓거나, 호스트가 '이 질문에는 이 파일이 필요하다'고 판단하는 경우. 정하는 것은 이지 모델이 아닙니다. 모델은 그 내용을 받았을 뿐입니다.

흔한 예: 파일 내용, git 이력, 데이터베이스 스키마.

답: Tool — 정하는 쪽은 모델

"이 버그를 티켓으로 만들어 줘"라고 하면, 어떤 기능을 어떤 인자로 부를지는 모델이 스스로 정합니다. 정하는 것은 모델입니다.

여기가 핵심입니다. 읽기만 하는 조회도 tool이 될 수 있습니다. 모델이 스스로 '조회할지'를 정한다면 그것은 tool입니다. 그래서 '읽기=resource, 쓰기=tool'은 틀립니다.

답: Prompt — 정하는 쪽은 사용자

메뉴에서 '코드 리뷰'를 고르거나 슬래시 명령을 칩니다. 정하는 것은 당신입니다. 모델이 알아서 쓰러 가지 않습니다.

흔한 예: 슬래시 명령, 정형 메뉴.

├─ 세 장면의 차이는 하나뿐. 누가 정하는가.

05 — 어떻게 나르는가

표준은 둘입니다. stdio는 서버를 자식 프로세스로 띄우고 표준 입출력으로 주고받습니다. Streamable HTTP는 메시지 하나가 HTTP POST 한 번이 됩니다. 이것은 '어떻게 나르는가'의 차이지 '어디에 있는가'의 차이가 아닙니다. 내 기계에서 도는 서버도 Streamable HTTP를 말할 수 있습니다.

알아 둘 값어치가 있는 것은 보안이 전혀 다르다는 점입니다. stdio는 당신의 권한을 그대로 물려받고 인증 계층이 없습니다. HTTP 쪽은 OAuth가 필요하고 보낸 곳 확인이 필요합니다. 그리고 '로컬 서버'란 '내 기계에서 돈다'는 뜻이지 바깥으로 나가지 않는다는 뜻이 아닙니다. 로컬 서버도 원격 API를 두드립니다.

06 — 이 판에서 바뀐 것

서버는 이제 아무것도 기억하지 않습니다.

2026-07-28은 MCP가 나온 이래 가장 큰 개정이며 하위 호환을 깨는 변경입니다. 전에는 클라이언트가 서버와 악수해 연결을 만들고, 그 뒤로 서로를 기억했습니다. 지금은 악수도, 연결 단계도 없습니다. 모든 요청이 스스로 버전과 신원을 지고 오며, 서버는 처리하고 나면 잊습니다.

방향도 바뀌었습니다. 서버가 되물어 오는 일은 없습니다. "이게 필요하다"고 돌려주고 그 요청은 거기서 끝납니다. 답을 얻은 클라이언트가 다시 한 번 보냅니다.

다른 데서 이런 것을 보면 그 자료는 낡은 것

  • ├─ initialize 악수
  • ├─ Mcp-Session-Id 헤더, 프로토콜 층의 세션
  • ├─ 서버가 스스로 클라이언트에 요청을 보내는 것
  • └─ pinglogging/setLevel 두 메서드

세 번째는 오해되기 쉬우니 분명히 적습니다. '서버가 이제 아무것도 요구할 수 없다'는 뜻이 아닙니다. 사라진 것은 '스스로 보내는' 장치이지, 요구를 낼 능력이 아닙니다. 전에는 서버가 요청을 곧바로 밀어 넣을 수 있었습니다. 지금은 응답 안에서 "이게 필요하다"고 말하고 끝내며, 나머지는 클라이언트가 이어받습니다.

그래서 '서버가 클라이언트에 무언가를 구하는' 기능은 모두 남아 있습니다. 지나는 길이 바뀌었을 뿐입니다. Elicitation(사용자에게 정보 하나를 구함)도 Sampling(호스트의 모델을 빌림. 방향이 직관과 반대라 특히 오해가 많습니다)도 마찬가지입니다.

이와는 별개로 Roots(작업 디렉터리 범위를 서버에 알림), Sampling, Logging 세 가지가 비권장으로 표시됐습니다. 아직 동작하지만 현행 구조로 익히지 않는 편이 좋습니다. 비권장과 위의 장치 변경은 다른 이야기입니다. 하나는 '어떻게 나르는가', 다른 하나는 '남길 것인가'입니다.

07 — 이 페이지가 가리키는 판

MCP의 버전은 날짜 그 자체입니다. 가리키는 것은 '마지막으로 호환을 깨는 변경을 한 날'이지 릴리스 주기가 아닙니다. 그래서 손에 든 MCP 자료는 대응하는 날짜만 보면 얼마나 새것인지 알 수 있습니다. 이 페이지에서 가져갈 값어치가 가장 큰 것이 이 한 가지입니다.

2024-11-05 → 2025-03-26 → 2025-06-18 → 2025-11-25 → 2026-07-28

날짜에 매인 서술

  • 앞 절 「이 판에서 바뀐 것」은 2026-07-28에 대해서만 성립합니다.
  • 비권장이 된 세 가지가 실제로 제거되는 것은 일러야 2027-07-28 이후의 어느 판입니다.
  • 사양에서 연결 단계가 사라진 것과, 현실의 서버가 무상태가 된 것은 다릅니다. 이미 돌고 있는 많은 서버가 낡은 판을 계속 말하고 있고, 이 간격은 한동안 남습니다.