← 블로그로 돌아가기

MCP 서버란 무엇인가 — 개발자를 위한 입문

· 7분 읽기

한 문장으로 정의하자면

MCP(Model Context Protocol) 서버는 도구·리소스·프롬프트를 표준화된 JSON-RPC 형식으로 LLM 클라이언트에 노출하는 로컬 프로그램이에요. 양쪽이 각자 전용 연동을 만들지 않아도 모델이 사용자의 기기 위에서 데이터를 읽거나 작업을 실행할 수 있게 해 줘요.

정의는 여기까지예요. 나머지 섹션에서 속을 하나씩 풀어 볼게요.

Anthropic은 왜 MCP를 만들었을까

MCP 이전에는 LLM과 외부 시스템을 잇는 구현이 전부 제각각의 접착제였어요. ChatGPT 플러그인에는 플러그인 방식이 있었고, Copilot의 도구 호출은 다른 방식, Cursor는 자체 파일 편집 연동을 내놨어요. 어느 벤더든 "나열·읽기·실행·도구 설명"이라는 동일한 네 가지 프리미티브를 다시 발명하고 있었던 셈이에요. 결과적으로 벤더마다 락인이 생겼고, 도구 제작자에게는 유지보수 부담이 남았어요.

Anthropic은 2024년 말에 MCP를 어느 LLM 클라이언트든 말할 수 있고 어느 도구 제작자든 구현할 수 있는, 작고 수수한 프로토콜로 발표했어요. 선택한 트랜스포트(stdio 또는 HTTP) 위에 JSON-RPC를 얹고, 탐색과 호출 메서드는 고정이에요. 화려한 구석은 의도적으로 없어요. 그게 핵심이에요.

약 18개월 만에, 틈새의 Anthropic 규격에서 Claude Desktop, Cursor, GitHub Copilot 에이전트 모드, Continue, Windsurf, Zed가 모두 지원하는 존재가 됐어요. 클라이언트들은 전부 같은 서버에 같은 MCP 핸드셰이크를 수행해요. 즉 HTTP 트래픽을 읽는 도구 같은 걸 한 번만 작성하면 어느 IDE에서도 작동해요.

stdio와 HTTP 트랜스포트의 차이

MCP는 두 가지 트랜스포트를 지원해요. stdio(클라이언트가 서버를 자식 프로세스로 실행하고 표준 입출력으로 대화)와 HTTP(서버가 포트에서 대기하고 클라이언트가 접속). 선택에는 실질적인 의미가 있어요.

stdio 트랜스포트는 클라이언트와 같은 기기에서 동작하는 도구에 쓰여요. MCP 서버는 클라이언트가 실행하는 바이너리나 스크립트예요. 네트워크 포트도, 인증 레이어도 없어요. 프로세스 경계가 보안 경계예요. 로컬 용도 — 파일 시스템, 노트북 위의 데이터베이스, Rockxy 같은 HTTP 프록시, 그 밖에도 "모델이 당신의 기기를 건드리는 것 자체가 목적"인 도구 — 에는 이게 합리적인 기본값이 돼요.

HTTP 트랜스포트는 다른 곳에서 동작하는 도구용이에요. 원격 데이터베이스, MCP 어댑터가 달린 SaaS API, 팀 공용 서버 같은 것들이요. 서버는 장시간 유효한 HTTP 엔드포인트를 노출하고, 시간이 걸리는 도구 호출은 스트리밍으로 돌려주는 게 일반적이에요. 인증, TLS, 그 밖에 HTTP라면 당연히 해야 할 보안 조치가 필요하지만, 그 대신 여러 클라이언트가 서버 한 대를 공유할 수 있어요.

기준은 이래요. 도구가 사용자 자신의 기기나 데이터와 관련된 거라면 stdio. 공유 시스템에 대한 거라면 HTTP. stdio면 충분한 상황에서 HTTP를 쓰지 마세요. localhost에서 대기하는 HTTP 서버도 여전히 공격 면이에요.

MCP의 표면 — tools, resources, prompts

MCP 서버는 세 종류를 노출할 수 있어요. 각각 용도가 달라요.

Tools

도구는 모델이 호출할 수 있는 함수예요. 이름, 설명, 입력의 JSON Schema, 반환값의 형태를 가져요. 모델 입장에서는 다른 함수 호출 인터페이스와 구별이 되지 않아요.

{
  "name": "list_flows",
  "description": "List recent HTTP flows captured by the proxy.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "host": { "type": "string" },
      "method": { "type": "string" },
      "status": { "type": "integer" },
      "limit": { "type": "integer", "default": 20 }
    }
  }
}

Resources

리소스는 서버가 모델에 참고 자료로 넘길 수 있는 콘텐츠예요. 파일, URL, 데이터베이스에서의 발췌 등이죠. 리소스는 URI로 주소가 지정돼요. "모델이 호출하는 함수"보다는 "모델이 읽는 컨텍스트"에 가까운 위치예요.

파일 시스템용 MCP 서버는 모든 파일을 리소스로 노출할 수 있어요. HTTP 디버깅 서버는 캡처한 각 플로의 응답 바디를 리소스로 노출하기도 해요.

Prompts

프롬프트는 서버가 클라이언트에 제시하는 재사용 가능한 템플릿이에요. "이 플로의 취약점 요약을 만들어 줘" 같은 저장된 쿼리에 파라미터를 붙인 것이라고 생각하면 돼요. 클라이언트 쪽에서는 슬래시 명령이나 퀵 액션으로 표시돼요. 프롬프트까지 제공하는 서버는 많지 않아요. 세 가지 프리미티브 중 가장 덜 쓰여요.

좋은 MCP 서버의 조건

오래 살아남는 MCP 서버와 데모에서 멈춘 서버를 가르는 건 다음 네 가지예요.

도구 표면이 좁다. Rockxy의 MCP 서버는 도구 네 개를 노출해요. Linear의 MCP 서버라면 티켓·팀·프로젝트·사이클·라벨·댓글로 40개를 노출할 수도 있지만, 표면이 좁을수록 모델이 다루기 쉽고 감사도 쉬워요. 도구가 적으면 다른 MCP 서버와 이름이 충돌할 가능성도 줄어요.

가능한 한 멱등. 읽기 계열은 부작용 없이 반복할 수 있어야 해요. 쓰기 계열은 멱등 키를 받거나 스스로 중복 제거를 하도록 설계해요. LLM은 재시도해요. 응답이 느릴 때, 네트워크가 끊겼을 때, 첫 시도가 틀렸다고 모델이 판단했을 때 반드시 재시도해요. 모델이 한 번만 시도했는데 중복 요청을 세 개 만들어 버리는 리플레이 도구는 버그예요.

로컬 우선. MCP 서버는 벤더의 클라우드가 아니라 사용자의 기기 위에서 도는 게 기본이어야 해요. 데이터가 원래 클라우드에 있는 경우(Notion의 MCP 서버처럼 본질적으로 클라우드 전제인 것)라면 클라우드로도 괜찮지만, 로컬 도구에 클라우드 MCP 래퍼를 씌우는 건 정보 유출이에요.

감사 가능. 사용자는 도구 호출을 자기 클라이언트에서 전부 볼 수 있어야 해요. MCP 대응 클라이언트는 기본적으로 그렇게 만들어져 있어요. 서버 제작자는 도구의 의미를 이름에서 솔직히 읽어 낼 수 있게 유지해야 해요. 숨겨진 부작용이나 이름에서 짐작할 수 있는 수준을 넘는 일을 하는 도구는 피해요.

에코시스템의 구체적인 사례

MCP 서버가 노출하는 것의 구체적인 예를 들어 볼게요.

  • Filesystem MCP. read_file, list_directory, write_file 도구. 설정한 루트 아래의 파일을 리소스로 노출해요. 어시스턴트에 코드베이스를 복붙 없이 읽히는 데 편해요.
  • GitHub MCP. 이슈 목록, PR 생성, 리포지토리 메타데이터 취득을 위한 도구. 사용자가 준비한 토큰으로 GitHub API에 HTTP 트랜스포트로 호출하는 게 일반적이에요. 인증이 붙은 원격이지만 많은 클라이언트에서는 로컬 stdio를 거치는 얇은 심을 끼워요.
  • Postgres MCP. 읽기 전용 쿼리를 실행하는 도구. 스키마를 리소스로 제공. 표면이 좁고, 멱등이고, 로컬(로컬 DB를 가리킴)이라는 조건에 들어맞아요.
  • Rockxy MCP. 도구는 네 개: list_flows, get_flow_detail, replay_request, diff_flows. stdio 트랜스포트, 로컬 전용, 소스는 AGPL-3.0으로 공개. Claude Desktop(및 그 밖의 MCP 클라이언트)에 HTTP 트래픽을 읽히고 요청을 리플레이하게 만들 수 있어요.

전부 단일 도메인에 좁혀진 작은 도구 표면이에요. 어느 것도 "모든 걸 다루는 AI 연동 레이어"가 되려고 하지 않아요. 이 자제심이 에코시스템을 조합 가능하게 해 줘요 — 클라이언트는 작은 서버 다섯 개를 불러와 하나씩 하나의 일을 맡기죠. 거대한 서버에 이것저것 다 집어넣는 것보다 훨씬 건전해요.

2026년의 개발자는 MCP를 일상적으로 어떻게 쓸까

현실적인 2026년 구성은 이래요. 리서치와 디버깅용으로 Claude Desktop을 띄우고 MCP 서버 세 개를 불러와요 — 파일 시스템(작업 디렉터리로 한정), GitHub, Rockxy. claude_desktop_config.json은 아마 30줄 정도예요.

코드 편집에는 Cursor를 병행해서 쓰고, 프로젝트별 .cursor/mcp.json에서 파일 시스템 서버에 더해 프로젝트 고유의 서버(예를 들어 사내에서 만든 MCP 게이트웨이)를 한두 개 불러와요.

두 클라이언트는 서버 바이너리를 공유해요. Rockxy를 한 번 설치하면 Claude Desktop에서도 Cursor에서도 쓸 수 있어요. 설정 파일 위치는 클라이언트마다 다르지만 연결되는 서버는 같아요. 공통 프로토콜의 이점이 바로 여기예요. 클라이언트마다 연동을 다시 만들 필요가 없어져요.

일상적인 사용 방식은 이런 느낌이에요. Claude Desktop에 "방금 실패한 API 호출의 내용은?"이라고 물으면 Rockxy에 조회하러 가요. Cursor에 "이 함수를 테스트가 통과하도록 고쳐 줘"라고 부탁하면 파일 시스템 서버를 불러 읽고 써요. 클라이언트에 도구를 가르치기 위한 보일러플레이트는 더 이상 안 써도 돼요.

앞으로 어디로 향하는가

2026년 초 기준으로 몇 가지 흐름이 보여요.

멀티 에이전트 간 주고받기. MCP 서버는 대화형 채팅 클라이언트뿐 아니라 서로를 호출하는 백그라운드 에이전트에서도 쓰이기 시작했어요. 한 에이전트가 수신 이슈를 트리아지하고, 가능성 있는 것을 다른 에이전트에 넘겨 코드베이스를 읽게 하고, 세 번째 에이전트에 PR 초안을 넘겨 테스트를 실행하게 하죠. 어느 전달이든 MCP 호출이에요. 프로토콜이 이 목적으로 설계된 건 아니지만 문제없이 작동해요.

퍼스트파티 IDE 연동. Xcode, Visual Studio, JetBrains 계열 IDE 등이 MCP 클라이언트 지원을 출시했거나 프로토타입 중이에요. 1년 안에 주요 IDE가 LSP를 말하는 것만큼 당연하게 MCP도 말하게 될 거예요.

서버 마켓플레이스. 배포는 아직 약점이에요. 대부분의 MCP 서버는 JSON 파일을 수동으로 편집해 설치해요. 마켓플레이스 계층 — MCP 서버용 앱스토어 같은 것 — 은 자연스러운 다음 단계이고, 몇몇 클라이언트는 그 방향으로 개발 중이에요.

인가와 케이퍼빌리티 모델. 현행 MCP 명세는 인가 처리가 가벼워요. MCP 서버를 신뢰하거나 불러오지 않거나의 두 선택지에 가까운 상태예요. 에코시스템이 넓어지면 도구 단위 권한 부여(모델은 list_flows는 호출 가능하지만 replay_request는 호출 불가 같은 것)가 표준이 되어 갈 거예요.

작고 스코프가 깔끔한 MCP 서버가 실제로 동작하는 모습을 보고 싶다면 Rockxy 셋업 가이드가 3분이면 끝나요. 네 가지 프리미티브가 실제 디버깅 워크플로에 녹아드는 사례를 따라가 볼 수 있어요.

Rockxy 다운로드 MCP 도구 보기