안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 나만의 MCP 서버 만들기 with 커서 AI를 읽고 서평을 하도록 하겠습니다.
필자도 Gemini, ChatGPT, Claude 등 업무에서 AI를 많이 활용하고 있습니다. 앞으로 세상은 AI를 얼마나 잘 활용하느냐에 따라 업무의 생산성이 달라질 것이라고 생각이 듭니다. 그 가운데서도 AI의 추가적인 기능을 붙여 사용할 수 있도록 MCP라는 개념이 있는데요. 이 책은 이 부분에 대해서 설명하고 있습니다.
그러면 본격적으로 각 단원별 내용을 정리하고 서평하도록 하겠습니다.
책의 제목은 “나만의 MCP 서버 만들기 with 커서 AI”이며, 이 책은 MCP 서버를 만드는 데 필요한 기초부터 고급 내용까지 폭넓게 다루고 있습니다. 커서 AI는 인공지능 기반의 도구로, MCP 서버 구축 과정에서 많은 도움을 줄 수 있는 강력한 파트너 역할을 합니다. 화려한 표지 디자인은 기술과 창의성이 결합된 느낌을 줍니다.
목차
1부 MCP 이해하기
- 1장. MCP 개념 이해하기
- 2장. MCP 동작 방식 이해하기
2부 실습 환경 준비하기
- 3장. API 키 획득하기
- 4장. 클로드 데스크톱 준비하기
- 5장. 커서 준비하기
- 6장. 커서 사용해보기
3부 MCP 실습하기
- 7장. MCP 사용해보기
- 8장. 커서에서 MCP 서버 만들고 연결하기
- 9장. 클로드 데스크톱에서 MCP 서버 만들고 연결하기
📘 1부: MCP의 개념과 필요성
MCP는 AI 모델이 외부 도구와 구조화된 표준 방식으로 상호작용할 수 있도록 설계된 프로토콜로, 프롬프트에 일일이 사용법을 명시하지 않아도 되고 JSON 명세를 기반으로 안정적인 호출과 결과 교환이 가능합니다. 이 장에서는 MCP의 등장 배경과 기존 방식의 한계를 설명하고, 왜 LLM에 MCP가 필요한지에 대해 다룹니다.
MCP가 무엇인지 부터 왜 필요한지에 대해서 설명하고 있습니다. 또한 MCP에 대한 구조적 설명을 하면서 앞으로 MCP를 통한 변화에 대해서도 설명을 하고 있습니다.
MCP의 동작 방식 및 통신 방식에 대해서도 설명을 하고 있습니다.
- Stdio(Standard Input/Output) 방식은 MCP 서버와 클라이언트가 표준 입출력을 통해 직접 데이터를 주고 받는 통신 방식
- SSE(Server-Sent Events) 방식은 MCP 서버가 HTTP 기반의 스트리밍 통신을 통해 클라이언트에게 실시간으로 데이터를 전송하는 방식
2026년에 이 책을 읽는다면 알아둘 것
이 책이 서버와 클라이언트를 잇는 통신 방식으로 소개하는 것은 Stdio 와 SSE 두 가지인데요, 규격 쪽에서는 이 사이에 한 차례 자리 이동이 있었습니다. 위 서평을 올린 2025년 9월 무렵에는 이미 규격 문서가 새 방식으로 넘어간 뒤였지만, 실제 서비스들은 예전 방식을 그대로 받아주고 있었고 지금도 상당수가 하위호환으로 열어두고 있어서 SSE 를 다루는 자료가 흔하던 때였습니다. 지금 이 책을 펼치는 분이라면 어디가 어떻게 갈렸는지만 미리 알고 들어가시는 편이 읽는 데 도움이 될 것 같습니다.
| 시점 | 규격 버전 또는 릴리스 | 그 시점의 표준 전송 방식 |
|---|---|---|
| 2024년 11월 | 2024-11-05 | stdio 와 HTTP+SSE |
| 2025년 3월 | 2025-03-26 | stdio 와 Streamable HTTP, 이 시점에 HTTP+SSE 가 deprecated 로 표시 |
| 2025년 4월 | TypeScript SDK v1.10.0 | StreamableHTTPServerTransport 추가 |
| 2025년 6월 | 2025-06-18 (현행) | stdio 와 Streamable HTTP |
오해하기 쉬운 대목을 하나 짚어두고 싶은데요, 없어진 것은 SSE 라는 기술 자체가 아닙니다. 현행 규격의 Streamable HTTP 는 서버가 필요하다고 판단할 때 그 안에서 SSE 스트림을 여는 구조라서 SSE 는 여전히 쓰이고 있고, 물러난 쪽은 SSE 엔드포인트와 POST 엔드포인트를 따로 두고 운영하던 예전의 HTTP+SSE 전송 방식입니다. 필자가 확인한 시점 기준으로 공식 전송 규격 문서의 Streamable HTTP 항목에는 이 방식이 2024-11-05 버전의 HTTP+SSE 전송을 대체한다는 문장이 그대로 붙어 있습니다.
그렇다고 목차 전체가 흔들리는 종류의 변화는 아닌 것 같습니다. 전송 방식이 바뀌어도 오가는 메시지 형식은 JSON-RPC 2.0 그대로이고, 1부가 제목으로 걸고 있는 MCP 의 개념과 동작 방식은 전송 계층과 다른 층에 놓인 주제이기 때문입니다. 달라진 자리는 서버를 원격으로 열어줄 때 어떤 엔드포인트 구조를 쓰느냐 한 곳이라고 보시면 될 것 같습니다.
stdio 와 Streamable HTTP, 언제 무엇을 쓰나
두 방식은 이름만 다른 선택지가 아니라 서버가 어디서 어떻게 살아 있느냐가 통째로 다른 구조인데요, 표로 늘어놓고 보면 어느 쪽을 골라야 하는지가 비교적 빨리 정리되는 것 같습니다.
| 항목 | stdio | Streamable HTTP |
|---|---|---|
| 서버 실행 위치 | 클라이언트가 서버를 하위 프로세스로 직접 띄웁니다 | 여러 클라이언트 연결을 받는 독립 프로세스로 돕니다 |
| 연결 방식 | 표준 입력과 표준 출력으로 메시지를 주고받습니다 | POST 와 GET 을 모두 받는 단일 HTTP 엔드포인트를 씁니다 |
| 세션 관리 | 프로세스 수명이 곧 세션입니다 | Mcp-Session-Id 헤더로 관리하고 서버가 끊으면 404 를 돌려줍니다 |
| 끊긴 연결 재개 | 해당 사항이 없고 프로세스를 다시 띄웁니다 | SSE 의 id 필드와 Last-Event-ID 헤더로 이어받습니다 |
| 스트리밍 | 표준 출력으로 순차 전달합니다 | 서버가 필요할 때 SSE 스트림을 선택적으로 엽니다 |
| 적합한 상황 | 내 컴퓨터 안에서만 도는 로컬 도구 | 원격에 두고 여러 클라이언트가 붙는 서버 |
공식 문서는 클라이언트가 가능한 한 stdio 를 지원해야 한다고 적어두었는데요, 내 컴퓨터 안에서 도는 도구라면 프로세스를 띄우고 표준 입출력으로 주고받는 쪽이 붙일 것도 지킬 것도 적기 때문일 것 같습니다. 반대로 서버를 원격에 두고 바깥에서 붙게 만들 생각이라면 Streamable HTTP 로 가야 하고, 이때 지켜야 할 규칙이 몇 가지 따라붙습니다.
- 서버는 POST 와 GET 을 모두 받는 단일 엔드포인트 하나를 제공해야 합니다.
- 클라이언트는 Accept 헤더에 application/json 과 text/event-stream 을 함께 넣어야 합니다.
- HTTP 를 쓰는 동안에는 MCP-Protocol-Version 헤더를 계속 실어 보내야 합니다.
요청 헤더만 떼어놓고 보면 이런 모양이 됩니다.
POST /mcp
Accept: application/json, text/event-stream
Mcp-Session-Id: 1868a90c
MCP-Protocol-Version: 2025-06-18세션은 Mcp-Session-Id 헤더로 관리되고 서버가 세션을 끝내버리면 그 뒤의 요청에는 404 가 돌아오는데요, 이때 클라이언트는 세션 아이디를 떼고 처음부터 다시 초기화해야 합니다. 스트림이 중간에 끊긴 경우라면 서버가 SSE 이벤트에 붙여둔 id 값을 클라이언트가 Last-Event-ID 헤더로 되돌려주면서 끊긴 지점부터 이어받는 방식으로 복구합니다.
이 책을 읽고 나서 따로 챙겨야 할 것
목차에 적힌 아홉 개 장은 개념과 동작 방식을 다루는 1부에서 출발해 API 키 발급과 도구 설치를 다루는 2부를 지나 서버를 직접 만들어보는 3부로 이어지는 구성인데요, 장 제목만 놓고 보면 완성한 서버를 원격에 올려두고 바깥에서 접근하게 만드는 단계는 목차에 자리를 갖고 있지 않습니다. 이 부분은 책을 덮은 뒤에 따로 챙겨야 할 몫으로 남는 셈입니다.
가장 먼저 챙길 곳은 보안 쪽인 것 같습니다. 공식 문서는 Streamable HTTP 를 구현할 때 지켜야 할 것을 세 가지로 못 박아 두었는데요, 로컬에서만 돌리는 동안에는 잘 드러나지 않다가 서버를 밖으로 여는 순간 곧바로 문제가 되는 항목들입니다.
- 서버는 들어오는 모든 연결에서 Origin 헤더를 검증해야 합니다. DNS 리바인딩 공격을 막기 위한 요구사항이고 문서에 MUST 로 적혀 있습니다.
- 로컬에서 실행할 때는 0.0.0.0 이 아니라 127.0.0.1 에만 바인딩하도록 권고하고 있습니다.
- 모든 연결에 적절한 인증을 구현하도록 권고하고 있습니다.
이 보호 장치가 없으면 원격의 웹사이트가 DNS 리바인딩을 통해 내 컴퓨터에서 돌고 있는 MCP 서버를 조작할 수 있다는 경고가 문서에 함께 붙어 있습니다. 실습으로 만든 서버를 컴퓨터 밖으로 꺼내볼 생각이라면 이 세 줄을 책 옆에 붙여두고 시작하시는 편이 좋겠습니다.
또 하나는 이미 원격 MCP 를 제공하고 있는 서비스들이 예전 방식을 언제까지 받아줄지 공지해두었다는 점입니다.
| 서비스 | 예전 HTTP+SSE 엔드포인트 처리 |
|---|---|
| Atlassian Rovo | mcp.atlassian.com/v1/sse 를 2026년 6월 30일까지만 하위호환으로 유지하고 이후 v1/mcp 로 이전 |
| Keboola | 2026년 4월 1일 종료 |
| Cloudflare | 기존 배포는 마이그레이션 기간 동안 유지 가능하고 신규 구축에는 stateless Streamable HTTP 를 권장 |
옮기는 작업 자체는 생각보다 무겁지 않아 보입니다. 세 전송 방식이 나르는 메시지 형식은 모두 JSON-RPC 2.0 으로 같아서 바뀌는 것은 바이트가 오가는 통로이지 메시지의 생김새가 아니고, 대부분의 SDK 에서 stdio 와 Streamable HTTP 는 인자 하나 차이로 갈립니다. 남이 만들어둔 stdio 서버를 원격에서 쓰고 싶은 경우에도 mcp-proxy 로 감싸는 경로가 열려 있습니다.
옛 클라이언트를 당장 버릴 수 없는 상황이라면 예전의 SSE 엔드포인트와 POST 엔드포인트를 새 MCP 엔드포인트 옆에 그대로 두는 방법도 공식 문서가 안내하고 있는데요, 하위 호환이 급한 서버에게는 이 조합이 현실적인 선택지가 될 것 같습니다.
이 책이 맞는 사람과 그렇지 않은 사람
목차 구성만 근거로 삼아도 이 책이 어느 쪽을 향하고 있는지는 비교적 또렷하게 보이는데요, 전체 아홉 개 장 가운데 네 개 장을 환경 준비에 쓰고 있다는 점이 가장 큰 단서입니다.
| 이런 상황이라면 | 목차에서 읽히는 근거 |
|---|---|
| MCP 를 이름만 들어본 상태 | 2부 네 개 장이 API 키 발급과 도구 설치부터 다루므로 준비 단계에서 막힐 일이 적습니다 |
| 손으로 만들어보며 익히고 싶은 상태 | 3부 세 개 장 가운데 두 개 장이 서버를 직접 만드는 실습을 제목으로 걸고 있습니다 |
| 원격 배포와 인증이 당장의 과제인 상태 | 아홉 개 장 어디에도 배포나 인증을 제목으로 단 장이 없어 다른 자료를 함께 봐야 합니다 |
| 이미 서버를 만들어 돌려본 상태 | 앞의 여섯 개 장이 개념과 환경 준비라서 이미 아는 내용과 겹칠 수 있습니다 |
실습 대상으로 언급되는 것은 수학 계산 서버와 문서 기반 RAG 서버에 더해 윈도우 탐색기와 웹 검색 서버까지 네 가지인데요, 여기에 필요한 API 키도 네 종류입니다. 키 발급이 자유롭지 않은 환경에서 읽으실 생각이라면 시작하기 전에 어떤 키가 필요한지부터 확인해두시는 편이 좋겠습니다.
자주 나오는 질문
SSE 를 쓰면 안 되나요?
SSE 라는 기술은 지금도 현행 규격 안에서 쓰이고 있습니다. Streamable HTTP 가 서버 쪽에서 여러 메시지를 흘려보낼 필요가 있을 때 SSE 스트림을 여는 구조이기 때문인데요, 물러난 것은 SSE 전용 엔드포인트와 POST 엔드포인트를 따로 두던 2024-11-05 버전의 HTTP+SSE 전송 방식입니다. 새로 만드는 원격 서버라면 단일 엔드포인트 방식으로 시작하시는 편이 맞습니다.
책 예제를 지금 그대로 따라 해도 되나요?
stdio 는 2024-11-05 때부터 현행 규격까지 표준 전송 방식 자리를 그대로 지키고 있어서 로컬 서버를 다루는 대목은 규격과 어긋날 일이 없습니다. 공식 문서 역시 클라이언트가 가능한 한 stdio 를 지원하도록 권고하고 있어서 개인 컴퓨터 안에서 쓰는 도구를 만드는 목적이라면 이쪽이 여전히 기본값에 가깝습니다. 원격 연결을 다루는 대목에 이르렀을 때만 현행 규격의 Streamable HTTP 문서를 옆에 함께 펼쳐두시면 될 것 같습니다.
stdio 만 알아도 되나요?
만든 서버를 자기 컴퓨터 안에서만 쓸 생각이라면 stdio 하나로 충분한 경우가 많습니다. 다만 서버를 다른 사람에게 열어주거나 여러 클라이언트가 함께 붙는 상황이 되면 세션 관리와 끊긴 연결의 재개 같은 요구가 따라붙기 때문에 Streamable HTTP 쪽 규격을 한 번은 읽어두시는 편이 좋습니다. 두 방식 모두 같은 JSON-RPC 2.0 메시지를 나르는 통로라서 한쪽을 익혀두면 다른 쪽으로 넘어가는 부담은 크지 않습니다.
🛠️ 2부: 실습 환경 준비
이 장에서는 MCP 서버를 만들기 위한 환경 세팅을 다룹니다. OpenAI, Tavily, Brave Search, 구글 지도 API 키 획득부터 클로드 데스크톱과 커서 설치까지, 초보자도 막힘없이 따라올 수 있도록 상세히 정리되어 있습니다.
이 책의 가장 큰 장점은 실습에 대해서 하나의 장으로 작성되어 설명하고 있다는 것입니다. 각 LLM의 키 획득 부터 클로드 데스크톱 준비 과정 끝으로 커서 준비까지 해서 실습을 준비하고 있습니다.
최근에 커서를 통한 코딩이 한참 인기를 끄는데 커서 사용법에 대해서도 간단히 소개가 되고 있습니다.
⚙️ 3부: MCP 서버 구축과 활용
이 장에서는 Stdio와 SSE 방식에 따른 MCP 서버 생성, 수학 계산 서버, PDF·오피스 문서를 다루는 RAG 서버, 윈도우 탐색기, 웹 검색 서버까지 직접 만들어보고 연결해 실행할 수 있습니다. 단순히 튜토리얼을 따라 하는 수준을 넘어 AI와 실제 환경을 연결하는 구체적인 응용 사례를 경험할 수 있습니다.
MCP를 직접 커서와 클로드 데스크톱에서 생성해보고 연결하는 방법에 대해서 소개하고 있습니다. 직접 적인 응용 사례를 통해서 준비 된 실습 환경 내에서 해볼 수 있어서 이해하는데 어려움이 없었습니다.
총평.
나만의 MCP 서버 만들기 with 커서 AI는 MCP 서버에 대한 체계적이고 구체적인 가이드를 제공합니다. 초보자부터 어느 정도 경험이 있는 개발자까지 모두에게 유용한 내용을 담고 있어, 추천할 만한 책입니다. 이 책을 통해 MCP 서버의 다양한 가능성을 경험해보기를 권장합니다.
또한 이 책은 MCP의 개념부터 실습까지 체계적으로 다루고 있어, AI 에이전트와 도구를 연결하여 실제 작업을 수행하고자 하는 분들에게 유용한 가이드가 된다고 생각합니다.
“길벗출판사 개발자 리뷰어로 도서를 제공받고 작성한 리뷰입니다.”
#도서 제공
#길벗출판사 개발자 리뷰어
함께 보면 좋은 글
- [서평 작성] 조코딩의 AI 비트코인 자동 매매 시스템 만들기
- [서평 작성] 리더의 AI 노트
- [서평 작성] AI 에이전트 마스터 클래스
- [서평 작성] 조코딩의 바이브 코딩 1인 창업 with 클로드 코드, 수파베이스, 스트라이프