이 “Static” 웹사이트가 P2P 채팅, Rooms, 그리고 Video Calls를 어떻게 구현하고 있나요?

Source: Dev.to

개요

최근 Talkrush – Stranger Chatting이라는 웹사이트를 우연히 발견했는데, “정적 사이트”가 할 수 있는 일에 대한 제 이해를 확실히 뒤흔들었습니다. 겉보기엔 단순한 GitHub Pages 프로젝트처럼 보입니다—백엔드도 없고, 로그인 시스템도 없으며, 눈에 띄는 API도 없습니다.

기능

• 1:1 낯선 사람 채팅
• 그룹 채팅
• 이름이 지정된 채팅 방
• 영상 통화

방

• 전용 방 페이지: Chat Rooms on Talkrush
• 그룹 채팅 페이지: Group Chat on Talkrush

동일한 group.html 파일이 쿼리 파라미터만 바꾸면 Singles Group Chat Room처럼 여러 다른 방처럼 동작합니다. 서버‑사이드 라우팅이나 백엔드에서 생성된 페이지가 전혀 관여하지 않으며, URL에 반응하는 정적 파일일 뿐입니다.

어떻게 작동할까

클라이언트 측 메커니즘

• URL 매개변수가 방 이름/네임스페이스를 결정합니다.
• 클라이언트 측 JavaScript가 이 매개변수를 파싱하고 메시지를 해당 범위에 맞게 처리합니다.
• 브라우저 API(WebRTC, WebSockets)가 실시간 통신을 처리합니다.

가능한 시그널링 접근 방식

1. 직접 피어‑투‑피어 연결을 위한 WebRTC.
2. 다른 곳에 호스팅되는 경량 시그널링 레이어(예: WebSockets).
3. PeerJS, WebTorrent 등과 같은 서드파티 추상화 라이브러리.

사이트가 정적으로 보이더라도 시그널링은 어딘가에서 이루어져야 합니다—브라우저는 오퍼와 ICE 후보를 교환하지 않고는 서로를 발견할 수 없습니다.

관찰된 동작

• 메시지가 즉시 도착합니다.
• 방이 충돌하지 않으며, 다른 그룹의 사용자는 격리됩니다.
• 이는 방 이름 스코핑과 결정적인 피어 발견(방 이름 = 네임스페이스), 그리고 깔끔한 연결 수명 주기 관리가 이루어졌음을 시사합니다.

왜 인상적인가

전통적인 백엔드가 없음에도 경험이 깔끔하고 반응성이 뛰어납니다:

• 백엔드 라우팅이 필요 없습니다.
• 실시간 기능이 전적으로 클라이언트 측 로직에 의해 구동됩니다.
• “실시간 앱은 반드시 백엔드가 무겁다”는 가정을 뒤흔듭니다.

토론 요청

다음 분야에 경험이 있다면:

• 피어‑투‑피어 채팅 시스템 구축
• 프로덕션 환경에서 WebRTC 사용
• 시그널링 또는 매치메이킹 레이어 설계

이런 시스템을 어떻게 구축할지 의견을 듣고 싶습니다.

프로젝트 참고

Talkrush – Stranger Chatting by Aman Kumar