쉽게 이해하기

MCP 자체가 표준이라면, MCP 서버는 그 표준을 실제 업무 도구에 붙이는 실행 단위입니다. 예를 들어 Postgres 조회, GitHub 이슈 생성, 파일 검색, 사내 문서 읽기 같은 기능을 서버가 tools, resources, prompts 형태로 노출합니다. 사용자가 대화형 AI 앱에서 작업을 요청하면 호스트는 MCP 클라이언트를 통해 해당 서버의 목록을 확인하고, 필요한 기능만 정책에 따라 호출합니다.

중요한 점은 MCP 서버가 모델 그 자체가 아니라는 점입니다. 서버는 외부 시스템을 감싸는 경계면이고, 모델 호출과 사용자 동의는 보통 호스트 쪽에서 관리합니다. 그래서 MCP 서버 설계는 "무엇을 할 수 있는가"만큼 "누가, 어떤 범위에서, 어떤 승인 절차로 실행할 수 있는가"가 중요합니다.

비유와 예시

• 데이터 조회 서버: 사내 데이터베이스를 직접 열지 않고, 허용된 테이블과 쿼리 템플릿만 resources/read 또는 제한된 tools/call로 노출한다.
• 운영 도구 서버: 배포 상태 조회, 로그 검색, 알람 음소거 같은 작업을 도구로 제공하되, 쓰기 작업은 사용자 승인 뒤에만 실행한다.
• 문서 작업 서버: 자주 쓰는 리뷰 템플릿을 prompts로 제공하고, 참고 문서를 resources로 읽게 해 모델이 필요한 맥락만 가져오게 한다.

한눈에 비교

MCP Server는 MCP의 구체적 인스턴스다. MCP를 안다고 해서 서버 운영 품질이 자동으로 확보되지는 않는다.

어디서 왜 중요한가

• 도구 재사용: 한 번 만든 MCP 서버를 여러 AI 앱과 에이전트에서 재사용할 수 있다.
• 권한 관리: 서버 단위로 읽기/쓰기, workspace, 사용자 scope를 분리할 수 있다.
• 배포 선택: 로컬 개발 도구는 STDIO로, 조직 공유 서비스는 Streamable HTTP로 배포할 수 있다.
• 보안 검수: 모델에게 보이는 tool description과 외부 resource가 prompt injection 표면이 되므로 서버 단위 검수가 필요하다.

자주 하는 오해

• 오해: MCP 서버는 그냥 API wrapper다 → 실제: tools, resources, prompts, capability negotiation, 호스트 승인 경계까지 포함해 설계해야 한다.
• 오해: 서버가 노출하면 모델이 바로 실행한다 → 실제: 호스트가 사용자 동의, 정책, 입력 검증을 거쳐 호출해야 한다.
• 오해: STDIO 서버는 보안 검토가 덜 필요하다 → 실제: 로컬 파일, 토큰, 쉘 도구에 접근할 수 있어 오히려 피해 반경이 클 수 있다.

대화에서는 이렇게

• "이 MCP 서버는 읽기 전용 resources와 승인 필요한 write tools를 분리해서 냅시다."
• "tool description은 모델 입력이니 prompt injection 검사를 배포 전에 돌리겠습니다."
• "원격 공유용은 Streamable HTTP로 배포하고, 개인 개발 도구는 STDIO로 유지하죠."
• "서버 registry에는 버전 고정과 provenance 확인을 넣어야 합니다."

함께 읽으면 좋은 용어

• 선행
  MCP — MCP 서버가 따르는 전체 프로토콜과 host/client/server 구조.
• 선행
  JSON-RPC — 서버가 주고받는 요청, 응답, 알림 메시지 형식.
• 유사
  Function Calling — 모델이 실행할 함수를 고르는 패턴으로, MCP tool 호출과 함께 쓰일 수 있다.
• 확장
  Prompt Injection — tool description과 resource 콘텐츠가 모델 행동을 오염시키는 위험.
• 확장
  Supply-chain attack — MCP 서버 패키지와 registry 신뢰성을 평가할 때 필요한 보안 관점.