2.3툴 제공 방식 선택

Claude의 툴은 누가 실행하느냐에 따라 두 부류로 나뉩니다.

클라이언트 툴(client tools) 은 여러분의 코드가 실행합니다. API 요청의 tools 배열에 스키마를 정의하면, 모델이 tool_use 블록으로 호출 의사를 밝히고(stop_reason: "tool_use"), 여러분의 코드가 실제 실행 후 tool_result를 돌려보냅니다. 사내 DB 조회, 내부 API 호출처럼 여러분의 인프라에 접근하는 모든 기능이 여기에 해당합니다.

서버 툴(server tools) 은 Anthropic 서버가 정의하고 실행까지 담당합니다. 웹 검색(web search), 코드 실행(code execution) 등이 대표적이며, 버전이 박힌 타입 문자열로 활성화합니다.

{
  "tools": [
    { "type": "web_search_20250305", "name": "web_search", "max_uses": 5 },
    { "name": "query_crm", "description": "...", "input_schema": { "...": "..." } }
  ]
}

첫 번째는 서버 툴(실행 왕복 불필요), 두 번째는 클라이언트 툴(여러분이 실행)입니다. 한 요청에 둘을 섞어 쓸 수 있습니다.

선택 기준은 단순합니다. Anthropic이 제공하는 서버 툴로 해결되는 기능(웹 검색 등)은 서버 툴을 쓰는 것이 왕복 지연과 구현 부담을 없애 줍니다. 여러분의 시스템·데이터에 닿아야 하는 기능은 클라이언트 툴이어야만 합니다.

클라이언트 툴을 만들기로 했다면, 다음 갈림길은 API 요청에 직접 정의할 것인가, MCP(Model Context Protocol) 서버로 노출할 것인가입니다.

직접 정의는 애플리케이션 코드 안에 스키마와 실행 로직을 함께 두는 방식입니다. 단일 애플리케이션 전용 기능, 빠른 프로토타이핑, 실행 로직과 앱 상태가 강하게 결합된 경우에 적합합니다. 의존성이 없고 디버깅이 단순합니다.

MCP 서버는 툴을 표준 프로토콜 뒤로 분리하는 방식입니다. 장점은 재사용성과 생태계입니다.

• 하나의 MCP 서버를 Claude Code, Claude Desktop, 자체 에이전트 등 여러 호스트에서 재사용
• 팀 간 공유: 데이터 팀이 만든 BigQuery MCP 서버를 전사가 사용
• 이미 존재하는 서드파티 서버(GitHub, Slack, Postgres 등) 활용
• 툴 배포·버전 관리를 애플리케이션 배포와 분리

판단 흐름:
이 기능을 여러 클라이언트/팀이 쓰는가?
  └─ 예 → MCP 서버
  └─ 아니오 → 기존 MCP 서버가 이미 있는가?
        └─ 예 → 그대로 연결 (직접 재구현 금지)
        └─ 아니오 → 앱 하나에서만 쓰면 직접 정의로 시작,
                     공유 필요가 생기면 MCP로 승격

주의: MCP는 만능이 아닙니다. 서버 프로세스 관리, 전송 계층, 인증 등 운영 복잡도가 추가되므로, 단일 앱 전용 툴을 처음부터 MCP로 만드는 것은 과설계입니다.

Claude Code 환경에서는 선택지가 한 층 더 늘어납니다.

내장 툴: Read, Write, Edit, Bash, Grep, Glob 등 파일·셸 작업은 이미 제공됩니다. 파일을 다루는 기능을 MCP로 다시 만들 필요가 없습니다. Bash로 호출 가능한 CLI가 이미 있다면(예: gh, aws) 그것도 사실상 툴입니다.

MCP 서버: .mcp.json 설정으로 외부 시스템(DB, 사내 API, SaaS)을 연결합니다. 셸에서 닿을 수 없는 시스템, 인증이 필요한 시스템에 적합합니다.

스킬(skills)과 슬래시 명령어: 새로운 실행 능력이 아니라 절차 지식을 제공하는 방식입니다. '배포 체크리스트', '리뷰 규칙'처럼 순서와 판단 기준이 핵심이라면 툴이 아니라 스킬로 만들어야 합니다.

기능 요구 → 어떤 형태인가?
├─ 파일/셸로 가능한 작업 → 내장 툴 + CLI (새로 만들지 않는다)
├─ 외부 시스템 접근 → MCP 서버
└─ 절차/지식/체크리스트 → 스킬 (CLAUDE.md, 슬래시 명령어)

시험에서는 "GitHub PR을 조회해야 한다"(→ gh CLI 또는 GitHub MCP 서버), "사내 배포 절차를 따르게 해야 한다"(→ 스킬/CLAUDE.md), "Postgres를 조회해야 한다"(→ MCP 서버) 같은 시나리오로 세 계층의 구분을 묻습니다. 핵심 구분선은 실행 능력이 필요한가, 지식이 필요한가입니다.

방식 선택에는 기능 적합성 외에 세 가지 실무 축이 있습니다.

컨텍스트 비용. 연결된 모든 툴의 스키마는 컨텍스트에 올라갑니다. MCP 서버 하나가 툴 30개를 노출하면 쓰지 않는 27개의 정의도 매 요청 토큰을 차지합니다. 대응책은 필요한 서버만 연결하기, 서버를 기능 단위로 잘게 나누기, 호스트가 지원한다면 툴 필터링·지연 로딩을 쓰는 것입니다.

지연(latency). 서버 툴은 API 안에서 처리되어 왕복이 없습니다. 클라이언트 툴은 모델 응답 → 실행 → 재요청의 왕복이 매번 발생합니다. MCP는 여기에 프로토콜 홉이 하나 더해지지만 대개 무시할 수준이고, 병목은 실제 백엔드 작업 시간입니다.

보안과 권한. 방식마다 신뢰 경계가 다릅니다.

• 직접 정의 툴: 여러분의 코드가 전권을 가짐 — 실행 전 검증은 전적으로 여러분 책임
• MCP 서버: 서버 단위로 자격증명을 격리할 수 있음 — 읽기 전용 DB 계정으로 서버를 돌리는 식의 최소 권한 설계가 쉬움
• 서드파티 MCP 서버: 공급망 신뢰 문제 — 검증되지 않은 서버는 프롬프트 인젝션(prompt injection)이나 데이터 유출 경로가 될 수 있으므로 출처 확인이 필수

정리하면, 기능의 소유자와 소비자, 컨텍스트 예산, 신뢰 경계를 함께 따져 방식을 고르는 것이 이 태스크의 핵심 역량입니다.