왜 SSE를 택했는가
Polling을 택하지 않은 가장 큰 이유는
경제성 및 운영 현실성 때문이었습니다.
개요
JumpingBattle은 사용자가 자신의 기록과 순위를 실시간으로 확인할 수 있도록 설계된 서비스입니다.
특히 매장별 랭킹뿐만 아니라 전국 랭킹 역시 함께 제공하고 있었기 때문에, 기록이 갱신되었을 때 이를 빠르게 사용자에게 전달할 수 있는 구조가 필요하였습니다.
초기 설계 단계에서는 Polling, WebSocket, SSE와 같은 다양한 실시간 전송 방식을 검토하였습니다.
그러나 단순히 실시간성만을 추구하기보다는, 실제 운영 환경에서의 비용과 유지보수성 그리고 서비스의 특성까지 함께 고려할 필요가 있었습니다.
본 문서에서는 당시 검토하였던 전송 방식들과 최종적으로 SSE를 선택하게 된 이유를 정리합니다.
Polling VS SSE
Polling 방식의 가장 큰 장점은 구현이 단순하다는 점입니다.
클라이언트는 일정 주기로 서버에 요청을 전송하고, 서버는 현재 시점의 데이터만 반환하면 되기 때문에 별도의 연결 유지나 이벤트 처리 구조가 필요하지 않습니다.
또한 MVP 단계에서는 빠르게 기능을 검증할 수 있으며, 실시간 연결 관리에 대한 부담이 적어 초기 개발 속도 역시 빠른 편에 속합니다.
운영 관점에서도 요청 수와 트래픽이 비교적 예측 가능하며, 병목 구간을 파악하거나 서버 증설 전략을 세우는 것 역시 상대적으로 단순한 편입니다.
그러나 JumpingBattle의 랭킹 시스템은 단순 조회 서비스가 아니라 순위의 변화를 비교적 실시간으로 정확하게 전달하는 것이 핵심이었습니다.
특히 매장 운영 시간이나 주말과 같은 특정 시간대에는 짧은 시간 동안 다수의 기록이 등록되며 랭킹이 연속적으로 변경될 수 있었습니다.
이러한 환경에서 Polling을 사용할 경우 동기화 주기를 어떻게 설정하느냐에 따라 문제가 발생합니다.
주기를 길게 설정하면 랭킹 반영이 늦어지고, 반대로 짧게 설정하면 실제 변경 여부와 관계없이 지속적인 요청이 발생하게 됩니다.
결과적으로 랭킹 시스템의 핵심은 주기적인 조회가 아니라 변경의 감지와 전달에 있었기 때문에, Polling 방식보다는 SSE가 보다 적합하다고 판단하였습니다.
왜 SSE를 선택하였는가
SSE를 택한 가장 큰 이유는 바로 느슨한 실시간 연결에 있어서 별도의 복잡한 인프라가 필요하지 않다는 점이었습니다.
JumpingBattle의 랭킹 시스템은 채팅 서비스나 실시간 게임과 같이 양방향 통신이 필요한 구조가 아니었습니다.
사용자가 서버로 지속적으로 데이터를 전송하는 것이 아니라, 기록이 갱신되었을 때 서버가 변경된 랭킹 정보를 사용자에게 전달하는 것이 핵심 요구사항이었습니다.
따라서 WebSocket과 같은 양방향 통신 구조를 도입할 경우, 실제 요구사항에 비해 과도한 복잡성이 발생할 수 있다고 판단하였습니다.
또한 SSE는 기존 HTTP 연결을 활용하기 때문에 구현과 운영 측면에서도 비교적 단순하며, 브라우저 차원에서 자동 재연결을 지원한다는 장점 역시 존재하였습니다.
무엇보다도 랭킹 시스템의 핵심은 사용자의 요청을 실시간으로 서버에 전달하는 것이 아니라, 랭킹의 변경 사항을 사용자에게 전달하는 것이었습니다.
따라서 본 서비스에서는 양방향 통신보다는 서버에서 클라이언트로의 이벤트 전달에 집중할 수 있는 SSE가 가장 적합한 선택이라고 판단하였습니다.
WebSocket을 선택하지 않은 이유
WebSocket 역시 실시간 통신을 구현하기 위한 훌륭한 기술입니다.
특히 채팅 서비스나 온라인 게임과 같이 클라이언트와 서버가 지속적으로 데이터를 주고받아야 하는 환경에서는 SSE보다 더욱 적합한 선택이 될 수 있습니다.
실제로 초기 설계 단계에서도 WebSocket 도입을 검토하였으나, JumpingBattle의 랭킹 시스템은 양방향 통신이 필요한 구조가 아니었습니다.
사용자는 자신의 기록을 일반 HTTP API를 통해 서버에 전달하고 있었으며, 실시간 연결에서는 갱신된 랭킹 정보를 수신하는 기능만 필요하였습니다.
즉,
- 클라이언트 → 서버 요청은 일반 API
- 서버 → 클라이언트 랭킹 갱신은 실시간 전송
이라는 역할 분리가 이미 가능하였습니다.
이러한 상황에서 WebSocket을 도입할 경우 실제 요구사항보다 복잡한 연결 관리가 필요해질 수 있으며, 재연결이나 연결 상태 관리와 같은 운영 부담 역시 함께 증가하게 됩니다.
따라서 본 서비스에서는 WebSocket을 사용할 수 없는 것이 아니라, 요구사항 대비 과도한 구조라고 판단하였으며 보다 단순한 SSE 방식을 선택하게 되었습니다.