아키텍처

에이전트 통신의 WebSocket vs SSE: MCP가 둘 다 선택하지 않은 이유

글쓴이: IdeaBosque최종 업데이트: 2026年9月11日

핵심 요점

MCP 2026-07-28 사양은 HTTP+SSE를 더 이상 사용하지 않고 Streamable HTTP로 대체했습니다 — WebSocket이 아닙니다 — 상태 비저장 서버가 영구 연결 관리 없이 표준 HTTP 인프라(WAF, 로드 밸런서, 인증 프록시)로 작동하기 때문입니다(MCP specification).
A2A는 작업 출력 스트리밍을 위해 HTTP 기반 JSON-RPC 2.0과 SSE를 사용합니다 — 전송은 배관이며, 프로토콜 의미(작업 수명 주기, INPUT_REQUIRED 상태)가 에이전트 간 통신을 작동시키는 것입니다(A2A protocol).
CVE-2026-16496(CVSS 10.0)은 Terraform MCP의 상태 저장 SSE 전송 모드를 악용했습니다 — 도난당한 세션 ID로 공격자가 다른 사용자의 자격 증명으로 도구 호출을 실행할 수 있었습니다. 상태 비저장 전송은 패치 수준이 아닌 아키텍처 수준에서 공격 표면을 제거합니다(NVD).
WebSocket은 사용자 정의 MCP 전송으로 사용 가능하지만 사양 작성자가 의도적으로 회피한 세션 관리 복잡성을 추가합니다 — 프로토콜은 전송 독립적이지만, 표준 전송(stdio, Streamable HTTP)이 프로덕션 사례를 다룹니다(MCP specification).
2026년 9월 17일 AGNTCon+MCPCon Europe의 "Stateless: The Future of MCP Transports" 세션은 상태 비저장 전송 방향의 첫 주요 컨퍼런스 검증입니다 — Google과 Hugging Face(MCP Transport Working Group 유지관리자)가 발표(Linux Foundation).

전송 문제는 인프라 배관처럼 들리며, 실제로 그렇습니다 — 하지만 이 선택은 프로덕션에서 나타나는 보안, 확장성, 운영상의 결과를 가져옵니다. Model Context Protocol이 2026년 7월 28일 HTTP+SSE를 더 이상 사용하지 않고 Streamable HTTP로 대체했을 때, 사양 작성자는 의도적인 엔지니어링 결정을 내렸습니다: 영구 연결보다 상태 비저장 서버, 사용자 정의 프로토콜보다 표준 HTTP, 듀얼 엔드포인트 SSE 모델보다 단일 엔드포인트. WebSocket은 양방향이고 SSE는 그렇지 않음에도 불구하고 WebSocket을 선택하지 않았습니다. 이유는 WebSocket이 잘못되어서가 아니라 — MCP가 서비스하는 특정 워크로드(에이전트와 데이터 소스 간의 도구 호출)에서 양방향 기능이 세션 관리 오버헤드만큼의 가치가 없기 때문입니다.

이 글은 세 가지 전송 옵션 — SSE, WebSocket, Streamable HTTP — 을 사용하는 두 에이전트 프로토콜(MCP와 A2A)에 매핑하고, B2B 에이전트 배포를 위한 의사결정 매트릭스를 제공합니다. 9월 17일 AGNTCon 세션이 타이밍을 구체적으로 만듭니다: 상태 비저장 전송이 사양에서 컨퍼런스 검증으로 이동하고 있으며, 더 이상 사용되지 않는 SSE 전송을 실행하는 팀에는 12개월 마이그레이션 윈도우가 있고 그 중 2개월이 이미 경과했습니다.

세 가지 전송과 각각의 기능

SSE(Server-Sent Events) — 더 이상 사용되지 않는 기본값

SSE는 단방향 프로토콜입니다: 서버가 장수명 HTTP 연결을 통해 클라이언트에 데이터를 푸시하며, 클라이언트는 같은 연결로 메시지를 돌려 보낼 수 없습니다. 클라이언트의 모든 작업 — 생성 취소, 작업 중 에이전트 조정, 도구 호출 승인 — 은 별도의 HTTP POST 요청이 필요합니다(WebSocket.org).

MCP는 2024-11-05 사양에서 원격 서버용 전송으로 SSE를 사용했습니다. 이 모델은 두 개의 엔드포인트가 필요했습니다: 서버-클라이언트 메시지용 SSE 엔드포인트와 클라이언트-서버 메시지용 별도 POST 엔드포인트. 서버는 두 연결 모두에서 세션 상태를 유지했습니다. 세 가지 제한이 더 이상 사용하지 않는 결정을 이끌었습니다: 재개 가능한 스트림 미지원, 장수명 고가용성 연결 요구, SSE를 통해서만 전달되는 서버 메시지(MCP specification PR #206).

A2A는 여전히 스트리밍 모드에 SSE를 사용합니다. SendStreamingMessage 메서드는 작업 업데이트를 SSE 이벤트로 전달합니다 — 토큰 델타, 아티팩트 청크, 상태 전환. 이것은 A2A에 올바른 선택입니다. 왜냐하면 스트리밍이 단방향(서버에서 클라이언트)이고 클라이언트의 제어 메시지(취소, 구독)가 별도의 JSON-RPC 호출을 통해 이루어지기 때문입니다(A2A protocol). SSE는 단순하고, 표준 HTTP에서 작동하며, 근본적으로 서버 푸시인 워크로드에 WebSocket의 세션 관리가 필요하지 않습니다.

WebSocket — MCP가 표준화하지 않은 양방향 옵션

WebSocket은 클라이언트와 서버 간의 영구적이고 양방향인 연결을 제공합니다. HTTP 업그레이드 핸드셰이크 후, 연결은 열린 상태로 유지되고 양측이 언제든지 메시지를 보낼 수 있습니다. 이것은 단일 채널에서 진정한 양방향 통신이 필요한 애플리케이션에 적합한 프리미티브입니다: 채팅, 협업 편집, 멀티플레이어 게임, 거래 대시보드(Ably).

AI 에이전트의 경우, 양방향 사례는 실재합니다. 에이전트 워크플로는 실행 중에 클라이언트-서버 메시지가 필요합니다: 생성 취소, 작업 중 에이전트 조정, 도구 호출 승인 또는 거부, 후속 컨텍스트 전송. SSE에서는 이들 각각이 별도의 HTTP 요청입니다. WebSocket에서는 토큰 스트림과 같은 연결에 탑재됩니다(WebSocket.org).

MCP 사양은 WebSocket을 표준화하지 않습니다. 사용자 정의 전송으로 사용 가능합니다 — 사양은 JSON-RPC 메시지 형식을 보존하는 한 "클라이언트와 서버는 추가 사용자 정의 전송 메커니즘을 구현할 수 있다"고 말합니다 — 하지만 표준 전송은 stdio(로컬 서버용)와 Streamable HTTP(원격 서버용)입니다(MCP specification). GitHub 이슈(#493)가 HTTP 모델을 단순화하기 위해 WebSocket을 표준 전송으로 추가할 것을 제안했지만; 채택 없이 닫혔고 사양은 대신 Streamable HTTP로 이동했습니다(GitHub).

MCP가 WebSocket을 표준화하지 않은 이유는 운영상의 것이지 기술적인 것이 아닙니다. WebSocket은 서버가 영구 연결을 유지하고, 세션 건강을 관리하고, 재연결 로직을 처리하고, 끊어진 연결을 다루도록 요구합니다. 이것은 SSE를 부담으로 만든 것과 같은 상태 저장 연결 부담입니다. MCP 작성자는 상태 비저장 서버를 원했습니다 — 어떤 인스턴스든 어떤 요청이든 처리할 수 있고, 공유 세션 저장소 없이, 단순 라운드 로빈 로드 밸런싱 — 그리고 WebSocket의 영구 연결 모델은 그 목표에 반대로 작용합니다.

Streamable HTTP — MCP가 대신 선택한 것

Streamable HTTP는 MCP 사양의 SSE 대 WebSocket 문제에 대한 답입니다. 서버는 POST와 GET을 모두 처리하는 단일 HTTP 엔드포인트(예: https://example.com/mcp)를 노출합니다. 클라이언트는 모든 JSON-RPC 메시지를 POST로 보냅니다. 서버는 단순 JSON 본문으로 응답하거나 결과가 장시간 실행되는 경우 응답을 SSE 스트림으로 업그레이드할 수 있습니다. 핵심 설계 선택: 서버는 영구 연결을 유지할 필요가 없습니다. 모든 요청은 자급자족합니다(MCP specification).

이것은 MCP에 장수명 연결 요구 없이 SSE의 스트리밍 기능을 제공하고, 세션 관리 오버헤드 없이 WebSocket의 양방향 기능을 제공합니다. 클라이언트는 POST(표준 HTTP)로 메시지를 보내고, 서버는 선택적 SSE(표준 HTTP)로 응답을 스트리밍하며, 서버는 상태 비저장일 수 있습니다(표준 HTTP 인프라)(Bright Data; Auth0).

보안 논증은 구체적입니다. Auth0의 분석: Streamable HTTP에서, "표준 `Authorization: *** 헤더를 모든 봉투에 찍을 수 있습니다. 우편실은 첫 번째 메시지가 아닌 모든 메시지의 도장을 확인합니다." 이전 SSE 전송에서는 인증 토큰이 연결 시 한 번 설정되었고 영구 연결이 모든 후속 메시지를 전달했습니다 — 세션 ID를 훔친 공격자의 메시지를 포함하여(Auth0).

의사결정 매트릭스

기준	SSE(더 이상 사용 안 함)	WebSocket(사용자 정의)	Streamable HTTP(MCP 표준)
방향	서버 → 클라이언트만	양방향	POST(클라이언트→서버) + 선택적 SSE
연결 모델	장수명, 영구적	장수명, 영구적	요청별(상태 비저장)
서버 상태	상태 저장(연결당 세션)	상태 저장(연결당 세션)	상태 비저장(요청 간 세션 없음)
로드 밸런싱	스티키 세션 필요	스티키 세션 필요	단순 라운드 로빈
스케일링	제한적(클라이언트당 연결)	제한적(클라이언트당 연결)	높음(모든 HTTP 인프라)
인증	연결 시	핸드셰이크 시	요청별(모든 POST에 Bearer)
재개 가능성	없음	없음	없음(하지만 상태 비저장은 재개할 세션이 없음을 의미)
인프라	SSE 인식 프록시 필요	WebSocket 인식 프록시 필요	표준 HTTP(WAF, LB, CDN, 인증 프록시)
보안 표면	세션 ID 도난(CVE-2026-16496)	영구 연결에서 세션 하이재킹	전송 계층에 없음(도난할 세션 없음)
MCP 상태	더 이상 사용 안 함, 12개월 썬셋	사용자 정의 전송(비표준화)	2026-03-26 이후 표준 원격 전송
A2A 상태	스트리밍 모드에 사용	미사용	미사용(A2A는 JSON-RPC over HTTP + SSE 사용)
최적	단순 서버 푸시(A2A 작업 스트리밍)	진정한 양방향(채팅, 협업)	에이전트-도구 호출(MCP)

이 표는 B2B 팀 대부분이 묻는 질문에 답합니다: 에이전트가 원격 MCP 서버의 도구를 호출해야 한다면 Streamable HTTP를 사용하세요. 에이전트가 다른 에이전트에 작업 출력을 스트리밍해야 한다면 A2A의 SSE 스트리밍 모드를 사용하세요. 클라이언트가 서버만큼 자주 메시지를 보내는 실시간 협업 인터페이스를 구축하는 경우라면 WebSocket이 올바른 기본 요소입니다 — 하지만 이는 프로토콜 표준이 아닌 사용자 정의 전송입니다.

비교된 세 가지 전송:

보안 차원 — 왜 상태 비저장이 중요한가

상태 비저장 전송 선택을 검증한 CVE는 CVE-2026-16496, HashiCorp의 Terraform MCP Server에서 CVSS 10.0 인증 바이패스입니다. 이 취약점은 상태 저장 streamable-HTTP 전송 모드에 영향을 미쳤습니다: 다른 사용자의 MCP 세션 ID를 획득한 사용자가 그 사용자의 Terraform 자격 증명으로 도구 호출을 실행할 수 있었습니다. 공격 벡터는 서버가 공격자가 도용하고 재사용할 수 있는 세션 상태를 보유하기 때문에만 존재합니다. 상태 비저장 서버에는 도난할 세션이 없습니다(NVD; The Hacker News).

이것은 상태 저장 전송 모드가 단순한 운영 복잡성이 아닌 보안 책임이라는 프로덕션 증거입니다. SSE의 12개월 더 이상 사용 안 함 윈도우는 이제 단순한 운영 기한이 아닌 보안 기한입니다. 더 이상 사용되지 않는 HTTP+SSE 전송을 여전히 실행하는 1,227개 서버가 가장 영향을 받는 집단이며 — 세션 하이재킹 공격 표면을 안고 있는 집단입니다.

상태 비저장 프로토콜과 서버 측 세션 상태를 대체하는 명시적 핸들 패턴의 더 깊은 처리는 MCP 2026-07-28: B2B 에이전트 배포에서 상태 비저장 프로토콜의 의미를 참조하세요.

A2A가 다른 점 — 그리고 왜 작동하는가

A2A는 Streamable HTTP가 아닌 SSE를 스트리밍에 사용합니다. 차이는 워크로드입니다. MCP 도구 호출은 짧은 요청/응답 작업입니다 — 데이터베이스 쿼리, 레코드 가져오기, 계산 실행. 서버는 요청을 처리하고 결과를 반환합니다. 스트리밍은 선택적이고 드뭅니다. A2A 작업은 명시적 수명 주기 관리를 갖는 장시간 실행 작업입니다 — 2분 걸리는 가격 평가, 1시간 걸리는 컴플라이언스 검사. 스트리밍은 진행 상황 업데이트이지 결과 자체가 아닙니다.

A2A의 SSE 스트리밍은 서버 푸시 전용이며, 작업 진행에 올바른 방향입니다: 작업을 수행하는 에이전트가 호출 에이전트에 업데이트를 보냅니다. 호출 에이전트의 제어 메시지(취소, 업데이트 구독)는 별도의 JSON-RPC 호출을 통해 이루어집니다. 제어 채널이 별도의 표준 HTTP 요청이기 때문에 스트리밍 채널에서 양방향 통신이 필요하지 않습니다(A2A protocol; Google Developers Blog).

이것이 전송 문제가 배관이지 아키텍처가 아닌 이유입니다. MCP와 A2A는 다른 워크로드를 가지기 때문에 다른 전송을 사용하지만, 둘 다 표준 HTTP 위에 구축됩니다. 프로토콜 의미 — MCP의 상태 비저장 도구 호출과 A2A의 상태 저장 작업 수명 주기 — 가 에이전트 통신을 작동시키는 것입니다. 전송은 메시지를 전달하며; 그것은 메시지를 정의하지 않습니다.

완전한 프로토콜 수준 비교(범위, 전송, 인증, 상태, 휴먼인더루프)는 A2A vs MCP: 에이전트 통신을 위한 올바른 프로토콜 선택을 참조하세요.

WebSocket이 올바른 답인 경우

WebSocket은 잘못되지 않았습니다. MCP와 A2A가 표준화하지 않는 특정 워크로드에 대한 올바른 전송입니다:

실시간 협업 인터페이스 — 클라이언트가 서버와 같은 빈도로 메시지를 보내는, 여러 운영자가 같은 에이전트를 동시에 조정하는 공유 에이전트 대시보드.
고빈도 양방향 통신 — 메시지당 HTTP 요청 오버헤드가 금지적인, 같은 채널에서 시장 데이터를 수신하고 주문을 보내는 거래 에이전트.
사용자 정의 MCP 전송 — 표준 전송이 맞지 않는 경우, 사양은 JSON-RPC 메시지 형식과 수명 주기 요구사항을 보존하는 한 사용자 정의 전송을 명시적으로 허용합니다(MCP specification).

트레이드오프는 운영 복잡성입니다. 장수명 양방향 연결 유지는 세션 건강, 재시도, 끊어진 연결, 메시지 프로토콜에 대한 명시적 로직이 필요합니다(Nimble Way). 대부분의 B2B 에이전트 배포 — NetSuite를 호출하는 에이전트, 가격 에이전트에 위임하는 조달 에이전트 — 에서 이 복잡성은 워크로드에 의해 정당화되지 않습니다.

상태 비저장 트렌드

업계 방향은 명확합니다. MCP는 2026년 7월 28일 상태 비저장으로 전환했습니다. A2A는 상태 저장 작업 머신을 사용하지만 전송은 상태 비저장입니다(HTTP + SSE, 서버에 영구 세션 없음). 9월 17일 AGNTCon+MCPCon Europe 세션 — "Stateless: The Future of MCP Transports", Kurtis Van Gent(Google)와 Shaun Smith(Hugging Face, MCP Transport Working Group 유지관리자)가 발표 — 는 상태 비저장 전송 방향에 전념하는 첫 주요 컨퍼런스 세션입니다(Linux Foundation; sched.com).

Shaun Smith는 같은 컨퍼런스에서 키노트도 발표합니다: "Getting to Stateless MCP: In Production" — 이것은 상태 비저장 전송이 사양에서 프로덕션 배포 가이드로 이동하고 있음을 신호합니다. 더 이상 사용되지 않는 SSE 전송을 실행하는 팀에게 12개월 마이그레이션 윈도우(2027년 7월 종료)가 운영 기한입니다. 보안 기한은 더 빠릅니다: 서버가 상태 저장 SSE 전송을 실행하는 매일은 CVE-2026-16496이 악용하는 세션 하이재킹 표면을 안고 있는 매일입니다.

에이전트 통신에서 WebSocket vs SSE 문제는 명확한 답을 가집니다: MCP에 구축하는 경우 둘 다 아닙니다. Streamable HTTP를 사용하세요. A2A 작업 출력을 스트리밍하는 경우 SSE를 사용하세요. 워크로드가 진정으로 양방향이고 운영 복잡성이 정당화되는 경우에만 WebSocket을 사용하세요. 전송은 배관입니다. 프로토콜 의미 — 상태 비저장 도구 호출, 상태 저장 작업 수명 주기, 명시적 핸들, 휴먼인더루프 상태 — 가 에이전트 시스템을 프로덕션에서 작동시키는 것입니다.