지난 16년 동안, 서버에 복잡한 질문을 던져야 했던 개발자들은 우회적인 방법에 의존해야 했습니다. URL에 담기에는 검색 페이로드가 너무 커지거나, 중첩된 필터와 민감한 파라미터가 쿼리 스트링에 다 들어가지 않을 때, 유일하고 실질적인 선택지는 POST였습니다. POST는 바이트를 전달할 수는 있었지만, 그 의도에 대해서는 거짓을 말했습니다. POST는 상태의 변화를 의미합니다. 이를 읽기 전용 작업에 사용하면 캐시, 프록시, 브라우저를 포함한 전체 네트워크 경로가 단순한 조회 작업을 마치 데이터베이스를 변경할 수도 있는 작업처럼 취급하게 만듭니다.

그 타협은 마침내 끝났습니다. 2026년 6월, IETF는 QUERY 메서드를 공식 표준화한 RFC 10008을 발표했습니다. 이는 2010년 PATCH가 도입된 이후 처음으로 등장한 새로운 HTTP 메서드입니다. QUERY는 본문(body)이 필요한 안전하고 멱등성(idempotent)이 보장되는 요청을 위해 특별히 존재합니다. 서버의 상태를 변경하지 않습니다. 동일한 요청을 반복해도 동일한 결과가 생성됩니다. 또한 캐싱이 가능하므로 중간 매개체(intermediaries)가 응답을 저장하고 재사용할 수 있습니다. 그리고 GET과 달리 POST처럼 데이터 페이로드를 허용합니다.

GraphQL 쿼리와 복잡한 REST 검색 엔드포인트가 가장 큰 수혜를 입을 것입니다. 더 이상 60개의 쿼리 파라미터를 URL에 억지로 밀어 넣거나, 중간 매개체가 캐싱을 거부하는 POST 본문 안에 JSON 필터 문서를 숨길 필요가 없습니다. 이제 의미론(semantics)이 정직해졌습니다.

하지만 RFC는 단지 문서상의 기록일 뿐입니다. 애플리케이션과 사용자 사이에는 두꺼운 인프라 계층이 존재하며, 그 대부분은 QUERY라는 개념을 들어본 적도 없습니다.

캐싱 문제는 아직 해결되지 않았습니다

GET 요청의 경우 캐싱은 간단합니다. 캐시 키는 URI입니다. 헤더가 허용한다는 가정하에, 동일한 URL에 접속하는 두 사용자는 동일하게 저장된 응답을 받게 됩니다.

QUERY는 요청 파라미터가 본문에 존재하기 때문에 이 모델을 깨뜨립니다. 캐시가 두 요청이 동일하다는 것을 인식하려면, 캐시 키에 URI와 본문 내용이 모두 포함되어야 합니다. 이러한 요구 사항은 실제 운영상의 마찰을 야기합니다.

첫째, 에지 서버와 CDN은 해시를 계산하기 전에 전체 요청 본문을 버퍼링해야 합니다. 이는 에지 노드에서 메모리와 시간을 소모합니다. 둘째, 논리적으로 동일한 두 쿼리가 동일한 바이트를 생성하지 않을 수 있습니다. 한 클라이언트는 {"status":"active"}를 보내는 반면, 다른 클라이언트는 공백이나 키 순서가 다른 {"status": "active"}를 보낼 수 있습니다. 캐싱 계층이 본문을 파싱하고, 정규화(normalize)하고, 정형화(canonicalize)하여—JSON 키를 정렬하고, 불필요한 서식을 제거하며, 인코딩 차이를 처리하지 않는 한—동일한 질문이라도 매번 캐시를 놓치게 될 것입니다.

가장 결정적으로, 주요 CDN들은 아직 QUERY를 위해 요청 본문에 따라 캐시를 분할하지 않습니다. 예를 들어 Cloudflare는 현재 형태에서 이 메서드의 본문을 캐시 키의 일부로 취급하지 않습니다. '캐싱 가능하다'는 것이 곧 '캐시된다'는 의미라고 가정하고 QUERY를 배포한다면, 충돌 오류, 광범위한 캐시 미스(cache miss), 또는 관련 없는 요청 간에 응답이 유출되는 현상을 겪을 수 있습니다. 서비스 제공업체가 명시적인 지원을 발표하기 전까지는, 운영 환경에서 QUERY가 유의미하게 캐싱된다고 가정하지 마십시오.

사용 중인 도구들이 먼저 차단할 가능성이 높습니다

모든 HTTP 요청은 일련의 미들박스(middleboxes)를 통과하며, 그중 대부분은 허용되는 메서드에 대해 엄격한 규칙을 적용합니다.

웹 애플리케이션 방화벽(WAF)과 API 게이트웨이는 종종 명시적인 허용 목록(allowlist)에 의존합니다. 일반적인 규칙 세트는 GET, POST, PUT, DELETE, PATCH를 허용합니다. 그 외의 것은 차단되거나 405 Method Not Allowed 응답을 받게 됩니다. QUERY는 애플리케이션 코드에 도달하기도 전에 이러한 장벽에 부딪힐 것입니다.

보안 규칙 엔진은 또 다른 장애물이 됩니다. 일부 침입 탐지 시스템은 본문을 포함하는 요청이