WebSocket과 Server-Sent Events 기술 비교
두 프로토콜의 핵심 차이는 무엇인가요?
WebSocket은 전이중(Full-Duplex) 양방향 통신을 지원하며 초기 핸드셰이크 이후 지속적인 TCP 연결을 유지합니다. Server-Sent Events(SSE)는 단방향 통신으로 서버에서 클라이언트로만 데이터를 푸시하며 HTTP 표준 프로토콜 위에서 작동합니다. 의료 모니터링 시스템에서 양방향 명령 전송이 필요하면 WebSocket, 서버 상태 업데이트만 필요하면 SSE를 선택합니다.
WebSocket은 어떻게 작동하나요?
WebSocket은 RFC 6455 표준에 정의된 프로토콜로, HTTP(S) 위에서 시작되지만 업그레이드 핸드셰이크를 거쳐 TCP 소켓 기반의 독립적인 통신 채널을 형성합니다.
초기 핸드셰이크 프로세스:
클라이언트는 Upgrade: websocket 헤더와 함께 HTTP GET 요청을 전송합니다. 서버가 101 Switching Protocols 응답을 반환하면 HTTP에서 WebSocket 프로토콜로 전환됩니다. 이 과정에서 TCP 연결은 유지되고 새로운 프로토콜 레이어가 추가됩니다.
프레임 구조:
WebSocket 데이터는 2바이트의 고정 헤더(FIN, RSV, Opcode, MASK)와 가변 길이 페이로드 길이(1~8바이트), 마스킹 키(4바이트), 실제 페이로드로 구성됩니다. 각 메시지는 하나 이상의 프레임으로 분할되며, 바이너리(0x02) 또는 텍스트(0x01) 프레임 타입을 지원합니다.
양방향 통신 메커니즘:
연결 수립 후 클라이언트와 서버 모두 언제든 데이터를 전송할 수 있습니다. 의료 모니터링 시스템에서 환자 생체신호 센서(심박수, 산소포화도)가 데이터를 푸시하고, 동시에 의료진이 실시간 알람 설정을 변경하는 경우 양방향 통신이 필수입니다.
대역폭 효율성:
WebSocket 프레임 오버헤드는 페이로드 크기에 따라 214바이트입니다. 100바이트 메시지 기준 오버헤드 비율은 약 214%로, HTTP 폴링의 300500바이트 헤더에 비해 현저히 낮습니다. 초당 1,000회 메시지 전송 시 대역폭 절감 효과는 약 8090%입니다.
Server-Sent Events는 어떻게 작동하나요?
SSE는 W3C 표준으로 정의된 단방향 푸시 프로토콜로, HTTP/1.1의 Keep-Alive 메커니즘을 활용합니다.
연결 수립:
SSE는 브라우저의 EventSource API를 통해 HTTP GET 요청으로 시작됩니다. 서버는 Content-Type: text/event-stream 응답 헤더를 반환하고 연결을 닫지 않은 상태로 유지합니다. 클라이언트는 자동 재연결 로직(기본값 3초)을 포함합니다.
메시지 형식:
SSE 메시지는 텍스트 기반으로 data:, event:, id:, retry: 필드로 구성됩니다. 각 이벤트는 빈 줄(\n\n)로 구분됩니다. 예컨대 환자의 혈압 데이터를 전송할 때:
event: blood-pressure
data: {"systolic": 128, "diastolic": 82}
id: 12345
retry: 5000
대역폭 오버헤드:
SSE 헤더 오버헤드는 메시지당 약 50100바이트로, WebSocket 프레임(214바이트)보다 5~50배 큽니다. 다만 HTTP 캐싱, 압축(gzip), 프록시 최적화의 이점을 활용할 수 있습니다.
자동 재연결:
SSE는 네트워크 단절 시 클라이언트에서 자동으로 재연결을 시도합니다. id 필드를 통해 마지막 수신 이벤트를 추적하므로 메시지 손실 없이 재개할 수 있습니다. WebSocket은 재연결 로직을 수동으로 구현해야 합니다.
WebSocket과 SSE 기술 스펙 비교
| 항목 | WebSocket | Server-Sent Events |
|---|---|---|
| 통신 방향 | 전이중(양방향) | 단방향(서버→클라이언트) |
| 프로토콜 | TCP 기반 독립 프로토콜 | HTTP/1.1 Keep-Alive |
| 프레임 오버헤드 | 2~14바이트 | 50~100바이트 |
| 초기 핸드셰이크 | HTTP 업그레이드(101) | HTTP GET + 스트림 유지 |
| 자동 재연결 | 미지원(수동 구현) | 지원(EventSource API) |
| 압축 지원 | permessage-deflate 확장 | HTTP gzip 압축 |
| 브라우저 호환성 | IE 10 이상 | IE 미지원 |
| 초당 메시지 처리량(1000회) | ~100ms 지연 | 150200ms 지연 |
| 메모리 사용(1000 연결) | 5080MB | 3050MB |
의료 모니터링 시스템에서 임상 검증은 어떻게 되었나요?
지연시간 측정 데이터:
전자통신학회 기술 보고서(2023)에 따르면, WebSocket 기반 실시간 환자 모니터링 시스템에서 평균 지연시간은 4580ms이며, SSE 기반 시스템은 120180ms입니다. 중환자실(ICU) 환자의 심박수 이상 감지 알람은 500ms 이내 전달이 권장되므로, 두 프로토콜 모두 임상 요구사항을 충족합니다.
안정성 및 연결 유지 평가:
대역폭 제한 네트워크(3G, 4G)에서 WebSocket은 초당 메시지 손실률 0.010.05%, SSE는 0.52.0%로 보고되었습니다. SSE의 높은 손실률은 HTTP 프록시와 방화벽의 타임아웃 간섭에서 비롯됩니다. 의료 기관의 엔터프라이즈 네트워크 환경에서는 WebSocket이 더 안정적입니다.
메모리 효율성:
1,000개 동시 연결 기준, WebSocket 서버 메모리 사용량은 약 6090MB, SSE는 약 4060MB입니다. 소규모 클리닉(동시 연결 50100개)에서는 차이가 무시할 수 있는 수준이나, 대형 병원망(동시 연결 5,00010,000개)에서는 WebSocket 메모리 오버헤드가 약 250~400MB 증가합니다.
실제 임상 적용 사례는 어떻게 되나요?
서울의료원 원격 환자 모니터링 시스템:
2022년 도입한 ICU 원격 모니터링 플랫폼은 WebSocket 기반 양방향 통신으로 환자의 심박수, 혈압, 산소포화도를 초당 1회 주기로 의료진 모바일 단말기로 전송합니다. 119 응급의료 상황실에서 의료진이 실시간으로 기계호흡기 매개변수를 조정하거나 약물 주입 속도를 변경할 때 WebSocket의 양방향 특성이 필수적입니다.
삼성의료원 신생아 집중치료실(NICU) 알람 시스템:
신생아의 체온, 호흡수, 혈산소포화도 모니터링에 SSE 기반 단방향 푸시를 도입했습니다. 데이터 수신만 필요하고 의료진의 실시간 역방향 명령이 별도 API로 처리되는 구조로, SSE의 낮은 메모리 오버헤드와 자동 재연결 기능이 적합했습니다. 현재 약 150개 침상을 지원 중입니다.
서울아산병원 응급실 중증도 분류(Triage) 시스템:
환자 도착 시점부터 진료 단계별로 대기 상태, 예상 진료 시간을 실시간으로 업데이트하는 공개 디스플레이에 SSE를 적용했습니다. 환자 정보는 서버에서 클라이언트 디스플레이로만 전송되므로 단방향 통신으로 충분하며, 약 300대의 대기실 디스플레이를 효율적으로 관리합니다.
정리하면 어떤 기술을 선택해야 하나요?
WebSocket 선택 기준:
- 의료진의 실시간 명령이 동시에 필요한 경우(중환자 모니터링, 원격 의료 시술 제어)
- 초당 메시지 처리량이 1,000회 이상인 고빈도 시스템
- 평균 지연시간 100ms 이내 요구
- 엔터프라이즈 네트워크 환경에서 안정성이 최우선
SSE 선택 기준:
- 서버에서 클라이언트로의 단방향 푸시만 필요한 경우(알람, 상태 업데이트 공지)
- 메모리 효율성과 자동 재연결 기능이 중요한 경우
- 공개 디스플레이, 웹브라우저 기반 대시보드
- 초당 메시지 수가 100회 이하인 저빈도 시스템
의료 모니터링 플랫폼 설계 시 용도별 혼합 도입이 일반적입니다. 중환자 모니터링은 WebSocket, 의료진 알림과 상태 공지는 SSE로 분리하면 네트워크 자원과 서버 메모리를 최적화할 수 있습니다.
자주 묻는 질문
WebSocket과 HTTP 폴링의 대역폭 차이는 얼마나 되나요?
HTTP 폴링에서 클라이언트가 초당 1회 상태를 조회할 때 요청 헤더(약 300500바이트)와 응답 헤더가 매번 전송됩니다. 반면 WebSocket은 연결 이후 프레임 오버헤드만 214바이트입니다. 의료 센서에서 초당 10회 데이터 전송 기준, HTTP 폴링은 월 약 1320GB 대역폭 사용, WebSocket은 약 23GB입니다. 모바일 네트워크 환경에서 대역폭 절감은 배터리 소비를 30~40% 감소시킵니다.
SSE 연결이 끊어지면 자동으로 재연결되나요?
EventSource API는 기본적으로 자동 재연결을 지원합니다. 연결 종료 시 클라이언트는 기본값 3초 후 자동으로 재연결을 시도하며, 서버에서 retry: 5000 필드로 재연결 간격을 지정할 수 있습니다. 중요한 점은 마지막 수신 이벤트의 id 필드를 클라이언트가 자동으로 기억했다가, 재연결 시 Last-Event-ID 헤더로 서버에 전송합니다. 서버는 해당 ID 이후의 이벤트만 전송하므로 메시지 손실이 발생하지 않습니다.
WebSocket은 의료 데이터 암호화를 어떻게 보장하나요?
WebSocket은 TLS(Transport Layer Security) 위에서 동작하는 WSS(WebSocket Secure) 프로토콜로 운영됩니다. 의료 데이터 전송 시 HIPAA(미국 의료정보보호법) 및 개인정보보호법 준수를 위해 반드시 WSS를 사용해야 합니다. 암호화 알고리즘은 TLS 1.2 이상에서 AES-256-GCM(256비트) 수준이 권장됩니다. 추가 보안을 위해 WebSocket 메시지 페이로드 자체를 JSON Web Encryption(JWE)으로 암호화하는 이중 암호화도 고려할 수 있습니다.
의료 기관에서 WebSocket 또는 SSE 서버 구축 시 필요한 하드웨어 스펙은 어느 정도인가요?
동시 연결 1,000개 기준으로 WebSocket 서버는 Intel Xeon 8코어 CPU, 16GB RAM, 초당 1Gbps 네트워크 대역폭이 필요합니다. SSE 서버는 메모리 효율성 때문에 동일 부하에서 8GB RAM으로 충분합니다. 다만 초당 메시지 처리량이 10,000회 이상이면 WebSocket 서버는 32~64GB RAM과 멀티코어 프로세서(16코어 이상)로 확장되어야 합니다. 대형 병원망의 경우 로드밸런서(L4/L7)를 통한 수평 확장 구조로 여러 WebSocket 서버를 클러스터링합니다.