MCP 클라이언트 비교: Claude Desktop, Cursor, VS Code, Windsurf, Cline, Zed

모델 컨텍스트 프로토콜(Model Context Protocol)이 서버 측 파편화 문제를 너무 완벽하게 해결해서, 이를 클라이언트 측에서 대체했습니다. 현재 6가지 인기 AI 도구가 MCP를 사용하며, 각 도구는 자체 설정 파일, 자체 UI 경로, 환경 변수가 올 수 있는 규칙, 그리고 원격 OAuth 흐름에 대한 고유한 허용 범위를 가지고 있습니다. 만약 이전에 한 에디터의 문서를 다른 에디터에 복사해 넣었는데 아무 일도 일어나지 않는 것을 본 적이 있다면, 이 가이드가 여러분을 위한 것입니다.

아래 내용은 stdio 또는 Streamable HTTP를 통해 작동하는 서버를 가정합니다. 전송 방식을 먼저 선택한다면 MCP stdio 대 원격 전송(stdio vs remote transports)을 읽어보세요.

각 클라이언트가 설정을 저장하는 위치

| 클라이언트 | 설정 위치 | stdio | 원격 HTTP | UI 내 OAuth | :--- |
| Claude Desktop | ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) | 예 | 예 | 예 |
| ... |
프로젝트 범위의 설정(Cursor, VS Code)은 하나의 리포지토리에 연결된 서버에 적합한 기본값이며, 전역 설정은 모든 프로젝트가 필요로 하는 개인용 도구에 적합합니다. 비밀 정보를 프로젝트 설정에 커밋하지 마세요. 환경 변수를 참조하고 README에 문서화하세요.

클라이언트별 stdio 설정

stdio 형태는 어디서나 거의 동일하며, 이는 프로토콜이 제 역할을 하고 있음을 보여줍니다. Claude Desktop과 Cursor는 표준 블록을 사용합니다:

{
  "mcpServers": {
    "orders": {
...

VS Code는 같은 서버를 선언적으로 표현하며, 명령 항목을 통해 stdio를 지원합니다:

{
  "servers": {
    "orders": {
...

Zed는 자체 키 이름을 사용하지만 필드는 동일합니다:

{
"context_servers": {
    "orders": {
...

Cline은 수동으로 편집하는 파일보다는 MCP Servers 패널을 통해 구성되므로, 비기술적인 팀원에게 가장 쉽고 다른 모든 사람들에게는 스크립팅하기 가장 어렵습니다.

원격 HTTP 설정

호스팅된 서버의 경우 설정은 URL로 축소되며, 클라이언트가 OAuth 2.1 과정을 담당합니다:

Claude Desktop과 Cursor는 브라우저 기반 인증 흐름을 자동으로 열고 리프레시 토큰을 저장합니다. 최근 버전의 VS Code도 동일하게 처리하며, 동의(consent)를 알림으로 표시합니다. Windsurf와 Zed는 역사적으로 동적 클라이언트 등록에 뒤처져 왔습니다. 만약 인증 서버가 사전 등록된 클라이언트를 지원하지 않는다면, 헤더에 개인 액세스 토큰을 전달해야 할 수 있습니다:

{
  "mcpServers": {
    "orders": {
...

이것은 디자인 목표라기보다는 호환성 대체 방안으로 간주하십시오. OAuth 흐름은 MCP 인증 설명에서 설명합니다.

오후 시간을 낭비하게 만드는 함정들

PATH는 셸의 PATH가 아닙니다. macOS GUI에서 실행된 데스크톱 앱은 최소한의 환경을 상속받습니다. 터미널에서 npx나 python이 작동하지만 클라이언트가 명령어를 찾을 수 없다고 보고하면, 절대 경로(which npx)를 사용하거나 프로필을 소싱하는 셸 스크립트로 실행을 감싸십시오.

npx 캐싱은 업데이트를 숨깁니다. 버전 지정 없이 -y @acme/orders-mcp를 사용하면 캐시된 빌드를 제공할 수 있습니다. 팀 공유 설정의 경우 버전을 고정하거나 모두가 이해하는 @latest 정책을 추가하십시오.

도구 개수 제한. 클라이언트는 모델에 노출되는 도구 수를 제한하며, 일반적으로 수십 개입니다. 300개의 도구를 광고하는 서버는 조용히 잘립니다. 도구를 신중하게 통합하고 이름을 지정하십시오. 모든 내부 API를 위한 단일 MCP 게이트웨이의 게이트웨이 패턴이 이를 직접적으로 해결합니다.

편집 후 재시작. 대부분의 클라이언트는 시작 시 설정을 읽습니다. Cursor와 VS Code는 설정 파일을 감시하지만, Claude Desktop은 역사적으로 전체 재시작을 필요로 했습니다. 서버가 나타나지 않을 때는 서버를 디버깅하기 전에 재시작하십시오.

하나의 stdio 프로세스당 하나의 클라이언트가 예상됩니다. 동일한 stdio 서버를 두 개의 열린 편집기에서 실행하면 각각 고유한 상태를 가진 두 개의 프로세스가 시작됩니다. 공유되어야 하는 모든 것은 프로세스 메모리가 아닌 원격 서버에 포함되어야 합니다.

클라이언트를 탓하기 전에 서버를 검증하십시오. 제가 본 "도구가 나타나지 않는다"는 유형의 문의 중 절반가량은 클라이언트 설정 문제와 initialize에 실패하는 서버 문제로 나뉘었습니다. 먼저 Inspector를 통해 서버를 실행해 보십시오. 해당 절차는 how to test and debug an MCP server에서 확인할 수 있습니다.

팀 배포를 위한 선택 방법

내부 MCP 서버로 표준화하려는 회사에게 운영적인 답변은 보통 다음과 같습니다:

1. OAuth가 지원 경로인 원격 Streamable HTTP 서버를 게시하고, 공유 인프라에 대해 아무도 JSON을 수동으로 편집하지 않도록 합니다.
2. 개발자들이 로컬에서 목(mocks) 및 스테이징 데이터와 비교하여 stdio 빌드를 추가로 실행하도록 합니다.
3. 두 가지 설정 블록(URL 및 stdio)을 한 곳에 문서화하고, UI에서 OAuth를 지원하는 정확한 클라이언트 버전을 명시하며, 나머지는 개별적인 선호 사항으로 취급합니다.

서버 자체가 OpenAPI 스펙으로부터 생성되는 경우, 두 구성 모두 동일한 도구 세트의 빌드를 가리킵니다: 오프라인 및 스펙 기반 작업을 위한 로컬 stdio 빌드와 공유 서비스를 위한 호스팅된 빌드입니다. 온라인 데모에서 스펙을 통해 두 대상 중 어느 것을든 생성할 수 있으며, 엔드투엔드 원격 설정은 connecting Cursor and Claude Code to your internal API over MCP에서 안내합니다.