Fix: WebRTC 상호작용 문제 해결 (#264)

[jueunk617]

📌 개요

WebRTC 화상 채팅 기능의 안정성과 유지보수성을 향상시키기 위해 WebSocket 기반 시그널링 서버의 핵심 로직을 개선하고 정책을 명확히 수립했습니다.

🔨 작업 내용

WebRTC 시그널링 방식을 방 전체 토픽(Broadcast)으로 변경

• Offer, Answer, ICE Candidate 등 모든 WebRTC 시그널을 기존에 고려했던 개인 큐 방식이 아닌, /topic/room/{roomId}/webrtc 주소로 브로드캐스트하도록 통일했습니다.
• 이를 통해 서버의 복잡도를 낮추고, 사용자-세션 매핑 실패와 같은 잠재적 오류를 원천적으로 차단하여 연결 안정성을 확보했습니다.

에러 처리 로직 개선

• WebRTC 관련 예외(CustomException) 발생 시, 오류 당사자에게만 개인 큐(/user/queue/errors)로 에러를 전송하도록 수정했습니다.
• 이를 통해 다른 사용자에게 불필요한 에러 정보가 노출되는 것을 방지하고 영향을 최소화했습니다.

미디어 상태 변경 DTO 명세 명확화

• 프론트엔드와의 통신 규약을 명확히 하여 WebRTCMediaToggleRequest의 데이터 불일치 문제를 사전에 방지했습니다.

테스트 코드 수정

• 변경된 로직에 맞춰 WebSocketMessageControllerTest와 WebRTCSignalingControllerTest의 관련 테스트 케이스를 수정 및 보완했습니다.

🔗 관련 이슈

Closes #264

📝 참고 사항

시그널링 방식을 브로드캐스트로 선택한 이유

• 개인 큐(convertAndSendToUser) 방식은 서버가 메시지를 보낼 대상(principal.getName())과 클라이언트가 지정한 대상(userId)의 식별자 불일치 문제, 그리고 세션 매핑 타이밍 이슈 등 실패 지점이 많아 안정성이 떨어질 수 있습니다.
• 반면, 방 전체 토픽으로 브로드캐스트하는 방식은 서버가 '메시지 중계'라는 단일 책임에만 집중하게 하여 매우 단순하고 견고한 구조를 만듭니다.
• WebRTC 시그널링 메시지는 수 KB의 텍스트 데이터에 불과하여, 실제 미디어 스트림 트래픽에 비하면 약간의 네트워크 비효율성은 시스템 전체의 안정성이라는 큰 이득에 비해 무시할 수 있는 수준이라고 판단하여 현재의 구조를 채택했습니다.

✅ 체크리스트

• 기능 동작 확인
• 테스트 코드 작성
• 문서/주석 추가 및 최신화