오늘도 딸깍딸깍하며 바이브 코딩을 즐기던 중, SSE로 개발되었던 기능에서 문제가 터졌다.
음... 평소 같았으면 그냥 넘겼겠지만, 갑자기 뭔가 오기가 생겼다.
Server-Sent Events
그니까... 가장 기본적이고 원초적인 건, 클라이언트가 서버에 요청을 보내서 데이터를 받는 거다.
이건데, SSE라는 놈은 이걸 연결을 계속 유지시켜 두고 서버에서 클라이언트로 데이터를 보내는 기술이라고 한다.
근데 이게 또 재미있는 게, SSE는 단방향 통신으로만 하는데, 서버에서 클라이언트로만 데이터를 보낼 수 있게 한다고 한다. 재미있네…
뭐 사용처를 생각해보니, 부분적으로 실시간 업데이트를 해야 하는 곳에서 사용하면 좋을 것 같긴 하다.
그리고 HTTP 기반이다.
이건 말 그대로, 클라이언트에서 서버에 요청을 보내고 서버에서 응답을 줄 수 있을 때까지 기다렸다가 응답을 보내고 나면, 클라이언트는 다시 서버에 요청을 보낸다.
별다른 건 아니고 그냥 패턴? 기법 중 하나이다.
이 장점이라고 하면... 일단 테크닉적으로 들어가기 때문에 브라우저나 HTTP의 영향을 크게 받지 않지 않을까 싶다. 대신 주기적으로 계속 보내고 받고를 반복하니 리소스도 많이 먹을 것 같고.
그니까 한번 HTTP 핸드셰이크(handshake)를 하고 나면, 이 WS(WebSocket) 프로토콜로 상호 간 양방향으로 데이터를 주고받을 수 있다는 건데, 이거 참 너무 좋은 것 같다.
Long Polling | SSE | WebSocket | |
---|---|---|---|
통신 방향 | 단방향 (재요청 반복) | 단방향 (서버 → 클라이언트) | 양방향 (클 ↔ 서) |
지연/속도 | 중간~높음 | 낮음 | 매우 낮음 (실시간성 우수) |
연결 유지 | ❌ (반복 연결) | ✅ (지속 연결) | ✅ (지속 연결) |
브라우저 호환 | 매우 좋음 | 대부분 좋음 (IE 제외) | 대부분 좋음 (IE 등 일부 제외) |
전송 방식 | 텍스트 | 텍스트 (text/event-stream ) | 텍스트 + 바이너리 |
주요 사용처 | 레거시 채팅, 단순 알림 | 뉴스피드, 알림, 로그 스트림 | 채팅, 게임, 실시간 협업 |
구현 난이도 | 쉬움 | 쉬움 | 복잡 (상태 관리 필요) |