2. 실시간 통신

🪵 세부 기술 로그

1. 양방향 웹 통신의 진화
2. WebRTC에 대하여
3. WebRTC 구현 방식
4. WebRTC 실습 (1) : 1:1 Mesh 방식
5. WebRTC 실습 (2) : 1:N Mesh 방식
6. WebRTC에서 Websocket으로
7. WebSocket 서버

---

WebRTC 선정 이유

프로젝트를 시작하면서 가장 큰 고민은 서버 구현이었습니다. 특히 FE 개발자가 다섯 명인 상황에서 실시간 통신을 어떻게 효율적으로 구현할 수 있을지 고민이 많았습니다. 처음에는 서버 부담을 최소화하기 위해 P2P 연결 방식인 WebRTC를 선택했습니다.

Important

• 양방향 웹 통신의 진화
• WebRTC에 대하여
• WebRTC 구현 방식
• WebRTC 실습 (1) : 1:1 Mesh 방식
• WebRTC 실습 (2) : 1:N Mesh 방식

WebRTC에서 WebSocket으로

하지만 예상치 못한 문제가 발생했습니다. WebRTC가 모든 네트워크 환경에서 원활하게 작동하지 않았고, 특히 Mesh 방식에서 TURN 서버를 경유할 때 발생하는 딜레이가 실시간 통신의 걸림돌이 되었습니다.

처음에는 SFU(Selective Forwarding Unit) 서버 도입을 고려했습니다. 이는 P2P 네트워크 부하 문제는 해결할 수 있지만, 모든 트래픽이 서버를 통과해야 하며, 미디어 스트림 처리를 위한 추가적인 서버 자원이 필요했습니다.

반면, WebSocket은 구현이 상대적으로 단순하고 서버 자원을 덜 사용하면서도 안정적인 양방향 통신이 가능합니다. 특히, 우리의 경우 영상/음성 같은 미디어 스트림 전송보다는 데이터 통신이 주요 요구사항이었기 때문에, WebSocket으로 충분히 목적을 달성할 수 있었습니다.

Important

• WebRTC에서 Websocket으로

WebSocket 서버

결론적으로, CRDT를 통해 서버는 중계 역할만 담당하고, 실제 데이터 병합과 처리는 모두 클라이언트에서 이루어지도록 설계했습니다. 이렇게 하여 빠르고 안정적인 실시간 통신을 구현할 수 있었습니다.

Important

• WebSocket 서버