WebTransport 세션 통합: 시작·종료와 호환성 확인
W3C API 명세와 HTTP/3 프로토콜 초안의 상태를 구분하고, 브라우저 기능 감지·세션 수명주기·서버 연동을 점검하는 방법을 설명합니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
WebTransport를 앱에 붙일 때는 브라우저가 세션을 만들 수 있는지, 서버가 같은 프로토콜을 받아들이는지, 연결을 어떤 시점에 정리할지 확인합니다. W3C API 명세는 세션·연결·종료 상태를 정의하고, IETF 문서는 HTTP/3에서 이를 운반하는 프로토콜 절차를 다룹니다. 두 문서의 표준화 상태와 실제 브라우저·서버 지원은 서로 다른 확인 항목입니다.
API 문서와 프로토콜 문서의 상태부터 구분하기
W3C WebTransport 문서는 2026년 7월 30일자 Candidate Recommendation Snapshot이며, W3C Recommendation을 목표로 폭넓은 검토와 상호운용 구현을 모으는 단계입니다. 아직 최종 Recommendation으로 표시된 문서는 아닙니다. 한편 IETF의 draft-ietf-webtrans-http3-16은 2026년 7월 6일 갱신된 Active Internet-Draft로, 당시 WG Last Call 상태이고 2027년 1월 7일 만료 예정인 작업 문서입니다. W3C API 단계와 IETF HTTP/3 프로토콜 초안을 하나의 “확정 표준”으로 합쳐 부르면 안 됩니다.
역할이 다릅니다. W3C 명세는 생성자와 ready·closed 등 JavaScript API 동작을, IETF 초안은 HTTP/3 세션 협상을 정의합니다.
세션을 만들고 서버 협상을 확인하기
MDN의 HTTP/3 사용 예에서는 HTTPS URL과 명시적인 포트를 WebTransport() 생성자에 전달합니다. 객체를 만든 순간이 연결 완료를 뜻하지는 않습니다. 애플리케이션은 transport.ready가 이행된 뒤 세션 기능을 사용하고, 거부되는 경우 인증서·네트워크·서버 응답 등 실제 실패를 처리해야 합니다. 서버 이름과 경로가 배포 환경에서 가리키는 대상도 함께 확인합니다.
브라우저는 WebTransport임을 나타내는 확장 CONNECT 요청을 보내고, 서버는 :protocol 정보를 확인해 요청을 처리합니다. 브라우저 요청의 Origin도 서버가 검증해야 하며, 서버가 세션을 수락해야 클라이언트와 데이터를 주고받을 수 있습니다. 그러므로 클라이언트 API 호출만 성공하도록 흉내 내는 테스트로는 충분하지 않습니다. 타깃 서버가 실제 요청을 수락하고 세션이 준비되는지 확인합니다.
애플리케이션 프로토콜 이름을 협상한다면 생성자에 제안 목록을 전달하고, ready 이후 transport.protocol에서 서버가 선택한 값을 확인할 수 있습니다. 값이 비어 있을 수도 있으므로 앱은 협상이 되지 않은 경우의 동작도 정의해야 합니다. 이 검사는 양쪽이 같은 애플리케이션 메시지 규약을 이해하는지 확인하는 단계입니다.
연결 상태와 종료를 앱 수명주기에 연결하기
ready는 세션이 성립해 사용할 수 있게 되는 시점을 나타내고, closed는 종료 결과를 비동기로 전달합니다. 정상 종료 정보가 도착할 수도 있고, 갑작스러운 네트워크 실패처럼 거부로 나타나는 경우도 있습니다. UI의 “연결 중” 상태를 생성자 호출만으로 “연결됨”으로 바꾸지 말고, 준비 실패와 연결 이후 종료를 각각 처리해야 재시도나 사용자 안내를 구분할 수 있습니다.
W3C API 명세는 서버가 세션을 점진적으로 닫는 상황을 나타내는 draining도 정의합니다. 이를 활용할 경우 실제 대상 브라우저에서 해당 속성이 지원되는지 먼저 확인해야 합니다. 앱이 더는 세션을 쓰지 않을 때는 close()를 호출하고, closeCode와 reason을 운영상 식별 가능한 수준으로 설정합니다. 종료 뒤에는 화면 상태·타이머·리더와 애플리케이션 작업도 정리해야 합니다. close()를 연결이 아직 진행 중일 때 호출하는 경로는 별도의 초기화 취소 흐름으로 시험합니다.
기능 감지와 실제 상호운용성 시험
MDN은 WebTransport API를 2026년 Baseline에 새로 포함된 기능으로 표시하면서, 일부 기능의 지원 수준이 다를 수 있고 오래된 브라우저에서는 동작하지 않을 수 있다고 설명합니다. API는 보안 컨텍스트에서만 제공되므로 HTTPS도 전제 조건입니다. 실행 전 typeof WebTransport === "function" 같은 기능 감지와 isSecureContext를 확인하되, 객체가 존재한다는 사실만으로 연결이나 서버 호환성이 보장된다고 보지 않습니다.
배포 전에는 대상 브라우저와 버전, 인증서가 설정된 HTTPS 엔드포인트, 서버의 HTTP/3 WebTransport 처리, Origin 정책, 프록시·로드밸런서 경로를 함께 시험합니다. ready 이행과 거부, 서버가 선택한 protocol, 정상 closed, 예기치 않은 종료, 재연결을 확인하고 환경별 결과를 기록합니다. MDN의 Baseline 안내는 최신 기기와 브라우저에서의 현재 가용성을 요약하지만, 앱이 사용하는 모든 API 구성요소나 사용자의 배포 경로를 대신 검증하지는 않습니다.
전문가 관점: 호환성은 브라우저 체크 하나로 끝나지 않는다
W3C 문서는 API 상태 전이와 사용자 에이전트 동작을, IETF 초안은 HTTP/3 세션 협상을, MDN은 웹 개발자가 만나는 보안 컨텍스트와 구현별 지원 주의점을 보여 줍니다. 이 세 층을 구분하면 기능 부재, 세션 협상 실패, 애플리케이션 프로토콜 불일치를 서로 다른 문제로 진단할 수 있습니다. 출시 판단은 실제 타깃 브라우저와 서버 조합의 시험 결과에 두고, 각 표준 문서의 상태와 날짜도 함께 기록합니다.