# 새로운 HTTP QUERY 메소드

> Clean Markdown view of GeekNews topic #30846. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30846](https://news.hada.io/topic?id=30846)
- GeekNews Markdown: [https://news.hada.io/topic/30846.md](https://news.hada.io/topic/30846.md)
- Type: news
- Author: [awbrg789](https://news.hada.io/@awbrg789)
- Published: 2026-06-26T10:28:50+09:00
- Updated: 2026-06-26T10:28:50+09:00
- Original source: [kreya.app](https://kreya.app/blog/new-http-query-method-explained/)
- Points: 13
- Comments: 6

## Topic Body

RFC 10008로 새롭게 정의된 HTTP QUERY 메소드에 대한 설명  
  
기존 RESTful API에서 복잡한 검색을 처리할 때 GET과 POST 모두 한계가 있었는데, 이를 해결하기 위해 오랜 논의 끝에 QUERY 메소드가 표준화됨  
  
GET의 한계  
- 복잡한 필터나 관계형 쿼리를 URL 파라미터로 보내면 URL이 지나치게 길어지고, 브라우저나 서버의 글자 수 제한에 걸릴 수 있음  
- 비ASCII 문자나 특수문자는 인코딩이 필요해 요청 크기가 증가  
- 배열이나 중첩 구조의 표현 방식이 표준화되어 있지 않음 (예: roles[]=admin vs roles=admin)  
- 서버/미들웨어가 URL 파라미터를 로그에 기록하므로 민감한 데이터 전송 시 문제  
- GET에 요청 본문을 보내는 것은 스펙상 명시적으로 금지되진 않지만, 프록시/방화벽/브라우저마다 처리 방식이 달라서 실질적으로 사용 불가  
  
POST 우회의 문제  
- 요청 본문은 보낼 수 있지만, POST는 비멱등(non-idempotent)으로 정의되어 있어 실패 시 자동 재시도가 안전하지 않음  
- 프록시나 미들웨어가 읽기 전용 작업임을 인식할 수 없어 자동 캐싱 등의 최적화가 불가능  
- 의미론적으로 리소스 생성/처리용인 POST를 검색에 사용하는 것은 RESTful 설계 원칙에 맞지 않음  
  
QUERY 메소드  
- GET처럼 안전(safe)하고 멱등(idempotent)하면서, 요청 본문을 포함할 수 있는 새로운 HTTP 메소드  
- 캐싱 가능하지만, 구현 시 요청 본문을 캐시 키에 포함해야 하므로 GET보다 캐싱 구현이 복잡  
- 요약하면 "읽기 전용 요청에서 POST를 대체"하는 것이 핵심 목적  
  
주의사항  
- 클라이언트/프록시/서버의 QUERY 지원이 아직 제한적이며, 완전한 지원까지는 시간이 걸릴 수 있음  
- 단순한 GET 쿼리 파라미터로 충분한 경우에는 굳이 변경할 필요 없음  
- 필터된 데이터의 URL 공유나 북마크가 필요한 경우엔 여전히 GET이 적합

## Comments



### Comment 60359

- Author: jongyeol
- Created: 2026-06-26T12:26:01+09:00
- Points: 3

> GET에 요청 본문을 보내는 것은 스펙상 명시적으로 금지되진 않지만, 프록시/방화벽/브라우저마다 처리 방식이 달라서 실질적으로 사용 불가  
  
어... 프록시/방화벽/브라우저마다 앞으로 10년쯤은 QUERY 메소드가 아직 적용되지 않을 수 있는건 생각을 못 한 걸까요? 아니면 아주 멀리 내다보고 한거이려나요.

### Comment 60371

- Author: tesha001
- Created: 2026-06-26T14:16:59+09:00
- Points: 1
- Parent comment: 60359
- Depth: 1

후자일것 같네요

### Comment 60350

- Author: click
- Created: 2026-06-26T11:05:49+09:00
- Points: 2

모 회사 서비스 API가 POST 수신하면서 URL 파라미터를 똑같이 안주면 동작을 안하던 문제가 있었던 기억이 나네요  
한국에서는 PUT이나 DELETE 도 이게 뭐임? 하는 경우가 꽤 있던데 QUERY 까지 정착하려면 얼마나 걸리련지 모르겠습니다

### Comment 60360

- Author: savvykang
- Created: 2026-06-26T12:32:26+09:00
- Points: 2
- Parent comment: 60350
- Depth: 1

???: POST는 보안에 좋다

### Comment 60353

- Author: sea715
- Created: 2026-06-26T11:12:51+09:00
- Points: 2
- Parent comment: 60350
- Depth: 1

??? : REST하지말고 그냥 POST로 다 통일해

### Comment 60367

- Author: ultimategamer
- Created: 2026-06-26T13:40:20+09:00
- Points: 1

RFC 문서는 https://datatracker.ietf.org/doc/rfc10008/ 이네요.  
GET은 URL이 길어진다는 단점도 있지만, ElasticSearch의 특정 조회 필터 결과를 공유하고 싶을 때 처럼 URL 주소를 그대로 공유할 수있다는 장점도 있는 것 같아요.  
  
GET 요청은 브라우저 주소창에 적는다는 전제 하에 암묵적으로 쓰이는 곳들도 많을 거라, 정착하기까지에는 기술적 지원 이상으로 많은 시간이 소요될듯 하네요.