무슨 일이냐면요
API 만들다가 이런 상황 겪어본 적 있으실 거예요. 검색 조건이 엄청 복잡해요. 필터가 수십 개에, 정렬 기준에, 페이징까지… 이걸 GET으로 보내자니 URL이 너무 길어지고(브라우저나 서버마다 URL 길이 제한이 있거든요), 한글이나 특수문자 인코딩도 골치 아파요. 그렇다고 POST로 보내자니 “조회인데 왜 POST야?” 싶고, 캐싱도 안 되고 영 찜찜하죠. 이 오래된 딜레마를 해결하려고 IETF가 새 HTTP 메서드 QUERY를 RFC 10008로 정식 표준화했어요.
QUERY가 뭐냐면요
한 줄로 말하면 “body를 가질 수 있는 GET”이에요. GET, POST, PUT처럼 HTTP 메서드의 한 종류인데, 성격이 독특해요.
- GET처럼 안전(safe)해요. 서버 상태를 바꾸지 않는, 그냥 읽기·조회용이라는 뜻이에요.
- GET처럼 멱등(idempotent)해요. 멱등이 뭐냐면, 같은 요청을 100번 보내도 결과가 똑같다는 거예요. 그래서 네트워크가 끊겨서 재시도해도 안전하죠.
- 그런데 POST처럼 요청 본문(body)을 가질 수 있어요. 복잡한 JSON 쿼리든 뭐든 body에 담아 보내면 돼요.
캐싱은 어떻게?
QUERY의 또 다른 묘미는 캐싱이에요. POST는 기본적으로 캐시가 안 되는데, QUERY는 안전한 메서드라 응답을 캐시할 수 있게 설계됐어요. 핵심 장치가 Content-Location 헤더예요. 서버가 “이 쿼리 결과는 사실상 이 URL의 내용과 같아요”라고 알려주면, 캐시가 그 URL을 키로 삼아 결과를 저장하고 재활용할 수 있어요. body 기반 요청인데도 캐싱의 이점을 살릴 수 있는 거죠.
업계 맥락
사실 이 문제, 다들 각자 알아서 우회하고 있었어요. Elasticsearch는 GET 요청에 body를 넣는 비표준 방식을 오래 써왔고(GET /_search + JSON body), GraphQL은 거의 다 POST로 보내버려서 캐싱 이점을 포기했죠. 어떤 팀은 POST /search로 타협하고요. QUERY는 이렇게 제각각이던 관행에 “표준”이라는 공통 언어를 준 거예요. 다만 현실적으로는 시간이 좀 걸릴 거예요. 브라우저 fetch, 프록시, CDN, 각종 프레임워크가 새 메서드를 제대로 지원하기 전까진 POST 우회가 한동안 남아 있을 테니까요.
한국 개발자에게
지금 당장 프로덕션에 QUERY를 쓰라는 건 아니에요. 인프라 지원이 아직 무르익지 않았거든요. 하지만 “복잡한 검색 API를 GET으로 할지 POST로 할지” 고민해본 분이라면, 이제 “원래는 QUERY가 정답인 상황”이라는 걸 알고 설계하는 것과 모르고 하는 건 차이가 커요. 사내 API 설계 가이드를 만들 때 참고할 수도 있고요. 그리고 멱등성·안전성 같은 HTTP 메서드의 기본 의미를 다시 짚어보는 좋은 계기이기도 해요. 의외로 이 개념을 정확히 모르고 메서드를 고르는 경우가 많거든요.
마무리
정리하면, QUERY는 “안전하고 멱등하면서 body도 가질 수 있고 캐싱도 되는” 조회 전용 메서드예요. 그동안의 GET vs POST 딜레마에 대한 공식 답안인 셈이죠. 여러분은 복잡한 검색 API, 지금 GET으로 짜고 계세요 POST로 짜고 계세요? QUERY가 보편화되면 갈아탈 생각 있으세요?
🔗 출처: Hacker News
TTJ 코딩클래스 정규반
월급 외 수입,
코딩으로 만들 수 있습니다
17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공