IT

[HTTP Method] 새로운 HTTP 메서드의 등장: 대용량 조회를 위한 QUERY 메서드 이해하기

Hans L 2026. 6. 28. 14:37

안녕하세요, Hans 입니다.

최근 HTTP 스펙을 관리하는 IETF(국제 인터넷 표준화 기구)에서 공식 표준화(RFC 10008) 과정을 거치며 큰 주목을 받고 있는 QUERY 메서드에 대한 조사 내용입니다.

기존 웹 생태계가 가진 고질적인 아키텍처 한계를 해결하기 위해 등장한 개념으로, 핵심 내용을 알기 쉽게 정리해 드립니다.

1. HTTP QUERY 메서드란?

QUERY 메서드는 한마디로 "안전하고 멱등하면서도, 대용량의 구조화된 데이터를 요청 본문(Body)에 담아 서버에 조회를 요청할 수 있는" 새로운 HTTP 메서드입니다. 기존의 GET과 POST가 가진 장점만을 결합한 형태라고 볼 수 있습니다.

2. 왜 도입되었을까? (기존 메서드의 한계)

기존에는 웹에서 데이터를 조회할 때 주로 GET을, 데이터를 생성·수정할 때는 POST를 사용했습니다. 하지만 복잡한 조건의 검색이나 대용량 데이터를 기반으로 조회를 수행할 때 명확한 한계가 존재했습니다.

  • GET의 한계:
    • 길이 제한: 검색 조건이 복잡해지면 URL(Query String)이 지나치게 길어집니다. 브라우저나 프록시 서버, CDN 레벨에서 지원하는 URL 길이 제한(일반적으로 약 8KB)을 초과하면 요청이 실패합니다.
    • 보안 노출: 검색 조건에 민감한 정보(예: 개인정보, 특정 키워드)가 포함되면 URL이 서버 로그나 브라우저 방문 기록 등에 그대로 노출되는 취약점이 있습니다.
    • 구조화의 어려움: 복잡한 중첩 구조(JSON 등)를 URL 쿼리 스트링으로 인코딩하여 표현하기가 매우 번거롭습니다.
  • POST 대안의 한계:
    • 위 문제를 우회하기 위해 많은 개발자가 대용량 검색 요청 시 POST를 사용해 왔습니다. 본문(Body)에 대용량 JSON을 담을 수 있기 때문입니다.
    • 그러나 POST는 스펙상 안전하지 않고(Non-safe) 멱등성도 없는(Non-idempotent) 메서드입니다. 이 때문에 중간 프록시나 CDN 레벨에서 캐싱(Caching)이 불가능하며, 네트워크 오류로 요청이 실패했을 때 브라우저가 안전하게 자동 재시도(Retry)를 하지 못합니다.

💡 바로 이 간극을 메우기 위해 탄생한 것이 QUERY 메서드입니다. > "대용량 본문(Body)을 지원하는 안전하고 캐싱 가능한 조회 동사"가 필요했던 것입니다.

3. QUERY 메서드의 핵심 특징

  • 안전성(Safe) 및 멱등성(Idempotent): GET과 마찬가지로 서버의 데이터 상태를 절대 변경하지 않으며, 동일한 요청을 여러 번 보내도 항상 같은 결과를 보장합니다. 덕분에 네트워크 끊김 시 클라이언트가 안전하게 자동 재시도를 할 수 있습니다.
  • 요청 본문(Request Body) 필수 활용: 검색 조건, 필터 데이터, 대형 텍스트 등을 URL이 아닌 본문에 안전하게 담아 전달합니다.
  • 콘텐츠 기반 캐싱(Caching) 지원: 가장 혁신적인 부분으로, 응답을 캐싱할 때 URL뿐만 아니라 요청 본문(Body)의 내용까지 함께 캐시 키(Cache Key)로 활용합니다. 동일한 본문으로 들어온 조회 요청은 중간 게이트웨이나 CDN이 서버를 거치지 않고 바로 응답할 수 있습니다.
  • 엄격한 Content-Type 요구: 본문을 포함하므로, 요청 헤더에 반드시 명확한 Content-Type(예: application/json)이 명시되어야 합니다. 데이터 형식이 맞지 않으면 서버는 요청을 거부해야 합니다.
  • 리다이렉트 시 메서드 보존: POST 요청 후 리다이렉트가 발생하면 브라우저가 GET으로 메서드를 바꾸는 경우가 많지만, QUERY는 리다이렉트(301, 302, 307, 308 등) 시에도 원래의 QUERY 메서드와 본문을 그대로 유지한 채 새 URL로 요청을 이어갑니다.

4. 메서드별 비교 요약

특징 GET POST QUERY
주요 목적 단순 리소스 조회 리소스 생성 / 프로세스 실행 대용량/구조화된 조건 기반 조회
요청 본문(Body) 권장하지 않음 (사실상 불가능) 지원함 지원함 (표준 스펙)
안전성 (Safe) O X O
멱등성 (Idempotent) O X O
캐싱 가능 여부 O (URL 기준) X (사실상 불가능) O (URL + Body 기준)

5. 실제 요청 예시로 비교하기

복잡한 조건으로 문서 검색을 수행하는 상황을 가정해 보겠습니다.

기존의 비표준적인 POST 방식 조회

 
HTTP
POST /documents/search HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "keywords": ["인공지능", "법률", "검색"],
  "date_range": {"start": "2026-01-01", "end": "2026-06-28"},
  "min_relevance": 0.85
}
  • ❌ 문제점: 인프라 장비나 네트워크 레이어에서는 이 요청이 '데이터를 변경하는 작업'인지 '단순 조회 작업'인지 알 수 없어 캐시 최적화를 적용하지 못합니다.

새로운 QUERY 방식 조회

HTTP
QUERY /documents/search HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "keywords": ["인공지능", "법률", "검색"],
  "date_range": {"start": "2026-01-01", "end": "2026-06-28"},
  "min_relevance": 0.85
}
  • 장점: 이 요청이 상태를 변경하지 않는 안전한 조회임이 명시되므로, 중간 CDN이나 API 게이트웨이가 동일한 검색 조건에 대해 캐시 플러그인을 활성화하여 성능을 극대화할 수 있습니다.

6. 주요 활용처 및 전망

QUERY 메서드는 특히 다음과 같은 환경에서 패러다임을 바꿀 것으로 기대됩니다.

  • AI 및 검색 증강 생성(RAG) 파이프라인: 긴 컨텍스트 쿼리문, 고차원 벡터 임베딩 데이터 등을 검색 조건(Arguments)으로 넘겨야 하는 대용량 시맨틱 검색 시스템에서 URL 길이 한계를 깔끔하게 해결합니다.
  • 엔터프라이즈급 다중 필터 검색: 수십 개의 파라미터나 정교한 쿼리 빌더 조건이 필요한 복잡한 대시보드 시스템.
  • GraphQL 및 복잡한 API 아키텍처: 쿼리문 자체가 거대하여 어쩔 수 없이 POST를 사용하며 캐싱 최적화에 애를 먹던 서비스들의 표준적인 대안이 됩니다.

현재 주요 오픈소스 웹 서버, 프록시 소프트웨어(Nginx, Envoy 등), API 게이트웨이 및 언어별 HTTP 클라이언트 라이브러리들이 이 새로운 표준 규격을 점진적으로 내장하는 추세입니다. 대규모 검색이나 복잡한 데이터 조회 요건이 핵심인 시스템을 설계할 때 매우 유용한 선택지가 될 것입니다.

 

Thanks 

Hans

저작자표시 비영리 변경금지 (새창열림)