공용 Room에서 화원별 User Room으로: 전달 범위와 전달 보장은 다르다

신규 구축에서 Polling과 Socket.io를 비교했습니다

하이패스 백엔드를 혼자 맡아 신규 구축할 때 주문 상태를 어떻게 전달할지 정해야 했습니다. 주기적으로 상태를 확인하는 Polling과 즉시 상태를 전달하는 Socket.io를 비교했고, 주문 변화를 바로 알려 주기 위해 Socket.io를 선택했습니다. 이미 운영하던 Polling을 제거한 작업은 아니었습니다.

공용 Room은 관계없는 사용자까지 포함했습니다

초기에는 주문 화면 사용자들이 하나의 공용 Room에 들어가는 구조였습니다. 개발 중 코드를 재검토하면서 관계없는 사용자도 다른 화원의 주문 이벤트를 받을 수 있다는 점을 발견했습니다. 운영 사고나 트래픽 시뮬레이션으로 발견한 문제가 아니었습니다.

이 문제의 핵심은 성능 수치가 아니라 전달 대상이었습니다. 특정 주문과 관계없는 사용자에게 이벤트를 보낼 이유가 없었고, 서버에서 수신 범위를 구분해야 했습니다.

화원별 User Room으로 수신 대상을 제한했습니다

주문 화원과 수주 화원의 user_<gardenId> Room에만 이벤트를 보내도록 변경했습니다. 개발 환경에서 서로 다른 화원 계정으로 확인했고, 관련 사용자에게만 이벤트가 전달되어 화면 갱신이 일어나는 것을 브라우저에서 확인했습니다. 전환 전후의 트래픽이나 성능 감소량은 측정하지 않았습니다.

전달 범위와 전달 보장은 다른 문제였습니다

공용 Room을 사용하던 때 서버 송신 기록은 있었지만 브라우저가 이벤트를 수신하지 못한 사례를 확인했습니다. 정확한 유실 원인은 규명하지 못했습니다.

User Room으로 바꾼 뒤에는 같은 유실 조건을 재현하는 방법을 찾지 못했습니다. 따라서 Room 변경으로 유실을 해결했거나 메시지 도달을 보장했다고 주장하지 않습니다. 전달 범위를 올바른 사용자로 좁히는 것과 네트워크 단절 중에도 이벤트 도달을 보장하는 것은 서로 다른 문제입니다.

운영에서는 동작을 확인했지만 내부 전달은 검증하지 못했습니다

운영 서버에는 PM2 3개 워커와 Socket.io cluster adapter 구성을 적용했습니다. 브라우저에서 소켓 이벤트와 화면 갱신이 정상 동작하는 것은 확인했습니다.

다만 다중 워커 사이의 이벤트 전달 구조를 정확히 이해하지 못했고, 워커 간 이벤트 전달만 분리해 검증하지도 않았습니다. 운영 화면에서 동작했다는 관찰을 클러스터 전달 보장으로 확대하지 않습니다.

적용 기준

특정 사용자·조직의 상태를 다루는 이벤트는 사용자별 Room으로 제한합니다. 반대로 모두에게 같은 정보가 필요한 공지성 이벤트라면 공용 Room을 사용할 수 있습니다.

어떤 Room을 선택하든 수신 대상 설계와 메시지 도달 보장은 별도로 검토해야 합니다. 이 프로젝트에서 확인한 것은 관련 화원만 수신하도록 범위를 바꾼 결과까지이며, 연결 단절과 재연결 사이의 복구 방식은 구현하거나 검증하지 않았습니다.