SSE(Server-Sent Events) 완벽 가이드: 실시간 데이터 전송, 왜 웹소켓만 고집하시나요?

안녕하세요. 오늘은 현대 웹 서비스에서 빼놓을 수 없는 핵심 기술 중 하나인 실시간 데이터 전송에 대해 이야기해보려 합니다.

우리가 매일 사용하는 서비스들을 떠올려보세요. 누군가 내 글에 댓글을 남겼을 때 실시간으로 울리는 알림, 주식 시장의 실시간 시세 변동, 혹은 배달 앱에서 라이더의 위치가 실시간으로 움직이는 모습들까지. 이제 '새로고침'을 누르지 않아도 화면이 스스로 업데이트되는 것은 선택이 아닌 필수가 되었습니다.

보통 이런 기능을 구현한다고 하면 많은 개발자분이 가장 먼저 '웹소켓(WebSocket)'을 떠올리곤 합니다. 하지만 모든 상황에서 웹소켓이 정답일까요? 오늘은 웹소켓보다 훨씬 가볍고, HTTP 표준을 그대로 활용하면서도 강력한 성능을 자랑하는 SSE(Server-Sent Events), 즉 서버 사이드 이벤트에 대해 깊이 있게 다뤄보겠습니다.

1. 실시간 웹의 시대, 왜 SSE에 주목해야 할까?

불과 몇 년 전만 해도 실시간 데이터를 처리하기 위해 우리는 '폴링(Polling)' 방식을 주로 사용했습니다. 클라이언트가 주기적으로 서버에 "새로운 데이터 있어?"라고 물어보고, 서버는 "아직 없어" 혹은 "여기 있어"라고 답하는 방식이었죠. 이 방식은 구현은 쉽지만 서버에 엄청난 부하를 줍니다. 데이터가 없어도 계속 요청을 주고받아야 하니까요.

그 대안으로 나온 것이 웹소켓입니다. 양방향 통신이 가능하다는 강력한 장점이 있지만, 그만큼 프로토콜이 복잡하고 서버 자원을 많이 소모한다는 단점도 있습니다.

여기서 등장한 것이 바로 **SSE(Server-Sent Events)**입니다. SSE는 서버에서 클라이언트로 데이터를 일방적으로 밀어주는(Push) 방식입니다. "알림 서비스"처럼 서버가 클라이언트에게 알려줄 내용만 있는 경우라면, 굳이 무거운 웹소켓을 쓸 필요 없이 실시간 데이터 전송을 위해 최적화된 SSE가 훨씬 효율적인 선택지가 될 수 있습니다.

2. SSE(Server-Sent Events)의 핵심 개념 이해하기

SSE는 HTML5 표준의 일부로, HTTP 연결을 통해 서버에서 클라이언트로 이벤트를 전달하는 기술입니다. 가장 큰 특징은 한 번 연결을 맺으면 서버가 지속적으로 데이터를 보낼 수 있는 '단방향 통신'이라는 점입니다.

동작 원리

클라이언트가 서버에 SSE 연결을 요청하면, 서버는 응답 헤더의 Content-Type을 text/event-stream으로 설정하여 연결을 유지합니다. 이후 서버는 클라이언트가 연결을 끊기 전까지 계속해서 데이터를 스트리밍 방식으로 전달하게 됩니다.

데이터 형식은 매우 단순합니다. 기본적으로 문자열 기반이며, 다음과 같은 구조를 가집니다.

Plaintext

id: 1
event: message
data: 안녕하세요, 새로운 알림이 도착했습니다.

id: 2
event: update
data: {"stock_price": 50000}

이처럼 ID, 이벤트 타입, 데이터를 명시하여 보낼 수 있어 클라이언트에서 이를 분기 처리하기에도 매우 용이합니다.

3. 웹소켓(WebSocket) vs SSE: 어떤 상황에 무엇을 써야 할까?

많은 분이 이 지점에서 고민에 빠지곤 합니다. "둘 다 실시간인데, 그냥 웹소켓 하나만 잘 쓰면 되는 거 아냐?"라고 생각하실 수 있죠. 저 역시 과거 프로젝트에서 비슷한 고민을 했던 경험이 있습니다. 하지만 두 기술은 목적이 명확히 다릅니다.

언제 웹소켓을 써야 할까요?

채팅 서비스나 멀티플레이어 게임처럼 클라이언트와 서버가 쉴 새 없이 서로 데이터를 주고받아야 하는 경우라면 당연히 웹소켓이 유리합니다.

언제 SSE를 써야 할까요?

SNS 알림, 실시간 뉴스 피드, 주식 시세 모니터링, 로그 스트리밍처럼 서버에서 발생하는 이벤트를 클라이언트에 전달하기만 하면 되는 경우에는 서버 사이드 이벤트가 정답입니다. 설정이 훨씬 간편하고, HTTP/1.1이나 HTTP/2 위에서 그대로 동작하기 때문입니다.

4. 직접 구현하며 느낀 SSE의 진정한 매력

제가 이전에 대규모 커뮤니티 사이트의 알림 시스템을 개편할 때의 경험을 들려드리고 싶습니다. 초기에는 웹소켓으로 구현을 검토했지만, 동시 접속자가 수만 명에 달하는 상황에서 모든 연결을 양방향으로 유지하는 것은 서버 비용 측면에서 큰 부담이었습니다.

그때 과감하게 SSE로 선회했습니다. 구현 과정에서 느낀 장점은 생각보다 훨씬 강력했습니다.

첫째, 자동 재연결(Automatic Reconnection) 기능

네트워크 상태가 불안정해서 연결이 끊기면, 브라우저가 스스로 서버에 재연결 요청을 보냅니다. 개발자가 별도로 onClose 시점에 재연결 로직을 복잡하게 짤 필요가 없다는 것이죠. 심지어 서버에서 마지막으로 받은 이벤트 ID(Last-Event-ID)를 전송해주면, 끊겼던 시점 이후의 데이터부터 다시 받을 수 있는 메커니즘도 갖추고 있습니다.

둘째, 가벼운 리소스 소모

표준 HTTP 연결을 유지하기 때문에 서버 측의 리소스 관리가 훨씬 수월합니다. 특히 HTTP/2를 사용 중이라면 하나의 커넥션 안에서 멀티플렉싱을 통해 효율적으로 여러 스트림을 관리할 수 있습니다.

셋째, 기존 인프라와의 호환성

웹소켓은 특정 프록시나 방화벽 설정에서 차단되는 경우가 종종 있습니다. 하지만 SSE는 순수 HTTP를 사용하므로 기존 보안 정책이나 인프라를 그대로 활용할 수 있어 배포 과정에서의 스트레스가 현저히 적었습니다.

5. 실무에서 반드시 체크해야 할 주의사항 (Troubleshooting)

물론 SSE가 만능은 아닙니다. 실제 현업에서 도입할 때 저를 당황하게 했던 몇 가지 포인트들이 있었는데요, 여러분은 같은 시행착오를 겪지 않으셨으면 합니다.

1) 브라우저 연결 수 제한 (HTTP/1.1 이슈)

가장 주의해야 할 점입니다. HTTP/1.1 환경에서 브라우저는 동일한 도메인에 대해 동시 연결 수를 최대 6개(Chrome 기준)로 제한합니다. 만약 사용자가 브라우저 탭을 여러 개 열어둔다면, SSE 연결이 6개를 초과하는 순간 새로운 탭에서는 실시간 알림이 작동하지 않게 됩니다.

• 해결책: 반드시 HTTP/2를 사용하세요. HTTP/2에서는 한 커넥션 내에서 수많은 스트림을 처리할 수 있어 이 제한에서 자유로워집니다.

2) 타임아웃(Timeout) 설정

중간에 위치한 Nginx 같은 프록시 서버나 L4 스위치에서 일정 시간 동안 데이터가 흐르지 않으면 연결을 강제로 끊어버릴 수 있습니다.

• 해결책: 서버에서 주기적으로 '더미(Dummy) 데이터' 또는 'Heartbeat' 패킷을 보내 연결이 살아있음을 알려주어야 합니다. 보통 15~30초 간격으로 빈 주석이나 작은 데이터를 보내는 방식을 사용합니다.

3) 클라이언트 종료 감지

단방향 통신이다 보니, 클라이언트가 비정상적으로 종료되었을 때 서버가 이를 즉각적으로 알아차리지 못하고 계속 데이터를 보내려 시도하는 경우가 생길 수 있습니다. 이는 서버 메모리 누수로 이어질 수 있으므로, 서버 측 로직에서 클라이언트의 연결 해제 이벤트를 정확히 캐치하여 리소스를 정리해주는 코드가 필수적입니다.

마치며: 기술 선택의 기준은 언제나 '목적'입니다

지금까지 **SSE(Server-Sent Events)**의 개념부터 실무 적용 시의 노하우까지 꼼꼼하게 살펴보았습니다.

글을 마치며 개인적인 소회를 덧붙이자면, 기술을 선택할 때 가장 위험한 태도는 "요즘 유행하니까" 혹은 "이게 제일 강력하니까"라는 생각인 것 같습니다. 저 역시 한때는 모든 실시간 기능에 웹소켓이 최고라고 믿었던 적이 있었습니다. 하지만 SSE를 깊이 이해하고 적재적소에 활용해보니, 오히려 단순함이 주는 강력함과 안정성이 서비스의 퀄리티를 한 단계 높여준다는 것을 깨달았습니다.

실시간 데이터 전송이 필요하신가요? 그렇다면 무조건적인 웹소켓 도입보다는, 내가 만들려는 기능이 '양방향'이 정말 필요한지 아니면 서버에서 주는 정보를 '받기만' 하면 되는 것인지를 먼저 고민해보시길 바랍니다. 만약 후자라면, SSE는 여러분의 프로젝트를 훨씬 가볍고 견고하게 만들어줄 훌륭한 파트너가 될 것입니다.

오늘 이 글이 실시간 웹 기술을 고민하시는 많은 개발자분께 작은 나침반이 되었기를 바랍니다. 혹시 구현 과정에서 궁금한 점이 생기신다면 언제든 의견 나누어 주세요. 아는 범위 내에서 성심껏 답변해 드리겠습니다.

작성 후기 및 회고

이번 글을 작성하면서 다시 한번 SSE의 기술적 명세와 실무적인 제약 사항들을 복기해볼 수 있었습니다. 단순히 이론적인 설명에 그치지 않고, 제가 실제 프로젝트에서 마주했던 '연결 수 제한' 이슈나 'HTTP/2'의 중요성을 강조하려 노력했습니다. 독자들이 기술의 장단점을 명확히 파악하여 실질적인 도움을 얻을 수 있기를 기대합니다.