MCP가 Spring 개발자에게 중요한 이유
title: "MCP가 Spring 개발자에게 중요한 이유" slug: "spring-ai-2-mcp" status: "draft" series: "Spring AI 2.0 읽는 순서" order: 7 description: "Spring AI 2.0의 MCP 문서를 바탕으로, Model Context Protocol을 유행어가 아니라 클라이언트/서버 표준화 계층으로 설명하는 글." tags: ["Spring AI", "MCP", "Spring Boot", "Tool Calling", "Java"] source_docs:
- "downloads/spring-ai-reference-2.0-ko/api/mcp/mcp-overview.html"
- "downloads/spring-ai-reference-2.0-ko/guides/getting-started-mcp.html"
- "downloads/spring-ai-reference-2.0-ko/api/mcp/mcp-client-boot-starter-docs.html"
- "downloads/spring-ai-reference-2.0-ko/api/mcp/mcp-server-boot-starter-docs.html"
MCP(Model Context Protocol)는 요즘 AI 생태계에서 자주 들리는 단어다. 그래서 오히려 더 헷갈리기도 한다.
유행하는 표준처럼 보이지만, 실제로 개발자가 궁금한 건 더 현실적이다.
- 내 Spring 애플리케이션이 외부 MCP 서버를 붙일 수 있는가
- 반대로 내 서비스를 MCP 서버로 노출할 수 있는가
- Tool Calling과는 무엇이 다르고 어떻게 연결되는가
- 운영 관점에서 어떤 전송 방식과 보안 포인트를 봐야 하는가
Spring AI 2.0 문서를 기준으로 보면, MCP는 단순한 유행어가 아니라 모델-도구-컨텍스트 연결을 표준화하는 계층으로 이해하는 편이 가장 정확하다.
MCP를 왜 굳이 알아야 하나
Tool Calling만으로도 모델과 외부 기능을 연결할 수 있다. 그럼에도 MCP가 중요한 이유는, 도구와 리소스 접근 방식을 애플리케이션마다 제각각 정의하지 않게 도와주기 때문이다.
쉽게 말하면 이런 문제를 줄여 준다.
- 공급자별/프레임워크별로 도구 연결 방식이 제각각임
- 어떤 시스템은 stdio, 어떤 시스템은 HTTP, 어떤 시스템은 독자 프로토콜을 씀
- 같은 기능을 연결해도 메타데이터와 계약 형식이 달라 재사용이 어려움
MCP는 이 지점에서 도구 접근의 공통 언어 역할을 하려는 시도다.
Spring AI에서 보이는 MCP의 그림
mcp-overview.html 문서는 MCP Java SDK 구조를 크게 세 층으로 설명한다.
- Client/Server Layer
- Session Layer
- Transport Layer
이 구조를 Spring 개발자 관점에서 풀면 이렇게 읽을 수 있다.
Client/Server Layer
애플리케이션이 MCP 서버를 소비하는 클라이언트가 될 수도 있고, 반대로 기능을 제공하는 서버가 될 수도 있다.
즉 Spring AI는 소비자 역할과 제공자 역할을 둘 다 지원한다.
Session Layer
한 번 연결하고 끝나는 호출이 아니라, 세션 상태와 프로토콜 상호작용을 관리하는 층이다.
MCP를 단순 REST 호출보다 조금 더 표준화된 상호작용 계층으로 봐야 하는 이유가 여기 있다.
Transport Layer
stdio, SSE, streamable HTTP 같은 실제 전송 방식을 담당한다.
즉 MCP는 “무조건 HTTP” 같은 단일 방식이 아니라, 운영 환경에 따라 전송 선택지를 가진다.
Spring 개발자에게 특히 중요한 두 가지 역할
Spring AI 문서를 따라가면 MCP는 크게 두 방향으로 실무에 들어온다.
1) MCP Client로서 외부 도구 생태계를 소비한다
내 애플리케이션이 외부 MCP 서버에 붙어서 도구를 받아 쓰는 경우다.
이건 이런 상황에서 유용하다.
- 이미 표준 MCP 서버로 제공되는 도구를 재사용하고 싶을 때
- 내부에서 모든 ToolCallback을 직접 구현하지 않고 싶을 때
- 여러 도구 공급원을 한 표준 인터페이스로 붙이고 싶을 때
즉 “Spring 앱이 외부 에이전트 도구 생태계와 연결되는 입구”가 된다.
2) MCP Server로서 내 기능을 표준 방식으로 노출한다
반대로 내 Spring 애플리케이션이 가진 기능을 MCP 서버로 내보낼 수도 있다.
예를 들어,
- 사내 문서 검색
- 주문 조회
- 운영 데이터 조회
- 특정 워크플로우 실행
같은 기능을 MCP 도구로 공개하면, 나중에 다양한 MCP 클라이언트가 재사용할 수 있다.
이건 장기적으로 꽤 큰 차이를 만든다. 한 애플리케이션 안의 사내용 유틸이 아니라, 표준화된 AI 연동 표면으로 기능을 승격시키는 셈이기 때문이다.
Boot Starter가 실무에서 주는 장점
Spring AI 문서가 MCP Client / Server Boot Starter를 따로 제공하는 이유는 명확하다. 표준 프로토콜이라고 해도, 실전에서는 결국 설정과 자동 구성이 개발 생산성을 좌우하기 때문이다.
클라이언트 쪽에서는 이런 점이 특히 눈에 띈다.
- sync / async 클라이언트 유형
- stdio / SSE / streamable HTTP 전송 지원
- tool filtering
- 도구 이름 prefix 생성
- 자동 ToolCallback 구성 제어
서버 쪽에서는 이런 포인트가 중요하다.
- STDIO, WebMVC 등 서버 스타터 선택
- 서버 capability 설정
- 어노테이션 기반 도구 정의
- 프로토콜/전송 설정 자동화
즉 Spring AI는 MCP를 단순 이론으로 소개하는 데서 끝나지 않고, Spring Boot 애플리케이션에 올리기 쉬운 형태로 다듬어 둔다.
MCP와 Tool Calling의 관계는 어떻게 보면 좋은가
이 둘을 경쟁 개념으로 보면 헷갈리기 쉽다. 실제로는 보완 관계에 가깝다.
- Tool Calling은 모델이 어떤 도구를 써야 할지 결정하는 흐름이다.
- MCP는 그 도구들이 외부와 어떻게 표준적으로 연결될지를 정하는 계층이다.
즉 Tool Calling이 상위의 사용 패턴이라면, MCP는 그 아래에서 도구 제공/소비 인터페이스를 표준화하는 기반에 가깝다.
그래서 Spring AI에서는 두 주제를 같이 보는 편이 좋다.
전송 방식은 단순 구현 디테일이 아니다
문서에서 stdio, SSE, streamable HTTP를 세세히 다루는 이유도 실무적이다.
stdio
로컬 프로세스 연동이나 개발 초기 실험에 잘 맞는다.
SSE / HTTP 계열
네트워크 환경, 서버 배포, 원격 연결이 필요한 운영 시나리오에 더 잘 맞는다.
즉 MCP 설계에서는 “도구가 있느냐”만이 아니라, 어디서 어떻게 연결되고 배포될 것인가도 같이 판단해야 한다.
보안과 필터링을 먼저 생각해야 한다
MCP가 표준이라고 해서 자동으로 안전해지는 건 아니다. 오히려 표준화된 만큼, 외부 연결 면이 더 분명해진다.
그래서 실무에서는 다음을 먼저 봐야 한다.
- 어떤 도구를 공개할 것인가
- 어떤 전송 경로를 허용할 것인가
- 인증과 권한 부여를 어디에 둘 것인가
- 멀티테넌트/환경 분리를 어떻게 할 것인가
- 로깅과 감사 추적을 남길 것인가
즉 MCP는 편의 기능이기도 하지만, 동시에 운영 인터페이스를 열어 주는 일이기도 하다.
처음 접근할 때 추천하는 순서
Spring 개발자가 MCP를 처음 볼 때는 아래 순서가 가장 무난하다.
1단계
MCP 개요와 아키텍처를 읽는다.
먼저 “클라이언트도 될 수 있고 서버도 될 수 있다”는 큰 그림을 잡는 게 중요하다.
2단계
간단한 MCP Client 예제를 붙여 본다.
기존 앱에 외부 도구를 가져오는 쪽이 보통 진입 장벽이 더 낮다.
3단계
그다음 내 기능을 MCP Server로 노출할지 판단한다.
이 단계부터는 API 설계, 인증, 운영 경계가 더 중요해진다.
한 문장으로 정리하면
MCP는 Spring 개발자에게 새로운 유행어가 아니라, 도구와 컨텍스트 연동을 표준 인터페이스로 끌어올리는 아키텍처 선택지다.
그리고 Spring AI 2.0은 이 선택지를 클라이언트와 서버 양쪽에서 꽤 실용적인 형태로 제공한다.
마무리
MCP를 너무 거창하게 볼 필요는 없다. 핵심은 단순하다.
- 외부 도구를 표준 방식으로 소비할 수 있고
- 내 기능을 표준 방식으로 제공할 수 있으며
- Spring Boot 안에서 그 설정과 구성을 비교적 자연스럽게 가져갈 수 있다
는 점이다.
이 흐름을 이해하면 Tool Calling, Advisors, MCP가 서로 따로 노는 주제가 아니라는 것도 보인다. 결국 전부 “모델과 애플리케이션 기능을 어떻게 연결할 것인가”라는 하나의 질문으로 이어지기 때문이다.
다음 글에서는 RAG와 운영 현실 쪽으로 다시 시선을 돌려서, 왜 Vector Store 선택이 모델 선택보다 더 운영적인 문제인지 정리해 보겠다.