Transport 고르기

선택 작고 결과 큼. 5 질문 순서대로 걸으면 잘 나옴:

Server 누가 install? User 가 자기 머신에 install (계산기, 개인 노트, 로컬 코드 검색) 이면 stdio 맞음. 여러 user 위해 service 운영하면 Streamable HTTP.
네트워크 도달 필요? Yes 면 Streamable HTTP. 'stdio-over-network' 같은 거 없음 — 그건 이름 잘못 붙인 tunneling protocol 일 뿐.
Horizontal scale 필요? Yes 면 Streamable HTTP, 이상적으로 stateless + load balancer. Stdio 는 process 간 부하 공유 못 함.
Multi-tenant 데이터? Yes 면 Streamable HTTP + per-request 명시적 auth. Stdio 는 'user 가 install' 너머의 auth 개념 없음.
Process restart 살아남? Stdio server 는 host 가 다시 띄울 때 옴; Streamable HTTP server 는 운영자가 restart 할 때 옴. 견딜 수 있는 실패 모드 매치.

정직한 요약: 개인용 stdio, 공유용 Streamable HTTP. 실수가 가장자리에서 — '개인' server 가 팀 서비스로 자람, 'internal' server 가 — 처음부터 auth 가졌어야 했던 — 충분한 사람들에게 노출. 의심 들면 SDK 가 허락하는 transport-agnostic 하게 server 짜고 deploy 시점에 transport 골라.",

Code

같은 FastMCP server, 두 deployment 모양·python

# server.py — 어느 transport 든 동작
from mcp.server.fastmcp import FastMCP
app = FastMCP("my-server")
# ... tool/resource/prompt 정의 ...

# stdio entry point
if __name__ == "__main__":
    app.run()  # 디폴트 stdio

# HTTP entry point (uvicorn / 비슷한 거):
# uvicorn server:app.streamable_http_app

Code

External links

Exercise

Progress

댓글 0