HTTP/2 리소스 우선순위: RFC 9218의 urgency와 incremental
RFC 9218은 HTTP/2에서 요청 리소스의 상대적 처리 선호를 전달하는 확장 가능한 방식을 정의합니다. urgency와 incremental의 의미, 서버가 우선순위 힌트를 실제 스케줄링으로 연결할 때의 한계를 살펴봅니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
HTTP/2의 다중화는 여러 요청을 한 연결에서 처리하지만, 어떤 응답 데이터를 먼저 보낼지는 별도의 스케줄링 문제입니다. RFC 9218은 클라이언트와 중간 처리자가 HTTP 응답의 상대적 우선순위 선호를 표현하는 공통 방식을 정의합니다. 이 값은 서버가 참고할 신호이지, 특정 리소스가 반드시 먼저 도착한다는 보장은 아닙니다. 브라우저가 보낸 선호와 서버의 실제 작업 큐, 네트워크 상태, 애플리케이션 정책이 함께 결과를 결정합니다.
1. 기존 의존성 트리 방식의 한계와 새 모델
이전 HTTP/2 우선순위 모델은 스트림 간 의존성과 가중치 트리를 표현했습니다. 하지만 브라우저와 서버가 같은 트리를 유지하지 않거나, 리소스 요청이 지연된 뒤 트리가 바뀌면 구현 간 해석 차이가 생길 수 있었습니다. RFC 9218은 복잡한 트리 상태 대신 각 응답에 대한 단순한 선호 속성을 전달하도록 설계되었습니다. 기존 구현과의 전환 과정에서는 예전 프레임이 계속 관찰될 수 있지만, 새 Priority 필드와 업데이트 프레임을 사용하는 쪽이 명시적인 신호가 됩니다.
이 변경은 전송 계층이 데이터를 자동 정렬한다는 뜻이 아닙니다. HTTP/2는 여전히 한 TCP 연결 위에서 스트림을 다중화하고, 서버 구현이 어떤 응답을 언제 프레임으로 만드는지가 중요합니다. 따라서 우선순위 프로토콜을 지원하는 것과 사용자에게 보이는 로딩 순서를 바꾸는 것은 별개의 단계입니다. 지원 여부뿐 아니라 실제 브라우저 요청과 서버 스케줄러가 신호를 어떻게 반영하는지 확인해야 합니다.
2. urgency와 incremental을 읽는 방법
Priority 필드의 u 매개변수는 urgency를 나타내며 0부터 7까지의 값을 사용합니다. 값이 작을수록 더 급한 응답이라는 선호를 표현하고, 생략하면 기본값은 3입니다. i 매개변수는 incremental 처리를 나타냅니다. 생략하면 false이며, true 값은 i=?1로 표현합니다. 참이면 응답을 한 번에 완성하기보다 일부를 먼저 전달하고 다른 응답과 번갈아 진행하는 방식이 적절할 수 있음을 알립니다. 예를 들어 큰 이미지나 스트리밍 응답과 같이 점진적으로 소비할 수 있는 데이터는 작은 완결형 리소스와 다른 스케줄링 선호를 가질 수 있습니다.
이 값들은 애플리케이션의 중요도를 완벽하게 측정하지 않습니다. 급한 리소스가 실제로 어떤 사용자 동작을 막는지, 응답 크기가 얼마나 되는지, 다른 요청과 어떤 관계인지 판단하는 것은 브라우저와 서버의 맥락에 달려 있습니다. 값은 순서표나 예약 시간을 뜻하지 않으며, 서버는 자체 정책과 현재 자원 상황을 고려해야 합니다. 그러므로 특정 urgency를 부여했다고 해서 렌더링 시점이 고정된다고 설명해서는 안 됩니다.
3. 요청 이후에도 바뀔 수 있는 우선순위
문서 파싱 초기에는 브라우저가 모든 리소스의 역할을 알지 못할 수 있습니다. CSS, 이미지, 스크립트의 발견 시점이나 화면의 가시 영역에 따라 필요한 우선순위가 달라질 수 있으므로, RFC 9218은 초기 선호를 전달하는 필드와 연결 중 우선순위를 갱신하는 HTTP/2·HTTP/3 프레임을 정의합니다. 서버는 이 정보를 보고 아직 보내지 않은 응답의 스케줄을 조정할 수 있지만, 이미 전송된 바이트를 과거로 돌리지는 못합니다.
운영에서는 갱신 메시지가 실제로 도착하는지, 프록시나 CDN이 이를 보존하는지, 원본 서버가 큐에 반영하는지 확인해야 합니다. Cloudflare의 배포 설명은 브라우저가 제시한 우선순위와 서버 측 처리 방식이 맞물려야 체감 성능에 영향이 나타난다는 점을 보여 줍니다. 서버가 Priority 필드를 받더라도 이를 무시하거나 다른 기준과 결합할 수 있기 때문에, 패킷 캡처만으로 개선을 단정하지 말고 브라우저 성능 기록과 실제 요청 순서를 함께 비교해야 합니다.
4. 전문가 관점: 성능 최적화에서 검증할 항목
먼저 주요 페이지에서 브라우저가 보내는 Priority 값과 요청 발생 시점을 수집합니다. 이후 서버가 각 응답을 프레임화하는 순서, 응답 완료 시간, 주요 렌더링 지표를 같은 조건의 비교군과 대조합니다. 캐시 적중, 연결 재사용, CDN 동작, 네트워크 혼잡처럼 결과를 바꿀 수 있는 변수를 기록하고, 큰 응답을 incremental로 처리했을 때 작은 핵심 응답이 실제로 더 빨리 끝나는지도 관찰합니다.
우선순위는 리소스 큐를 조정하는 입력 중 하나입니다. 대역폭이 이미 충분하거나 서버가 모든 응답을 거의 동시에 생성한다면 차이가 작을 수 있고, 잘못 분류한 리소스는 중요한 응답을 늦출 수 있습니다. 따라서 초기 설정을 전 페이지에 일괄 적용하기보다 핵심 경로 몇 개에서 관측 자료를 수집하고 조정하는 편이 안전합니다. RFC의 의미, 브라우저의 실제 신호, 서버 구현의 정책을 각각 구분해 진단하면 “HTTP/2가 자동으로 중요한 파일을 먼저 보낸다”는 오해를 피할 수 있습니다.