Model Context Protocol (MCP)는 현대의 대규모 언어 모델 (LLMs)과 에이전트 런타임 (agentic runtimes)이 외부 시스템을 발견하고, 호출하며, 상호작용하는 방식을 완전히 변화시켰습니다. 에이전트 호스트 (agentic hosts)와 도구 (tool), 리소스 (resource), 프롬프트 제공자 (prompt providers) 사이의 통신 브릿지를 표준화함으로써, MCP는 맞춤형 에이전트 통합의 파편화 문제를 해결합니다.

하지만 프로덕션급 에이전트 인프라를 구축할 때 개발자들은 근본적인 아키텍처 질문에 직면하게 됩니다: 이 개별적인 프로세스, 애플리케이션, 그리고 분산된 노드들은 실제로 어떻게 서로 대화하는가?

그 해답은 전적으로 전송 계층 (transport layer) 안에 있습니다. Node.js 생태계에서 전송 계층을 선택하는 것은 결코 단순한 표면적 설정 세부 사항이 아닙니다. 이는 보안 경계 (security boundary), 지연 시간 프로필 (latency profile), 배포 토폴로지 (deployment topology), 그리고 전반적인 운영 복잡성을 직접적으로 결정합니다.

번개처럼 빠른 로컬 개발자 유틸리티를 구축하든, 멀티 테넌트 클라우드 네이티브 SaaS 마이크로서비스를 구축하든, **Stdio (Standard Input/Output)**와 **Server-Sent Events (SSE)**의 이론적 메커니즘과 실제 구현을 이해하는 것은 필수적입니다. 두 패러다임을 깊이 있게 살펴보고, 아키텍처를 비교하며, 프로덕션 준비가 된 TypeScript 구현을 함께 살펴보겠습니다.

두 가지 패러다임: 로컬 프로세스 격리 vs. 네트워크 기반 멀티플렉싱

MCP 내에서 Stdio와 SSE 전송 방식 사이의 이분법을 진정으로 파악하려면, 운영 체제와 네트워크 스택이 데이터 교환을 어떻게 관리하는지 검토해야 합니다.

Stdio: 프로세스 제한 파이프라인

Stdio 전송 방식은 프로세스 실행에 대한 전통적인 Unix 철학을 활용합니다. 생성된 모든 프로세스는 부모로부터 세 가지 표준 데이터 스트림을 상속받습니다: stdin (File Descriptor 0), stdout (File Descriptor 1), 그리고 stderr (File Descriptor 2). MCP 컨텍스트 내에서, 에이전트 호스트 (클라이언트)는 Node.js의 child_process.spawn()과 같은 운영 체제 API를 사용하여 도구 제공자 (서버)를 자식 프로세스로 생성합니다.

메시지 교환은 이러한 파일 디스크립터 (file descriptors)를 통한 직접적인 바이트 스트림 직렬화 (byte-stream serialization)를 통해 이루어집니다. 에이전트 호스트 (agent host)가 도구를 호출해야 할 때, JSON-RPC 요청을 직렬화하여 자식 프로세스의 stdin 스트림에 직접 씁니다. 자식 프로세스는 표준 입력 (standard input)으로부터 읽어 로직을 실행하고, JSON-RPC 응답을 자신의 stdout 스트림에 직접 쓰며, 호스트는 이를 비동기적으로 읽습니다.

여기서 핵심적인 장점은 완전한 격리 (isolation)와 설정이 필요 없는 네트워킹 (zero-configuration networking)입니다. 통신 채널이 운영 체제 파이프 (operating system pipes, POSIX 시스템의 pipe(2) 또는 Windows의 익명 파이프)에 의존하기 때문에, 협상해야 할 TCP/IP 스택 오버헤드, 포트 할당, DNS 조회 또는 방화벽 규칙이 없습니다. 또한, 서버 프로세스의 생명 주기 (lifecycle)가 호스트 클라이언트와 결정론적으로 연결되어 있습니다. 호스트 클라이언트가 종료되면 운영 체제가 자식 프로세스를 자동으로 회수합니다.

Server-Sent Events (SSE): 네트워크 기반 스트리밍 채널

반대로, Server-Sent Events (SSE) 전송 계층은 통신 채널을 로컬 프로세스 파이프로부터 추상화하여 표준 HTTP/1.1 또는 HTTP/2 네트워크 스택 위에 직접 배치합니다. SSE는 HTTP를 기반으로 구축된 단방향 프로토콜로, 서버가 단일한 장기 유지 TCP 연결 (long-lived TCP connection)을 통해 클라이언트에 실시간 데이터 업데이트를 푸시할 수 있게 합니다.

MCP SSE 아키텍처에서 전송 계층은 두 개의 논리적 채널로 분리됩니다:

1. 인바운드 채널 (Inbound Channel, 클라이언트-to-서버): 클라이언트는 서버의 지정된 엔드포인트(endpoint)로 표준 HTTP POST 요청을 통해 JSON-RPC 요청을 보냅니다.
2. 아웃바운드 채널 (Outbound Channel, 서버-to-클라이언트): 클라이언트는 Accept: text/event-stream 헤더를 사용하여 HTTP 연결을 엽니다. 서버는 이 연결을 무기한 열어두고, JSON-RPC 알림 (notifications)과 응답 청크 (response chunks)를 표준 SSE 텍스트 블록(`data: <json-payload>

`) 형식으로 구성하여 회선(wire)을 통해 스트리밍합니다.

이러한 디커플링된(decoupled) 아키텍처를 통해 MCP 서버는 IP 주소만 있다면 어디에나 존재할 수 있습니다. Kubernetes 클러스터 내의 전용 마이크로서비스(microservice), 서버리스 컨테이너 인스턴스, 또는 원격 에지 노드(edge node) 등이 그 예입니다. 하지만 이러한 유연성은 네트워크 분할(network partitions), 로드 밸런서 타임아웃(load balancer timeouts), 인증 헤더(authentication headers), TLS 종료(TLS termination), 그리고 여러 동시 클라이언트 세션 간의 상태 동기화(state synchronization)와 같은 분산 시스템의 고전적인 복잡성을 야기합니다.

심층 분석: Stdio 전송 계층의 메커니즘

Node.js에서 Stdio 전송을 마스터하려면 스트림 프레이밍(stream framing)과 단일 스레드 이벤트 루프(single-threaded event loop)가 I/O를 처리하는 방식을 면밀히 살펴봐야 합니다.

스트림 프레이밍과 JSON-RPC 라인 구분(Line Delimitation)

JSON-RPC 2.0은 상태가 없는(stateless) 경량 원격 프로시저 호출(remote procedure call) 프로토콜입니다. 이 프로토콜은 페이로드(payload)의 형태(예: {"jsonrpc": "2.0", "method": "...", "params": {...}, "id": 1})를 정의하지만, 원시 스트림(raw stream) 상에서 메시지가 어떻게 프레이밍되는지는 규정하지 않습니다. TCP와 OS 파이프(pipes)는 메시지 경계를 보존하지 않는 연속적인 바이트 스트림(byte streams)이기 때문에, Stdio 전송 계층은 애플리케이션 계층의 프레이밍 프로토콜을 구현해야 합니다.

MCP에서 Stdio를 위한 범용 프레이밍 표준은 **NDJSON (Newline-Delimited JSON)**입니다. 요청(request), 응답(response), 또는 알림(notification) 여부에 관계없이 모든 개별 JSON-RPC 메시지는 줄바꿈 문자(\n 또는 \r\n)로 끝나는 단일하고 압축된 JSON 문자열로 직렬화(serialize)되어야 합니다.

서버가 도구 목록(tool listing) 응답을 내보내고자 한다면, JSON 객체를 생성하고, 이스케이프되지 않은 줄바꿈 문자가 포함되지 않도록 단일 행으로 최소화(minify)한 뒤, 이를 stdout에 쓰고 줄바꿈 문자를 추가합니다. 호스트 프로세스는 stdout으로부터 청크(chunk) 단위로 읽어 들여, 줄바꿈 구분자를 만날 때까지 들어오는 바이트를 메모리 버퍼에 쌓아두었다가, 해당 슬라이스(slice)를 추출하여 JSON으로 파싱하고 JSON-RPC 디스패처(dispatcher)로 라우팅합니다.

Node.js에서의 비동기 처리와 논블로킹 I/O (Non-Blocking I/O)

TypeScript로 Stdio 기반의 MCP 서버를 구축할 때, libuv에 의해 구동되는 Node.js 이벤트 루프 (event loop)를 관리하는 것은 매우 중요합니다. 입력 스트림 (process.stdin)과 출력 스트림 (process.stdout)은 논블로킹 (non-blocking) 모드에서 net.Socket과 유사한 스트림으로 작동합니다.

MCP 서버가 외부 API를 통한 임베딩 (embedding) 생성이나 로컬 벡터 데이터베이스 (vector database) 쿼리와 같이 집약적인 도구 호출 (tool call)을 실행하는 상황을 가정해 보겠습니다. 제공자(provider)로부터 네트워크 응답을 기다리는 동안, Node.js 이벤트 루프는 블로킹되지 않은 상태를 유지하여 process.stdin으로부터 들어오는 JSON-RPC 취소 요청이나 하트비트 핑 (heartbeat ping)을 읽을 수 있습니다.

하지만 개발자는 fs.readFileSync와 같은 동기적 (synchronous) 작업이나 대규모 데이터셋에 대한 과도한 CPU 집약적 (CPU-bound) JSON 파싱 (parsing)으로 인해 이벤트 루프가 차단되지 않도록 엄격하게 주의해야 합니다. 만약 이벤트 루프가 얼어붙으면(freeze), process.stdin에 대한 운영 체제의 버퍼 (buffer)가 빠르게 가득 차게 됩니다. OS 파이프 버퍼 (pipe buffer)가 용량에 도달하면, 부모 호스트 프로세스는 추가 요청을 쓰려고 시도할 때 블로킹되어, 에이전틱 런타임 (agentic runtime)에서 지연 시간 급증(latency spikes)을 유발하거나 타임아웃 예외 (timeout exceptions)를 발생시킵니다.

심층 분석: SSE 전송 계층의 메커니즘

Stdio가 운영 체제의 경계에 의존하는 반면, 서버 전송 이벤트 (Server-Sent Events, SSE) 전송 계층은 HTTP 프리미티브 (primitives), 청크 전송 인코딩 (chunked transfer encoding), 그리고 세션 관리 (session management)에 크게 의존합니다.

프로토콜 라이프사이클: 핸드셰이크 및 이벤트 스트리밍

MCP SSE 연결을 설정하려면 구조화된 다단계 핸드셰이크 (handshake)가 필요합니다:

1. SSE 연결 설정 (The SSE Connection Establishment): MCP 클라이언트는 서버의 SSE 엔드포인트(예: https://mcp.enterprise.internal/sse)로 HTTP GET 요청을 보냅니다. 이때 이벤트 스트림을 기대한다는 것을 나타내는 헤더(Accept: text/event-stream, Cache-Control: no-cache, Connection: keep-alive)를 포함합니다.
2. 서버 스트림 초기화 (The Server Stream Initialization): 서버는 200 OK 상태로 응답하며, Content-Type 헤더를 text/event-stream으로 설정하고 TCP 연결을 유지합니다. 초기 핸드셰이크 이벤트(종종 endpoint라는 이름의 이벤트로 방출됨)의 일부로, 서버는 클라이언트가 이후의 JSON-RPC 요청을 보내야 하는 특정 URI 경로를 전송합니다.
3. 메시지 POST 채널 (The Message POST Channel): 클라이언트가 JSON-RPC 요청(예: tools/call 호출)을 보내고자 할 때, 엔드포인트 이벤트에서 제공된 URI로 HTTP POST 요청을 발행하며, 요청 본문(request body)에 JSON-RPC 페이로드(payload)를 전달합니다.
4. 아웃바운드 알림 스트림 (The Outbound Notification Stream): 서버는 요청을 비동기적으로 처리합니다. 서버는 HTTP POST 응답을 통해 즉각적인 결과를 반환하거나, 열려 있는 GET /sse 지속 연결(persistent connection)을 통해 이벤트 프레임(event frames)으로서 비동기 알림 및 응답을 푸시(push)합니다.

멀티플렉싱 및 상태 유지 세션 관리 (Multiplexing and Stateful Session Management)

하나의 부모 프로세스와 하나의 자식 프로세스 사이의 내재적인 1:1 전용 파이프(pipe)인 Stdio와 달리, SSE 서버는 일반적으로 공유 웹 서비스로 배포됩니다. 이는 중요한 아키텍처적 과제를 야기합니다: 다중 클라이언트 동시성 및 상태 격리 (Multi-Client Concurrency and State Isolation).

단일 HTTP 서버 인스턴스는 수십 개의 서로 다른 에이전트 호스트(agentic hosts)로부터 동시에 SSE 연결을 받을 수 있습니다. 따라서 서버는 엄격한 세션 상태 관리(session state management)를 유지해야 합니다. 모든 유입되는 GET /sse 연결에는 고유한 세션 식별자(session identifier)가 할당되어야 합니다. POST /message가 도착하면, 서버는 세션 ID 쿼리 매개변수(query parameter) 또는 헤더를 사용하여 유입된 JSON-RPC 요청을 올바른 내부 클라이언트 컨텍스트(client context) 또는 워커 스레드(worker thread)로 라우팅합니다.

나아가, 분산 배포(distributed deployments)는 부하 분산(load balancing) 문제를 야기합니다. 만약 기업이 수평적 오토스케일링 그룹(horizontal auto-scaling group) 뒤에 MCP SSE 서버를 배포한다면(예: 세 개의 Node.js 포드(pod) 앞에 AWS Application Load Balancer를 배치하는 경우), GET /sse 요청은 포드 A(Pod A)에 도달할 수 있지만, 동일한 세션에 대한 후속 POST /message 요청은 포드 B(Pod B)에 도달할 수 있습니다. 스티키 세션(sticky sessions)이나 포드 간 상태를 동기화하는 중앙 집중식 메시지 브로커(Redis Pub/Sub 등)가 없다면, 포드 B는 포드 A에서 열려 있는 SSE 스트림에 대해 알지 못하므로 통신 채널이 실패하게 됩니다.

아키텍처 비교: 웹 개발 비유

이러한 추상적인 전송 메커니즘(transport mechanisms)을 익숙한 소프트웨어 엔지니어링 개념에 고정하기 위해, 전통적인 웹 개발 패러다임의 관점에서 이를 살펴보겠습니다.

• Stdio vs. SSE: 모놀리식 서브프로세스(Monolithic Subprocesses) vs. 마이크로서비스 API(Microservice APIs)
  • Stdio는 메인 애플리케이션(Main Application)이 로컬에서 CLI 서브프로세스(CLI Subprocess) 또는 워커 스레드(Worker Thread)를 생성하는 것과 유사합니다. 이미지를 최적화하기 위해 로컬 셸 스크립트를 실행하거나 child_process.exec()를 통해 자식 프로세스(child process)를 실행하는 Next.js 서버를 생각해 보십시오. 이는 밀접하게 결합(tightly coupled)되어 있고, 빠르며, 오버헤드가 없고, 네트워크 인터페이스를 전혀 건드리지 않기 때문에 매우 안전하지만, 애플리케이션을 호스팅하는 물리적 머신에 완전히 종속됩니다.
  • SSE는 React 프론트엔드(Frontend)가 WebSocket 또는 롱 폴링(Long-Polling)을 통해 백엔드 API(Backend API)와 통신하는 것과 유사합니다. 브라우저가 들어오는 채팅 메시지를 받기 위해 지속적인 SSE 연결을 열고, 표준 fetch() POST 요청을 통해 사용자 메시지를 보내는 실시간 채팅 애플리케이션을 생각해 보십시오. 이는 네트워크 경계를 넘나들며, 명시적인 인증 토큰(authentication tokens)이 필요하고, 프록시(proxies)를 협상하며, 클라우드 인프라 전반에 걸쳐 수평적으로 확장(scales horizontally)됩니다.

보안, 에러 처리 및 회복탄력성

전송 계층(transport layer)을 선택하는 것은 위협 모델(threat model)과 회복탄력성(resilience) 전략을 직접적으로 정의합니다.

Stdio 위협 모델링

Stdio는 운영 체제 파이프 (OS pipes)를 통해 로컬 머신 내부에서만 완전히 작동하기 때문에, 네트워크 기반의 취약점(Man-in-the-Middle 공격, 패킷 스니핑 (packet sniffing), DNS 스푸핑 (DNS spoofing), 승인되지 않은 외부 IP 접근 등)의 범주를 통째로 제거합니다. 관리해야 할 TLS 인증서나 설정해야 할 네트워크 방화벽도 없습니다.

하지만 Stdio는 로컬 권한 상승 (local privilege escalation) 및 공급망 (supply chain) 공격 벡터를 유발할 수 있습니다:

• 프로세스 생성 (Spawning)을 통한 임의 코드 실행 (Arbitrary Code Execution): 만약 MCP 호스트가 신뢰할 수 없는 입력을 기반으로 Stdio 서버를 생성(spawn)하는 데 사용되는 명령 문자열을 동적으로 구성한다면, 공격자는 호스트 머신에서 원격 코드 실행 (RCE)을 달성할 수 있습니다.
• 프로세스 하이재킹 (Process Hijacking) 및 Stdin/Stdout 변조: 악성 프로세스가 호스트 머신의 사용자 공간 (user space)에 접근할 수 있다면, 적절한 파일 권한 경계가 유지되지 않을 경우 이론적으로 파일 디스크립터 (file descriptors)에 연결하거나 이를 조작할 수 있습니다.

SSE 위협 모델링 (Threat Modeling SSE)

SSE는 MCP 도구를 네트워크 스택 (network stack)에 노출시키므로, 표준 웹 애플리케이션 보안 원칙의 적용을 받게 됩니다: