Transport 고르기

선택지는 작은데 결과는 커. 질문 다섯 개를 순서대로 걸으면 대체로 답이 나와:

Server 를 누가 설치해? User 가 자기 머신에 깔아 쓰면 (계산기, 개인 노트, 로컬 코드 검색) stdio 가 맞아. 여러 user 를 위해 서비스로 돌린다면 Streamable HTTP 고.
네트워크로 닿아야 해? 그렇다면 Streamable HTTP. 'stdio 를 네트워크로' 같은 건 없어 — 그건 이름만 잘못 붙인 터널링일 뿐이야.
옆으로 늘려야 해? 그렇다면 Streamable HTTP, 되도록 stateless 로 짜서 부하 분산기 뒤에 세워. Stdio 는 프로세스끼리 부하를 나눠 지지 못해.
여러 고객의 데이터를 다뤄? 그렇다면 Streamable HTTP 에 요청마다 명시적인 auth 를. Stdio 에는 'user 가 설치했다' 너머의 auth 개념이 아예 없어.
프로세스가 죽었다 살아나는 걸 어떻게 견뎌? Stdio server 는 host 가 다시 띄울 때 돌아오고, Streamable HTTP server 는 운영자가 다시 올릴 때 돌아와. 네가 감당할 수 있는 실패 모양에 맞춰.

솔직한 요약은 이거야. 개인용이면 stdio, 공유용이면 Streamable HTTP. 사고는 늘 경계에서 나. '개인용' server 가 어느새 팀 서비스로 자라 있고, '사내용' server 가 처음부터 auth 를 달았어야 할 만큼 많은 사람한테 열려 있는 식이지. 애매하면 SDK 가 허락하는 선까지 transport 를 안 가리게 짜두고, 배포하는 시점에 골라.

Code

같은 FastMCP server, 두 가지 배포 모양·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