토론 타이머 시간 동기화 기능, WebSocket이 최선일까?
안녕하세요, 토론 타이머 백엔드 팀입니다! 지난번 토론 타이머의 시간 동기화 기능 구현을 앞두고, 팀 내에서 가장 효율적인 실시간 통신 방식에 대해 열띤 토론을 진행했습니다. 주요 논제는 "WebSocket 도입이 최선인가?" 였으며, 토론 내용을 정리하여 기술 블로그로 공유합니다.
토론 타이머의 새로 도입될 시간 동기화 기능은 발행자(사회자)가 조작하는 타이머 화면을 구독자(토론 참여자/관전자)들이 실시간으로 확인하는 기능입니다.
| 도메인 특성 | 설명 | 요구 사항 |
|---|---|---|
| 느슨한 시간 동기화 | 0.1초 단위의 엄밀함보다는 1초 내외의 딜레이가 허용됨. (토론 마무리를 인지하는 정도) | 극도의 실시간성 불필요 |
| 이벤트 희소성 | 약 30분 토론 중 타이머 시작, 정지, 팀 전환 등 조작 이벤트 발생 횟수가 매우 적음. | 장시간 연결 유지의 비효율성 |
| 단방향 소통 성격 | 사회자 |
이러한 특성 때문에, 팀은 '고성능 양방향 통신 기술'인 WebSocket이 과연 최적의 선택인지에 대한 의문을 제기했습니다.
저희는 더 적합한 기술에 대해 이야기를 해보기 위해 토론을 기획했습니다.
- ‘시간 동기화 기능’ 기능에서 적합한 기술 조사 및 논의
- 토론을 통한 개발 방법 논의가 얼마나 효율적인지 파악
- 입론 - 주도권 토론 - 자유토론 - 최종 발안을 찬성/반대가 번갈아가며 진행
- '토론 타이머' 서비스를 이용해 토론 진행
찬성측은 미래 확장성과 실시간 통신 효율 측면에서 WebSocket이 우위를 가진다고 주장했습니다.
현재는 타이머 동기화만 필요하지만, 향후 새로운 실시간 기능이 추가될 가능성을 고려해야 합니다.
- 단일 커넥션 통합: WebSocket은 하나의 연결(커넥션)을 통해 다양한 실시간 기능을 처리할 수 있어, 기능이 늘어날 때마다 새로운 연결 방식(예: SSE/HTTP의 복합 사용)을 추가하는 것보다 장기적으로 개발 및 운영 리소스 관점에서 유리합니다.
- 기술 성숙도: 이미 WebSocket 관련 라이브러리가 풍부하게 제공되므로, 기술적 복잡도에 대한 우려는 크지 않으며, 네트워크가 끊겼을 때 재시도 로직을 직접 구현할 수 있는 기반을 제공합니다.
타이머는 기본적으로 실시간성이 중요한 영역이므로, Polling, SSE 등 다른 대안보다 실시간 통신 효율이 높은 WebSocket이 근본적으로 더 적합합니다.
반대측은 도메인 특성상 WebSocket의 단점이 부각된다고 지적하며, 서버 부담이 적고 안정적인 Pub/Sub 구조를 제공하는 FCM을 대안으로 제시했습니다.
소규모 서비스 환경(프리티어 서버)에서 WebSocket의 단점이 치명적일 수 있습니다.
- 비효율적인 쓰레드 점유: 몇 번 되지 않는 이벤트 전송을 위해 토론 시간 내내(30분 이상) 서버 쓰레드가 장시간 연결을 유지하며 점유됩니다. 이는 서버에 부담으로 작용합니다.
- 비정상 종료 시 문제: 유저가 브라우저를 닫아도 서버가 이를 인지하지 못하고 불필요하게 TCP 연결을 유지할 수 있으며, 이에 대한 대응책 마련이 필요합니다.
- 확장성의 제약: WebSocket 연결 유지는 서버에 상태성(Statefulness)을 부여하며, 스케일 아웃 시 스티키 세션(Sticky Session) 설정이 요구되어 향후 트래픽 증가 시 병목 지점이 될 수 있습니다.
FCM은 단순히 푸시 알림뿐만 아니라 데이터 메시지(JSON 페이로드) 전송에도 사용되는 안정적인 메시지 브로커입니다.
- 자체 서버 리소스 절감: FCM 서버를 활용하면 자체 서버를 경유하지 않고 클라이언트 간에 이벤트를 전달할 수 있으므로, 추가적인 서버 리소스 소모가 거의 없습니다.
- 안정성과 편의성: 이미 구글이 관리하는 높은 안정성을 갖추고 있으며, 복잡한 소켓 통신이나 프로토콜 전환 없이 RESTful API를 통해 소통이 가능해 개발팀의 학습 및 개발 리소스 부담을 줄여줍니다. (외부 API의 불안정성 우려에 대해서도 대규모 서비스 사례를 들어 안정적임을 반박했습니다.)