2026년에 설치할 가치가 있는 MCP 서버: 엄선된 리뷰

올해 초 저는 Model Context Protocol (MCP)을 발견했을 때 모두가 하는 행동을 했습니다. 바로 모든 것을 설치하는 것이었습니다. Filesystem, git, GitHub, Postgres, SQLite, 웹 페처 (web fetcher), 두 개의 검색 서버, 브라우저 자동화 서버, 메모리 서버, 그리고 더 이상 기억나지 않는 몇몇 니치 (niche)한 서버들까지 말이죠. 저의 Claude Code 설정은 마치 크리스마스트리처럼 보였습니다. 그리고 약 일주일 동안은 강력하다는 느낌이 들었습니다. 에이전트가 모든 것에 접근할 수 있었으니까요. 하지만 제 컨텍스트 윈도우 (context window)를 읽기 시작하면서 그 느낌은 변질되었습니다. 에이전트가 제 코드 한 줄을 읽기도 전에, 컨텍스트의 약 5분의 1이 이미 사라져 있었습니다. 에이전트가 해당 세션에서 절대 사용하지 않을 기능들을 설명하는 도구 스키마 (tool schemas)가 컨텍스트를 잡아먹고 있었던 것입니다. 저는 온갖 것이 다 들어있는 싱크대(kitchen sink)를 만들어 놓고, 모든 수도꼭지마다 월세를 내고 있었던 셈입니다.

이 가이드는 그에 대한 교정안입니다. Claude Code를 주로 사용하고 Cursor, Cline, Goose 등을 병행하며 실제 업무에 코딩 에이전트를 몇 달간 적용해 본 결과, 카테고리별로 분류하여 지속적으로 제 역할을 다하는 MCP 서버들의 짧은 목록을 만들었습니다. 각 서버에 대해 무엇을 하는지, 언제 컨텍스트 비용을 지불할 가치가 있는지, 그리고 어디에서 조용히 토큰 예산을 낭비하는지 설명하겠습니다. 제 논지는 단순하며 다시 한번 반복하겠습니다: 온갖 것이 다 있는 싱크대보다, 더 적고 날카로운 서버들이 언제나 승리합니다.

MCP가 실제로 치르는 비용

2024년 말 Anthropic에 의해 도입되었고 현재 에이전트 기반 코딩 도구 전반에서 널리 지원되는 Model Context Protocol (MCP)은 AI 에이전트가 파일, 데이터베이스, API, 브라우저와 같은 외부 시스템과 통일된 인터페이스를 통해 통신할 수 있는 표준화된 방식입니다. 서버는 "도구 (tools)"(호출 가능한 함수), "리소스 (resources)"(읽기 가능한 데이터), 그리고 때로는 "프롬프트 (prompts)"를 노출합니다. 에이전트의 호스트는 이를 로드하여 모델이 사용할 수 있도록 합니다. 프로토콜 자체는 건전하고 진정으로 유용합니다. 문제는 운영 측면에 있습니다.

출시 데모에서 생략되는 부분이 바로 여기입니다. MCP 서버를 연결하면, 호스트는 에이전트가 해당 도구들을 실제로 호출하든 안 하든 상관없이, 세션 시작 시점에 서버가 노출하는 모든 도구의 전체 스키마(Schema)—이름, 설명, 파라미터 정의 등 모든 것—를 모델의 컨텍스트(Context)에 주입합니다. 적당히 복잡한 서버는 수십 개의 도구를 포함할 수 있으며, 각 도구는 한 단락의 설명과 중첩된 JSON 스키마를 가집니다. 서버 5~6개를 쌓으면 에이전트가 사용자의 프롬프트를 읽기도 전에 기능을 설명하는 데만 수만 개의 토큰을 소모할 수 있습니다. 저는 단일 설정에서 결합된 도구 정의가 전체 소스 파일을 로드하는 비용보다 더 큰 경우를 측정한 적이 있습니다.

비용은 단순히 돈만이 아닙니다. 그것은 주의력(Attention)과 정확도(Accuracy)의 문제입니다. 에이전트가 사용하지 않을 30개의 도구로 채워진 컨텍스트 창은 모델이 올바른 도구를 선택하는 속도를 늦추고, 잘못된 도구를 선택할 가능성을 높입니다. 제 경험상 이러한 성능 저하는 실재합니다. 비대해진 도구 세트 때문에 에이전트는 파일에서 읽을 수 있는 내용을 확인하기 위해 가끔 데이터베이스 쿼리 도구를 호출하기도 합니다. 도구를 추가할 때마다 당신은 모델이 매 턴마다 내려야 하는 선택지를 강요하는 것입니다. 큐레이션(Curation)은 단순히 깔끔하게 정리하는 것이 아니라, 정확도를 측정하는 척도입니다.

이것이 제가 더 이상 서버를 "유용한가?"라는 기준으로 평가하지 않는 이유입니다. 거의 모든 서버는 어떤 시나리오에서는 유용합니다. 저는 "내가 실제로 수행하는 작업에서 그 유용성이 매 세션마다 부과되는 고정된 컨텍스트 세금(Context tax)을 초과하는가?"를 기준으로 평가합니다. 대부분의 서버는 대부분의 경우 이 테스트를 통과하지 못합니다. 소수의 서버만이 거의 항상 이를 통과합니다.

핵심 3인방: Filesystem, Git, 그리고 Fetch

만약 제가 단 세 개의 서버만 실행할 수 있다면, 바로 이것들일 것입니다. 그리고 일상적인 코딩 작업의 상당 부분에는 세 개면 충분합니다.

**filesystem server (파일 시스템 서버)**는 에이전트에게 당신이 화이트리스트(whitelist)로 지정한 디렉토리에 대해 범위가 제한된 읽기 및 쓰기 권한을 부여합니다. 실제로 많은 코딩 에이전트들이 이미 네이티브 파일 접근 권한을 가지고 있기 때문에, 독립형 filesystem MCP server는 주로 내장 파일 도구가 없는 호스트를 사용하거나, 프로젝트 루트 외부의 디렉토리(공유 에셋 폴더, 형제 리포지토리, 문서 트리 등)에 대한 접근 권한을 부여하고 싶을 때 그 가치를 발휘합니다. 이 서버가 필요할 때는 허용된 경로를 엄격하게 유지하십시오. 홈 디렉토리를 가리키는 filesystem server는 보안상의 위험 요소가 될 뿐만 아니라, 에이전트가 여기저기 방황하도록 유혹하는 수단이 될 수 있습니다.

**git server (Git 서버)**는 제가 가장 오랫동안 과소평가했던 것입니다. 이 서버는 에이전트가 git 명령어를 셸(shell)로 실행하고 텍스트를 파싱하게 만드는 대신, 상태(status), 차이점(diff), 로그(log), blame, 브랜치 검사(branch inspection)와 같은 구조화된 Git 작업들을 도구(tools)로서 노출합니다. 여기서의 핵심 가치는 정밀함입니다. 에이전트는 터미널 출력을 긁어모으는 대신(이는 당신의 기대보다 훨씬 덜 신뢰할 수 있는 방식입니다), 깔끔하고 구조화된 diff와 히스토리를 받게 됩니다. "무엇이 바뀌었는가", "왜 이 라인이 추가되었는가", 또는 신중한 스테이지 커밋(staged commits)이 포함된 모든 워크플로우에서 git server는 제값을 합니다. 또한 매우 가볍습니다. 몇 가지 집중된 도구와 적당한 스키마 비용만 필요합니다.

**web fetch and search servers (웹 페치 및 검색 서버)**는 상황이 다소 미묘해지는 부분인데, 대화 중에는 종종 하나로 묶여 언급되지만 실제로는 두 가지 서로 다른 작업이기 때문입니다. **fetch server (페치 서버)**는 알려진 URL을 가져와 그 내용을 깔끔한 텍스트나 마크다운(markdown)으로 반환합니다. 에이전트에게 "이 링크의 문서를 읽어줘" 또는 "이 변경 로그(changelog)를 가져와줘"라고 말할 때 매우 유용합니다. **search server (검색 서버)**는 검색 엔진이나 인덱스에 쿼리를 날려 순위가 매겨진 결과를 반환하며, 에이전트가 이미 가지고 있지 않은 소스를 찾아내야 할 때 사용됩니다. 저는 거의 항상 fetch server를 실행합니다. 비용이 저렴하고 활용도가 매우 높기 때문입니다. 반면 search server는 좀 더 선택적으로 추가합니다. 성능이 좋은 것들(실제 검색 API에 연결된 것들)은 더 무거운 스키마를 가질 수 있고, 제공업체에 따라 쿼리당 실제 비용이 발생할 수 있기 때문입니다.

제가 핵심적으로 사용하는 세 가지 서버에서 하나의 패턴을 발견했습니다. 그것들은 모두 범위가 좁고 엄격하게 제한된 소수의 도구(tools)만을 노출한다는 점입니다. git 서버는 GitHub 클라이언트가 되려고 애쓰지 않습니다. fetch 서버는 한 가지 일만 수행합니다. 그러한 집중력이 바로 이 서버들을 계속 로드해 두어도 부담스럽지 않게 만드는 핵심입니다. 제가 삭제하는 서버들은 예외 없이 스무 가지 일을 하려고 시도하는 것들입니다. 단 두 가지만 필요했던 세션에서 스무 가지 분량의 스키마(schema) 비용을 청구하니까요.

상황별 활용 능력: 데이터베이스 및 브라우저 자동화 (Browser Automation)

이 서버들은 작업별로 설치하고 작업이 끝나면 제거하는 것들입니다. 이들은 켜고 끄는 번거로움을 감수할 만큼 충분히 강력하며, 그 번거로움 자체가 하나의 신호가 됩니다. 즉, 어떤 서버를 가끔씩만 실행할 가치가 있다면, 그것은 항상 켜져 있는 설정(always-on config)에 머물러서는 안 된다는 것입니다.

데이터베이스 서버 (Database servers) — 제가 주로 사용하는 것은 Postgres와 SQLite 두 가지입니다 — 에이전트(agent)가 스키마를 조사하고, 쿼리(query)를 실행하며, 데이터 구조에 대해 직접 추론할 수 있게 해줍니다. Postgres 서버는 "이 스키마를 이해하고 마이그레이션(migration) 작성을 도와줘"라거나 "이 쿼리가 왜 느린지 실제 테이블을 보고 확인해줘"와 같은 특정 작업에 진정으로 탁월합니다. 에이전트에게 수동으로 스키마 덤프(schema dump)를 제공하는 것보다 테이블, 인덱스(index), 제약 조건(constraints)을 훨씬 더 빠르게 조사할 수 있습니다. SQLite 서버도 작은 규모에서는 동일한 개념이며, 로컬 앱 데이터베이스나 분석 파일에 완벽합니다. 주의사항은 명백하지만 분명하게 언급할 가치가 있습니다. 명확한 이유가 없다면 이 서버들은 읽기 전용(read-only)으로 연결하십시오. 그리고 쓰기 권한(write access)을 가지고 프로덕션(production) 환경에 절대 연결하지 마십시오. 쓰기 가능한 프로덕션 데이터베이스 연결 권한을 가진 에이전트는 제가 감수할 수 없는 리스크 프로필(risk profile)입니다.

Playwright 서버를 통한 **브라우저 자동화 (Browser automation)**는 이 목록에서 가장 강력한 도구이며, 적절한 순간에 가장 유용합니다. 이 서버는 실제 브라우저를 구동하여 탐색, 클릭, 양식 채우기, DOM 읽기, 스크린샷 촬영 등을 수행합니다. 엔드 투 엔드 (end-to-end) 테스트 작성, 에이전트가 렌더링된 결과를 실제로 확인해야 하는 "페이지 렌더링 오류" 디버깅, 그리고 단순한 페처 (fetcher)로는 불가능한 스크래핑 (scraping) 워크플로우를 위해서는 이만한 대안이 없습니다. 하지만 브라우저를 제어하는 것 자체가 본질적으로 수많은 작은 작업들로 이루어져 있기 때문에, 가장 방대한 도구 표면 (tool surface)을 가질 가능성이 높은 서버이기도 합니다. 저는 테스트 세션 동안에만 Playwright를 설치하고 작업이 끝나면 제거합니다. 이를 상시 로드된 상태로 두는 것은 제가 다른 사람들의 설정에서 보는 가장 흔한 토큰 예산 (token-budget) 낭비 실수입니다.

GitHub와 메모리: 의도적인 트레이드오프 (Trade-offs)

두 개의 서버를 더 별도의 섹션으로 다룰 가치가 있는데, 그 이유는 두 서버 모두 기본값으로 널리 추천되지만, 저는 두 서버 모두 의도적인 선택이 되어야 한다고 생각하기 때문입니다.

GitHub 서버는 이슈 (issues), 풀 리퀘스트 (pull requests), 리포지토리 콘텐츠, 리뷰, 액션 (actions) 등 GitHub API를 도구로 노출합니다. "이 오픈 이슈들을 분류해줘"라거나 "이 PR 스레드를 요약해줘", 또는 "이 설명으로 PR을 생성해줘"와 같은 작업에는 정말 유용합니다. 문제는 GitHub API가 매우 방대하며, 포괄적인 GitHub 서버는 이를 반영하여 스키마 (schema)가 무거운 대규모 도구 세트를 제공한다는 점입니다. 만약 당신의 작업이 주로 로컬 코딩 위주이고 가끔 PR을 생성하는 정도라면, 거의 사용하지 않는 기능들을 위해 막대한 컨텍스트 비용 (context tax)을 지불하고 있는 셈입니다. 저의 절충안은 이렇습니다. 이슈 분류나 리뷰가 집중되는 세션 동안에만 GitHub 서버를 실행하고, 나머지 시간에는 경량화된 git 서버와 gh CLI에 의존합니다. CLI 방식은 스키마 비용이 거의 들지 않으면서도 제가 실제로 수행하는 작업의 대부분을 커버할 수 있습니다.

**메모리 서버 (memory server)**는 철학적으로 가장 흥미로우면서도 제가 가장 주의를 기울이는 부분입니다. 이는 에이전트에게 세션 전반에 걸쳐 사실(프로젝트 관례, 결정 사항, 사용자 선호도 등)을 기억할 수 있는 영구 저장소 — 일반적으로 지식 그래프 (knowledge graph) 또는 키-값 (key-value) 레이어 — 를 제공합니다. 그 약속은 매일 아침 사용자의 코드베이스를 다시 학습할 필요가 없는 에이전트입니다. 실제 결과는 엇갈립니다. 메모리 서버의 성능은 그곳에 무엇이 기록되느냐에 달려 있으며, 에이전트는 무엇을 기억할지 결정하는 데 있어 일관성이 없습니다. 저는 메모리 서버가 오래되거나 모순된 사실을 축적하여 이후의 세션을 적극적으로 오도하는 것을 보았습니다. 제대로 작동할 때는 매우 훌륭하지만, 정보가 어긋나기 시작하면 아무것도 없는 것보다 못합니다. 저는 이를 기본 설정이 아닌 프로젝트별 실험으로 취급하며, 쓰레기 데이터를 정리하기 위해 저장된 내용을 주기적으로 읽어봅니다.

엄선된 리스트의 구성 방식

다음은 요약된 저의 실제 의사결정 프레임워크입니다. "~에 가장 적합 (best for)" 열을 "이 서버가 컨텍스트 비용 (context cost)을 지불할 가치가 명확히 있는 단 한 가지 상황"으로 읽으십시오.

해당 표의 형태가 곧 논점의 핵심입니다. 비용이 낮은 세 개의 서버는 기본 설정 (default config)에 포함되어야 합니다. 그 외의 모든 것은 컨텍스트 세금 (context tax)과 비교하여 작업별로 결정해야 합니다. 만약 당신의 설정에 항상 켜져 있는 서버가 4~5개 이상 있다면, 저는 그중 일부가 당신이 더 이상 인지하지 못하는 무거운 짐(dead weight)이라고 확신합니다.

몇 가지 실질적인 설치 참고 사항

대부분의 코딩 에이전트는 JSON 파일을 통해 MCP 서버를 구성합니다. Claude Code와 Cursor 모두 각 서버가 명령(command)과 인자(arguments)를 갖는 설정 파일을 사용하며, 참조용 서버의 경우 자주 npx를 통해 실행되거나 다른 서버의 경우 전용 바이너리 (binary)를 통해 실행됩니다. 작동 방식은 도구별로 잘 문서화되어 있으므로, 상투적인 설명은 생략하고 실제로 중요한 운영상의 조언을 드리겠습니다.

첫째, 모든 서버의 범위를 필요한 최소한으로 제한하십시오. 파일 시스템 (Filesystem) 서버는 허용된 디렉토리 인자 (allowed-directory arguments)를 받으므로, 이를 활용하십시오. 데이터베이스 (Database) 서버는 연결 문자열 (connection strings)을 받습니다. 이를 운영 환경의 기본 서버 (production primaries)가 아닌 읽기 복제본 (read replicas)이나 로컬 복사본을 가리키도록 설정하십시오. 둘째, 호스트가 지원한다면 개별 도구 (tools)를 비활성화할 수 있는 서버를 선호하십시오. 규모가 큰 서버의 도구 목록을 줄이는 것은 토큰 (token) 비용을 아낄 수 있는 가장 저렴하고 효과적인 방법입니다. 셋째, 정기적으로 감사(audit)하십시오. 새로운 세션을 열고, 실질적인 내용을 입력하기 전에 컨텍스트 (context)에 무엇이 포함되어 있는지 살펴본 뒤, 각 로드된 서버가 마지막 점검 이후로 그 자리를 유지할 가치가 있는지 자문해 보십시오. 저는 대략 한 달에 한 번씩 이 작업을 수행하며, 거의 항상 무언가를 제거합니다.

마지막으로, 마켓플레이스 (marketplace)의 본능에 저항하십시오. 사용 가능한 MCP 서버의 생태계는 방대하고 성장하고 있으며, 그중 아주 많은 서버가 완벽하게 실재하고 훌륭합니다. 바로 그것이 함정입니다. 사용 가능하다는 것이 설치의 이유가 될 수는 없습니다. 올바른 질문은 결코 "이것이 유용할 수도 있을까?"가 아니라, "이것이 나의 실제 업무에서 매 턴(turn)마다 발생하는 비용을 정당화할 만큼 충분히 유용한가?"여야 합니다. 이 질문에 솔직하게 답한다면 여러분의 설정 (config)은 빠르게 간결해질 것입니다.

어떤 서버를 실행해야 하는가

만약 당신이 주로 로컬 코딩을 하는 1인 개발자라면, 파일 시스템 (filesystem) (호스트에 필요한 경우), git, 그리고 fetch 서버를 실행하십시오. 그것으로 충분합니다. 데이터베이스를 다루는 날에 데이터베이스 서버를 추가하고, 그 다음 날 바로 제거하십시오. 당신이 얼마나 많은 것을 그리워하지 않는지 알고 놀라게 될 것입니다.

만약 당신이 PR(Pull Request) 및 리뷰 워크플로가 활발한 팀에서 일한다면, GitHub 서버가 그 비용을 정당화하기 시작할 것입니다. 하지만 평소의 코딩 설정 (config) 대신 전용 "리뷰 모드" 설정에서 실행하는 것을 고려하십시오. 그래야 일반적인 세션이 가볍게 유지됩니다.

만약 당신이 **QA, 테스트 작성, 또는 프론트엔드 디버깅 (front-end debugging)**을 수행한다면, Playwright가 세션별로 설치할 가치가 있는 고효율 선택지입니다. 이를 fetch 및 git과 조합하고 나머지 거의 모든 것은 건너뛰십시오.

만약 **메모리 서버 (memory server)**의 유혹을 느낀다면, 정확히 하나의 프로젝트에서만 테스트해 보십시오. 일주일 후에 서버가 무엇을 저장하고 있는지 확인한 다음, 저장된 사실들이 에이전트 (agent)에게 도움이 되고 있는지 아니면 조용히 거짓 정보를 제공하고 있는지에 따라 사용 여부를 결정하십시오. 맹목적인 믿음으로 모든 곳에 배포하지 마십시오.