AI/Engineering

MCP란? AI 앱과 도구를 잇는 표준 규격 MCP 구조 쉽게 정리 (호스트·클라이언트·서버, 도구·리소스·프롬프트)

agentnote 2026. 10. 18. 10:47

요약. MCP(Model Context Protocol)는 AI 앱과 바깥 도구·데이터를 잇는 공통 규격입니다. 예전에는 AI 앱마다, 도구마다 연결 코드를 따로 짰습니다. MCP를 쓰면 도구 쪽은 "MCP 서버"를 한 번 만들고, MCP를 아는 AI 앱이면 어디서나 그 서버를 붙여 씁니다. 서버가 내놓는 것은 세 가지입니다. 모델이 골라 쓰는 도구, 앱이 골라 붙이는 리소스, 사용자가 골라 쓰는 프롬프트입니다.

4화에서 이어지는 질문: 도구는 어디서 오나

1막(0~4화)에서는 에이전트가 무엇이고 어떻게 도는지 봤습니다. 2화에서는 모델이 "이 도구를 이 값으로 불러 줘"라고 글자를 쓰면 프로그램이 대신 실행한다는 것을 봤습니다.

그런데 그 도구 목록은 누가 만들까요? 2화 예제에서는 앱을 만드는 사람이 날씨 조회 함수를 직접 짜서 넣었습니다. 파일을 읽고, 깃허브 이슈를 보고, 일정을 확인하는 도구도 다 그렇게 넣어야 할까요? 그리고 Claude 앱, 코드 편집기, 사내 챗봇처럼 AI 앱이 여러 개면 같은 도구를 앱마다 다시 짜야 할까요?

2막(세상과 연결되기)의 첫 질문입니다. 이번 화는 이 문제를 푸는 공통 규격, MCP의 구조를 다룹니다.

MCP가 푸는 문제: 앱 N개 × 도구 M개

AI 앱이 3개이고 붙이고 싶은 도구가 3개라고 해 봅시다. 앱마다 도구마다 연결 코드를 따로 짜면 연결이 9개 필요합니다. 앱이나 도구가 하나 늘 때마다 연결 수는 곱으로 늘어납니다.

Anthropic의 Mahesh Murag는 MCP 워크숍에서 이를 "N×M 문제"라고 부르고, MCP가 이것을 평평하게 만들려 한다고 설명합니다. 앱은 MCP를 한 번 맞추고, 도구도 MCP를 한 번 맞춥니다. 그러면 연결은 앱 수 더하기 도구 수, 3+3=6개면 됩니다.

그림 1. 앱과 도구가 각자 규격 하나만 맞추면 됩니다.

MCP 공식 소개 페이지는 MCP를 "AI 앱을 위한 USB-C 포트"에 비유합니다. 기기마다 충전 단자가 다르면 케이블을 기기마다 챙겨야 합니다. 단자가 USB-C 하나면 같은 케이블이 어디에나 맞습니다. MCP 서버는 USB-C 단자를 단 주변기기, MCP를 지원하는 AI 앱은 USB-C 포트가 있는 노트북인 셈입니다.

다만 비유와 다른 점이 하나 있습니다. 케이블은 꽂으면 전기가 흐르고 끝이지만, MCP는 꽂은 뒤에 대화를 합니다. 앱이 서버에 "무엇을 할 수 있나요?"라고 묻고, 받은 목록에서 골라 부릅니다. 이 대화가 실제로 어떻게 생겼는지는 아래에서 직접 봅니다.

MCP는 Anthropic이 2024년 11월에 공개했고, 2025년 12월 Linux Foundation 산하 재단(Agentic AI Foundation)에 기증했습니다. 지금은 한 회사의 기능이 아니라 공개 규격입니다.

MCP 구조: 호스트, 클라이언트, 서버

MCP에는 세 역할이 나옵니다.

  • 호스트: 사용자가 쓰는 AI 앱입니다. Claude 앱이나 코드 편집기 같은 것입니다.
  • 서버: 도구와 데이터를 내놓는 쪽입니다. 파일 서버, 깃허브 서버, 일정 서버처럼 하나가 한 가지 영역을 맡습니다.
  • 클라이언트: 호스트 안에서 서버 하나와 연결을 맡는 부분입니다.

MCP 명세는 호스트가 클라이언트 여럿을 만들고 관리하며, 클라이언트 하나는 서버 하나와 1대1로 연결된다고 정의합니다. 서버를 세 개 붙이면 호스트 안에 클라이언트가 세 개 생기는 구조입니다.

그림 2. 호스트 하나에 클라이언트 여럿, 클라이언트 하나에 서버 하나.

이 구조에서 중요한 점은 모델이 서버와 직접 이야기하지 않는다는 것입니다. Anthropic의 MCP 대담에서 MCP 공동 제작자 David Soria Parra는 "모델은 API와 직접 대화하지 않는다"고 말합니다. 모델이 보는 것은 호스트가 건네준 도구 설명과 결과뿐입니다. 서버를 부르고, 결과를 모델에게 넘기고, 위험한 실행을 막는 일은 호스트가 합니다. 2화에서 본 "모델은 글자만 쓰고 실행은 프로그램이 한다"와 같은 구조입니다.

서버가 내놓는 세 가지: 도구, 리소스, 프롬프트

MCP 서버가 내놓는 것은 세 종류입니다. 셋을 가르는 기준은 누가 고르느냐입니다.

그림 3. 세 가지 기본 요소와 각각을 고르는 주체. 명세의 정의를 따랐습니다.

  • 도구 (모델이 고름): 파일 읽기, 이슈 만들기처럼 실행하는 기능입니다. 모델이 도구 설명을 보고 언제 부를지 정합니다. 2화의 함수 호출이 바로 이것입니다.
  • 리소스 (앱이 고름): 파일 내용, 문서, 데이터처럼 읽을거리입니다. 앱이 어떤 것을 모델에게 보여 줄지 정합니다. 사용자가 대화에 파일을 첨부하는 모습을 떠올리면 됩니다.
  • 프롬프트 (사용자가 고름): "이 코드 리뷰해 줘"처럼 미리 만들어 둔 지시문 틀입니다. 사용자가 슬래시 명령 같은 메뉴에서 골라 씁니다.

Mahesh Murag는 리소스를 왜 도구로 합치지 않았냐는 질문에 "모델이 고르는 것과 앱이 고르는 것을 깔끔하게 나누고 싶었다"고 답합니다. 누가 고르느냐가 다르면 권한과 안전장치도 달라지기 때문입니다.

실제로 주고받는 메시지: 공식 파일 서버에 물어보기

구조를 봤으니 실제 대화를 볼 차례입니다. MCP 공식 저장소의 참조 서버 중 하나인 파일 서버(server-filesystem)를 띄우고, 허용 폴더를 하나로 정한 뒤 메시지를 보내 보면 아래처럼 대화가 오갑니다. 메시지는 JSON-RPC라는 형식의 짧은 JSON 한 줄씩입니다.

그림 4. 2026-10-16에 공식 파일 서버(npm 1.0.0)와 주고받은 실제 응답을 줄였습니다.

흐름은 이렇습니다.

  1. 인사. 클라이언트가 initialize로 자기가 아는 규격 판과 기능을 알리면, 서버가 자기 이름과 판(2025-11-25)을 답합니다.
  2. 목록 묻기. tools/list를 보내자 도구 14개가 왔습니다. 파일 읽기, 쓰기, 고치기, 폴더 만들기, 검색 같은 것들입니다. 도구마다 이름, 설명, 받을 값의 모양이 붙어 있습니다. 이 설명이 그대로 모델에게 건네지는 도구 설명이 됩니다.
  3. 부르기. tools/call로 허용 폴더 안의 notes.txt를 읽게 하자 내용("회의록: 다음 주 화요일 배포")이 돌아왔습니다.
  4. 거절. 허용 폴더 밖의 시스템 파일을 읽게 하자 "허용된 폴더 밖"이라는 오류가 돌아왔습니다.

두 가지가 눈에 띕니다. 하나는 안전장치가 서버에도 있다는 점입니다. 모델이 엉뚱한 파일을 읽으려 해도 서버가 막습니다. 다른 하나는 응답 순서입니다. 3번과 4번을 연달아 보냈는데 4번 답이 먼저 왔습니다. 그래서 메시지마다 번호(id)를 붙여 어느 질문의 답인지 짝을 맞춥니다.

MCP 연결 방식은 지금 바뀌는 중

여기까지가 판이 바뀌어도 그대로인 부분입니다. 이제 바뀌는 부분입니다.

원본 레슨 13-06 MCP Fundamentals는 위 4번 같은 "인사"가 없는 방식을 가르칩니다. 2026년 7월 28일에 나온 MCP 명세 최신판이 인사 절차와 연결 단위 세션을 없앴기 때문입니다. 대신 요청마다 "나는 이 판을 쓰고, 이런 기능이 있다"는 자기소개를 붙입니다. 명세는 이를 "MCP는 무상태 프로토콜"이라고 적습니다.

그림 5. 왼쪽은 많이 쓰는 공식 서버가 지금 쓰는 방식, 오른쪽은 명세 최신판.

왜 바꿨을까요? 레슨의 설명은 이렇습니다. 서버 한 대가 여러 클라이언트의 요청을 번갈아 받을 때, 앞 요청에서 들은 정보를 기억해 두면 다음 요청에 엉뚱한 권한을 적용할 수 있습니다. 요청이 스스로를 설명하면 어느 서버가 받아도 같은 판단을 내립니다. 원격 서버를 여러 대로 늘리기도 쉬워집니다.

그런데 위 실험의 공식 파일 서버는 아직 인사하는 쪽(2025-11-25 판)입니다. 최신판의 첫 요청인 server/discover를 보내자 "그런 메서드 없음"으로 답했습니다. 최신판으로 인사를 청해도 2025-11-25로 낮춰서 답했습니다. 이 서버가 쓰는 공식 TypeScript SDK(1.32.0)도 2025-11-25를 최신으로 알고 있었습니다. 명세는 앞서가고, 도구들은 따라가는 중입니다.

4화에서 모델이 빨리 바뀌어도 남는 것을 이야기했습니다. MCP도 비슷합니다. 연결 절차는 최신판에서 크게 바뀌었지만, 호스트·클라이언트·서버 구조와 "도구는 모델이, 리소스는 앱이, 프롬프트는 사용자가 고른다"는 기준은 그대로입니다. 처음 공부할 때는 이 뼈대를 잡아 두고, 연결 절차는 쓰는 SDK의 판을 확인하면 됩니다.

레슨 코드로 돌려 보면

원본 레슨 두 편의 예제는 외부 패키지 없이 Python만으로 돌아가고, 함께 들어 있는 테스트도 모두 통과합니다(13-06 7개, 13-09 18개). 다만 설명하는 범위보다 코드가 좁습니다.

  • 13-06 본문은 도구·리소스·프롬프트 세 가지를 설명하지만, 예제 서버는 도구만 처리합니다. 리소스나 프롬프트를 요청하면 "그런 메서드 없음"이 돌아옵니다. 검색 도구도 실제로 검색하지 않고, 받은 검색어를 문장에 끼워 돌려줍니다. 메시지 모양을 보여 주는 예제로 보면 됩니다.
  • 13-09 MCP Transports 본문은 연결 통로 두 가지(아래 "더 깊이")를 다 설명하지만, 코드는 HTTP 쪽만 있습니다.

따라 해 보기

1. 레슨 예제로 메시지 모양 보기 (Python만 있으면 됨).

curl -O https://raw.githubusercontent.com/rohitg00/ai-engineering-from-scratch/main/phases/13-tools-and-protocols/06-mcp-fundamentals/code/main.py
python3 main.py

요청 네 개와 응답이 차례로 출력됩니다. 요청마다 _meta 안에 판과 기능이 반복해서 들어 있는지, 마지막 요청(없는 판 2027-01-01)이 어떤 오류를 받는지 보세요.

2. 공식 파일 서버에 직접 물어보기 (Node.js 필요). 빈 폴더 하나를 만들고 안에 텍스트 파일을 하나 넣은 뒤, 서버를 띄워 메시지를 보냅니다. 아래는 위 실험의 요청 세 개를 줄인 것입니다.

mkdir -p ~/mcp-test && echo "hello mcp" > ~/mcp-test/notes.txt
printf '%s\n' \
 '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"me","version":"0"}}}' \
 '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
 '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
 | npx -y @modelcontextprotocol/server-filesystem ~/mcp-test

인사에 대한 답과 도구 목록이 JSON으로 나옵니다. 앱이 서버에 붙을 때 화면 뒤에서 오가는 대화가 이것입니다.

이런 데 쓸 수 있다

  • 팀 문서 폴더를 읽기 전용으로 연결하기. 파일 서버를 허용 폴더 하나로 묶어 AI 앱이 팀 문서를 찾아 읽게 합니다. 쓰기 도구는 끄거나 사람 승인을 거치게 둡니다.
  • 자주 쓰는 사내 조회 기능을 서버 하나로 만들기. 채팅 도구, 코드 편집기, 사내 챗봇에 따로 붙이던 기능을 MCP 서버 하나로 만들면 MCP를 아는 앱 어디서나 씁니다. 서버를 직접 만드는 법은 6화에서 다룹니다.
  • 팀 공용 지시문을 프롬프트로 내놓기. "주간 보고 정리" 같은 팀 템플릿을 서버의 프롬프트로 두면, 사용자가 메뉴에서 골라 씁니다.

자주 묻는 질문

Q. MCP와 함수 호출(Function Calling)은 무엇이 다른가요? 함수 호출은 모델이 "이 도구를 이 값으로"라고 쓰는 방식이고, MCP는 그 도구를 어디서 가져오고 어떻게 부르는지에 대한 규격입니다. MCP 서버가 내놓은 도구 목록이 호스트를 거쳐 모델에게 함수 호출용 도구 설명으로 건네집니다. 둘은 경쟁 관계가 아니라 위아래 층입니다. 함수 호출은 2화에서 다뤘습니다.

Q. MCP는 Claude에서만 쓰나요? 아닙니다. Anthropic이 만들었지만 2025년 12월 Linux Foundation 산하 Agentic AI Foundation에 기증한 공개 규격입니다. Mahesh Murag의 워크숍(2025년 2월)만 해도 Claude 앱 말고 여러 코드 편집기와 에이전트 도구가 MCP 클라이언트로 나옵니다.

Q. 아무 MCP 서버나 붙여도 안전한가요? 조심해야 합니다. 서버의 도구 설명은 그대로 모델에게 들어가고, 도구는 실제로 파일을 쓰거나 지울 수 있습니다. 믿을 수 있는 서버만 붙이고, 허용 범위를 좁히고, 쓰기 도구는 승인을 거치게 하는 것이 기본입니다. MCP 보안은 4막(15화)에서 따로 다룹니다.

더 깊이: MCP 명세, 강의 세 편, 보안 논문, 코드

MCP 명세 2026-07-28 (최신판). 명세가 이번 화의 주 출처입니다. 판은 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25를 거쳐 2026-07-28이 최신입니다. 메시지 형식은 JSON-RPC 2.0입니다. 요청에는 번호(id)와 메서드 이름이 붙고, 응답은 같은 번호로 결과나 오류를 돌려줍니다. 서버의 세 기본 요소는 메서드로 나뉩니다. 도구는 tools/list와 tools/call, 리소스는 resources/list와 resources/read, 프롬프트는 prompts/list와 prompts/get입니다. 변경 기록의 큰 변화는 이렇습니다. initialize 인사와 프로토콜 세션을 없앴습니다. 요청마다 _meta에 판(io.modelcontextprotocol/protocolVersion)과 클라이언트 기능을 반드시 싣습니다. 서버는 판과 기능을 알려 주는 server/discover를 반드시 구현합니다. 모르는 판이 오면 오류 코드 -32022와 지원하는 판 목록을 돌려줍니다. 서버가 먼저 클라이언트에게 요청을 보내던 방식도 없앴습니다. 서버가 사용자에게 물어볼 것이 있으면 "입력 필요" 결과를 돌려주고, 클라이언트가 답을 붙여 원래 요청을 다시 보냅니다. 클라이언트 쪽 기능 중 sampling, roots, logging은 폐지 예정이고, 서버가 사용자에게 추가 정보를 묻는 elicitation만 남았습니다. 옛 판의 인사 절차는 2025-11-25 명세의 lifecycle에 있습니다.

연결 통로 두 가지 (원본 레슨 13-09). 앱이 서버를 자기 컴퓨터에서 직접 띄울 때는 stdio를 씁니다. 표준 입력에 JSON 한 줄을 쓰고, 표준 출력으로 답을 받습니다. 위 실험과 "따라 해 보기"가 이 방식입니다. 네트워크 너머 서버에는 Streamable HTTP를 씁니다. 최신판에서는 주소 하나(/mcp)에 요청마다 POST를 보내고, 답은 JSON 하나나 그 요청 전용 스트림으로 받습니다. 세션 번호(Mcp-Session-Id)와 끊긴 스트림 이어 받기는 없어졌습니다. 레슨은 HTTP 헤더에 메서드와 도구 이름을 한 번 더 적고 본문과 같은지 확인해야 한다고 강조합니다(다르면 -32020). 중간 관문이 헤더만 보고 "읽기"를 허락했는데 본문은 "삭제"를 실행하는 혼동을 막기 위해서입니다. 레슨 예제 서버로 확인하면 잘못된 Origin은 403, 헤더 불일치는 -32020, 모르는 판은 -32022, GET·DELETE는 405를 돌려줍니다.

Stanford CME295 Lecture 7 "Agentic LLMs" (Afshine·Shervine Amidi, 2025년 11월). MCP 구간 1:28:50~1:31:52, 약 3분입니다. 모델마다 도구를 정의하는 방식이 달라 같은 도구를 여러 번 구현하게 되는 중복을 문제로 꼽고, MCP를 도구를 모델에 노출하는 방식의 표준화로 소개합니다. 서버가 호스트 안의 클라이언트와 1대1로 연결된다는 점도 짚습니다. 리소스와 프롬프트 설명은 짧고 느슨해서, 정의는 명세를 따르는 편이 낫습니다.

Mahesh Murag(Anthropic), "Building Agents with Model Context Protocol" 워크숍 (AI Engineer Summit 2025). 영상. 2:08에서 MCP의 뿌리를 LSP(편집기와 언어 도구 사이의 규격)에 둡니다. 언어 서버를 한 번 만들면 어느 편집기든 붙는 것처럼, MCP 서버도 한 번 만들면 어느 클라이언트든 붙습니다. 6:04에 N×M 문제가 나오고, 10:21부터 도구는 모델, 리소스는 앱, 프롬프트는 사용자가 고른다는 설명이 이어집니다. 2025년 2월 녹화라 그 뒤 바뀐 연결 방식은 반영돼 있지 않습니다.

Anthropic, "The Model Context Protocol (MCP)" 대담 (2025년 6월). 영상. 해설 영상이 아니라 MCP를 만든 사람들의 대담입니다. 3:17에 시작 이야기가 나옵니다. David Soria Parra가 Claude 데스크톱 앱과 코드 편집기 사이를 복사·붙여넣기로 오가는 게 답답했다고 합니다. 8:32에서는 공개 규격으로 낸 이유를 말합니다. 닫힌 생태계에는 연동을 만드는 사람들이 투자하지 않는다는 것입니다.

MCP 보안 논문. Hou 외, "Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions"(arXiv 2503.23278, v3 2025년 10월). 초록 기준으로, MCP 서버의 일생을 만들기·배포·운영·유지보수 네 단계로 나눕니다. 공격자 네 유형과 위협 시나리오 16개를 분류하고, 단계별 대응책을 제안합니다. 15화(MCP 보안)에서 자세히 봅니다.

코드. 원본 레슨 13-06과 13-09의 code/main.py는 표준 라이브러리만으로 최신판 메시지와 HTTP 서버를 보여 줍니다. 실제로 쓰는 서버는 modelcontextprotocol/servers에 있습니다. 이 저장소에는 MCP 운영 그룹이 관리하는 참조 서버 7개(Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, Time)만 남아 있습니다. 더 많은 서버는 MCP 레지스트리에서 찾도록 안내합니다. 라이선스는 기존 코드 MIT, 새 기여분 Apache-2.0으로 옮겨 가는 중입니다.

다음 화 예고. 이번 화는 MCP 서버를 쓰는 쪽에서 구조를 봤습니다. 6화에서는 MCP 서버를 직접 만들어 봅니다.

원본: rohitg00/ai-engineering-from-scratch (MIT, © 2026 Rohit Ghumare). 이 글은 원문을 바탕으로 직접 정리하고 재구성했습니다.

출처

'AI > Engineering' 카테고리의 다른 글

사내 서비스 셋을 티켓 시스템 하나로 잇기: AI 도우미 요청과 회의록 할 일이 티켓이 되기까지 (MCP는 왜 아직 아닌가)  (0) 2026.10.22
MCP 서버 만들기: Python SDK로 함수 세 개, 26줄 첫 MCP 서버 (직접 짜면 400줄인 이유까지)  (0) 2026.10.20
모든 AI 일을 에이전트로 시켜야 할까? 워크플로와 에이전트의 차이, 워크플로 패턴 5가지 쉽게 정리  (0) 2026.10.15
AI에게 "단계별로 생각해 봐"라고 하면 정말 더 잘할까? 프롬프트 기법 쉽게 정리 (퓨샷, 생각의 사슬)  (0) 2026.10.12
AI 에이전트는 왜 몇 번씩 다시 시도할까? ReAct 루프 쉽게 정리 (생각·행동·관찰)  (0) 2026.10.06

'AI/Engineering'의 다른글

  • 현재글MCP란? AI 앱과 도구를 잇는 표준 규격 MCP 구조 쉽게 정리 (호스트·클라이언트·서버, 도구·리소스·프롬프트)

관련글

티스토리툴바