WebSocket과 Server-Sent Events(SSE)의 차이를 설명해주세요.

WebSocket은 하나의 연결에서 클라이언트와 서버가 양방향으로 메시지를 주고받는 프로토콜이고, SSE(Server-Sent Events)는 서버가 클라이언트로 이벤트 스트림을 단방향 전송하는 HTTP 기반 기술입니다. 실시간성이 필요하더라도 양방향인지 단방향인지에 따라 선택이 달라집니다.

핵심 개념

• WebSocket은 채팅, 협업 편집, 게임처럼 클라이언트도 자주 메시지를 보내야 할 때 적합합니다.
• SSE는 알림, 로그 스트리밍, 진행률 업데이트처럼 서버 → 클라이언트 흐름이 중심일 때 단순합니다.
• SSE는 일반 HTTP와 잘 맞고 자동 재연결, event id를 지원하지만 바이너리 전송과 양방향 통신에는 한계가 있습니다.

동작 방식 또는 판단 기준

이 주제를 이해할 때는 다음 순서로 보면 실무 적용이 쉬워집니다.

1. 무엇을 해결하려는가: 성능, 표현력, 안정성, 접근성 중 어떤 문제를 줄이려는지 확인합니다.
2. 전제 조건은 무엇인가: 정렬 여부, 브라우저 지원, 네트워크 특성, 동시성 조건처럼 성립해야 하는 조건을 점검합니다.
3. 비용은 어디서 발생하는가: 시간 복잡도, 메모리, 캐시, 재시도, 렌더링 비용처럼 병목 지점을 나눠 봅니다.
4. 실패 시 어떤 문제가 생기는가: 잘못 적용했을 때의 버그나 운영 리스크를 함께 고려합니다.

실제 예시

// SSE 클라이언트
const events = new EventSource('/events');
events.onmessage = (event) => {
  console.log('server event:', JSON.parse(event.data));
};

// WebSocket 클라이언트
const socket = new WebSocket('wss://example.com/ws');
socket.onmessage = (event) => console.log(event.data);
socket.onopen = () => socket.send(JSON.stringify({ type: 'join', roomId: '1' }));

실무에서 주의할 점

• WebSocket은 연결 수, heartbeat, 재연결, 인증 만료 처리를 직접 설계해야 합니다.
• SSE는 일부 프록시에서 buffering 설정 때문에 이벤트가 즉시 전달되지 않을 수 있습니다.
• 실시간 연결은 서버 인스턴스 확장 시 sticky session, pub/sub, connection registry가 필요할 수 있습니다.

실무 적용 가이드

• 양방향 빈도가 높으면 WebSocket, 서버 알림 중심이면 SSE를 우선 검토합니다.
• 재연결 시 마지막으로 받은 메시지 이후부터 복구할 수 있도록 id나 sequence를 둡니다.
• 로드밸런서 timeout과 애플리케이션 heartbeat를 함께 맞춥니다.

함께 연결해서 보면 좋은 키워드

WebSocket, SSE, Realtime, EventSource, PubSub

정리

WebSocket은 하나의 연결에서 클라이언트와 서버가 양방향으로 메시지를 주고받는 프로토콜이고, SSE(Server-Sent Events)는 서버가 클라이언트로 이벤트 스트림을 단방향 전송하는 HTTP 기반 기술입니다. 다만 개념 자체보다 중요한 것은 적용 조건과 한계를 함께 이해하는 것입니다. 작은 예제에서는 단순해 보여도 실제 서비스에서는 성능, 보안, 유지보수성, 접근성 요구사항이 함께 얽히므로, 문제의 성격을 먼저 파악한 뒤 적절한 도구로 선택하는 것이 좋습니다.