토론 타이머 시간 동기화 기능, 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의 불안정성 우려에 대해서도 대규모 서비스 사례를 들어 안정적임을 반박했습니다.)
토론을 마친 후 토론 활동에 대해 회고를 진행했습니다.
| 참가자 | 주요 소감 |
|---|---|
| 커찬 (사회자) | 각 기술 방식에 대한 서로의 이해도가 달라 아쉬웠다. 특히 외부 컴포넌트(FCM)가 논의에 추가되면서 정보 비대칭성이 심화되어 심층적인 논의가 어려웠다. |
| 콜리 (반대) | FCM의 강력한 장점(서버 리소스 절감, 안정성)을 논리적으로 제시할 수 있었으나, 모두가 동일한 이해를 가진 주제가 주어졌다면 더 효율적이었을 것이다. |
| 비토 (찬성) | 정보의 비대칭성이 있었음을 인정하며, 토론이 FCM의 재시도 로직 등 핵심 기술적 문제를 파고들지 못하고 표면적인 논리 전개에 그쳐 아쉬웠다. |
기술 토론을 '토론' 형식으로 진행한 결과, 기술 선택 방법론으로서의 한계를 명확히 인지했습니다. 토론은 생각의 가지를 넓게 퍼져나가게 하는 평소의 '토의' 방식에 비해 효율적이지 못했으며, 정해진 논리에 갇혀버리는 경향이 있었습니다.
이번 토론을 통해 각 기술의 장단점을 깊이 있게 이해하는 성과를 얻었습니다. 기술 구현 방식에 대한 논의는 정보의 비대칭성을 해소하고 생각의 가지를 넓히는 데 더 적합한 '토의' 방식을 지향하여 진행할 예정입니다. 토론에서 얻은 통찰을 바탕으로, 추가적인 기술 토의를 거쳐 토론 타이머에 가장 합리적인 실시간 통신 기술을 최종 결정할 계획입니다.