Model Context Protocol (MCP)는 2025년 어느 시점에 이미 신기함을 넘어선 기술이 되었습니다. Anthropic은 2024년 말에 사양(spec)을 발표했으며, 현재 주요 코딩 에디터들 — Cursor, Copilot을 통한 VS Code, Zed, 그리고 Claude 데스크톱 및 CLI 클라이언트 — 모두 동일한 mcp.json 스타일의 설정을 읽습니다. 이는 한 번 연결한 서버가 특정 벤더에 종속되지 않고, 여러분이 이미 사용 중인 도구들 전반에서 작동하는 경향이 있음을 의미합니다.

이제 문제는 서버를 찾는 것이 아닙니다. 공개 레지스트리에는 수백 개가 나열되어 있지만, 대부분은 직접 호출하는 것이 더 나은 API를 단순히 감싸고 있는 얇은 래퍼(wrapper)에 불과합니다. 우리는 작업 방식을 변화시키는 서버와 단순히 지연 시간(latency) 및 새로운 오류 모드(failure mode)만 추가하는 서버를 구분하기 위해, 실제 프로젝트 내에서 몇 가지를 실행하며 시간을 보냈습니다. 그 결과는 다음과 같습니다.

MCP 서버가 실제로 제공하는 것

MCP 서버는 에디터의 AI에게 세 가지를 제공합니다: 호출할 수 있는 도구(tools), 읽을 수 있는 리소스(resources), 그리고 재사용할 수 있는 프롬프트(prompts)입니다. 실질적인 효과는 모델이 여러분의 환경에 대해 추측하는 것을 멈춘다는 것입니다. 그럴듯한 테이블 이름을 지어내는 대신, 모델은 여러분의 스키마(schema)를 쿼리합니다. API 응답 형태를 환각(hallucination)하는 대신, 실제 응답을 가져옵니다.

이것은 서버가 모델이 가진 진정한 격차(gap)를 메울 때만 가치가 있습니다. 모델은 이미 여러분이 열어둔 파일과, 대부분의 에디터에서는 git diff를 알고 있습니다. 하지만 모델은 여러분의 운영 데이터베이스 스키마, Linear 티켓의 내용, 또는 팀 위키(wiki) 페이지에 무엇이 적혀 있는지는 알지 못합니다. 이러한 격차야말로 서버가 설정 슬롯을 차지할 수 있는 지점입니다.

여러분이 활성화하는 모든 MCP 서버는 에디터의 권한으로 실행되는 코드이며, 많은 서버가 광범위한 도구 범위(tool scopes)를 가지고 배포됩니다. 쓰기 권한이 있는 데이터베이스 서버는 모델이 혼란을 겪고 여러분이 승인을 클릭할 경우 DROP TABLE을 실행할 수 있습니다. 활성화하기 전에 도구 목록을 확인하고, 실제 데이터 저장소에 접근하는 모든 것에는 읽기 전용(read-only) 자격 증명을 선호하며, 쓰기 도구에 대한 자동 승인(auto-approval)은 꺼두십시오.

지속적으로 제 역할을 다한 4가지 서버

Filesystem 및 fetch (내장 도구). 프로젝트 루트(project root)로 범위를 제한한 참조용 filesystem 서버와 fetch/web 서버는 가장 흔한 공백을 메워줍니다. 즉, 현재 에디터 창 외부의 파일을 읽거나 라이브 URL을 컨텍스트(context)로 가져오는 작업입니다. 이들은 MCP 프로젝트 자체에서 제공되므로 가장 위험 부담이 적은 시작점입니다. 다른 것은 하지 않더라도, filesystem 접근 권한은 하나의 디렉토리로 제한하고 그 이상은 허용하지 마십시오.

데이터베이스 서버 (Postgres/SQLite). 이것은 우리의 일상을 가장 많이 변화시킨 도구입니다. 읽기 전용(read-only) 역할을 가진 읽기 복제본(read replica)을 가리키게 하면, 모델이 마이그레이션(migration) 코드를 작성하기 전에 스키마(schema)를 조사하고, 컬럼(column) 타입을 확인하며, 실제 데이터에 대해 쿼리(query)를 검증할 수 있게 해줍니다. "작동할 것 같은 쿼리입니다"와 "귀하의 스키마에서 실행해 보니 14개의 행이 반환되었습니다"의 차이는 단순한 제안과 확신에 찬 답변의 차이입니다.

버전 관리 / 이슈 서버 (GitHub, Linear). GitHub 서버를 연결하면 사용자가 복사해서 붙여넣을 필요 없이 모델이 PR(Pull Request)의 리뷰 댓글이나 이슈(issue) 스레드를 읽을 수 있습니다. 우리는 이것이 코드 작업 중 지루한 절반의 과정을 처리하는 데 가장 유용하다는 것을 발견했습니다. 예를 들어, 긴 PR 스레드에서 실제로 결정된 내용을 요약하거나, 구현 코드를 작성하기 전에 티켓(ticket)에서 수락 기준(acceptance criteria)을 가져오는 작업 등입니다.

문서/지식 서버 (Notion, Sentry). 설계 결정 사항과 런북(runbook)이 위키(wiki)에 저장되어 있을 때, 이를 읽는 서버가 있다면 모델은 일반적인 모범 사례(best practice) 대신 팀의 실제 관례(convention)에 기반하여 답변을 내놓을 수 있습니다. Sentry 서버는 에러에 대해 동일한 역할을 수행합니다. 스택 트레이스(stack trace)를 붙여넣으면, 모델은 사용자가 우연히 복사한 잘린 스니펫(snippet)이 아니라 전체 이벤트 컨텍스트(event context)를 가져와 작업할 수 있습니다.

설정을 비대하게 만들지 않고 서버 선택하기

서버가 많다고 해서 더 좋은 것은 아닙니다. 각 서버는 모델이 추론해야 할 도구 목록(tool list)을 늘리며, 도구 목록이 너무 많아지면 도구 선택 성능이 눈에 띄게 저하됩니다. 즉, 모델이 잘못된 도구를 선택하거나, 하나면 충분할 상황에서 세 개를 호출하는 등의 문제가 발생합니다. 저희는 모든 기능을 전역적으로 활성화하기보다, 활성 세트를 작게 유지하고 프로젝트별로 특화했을 때 가장 깔끔한 동작을 확인했습니다.

대부분의 프로젝트를 위한 합리적인 시작 설정은 3개에서 5개의 서버입니다. 레포지토리(repo)에 한정된 파일 시스템(filesystem), 읽기 전용(read-only) 권한을 가진 데이터베이스(database), VCS 또는 이슈 트래커(issue tracker), 그리고 하나의 지식 소스(knowledge source) 정도가 적당합니다. 네 번째나 다섯 번째 서버는 추측에 기반하지 말고, 구체적인 공백이 느껴질 때만 추가하세요.

대부분의 에디터는 MCP 서버를 전역(globally)뿐만 아니라 프로젝트별(per-project)로 정의할 수 있게 해줍니다. 데이터베이스와 이슈 트래커 서버는 레포지토리 옆에 위치한 프로젝트 수준의 설정(project-level config)에 두고, 전역 설정은 파일 시스템(filesystem)이나 fetch와 같이 진정으로 범용적인 도구로만 제한하세요. 이렇게 하면 관련 없는 사이드 프로젝트를 진행할 때 클라이언트의 운영 데이터베이스(production database)가 컨텍스트에 포함되는 것을 방지할 수 있습니다.

여전히 문제가 발생하는 지점들

기대치를 조정해야 할 두 가지 거친 지점(rough edges)이 있습니다. 첫째는 인증(authentication)입니다. SaaS API와 통신하는 서버는 토큰(token)이 필요하며, 저장 방식은 에디터마다 다릅니다. 어떤 에디터는 환경 변수(environment variables)에서 읽어오고, 어떤 에디터는 설정 파일에 평문(plaintext)으로 저장합니다. MCP 설정에 넣는 모든 토큰은 유출될 수 있다고 가정하고, 필요한 최소한의 권한으로 범위를 제한(scope)하세요.

둘째는 신뢰성(reliability)입니다. MCP 서버는 별도의 프로세스이며, 서버가 충돌하거나 멈추면 모델이 마땅히 알아야 할 것을 신비롭게 "모르는" 것처럼 실패가 나타납니다. 서버 기반의 답변이 틀린 것처럼 보인다면, 모델을 탓하기 전에 서버가 실제로 실행 중인지 먼저 확인하세요. 프로토콜 자체에 비해 상태 확인(health) 및 관찰 가능성(observability)을 위한 툴링은 아직 미비한 상태입니다.

이러한 점들이 MCP를 건너뛰어야 할 이유는 아닙니다. 대신 좁게 시작해야 할 이유가 됩니다. 실제로 필요하다고 느끼는 공백을 메워주는 2~3개의 서버로 시작하고, 데이터 저장소(datastore)가 관여될 때는 읽기 전용(read-only)으로 설정하며, 쓰기 작업이 발생하는 모든 것에는 승인(approval) 단계를 유지하세요.