배경

Haze 프로젝트의 목표는 1:1 화상채팅 앱의 MVP를 빠르게 개발하고 검증하는 것이었습니다.

가장 큰 기술적 과제는 서버 비용과 부하를 최소화하면서 안정적인 실시간 영상 통화를 구현하는 것이었습니다.

만약 모든 사용자의 영상 데이터를 서버가 중계하는 방식을 사용한다면, 트래픽 비용과 서버 유지보수 비용이 기하급수적으로 증가할 것이 분명했습니다.

따라서, 서버의 역할을 최소화하고 사용자 간에 직접 미디어 데이터를 교환하는 P2P 방식의 아키텍처가 필요하다고 생각했습니다.

과정

이 문제를 해결하기 위해 WebRTC 기술을 채택하고, 서버는 P2P 연결을 중개하는 시그널링 서버의 역할만 담당하도록 아키텍처를 설계했습니다.

1. P2P 아키텍처 채택과 시그널링 서버의 역할

WebRTC는 클라이언트 간에 직접 미디어 스트림을 주고받는 기술입니다.

하지만 서로의 네트워크 주소를 모르기 때문에, 연결 초기 단계에서는 두 클라이언트를 연결해 줄 '주선자'가 필요합니다. 이것이 바로 시그널링 서버의 역할입니다.

저희는 Socket.IO를 이용하여 이 시그널링 서버를 구현했으며, 서버는 다음과 같은 P2P 연결 정보 교환 과정만을 중개했습니다.

• Offer/Answer (연결 제안 및 수락): 한쪽 클라이언트(Caller)가 자신의 미디어 정보(코덱, 해상도 등)가 담긴 SDP Offer를 생성하면, 서버는 이를 상대방(Answerer)에게 전달합니다. 상대방은 이를 받아 자신의 정보가 담긴 SDP Answer를 서버를 통해 회신합니다.
• ICE Candidate 교환 (네트워크 경로 탐색): 각 클라이언트는 자신의 공인 IP 주소와 포트 등, 연결 가능한 네트워크 경로 정보(ICE Candidate)들을 수집합니다. 서버는 이 정보들을 서로에게 전달하여, 두 클라이언트가 최적의 P2P 연결 경로를 찾을 수 있도록 돕습니다.

이 모든 시그널링 과정이 성공적으로 끝나면, 두 클라이언트 간의 P2P 연결이 확립되고, 이후 모든 영상/음성 데이터는 저희 서버를 전혀 거치지 않고 사용자끼리 직접 교환됩니다.

2. NAT 문제 해결 (STUN/TURN)

대부분의 사용자는 공유기(NAT) 뒤에 있어 공인 IP가 아닌 사설 IP를 사용합니다.

이 문제를 해결하기 위해, WebRTC는 STUN 서버를 사용합니다.