[P2P 프로토콜] WebTransport와 QUIC은 WebRTC를 대체할까

대용량 파일을 보내는 화면을 만들고 있다고 생각한다. 첫 번째 시도는 브라우저끼리 직접 붙는다. 두 번째 시도는 서버를 거쳐 빠르게 붙는다. 둘 다 bytes는 흐를 수 있지만 사용자가 동의한 약속은 같지 않다. 숫자로 포장하기보다, 재현 조건과 운영에서 고정한 규칙을 중심으로 적었다.

WebTransport를 다시 보게 된 이유

실험 결과를 읽을 때도 마지막 성공 여부만 보지 않는다. direct 경로가 성공했지만 ICE 후보 수집에 오래 걸렸다면 사용자는 이미 불안해졌을 수 있다. 서버 endpoint는 빨리 붙었지만 relay byte가 크게 늘었다면 비용 모델이 바뀐다. TURN 전환이 잦다면 WebRTC를 고집한 것이 아니라 fallback 정책을 다시 봐야 한다. 로그도 같은 방식으로 쪼갠다. webtransport.endpoint_connected, quic.stream_retry, webrtc.ice_gathering, turn.fallback, mode.server_relay처럼 내부 사건을 분리하고, 화면에는 direct와 서버 경유의 차이를 사용자가 이해할 수 있는 문장으로 남긴다.

그래야 “P2P가 느리다”는 문의가 왔을 때 전송 속도인지 발견 시간인지 relay 비용인지 다시 풀 수 있다. 사용자 동의의 관점에서도 둘은 다르게 읽힌다. 직접 연결이라고 설명한 기능에서 서버 경유가 길게 남으면 사용자는 속도보다 신뢰를 먼저 의심할 수 있다. 반대로 서버 경유를 명확히 고지한 비동기 전달 기능이라면 WebTransport/QUIC 경로는 더 자연스럽다.

기술 이름보다 약속의 문장이 먼저다. | 제품 상황 | 먼저 볼 선택 | 기록할 값 | 사용자에게 숨기면 안 되는 것 | |---|---|---|---| | 같은 시간에 양쪽 브라우저가 열려 있음 | WebRTC direct 우선 | ICE 후보 수집 시간, TURN 전환 비율 | 직접 연결이 실패할 수 있음 | | 받는 쪽이 늦게 열거나 모바일 백그라운드에 있음 | WebTransport/QUIC relay 또는 edge buffer | server endpoint 연결 시간, 보관 시간 | 서버가 잠시 경유할 수 있음 | | 비용 제한이 강함 | direct 유지와 fallback 조건 | TURN 사용량, relay byte | fallback의 비용과 조건 | | 개인정보 설명이 중요한 파일 | direct와 서버 경유 문구 분리 | payload 경로, 암호화 상태 | 어떤 경로로 byte가 흐르는지 |

섞기 쉬운 인접 개념

WebTransport는 서버와의 저지연 양방향 전송에 강하다. QUIC stream은 전송 방식의 특성을 바꿔도 상대 피어를 찾는 문제까지 대신 풀지는 않는다. WebRTC 쪽은 브라우저 간 직접 연결을 목표로 삼고 그 안에서 ICE 절차를 수행한다. 이 셋을 같은 줄에 놓고 “빠른 전송”만 비교하면 핵심이 빠진다. 제품 문구는 프로토콜 이름보다 경계를 보여 주는 쪽이 낫다. “QUIC 처리 중”보다 “서버 경유 경로를 확인하는 중”, “직접 연결 후보를 찾는 중”, “임시 relay로 전환할 수 있음” 같은 문장이 사용자의 다음 행동에 가깝다.

TURN 비용을 피하려는 목적이라면 WebTransport가 자동 해답이 되지는 않는다. WebTransport는 직접 P2P 연결을 대신 찾아 주는 기술이 아니다. 서버 endpoint가 기준이 되기 때문에 NAT traversal 부담은 줄어든 듯 보일 수 있지만, 그 대신 서버 경유 비용과 개인정보 설명이 더 앞에 나온다. PonsWarp에 붙이면 WebTransport와 WebRTC는 승자 경쟁보다 모드 선택 문제가 된다. 같은 P2P라도 제품이 지켜야 할 약속이 다르면 선택도 달라진다.

사용자에게 “직접 전달”이라고 말해 놓고 서버 endpoint를 오래 경유하면 설명이 어긋난다. 반대로 서버 경유를 허용한 기능에서 억지로 직접 연결만 고집하면 실패율과 대기 시간이 올라간다. 대용량 파일에서는 직접 전송을 우선하되, 비동기 수신이나 모바일 백그라운드 구간은 WebTransport/QUIC 기반 relay나 edge buffer와 섞는 판단이 현실적이다. 이때 중요한 것은 “대체”가 아니라 모드 이름이다.

direct 모드, 서버 경유 모드, 임시 relay 모드가 화면과 로그에서 구분되어야 한다.

각 전송이 지키는 것

API 선택처럼 보이는 결정을 NAT, TURN 비용, 서버 endpoint, 사용자 문구의 실패 지도로 다시 나눈 그림. PonsLink와 PonsWarp 같은 브라우저 기반 제품에서는 이 구분이 기능 설명보다 먼저 온다. 파일이 서버를 지나가도 되는가, 아니면 직접 연결 약속이 제품의 핵심인가를 먼저 정해야 한다. 사용자가 느끼는 속도도 한 값이 아니다. 연결 준비가 빠른지, 첫 byte가 빠른지, 전체 전송이 빠른지, 실패 뒤에 회복이 빠른지 나눠야 한다.

WebTransport가 어떤 값에서는 좋아 보여도 직접 연결 요구가 강한 장면에서는 다른 값이 더 중요할 수 있다. 반대로 WebRTC만 고집하면 브라우저 연결 실패와 TURN 비용을 계속 떠안게 된다. 사용자에게는 둘 다 “파일 보내기” 버튼이지만 운영자는 서버 endpoint를 거친 byte와 peer 사이에서 흐른 byte를 다르게 봐야 한다. 모드가 바뀌었는데 화면이 그대로라면 나중에 문의가 들어왔을 때 설명할 근거가 부족하다.

PonsWarp가 작은 제품이라는 점도 여기서는 장점이 된다. 거대한 범용 전송 플랫폼처럼 모든 조합을 한 번에 제공할 필요가 없다. 먼저 “지금은 직접 연결을 시도한다”, “필요하면 서버 경유로 전환한다”, “서버 경유 시 비용과 개인정보 문구가 달라진다”는 세 문장을 맞추면 된다. 지금 기준으로는 WebTransport가 WebRTC를 대체한다고 말하지 않는 편이 정확하다. WebTransport/QUIC은 서버 endpoint가 자연스러운 기능에서 좋은 선택지가 되고, WebRTC는 브라우저끼리 직접 연결해야 하는 장면에서 여전히 별도의 역할을 가진다.

판단의 중심은 API 취향이 아니라 서버를 경유해도 되는 기능인지, 그리고 그 경유를 사용자와 운영 로그가 설명할 수 있는지다. P2P를 설명할 때 서버/클라이언트/사용자 중 누구 문장으로 말하는지 먼저 고르면 논쟁이 줄었다.

프로토콜 관점에서 본 차이

서버를 경유하는 것이 항상 나쁜 것도 아니다. 비동기 수신, 모바일 백그라운드, 잠깐의 edge buffer가 필요한 기능에서는 서버 endpoint가 오히려 안정적인 사용자 경험을 만든다. 문제는 그것을 WebRTC 대체재라고 부르며 같은 약속처럼 보이게 만드는 순간이다. *WebTransport, QUIC, WebRTC를 API 모양이 아니라 연결 대상과 책임 위치로 나눠 보기 위한 흐름 노트. direct 모드와 서버 경유 모드를 화면에서 분리하면 운영 판단도 쉬워진다.

direct 모드가 실패해 TURN으로 갔는지, 서버 경유 모드를 처음부터 선택했는지, 모바일 백그라운드 때문에 edge buffer를 썼는지 로그가 달라진다. 같은 완료율이라도 비용과 설명 책임은 다르다. 비교표를 그리면 질문이 바뀐다. 더 깔끔한 API인가, 아니면 서버를 경유해도 되는 기능인가? WebTransport는 브라우저와 서버 endpoint 사이를 잘 다루는 쪽에 가깝고, WebRTC는 브라우저끼리 연결하려는 모델 안에 NAT traversal, ICE, STUN, TURN을 끌고 온다.

이 질문은 비교를 단순하게 만든다. 서버를 경유해도 되는 기능이라면 WebTransport/QUIC의 단정함이 장점이 된다. 반대로 직접 전달 약속이 핵심이면 WebRTC의 복잡함은 피해야 할 잡음이 아니라 제품이 받아들인 책임이다.

브라우저가 주는 제약

그래서 비교의 첫 줄은 성능 숫자가 아니라 제품 약속이어야 한다. 파일이 반드시 브라우저끼리만 지나가야 하는가. 서버가 잠깐 보관하거나 relay해도 되는가. 사용자가 모드 전환을 알아야 하는가. 이 질문에 답하지 않고 API 모양만 보면 WebTransport는 늘 깔끔해 보이고 WebRTC는 늘 복잡해 보인다. 모드 이름을 먼저 정하면 테스트 시나리오도 선명해진다. direct 모드에서는 상대 브라우저가 열려 있는지와 ICE 시간이 중요하다.

relay 모드에서는 서버 endpoint 연결 시간과 byte 비용이 중요하다. edge buffer 모드에서는 보관 시간, 만료 문구, 다시 받기 흐름이 중요하다. WebTransport 실험은 WebRTC와 같은 파일을 보내게 해 놓고 비교해야 한다. 서버 endpoint 경로, WebRTC direct 경로, TURN으로 떨어지는 경로를 나란히 둔다. 같은 bytes를 보냈더라도 연결 대상, 비용, 개인정보 문구, 회복 경로가 다르기 때문이다. 장애 문구는 특히 조심해야 한다. “연결 실패”라고만 쓰면 사용자는 다시 누르는 것 말고 할 일이 없다.

direct 후보를 찾는 중인지, TURN으로 전환하는 중인지, 서버 경유 모드를 준비하는 중인지 알려 주면 같은 실패도 기다림, 재시도, 모드 변경으로 나뉜다. 그래서 PonsWarp에서는 프로토콜 이름을 전면에 내세우기보다 모드 이름을 먼저 둔다. direct, relay, edge buffer 같은 이름은 완벽하지 않지만 운영 로그와 사용자 문구를 연결하기 쉽다. 이 연결이 있어야 WebTransport와 WebRTC를 한 화면 안에서 같이 실험할 수 있다.

'[P2P 프로토콜 WebTransport와 QUIC은 WebRTC를 대체할까'을 관통하는 질문은 이 섹션에서도 같았고, 답만 더 구체적이 됐다.

설계할 때 던져야 할 질문

이전 글에서 libp2p를 transport, security, discovery 경계로 나눠 봤다면, 여기서는 그중 전송 경계가 브라우저 제품에서 어디까지 책임지는지 좁혀 본다. 비교표에는 평균 전송률보다 전환 순간을 더 앞에 둔다. direct 시도 시작, ICE 완료, TURN 전환, server endpoint 연결, 첫 byte, 사용자 문구 변경 시각을 나란히 둔다. 이 순서가 있어야 WebTransport와 WebRTC를 승부처럼 보지 않고 제품 모드처럼 다룰 수 있다. 구현 전에 WebTransport, QUIC, WebRTC, NAT, server endpoint의 책임을 다시 묻기 위한 점검표. 이 표가 있어야 기능 플래그도 의미가 생긴다.

QUIC 경로를 탄 사용자를 모르면 점진 배포, 롤백, 비용 제한이 모두 어색해진다. WebRTC fallback을 남겨도 어떤 조건에서 fallback했는지 모르면 다음 개선이 어렵다. 이 차이는 개인정보 문구와 비용 모델까지 내려간다. WebRTC direct 경로에서는 서버가 signaling을 돕더라도 payload가 peer 사이로 흐를 수 있다. WebTransport 경로에서는 서버 endpoint가 전송 경로의 중심에 가까워진다. 둘 다 암호화와 권한 설계가 필요하지만, 사용자가 기대하는 “직접 전달”의 의미는 달라진다.

비용 제한도 같은 방식으로 본다. WebRTC direct가 성공하면 서버 byte는 줄 수 있지만 ICE 실패와 TURN 전환이 잦으면 운영 비용은 다른 곳에서 생긴다. WebTransport는 endpoint가 단정하지만 relay byte와 edge buffer 비용을 숨길 수 없다. 둘 다 공짜가 아니므로 완료율과 함께 비용 위치를 기록해야 한다.

이어서 보면 좋은 글

WebTransport와 QUIC을 처음 봤을 때는 WebRTC보다 훨씬 단정해 보였다. HTTP/3 위에서 stream과 datagram을 다루고, head-of-line blocking을 줄이고, 브라우저 API도 DataChannel보다 명확해 보였다. 그래서 한동안은 WebRTC 파일 전송의 더 깔끔한 대체재가 될 수 있지 않을까 생각했다. p2p-protocol-0 서버 endpoint가 먼저 있는 전송과 peer candidate를 모아야 하는 전송은 실패하는 위치가 다르다. WebTransport는 endpoint에 붙지 못하면 시작부터 서버 경로 문제로 보인다. WebRTC는 ICE 후보 수집, STUN 응답, TURN 전환, 상대 피어 이탈 같은 사건을 거친다. 어느 쪽이 낫다는 말보다 어떤 책임을 제품이 받아들일 수 있는지가 먼저다. 깔끔한 API는 중요한 장점이다. 다만 API가 단정하다는 이유만으로 peer-to-peer 요구사항이 사라지지는 않는다. 빠른 전송과 직접 연결은 같은 요구사항이 아니다. 측정값은 server endpoint 연결 시간, ICE 후보 수집 시간, TURN 전환 비율, QUIC stream 재시도, 사용자에게 보이는 모드 전환 횟수로 나눠 본다. API가 깔끔하다는 느낌은 이 조건을 통과해야 제품 판단이 된다.

마치며

이 글에서 확인한 경계는 다음 변경의 기준으로 남겼다.