Never give up

일반적인 웹 브라우저 간(Web-to-Web)의 WebRTC 애플리케이션이라면 브라우저의 네이티브 런타임에서는 관대하게 작동합니다 패킷 순서가 조금 뒤바뀌어 오더라도 자체적으로 버퍼링을 하거나 암호화 핸드셰이크 과정에서 일어나는 일시적인 상태 미스매치를 알아서 복구해 주죠 하지만 이 피어 연결을 브라우저 밖으로 꺼내서 에이전트에 올리고 비동기 메시지 브로커와 동기화하는 순간 그 자비로움(?)은 눈 씻고 찾아볼 수 없습니다(Node.js 미디어 런타임은 자비가 없습니다) ICE Candidate나 SDP Offer가 단 1밀리초라도 순서가 뒤바뀌어 도착하면 엔진은 기다려주지 않고 즉시 invalid state 예외를 뿜으며 미디어 세션을 통째로 날려버립니다 이 무자비한 비동기 시그널링의 포화 속에서 살아남..

지난 포스팅에서 로컬 기기 페어링 지옥을 다뤘는데 이번에는 패킷을 안전하게 주고받기 위한 시그널링 서버의 구성에 대해 짚고 넘어가보자 합니다 WebRTC를 구현할 때 브라우저와 기기 간에 SDP나 ICE Candidate 같은 메타데이터를 교환하는 시그널링은 필수죠 하지만 클라우드 환경에서 이를 안정적으로 설계하는 것은 완전히 다른 문제입니다 Reverse Tunneling: 공유기 설정 없이 방화벽 우회하기프로토콜을 고민하기 전에 가장 먼저 마주한 제약은 바로 네트워크 접근성이었습니다 전통적인 방식대로 원격 기기에 접속하려면 고정 IP를 쓰거나 방화벽 인바운드 규칙을 바꾸고 포트 포워딩을 설정해줘야 됩니다 하지만 일반 유저에게 이런 복잡한 설정을 요구하는 순간 유저들은 떨어져 나가죠(실제 많은 유저가 ..