MCP는 Tool Calling과 무엇이 다를까?

Spring AI로 챗봇을 넘어 일하는 AI 만들기 8/9

Java·Spring 개발자가 LLM, RAG, Tool Calling, MCP를 공부하며 이해한 것들

이전 글 — AI가 답만 하지 않고 실제 일을 하게 하려면?

학교 축제 AI가 일정 조회, 간식 예약과 방송 신청 도구를 사용하기 시작했습니다. 그런데 학생회 앱, 선생님 앱과 방송부 앱마다 같은 도구 연결 코드를 다시 만들어야 한다면 금방 복잡해집니다.

이 문제를 줄이기 위한 표준이 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)입니다. Tool Calling은 모델이 어떤 도구와 인자를 사용할지 요청하는 방식이고, MCP는 AI 애플리케이션과 외부 기능이 도구·자료·프롬프트를 발견하고 주고받는 연결 규칙입니다. 둘은 경쟁 기술이 아니라 서로 다른 층에서 함께 동작할 수 있습니다.

7편에서 모델의 Tool Call은 실행 명령이 아니라 검증할 요청서라고 설명했습니다. MCP를 붙여도 이 원칙은 바뀌지 않습니다. 표준 연결이 생겨도 인증, 인가, 입력 검증과 사람 승인은 애플리케이션과 업무 시스템의 책임입니다.

이 글의 게시 흐름은 2026년 4월 23일입니다. 개념과 예제는 2026년 8월 16일 Spring AI 2.0.0과 MCP 공식 문서를 기준으로 다시 확인했습니다. 이 Astro 저장소에서 실제 MCP Server나 모델을 실행한 결과는 아닙니다.

Tool Calling만으로도 도구를 쓸 수 있는데 왜 MCP가 필요할까?

한 Spring 애플리케이션에 도구가 두세 개라면 @Tool 메서드를 직접 등록하는 방식이 단순합니다. 모델이 reserveSnack을 요청하면 같은 애플리케이션이 메서드를 찾아 검증하고 실행합니다.

하지만 AI 애플리케이션이 세 개, 도구 제공 시스템이 열 개라면 연결 조합이 빠르게 늘어납니다. 각 앱이 도구 이름, 입력 Schema, 통신 방식과 오류 처리를 따로 구현하면 같은 기능이 여러 곳에서 달라질 수 있습니다.

MCP는 “기능을 어떤 형식으로 소개하고, 목록을 발견하고, 호출하고, 결과를 돌려줄지”를 Client와 Server 사이의 공통 규칙으로 만듭니다. USB-C가 모든 기기를 안전하게 만든다는 뜻은 아니지만 연결 규격을 맞춰주는 것과 비슷합니다.

비유를 실제 기술에 연결하면 다음과 같습니다.

학교 축제 이야기	실제 MCP 구조
축제 운영 앱	MCP Host
도구 안내 데스크와 연결 담당자	MCP Client
방송부·매점이 운영하는 기능 창구	MCP Server
예약·조회 신청서 양식	Tool과 JSON Schema
안내문과 재고 자료	Resource
반복해서 쓰는 방송 요청 양식	Prompt
창구 사이의 접수 규칙	MCP Protocol과 Transport

표준은 연결 코드를 줄일 수 있지만, 잘못된 창구에 권한을 많이 주면 피해도 커질 수 있습니다. 연결하기 쉬워진 만큼 어떤 서버와 기능을 신뢰할지 더 분명하게 정해야 합니다.

Tool Calling과 MCP의 차이를 한 표로 보면

비교	Tool Calling	MCP
핵심 질문	모델이 어떤 기능을 요청할까?	앱과 외부 기능을 어떤 표준으로 연결할까?
중심 데이터	도구 이름, 설명, 입력 인자, 결과	기능 목록, Capability, 요청·응답, 알림
범위	한 모델 요청 안의 도구 선택과 실행 흐름	Host·Client·Server 사이의 연결과 기능 교환
제공 대상	주로 Tool	Tools, Resources, Prompts 등
함께 사용	MCP Tool도 모델의 Tool Calling 대상으로 사용 가능	발견한 Tool을 Spring AI ToolCallback으로 연결 가능

MCP가 Tool Calling을 없애는 것이 아닙니다. MCP Server가 제공한 Tool을 Spring AI가 ToolCallback으로 바꾸면 모델은 여전히 Tool Calling으로 그 도구를 선택합니다.

도구가 많아지면 연결은 어떻게 달라질까?

Tool Calling은 모델이 도구를 선택하는 흐름이고, MCP는 애플리케이션과 외부 기능 사이의 연결 방식을 표준화합니다.

↔직접 Tool 연결MMCP로 연결

직접 Tool 연결

한 애플리케이션 안에서 Java 도구를 직접 등록

11사용자 요청축제 일정과 간식 재고를 알려줘

2AI모델의 Tool CallcalendarTool·stockTool 선택

3APPSpring 애플리케이션@Tool과 ToolCallback 등록

4API업무 API 실행권한과 입력을 검사한 뒤 호출

5A최종 답변도구 결과를 모델에 다시 전달

✓앱마다 연결 코드를 관리

MCP로 연결

여러 애플리케이션이 같은 서버의 기능을 발견하고 사용

11사용자 요청축제 일정과 간식 재고를 알려줘

2AI모델의 Tool Call발견된 MCP Tool 중 하나를 선택

3HOSTSpring AI HostMCP Client와 모델을 관리

4MCP표준 프로토콜기능 발견·호출·결과 교환

5SVRMCP ServerTools·Resources·Prompts 제공

6A최종 답변결과를 모델이 사용자 문장으로 구성

✓표준 연결 위에서 Tool Calling 실행

Tool Calling모델이 어떤 도구와 인자를 요청할지 선택

+

MCP클라이언트와 서버가 기능을 발견하고 교환하는 표준

현재 단계: 사용자 요청

다시 보기

그림의 MCP 구간은 모델 대신 API를 실행하는 지름길이 아닙니다. 모델의 요청이 Spring AI Host, MCP Client와 MCP Server를 거쳐 실제 업무 기능에 도달하는 연결 경로입니다.

Host, Client와 Server는 무엇을 할까?

MCP는 Host·Client·Server 구조를 사용합니다.

Host는 전체 AI 애플리케이션이다

Host는 모델, 사용자 화면, 여러 MCP Client와 보안 정책을 관리하는 애플리케이션입니다. 이 글에서는 Spring Boot 챗봇이 Host에 해당합니다.

어떤 Server에 연결할지, 사용자에게 어떤 기능을 보여줄지, 결과를 모델 Context에 넣을지 결정합니다. 사용자의 동의와 권한 판단도 Host가 놓치면 안 되는 책임입니다.

Client는 Server와 한 연결을 관리한다

MCP Client는 Server와 연결을 열고 Protocol 버전과 Capability를 협상합니다. 도구 목록을 발견하고 호출 요청을 보내며 결과와 알림을 받습니다.

공식 구조에서는 Host가 여러 Client를 가질 수 있고, 각 Client는 특정 Server와 연결됩니다. “MCP Client 하나가 세상의 모든 Server를 자동으로 신뢰한다”는 뜻이 아닙니다.

Server는 기능을 표준 형태로 노출한다

MCP Server는 특정 영역의 Tool, Resource와 Prompt를 제공합니다. 매점 Server는 재고 조회와 예약 Tool을, 문서 Server는 축제 안내 Resource를 제공할 수 있습니다.

Server는 모델 자체일 필요가 없습니다. 파일 시스템, 데이터베이스나 기존 API 앞에 표준 창구를 두는 프로그램에 가깝습니다.

MCP Server는 Tool만 제공할까?

MCP의 대표 Server 기능은 세 가지입니다.

Tools

모델이 선택해 실행을 요청할 수 있는 기능입니다. 재고 조회, 일정 검색과 예약 생성 같은 동작입니다. 모델이 선택할 수 있다는 뜻이지 권한 검증이 끝났다는 뜻은 아닙니다.

Resources

애플리케이션이 Context로 가져올 수 있는 자료입니다. 파일 내용, 문서나 데이터베이스 조회 결과가 될 수 있습니다. Resource를 읽을 권한과 모델에 전달할 범위는 별도로 통제해야 합니다.

Prompts

반복해서 사용할 Prompt Template이나 작업 흐름을 Server가 제공할 수 있습니다. Prompt가 Server에 있다는 이유만으로 안전하거나 정확한 것은 아닙니다.

Tool Calling은 이 가운데 Tool 선택에 초점을 둡니다. MCP는 Tool뿐 아니라 자료와 Prompt까지 표준 방식으로 발견하고 교환하는 더 넓은 연결 규칙입니다.

STDIO와 Streamable HTTP는 무엇이 다를까?

Transport는 MCP 메시지가 실제로 이동하는 통로입니다.

STDIO(Standard Input/Output, 표준 입출력)는 Host가 로컬 Server 프로세스를 실행하고 표준 입력과 출력으로 통신하는 방식입니다. 개발 도구나 한 컴퓨터에서 실행되는 Server에 잘 맞을 수 있습니다.

Streamable HTTP는 네트워크의 독립 Server와 HTTP로 통신합니다. 여러 Client가 원격 서비스에 연결할 때 사용할 수 있지만 TLS, 인증, Timeout, 네트워크 장애와 배포를 관리해야 합니다.

Spring AI 2.0.0 Server 문서는 기존 SSE 방식을 새 설계에서 권장하지 않고 Streamable HTTP를 사용하도록 안내합니다. 오래된 예제를 그대로 복사하기보다 사용하는 Spring AI 안정 버전의 Starter와 설정을 확인해야 합니다.

Spring AI 2.0에서 MCP Client를 준비한다

Spring AI 2.0.0의 기본 MCP Client Starter는 다음 의존성을 사용합니다.

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-mcp-client</artifactId>
</dependency>

원격 Streamable HTTP Server를 연결하는 설정은 다음처럼 구성할 수 있습니다.

spring:
  ai:
    mcp:
      client:
        request-timeout: 30s
        type: SYNC
        streamable-http:
          connections:
            festival-tools:
              url: http://localhost:8083
              endpoint: /mcp

이 주소와 이름은 학습용 가상 예시입니다. 실제 서비스에서는 HTTPS, 인증, 네트워크 접근 제어와 Server 신뢰 절차가 필요합니다.

Starter는 연결된 MCP Server의 Tool을 Spring AI 도구 체계에 연결할 SyncMcpToolCallbackProvider를 제공합니다. 발견한 Tool은 요청할 때 ChatClient.tools()에 전달할 수 있습니다.

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.ai.mcp.SyncMcpToolCallbackProvider;

final class FestivalAssistant {

    private final ChatClient chatClient;
    private final SyncMcpToolCallbackProvider toolCallbackProvider;

    FestivalAssistant(
        ChatClient.Builder chatClientBuilder,
        SyncMcpToolCallbackProvider toolCallbackProvider
    ) {
        this.chatClient = chatClientBuilder.build();
        this.toolCallbackProvider = toolCallbackProvider;
    }

    String ask(String question) {
        return chatClient.prompt()
            .user(question)
            .tools(toolCallbackProvider)
            .call()
            .content();
    }
}

tools()는 ToolCallbackProvider를 받을 수 있습니다. Spring AI의 ToolCallingAdvisor가 모델의 Tool Call과 실행 결과를 잇습니다. MCP는 Server의 Tool을 가져오는 연결 층이고, Tool Calling은 모델이 그 Tool을 사용할지 선택하는 실행 흐름입니다.

이 코드는 Spring AI 2.0.0 공식 문서를 바탕으로 단순화한 학습 예제입니다. 현재 저장소에서 MCP Server, 모델과 축제 시스템을 실행하거나 컴파일한 결과는 아닙니다.

도구를 발견했다고 모두 모델에 보여줘야 할까?

아닙니다. 연결된 모든 Server의 모든 Tool을 모든 요청에 노출하면 선택 오류와 공격 범위가 커질 수 있습니다.

Spring AI MCP Client Starter는 발견한 Tool을 거르는 McpToolFilter 확장 지점을 제공합니다. 여러 Server에 같은 이름의 Tool이 있을 때 이름 충돌을 줄이는 Prefix 처리도 지원합니다.

하지만 Filter 이름만 붙였다고 최소 권한이 자동으로 완성되지는 않습니다. 인증된 사용자, Tenant, 요청 목적과 업무 위험에 맞춰 서버 측에서 다시 검사해야 합니다.

예를 들어 학생에게는 readFestivalSchedule만 보여주고, 예약 담당자에게만 reserveSnack을 노출할 수 있습니다. 삭제나 결제 Tool은 명시적인 승인 흐름이 있는 요청에서만 제한적으로 제공해야 합니다.

MCP를 사용하면 보안도 표준으로 해결될까?

MCP에는 HTTP 기반 Authorization 규격이 있지만, 인증과 권한 정책이 애플리케이션에서 저절로 생기는 것은 아닙니다. 구현과 배포 방식에 맞게 보안 체계를 구성해야 합니다.

특히 다음을 확인해야 합니다.

• 연결하려는 MCP Server를 누가 운영하고 어떤 코드를 실행하는가?
• Server가 요청하는 Tool과 Resource 범위가 필요한 수준인가?
• 사용자별 권한과 조직별 Tenant 경계가 지켜지는가?
• Access Token이 올바른 대상 Server용인지 검증하는가?
• 받은 Token을 다른 시스템에 그대로 전달하지 않는가?
• Tool 인자, Resource와 결과가 로그에 노출되지 않는가?
• 로컬 STDIO Server가 예상하지 않은 명령과 파일에 접근하지 않는가?

공식 MCP 보안 가이드는 새 로컬 Server를 실행하기 전에 실제 명령과 권한을 사용자에게 보여주고 동의를 받도록 강조합니다. 편리한 “한 번에 연결” 버튼이 보안 확인을 숨기면 안 됩니다.

실패 지점은 연결 수만큼 늘어난다

직접 Tool 연결보다 MCP 구조에는 확인할 경계가 더 많습니다.

사용자 요청
→ 모델의 Tool Call
→ Spring AI ToolCallback
→ MCP Client
→ Transport
→ MCP Server
→ 실제 업무 API
→ 결과 반환

Server가 꺼졌거나 Protocol 버전 협상이 실패할 수 있습니다. Tool 목록이 바뀌거나 이름이 충돌할 수도 있습니다. 네트워크 Timeout 뒤 실제 작업이 실행됐는지 모를 수 있습니다.

따라서 Readiness, Timeout, 재연결, Tool 목록 변경, 요청 취소, 멱등성과 감사 로그를 분리해 관찰해야 합니다. MCP가 실패했다고 모델에게 무조건 다른 위험한 Tool을 선택하게 해서는 안 됩니다.

언제 직접 연결하고 언제 MCP를 사용할까?

상황	먼저 검토할 방식	이유
한 앱 안의 도구 두세 개	직접 @Tool	구조가 단순하고 디버깅 경로가 짧음
여러 앱이 같은 기능 사용	MCP	기능 정의와 연결 규칙을 공유하기 쉬움
외부 팀이 기능 제공	MCP	Client·Server 책임과 Transport 경계를 분리 가능
고위험 상태 변경	둘 다 추가 통제 필요	연결 방식이 인증·인가·승인을 대신하지 않음

MCP가 항상 더 좋은 선택은 아닙니다. 작은 애플리케이션에 Server, Client와 Transport를 추가하면 운영 지점만 늘어날 수 있습니다. 재사용할 기능 수, 팀 경계, 배포 구조와 보안 책임을 보고 결정해야 합니다.

한 단계 더 깊게: Capability 협상

MCP Client와 Server는 연결을 시작할 때 Protocol 버전과 지원 Capability를 교환합니다. Server는 Tools, Resources와 Prompts 같은 기능을 제공한다고 알리고 Client도 지원하는 기능을 알립니다.

이 과정은 서로 지원하지 않는 기능을 무작정 호출하지 않게 돕습니다. 하지만 Capability를 제공한다고 그 기능을 모든 사용자에게 허용한다는 뜻은 아닙니다. Protocol 지원과 업무 권한은 다른 층입니다.

Spring AI Client Starter는 여러 연결의 생명주기와 ToolCallback 변환을 도와줍니다. Server 쪽 Starter는 STDIO, WebMVC·WebFlux의 Streamable HTTP와 Stateless 방식으로 Tool·Resource·Prompt를 노출할 수 있습니다.

자주 생기는 오해

MCP는 Tool Calling을 대체하나요?

아닙니다. MCP Server가 제공한 Tool도 모델이 선택할 때는 Tool Calling 흐름을 사용합니다. MCP는 도구를 발견하고 연결하는 표준 층입니다.

MCP Server가 LLM인가요?

아닙니다. 외부 기능과 Context를 제공하는 프로그램입니다. 모델은 Host 애플리케이션이나 별도 제공자에 있을 수 있습니다.

MCP를 쓰면 모든 AI 앱에서 똑같이 동작하나요?

연결 규격은 같아질 수 있지만 Host의 모델, 권한 정책, 지원 Capability와 사용자 경험은 다를 수 있습니다.

MCP에 연결하면 인증도 끝나나요?

아닙니다. Server 신뢰, 사용자 인증, 인가, Token 대상 검증과 Tool별 업무 규칙을 별도로 설계해야 합니다.

도구가 많을수록 Agent가 똑똑해지나요?

항상 그렇지 않습니다. 비슷한 도구가 많으면 선택 오류와 공격 표면이 커질 수 있습니다. 요청에 필요한 최소 기능만 노출하고 결과를 평가해야 합니다.

세 줄 요약

1. Tool Calling은 모델의 도구 선택과 인자 요청을 다루고 MCP는 AI 애플리케이션과 외부 기능의 연결을 표준화합니다.
2. Spring AI는 MCP Server의 Tool을 ToolCallback으로 연결해 기존 ChatClient의 Tool Calling 흐름에서 사용할 수 있습니다.
3. MCP를 사용해도 Server 신뢰, 인증·인가, 입력 검증, 최소 권한과 사람 승인은 별도로 설계해야 합니다.

다음 편 예고

다음 편 — 그럴듯하게 답하면 좋은 AI 서비스일까?

이제 AI는 문서를 찾고, 도구를 실행하고, 여러 외부 시스템과 표준 방식으로 연결할 수 있습니다. 그런데 화면에 “완료했습니다”라고 나타났다는 이유만으로 정말 일을 잘했다고 말할 수 있을까요?

마지막 9편에서는 답변, RAG 검색, Tool 선택, 실제 업무 결과와 안전성을 어떻게 나누어 평가할지 살펴봅니다.

공식 문서

• Spring AI 2.0.0 MCP 개요
• Spring AI MCP Client Boot Starter
• Spring AI MCP Server Boot Starter
• Spring AI Tool Calling
• MCP 공식 소개
• MCP Client·Host·Server 구조
• MCP Server의 Tools·Resources·Prompts
• MCP Authorization
• MCP Security Best Practices