새로운 HTTP 메서드: "QUERY"

2026년 6월, HTTP QUERY 메서드가 RFC 10008로 새롭게 발행되었다. 엄밀히는 IETF 표준화 트랙의 첫 단계인 Proposed Standard 상태라 아직 '완성된 표준'이라 부르기는 이르지만, 어쨌든 공식 문서로 세상에 나온 것이다. 왜 새로운 HTTP 메서드가 나왔는지, 그리고 무엇이 변하는지에 대해서 알아보자.

왜 나왔는가

갑자기 잘 쓰던 HTTP 메서드에 왜 새로운 메서드를 추가하게 되었는지를 설명하기 위해서는 GET의 작동 방식에 대해서 설명해야 한다.

GET은 문자 그대로 어떤 데이터를 가져오거나 조회할 때 사용되는 메서드이다. 단순 유저 정보 조회부터 검색까지 광범위하게 사용된다.

이때 GET의 가장 큰 특징은 쿼리 파라미터로 요청을 처리한다는 것이다. 예를 들어서 게시글 제목 검색 API가 있다고 하면

/post?title=

이런 식으로 요청을 하는 식이다.

문제는 검색 필터가 늘어날 경우 쿼리 파라미터 또한 필연적으로 매우 길게 늘어나게 되면서 URL 전체 크기가 거대해진다는 것이다. 단순히 보기 안 좋은 수준의 문제가 아니라, 서버나 프록시가 허용하는 URL 길이 제한을 넘기면 414 URI Too Long으로 요청 자체가 거부될 수도 있다.

그 외에도 비-ASCII 문자 인코딩으로 인한 요청 크기 증가, 미들웨어가 파라미터를 로그로 남기는 보안 이슈, 그리고 배열·중첩 구조 표현 방식이 표준화되어 있지 않다는 점이 있다.

GET과 Request Body

GET의 특징을 읽고 나면 아래 질문이 자연스럽게 떠오른다.

그냥 GET에 바디를 담으면 안돼나?

우선 HTTP RFC에서 GET에 바디를 명시적으로 금지하는 것은 아니지만 사용하지 않을 것을 '권고'하고 있다. 문제는 이 권고 탓에 클라이언트, 웹서버, 프록시마다 처리가 제각각이라는 점이다. 어떤 구현은 바디가 담긴 GET을 아예 거부하고, 어떤 구현은 바디를 조용히 버리며, 또 어떤 구현은 그대로 해석한다. 따라서 GET에 바디는 신뢰성이 떨어지고 동작을 보장하기 힘들어서 사용하지 않는다.

POST 문제

그래서 바디를 담아야 할 경우 개발자들은 어쩔 수 없이 POST를 사용하고는 했다. 하지만 POST는 정의상 데이터의 생성 및 처리를 위한 메서드이고, 무엇보다 멱등(idempotent)하지 않다는 게 문제다.

여기서 잠깐 두 개념을 짚고 가자. safe(안전)는 요청이 서버의 상태를 바꾸지 않는다는 뜻이고, idempotent(멱등)는 같은 요청을 몇 번 보내든 결과가 동일하다는 뜻이다. GET이 실패해도 마음 놓고 재시도할 수 있고 중간에 캐싱이 되는 이유가 바로 이 두 속성 덕분이다.

POST는 이 둘을 보장하지 않는다. 그래서 실패 시 자동으로 재시도하면 데이터가 중복 생성되는 식의 부수효과가 생길 수 있어 재시도가 까다롭고, 프록시나 미들웨어 입장에서도 이게 읽기 전용 요청인지 알 수 없으니 자동 캐싱 또한 불가능하다.

QUERY

위에 있었던 기존 GET 메서드의 문제점과, 이를 해결하기 위한 차선책이었던 POST의 한계를 모두 극복하기 위해 새롭게 발행된 메서드가 바로 QUERY 메서드이다.

GET처럼 데이터를 조회할 때 사용하지만 가장 큰 차이점은 바디를 가질 수 있다는 점이고, 동시에 RFC상 safe하고 idempotent하도록 정의되어 있다.

즉 '바디를 담을 수 있으면서 동시에 safe + idempotent한 메서드'인데, 사실 지금까지 이 조건을 한 번에 만족하는 메서드는 없었다.

POST는 바디는 되지만 멱등하지 않았고, GET은 멱등하지만 바디가 안 됐다. QUERY가 딱 그 빈칸을 채운 셈이다.

실제 요청은 대략 이렇게 생겼다.

QUERY /posts HTTP/1.1
Content-Type: application/json

{
  "title": "검색어",
  "tags": ["notice", "event"],
  "filters": { "createdAfter": "2026-01-01" }
}

메서드 이름만 빼면 POST와 거의 똑같아 보이지만, 이 한 글자 차이로 '이건 읽기 전용이고 몇 번을 재시도해도 안전하다'는 의미가 클라이언트·서버·프록시·CDN 모두에게 전달된다.

다만 캐싱에는 주의할 점이 있다. QUERY 응답도 캐시할 수 있지만, 데이터가 URL이 아니라 바디에 들어있기 때문에 캐시 키에 요청 바디까지 반드시 포함해야 한다.

그래서 URL만 키로 쓰면 되는 GET보다 캐싱 구현이 조금 더 까다롭다. 바디를 정규화(JSON 키 정렬, 공백 제거 등)해줘야 캐시 적중률도 올라간다.

가장 와닿는 예시는 GraphQL이다. GraphQL은 사실상 조회 요청까지 전부 POST로 보내는데, 그 탓에 HTTP 레벨의 캐싱 이점을 못 누리는 게 고질적인 문제였다.

QUERY를 쓰면 쿼리 언어 자체는 그대로 둔 채로 이 문제를 깔끔하게 풀 수 있는 길이 열린다.

결론

물론 QUERY가 발표됐다고 해서 모든 라이브러리나 프레임워크가 곧바로 지원하는 것은 아니다. 다만 좀 더 정확히 짚자면, HTTP 메서드는 결국 문자열이기 때문에 임의 메서드를 허용하는 클라이언트(Go의 net/http, Rust의 reqwest, curl 등)는 사실 지금도 QUERY를 보낼 수 있다.

느린 쪽은 메서드의 '의미'를 이해해야 하는 프록시, 캐시, 그리고 프레임워크의 라우팅·시맨틱이다. 즉 '보내는 것 자체는 지금도 되지만, 생태계가 제대로 정착하기까지는' 시간이 걸린다는 얘기다.

개인적으로는 인프라가 충분히 갖춰지기까지 최소 2~3년 정도는 걸리지 않을까 예상해 본다. 다만 RFC 저자에 Cloudflare와 Akamai 같은 CDN 사업자가 포함되어 있는 걸 보면, 프레임워크 통합보다 CDN 레벨의 지원이 먼저 도착할 가능성도 있어 보인다.

그리고 QUERY가 만능은 아니다. 예를 들어 필터링된 결과를 링크로 공유하거나 북마크해야 하는 경우라면, 데이터가 바디에 들어가는 QUERY로는 불가능하니 기존처럼 GET을 쓰는 게 맞다.

잘 쓰던 URL 파라미터 기반 GET을 무리해서 전부 QUERY로 바꿀 필요는 없다는 뜻이다.

그럼에도 기존 GET의 문제점을 보완한 메서드가 나왔다는 건 반가운 일이고, 제대로 정착하기만 한다면 꽤 쓸모 있을 듯하다.

출처: https://kreya.app/blog/new-http-query-method-explained/
RFC 10008: https://www.rfc-editor.org/info/rfc10008/