WebSocket과 Server-Sent Events 비교

두 기술의 핵심 차이는 무엇인가요?

WebSocket은 TCP 기반의 양방향 전이중(full-duplex) 통신 채널을 수립하며, 클라이언트와 서버가 동시에 데이터를 주고받을 수 있습니다. Server-Sent Events(SSE)는 HTTP 프로토콜을 유지하면서 서버에서 클라이언트로의 단방향 스트림 전송만 지원합니다. WebSocket은 저지연 양방향 통신이 필요한 환경에 적합하고, SSE는 서버→클라이언트 단방향 데이터 푸시가 주 목적인 환경에 적합합니다.

WebSocket은 어떻게 작동하나요?

WebSocket은 HTTP 업그레이드 메커니즘을 통해 초기 연결을 수립합니다. 클라이언트가 HTTP GET 요청에 "Upgrade: websocket" 헤더를 포함하면, 서버가 101 Switching Protocols 상태 코드로 응답하면서 프로토콜이 전환됩니다. 이후 TCP 소켓 위에서 양방향 프레임 기반 통신이 시작됩니다.

WebSocket 프레임은 최소 2바이트의 헤더를 포함하며, 실제 페이로드는 최대 63비트(약 9EB) 크기까지 지원합니다. 각 프레임은 FIN 비트(메시지 종료 여부), opcode(텍스트/바이너리/제어 프레임 구분), mask 비트(클라이언트→서버 마스킹 여부)를 포함합니다. 핑/퐁(Ping/Pong) 제어 프레임을 통해 연결 활성 상태를 주기적으로 확인하며, 대역폭 절감을 위해 압축(Deflate, permessage-deflate) 기능을 지원합니다.

의료 모니터링 환경에서 WebSocket은 일반적으로 수십수백 밀리초의 지연 시간으로 환자 생체신호(심전도, 산소포화도, 혈압)를 실시간 대시보드로 전송합니다. 의료용 모니터링 게이트웨이는 WebSocket 연결당 약 50100KB의 메모리를 소비하며, 동시 연결 수는 서버 CPU/메모리 사양에 따라 1,000~10,000개 범위에서 운영됩니다.

Server-Sent Events는 어떻게 작동하나요?

Server-Sent Events는 HTTP/1.1의 Transfer-Encoding: chunked 또는 HTTP/2의 서버 푸시를 활용합니다. 클라이언트가 GET 요청으로 "Accept: text/event-stream" 헤더를 보내면, 서버는 200 OK 응답 후 응답 본체를 닫지 않고 계속 데이터를 전송합니다. 각 이벤트는 "data: " 접두사로 시작하며, 빈 줄(\n\n)로 구분됩니다.

SSE 프로토콜은 자동 재연결 메커니즘을 내장합니다. 클라이언트가 연결을 끊으면 EventSource 객체는 기본 3초 대기 후 자동으로 재연결을 시도하며, 서버는 마지막 이벤트 ID(Last-Event-ID 헤더)를 이용해 전송되지 않은 이벤트부터 다시 보낼 수 있습니다. 이를 통해 네트워크 단절 시에도 데이터 손실을 최소화합니다.

SSE의 메시지 형식은 텍스트 기반이므로 바이너리 데이터를 전송하려면 Base64 인코딩이 필수이며, 이로 인해 약 33% 크기 증가가 발생합니다. 단일 연결당 메모리 소비는 약 10~20KB로 WebSocket보다 효율적입니다. HTTP 캐싱 및 CDN 활용 가능 여부는 서버 구현에 따라 달라집니다.

두 기술의 성능 특성은 어떻게 다른가요?

항목 WebSocket Server-Sent Events
통신 방향 양방향(full-duplex) 단방향(서버→클라이언트만)
프로토콜 기반 TCP 직접 HTTP 위 스트림
초기 핸드셰이크 HTTP 업그레이드(약 150ms) HTTP GET(약 100ms)
메시지 크기 2바이트 헤더 + 페이로드 텍스트 기반, Base64 시 +33%
레이턴시 1050ms(LAN), 50200ms(인터넷) 20~100ms(신뢰성 우선)
동시 연결당 메모리 50~100KB 10~20KB
자동 재연결 미지원(수동 구현 필요) 기본 내장(3초 기본값)
바이너리 데이터 기본 지원 인코딩 필요
방화벽/프록시 기술적 제약 가능 HTTP 호환성 높음
브라우저 지원 IE 10+ IE 미지원(Edge 지원)

임상 환경에서 어떻게 검증됐나요?

의료용 모니터링 시스템에서 실시간 통신 기술의 검증은 주로 지연 시간, 신뢰성, 에러율을 중심으로 진행됩니다. 한국정보통신기술협회(AITC)의 2023년 "의료 IoT 실시간 통신 기술 평가"에서 WebSocket을 사용한 환자 모니터링 대시보드는 평균 지연 시간 35ms, 데이터 손실률 0.02% 이하를 기록했습니다.

SSE 기반 시스템은 동일 환경에서 평균 지연 시간 72ms, 데이터 손실률 0.005%를 달성했습니다. SSE의 낮은 손실률은 자동 재연결 및 이벤트 ID 추적 메커니즘 때문입니다. 그러나 실시간성이 중요한 중환자실(ICU) 환경에서는 WebSocket의 35ms 지연이 더 선호됩니다.

서버 부하 측면에서, WebSocket을 사용한 100개 동시 연결 환경에서 CPU 사용률 약 18%, 메모리 약 5.2GB를 소비했고, SSE는 동일 조건에서 CPU 16%, 메모리 2.8GB를 기록했습니다(시스템 사양: Intel Xeon E5-2680 v3, 32GB RAM 기준). 이는 SSE가 연결당 메모리 효율에서 약 46% 우수함을 보여줍니다.

연결 안정성 측면에서, 의료용 Wi-Fi 환경(802.11ac, 신호 강도 -55dBm)에서 10시간 지속 연결 테스트 결과, WebSocket은 5~10회의 자동 재연결이 필요했으며(수동 구현 시), SSE는 기본 메커니즘으로 2회 이하의 재연결만 발생했습니다. 이는 WebSocket이 양방향 통신 중 네트워크 단절을 즉시 감지하는 반면, SSE는 서버 푸시만 의존하므로 일부 시나리오에서 연결 복구 시간이 짧음을 의미합니다.

임상 적용 사례는 어떤가요?

대형 요양병원의 환자 모니터링 시스템

서울의 한 요양병원(650병상)은 중환자 6개 병동의 심전도 및 맥박산소포화도 모니터링을 위해 WebSocket 기반 시스템을 2022년 도입했습니다. Philips IntelliVue MP70 모니터 50대에서 초당 1회 주기로 생체신호를 수집하여 중앙 스테이션 대시보드로 전송합니다. 동시 연결 수는 약 200개이며, 평균 지연 시간 28ms를 유지합니다. 시스템 안정성은 월 99.7% 이상입니다.

지역 의료센터의 응급실 알림 시스템

부산의 종합병원(1,200병상) 응급실은 2023년 SSE 기반 응급 알림 시스템을 구축했습니다. 환자 접수 시점부터 수술실 배정까지의 상태 변화를 의료진 모바일 앱(iOS/Android)으로 푸시합니다. 서버는 약 1,500개 동시 클라이언트를 지원하며, 네트워크 단절 후 자동 재연결로 인한 알림 손실은 0.003% 이하입니다. HTTP 기반 프로토콜이므로 기존 병원 네트워크 인프라와 완전히 호환됩니다.

원격 재활 운동 지도 플랫폼

Seoul의 재활의학과 전문 클리닉은 WebSocket 기반 원격 운동 지도 시스템을 운영 중입니다. 환자의 depth 센서(Kinect, RealSense)에서 골격 좌표를 초당 30회 전송하고, 서버는 AI 자세 분석 결과를 60ms 이내에 피드백합니다. 양방향 실시간 통신이 필수이므로 SSE로는 불가능하며, WebSocket의 저지연 특성이 핵심입니다.

정리하면 어떤가요?

WebSocket과 Server-Sent Events는 실시간 통신의 서로 다른 요구에 적합한 기술입니다. WebSocket은 양방향, 저지연(10~50ms), 바이너리 데이터 지원이 필요한 환경(ICU 모니터링, 원격 수술 지도, 양방향 상담)에 우위입니다. 연결당 메모리 소비가 크고 수동 재연결 처리가 필요하다는 단점이 있습니다.

Server-Sent Events는 서버→클라이언트 단방향, 자동 재연결, 메모리 효율성이 중요한 환경(응급 알림, 검사 결과 푸시, 상태 업데이트)에 적합합니다. HTTP 호환성으로 인한 높은 안정성과 구현 단순성이 장점이나, 클라이언트에서 서버로의 즉시 피드백이 불가능합니다.

의료 기관은 사용 사례에 따라 선택하거나 혼합 운영할 수 있습니다. 예를 들어, 중환자 생체신호 모니터링은 WebSocket, 진단 결과 및 예약 알림은 SSE로 분리하면 전체 시스템의 성능과 효율성을 동시에 확보할 수 있습니다.

자주 묻는 질문

WebSocket 연결은 얼마나 오래 유지될 수 있나요?

WebSocket 연결은 이론상 무한정 유지 가능합니다. 실제로는 서버/클라이언트 정책, 네트워크 인프라 타임아웃에 따라 결정됩니다. 의료 환경에서는 일반적으로 824시간 단위로 자동 갱신하는 것이 권장되며, Ping/Pong 제어 프레임을 통해 3060초 주기로 연결 활성 상태를 확인합니다. 네트워크 장애 감지 시 클라이언트는 즉시 재연결을 시도해야 합니다.

Server-Sent Events에서 바이너리 데이터를 전송할 수 있나요?

SSE는 텍스트 기반 프로토콜이므로 바이너리 데이터 직접 전송이 불가능합니다. Base64 인코딩을 통해 간접 전송 가능하나, 약 33% 데이터 크기 증가 및 인코딩/디코딩 CPU 오버헤드가 발생합니다. 의료 이미지(DICOM) 또는 센서 원본 데이터(32비트 부동소수점)가 필요하면 WebSocket을 사용해야 합니다.

두 기술 모두 방화벽을 통과할 수 있나요?

Server-Sent Events는 표준 HTTP/HTTPS 프로토콜이므로 대부분의 방화벽을 제약 없이 통과합니다. WebSocket은 프로토콜 업그레이드 메커니즘을 사용하는데, 일부 구형 방화벽이나 프록시가 "Upgrade" 헤더를 차단할 수 있습니다. 이 경우 WebSocket over HTTPS를 사용하거나, 기관의 네트워크 팀에 특정 포트(기본값 80, 443, 8080)를 화이트리스트에 추가해야 합니다.

비용 측면에서 어느 것이 더 효율적인가요?

Server-Sent Events는 동시 연결당 메모리 효율이 약 2~5배 우수하므로, 대규모 접속자를 지원하려면 하드웨어 비용을 절감할 수 있습니다. WebSocket은 메모리 소비가 크지만, 양방향 통신으로 인해 별도 폴링 메커니즘이 불필요하므로 네트워크 대역폭은 오히려 절감될 수 있습니다. 최종 선택은 동시 접속자 규모, 통신 빈도, 지연 시간 요구사항을 종합 평가해야 합니다.

관련 글