MCP(Model Context Protocol) 완전 이해 — AI 세계의 USB-C (Part 1)

AI는 똑똑하지만 손발이 없다

ChatGPT에게 물어본 적이 있을 것이다. "오늘 서울 날씨 알려줘." 돌아오는 대답은 두 가지 중 하나다. 학습 데이터에 기반한 과거의 평균 기온을 늘어놓거나, 솔직하게 "실시간 정보는 제공할 수 없습니다"라고 고백하거나. 2024년 이후 웹 검색 기능이 탑재되면서 상황은 나아졌지만, 이 경험이 드러내는 본질적 한계는 여전히 유효하다. AI는 자기 머릿속에 없는 정보를 스스로 가져올 수 없다.

이런 상황을 한번 떠올려보자.

• "AI야, 우리 팀 Slack에서 오늘 논의된 내용 요약해줘" → 불가. AI는 여러분의 Slack 워크스페이스에 접근할 권한이 없다.
• "AI야, 이 데이터를 Google Sheets에 정리해줘" → 불가. AI는 구글 스프레드시트에 행을 추가하는 방법을 모른다.
• "AI야, GitHub에 올라온 PR 리뷰해줘" → 불가. AI는 여러분의 리포지토리 코드를 읽을 수 없다.

하나같이 업무 현장에서 매일 마주치는 요청이다. 그리고 하나같이 AI 혼자서는 해결할 수 없는 요청이기도 하다.

문제의 핵심은 명확하다. 현재의 대형 언어 모델(LLM)은 놀라울 정도로 똑똑하다. 논문을 요약하고, 코드를 작성하고, 전략 보고서를 초안하는 데 탁월한 능력을 보여준다. 그러나 그 똑똑한 두뇌는 완전히 고립된 방 안에 갇혀 있다. 창문도 없고, 전화기도 없고, 인터넷 케이블도 연결되어 있지 않다. 아무리 천재라도 바깥 세상과 연결되지 않으면, 할 수 있는 일에는 분명한 한계가 있다.

"AI에게 부족한 것은 지능이 아니라 세상과의 접점이다."

이 문제를 개발자들은 어떻게 풀어왔을까? 그리고 왜 그 해법들은 또 다른 문제를 낳았을까?

---

개발자의 악몽 — N×M 문제

AI를 바깥 세상과 연결하려는 시도는 이미 수없이 있었다. 2023년 OpenAI가 야심 차게 출시한 ChatGPT Plugins, LLM이 외부 함수를 호출할 수 있게 한 Function Calling, 그리고 다양한 도구를 체인으로 엮는 LangChain의 도구 체인까지. 각각은 나름의 방식으로 AI의 팔다리를 만들어주려 했다.

문제는 이 모든 시도가 표준 없이 진행되었다는 것이다. OpenAI의 플러그인 규격은 OpenAI에서만 작동했다. LangChain으로 만든 도구 연동 코드는 LangChain 프레임워크에 종속됐다. Claude에서 작동하는 연동 코드를 만들려면, ChatGPT용과는 전혀 다른 코드를 처음부터 다시 작성해야 했다.

이것이 개발자들이 N×M 문제라고 부르는 악몽의 시작이다. LLM이 N개이고, 연결해야 할 외부 도구가 M개라면, 필요한 연동 코드의 수는 N×M이 된다.

스마트폰 충전기로 비유하면 이해가 쉽다. 2010년대 초반을 기억하는가? 삼성 폰에는 마이크로USB, 아이폰에는 라이트닝, 어떤 기기에는 독자 규격 — 새 기기를 살 때마다 충전기도 새로 사야 했다. 서랍 속에 쌓여가는 충전 케이블들. AI 도구 연동의 세계가 정확히 그 모습이었다.

LLM 5종(ChatGPT, Claude, Gemini, LLaMA, Mistral) × 도구 10개(Slack, GitHub, Google Drive, Notion, Jira, DB, 이메일, 캘린더, CRM, 파일시스템) = 연동 코드 50개. 하나의 도구가 API를 변경하면? 50개의 코드 중 관련된 5개를 전부 찾아서 수정해야 한다. 새로운 LLM이 등장하면? 10개의 연동 코드를 처음부터 새로 작성해야 한다. 유지보수 지옥이 따로 없다.

"모든 것을 연결했는데, 아무것도 호환되지 않는 세계."

개발 팀의 시간과 에너지는 AI의 핵심 가치를 만드는 데 쓰이는 것이 아니라, 이미 만든 연결을 유지하는 데 소모되고 있었다. 업계 전체가 하나의 질문 앞에 서게 됐다 — 충전기 규격을 통일했듯, AI와 도구 사이에도 하나의 표준 규격을 만들 수는 없을까?

---

USB-C의 등장 — MCP란 무엇인가

2024년 11월, Anthropic은 하나의 오픈소스 프로젝트를 조용히 공개했다. 이름은 Model Context Protocol, 줄여서 MCP. 이 프로토콜이 제안하는 것은 단순하면서도 강력했다 — AI와 외부 도구 사이에 하나의 표준 통신 규격을 만들자는 것이었다.

USB-C를 떠올려보자. USB-C 하나로 충전도 하고, 데이터도 옮기고, 외부 모니터에 영상도 출력한다. 케이블 하나, 포트 하나로 모든 것이 통한다. MCP는 AI 세계의 USB-C를 지향한다. 어떤 LLM이든, 어떤 외부 도구든, 하나의 프로토콜로 연결할 수 있는 세상.

이전 장에서 봤던 N×M 문제를 다시 살펴보자. MCP 이전에는 LLM마다, 도구마다 전용 커넥터가 필요했다.

각 LLM이 각 도구에 접근하려면 전용 연동 코드를 따로 만들어야 했다. 3개의 LLM과 3개의 도구만으로도 9개의 커넥터가 필요한 구조. MCP는 이 구조를 근본적으로 바꾼다.

마법 같은 변화가 일어났다. N×M이 N+M으로 바뀌었다. 도구 개발자는 MCP 서버 하나만 만들면 된다. 그러면 MCP를 지원하는 모든 LLM에서 자동으로 사용할 수 있다. LLM 개발자는 MCP 클라이언트 하나만 구현하면 된다. 그러면 MCP를 지원하는 모든 도구에 접근할 수 있다.

이전의 50개(5 LLM × 10 도구) 연동 코드가 15개(5 + 10)로 줄어든다. 새로운 LLM이 등장해도 MCP 클라이언트 1개만 추가하면 기존 10개 도구를 즉시 사용할 수 있고, 새로운 도구가 출시되어도 MCP 서버 1개만 만들면 5개 LLM 전부에서 바로 접근할 수 있다. USB-C가 충전기 지옥을 끝냈듯, MCP는 연동 지옥을 끝내겠다는 선언이었다.

"한 번 만들면, 어디서든 연결된다(Build once, connect everywhere)."

그렇다면 MCP는 내부적으로 어떤 구조로 이 마법을 실현하는 걸까?

---

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

MCP의 아키텍처를 이해하는 가장 쉬운 방법은 레스토랑을 떠올리는 것이다.

여러분이 레스토랑에 들어가서 자리에 앉으면, 웨이터가 다가와 주문을 받는다. 웨이터는 주문을 주방에 전달하고, 주방은 요리를 만들어 웨이터에게 건넨다. 웨이터가 음식을 여러분의 테이블로 가져오면, 식사가 시작된다. MCP도 정확히 같은 구조로 작동한다.

호스트(Host)는 여러분이 직접 사용하는 애플리케이션이다. Claude Desktop 앱에서 대화를 나누고 있다면, Claude Desktop이 호스트다. Cursor IDE에서 코드를 작성하며 AI에게 도움을 요청하고 있다면, Cursor가 호스트다. 호스트는 레스토랑 건물 그 자체 — 모든 것이 이루어지는 공간이다.

클라이언트(Client)는 호스트 내부에서 작동하는 중개자다. 레스토랑의 웨이터처럼, 사용자의 요청을 받아 적절한 서버에 전달하고, 서버의 응답을 다시 가져오는 역할을 한다. 중요한 점은 클라이언트와 서버가 항상 1:1 관계라는 것이다. 한 웨이터가 하나의 주방을 전담하듯, 하나의 MCP 클라이언트는 하나의 MCP 서버와만 통신한다. 호스트가 여러 도구를 사용하려면, 도구 수만큼의 클라이언트를 내부에 생성한다.

서버(Server)는 실제로 일을 하는 주방이다. Slack MCP 서버는 Slack에서 메시지를 읽고 보내는 법을 알고 있고, GitHub MCP 서버는 PR을 조회하고 이슈를 생성하는 법을 알고 있다. 각 서버는 자기 전문 분야의 일만 담당한다.

그렇다면 MCP 서버는 구체적으로 어떤 기능을 제공할까? 크게 세 가지다.

• Tools(도구) — AI가 호출할 수 있는 함수다. 데이터베이스 쿼리를 실행하거나, 파일을 생성하거나, 이메일을 전송하는 등 실제 액션을 수행한다. 레스토랑으로 치면 주방에서 만들 수 있는 메뉴 항목에 해당한다.
• Resources(리소스) — AI가 읽을 수 있는 데이터다. 파일 내용, API 응답, 데이터베이스 레코드 등 AI에게 맥락(context)을 제공하는 정보원이다. 레스토랑에 비유하면 오늘의 식재료 재고 현황표와 같다.
• Prompts(프롬프트) — 미리 정의된 작업 템플릿이다. 코드 리뷰 양식, 보고서 작성 포맷 등 반복적인 작업을 표준화한 일종의 레시피 카드다.

이 세 가지가 MCP 서버의 "메뉴판"이다. 클라이언트가 서버에 접속하면, 서버는 자신이 제공할 수 있는 도구·리소스·프롬프트 목록을 알려준다. AI는 이 메뉴판을 보고 상황에 맞는 기능을 선택해서 사용한다.

전체 구조를 그림으로 보면 다음과 같다.

모든 것이 하나의 흐름으로 연결된다. 사용자가 "Slack에서 오늘 논의된 내용 요약해줘"라고 요청하면, 호스트 안의 MCP 클라이언트가 Slack MCP 서버에 접속한다. 서버는 Slack API를 통해 메시지를 가져오고, 그 결과를 클라이언트를 거쳐 AI에게 전달한다. AI는 전달받은 메시지를 읽고 요약본을 작성해 사용자에게 보여준다. 이 모든 과정이 표준화된 MCP 프로토콜 위에서 일어나기 때문에, Slack 대신 Notion을, Claude Desktop 대신 Cursor를 사용해도 동일한 방식으로 동작한다.

"하나의 프로토콜, 무한한 연결."

---

사례로 보는 MCP의 힘

MCP의 개념, 등장 배경, 그리고 내부 구조까지 살펴봤다. 이제 가장 중요한 질문이 남았다 — 실제로 어떻게 쓰이는가? 이론은 아름답지만, 결국 도구의 가치는 현장에서 증명된다. 지금부터 다섯 가지 구체적인 시나리오를 통해, MCP가 일하는 방식을 어떻게 바꾸는지 직접 확인해보자.

사례 1: 파일시스템 — "프로젝트 문서를 정리해줘"

"이 프로젝트 폴더에서 README 파일 찾아서 요약해줘"

MCP 없이: 누구나 한 번쯤 해봤을 것이다. 프로젝트 폴더를 열고, 파일 트리를 뒤지며 README를 찾고, 내용을 복사해서 AI 채팅창에 붙여넣는다. 파일이 하나라면 그나마 괜찮다. 하지만 하위 폴더 열 개에 문서가 흩어져 있다면? 각 폴더를 하나씩 열어보고, 관련 파일을 골라내고, 내용을 복사하고, 다시 AI에게 붙여넣고 — 이 과정을 반복하다 보면 정작 AI에게 물어보려던 질문이 무엇이었는지도 잊게 된다. AI는 여러분의 파일 시스템을 들여다볼 수 없다. 폴더 구조를 탐색할 수도 없고, 특정 파일을 열어볼 수도 없다.

MCP로: MCP 파일시스템 서버를 연결하면 상황이 완전히 달라진다. AI가 여러분의 로컬 파일 시스템에 직접 접근한다(물론 사용자가 허용한 디렉토리 범위 내에서). "프로젝트 폴더에서 README를 찾아 요약해줘"라고 말하면, AI는 스스로 디렉토리를 탐색하고, README 파일을 찾아 읽고, 핵심 내용을 정리해서 돌려준다. 복사-붙여넣기는 제로. 대화 한 턴으로 끝난다. 필요하면 "다른 문서 파일도 같이 정리해줘"라고 이어서 요청할 수 있고, AI는 같은 맥락 안에서 추가 파일을 읽어 작업을 확장한다.

사례 2: GitHub — "PR 코드 리뷰해줘"

"최근 PR에서 버그 가능성이 있는 변경사항을 검토해줘"

MCP 없이: 개발자의 일상적인 코드 리뷰 과정을 떠올려보자. GitHub에서 PR 페이지를 열고, 변경된 파일의 diff를 복사한다. diff가 수백 줄이면 여러 번에 나눠서 붙여넣어야 한다. 그런데 AI는 diff만 봐서는 충분한 리뷰를 하기 어렵다. 변경된 함수가 호출되는 다른 파일의 맥락, 관련 테스트 코드, 이전 커밋 히스토리 — 이런 정보 없이는 "이 코드가 괜찮은지" 판단하기가 쉽지 않다. 결국 추가 파일을 더 복사하고, 더 붙여넣고, 컨텍스트를 설명하는 데 시간을 쏟게 된다.

MCP로: MCP GitHub 서버가 연결되면, AI는 마치 팀원처럼 리포지토리를 직접 들여다본다. PR의 전체 diff를 가져오는 것은 물론이고, 변경된 파일의 원본 코드, 관련 파일, 커밋 히스토리까지 함께 조회한다. 충분한 맥락을 갖춘 상태에서 "이 부분은 null 체크가 빠져 있어 런타임 에러가 발생할 수 있습니다"와 같은 구체적인 피드백을 내놓는다. 리뷰 결과를 PR 코멘트로 직접 남기는 것도 가능하다.

사례 3: Slack — "오늘 회의 내용 요약해줘"

"오늘 #개발팀 채널에서 논의된 내용 요약해줘"

MCP 없이: 바쁜 하루를 보내고 나서 Slack을 열면 #개발팀 채널에 메시지가 200개 쌓여 있다. 스크롤을 올리며 중요한 논의를 찾아내고, 핵심 메시지를 선별하고, 스레드를 하나씩 열어 맥락을 파악하고 — 이 작업만으로 30분이 훌쩍 지나간다. 그래도 혹시 놓친 스레드가 있을까 불안하다. AI에게 도움을 받으려 해도, 결국 중요하다고 생각한 메시지를 직접 골라 복사해야 하니 이미 절반은 사람이 한 셈이다.

MCP로: MCP Slack 서버를 활용하면, AI가 오늘 날짜의 채널 메시지를 스레드 포함해서 통째로 읽어들인다. 그리고 알아서 핵심 주제를 식별하고, 결정된 사항과 미결 사항을 분류하고, 각 논의의 액션 아이템까지 정리한 구조화된 요약본을 수 초 만에 만들어낸다. 사람이 놓치기 쉬운 긴 스레드 속 중요한 코멘트까지 빠짐없이 포착한다. 200개의 메시지를 읽는 30분이, 요약본을 훑는 2분으로 바뀐다.

사례 4: 데이터베이스 — "매출 이상치를 분석해줘"

"지난달 매출 데이터를 분석해서 이상치를 찾아줘"

MCP 없이: 데이터 분석의 전형적인 삽질이 시작된다. 먼저 데이터베이스에서 CSV로 내보내기. 파일을 AI에 업로드하고, 테이블 스키마를 설명하고, 각 컬럼의 의미를 알려주고, 데이터의 맥락(사업부 구조, 시즌 특성 등)을 장문으로 입력한다. 데이터가 크면 샘플링하거나 쪼개야 한다. 그리고 가장 치명적인 문제 — AI가 분석 중에 "이 이상치의 원인을 확인하려면 고객 테이블도 봐야 할 것 같습니다"라고 하면? 다시 CSV 내보내기부터 시작이다. 후속 질문을 던질 때마다 수동 데이터 추출의 루프가 반복된다.

MCP로: MCP 데이터베이스 서버가 DB에 직접 연결된다. AI는 먼저 스키마를 탐색해서 테이블 구조와 관계를 스스로 파악한다. 그런 다음 SQL 쿼리를 작성하고 실행하며, 결과를 분석하고, 이상치를 발견하면 원인을 추적하기 위한 후속 쿼리를 자율적으로 이어간다. "이 이상치는 특정 지역의 프로모션 기간과 겹칩니다. 프로모션 테이블을 확인해볼까요?"라는 제안까지 가능하다. 데이터 분석이 일방적인 입력-출력이 아니라, 진짜 대화형 분석이 된다.

사례 5: 복합 시나리오 — "이슈를 분석하고 팀에 공유해줘"

"GitHub 이슈를 분석해서 우선순위를 정하고, 결과를 Slack에 공유해줘"

MCP 없이: 이 요청을 수동으로 처리한다고 생각해보자. 먼저 GitHub에서 열린 이슈 목록을 확인한다. 각 이슈의 라벨, 코멘트, 관련 PR을 살피며 중요도를 판단한다. 스프레드시트를 열어 우선순위 표를 만든다. 요약 문서를 작성한다. Slack으로 전환해서 #개발팀 채널에 메시지를 작성하고 첨부한다. 각 단계마다 컨텍스트 전환이 일어나고, 한 시간 가까운 시간이 흘러간다. AI에게 도움을 받으려 해도, 단계별로 데이터를 수동으로 건네줘야 하니 병목은 사라지지 않는다.

MCP로: AI가 여러 MCP 서버를 순차적으로 오케스트레이션한다. 이것이 바로 에이전틱(Agentic) AI의 진수다.

1. GitHub 서버: 열린 이슈 전체를 라벨, 코멘트, 연결된 PR 정보와 함께 가져온다.
2. AI 분석: 이슈들의 패턴을 분석하고, 영향도와 긴급도를 기준으로 우선순위를 매기고, 구조화된 요약 보고서를 생성한다.
3. Slack 서버: 완성된 보고서를 #개발팀 채널에 깔끔하게 포맷팅해서 전송한다.

사용자가 한 것은 한 줄의 요청뿐이다. AI가 알아서 여러 도구를 넘나들며 목표를 달성한다. 이것이 에이전틱 AI의 본질이다 — 사람이 목표만 제시하면, AI가 자율적으로 도구를 선택하고 조합해서 결과를 만들어낸다. MCP가 모든 도구에 대한 통합 인터페이스를 제공하기 때문에 이런 워크플로우가 비로소 가능해진다.

---

다섯 가지 사례를 관통하는 공통점이 보이는가? MCP는 AI와 사람들이 이미 사용하고 있는 도구 사이의 중간 허들을 없앤다. 파일을 복사-붙여넣기할 필요도, CSV를 내보낼 필요도, 앱 사이를 전환하며 수동으로 데이터를 옮길 필요도 없다. AI가 도구에 직접 접근하고, 사용자는 "무엇을 원하는지"만 말하면 된다.

그리고 위의 모든 사례는 가상의 미래가 아니다. 파일시스템, GitHub, Slack, PostgreSQL 등 주요 도구의 MCP 서버는 이미 오픈소스로 공개되어 있고, 지금 바로 사용할 수 있다. MCP 생태계는 빠르게 확장 중이며, 매주 새로운 서버가 추가되고 있다.

---

왜 지금인가 — 에이전틱 AI 시대

2024년과 2025년을 거치며 AI 업계에 하나의 거대한 흐름이 형성됐다. 단순한 질문-응답 챗봇을 넘어, 자율적으로 도구를 사용해 목표를 달성하는 AI 에이전트의 시대가 열린 것이다. 이 흐름을 업계에서는 "에이전틱 AI(Agentic AI)"라고 부른다.

차이를 이해하려면 기존 챗봇과 에이전트의 작동 방식을 비교해보면 된다. 기존 챗봇은 사용자의 질문에 텍스트로 답하는 것이 전부였다. "이메일 초안을 써줘"라고 하면 초안 텍스트를 생성해주지만, 그것을 실제로 이메일로 보내는 것은 사람의 몫이었다. "데이터를 분석해줘"라고 하면 분석 방법론을 설명해주지만, 실제 데이터에 접근해서 분석을 수행하지는 못했다.

에이전틱 AI는 근본적으로 다르다. 목표를 부여받으면, 스스로 계획을 세우고, 필요한 도구를 선택하고, 단계별로 실행하며, 결과를 검증한다. "지난주 고객 문의 중 긴급한 것을 파악해서 담당자에게 Slack으로 알려줘"라는 요청에, 에이전트는 이메일 시스템에서 문의를 조회하고, 내용을 분석해 긴급도를 판단하고, 담당자를 매핑하고, Slack 메시지를 전송하는 전체 과정을 자율적으로 수행한다.

그런데 에이전트가 자율적으로 도구를 사용하려면, 한 가지 전제 조건이 반드시 충족되어야 한다 — 도구에 접근하는 방법이 표준화되어 있어야 한다. 에이전트가 매번 다른 방식으로 다른 도구에 연결해야 한다면, 에이전트의 자율성은 코드 한 줄 한 줄에 하드코딩된 연동 로직에 갇히게 된다. 새로운 도구를 추가할 때마다 에이전트의 코드를 수정해야 하고, 도구의 API가 변경될 때마다 에이전트가 멈추는 취약한 구조가 된다.

MCP는 바로 이 문제를 해결하는 인프라 레이어다. 에이전트에게 "도구가 어떤 기능을 제공하는지 알아내고, 필요한 기능을 호출하는" 표준화된 방법을 제공한다. MCP가 있으면 에이전트는 어떤 도구든 동일한 방식으로 발견하고, 동일한 방식으로 사용할 수 있다. 에이전트 개발자는 연동 코드를 짜는 대신, 에이전트의 추론 능력과 작업 수행 전략에 집중할 수 있다.

이것이 바로 MCP가 지금 중요한 이유다. AI가 단순 챗봇 단계에 머물러 있었다면 MCP는 과잉 설계였을 것이다. 하지만 AI가 에이전트로 진화하는 이 시점에서, MCP는 에이전트가 실제로 작동하기 위한 필수 기반이 된다. 에이전틱 AI 시대에 MCP는 선택이 아니라 전제 조건이다.

업계도 이 사실을 인식하고 있다. 2025년 3월 Google은 Gemini에서 MCP를 지원하겠다고 발표했고, 같은 달 OpenAI도 ChatGPT와 에이전트 플랫폼에 MCP 지원을 통합하겠다고 선언했다. Anthropic이 만든 프로토콜을 최대 경쟁사들이 채택한다는 것은 무엇을 의미하는가? 이것은 더 이상 한 회사의 프로젝트가 아니라, 업계 전체의 표준이 되어가고 있다는 신호다. 마치 USB-C가 Apple, Samsung, Google 모두에게 채택되며 진정한 범용 규격이 된 것처럼, MCP도 AI 업계의 범용 연결 규격으로 자리잡아가고 있다.

생태계의 성장세는 이 판단을 뒷받침한다.

공식 서버 약 30개에 비해 커뮤니티 서버가 1,000개를 넘어섰다는 사실이 핵심이다. 이것은 개발자들이 MCP의 가치를 인정하고, 자발적으로 생태계를 확장하고 있다는 강력한 증거다. Python, TypeScript, Java, Go, Rust, C# 등 6개 이상의 언어로 SDK가 제공되고, Claude Desktop부터 Cursor, Windsurf, VS Code까지 10개 이상의 플랫폼이 MCP를 지원한다.

이 폭발적인 성장은 우연이 아니다. 개발자들은 오랫동안 AI와 도구를 연결하는 표준화된 방법을 원해왔고, MCP가 그 답을 제시한 것이다. MCP는 AI 에이전트에게 있어 HTTP가 웹에게 그랬던 것과 같은 존재가 되어가고 있다 — 눈에 보이지 않지만, 모든 것을 가능하게 만드는 보이지 않는 프로토콜. HTTP라는 표준이 없었다면 오늘날의 웹 생태계는 존재하지 않았을 것이다. MCP 없이는 진정한 에이전틱 AI 생태계 역시 존재할 수 없다.

---

마무리

MCP는 AI를 탁월하지만 고립된 두뇌에서 세상과 연결된 유능한 조력자로 변화시킨다. USB-C가 충전기 케이블의 혼란을 끝낸 것처럼, MCP는 AI와 도구 사이의 연결 혼란을 끝낸다. 하나의 표준 프로토콜로 어떤 AI든, 어떤 도구든 연결할 수 있는 세상. 그것이 MCP가 그리는 미래이자, 이미 시작된 현재다.

Part 2에서는 MCP 서버를 직접 만들어보며 기술적 구조를 더 깊이 살펴보겠습니다. JSON-RPC 기반의 프로토콜 구조, Transport 레이어의 작동 원리, 그리고 간단한 MCP 서버를 직접 구현하는 과정을 다룰 예정입니다.