Claude Certified Architect – Foundations (CCA-F) 자격시험 교재

출제 도메인: 도메인 2 (18%) · 작성자: 김재우 (jaewoo@claudcode.to)

① MCP(Model Context Protocol) 입문 완벽 가이드 (CCA-F 세션 6): Tools·Resources·Prompts

지난 장 돌아보기

지난 장에서는 Tool Use(Function Calling)의 기본을 배웠어요. 이번 장에서는 Tool Use를 업계 표준 사양으로 끌어올린 Model Context Protocol(MCP)을 배워요. CCA-F 도메인 2의 핵심이 되는 주제예요.

주제 개요

MCP(Model Context Protocol)는 LLM과 툴/데이터 소스를 잇기 위한 오픈 표준 프로토콜이에요. 비유하자면 MCP는 USB Type-C 같은 공통 규격이에요. 각 회사가 독자 단자(독자 툴 포맷)를 만들던 시대에서, 공통 규격으로 접속할 수 있게 해 주는 통일 사양이에요.

MCP를 쓰면:

• 여러 LLM과 여러 툴이 같은 프로토콜로 대화할 수 있다
• 한 번 만든 MCP 서버는 Claude Desktop / Claude Code / 타사 LLM IDE에서 재사용할 수 있다
• 툴 제공자와 LLM 제공자의 느슨한 결합이 실현된다

습득 포인트

• MCP의 목적·등장 배경·표준화의 의의를 설명할 수 있다
• MCP의 3요소 Tools / Resources / Prompts의 차이와 구분 사용을 말할 수 있다
• 클라이언트 / 서버 / 트랜스포트의 3층 구조를 이해하고 있다
• stdio와 SSE / HTTP 트랜스포트의 차이를 파악하고 있다
• 통지 기능(notifications)의 역할을 이해하고 있다
• MCP의 전형적인 유스케이스(사내 DB 접속, GitHub 조작 등)를 예시할 수 있다
• Claude Code / Claude Desktop에서 MCP 서버를 이용하는 방법을 파악하고 있다

1. MCP의 등장 배경

1.1 MCP 이전의 과제

flowchart TB
    A["상위 에이전트<br/>도구 5개"]

    B["사용자 관리 에이전트<br/>도구 10개"]
    C["주문 관리 에이전트<br/>도구 8개"]
    D["재고 관리 에이전트<br/>도구 7개"]
    E["외부 연동 에이전트<br/>도구 15개"]
    F["분석 에이전트<br/>도구 10개"]

    A --> B
    A --> C
    A --> D
    A --> E
    A --> F

    classDef agent fill:#EEF2FF,stroke:#6C63FF,stroke-width:2px,color:#222;

    class A,B,C,D,E,F agent;

→ N × M의 조합 폭발. 각 LLM과 툴이 서로 전용 접속을 구현해야 했다.

[보완 — 추가된 내용] 캡션(N × M)에 맞게 재구성한 도식입니다(원문에는 없음).

flowchart LR
    L1["LLM A"]
    L2["LLM B"]
    L3["LLM C"]
    T1["도구 1"]
    T2["도구 2"]
    T3["도구 3"]
    L1 --> T1
    L1 --> T2
    L1 --> T3
    L2 --> T1
    L2 --> T2
    L2 --> T3
    L3 --> T1
    L3 --> T2
    L3 --> T3

1.2 MCP 도입 후

flowchart TD
    A["상위 에이전트<br/>도구 5개"]

    B["사용자 관리 에이전트<br/>도구 10개"]
    C["주문 관리 에이전트<br/>도구 8개"]
    D["재고 관리 에이전트<br/>도구 7개"]
    E["외부 연동 에이전트<br/>도구 15개"]
    F["분석 에이전트<br/>도구 10개"]

    A --> B
    A --> C
    A --> D
    A --> E
    A --> F

→ N + M의 조합으로 간략화. 각 LLM과 툴이 MCP 사양에만 준거하면 된다.

[도식 오류] 1.1과 마찬가지로 이 도식도 서브에이전트 계층도가 잘못 삽입됐습니다. 캡션(N + M)에 맞는 그림은 '여러 LLM이 MCP라는 공통 허브에만 접속하고, MCP가 각 툴로 이어 주는' 구조입니다. 아래 [보완]을 참고하세요.

[보완] 캡션(N + M)에 맞게 재구성한 도식입니다(원문에는 없음).

flowchart LR
    L1["LLM A"]
    L2["LLM B"]
    L3["LLM C"]
    M["MCP<br/>표준 프로토콜"]
    T1["도구 1"]
    T2["도구 2"]
    T3["도구 3"]
    L1 --> M
    L2 --> M
    L3 --> M
    M --> T1
    M --> T2
    M --> T3

1.3 MCP의 개방성

• 오픈 사양: https://modelcontextprotocol.io
• 제창은 Anthropic이지만, 타사 LLM 제공자도 대응(OpenAI, Google 등)
• IDE(VS Code, Cursor, Zed 등)에서도 이용 가능

2. MCP의 3요소: Tools / Resources / Prompts

MCP 서버는 3종류의 리소스를 공개할 수 있어요. 이건 시험에 자주 나오는 최중요 개념이에요.

2.1 비유

MCP 서버를 '프로 어시스턴트 사무소'라고 생각하면:

• Tools: 의뢰할 수 있는 작업(전화를 건다·서류를 작성한다·일정을 조정한다)
• Resources: 열람할 수 있는 자료(고객 리스트·과거 의사록·규정집)
• Prompts: 정형 업무의 매뉴얼(클레임 대응 표준 절차·신입용 FAQ)

2.2 Tools vs Resources의 차이

❌ 자주 하는 혼동

bad.py

# '파일 내용을 가져오는 툴'은 Tool이 아니라 Resource로 공개해야 한다
@server.tool()
def read_file(path: str) -> str:
    return Path(path).read_text()

✓ 올바른 구분 사용

good.py

# 읽기 전용은 Resource로 공개
@server.resource("file://{path}")
def file_resource(path: str) -> str:
    return Path(path).read_text()

# 부수 효과가 있는 건 Tool로 공개
@server.tool()
def write_file(path: str, content: str) -> None:
    Path(path).write_text(content)

2.3 Prompts의 활용

Prompts는 재사용 가능한 프롬프트 템플릿을 공개해요.

prompts_example.py

@server.prompt()
def code_review(language: str, code: str) -> str:
    return f"""
당신은 경험 많은 {language} 리뷰어입니다.
다음 코드를 리뷰하고, 개선점을 3가지 짚어 주세요.

<code>
{code}
</code>
"""

사용자는 Claude Desktop / Claude Code에서 /code-review python {코드}처럼 슬래시 커맨드로 호출할 수 있어요.

3. MCP의 3층 아키텍처

3.1 용어 정리

3.2 Transport의 종류

4. 최소 MCP 서버 구현

4.1 Python으로 구현

hello_mcp_server.py

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("hello-server")

@mcp.tool()
def get_weather(city: str) -> str:
    """지정한 도시의 날씨를 반환합니다."""
    # 구현은 생략(실제로는 외부 API를 호출)
    return f"{city}의 날씨는 맑음, 기온 22도입니다."

@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
    """이름에 맞는 인사를 반환합니다."""
    return f"안녕하세요, {name}님!"

@mcp.prompt()
def code_review_prompt(language: str, code: str) -> str:
    """코드 리뷰용 프롬프트 템플릿."""
    return f"다음 {language} 코드를 리뷰해 주세요:\n\n{code}"

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

4.2 Claude Code에 등록

# Claude Code에서 MCP 서버를 추가(-- 이후가 서버 기동 명령)
claude mcp add hello-server --scope project -- python /path/to/hello_mcp_server.py

--scope에는 project(리포지터리에서 공유·.mcp.json에 저장) / user(자신의 모든 프로젝트에서 공유·~/.claude.json에 저장) / local(현재 프로젝트의 자신 전용)을 지정할 수 있어요. -- 이후에 서버의 기동 명령과 인자를 써요.

CLI를 쓰지 않고, 프로젝트 스코프 설정 파일 .mcp.json(리포지터리 루트에 둔다)을 직접 편집해도 등록할 수 있어요:

.mcp.json

{
  "mcpServers": {
    "hello-server": {
      "command": "python",
      "args": ["/path/to/hello_mcp_server.py"]
    }
  }
}

주의: 설정 파일의 최상위 키는 mcpServers예요(이 키가 없으면 로드되지 않아요). API 키 같은 비밀 정보는 값에 직접 쓰지 말고, "env": {"API_KEY": "${MY_API_KEY}"}처럼 ${VAR}로 환경 변수를 참조시켜요. 스코프와 환경 변수 전개의 상세는 MCP 서버 설계 세션에서 다룹니다.

5. 통지 기능(Notifications)

MCP 서버는 클라이언트에 비동기 통지를 보낼 수 있어요.

사용법과 주의점

• 동적으로 툴이 늘고 주는 케이스(플러그인 같은 구조)에서 중요
• 장시간 처리의 진척을 사용자에게 보여 주기 위해서도 쓰인다
• 모든 클라이언트가 통지에 대응하는 건 아니다(사양상 임의)

6. MCP의 전형적인 유스케이스

공식 MCP 서버 목록은 https://modelcontextprotocol.io 에서 확인할 수 있어요.

7. MCP vs 직접 Tool Use의 비교

구분 사용의 기준

• 단일 앱 안의 단순한 함수 호출 → 직접 Tool Use
• 여러 LLM·IDE에서 재사용하고 싶다 → MCP
• Claude Code / Desktop과 연동한다 → 반드시 MCP

자주 하는 오해와 개념 정리

❌ 자주 하는 오해: 'MCP는 Anthropic 전용이다'

• 오해: Claude 전용의 독자 프로토콜이라고 여기기 쉬움
• 실제: 오픈 사양. OpenAI, Google 등 타사도 대응 진행 중
• 확인 방법: https://modelcontextprotocol.io 에서 공식 사양을 확인

❌ 자주 하는 오해: 'Tools와 Resources는 같은 것이다'

• 오해: 둘 다 데이터를 반환하니 같다
• 실제: 부수 효과 / 읽기로 명확히 분리. 의도해서 구분 사용한다
• 확인 방법: '호출하면 뭔가가 바뀌는가'를 기준으로 판정

❌ 자주 하는 오해: 'MCP 서버는 상시 가동한다'

• 오해: 상주 서비스로 기동해 둬야 한다
• 실제: stdio 트랜스포트에서는 클라이언트가 필요에 따라 기동·정지하는 자식 프로세스
• 확인 방법: Claude Code 기동 시 서버가 프로세스로 올라온다

자주 나는 에러와 대처법

• 에러 예시: MCP 서버가 Claude Code에서 인식되지 않음
  • 원인: .mcp.json의 경로 지정 실수, 또는 Python 환경 불일치
  • 대처법: claude mcp list로 상태 확인, claude mcp logs <name>으로 로그 확인
• 에러 예시: 툴이 Claude에서 호출되지 않음
  • 원인: description이 불충분하거나, LLM 쪽의 판단
  • 대처법: description을 개선, tool_choice 지정을 검토

정리와 다음 한 걸음

• MCP는 LLM과 툴/데이터를 잇는 오픈 표준 프로토콜
• 3요소: Tools(부수 효과) / Resources(읽기) / Prompts(재사용 템플릿)
• 3층 아키텍처: Host → Client → Server(Transport: stdio / SSE)
• 통지 기능으로 동적 갱신 / 진척 보고가 가능
• Claude Code / Desktop과 연동한다면 MCP 하나뿐

다음 세션에서는 MCP 서버를 본격적으로 설계·구현하기 위한 베스트 프랙티스를 배웁니다.

② CCA-F 세션 6 연습문제 9선: MCP 목적·Tools/Resources/Prompts·트랜스포트 완전 대비

습득 포인트와 문제 매칭

문제 1: MCP의 목적

• 카테고리: 기초
• 난이도: ★☆☆☆☆
• 예상 소요 시간: 5분

MCP의 최대 가치로 가장 적절한 것은 무엇인가요?

• (A) Anthropic 독자의 경쟁 우위를 만든다
• (B) 여러 LLM과 여러 툴의 접속을 N × M에서 N + M으로 간략화한다
• (C) 파이썬으로만 구현할 수 있다
• (D) Claude 전용의 통신 암호화

문제 2: 3요소의 구분 사용 (Tools)

• 카테고리: 기초
• 난이도: ★★☆☆☆
• 예상 소요 시간: 5분

다음 중 MCP의 Tools로 공개해야 하는 것은 무엇인가요?

• (A) 정적인 문서의 본문 취득
• (B) 시스템의 버전 정보
• (C) 수학 상수 π의 값
• (D) 파일에 새 텍스트를 써넣는다

문제 3: 3요소의 구분 사용 (Resources)

• 카테고리: 기초
• 난이도: ★★☆☆☆
• 예상 소요 시간: 5분

다음 중 MCP의 Resources로 공개해야 하는 것은 무엇인가요?

• (A) 메일을 보낸다
• (B) Slack에 메시지를 올린다
• (C) 사내 Wiki의 기사 내용(읽기)
• (D) 은행 이체

문제 4: 3요소의 구분 사용 (Prompts)

• 카테고리: 응용
• 난이도: ★★★☆☆
• 예상 소요 시간: 5분

다음 중 MCP의 Prompts의 역할을 가장 적절하게 설명한 것은 무엇인가요?

• (A) LLM이 호출해 부수 효과를 일으키는 함수
• (B) LLM이 읽어 들이는 참조 데이터
• (C) 재사용 가능한 프롬프트 템플릿
• (D) LLM의 시스템 프롬프트를 직접 편집하는 구조

문제 5: MCP의 3층 아키텍처

• 카테고리: 응용
• 난이도: ★★☆☆☆
• 예상 소요 시간: 5분

MCP의 전형적인 아키텍처로 올바른 것은 무엇인가요?

• (A) Host → Server → Tool
• (B) Client → Database → Server
• (C) Host → Tool
• (D) Host → Client → Server → Tool/Resource/Prompt

문제 6: 트랜스포트의 구분 사용

• 카테고리: 응용
• 난이도: ★★★☆☆
• 예상 소요 시간: 10분

로컬 PC에 둔 작은 MCP 서버를 Claude Code에서 이용하는 경우, 가장 일반적인 트랜스포트는 무엇인가요?

• (A) stdio
• (B) WebSocket
• (C) SMTP
• (D) gRPC

문제 7: 통지 기능(notifications)

• 카테고리: 응용
• 난이도: ★★★☆☆
• 예상 소요 시간: 10분

MCP 서버에서 동적으로 추가된 툴을 클라이언트에 알리기 위한 구조로 올바른 것은 무엇인가요?

• (A) 클라이언트를 재기동해야 한다
• (B) notifications/tools/list_changed 통지를 보낸다
• (C) Anthropic API를 호출해 메타데이터 갱신을 요구
• (D) 서버 로그에 메시지를 기록한다

문제 8: MCP vs 직접 Tool Use

• 카테고리: 응용
• 난이도: ★★★☆☆
• 예상 소요 시간: 10분

다음 시나리오에서 MCP를 골라야 하는 가장 큰 이유는 무엇인가요?

시나리오: 사내 Wiki와 GitHub에 Claude Code / Cursor / VS Code Copilot에서 같은 방법으로 접속하고 싶다.

• (A) 여러 LLM / IDE에서 같은 툴 정의를 재사용할 수 있다
• (B) MCP를 쓰면 추론 정확도가 향상된다
• (C) MCP는 통신이 빠르다
• (D) MCP는 라이선스 비용이 들지 않는다(사실이지만 본질은 아니다)

문제 9 (고급): Resources와 Tools의 경계

• 카테고리: 고급
• 난이도: ★★★★☆
• 예상 소요 시간: 15분

'사용자가 지정한 URL의 웹 페이지 내용을 가져오는' 기능을 MCP로 공개하는 경우, Tools와 Resources 중 어느 쪽으로 분류해야 하는지, 그 이유와 함께 100자 정도로 서술하세요.

정답은 이 장 후반의 정답·해설편에서 확인하세요.

③ MCP 연습문제 해설 총정리: 3요소(Tools·Resources·Prompts)와 3계층 아키텍처 (세션 6)

해답 일람

문제 1: MCP의 목적 — 정답 (B)

해설

MCP의 핵심 가치는 간단해요. N × M으로 폭발하던 연결 조합을 N + M으로 줄여주는 거죠. LLM과 도구가 각자 MCP 사양에만 맞추면 되니까, 조합의 가짓수가 확 줄어듭니다.

설계·운영 포인트

• 설계 관점: USB Type-C처럼 업계 표준 역할을 합니다.
• 운영 시 주의점: 표준화의 가장 큰 이점은 재사용성이에요. 특정 벤더에 묶이는(lock-in) 상황을 피하는 효과도 덤으로 따라옵니다.

문제 2: 3요소 구분 (Tools) — 정답 (D)

해설

파일 쓰기는 부작용(side effect)을 동반하니까 Tools로 공개합니다. 읽기나 정적 데이터는 Resources가 적절해요.

설계·운영 포인트

• 설계 관점: "호출했을 때 외부 상태가 바뀌는가"를 기준으로 Tools와 Resources를 구분합니다.

문제 3: 3요소 구분 (Resources) — 정답 (C)

해설

사내 위키 글을 읽는 건 부작용이 없으니까 Resources로 공개해요.

설계·운영 포인트

• 운영 시 주의점: Resources는 URI 스킴으로 공개합니다. (예: wiki://articles/123)

문제 4: 3요소 구분 (Prompts) — 정답 (C)

해설

Prompts는 재사용 가능한 프롬프트 템플릿을 공개하는 구조예요. 슬래시 커맨드나 UI 버튼으로 사용자에게 보여주는 경우가 많습니다.

설계·운영 포인트

• 설계 관점: 프롬프트를 "도구"처럼 공개하면 사용자가 직접 호출할 수 있습니다.
• 운영 시 주의점: 자주 쓰는 정형 프롬프트를 Prompts로 공개하면 사용자가 입력하는 수고가 줄어들어요.

[보완] MCP 3요소는 "누가 호출을 제어하는가"로도 구분해두면 이해가 쉬워요. Tools는 모델이 제어(model-controlled), Resources는 앱(호스트)이 제어(app-controlled), Prompts는 사용자가 제어(user-controlled)합니다. 위 세 문제(2~4)의 판별 기준과 함께 기억해두면 헷갈릴 일이 줄어듭니다. (출처: Anthropic MCP 공식 코스 자료)

문제 5: MCP의 3계층 아키텍처 — 정답 (D)

해설

MCP의 3계층은 Host → Client → Server → Tool/Resource/Prompt로 이어져요. 호스트는 사용자가 직접 쓰는 앱(Claude Code 등)이고, 클라이언트는 MCP 프로토콜로 서버와 통신하는 부분, 서버는 실제 도구 구현을 공개하는 쪽입니다.

문제 6: 트랜스포트 구분 — 정답 (A)

해설

로컬 MCP 서버라면 stdio 트랜스포트가 가장 흔해요. 표준 입출력을 거쳐 프로세스끼리 통신하는 방식이죠. 원격 서비스로 올릴 때는 SSE / Streamable HTTP를 씁니다.

[최신 정보] MCP 사양 2025-03-26 버전부터 원격 트랜스포트의 표준은 Streamable HTTP로 정리됐고, 기존 HTTP+SSE 방식은 하위 호환용으로만 남았습니다(deprecated). 새로 원격 서버를 만든다면 SSE 대신 Streamable HTTP를 쓰는 것이 권장돼요. Atlassian Rovo 등 일부 서버는 2026년 6월 30일부로 HTTP+SSE 지원을 종료합니다. (출처: MCP 공식 사양·Atlassian 공지)

설계·운영 포인트

• 설계 관점: stdio는 구현이 가장 단순합니다. 서버 쪽이 자식 프로세스로 실행돼요.
• 운영 시 주의점: 원격으로 돌릴 때는 인증·인가를 별도로 설계해야 합니다.

문제 7: 알림 기능 (notifications) — 정답 (B)

해설

notifications/tools/list_changed를 보내면 클라이언트가 새 도구 목록을 다시 가져옵니다. 재시작은 필요 없어요.

설계·운영 포인트

• 설계 관점: MCP는 동적 업데이트를 전제로 설계돼 있습니다.
• 운영 시 주의점: 클라이언트가 알림을 반드시 처리한다는 보장은 없으니, 중요한 변경이라면 재접속을 유도하는 설계도 함께 고려하세요.

문제 8: MCP vs 직접 Tool Use — 정답 (A)

해설

이 시나리오의 가장 큰 이점은, 여러 LLM / IDE에서 똑같은 도구 정의를 그대로 재사용할 수 있다는 거예요.

설계·운영 포인트

• 설계 관점: "한 번 만들어 N번 재사용"이 MCP의 최대 가치입니다.
• 운영 시 주의점: 팀 내부 OSS로 MCP 서버를 공개하면 조직 전체의 재사용 효과가 큽니다.

문제 9 (심화): Resources와 Tools의 경계 — 해답 예시

모범 답안

Resources로 공개해야 한다. 웹 페이지 내용을 가져오는 작업은 부작용이 없는 읽기 동작이고, URI 스킴(예: web://example.com/path)으로 표현할 수 있기 때문이다. 다만 인증이 필요하거나 외부 API 제한(rate limit)에 도달할 수 있는 경우에는, Tools로 두어 명시적으로 호출하게 만드는 선택지도 있다.

채점 포인트

설계·운영 포인트

• 설계 관점: 기능의 본질은 "읽기"지만, API rate limit 같은 외부 부작용이 있을 때는 "호출 타이밍을 Claude가 제어할 수 있다"는 점에서 Tools가 유리해요.
• 운영 시 주의점: 양쪽으로 공개하는 하이브리드 MCP 서버 설계도 가능합니다. (중요한 리소스는 Tools와 Resources 양쪽으로 공개)

이번 세션 정리

• MCP는 LLM과 도구/데이터를 잇는 오픈 표준이에요.
• 3요소: Tools(부작용) / Resources(읽기) / Prompts(템플릿)
• 3계층 구조: Host → Client → Server
• 로컬은 stdio, 원격은 SSE / HTTP 트랜스포트
• 알림 기능으로 동적 업데이트와 진행 상황 보고를 할 수 있습니다.

다음 세션(제9장)에서는 MCP 서버를 실제 프로덕션 운영 수준으로 설계하기 위한 베스트 프랙티스를 다룹니다.

©2024-2026 ClaudeCode.to, Hand-crafted & made with Jaewoo Kim.

• 이메일문의: jaewoo@claudecode.to
• AI 에이전트 만드는 사람
• 기업 AI 강의 · 에이전트 개발 · 기술자문
• "AI한테 일 시키는 법, 제대로 알려드립니다"