요약 (TL;DR): SSE와 WebSockets는 취소(cancellation), 에스컬레이션(escalation), 또는 멀티 디바이스 지원 기능이 추가될 때 AI 채팅을 처리하는 방식이 다릅니다. 여기서는 프로덕션 환경에서 각 방식이 언제 유효한지 설명합니다.

WebSockets와 SSE는 모두 AI 채팅 응답을 브라우저로 스트리밍하지만, 취소, 재연결(reconnection), 그리고 디바이스 전환을 처리하는 방식은 매우 다릅니다. 고객 지원 채팅 제품의 경우, 이러한 차이는 고객이 이미 좌절감을 느끼고 있는 순간, 즉 취소 중이거나, 상담원 연결(escalation) 중이거나, 디바이스를 전환하는 도중에 명확히 드러납니다. 이 포스트에서는 각 프로토콜이 무엇을 하는지, 프로덕션 지원 채팅에서 SSE의 제약 사항이 어디에서 나타나는지, 그리고 이들 사이에서 어떻게 선택해야 하는지를 다룹니다.

핵심 요약 (Key takeaways)

• 제어되지 않는 응답을 고객이 취소해야 하거나 상담원에게 연결(escalation)되어야 할 때, SSE의 단방향 연결(one-way connection)은 해당 신호가 중단하려는 응답과는 별도의 요청을 통해 전달되어야 함을 의미합니다. 이는 고객의 신뢰가 가장 취약한 바로 그 순간에 조정의 공백(coordination gap)을 발생시킵니다.
• SSE의 내장된 자동 재연결(auto-reconnect) 기능은 대화가 아닌 연결을 재개합니다. 연결이 끊어진 후 고객은 방금 전까지 가지고 있던 문맥(context)이 아닌 새로운 스트림을 받게 됩니다. 만약 상담원이 환불 조회를 진행 중이었다면, 그 작업은 사라집니다. 고객은 문제를 처음부터 다시 설명해야 하거나, 상담원이 AI가 이미 찾아낸 내용에 대한 기록 없이 수동으로 업무를 이어받아야 합니다.
• 지원 대화를 모바일에서 데스크톱으로 이동하면 SSE 연결은 완전히 끊어집니다. WebSockets로 전환하는 것만으로는 이 문제를 해결할 수 없는데, 세션 상태(session state)가 고객이 아닌 연결에 귀속되어 있기 때문입니다.

WebSockets와 SSE란 무엇인가?

WebSockets와 SSE는 모두 서버가 브라우저로 데이터를 푸시(push)할 수 있게 해줍니다. 두 방식은 AI 채팅에 중요한 거의 모든 기계적 측면에서 차이가 있습니다.

속성 (Property)	WebSockets	SSE
방향 (Direction)	양방향 (Bidirectional): 클라이언트와 서버 모두 동일한 연결에서 데이터를 전송	단방향 (One-way): 서버에서 클라이언트로만 전송
...	...	...

어느 프로토콜도 추상적인 관점에서 무엇이 더 "낫다"고 할 수는 없습니다. WebSockets는 양측 모두가 쓸 수 있는 채널을 제공합니다. SSE는 스스로 재연결되는 더 단순한 단방향 스트림 (stream)을 제공합니다.

계산의 기준을 바꾸는 것은, 당신의 AI 채팅 제품이 실제 고객들 앞에서 작동하기 시작했을 때 무엇을 수행해야 하는가입니다.

프로덕션 AI 채팅에서 WebSockets vs SSE 선택이 중요한 이유

프로토타입 AI 채팅 기능은 이러한 선택의 차이를 드러내는 사례들을 거의 테스트하지 않습니다. 단일 사용자가 메시지를 보내고, 응답을 기다린 뒤, 탭을 닫는 식입니다.

프로덕션 환경의 고객 지원 채팅은 이와 전혀 다릅니다. 고객은 잘못된 방향으로 흘러가는 응답을 취소합니다. 대화 도중에 상담원(human)에게 연결(escalation)되기도 합니다. 또한 고객은 문제를 해결하는 도중에 모바일 앱에서 데스크톱 브라우저로 전환하며, 대화 내용이 그대로 남아 있기를 기대합니다.

이 각각의 사례는 단순한 스트리밍 (streaming) 문제가 아니라, 조정 (coordination) 문제입니다.

• 취소 신호 (cancellation signal)가 AI 에이전트에게 전달되어야 합니다.
• 에스컬레이션된 문맥 (escalation context)이 이를 인계받는 상담원에게 전달되어야 합니다.
• 대화 상태 (conversation state)가 고객이 다음에 여는 어떤 기기에서도 사용 가능해야 합니다.

이 모든 과정은 서버에서 클라이언트로 토큰 (tokens)을 푸시하는 것 이상의 것을 요구합니다. 전송 (transport) 방식의 선택은 이러한 조정 작업 중 얼마만큼이 자동으로 해결될지를 결정합니다.

이 선택을 잘못했을 때의 비용은 추상적이지 않습니다. AI가 이미 파악한 내용에 대한 기록 없이 에스컬레이션된 대화를 전달받은 상담원은 처음부터 다시 시작해야 하며, 고객은 이를 즉시 알아차립니다.

응답 생성을 중단할 수 없는 고객은 인터페이스에 대한 신뢰를 빠르게 잃습니다. 아무런 데이터도 불러오지 못하고 재연결된 고객은 이전보다 더 큰 마찰 (friction)을 겪으며 대화를 이어가야 합니다.

실제 AI 채팅 조건에서 SSE가 무너지는 방식

SSE는 클라이언트에서 서버로의 신호 전달 (signaling)이 필요하지 않은, 단일 응답을 스트리밍하는 챗봇에게는 방어 가능한 선택지입니다. 하지만 고객 지원 AI 채팅은 그 이상의 연결 성능을 요구합니다. 다음은 그 격차가 드러나는 구체적인 지점들입니다.

스트림 중간에 응답을 취소하거나 중단하는 경우

SSE는 스트림이 활성화되어 있는 동안 클라이언트가 무언가를 다시 보낼 수 있는 채널이 없습니다. 만약 고객이 궤도를 벗어난 응답을 중단하고 싶다면, 애플리케이션은 취소를 신호하기 위해 별도의 HTTP 요청을 열어야 합니다.

이 별도의 요청은 응답을 생성 중인 동일한 백엔드 프로세스에 도달해야 합니다. 또한 진행 중인(in-flight) 올바른 생성 작업과 매칭되어야 하며, 해당 생성을 깔끔하게 중단시켜야 합니다. 이러한 조정 기능은 SSE 자체에서 제공되지 않습니다.

이를 직접 구현하면 단일 양방향 채널(bidirectional channel)에서는 발생하지 않는 종류의 버그들이 나타납니다. 예를 들어, 스트림이 이미 종료된 후에 도착하는 취소 요청이나, 아예 잘못된 생성 작업을 대상으로 하는 취소 요청 등이 발생할 수 있습니다.

대화 도중 AI에서 상담원(human agent)으로 전환하는 경우

AI 에이전트로부터 상담원에게 대화를 넘겨주는 것은 고객 지원 채팅에서 가장 흔한 흐름 중 하나입니다. 이는 대화를 받는 상담원이 고객이 무엇을 물었는지, AI가 이미 무엇을 시도했는지, 그리고 어디에서 막혔는지와 같은 전체 문맥 (context)을 즉시 파악할 수 있는지에 달려 있습니다.

SSE의 단방향 설계는 이러한 핸드오프 (handoff)가 일어날 수 있는 자연스러운 공간을 제공하지 않습니다. 문맥은 대화가 이미 실행 중인 전송 계층 (transport)에서 자연스럽게 흘러나오는 것이 아니라, 이 흐름을 위해 특별히 구축된 별도의 메커니즘을 통해 조립되고 전달되어야 합니다.

기기를 넘나들며 대화를 이어가는 경우

출퇴근 중에 휴대폰으로 지원 대화를 시작한 고객은 나중에 노트북을 집어 들었을 때 대화가 정확히 멈췄던 지점에서 이어지기를 기대합니다. 하지만 SSE 연결은 해당 연결을 연 브라우저 탭에 종속되어 있습니다.

동일한 대화를 두 번째 기기에서 열면 첫 번째 연결과는 아무런 관계가 없는 완전히 별개의 SSE 연결이 시작됩니다. 세션 상태(Session state)는 전송 계층(Transport layer) 이외의 다른 요소로부터 재구성되어야 합니다.

엔터프라이즈 프록시(Enterprise proxy) 및 방화벽 동작

이 부분은 SSE가 진정으로 지속적인 우위를 점하는 유일한 영역입니다. SSE는 표준 HTTP 연결을 통해 실행되므로, 특별한 설정 없이도 대부분의 엔터프라이즈 프록시와 기업용 방화벽을 통과할 수 있습니다.

WebSockets는 HTTP 업그레이드 핸드셰이크(HTTP upgrade handshake)에 의존하며, 일부 패킷 검사 방화벽(Packet-inspecting firewalls)은 이 핸드셰이크를 깔끔하게 처리하지 못할 수 있습니다. 이는 기업 네트워크에서 연결이 소리 없이 실패하는 원인이 될 수 있습니다.

만약 귀하의 고객 지원 제품이 보안이 엄격한 엔터프라이즈 네트워크를 사용하는 B2B 고객을 대상으로 한다면, 이는 반드시 고려해야 할 실제적인 제약 사항입니다. 그렇다고 해서 WebSockets를 무조건 배제해야 한다는 뜻은 아닙니다. 이러한 실패 모드는 WebSockets를 완전히 피하기보다는 프로토콜 폴백(Protocol fallback)을 통해 해결할 수 있는 문제입니다.

AI 채팅을 위한 WebSockets와 SSE 사이의 선택 방법

SSE

적합한 경우:

• AI 채팅이 단발성(Single-turn)이거나 수명이 짧은 경우
• 응답이 시작된 후 고객이 다시 무언가를 보낼 필요가 없는 경우
• 상담원 연결(Escalation-to-human) 흐름이나 기기 전환 요구사항이 없는 경우

단순한 FAQ 봇은 이 프로필에 잘 부합하며, 엔터프라이즈 네트워크에서 SSE가 보여주는 HTTP 네이티브(HTTP-native) 동작은 SSE의 확실한 장점입니다.

부적합한 경우:

• 고객이 스트리밍 중간에 응답을 취소해야 하는 경우
• 대화 도중에 상담원에게 연결(Escalation)되는 경우
• 고객이 기기를 넘나들며 대화가 계속되기를 기대하는 경우

이러한 각 상황은 양방향 연결(Bidirectional connection)이 기본적으로 제공하는 기능을 SSE 상단에 별도의 조정 로직(Coordination logic)으로 직접 구축해야 함을 의미합니다.

WebSockets

적합한 경우:

• 제품에 취소, 상담원 연결, 또는 멀티 디바이스 조정 기능이 필요한 경우
• 단일 양방향 연결이 각 기능마다 별도의 사이드 채널(Side-channel)을 만들지 않고도 이 모든 신호를 전달할 수 있는 경우

이는 에스컬레이션(Escalation)과 중단(Interruption)이 예외적인 상황이 아닌 핵심 흐름인 대부분의 프로덕션(Production) 고객 지원 AI 채팅 환경과 일치합니다.

문제가 발생하는 경우:

• 엄격한 패킷 검사(Packet inspection)를 수행하는 네트워크에서는 업그레이드 핸드셰이크(Upgrade handshake)가 실패할 수 있으므로, 엔터프라이즈 프록시(Enterprise proxy) 동작을 고려하지 않은 경우
• SSE와 달리 WebSocket은 자동으로 재연결되지 않으므로, 재연결 로직(Reconnection logic)을 구축하지 않은 경우

두 가지 모두 해결 가능하지만, 순수한 WebSocket 연결만으로는 저절로 해결되지 않습니다.

WebSocket을 채택하면 양방향 시그널링(Bidirectional signaling) 문제는 해결됩니다. 하지만 WebSocket 자체가 세션 연속성(Session continuity)을 해결해주지는 않습니다. 재연결된 WebSocket은 새로운 연결이며, 추가적인 세션 레이어(Session layer) 없이는 이전 연결에 종속되었던 대화 상태(Conversation state)가 여전히 유실됩니다.

Ably AI Transport가 WebSocket 위에 내구성이 있는 세션을 추가하는 방법

내구성이 있는 세션(Durable session)은 대화 상태를 단일 연결이 아닌 대화 자체에 결합하여 유지합니다. 재연결, 기기 전환, 또는 사람으로의 핸드오프(Handoff)가 발생해도 문맥(Context)을 잃지 않습니다. WebSocket만으로는 양방향 채널을 제공할 뿐이며, 세션 상태는 여전히 어딘가에 존재해야 하므로 대부분의 팀은 결국 이 레이어를 직접 구축하게 됩니다.

Ably AI Transport는 이러한 아이디어를 기반으로 구축되었습니다. 세션은 하위 연결보다 더 오래 지속됩니다. 즉, 재연결, 멀티 디바이스 전달, 취소 등은 별도로 구축해야 하는 기능이 아니라 세션이 작동하는 방식의 속성입니다. 연결이 끊긴 후 재연결된 클라이언트는 중단된 지점부터 다시 시작하며, 고객이 여는 어떤 기기든 진행 중인 동일한 세션에 참여하게 됩니다.

여기에는 실제적인 트레이드오프(Tradeoff)가 따릅니다. Ably AI Transport는 새로운 의존성(Dependency)이며, 서버와 클라이언트 간의 직접적인 연결 대신 Ably의 인프라를 통해 작동합니다.

이미 Ably에서 다른 실시간(Realtime) 기능을 운영 중인 팀에게 이는 자연스러운 확장입니다. Ably를 사용하고 있지 않은 팀에게는 당연한 선택이 아니라, 직접 구축할 것인지(Build) 아니면 도입할 것인지(Adopt)에 대한 진정한 결정의 문제입니다.

세션 레이어(Session layer)가 어떻게 작동하는지에 대한 자세한 내용은 Docs go deeper에서 확인할 수 있습니다.

FAQ

AI 채팅에 SSE가 적절한 선택이 될 수 있나요?
네. 만약 사용 중인 AI 채팅에 취소(Cancellation), 에스컬레이션(Escalation), 또는 멀티 디바이스(Multi-device) 요구 사항이 없다면(예: 단순한 단일 턴 어시스턴트), SSE의 단순함과 HTTP 네이티브 방화벽 동작 특성 덕분에 합리적인 시작점이 될 수 있습니다.

AI 스트리밍에서 WebSockets가 해결할 수 있는 문제 중 SSE가 지원하지 못하는 것은 무엇인가요?
SSE는 동일한 연결 내에서 클라이언트에서 서버로 신호를 전달할 수 없습니다. 취소(Cancellation), 라이브 스티어링(Live steering), 그리고 스트리밍 중간의 모든 클라이언트 입력은 별도의 메커니즘이 필요합니다. WebSockets는 하나의 연결에서 양방향을 모두 전달함으로써 이 문제를 해결하지만, 재연결(Reconnection) 및 멀티 디바이스 연속성을 해결하기 위해서는 여전히 추가적인 세션 레이어(Session layer)가 필요합니다.

왜 SSE는 스트림 취소(Stream cancellation)를 신뢰할 수 없게 만드나요?
SSE는 서버에서 클라이언트로 데이터만 전달합니다. 응답을 취소하려면 스트림 자체 외부에서 별도의 HTTP 요청이 필요하며, 이 요청은 백엔드에서 진행 중인 올바른 생성(Generation) 작업과 매칭되어야 합니다. 이러한 조정(Coordination)은 프로토콜의 일부가 아니며 애플리케이션에서 직접 구축해야 합니다.

WebSocket 기반의 AI 채팅이 엔터프라이즈 프록시(Enterprise proxies) 및 기업용 VPN 뒤에서도 작동하나요?
기본적으로 항상 작동하는 것은 아닙니다. WebSocket 업그레이드 핸드셰이크(Upgrade handshake)는 패킷 검사(Packet inspection)를 수행하는 방화벽에 의해 차단될 수 있으며, 이는 소비자용 네트워크보다 기업용 네트워크에서 더 흔하게 발생합니다. WebSocket을 먼저 시도하고 HTTP 스트리밍으로 폴백(Fallback)하는 프로토콜 폴백(Protocol fallback) 방식은, WebSocket의 다른 기능을 포기하지 않으면서도 이 문제를 해결합니다.

SSE에서 WebSockets로 전환하는 것만으로 세션 연속성(Session continuity) 문제가 해결될까요?

아니요. WebSockets는 취소(Cancellation)와 중단(Interruption) 신호가 동일한 연결을 통해 전달될 수 있으므로 양방향 시그널링(Bidirectional signaling) 문제를 해결합니다. 하지만 재연결된 WebSocket은 여전히 새로운 연결이며, 별도의 세션 레이어(Session layer)가 없다면 대화 상태(Conversation state)는 재연결이나 기기 전환 시 자동으로 유지되지 않습니다.

다른 곳에서는 프로덕션 AI 채팅의 휴먼 핸드오프(Human handoff)를 어떻게 처리하고 있는지 궁금합니다. 사이드 채널(Side-channel)을 병행하는 SSE 방식을 사용하나요, 아니면 처음부터 양방향 전송(Bidirectional transport) 방식을 사용하나요?

원문은 Ably 블로그에 게시되었습니다.