MCP stdio와 Streamable HTTP 비교: 선택 기준과 버전별 차이
- 로컬 프로세스를 호스트가 실행해 표준 입출력으로 연결한다면 stdio가 간단합니다.
- 원격 서버를 운영하거나 여러 클라이언트가 접속한다면 Streamable HTTP를 검토하세요. 인증과 Origin 검증 등 서버 보안 설정이 필요합니다.
- 세션과 GET 스트림 지원 여부는 MCP 규격 버전에 따라 다릅니다. 2026-07-28 규격에서는 프로토콜 세션과 GET 스트림이 제거됐습니다.
MCP(Model Context Protocol)는 AI 호스트와 외부 도구·데이터를 연결하는 프로토콜입니다. 전송 방식은 MCP 메시지를 어떤 경로로 주고받는지 정합니다. 로컬 프로그램이 서버를 자식 프로세스로 실행하는 연결에는 stdio를, HTTP 엔드포인트를 통해 원격 서버에 접속하는 연결에는 Streamable HTTP를 사용할 수 있습니다.
선택할 때는 서버 위치뿐 아니라 도구가 접근해야 하는 파일·계정·서비스의 위치도 고려해야 합니다. 원격 서버로 옮긴다고 사용자의 로컬 파일이 자동으로 공유되는 것은 아닙니다. 또한 Streamable HTTP의 세션과 스트리밍 기능은 프로토콜 버전에 따라 달라질 수 있으므로 클라이언트와 서버의 지원 버전을 확인해야 합니다.
stdio와 Streamable HTTP의 기본 차이
stdio는 호스트가 서버 프로세스를 실행합니다
stdio에서는 클라이언트 역할을 하는 호스트가 MCP 서버를 자식 프로세스로 실행합니다. 서버는 표준 입력(stdin)에서 MCP 메시지를 읽고 표준 출력(stdout)으로 메시지를 보냅니다. 통신을 위해 HTTP 엔드포인트를 별도로 열 필요가 없어 로컬 개발 도구나 개인용 통합에 간편합니다.
표준 출력에는 MCP 메시지만 기록해야 합니다. 시작 문구나 디버그 로그를 stdout에 섞으면 호스트가 이를 프로토콜 메시지로 처리할 수 있습니다. 로그는 표준 오류(stderr)로 보내세요.
Streamable HTTP는 HTTP 엔드포인트로 요청합니다
Streamable HTTP에서는 서버가 MCP 엔드포인트를 운영하고 클라이언트가 HTTP로 요청합니다. 응답은 JSON 객체일 수 있고, 요청 처리 중 관련 메시지를 스트리밍해야 하는 경우에는 SSE(Server-Sent Events)를 사용할 수 있습니다. 따라서 이름에 ‘Streamable’이 들어가도 모든 요청이 장시간 연결을 유지하는 것은 아닙니다.
이 전송은 2025-03-26 규격에서 기존 HTTP+SSE 방식을 대체했습니다. HTTP+SSE는 이전 클라이언트와의 호환이 필요한 경우에 살펴볼 레거시 방식입니다. MCP Streamable HTTP 규격
| 비교 기준 | stdio | Streamable HTTP |
|---|---|---|
| 실행 구조 | 호스트가 로컬 자식 프로세스를 실행 | 독립 HTTP 서버에 접속 |
| 통신 경로 | stdin과 stdout | HTTP 요청·응답, 선택적 SSE 스트리밍 |
| 주요 사용 사례 | 로컬 개발 환경과 파일·명령줄 도구 | 원격 배포와 네트워크를 통한 클라이언트 연결 |
| 운영 점검 | 프로세스 권한, 실행 명령, stdout과 stderr 분리 | 인증, TLS, Origin 검증, 지원 프로토콜 버전 |
stdio가 잘 맞는 상황과 주의점
도구가 로컬 자원에 직접 접근해야 할 때
프로젝트 디렉터리의 코드 검색, 로컬 데이터베이스 접근, 컴퓨터에 설치된 명령줄 프로그램 실행처럼 도구가 호스트와 같은 환경의 자원을 써야 한다면 stdio가 자연스럽습니다. 서버와 데이터가 같은 머신에 있어 원격 접근 경로나 별도 HTTP 엔드포인트를 구성하지 않아도 됩니다.
프로세스 권한과 실행 명령을 확인하세요
stdio는 네트워크 포트를 공개하지 않지만, MCP 서버 프로세스는 실행 계정이 접근할 수 있는 파일과 환경을 사용할 수 있습니다. 서버의 출처와 실행 명령을 확인하고, 필요한 파일과 권한만 허용하세요. 설정 파일에 서버 명령과 인자를 추가할 때 출처를 확인하지 않은 명령을 그대로 실행하지 마세요.
stdio 전송 규격에서는 stdout에 유효한 MCP 메시지만 쓰도록 요구하며, 로그는 stderr로 보낼 수 있습니다. MCP stdio 규격
Streamable HTTP가 적합한 상황
서버가 원격에 있거나 여러 클라이언트가 접속할 때
클라이언트와 서버가 서로 다른 컴퓨터에 있거나 공용 인프라에 서버를 배포해야 한다면 HTTP 기반 연결을 검토할 수 있습니다. 팀에서 서비스를 공유할 때는 사용자 인증과 권한을 서버에서 관리하고, 요청이 어느 사용자에게 속하는지 애플리케이션 차원에서 구분해야 합니다.
도구가 개인 컴퓨터의 파일이나 연결 장치에 접근해야 한다면, 원격 서버가 해당 자원에 접근할 수 있도록 파일을 서버 쪽으로 옮기거나 안전한 저장소·API를 연결해야 합니다. 서버의 위치만 바꾸어서는 로컬 자원이 공유되지 않습니다.
세션 동작을 규격 버전과 함께 판단하세요
2025-11-25 및 그 이전 규격의 Streamable HTTP 구현은 서버 구성에 따라 세션을 유지할 수 있습니다. 이때 세션 상태를 특정 인스턴스의 메모리에 보관한다면 로드밸런서의 고정 세션이나 공유 저장소가 필요할 수 있습니다.
2026-07-28 규격은 프로토콜 수준의 세션과 GET 스트림 엔드포인트를 제거했습니다. 요청은 HTTP POST로 전송하고, 서버는 각 요청에 JSON 응답 또는 해당 요청에 연결된 SSE 스트림으로 응답합니다. 따라서 세션 기반 기능이나 오래된 동작을 전제로 배포 구조를 설계하기 전에, 실제 클라이언트와 서버가 사용하는 규격 버전을 확인하세요. 구버전 클라이언트도 지원해야 한다면 해당 버전과의 하위 호환을 구현에서 확인해야 합니다. Streamable HTTP 최신 규격 및 하위 호환 안내
선택 기준: 호스트가 로컬 프로그램을 실행하고 해당 환경의 자원을 써야 한다면 stdio를 검토하세요. 원격 접속이나 서버 배포가 필요하다면 Streamable HTTP를 검토하고, 프로토콜 버전과 인증·네트워크 설정을 함께 확인하세요.
보안과 운영에서 놓치기 쉬운 점
HTTP 서버의 인증과 Origin 검증
Streamable HTTP 규격은 서버가 들어오는 연결의 Origin을 검증해 DNS 리바인딩 공격을 방어하고, 연결에 적절한 인증을 적용하도록 안내합니다. 로컬에서 실행하는 HTTP 서버는 모든 네트워크 인터페이스에 바인딩하기보다 localhost에만 바인딩하는 방식을 검토하세요. 외부 네트워크에서 운영한다면 TLS, 사용자 인증·인가, 비밀 토큰 보관, 허용 Origin과 프록시 설정을 환경에 맞게 구성해야 합니다.
MCP가 도구 호출의 메시지 형식을 정해도 누가 어떤 도구를 실행할 수 있는지 자동으로 결정해주지는 않습니다. 브라우저 클라이언트를 허용한다면 인증 정보를 사용하는 요청에 맞게 CORS 정책을 구성하고, 배포 환경의 프록시와 서버가 Origin 검증을 어떻게 처리하는지도 확인하세요. MCP 전송 규격의 보안 안내
호출할 수 있는 도구의 권한을 제한하세요
전송 방식과 관계없이 읽기·쓰기·삭제·외부 전송 권한을 구분하고, 위험한 작업은 입력 검증과 사용자 확인을 거치게 설계하세요. 여러 사용자가 같은 서버를 이용한다면 인증 정보, 세션, 캐시, 도구 실행 결과가 사용자 간에 섞이지 않는지 확인해야 합니다. 로그에는 요청 식별자와 오류를 남기되 인증 토큰이나 민감한 입력값은 기록하지 않도록 주의하세요.
- stdio 점검: 서버 출처, 실행 계정 권한, 허용 디렉터리, stdout과 stderr 분리
- HTTP 점검: Origin 검증, HTTPS, 사용자 인증·인가, 비밀정보와 프록시 설정
- 공통 점검: 도구별 최소 권한, 입력 검증, 오류 처리와 민감정보 마스킹
상황별 선택 순서
- 도구가 접근해야 할 파일과 프로그램이 어디에 있는지 확인합니다. 호스트 머신의 자원을 직접 써야 한다면 stdio가 유력합니다.
- 접속하는 클라이언트의 위치와 수를 확인합니다. 원격 서버나 여러 클라이언트가 필요하다면 Streamable HTTP를 검토합니다.
- 클라이언트와 서버가 지원하는 MCP 규격 버전을 확인합니다. 특히 구버전 호환, 세션, GET 스트림 지원 여부를 점검합니다.
- HTTP 서버라면 인증, 권한, Origin 검증, TLS와 프록시 구성을 정합니다.
- 실제 도구 호출과 오류·종료 상황을 확인한 뒤 운영 환경에 배포합니다.
개인용 로컬 도구는 stdio로 시작하는 것이 단순할 수 있습니다. 팀 공유나 원격 운영 요구가 생기면 Streamable HTTP 배포를 검토하세요. 두 전송을 함께 지원할 경우에는 클라이언트별 설정과 프로토콜 버전, 인증 경계를 각각 확인해야 합니다.
자주 묻는 질문
Q. stdio MCP 서버에는 보안 점검이 필요 없나요?
필요합니다. HTTP 인증을 거치는 구조는 아니지만 서버 프로세스는 실행 계정의 권한으로 파일과 환경에 접근합니다. 신뢰할 수 있는 서버만 실행하고 권한을 최소화하세요.
Q. Streamable HTTP는 항상 SSE 연결을 유지하나요?
아닙니다. 요청은 HTTP POST로 전송되며 응답은 JSON 객체일 수도 있고 SSE 스트림일 수도 있습니다. 최신 2026-07-28 규격은 GET 기반 스트림을 제거했으므로, 지원 규격과 구현을 확인하세요.
Q. Streamable HTTP의 상태 유지 방식은 언제 고려하나요?
세션을 사용하는 2025-11-25 및 이전 규격의 구현을 운영하거나 해당 버전의 클라이언트와 호환해야 할 때 세션 동작을 확인하세요. 2026-07-28 규격에서는 프로토콜 세션이 제거됐으며, 여러 요청에 걸친 애플리케이션 상태가 필요하면 서버 구현에서 별도로 설계해야 합니다.
Q. 로컬 파일을 사용하는 서버를 원격으로 옮길 수 있나요?
가능하지만 원격 서버가 해당 파일에 접근할 방법을 따로 마련해야 합니다. 파일을 서버 환경에 옮기거나 접근 통제가 적용된 저장소·API를 연결하세요. 원격 배포만으로 사용자 컴퓨터의 파일이 공유되지는 않습니다.
Q. 새 HTTP 기반 MCP 구현에서 예전 HTTP+SSE를 선택해도 되나요?
기존 클라이언트와 호환해야 할 때는 해당 클라이언트의 지원 전송을 확인하세요. 새 구현에서는 Streamable HTTP를 기준으로 검토하고, 함께 지원할 프로토콜 버전의 차이를 확인하는 것이 좋습니다.
