책에 포함된 노트만들면서 배우는 MCP: PKM-MCP로 끝내는 설계·구현·운영·배포

부록 F. MCP 서버 50선

2026-04-27Views 68약 11분생성형 AI 활용

부록 F. MCP 서버 50선

좋은 MCP 서버를 빨리 만들고 싶다면, 좋은 MCP 서버를 많이 보는 것이 가장 빠른 지름길이다. 혼자 머리를 싸매고 스키마를 짜는 것보다, 이미 잘 만든 서버가 어떤 도구를 어떻게 나누고, 어떤 식으로 에러를 설명하고, 어디까지를 읽기 전용으로 두는지 보는 편이 훨씬 빠르다.

2026년의 MCP 생태계는 정말 크다. 공개 디렉터리에서 2만 개 이상을 거론할 정도이고, 별도 큐레이션 저장소만 봐도 수백 개 프로젝트가 카테고리별로 정리될 정도다.¹⁴ 여기에 원격 HTTP 서버가 빠르게 늘면서 예전보다 "일단 연결해 보기"는 쉬워졌지만, 서버 품질의 편차는 더 커졌다.² 심지어 공개 서버를 무작정 가져다 쓰는 것은 보안상 위험할 수 있다는 경고도 여러 곳에서 반복된다.³

그래서 이 부록은 "많이 설치할 서버 목록"이 아니라, "좋은 설계를 배우기 위한 샘플 라이브러리"로 읽는 편이 좋다. 특히 이 책의 메인 프로젝트인 PKM-MCP를 확장할 때는, 메모 서버를 메모 서버만 보고 설계하지 말고 GitHub, Notion, Slack, Cloudflare, Sentry 같은 전혀 다른 분야의 서버도 같이 보는 편이 훨씬 도움이 된다. 좋은 MCP 서버는 도메인이 달라도 설계 감각이 비슷하기 때문이다.

부록 F. MCP 서버 50선

이 목록의 선정 기준

이 목록은 단순 인기 순위가 아니다. 다음 다섯 가지를 기준으로 골랐다.

실제 워크플로에 자주 들어오는가 멋진 데모보다, 일주일에 여러 번 쓰게 되는 서버가 더 중요하다. GitHub, PostgreSQL, Slack 같은 서버가 꾸준히 강한 이유다.¹
도구 설명이 좋은가 MCP 서버는 코드보다 스키마와 설명이 먼저 읽힌다. 파라미터 이름, 타입, docstring, 기본값이 부실하면 AI도 흔들린다.¹³
읽기와 쓰기가 적절히 분리되는가 잘 만든 서버는 "검색"과 "변경"을 대충 한 도구에 섞지 않는다. read-only, destructive, idempotent 감각이 살아 있다.
공식 또는 활발한 유지보수가 있는가 빠르게 변하는 SaaS API를 감싸는 서버는 관리가 생명이다. 최근 커밋, 공식 문서, OAuth 지원 여부를 꼭 본다.¹²
보안 경계가 분명한가 로컬 파일 접근 범위, 데이터베이스 권한, OAuth 스코프, 원격 서버 신뢰 모델이 모호하면 좋은 예제가 아니다.³

개발과 코드 작업에서 먼저 볼 5선

공식 서버 인덱스에는 GitHub, Playwright, Chrome DevTools, Cloudflare, Supabase처럼 "설계 공부용"으로도 좋은 서버들이 꾸준히 올라온다.⁵ 이 섹션은 코딩 에이전트를 붙일 때 가장 먼저 보는 축이다.

GitHub MCP 세계의 교과서 같은 서버다. 저장소 조회, 이슈 생성, PR 확인, 코드 검색처럼 읽기와 쓰기가 자연스럽게 분리되어 있다. PKM-MCP를 만든다면 search_notes와 update_note를 어떤 어조와 입력 스키마로 나눌지 GitHub 서버에서 감을 잡을 수 있다.
GitLab GitHub보다 엔터프라이즈 맥락이 강하다. CI/CD, Merge Request, 자체 호스팅 환경과 맞물리는 경우가 많아서, 사내 도구형 MCP를 설계할 때 참고하기 좋다. "회사 안에서만 쓰는 MCP 서버"의 현실적인 모습에 가깝다.
Filesystem 단순해 보여도 아주 중요하다. 권한을 어디까지 열어줄지, 경로를 어떻게 제한할지, 로컬 도구가 어느 수준의 안전장치를 가져야 하는지 보여준다. PKM-MCP가 로컬 마크다운 저장소를 다룬다면 사실상 가장 먼저 연구해야 할 서버다.
Context7 문서 조회 서버이지만, 본질적으로는 "최신 정보 주입" 서버다. 응답이 장황하지 않고 AI가 바로 쓸 수 있는 형태로 정리된다는 점이 중요하다. PKM-MCP의 RAG 응답 형식을 설계할 때도 이 감각이 유용하다.
Docker 로컬 개발 환경과 운영 환경을 AI가 만지는 예시다. 상태가 있는 대상에게 도구를 붙일 때 어떤 보호 장치가 필요한지, 실행 전 확인이 왜 중요한지 배울 수 있다. 쓰기 도구의 위험도 설계 감각을 익히기 좋다.

데이터와 백엔드 설계에 좋은 5선

데이터 계층을 붙이는 순간 MCP 서버는 갑자기 "장난감"에서 "서비스"가 된다. 이 다섯 개는 PKM-MCP의 CRUD, 검색, RAG, 감사 로그 설계와 바로 연결된다.

PostgreSQL 자연어 질의를 SQL로 바꾸는 대표 서버다. 스키마 탐색, 읽기 전용 질의, 결과 포맷 제어가 모두 중요하다. PKM-MCP의 노트 메타데이터를 테이블로 관리할 계획이라면 거의 필수 교과서다.
Supabase 데이터베이스만이 아니라 Auth, Storage, Edge Functions까지 묶여 있다. 그래서 "백엔드 전체를 MCP로 감싸면 어떤 느낌인가"를 보기 좋다. PKM-MCP를 멀티유저 서비스로 키울 때 아주 좋은 비교 대상이다.
SQLite 작고 단단하다. 로컬 우선, 단일 사용자, 임베딩 가능한 저장소라는 점에서 개인 지식 관리 도구와 잘 맞는다. 처음엔 SQLite로 시작하고 나중에 Postgres로 넘어가는 경로를 설계할 때 감이 온다.
MongoDB 문서 지향 저장소를 AI가 어떻게 다루는지 보여준다. 메모, 첨부 메타데이터, 유연한 스키마가 필요한 프로젝트라면 관계형 DB와 다른 설계 습관을 익힐 수 있다. "모든 것을 표로 만들 필요는 없다"는 점을 일깨워준다.
ClickHouse 분석 쿼리 중심 워크로드에 강하다. 감사 로그, 이벤트 집계, 검색 사용 패턴 분석 같은 운영 데이터에 특히 어울린다. PKM-MCP에서 "누가 어떤 노트를 얼마나 조회했는가" 같은 분석 기능까지 생각한다면 좋은 미래형 참고서다.

검색과 리서치에 강한 5선

검색 서버는 단순히 외부 정보를 가져오는 도구가 아니다. "AI가 어떤 결과를 가장 잘 쓰는가"를 배울 수 있는 응답 포맷 실험실이다.

Brave Search 웹 검색의 기본형이다. 빠르고 단순해서, 검색 서버의 최소 기능이 무엇인지 보기 좋다. PKM-MCP의 키워드 검색 도구도 처음에는 이처럼 군더더기 없이 만드는 편이 낫다.
Exa 의미 기반 검색을 잘 보여준다. 키워드보다 개념 가까움을 중요하게 다루기 때문에, semantic search를 별도 도구로 분리해야 하는 이유를 체감하게 해준다. 2부 7장의 설계 감각을 다시 확인하기 좋다.
Tavily 웹 검색과 콘텐츠 추출의 중간쯤에 있다. "찾기"와 "가져오기"를 어디서 분리할지 고민할 때 좋은 예제다. PKM-MCP에서도 search_notes와 get_note를 나누는 이유가 이와 비슷하다.
Firecrawl 웹 페이지를 LLM 친화적인 형태로 정리하는 능력이 강점이다. 결과를 예쁘게 뽑는 서버가 아니라, AI가 바로 읽고 쓸 수 있게 가공하는 서버라는 점이 중요하다. 메모 첨부 링크를 요약하거나 아카이브하는 기능을 만들 때 참고 가치가 높다.
Perplexity 인용이 포함된 리서치형 응답을 잘 보여준다. 응답 품질뿐 아니라, "근거를 함께 주는 검색 도구"가 왜 중요한지 알려준다. PKM-MCP의 RAG 결과에도 출처와 발췌 문맥을 함께 주고 싶다면 배울 점이 많다.

브라우저 자동화와 디버깅에서 볼 5선

브라우저 계열 서버는 MCP의 손발을 길게 만든다. 사람이 탭을 열고 클릭하던 일을 AI가 대신하게 되면, 도구 설계에서 상태, 재시도, 오류 메시지의 중요성이 훨씬 커진다.

Playwright 브라우저 자동화의 대표 주자다. 구조화된 입력으로 페이지 이동, 클릭, 스크린샷, 테스트까지 이어지는 흐름이 좋다. 여러 단계 워크플로를 MCP 도구로 쪼갤 때 아주 좋은 참고서다.
Chrome DevTools 디버깅 쪽 색깔이 강하다. DOM 검사, 네트워크, 렌더링 문제처럼 "상태를 읽는" 도구가 얼마나 자세해야 하는지를 배울 수 있다. PKM-MCP에 자체 UI를 붙일 때 프런트엔드 디버깅 감각까지 챙기고 싶다면 유용하다.
Browserbase 브라우저를 클라우드에서 다룬다는 점이 핵심이다. 로컬 전용 서버에서 원격 실행 서버로 사고를 확장하게 만든다. 나중에 PKM-MCP가 외부 웹 서비스에서 자료를 수집하는 방향으로 커질 때 참고하기 좋다.
Puppeteer 오래된 친구처럼 익숙한 설계가 많다. Playwright보다 가볍게 시작할 때 좋고, 커뮤니티 예제가 풍부하다. 실전에서는 "단순한 도구 세트도 충분히 쓸모 있다"는 사실을 보여준다.
Proxyman MCP HTTP 트래픽을 읽고 분석하는 방향의 예제다. 눈에 보이지 않는 네트워크를 구조화된 데이터로 바꾸는 감각이 좋다. PKM-MCP에서 감사 로그나 외부 API 호출 추적을 어떻게 보여줄지 고민할 때 생각보다 큰 힌트를 준다.

생산성과 지식관리에 좋은 5선

2026년 생산성 영역은 hosted 공식 서버가 빠르게 늘면서, "회사 문서와 개인 메모를 AI가 직접 만지는 시대"로 확실히 넘어갔다.⁶ 이 섹션은 PKM-MCP와 가장 가까운 친척들이다.

Notion 문서, 데이터베이스, 댓글, 검색이 한데 묶여 있다. 무엇보다 Notion 블록 구조를 LLM이 잘 쓰는 표현으로 바꾸는 감각이 좋다. PKM-MCP에서 마크다운을 어떻게 잘라 보여줄지 고민할 때 큰 도움이 된다.
Linear 이슈와 프로젝트 계층이 아주 깔끔하다. 파라미터 스키마가 단순하고, 상태 전이가 명확해서 AI가 실수할 여지가 적다. "좋은 MCP 서버는 결국 좋은 제품 모델을 갖고 있다"는 걸 보여주는 사례다.
Todoist 개인 생산성 도구의 정석에 가깝다. 해야 할 일, 프로젝트, 리마인더, 우선순위처럼 인간의 일상 단위를 어떻게 도구로 쪼개는지 보기 좋다. PKM-MCP에 작업 관리 기능을 붙일 생각이라면 꼭 구경해볼 만하다.
Obsidian 계열 서버 로컬 마크다운 볼트를 직접 다루는 계열이다. SaaS가 아니라 파일 기반 지식 저장소를 MCP로 노출한다는 점에서 PKM-MCP와 정서가 아주 비슷하다. URI 설계, 노트 단위 읽기, 태스크 추출 같은 아이디어를 얻기 좋다.
PKM MCP Server 이 책의 메인 프로젝트와 가장 직접적으로 닿아 있는 사례다. 구조화된 마크다운 볼트를 stateless HTTP와 OAuth 2.1로 노출하고, 읽기/쓰기 도구를 갖춘 형태로 소개되어 있다.⁷ 여기에 다중 소스 데이터를 일일 리포트로 모으는 pkm-tool 같은 프로젝트까지 같이 보면, "단일 볼트 서버"와 "수집형 PKM 서버"라는 두 가지 설계 방향을 비교해 볼 수 있다.⁸

협업, 커뮤니케이션, 고객업무에 좋은 5선

AI가 팀 도구를 건드리기 시작하면 생산성은 크게 오르지만, 실수의 비용도 커진다. 이 다섯 개는 검색 중심 UX와 쓰기 권한 제어를 동시에 배우기 좋다.

Slack 채널 검색, 메시지 읽기, 스레드 맥락 파악이 핵심이다. "요약"과 "후속 액션"을 도구로 연결하는 흐름이 좋아서, 협업형 MCP의 좋은 본보기다.
Atlassian Jira와 Confluence를 함께 다룬다는 점이 강력하다. 이슈 관리와 문서 검색이 한 세계 안에 들어오면 도구 조합이 얼마나 풍부해지는지 보여준다. PKM-MCP도 나중에 메모와 작업을 함께 다루려면 참고할 포인트가 많다.
Gmail 이메일 검색, 읽기, 초안 작성, 회신까지 들어간다. 커뮤니케이션 도구에 쓰기 기능이 들어갈 때 승인 흐름이 얼마나 중요한지 배우게 된다. "메일 보내기"는 강력하지만, 그래서 더 조심해야 한다.
HubSpot CRM 쪽의 대표 예제다. 고객, 회사, 딜, 활동 이력이 모두 구조화되어 있어서, 데이터 모델을 MCP 도구에 잘 투영한 사례로 볼 수 있다. PKM-MCP가 사람 중심 메모를 다룬다면 이런 객체 모델이 힌트가 된다.
Zendesk 지원 티켓 맥락을 AI에게 연결하는 전형적인 서버다. 한 건의 문의를 단일 텍스트로 보지 않고, 고객 맥락과 지식베이스와 연결해 다룬다는 점이 중요하다. 메모 검색과 후속 액션을 엮고 싶을 때 생각보다 비슷한 문제가 나온다.

운영과 관측성에서 배울 5선

운영 계열 서버는 "도구가 실패했을 때 무엇을 반환해야 하는가"를 가장 잘 보여준다. 에러 메시지의 품질이 서버의 품질인 영역이다.

Sentry 에러 추적 MCP의 대표 선수다. 최근 오류, 스택 트레이스, 빈도 변화를 가져오면서도, 사용자가 바로 행동할 수 있는 수준의 정보만 준다. PKM-MCP의 감사 로그와 운영 로그를 보여줄 때도 이 절제가 중요하다.
Datadog 메트릭, 로그, 트레이싱이 함께 묶인다. 즉, "한 문제를 여러 관측 축으로 본다"는 감각을 익히게 한다. PKM-MCP가 커지면 검색 성능, API 지연, 오류율을 따로따로 볼 수 있어야 한다.
Grafana 대시보드형 사고방식이 강하다. 수집된 데이터를 어떻게 쿼리하고, 어떤 지표를 먼저 보여줄지 감각을 준다. 자체 MCP Apps UI를 만들 때도 이 시각화 감각을 참고하기 좋다.
New Relic APM과 에러, 인프라 뷰를 함께 본다. 복잡한 시스템을 요약하는 도구는 무엇을 생략해야 하는지 배우게 된다. 운영용 MCP는 정보 과식이 아니라 정보 절제가 중요하다.
PagerDuty 인시던트와 온콜이 중심이다. 즉시성이 중요한 도구는 파라미터보다 우선순위와 상태 전이가 더 중요하다는 점을 잘 보여준다. PKM-MCP에도 나중에 "긴급 수정", "승인 필요" 같은 상태 개념이 들어갈 수 있다.

클라우드와 인프라에 좋은 5선

원격 MCP 서버를 운영하는 순간부터는 코드보다 배포가 더 큰 일이 된다. 이 다섯 개는 3부의 내용을 현실로 가져오는 데 좋은 참고서다.

Cloudflare Workers, KV, R2, DNS까지 한 번에 연결된다. MCP 서버를 엣지에 가깝게 두고 싶을 때 어떤 운영 모델이 가능한지 잘 보여준다. 이 책의 12장과 가장 직접적으로 연결되는 대표 예제다.
Vercel 배포, 로그, 환경 변수 같은 "개발자가 매일 만지는 운영 버튼"을 MCP로 감싼다. 도구가 너무 많아지면 오히려 혼란스러워진다는 교훈도 준다. 실무에서는 필요한 것만 보이게 하는 것이 중요하다.
AWS 세상에서 제일 큰 공구함을 AI에게 쥐여주는 느낌이다. 그래서 더더욱 범위 제한, 자격 증명, 계정 분리가 중요하다. 대규모 권한 모델을 공부하기엔 최고지만, 초보자가 무턱대고 넓게 열어두기엔 위험하다.
Kubernetes 클러스터는 상태가 많은 세계다. 조회와 변경, 롤링 업데이트와 장애 대응 등 "행동의 비용"이 큰 작업을 다룬다. 복잡한 상태 머신을 MCP 도구로 표현하는 좋은 공부 대상이다.
Neon 서버리스 Postgres와 브랜칭이 결합된 형태라서 재미있다. 데이터베이스도 이제 배포처럼 다룰 수 있다는 감각을 준다. PKM-MCP의 실험 환경과 운영 환경을 분리하는 아이디어로 이어질 수 있다.

디자인과 크리에이티브에서 영감을 주는 5선

디자인 서버는 "텍스트 설명만으로는 부족한 세계"를 잘 보여준다. MCP Apps 시대로 갈수록 이런 영역은 더 중요해진다.

Figma 디자인-코드 사이의 번역기를 자처하는 서버다. 토큰, 컴포넌트, 레이아웃 정보를 구조화해서 주는 방식이 아주 인상적이다. PKM-MCP에 카드형 UI를 붙일 때도 "텍스트만 반환하지 말자"는 감각을 준다.
Canva 더 대중적인 제작 워크플로에 가깝다. 디자인 전문 도구가 아니어도, AI가 템플릿 기반 편집을 돕는 흐름을 만들 수 있다는 점을 보여준다. 사용성 중심 MCP의 좋은 예다.
ElevenLabs 텍스트를 음성으로 확장하는 사례다. MCP가 꼭 CRUD와 검색만 하는 것은 아니라는 사실을 일깨워준다. 나중에 음성 메모 요약, 음성 읽어주기 같은 PKM 확장을 상상하게 만든다.
Blender 조금 놀랍지만, 바로 그래서 재미있다. 복잡한 그래픽 소프트웨어도 MCP로 다룰 수 있다면, 우리 서버의 도메인 모델도 생각보다 더 풍부하게 설계할 수 있다는 자신감을 준다.
DaVinci Resolve 영상 편집이라는 긴 워크플로를 MCP로 감싸는 예제다. 단일 도구 호출이 아니라, 단계별 작업 흐름을 어떻게 구성할지 감을 잡게 해준다. 복잡한 편집 워크플로는 곧 복잡한 비즈니스 워크플로와 닮아 있다.

한국 생태계에서 꼭 봐둘 5선

한국 시장에서는 글로벌 서버만으로 해결되지 않는 일이 많다. 법령, 지도, 공공데이터, 한글 문서, 국내 커머스처럼 지역 특화 데이터가 강한 분야는 한국형 MCP 서버가 훨씬 실전적이다. 이런 흐름을 한데 보려면 awesome-mcp-korea 같은 큐레이션이 좋은 출발점이다.⁹

korean-law-mcp 계열 국가법령정보 API를 바탕으로 법령과 판례를 다룬다. 구조화된 법률 데이터를 AI가 탐색하게 만들 때 어떤 질의 패턴이 필요한지 보기 좋다. "검색 결과만 주지 말고 조문 맥락까지 줘야 한다"는 교훈을 준다.
Naver Maps MCP 계열 한국 주소 체계와 장소 검색은 글로벌 지도만으로 아쉬울 때가 많다. 지오코딩, 역지오코딩, 경로 탐색 같은 기능을 지역 현실에 맞게 붙일 수 있다. 위치 기반 PKM이나 생활형 에이전트라면 특히 중요하다.
kordoc HWP, HWPX, PDF를 다루는 한국형 문서 서버다. "문서 파싱"이라는 말은 쉬워 보여도, 실제로는 지역 문서 포맷 대응이 큰 장벽이라는 걸 알려준다. 한국 기업 환경에서 MCP를 현실 도구로 만드는 핵심 퍼즐 중 하나다.
daiso-mcp 주변 매장 검색, 재고 조회, 가격 조회처럼 아주 생활형이면서도 실용적인 예제다. 이런 서버를 보면 MCP가 꼭 거창한 엔터프라이즈 영역에서만 빛나는 것이 아니라는 걸 알게 된다. 사용자가 바로 체감하는 가치를 만드는 법을 보여준다.
KMA 날씨 MCP 계열 한국 기상청 데이터를 자연어로 다루는 대표 패턴이다. 공공 API를 감싸는 서버가 어떤 식으로 지역명 검색, 예보 시점, 응답 정규화를 처리해야 하는지 배울 수 있다. 작은 생활 데이터도 잘 감싸면 아주 강력한 MCP가 된다.