Claude든 다른 LLM 클라이언트든, 모델이 파일을 읽거나 외부 API를 호출하게 하려면 "도구 호출" 기능이 필요합니다. 문제는 이 도구 연동 방식이 벤더마다 제각각이었다는 점입니다. OpenAI의 함수 호출 스펙과 다른 벤더의 플러그인 스펙이 서로 호환되지 않아서, 같은 도구(예: GitHub 연동, DB 조회)를 여러 AI 클라이언트에서 쓰려면 클라이언트별로 어댑터를 따로 만들어야 했습니다.

왜 필요한가

도구를 하나 만들 때마다 "이 도구를 어떤 클라이언트에 붙일 것인가"를 고민해야 하는 구조는 확장성이 떨어집니다. 웹 개발 초기에 브라우저마다 API가 달라서 폴리필을 겹겹이 쌓았던 것과 비슷한 문제입니다. Anthropic이 2024년 11월 공개한 MCP(Model Context Protocol)는 이 연동 방식을 표준화합니다. 서버 쪽에서 MCP 스펙에 맞춰 도구를 한 번 구현해두면, MCP를 지원하는 어떤 클라이언트(Claude Desktop, Claude Code, 그 외 MCP 호환 도구)에서도 같은 서버를 그대로 붙여 쓸 수 있습니다. USB가 기기마다 다른 커넥터를 하나로 통일한 것과 같은 역할입니다.

핵심 개념

MCP는 클라이언트-서버 구조이고, 메시지는 JSON-RPC 2.0 형식을 씁니다. 서버가 클라이언트에 제공하는 기능은 세 가지 primitive로 나뉩니다.

  • Tools: 모델이 호출할 수 있는 함수. 입력 스키마와 실행 로직을 서버가 정의합니다. (예: get_forecast(city) 처럼 날씨를 조회하는 함수)
  • Resources: 모델이 읽어올 수 있는 데이터. 함수 호출이 아니라 파일처럼 URI로 식별되는 컨텍스트입니다. (예: file:///logs/latest.txt)
  • Prompts: 자주 쓰는 프롬프트를 서버가 템플릿으로 미리 정의해두고, 클라이언트가 인자만 채워서 재사용하는 기능

전송 방식(transport)은 두 가지가 주로 쓰입니다. 로컬 프로세스를 표준입출력으로 띄우는 stdio는 별도 네트워크 설정 없이 클라이언트가 서버 프로세스를 직접 실행하는 방식이라 로컬 개발 도구에 적합합니다. 원격 서버에 붙는 경우에는 Streamable HTTP를 쓰는데, 이 경우 인증(OAuth 등)과 배포를 직접 신경 써야 합니다.

실전 예시

Python SDK의 FastMCP를 쓰면 데코레이터만으로 도구 하나를 서버로 노출할 수 있습니다.

# weather_server.py
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Weather")

@mcp.tool()
def get_forecast(city: str) -> str:
    """도시 이름으로 오늘 날씨 예보를 조회합니다."""
    # 실제 서비스라면 여기서 외부 기상 API를 호출합니다
    forecasts = {
        "seoul": "맑음, 최고 24도",
        "busan": "흐림, 최고 21도",
    }
    return forecasts.get(city.lower(), f"{city}의 예보 데이터가 없습니다")

if __name__ == "__main__":
    mcp.run(transport="stdio")

이 서버를 클라이언트에 등록할 때는 실행 커맨드만 설정 파일에 적어주면 됩니다. Claude Desktop 기준 설정 파일 예시입니다.

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["/absolute/path/to/weather_server.py"]
    }
  }
}

클라이언트가 재시작되면 서버 프로세스를 자동으로 띄우고, get_forecast라는 도구가 있다는 사실과 함수 시그니처(도구 이름, 파라미터, docstring)를 모델에게 전달합니다. 이후 사용자가 "서울 날씨 알려줘"라고 물으면 모델이 이 도구를 호출할지 스스로 판단해서 실행합니다. 같은 weather_server.py를 MCP를 지원하는 다른 클라이언트에 등록해도 코드 수정 없이 그대로 동작합니다.

장단점 정리

장점

  • 벤더 중립적인 표준이라, 한 번 만든 서버를 여러 클라이언트에서 재사용할 수 있음
  • Tools/Resources/Prompts로 역할이 명확히 나뉘어 있어서, "모델이 실행할 것"과 "모델이 참고만 할 것"을 설계 단계에서 분리할 수 있음
  • stdio transport는 로컬 프로세스 실행이 전부라 인증 인프라 없이 바로 시작할 수 있음

단점

  • 생태계가 아직 초기라 커뮤니티 MCP 서버 품질 편차가 큼. 신뢰할 수 없는 서버는 실행 전 코드를 확인해야 함
  • 원격 서버로 배포하려면(Streamable HTTP) 인증·네트워크 설정을 직접 챙겨야 해서 stdio보다 진입 장벽이 있음
  • 도구를 너무 많이 붙이면 모델에 전달되는 도구 목록 자체가 길어져서 컨텍스트를 소비하고, 오히려 어떤 도구를 쓸지 판단이 흐려지는 경우가 있어 필요한 도구만 선별해서 붙이는 게 좋음

도구 연동을 클라이언트별로 따로 만들어야 했던 문제를 표준 하나로 풀었다는 점에서, MCP는 이미 여러 AI 코딩 도구·데스크톱 클라이언트가 채택하는 쪽으로 자리잡는 중입니다. 직접 서버를 만들 계획이 없더라도, 지금 쓰는 AI 도구가 왜 "MCP 서버 추가"라는 설정 항목을 두고 있는지는 알아두면 도움이 됩니다.