MCP 서버 구축 개념

쓰리원·2025년 5월 18일

AI AI Agent LLM MCP Server Sent Events Streamable HTTP mcp server sse stdio

MCP (Model Context Protocol)

목록 보기

2/4

MCP 의 개념에 대해서 자세히 알고 싶다면 이전글을 읽어보시면 도움이 될것 입니다. 아래는 간단히 소개하는 글로 시작하겠습니다

1. MCP란 무엇인가?

Model Context Protocol (MCP)은 Anthropic이 개발한 개방형 프로토콜로, 대형 언어 모델이 외부 시스템과 안전하고 구조적으로 상호작용할 수 있도록 설계되었습니다. 기존 LLM이 제공하는 단순한 텍스트 응답을 넘어, 외부 API 호출, 실시간 데이터 검색, 문서 조회 및 요약, 툴 실행 등 다양한 기능 확장이 가능해졌습니다.

1. 목적

예를 들어 특정 코드를 검색하고 싶을 때 LLM 애플리케이션에 프롬프트를 작성해 요청하면, GitHub에 접속해서 라이브러리를 조사하는 것이 아니라 기존에 학습한 모델을 바탕으로 응답할 것입니다. 그러면 AI 할루시네이션이 발생할 수 있는 상황이 됩니다.

반면 GitHub MCP를 사용하면 LLM 애플리케이션이 GitHub에 접속해 실제 리포지터리에서 해당 코드를 검색한 뒤 검색 결과를 기준으로 응답합니다. 다만 이를 위해서는 외부 서비스인 GitHub에서 MCP 서버를 제공해야 하며, 사용하는 LLM 애플리케이션에서도 이 MCP를 사용해 호출해야 합니다.

2. 요약 정리

LLM의 기능을 확장하여 "대화형 인터페이스 이상의 역할"을 하게 함

외부 애플리케이션/서비스와 LLM이 구조화된 방식으로 연결 가능

2. MCP 아키텍처 구성

MCP는 호스트 애플리케이션이 여러 서버에 연결할 수 있는 클라이언트-서버 아키텍처를 따릅니다.

MCP 호스트 : MCP를 통해 데이터에 액세스하려는 Claude Desktop, IDE 또는 AI 도구와 같은 프로그램

MCP 클라이언트 : 서버와 1:1 연결을 유지하는 프로토콜 클라이언트

MCP 서버 : 표준화된 모델 컨텍스트 프로토콜을 통해 각각 특정 기능을 노출하는 경량 프로그램

로컬 데이터 소스 : MCP 서버가 안전하게 액세스할 수 있는 컴퓨터의 파일, 데이터베이스 및 서비스

원격 서비스 : MCP 서버가 연결할 수 있는 인터넷(예: API를 통해)을 통해 사용 가능한 외부 시스템

3. MCP 서버 통신 종류

1. Stdio (Standard I/O)

1. Stdio란 무엇인가?

stdio는 MCP 서버가 표준 입력(stdin) 과 표준 출력(stdout) 을 통해 외부 애플리케이션과 직접 통신하는 방식입니다. 이는 일반적인 네트워크 소켓 기반 API 호출과 달리, 네트워크 없이도 두 프로세스 간에 직접 통신할 수 있게 해줍니다.

stdin: 외부 시스템 → MCP 서버로 JSON 요청 전달

stdout: MCP 서버 → 외부 시스템으로 JSON 응답 반환

통신 포맷은 일반적으로 JSON이며, 텍스트 스트림 기반입니다.

예: Claude Desktop이 MCP 서버를 서브프로세스로 실행하고, stdin으로 요청을 전달 → MCP 서버는 처리 후 stdout으로 결과 반환

2. 주요 특징

1. 프로세스 간 통신 (IPC)

MCP 서버는 외부 시스템에 의해 서브프로세스(subprocess) 로 실행됩니다.

외부 시스템은 MCP 서버에 입력 스트림(stdin) 으로 JSON 요청을 보내고, 출력 스트림(stdout) 으로 JSON 응답을 읽습니다.

2. 대표적인 실행 방식

FastMCP.run(transport="stdio")

FastMCP는 OpenMCP의 표준 Python SDK이며, transport="stdio" 설정 시 stdin/stdout을 기반으로 요청을 처리하도록 설정됩니다.
이 서버는 에이전트처럼 작동하며, 외부 시스템과 상호작용합니다.

3. 언어 및 플랫폼

MCP 서버는 Python, Node.js, Go, Rust 등 거의 모든 언어로 작성 가능
외부 시스템은 로컬에서 이 서버를 subprocess로 실행하여 통신

3. 장점

1. 구현 단순성

별도의 웹 서버나 소켓 설정 없이 작동
다양한 언어/환경에서 폭넓게 활용 가능 그리고, stdin, stdout만 다루면 되므로, 시스템 자원이 적게 듬

2. 테스트 및 디버깅 편의

터미널에서 직접 JSON 요청을 보내고, 결과를 받아 테스트 가능

$ echo '{"jsonrpc":"2.0", "method":"hello", "id":1}' | python mcp_server.py

3. 보안성 및 네트워크 불필요

네트워크 통신이 아니므로, 방화벽이나 인증 없이도 실행 가능
민감한 데이터를 로컬에서 안전하게 처리 가능

4. 툴 등록의 간편함

FastMCP 기반으로 tool 등록만 하면 쉽게 에이전트 구현 가능

@mcp.tool()
def get_time():
    return datetime.now().isoformat()

4. 단점

1. 네트워크 호출 불가

MCP 서버는 로컬 프로세스로만 작동
다른 컴퓨터나 서버에서 직접 요청 불가 (원격 호출 불가능)

2. 예외 처리의 복잡성

subprocess 기반 호출은 다음과 같은 위험이 존재:
- 응답 지연
- 프로세스 무한 대기 상태
- 예기치 않은 종료(crash)
따라서 호출하는 쪽에서는 반드시 다음과 같은 예외 처리가 필요함:
- 타임아웃 처리
- 읽기/쓰기 예외 처리
- 프로세스 상태 확인 및 재시도 로직

5. 사용 예시

from mcp import FastMCP

mcp = FastMCP()

@mcp.tool()
def say_hello(name: str) -> str:
    return f"Hello, {name}!"

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

위의 아주 간단한 코드 구성을 통해서 FastMCP() 서버 구성 및 tool을 등록할 수 있습니다.

2. SSE (Server Sent Events)

1. SSE (ServerS ent Events) 란?

SSE(Server Sent Events) 방식은 HTTP 기반의 단방향 스트리밍 기술로, MCP 서버가 클라이언트에게 지속적으로 데이터를 푸시(push) 할 수 있는 구조입니다. MCP에서는 이 방식을 통해 Claude 같은 클라이언트와 지속적인 연결을 유지하면서 Function 요청과 응답을 처리할 수 있습니다.

FastMCP에서는 transport="sse" 또는 sse_app() 메서드를 통해 SSE 기반의 MCP 서버를 생성할 수 있습니다.

2. 주요 특징

1. 통신 방식: HTTP/1.1 기반 단방향 통신

SSE는 기존의 HTTP/1.1 프로토콜 위에서 동작합니다.
클라이언트는 단순히 GET 요청을 보냄. Accept: text/event-stream: SSE 스트리밍을 요청하는 MIME 타입입니다. 이 헤더가 있어야 서버가 SSE로 응답함을 인식합니다.

GET /sse HTTP/1.1
Host: example.com
Accept: text/event-stream

서버는 응답 헤더로 다음과 같이 설정.

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

헤더	의미
`Content-Type: text/event-stream`	SSE의 핵심, 스트리밍 형식임을 명시
`Cache-Control: no-cache`	SSE는 실시간 스트리밍이므로, 브라우저 캐싱 방지
`Connection: keep-alive`	연결을 끊지 않고 지속적으로 유지할 것임을 명시

이후 서버는 본문에 event: 또는 data:로 시작하는 이벤트 메시지를 HTTP 응답 스트림으로 계속 전송합니다.

event: message
data: {"status": "in_progress", "progress": "30%"}

WebSocket은 별도 프로토콜(WS/Sec-WebSocket-Key 등)을 요구하지만, SSE는 HTTP로 통일되어 있으므로 방화벽이나 리버스 프록시 통과가 용이합니다.
대부분의 HTTP 인프라(GCP, Nginx, Apache 등)에서 별도 설정 없이도 기본 지원됩니다.

2. 연결 유지: 지속적인 HTTP 스트리밍 세션

클라이언트가 /sse 경로로 요청을 보내고, 서버는 해당 요청에 대해 응답을 끊지 않고 유지
서버는 연결이 유지되는 동안 언제든 메시지를 전송할 수 있음
HTTP 응답 본문이 한 번에 끝나지 않고, chunked transfer encoding 방식으로 계속 전송됩니다.
FastAPI에서는 다음과 같이 구현 가능:

async def event_stream():
    yield "data: Hello\n\n"
    await asyncio.sleep(1)
    yield "data: World\n\n"

연결이 끊기지 않는 한 서버는 실시간으로 데이터를 계속 푸시
EventSource.readyState로 연결 상태를 체크할 수 있으며, onopen, onmessage, onerror 핸들러 제공

3. 단방향 스트리밍: 서버 → 클라이언트 전용

클라이언트는 단순히 연결을 열고 수신만 하며, 서버만이 자율적으로 원하는 시점에 메시지를 전송할 수 있습니다.
클라이언트는 해당 연결을 통해 데이터를 서버로 보낼 수 없음
클라이언트가 GET /sse 의 엔드포인트로 접속하면, 서버는 해당 HTTP 연결을 끊지 않고 유지하며, 필요한 시점에 데이터를 전송

3. 장점

1. 지속적인 연결 유지

클라이언트(예: Claude Desktop)와 MCP 서버 간의 HTTP 연결을 한 번만 맺고, 그 연결을 끊지 않고 계속 유지합니다.
Claude가 여러 MCP function을 호출해도, 동일한 SSE 연결을 통해 계속 주고받을 수 있음
하나의 TCP 연결로 여러 메시지를 실시간 교환 가능하므로 불필요한 네트워크 오버헤드 없음
SSE는 웹소켓처럼 실시간 연결을 제공하지만, HTTP 표준 안에서 돌아가므로 상대적으로 구현 및 환경 셋팅에 복잡성이 없습니다.

2. 실시간 스트리밍 가능

Claude가 tool(MCP function)을 호출하면, 결과를 한 번에 다 보내는 것이 아니라, 처리 중간 yield를 통해 중간 상태나 메시지를 실시간으로 전달할 수 있음
Claude는 기다리는 동안 "진행 중입니다", "거의 완료!" 등 메시지를 받아 사용자 경험을 향상시킴
LLM 기반 Claude가 마치 실시간으로 사고하는 듯한 흐름 표현이 가능

3. 멀티 클라이언트 처리 가능

하나의 SSE MCP 서버는 여러 클라이언트(Claude 인스턴스)와 각각 연결을 유지하고, 비동기 처리로 병렬로 응답을 보낼 수 있음
FastAPI 기반 SSE는 ASGI 비동기 환경에 최적화되어 있어, 수십~수백 명의 Claude 클라이언트가 동시에 연결해도 서버가 각각의 요청을 효율적으로 처리 가능하고, 별도 워커 분기 없이 자연스럽게 동시성 확보

4. 표준 HTTP 기반

SSE는 별도의 프로토콜 없이 HTTP/1.1만으로 동작하므로, 복잡한 프록시 설정, 방화벽, 인증 구성 없이도 대부분 환경에서 작동함
WebSocket은 종종 방화벽, 리버스 프록시, 인증 헤더 문제에 부딪힘
반면 SSE는 일반적인 text/event-stream MIME 타입만 설정하면 브라우저나 백엔드 환경에서 모두 호환됨
Claude도 기본적으로 SSE 기반 연결을 안정적으로 지원

5. 배포 용이성

FastAPI, Starlette, Uvicorn, Gunicorn, Docker 등 기존 Python 웹 서버 기술을 그대로 사용하여 손쉽게 배포 및 운영 가능
mcp.sse_app()만 호출하면 바로 실행 가능한 FastAPI 앱이 만들어짐
uvicorn app:app 또는 Gunicorn + Uvicorn Worker로 배포
복잡한 메시지 브로커나 비동기 큐 없이도 가볍고 쉽게 실행 가능
AWS, GCP, Vercel 등 표준 HTTP 서버 환경에 바로 올릴 수 있음

4. 단점

1. 단방향 통신

SSE는 서버 → 클라이언트 방향으로만 데이터를 전송할 수 있습니다. 클라이언트가 서버에 데이터를 보내려면 별도의 요청(예: HTTP POST) 이 필요합니다.
HTTP 기반 GET 요청으로 연결을 시작한 후, 서버는 지속적으로 event: message 스트림을 보낼 수 있지만, 클라이언트는 그 연결을 통해 직접 데이터를 보낼 수 없음
Claude는 SSE로 툴 호출 명령을 스트리밍하지만, 클라이언트의 요청은 POST /v1/messages를 통해 전송됩니다. 따라서 클라이언트 → 서버 방향은 SSE가 아닌 별도의 HTTP 통신을 사용하는 표준 구조입니다.
WebSocket과 비교하면 양방향성에서 기능이 제한됨
요약

요청 종류	연결 유지 여부	기능 설명
GET /v1/sse (Claude → MCP 서버)	✅ 유지됨	Claude가 MCP 서버에 SSE 연결 요청을 보내고, MCP 서버는 `event: message` 형식의 스트리밍 데이터를 전송함
POST /v1/messages (`tool_result`)	❌ 응답 후 종료	클라이언트(도구)가 Claude에 툴 실행 결과를 전송. 일반 HTTP 요청으로, 응답 1회 후 종료됨

2. 재연결 처리 필요

SSE는 네트워크 연결이 끊기거나 클라이언트가 잠시 오프라인이 되면, 연결이 자동으로 복구되지 않음. 클라이언트가 직접 재연결 로직을 구현해야 합니다.
Claude처럼 안정적으로 연결 유지가 필요한 환경에서는 → SSE 연결이 끊길 경우 클라이언트에서 감지 → 재시도 로직이 필수
일반 브라우저에서는 EventSource가 내부적으로 재연결을 시도하지만, 상태 동기화/세션 복원은 직접 처리해야 함
예: Last-Event-ID 헤더를 활용해 중단 이후 이어받기 구현 필요

3. 고빈도 메시지에는 부적합

서버가 매우 빈번하게 메시지를 전송할 경우, SSE는 HTTP text/event-stream 포맷의 특성상 스트림 성능이 저하되거나 브라우저가 병목 현상을 일으킬 수 있습니다.
메시지를 0.01초 단위로 보내는 경우, 문자열 파싱 + 이벤트 디스패치 비용이 증가
특히 클라이언트가 JavaScript 기반이라면, onmessage 이벤트가 과도하게 발생해 렌더링 성능 저하 발생
이런 경우엔 gRPC stream, WebSocket, 또는 binary protocol 기반 전송이 적합
Claude는 보통 중간 출력 정도로만 사용하므로 심각한 문제는 아니지만, 실시간 센서/데이터 스트림 용도에는 적합하지 않음

4. 서버의 고가용성 연결 부담

Connection 수 증가: 각 클라이언트마다 하나의 HTTP 연결을 오랫동안 유지해야 하므로, 대규모 서비스에서는 커넥션 수가 빠르게 증가합니다.
리소스 소모: 각 연결은 일정한 서버 리소스를 점유하므로, 서버는 이를 안정적으로 유지하기 위해 적절한 Connection Pool 관리, Keep-Alive 설정, 타임아웃 제어가 필요합니다.
프록시/로드밸런서 대응: 일부 프록시 서버나 로드밸런서가 장시간 지속되는 연결을 차단할 수 있어, 이를 감지하고 대체 연결을 수립하는 로직이 필요합니다.
대부분의 프록시 서버나 로드밸런서는 일정 시간 동안 데이터가 흐르지 않으면 연결을 끊는 정책을 가지고 있습니다. (예: "10분간 데이터가 없으면 이 연결은 죽은 것으로 간주하고 끊어버리자!")

5. 연결 끊김 복구/재개 미지원

연결이 끊어지면 전체 세션 상태가 소실됩니다.
작업 중인 데이터(예: Claude가 분석 중인 대형 문서)의 상태 복구가 불가능합니다.
결과적으로 사용자는 처음부터 다시 작업을 시작해야 하는 불편함이 있습니다.

5. 사용 예시

from mcp import FastMCP

# MCP 인스턴스 생성
mcp = FastMCP()

# 툴 정의
@mcp.tool()
def say_hello(name: str) -> str:
    return f"Hello, {name}!"

# FastAPI 앱 생성
app = mcp.sse_app()

# 서버 실행 (uvicorn 등을 이용)
# uvicorn filename:app --reload

아래와 같은 명령어를 통해 MCP Server를 실행 할 수 있습니다.
uvicorn your_file:app --host 0.0.0.0 --port 8000

3. Streamable HTTP

1. Streamable HTTP 란?

Streamable HTTP는 기존의 HTTP + SSE 방식의 단점을 해결하고, 단일 HTTP 엔드포인트를 통해 요청과 응답을 보다 효율적으로 처리하는 새로운 통신 방식입니다. MCP에서는 transport="streamable-http" 또는 streamable_http_app() 메서드를 통해 Streamable HTTP 서버를 생성할 수 있습니다.

HTTP+SSE : 클라이언트는 HTTP POST를 통해 요청을 보내고, 서버는 별도의 SSE(Server-Sent Events) 엔드포인트를 통해 응답을 푸시하므로 두 개의 별도 연결을 유지해야 합니다.
Streamable HTTP : 단일 HTTP 엔드포인트를 사용하여 요청과 응답을 균일하게 처리하므로 서버는 표준 HTTP 응답을 반환할지 아니면 필요에 따라 SSE 스트리밍을 활성화할지 선택할 수 있습니다.

2. 주요 특징

1. 기존 HTTP + SSE 방식의 문제점

1. 이중 연결 관리 필요

요청은 HTTP POST로, 응답은 별도의 /sse SSE 엔드포인트를 통해 수신.
클라이언트-서버 간 두 개의 연결 필요 → 복잡성 증가, 서버 메시지는 SSE를 통해서만 전송될 수 있는데, 이는 불필요한 복잡성과 오버헤드를 발생시킵니다.

2. 리소스 과다 사용

SSE는 지속적인 연결 유지 필요 → 서버 리소스 많이 소모.
특히 높은 동시 접속 시 TCP 연결 수 급증.

3. 인프라 호환성 문제

일부 방화벽 및 프록시에서 장기 SSE 연결을 강제로 끊고, 기존 네트워크 인프라 중 상당수가 장기 SSE 연결을 제대로 처리하지 못할 수 있습니다. ( 예: 기업 방화벽이 시간 초과된 연결을 강제로 종료하여 서비스 안정성을 저하시킬 수 있습니다. )

2. Streamable HTTP의 핵심 개선점

1. 단일 엔드포인트 구조

Streamable HTTP는 연결 설정을 위한 전용 /sse 엔드포인트를 제거하고 모든 통신을 단일 HTTP POST 엔드포인트로 통합합니다.

간소화된 아키텍처 : 클라이언트와 서버 간의 연결 수를 줄여 시스템 복잡성을 낮춥니다.
리소스 소모 감소 : 단일 연결 관리가 더 효율적이어서 서버 리소스 사용량이 줄어듭니다.
향상된 호환성 : 기존 네트워크 인프라에 더 잘 적응하여 방화벽 및 프록시 서버와의 호환성 문제를 줄입니다.

2. 유연한 전송 모드

서버는 요청의 유형과 내용에 따라 표준 HTTP 응답을 반환할지 아니면 SSE를 통해 스트리밍할지 유연하게 선택할 수 있습니다.

간단한 요청의 경우 긴 연결을 설정하지 않고도 직접 HTTP 응답을 반환할 수 있습니다.
네트워크 상태가 좋지 않을 경우 자동으로 degrade (표준 HTTP로 전환)
리소스 최적화 : 복잡한 요청만 SSE 방식 사용

3. 강력한 세션 관리

상태 관리 및 복구를 지원하기 위해 포괄적인 세션 메커니즘이 도입되었습니다.

세션 일관성 : Mcp-Session-Id 헤더를 통해 요청 전체에서 상태 일관성을 보장.
연결 해제 시 재연결 : 연결 해제 후 수신되지 않은 메시지를 복구할 수 있도록 Last-Event-ID 메커니즘을 지원.
상태 복구: 클라이언트가 다시 연결할 때 이전 세션 상태를 복원할 수 있어 사용자 경험이 향상.

3. TCP 연결 수 비교

Python 프로그램을 사용하여 1,000명의 사용자가 원격 MCP 서버에 동시에 접속하여 도구 목록을 요청하는 상황을 시뮬레이션해 보면, 그림에서 알 수 있듯이 SSE 서버의 SSE 연결은 재사용이 불가능하며 장기적인 유지 관리가 필요합니다. 높은 동시성 요구는 TCP 연결 수의 급격한 증가로 이어지지만, Streamable HTTP 프로토콜은 여러 요청에 대해 동일한 TCP 연결을 재사용하여 직접 응답을 반환할 수 있습니다. TCP 연결 수는 최대 수십 개에 불과하며, 전체 실행 시간은 SSE 서버의 4분의 1에 불과합니다.

동시 사용자가 1000명인 테스트 시나리오에서 Streamable HTTP 솔루션의 TCP 연결 수는 HTTP + SSE 솔루션보다 상당히 낮습니다.

HTTP + SSE: 많은 수의 긴 연결을 유지해야 하며, TCP 연결 수는 시간이 지남에 따라 지속적으로 증가합니다.
Streamable HTTP: 필요에 따라 연결을 설정하고 낮은 수준의 TCP 연결을 유지합니다.

3. 장점

1. 단일 엔드포인트 아키텍처

/sse 같은 별도 엔드포인트 불필요
POST /mcp만으로 모든 요청 및 스트리밍 처리가 가능
코드 간결성과 유지보수 비용 대폭 절감

2. 클라이언트 구현이 단순

연결 유지, 재연결, 이벤트 파싱 등 복잡한 로직이 필요 없음
클라이언트는 단순히 요청을 보내고 응답을 읽기만 하면 됨
실패 시 단순히 재요청하면 됨 (자동 재연결 로직 불필요)

3. 서버 리소스 절약

SSE처럼 항상 연결을 유지할 필요 없음
필요할 때만 스트리밍 연결을 유지하므로 TCP 연결 수를 최소화
테스트 결과, 동시 접속 1000명 시에도 TCP 연결 수 수십 개 수준 유지

4. 높은 안정성과 성능

SSE 방식보다 응답 시간이 짧고 안정적
연결 수 과다 문제 없음 → 리소스 관리 용이

5. 방화벽/프록시 호환성 우수

HTTP POST 기반으로 모든 통신이 이뤄짐 → 방화벽, 프록시, 리버스 프록시 환경에서도 안정적
WebSocket이나 SSE와 달리 특별한 구성 없이 바로 작동 가능

4. 단점

1. WebSocket에 비해 완전한 양방향성이 아님

Streamable HTTP는 요청(POST) → 응답 흐름의 HTTP 구조를 따릅니다.
클라이언트가 서버로 메시지를 보내는 즉시 서버가 반응을 시작할 수는 있지만, 이는 엄밀한 실시간 상호작용은 아닙니다.
WebSocket처럼 양방향 상호 대화가 필요한 경우에는 비효율적

2. SSE보다 덜 직관적인 스트리밍 응답 처리

응답이 JSON이거나 SSE 형식일 수 있음 → 직접 Content-Type 확인 및 파싱 필요
Python에서는 text/event-stream 응답을 직접 수동으로 파싱해야 함

async def streamable_http_client():
    async with aiohttp.ClientSession() as session:
        async with session.post('http://localhost:8000/mcp', json=payload) as resp:
            content_type = resp.headers.get('Content-Type')
            if content_type == 'text/event-stream':
                async for line in resp.content:
                    print("Stream:", line.decode())
            else:
                print("JSON:", await resp.json())

5. 사용 예시

from mcp import FastMCP

# MCP 인스턴스 생성
mcp = FastMCP()

# 툴 정의
@mcp.tool()
def say_hello(name: str) -> str:
    return f"Hello, {name}!"

# FastAPI 앱 생성 (Streamable HTTP 모드)
app = mcp.streamable_app()

# 실행: uvicorn main:app --reload

6. 요약 비교

항목	HTTP + SSE	Streamable HTTP
연결 방식	HTTP POST + SSE GET (2개)	HTTP POST (1개)
실시간 스트리밍	SSE 방식 사용	SSE 또는 HTTP JSON 선택 가능
세션 관리	Last-Event-ID 필요	Mcp-Session-Id로 고급 상태 복구 가능
클라이언트 구현	복잡 (이벤트 수신, 재연결 필요)	단순 (POST 한 번, 응답 읽기)
방화벽 호환성	보통 (장기 연결 문제 발생 가능)	우수 (모든 통신이 POST 기반)
성능	연결 수 증가 시 급격히 저하	안정적, 고동시성에 최적
브라우저 지원	EventSource 내장 지원	fetch + stream 직접 구현 필요

Streamable HTTP는 차세대 MCP 통신의 핵심으로, SSE보다 더 유연하고 간단하며 고성능입니다. 특히 대규모 LLM 기반 툴 호출, 고동시성 환경, 인프라 단순화를 추구하는 기업/개발자에게 적합한 선택입니다.

4. reference

https://modelcontextprotocol.io/introduction
https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http
https://medium.com/@higress_ai/comparison-of-data-before-and-after-using-streamable-http-b094db8b414e
https://medium.com/@nirdiamant21/model-context-protocol-mcp-explained-6dcdc8dc3d44
https://techblog.lycorp.co.jp/ko/introduction-to-mcp-and-building-mcp-server-using-line-messaging-api

쓰리원

가장 아름다운 정답은 서로의 협업안에 있다.

이전 포스트

MCP란 무엇인가?

다음 포스트

MCP 서버 구축 개념

MCP (Model Context Protocol)

1. MCP란 무엇인가?

1. 목적

2. 요약 정리

2. MCP 아키텍처 구성

3. MCP 서버 통신 종류

1. Stdio (Standard I/O)

1. Stdio란 무엇인가?

2. 주요 특징

3. 장점

4. 단점

5. 사용 예시

2. SSE (Server Sent Events)

1. SSE (ServerS ent Events) 란?

2. 주요 특징

3. 장점

1. 지속적인 연결 유지

2. 실시간 스트리밍 가능

3. 멀티 클라이언트 처리 가능

4. 표준 HTTP 기반

5. 배포 용이성

4. 단점

1. 단방향 통신

2. 재연결 처리 필요

3. 고빈도 메시지에는 부적합

4. 서버의 고가용성 연결 부담

5. 연결 끊김 복구/재개 미지원

5. 사용 예시

3. Streamable HTTP

1. Streamable HTTP 란?

2. 주요 특징

1. 기존 HTTP + SSE 방식의 문제점

2. Streamable HTTP의 핵심 개선점

3. TCP 연결 수 비교

3. 장점

4. 단점

1. WebSocket에 비해 완전한 양방향성이 아님

2. SSE보다 덜 직관적인 스트리밍 응답 처리

5. 사용 예시

6. 요약 비교

4. reference

MCP란 무엇인가?

MCP 서버 구현

0개의 댓글