2026년 6월, IETF가 RFC 10008을 공식 발행하면서 HTTP에 새로운 메서드 QUERY가 등장했다. 2010년 PATCH 이후 16년 만에 등장한 표준 HTTP 메서드다. 프론트엔드 개발자 입장에서 이 소식이 흥미로운 이유는 단순히 '새 메서드가 생겼다'는 사실 때문이 아니다. QUERY는 우리가 오랫동안 불편함을 참으며 써온 POST-for-search 패턴의 구조적 문제를 정면으로 해결하는 메서드이기 때문이다.
QUERY의 핵심은 조합이다. GET처럼 안전하고(Safe) 멱등성(Idempotent)을 가지며 캐시 가능(Cacheable)하면서도, POST처럼 요청 바디를 가질 수 있다. 복잡한 필터 조건이나 중첩된 객체를 URL 쿼리스트링에 욱여넣다가 브라우저·프록시마다 제각각인 2~8KB 길이 제한에 막혀본 경험이 있다면, 이 조합이 얼마나 우아한 해법인지 바로 느낄 수 있다. GraphQL 생태계가 특히 큰 수혜자가 될 텐데, 지금까지 읽기 작업임에도 POST를 써야 했던 이유가 오직 '바디를 실어야 해서'였기 때문이다. QUERY는 그 read path에 의미론적으로 올바른 자리를 마련해 준다.
그런데 dev.to의 분석 글이 정확하게 짚듯, 스펙과 현실 사이의 간극이 문제다. RFC는 완성됐지만 당신의 인프라는 아직 준비가 안 되어 있을 가능성이 높다. 세 가지 현실적인 걸림돌을 살펴보자.
첫 번째는 캐싱 레이어의 미준비다. GET에서 캐시 키는 URL 하나면 충분했다. 하지만 QUERY에서는 요청 바디가 요청의 '정체성'을 결정하기 때문에, 캐시 키를 URL과 바디의 해시 조합으로 재구성해야 한다. 더 나아가 의미론적으로 동일한 JSON 페이로드(키 순서나 공백이 다른 경우)를 동일한 캐시 항목으로 처리하는 정규화 로직도 필요하다. Cloudflare Workers의 현재 캐시 키 구현은 path와 query string 기반으로만 작동한다. Cloudflare와 Akamai 엔지니어가 RFC 공동 저자로 참여했다는 점은 엣지 레벨 지원이 빠르게 따라올 신호지만, 지금 당장 'QUERY는 캐시 가능하다'는 명제를 프로덕션에서 신뢰하는 건 시기상조다.
두 번째는 WAF와 보안 레이어의 오탐 문제다. 대부분의 WAF, API 게이트웨이, 로드 밸런서는 허용 메서드 목록을 GET POST PUT DELETE PATCH 수준으로 명시해둔다. 알 수 없는 메서드가 들어오면 조용히 드롭하거나, 더 나쁜 경우엔 잘못된 경로로 보내버린다. CORS도 문제다. QUERY는 CORS 안전 목록(safelisted)에 없어서 브라우저는 반드시 OPTIONS 프리플라이트를 먼저 날린다. 인프라가 이 프리플라이트에 올바르게 응답하지 못하면 요청 자체가 막힌다. CSRF 미들웨어도 마찬가지로 '안전 메서드 = 바디 없음 = CSRF 위험 없음'이라는 가정을 깔고 설계된 경우가 많아서 점검이 필요하다.
세 번째는 클라이언트 레벨 지원 부재다. 브라우저 fetch() API는 아직 QUERY를 네이티브로 지원하지 않는다—WHATWG가 움직여야 한다. curl과 HTTP 라이브러리 수준의 지원은 따라오고 있고, .NET 10은 이미 지원을 시작했지만 대부분의 프레임워크는 아직 미완이다.
여기서 '98% 지원율' 문제가 교차한다. whynothugo.nl에서 정리한 논점처럼, 기술 지원율은 숫자 자체보다 맥락이 훨씬 중요하다. 전 세계 브라우저 기준 98%가 어떤 기능을 지원한다고 해도, 특정 사이트의 실제 방문자 분포에서는 70%에 그칠 수 있다. nested CSS의 사례가 그랬다. QUERY도 마찬가지다. CDN이 '지원한다'고 공식 발표하는 시점이 와도, 내 서비스 앞단 WAF의 allowlist를 직접 업데이트하기 전까지는 해당 트래픽이 실제로 통과한다고 볼 수 없다. 글로벌 통계가 아니라 내 스택의 동작을 직접 검증하는 습관이 중요한 이유다.
그렇다면 지금 프론트엔드 개발자가 할 수 있는 실질적인 준비는 무엇일까?
지금 당장 해야 할 것: WAF, API 게이트웨이, CDN 설정을 열어서 알 수 없는 HTTP 메서드가 들어왔을 때 어떻게 처리되는지 확인하라. 405 응답인지, 조용한 드롭인지, 아니면 통과인지. 405가 나온다면 그나마 낫다—적어도 실패가 명시적이다. 조용한 드롭은 디버깅 지옥의 시작이다.
중기적으로 준비할 것: 지금 POST로 복잡한 검색·필터를 구현하고 있다면 QUERY로의 마이그레이션 경로를 설계해두되, 실제 전환은 프레임워크와 CDN의 공식 지원 발표를 확인한 후로 미뤄도 충분하다. 브라우저 fetch() 지원도 변수이므로 폴리필이나 래퍼 레이어를 먼저 추상화해두는 게 안전하다.
GraphQL을 쓰고 있다면: 가장 직접적인 수혜자가 될 수 있다. 쿼리 작업(reads)을 QUERY로 전환하면 HTTP 레벨 캐싱과 안전한 재시도를 자연스럽게 얻을 수 있다. 다만 역시 인프라 지원이 선행되어야 한다.
새로운 표준이 등장할 때마다 반복되는 패턴이 있다. 스펙은 완성되지만, 생태계가 따라오는 데는 항상 시간이 걸린다. HTTP QUERY도 예외가 아니다. 2010년 PATCH가 표준화된 후에도 많은 인프라가 오랫동안 이를 제대로 처리하지 못했다는 걸 기억할 필요가 있다.
중요한 건 QUERY를 쓸 수 있게 될 때를 막연히 기다리는 게 아니라, 지금 내 스택이 어떤 상태인지 파악해두는 것이다. 새 표준을 도입할 때 가장 큰 리스크는 기술 자체가 아니라, 준비됐다고 착각하는 데서 온다. 지금 WAF allowlist를 확인하고, 프레임워크와 CDN 체인지로그를 구독해두는 것—이 작은 습관이 QUERY가 실제로 쓸 수 있게 되는 날, 당신의 팀이 가장 빠르게 움직일 수 있는 토대가 된다.