HTTP 요청 메서드 (HTTP Request Method)

한눈에 보기

HTTP 요청 메서드는 자원에 수행하려는 행위를 나타내는 동사다. GET, POST, PUT, PATCH, DELETE의 의미와 안전성, 멱등성 개념을 정리하고 캐시, 재시도, API 설계에서의 활용을 다룬다.

최종 업데이트 2026.09.17

HTTP 요청 메서드(HTTP Request Method)는 클라이언트가 서버의 자원에 대해 수행하려는 행위의 의미를 나타내는 동사다. GET, POST, PUT, PATCH, DELETE가 실무에서 주로 쓰이며, 각 메서드는 안전성(Safety)과 멱등성(Idempotency)이라는 성질로 구분된다. 이 성질을 정확히 이해해야 캐시, 재시도, REST API 설계에서 올바른 판단을 내릴 수 있다.

주요 메서드의 의미

GET은 자원의 조회를 뜻하며 요청 본문 없이 URL과 쿼리 문자열로 조건을 전달한다. POST는 서버에 데이터를 제출해 처리하게 하는 메서드로, 새 자원 생성이나 특정 동작의 실행에 두루 쓰인다. PUT은 대상 URI(Uniform Resource Identifier)의 자원을 요청 본문으로 통째로 교체한다. 없던 자원이면 생성될 수도 있다. PATCH는 자원의 일부 필드만 수정한다. DELETE는 자원의 삭제를 요청한다. 이 밖에 HEAD는 GET과 같지만 본문 없이 헤더만 받아 자원의 존재나 크기를 확인할 때 쓰고, OPTIONS는 대상 자원이 지원하는 메서드를 묻는 용도로, 특히 CORS(Cross-Origin Resource Sharing)의 사전 요청(Preflight Request)에 사용된다.

GET /users/42 HTTP/1.1            조회
POST /users HTTP/1.1              생성, 본문에 새 사용자 정보
PUT /users/42 HTTP/1.1            전체 교체, 본문에 완전한 표현
PATCH /users/42 HTTP/1.1          부분 수정, 본문에 바뀐 필드만
DELETE /users/42 HTTP/1.1         삭제

안전성과 멱등성

안전한 메서드는 서버의 상태를 바꾸지 않는 메서드로 GET, HEAD, OPTIONS가 해당한다. 안전하기 때문에 브라우저와 중간 서버가 마음 놓고 캐시하거나 미리 가져올 수 있다. 멱등한 메서드는 같은 요청을 여러 번 보내도 한 번 보낸 것과 서버 상태가 같아지는 메서드다. GET, PUT, DELETE가 멱등하다. PUT은 몇 번을 보내도 같은 내용으로 교체될 뿐이고, DELETE는 이미 지워진 자원을 다시 지워도 결과 상태는 같다. 반면 POST는 멱등하지 않아서 두 번 보내면 주문이 두 건 생길 수 있다. PATCH는 명세상 멱등성이 보장되지 않는데, 필드를 값으로 덮어쓰는 수정은 사실상 멱등하지만 조회수를 1 올리라는 식의 수정은 멱등하지 않기 때문이다. 이 성질은 실무에 직접 영향을 준다. 네트워크 오류 시 클라이언트나 프록시는 멱등한 요청만 자동 재시도할 수 있고, POST의 중복 제출을 막으려면 멱등성 키(Idempotency Key)를 헤더로 보내 서버가 같은 키의 요청을 한 번만 처리하게 하는 설계가 필요하다.

메서드 성질 비교

메서드용도안전성멱등성요청 본문캐시
GET조회안전멱등없음가능
HEAD헤더만 조회안전멱등없음가능
POST생성, 처리 요청비안전비멱등있음원칙적으로 안 함
PUT전체 교체비안전멱등있음안 함
PATCH부분 수정비안전보장 안 됨있음안 함
DELETE삭제비안전멱등없음이 보통안 함
OPTIONS지원 메서드 확인안전멱등없음안 함

GET과 POST를 둘러싼 오해

GET과 POST의 차이를 데이터가 URL에 보이느냐 숨겨지느냐의 문제로만 설명하는 것은 부정확하다. 본질적인 차이는 의미론이다. GET은 조회이므로 몇 번 반복돼도 무방하고 캐시와 북마크, 뒤로 가기가 자연스럽게 동작한다. POST는 상태를 바꾸므로 브라우저가 새로 고침 시 재제출 경고를 띄운다. 보안 관점에서도 POST 본문이 GET 쿼리보다 안전하다는 통념은 절반만 맞다. 둘 다 HTTPS로 암호화되면 전송 중에는 보호되지만, URL은 브라우저 히스토리, 서버 접근 로그, Referer 헤더에 남을 수 있으므로 비밀번호 같은 민감 정보는 GET 쿼리에 절대 넣지 않아야 한다. 또 GET이 상태를 바꾸도록 구현하면 크롤러의 링크 순회나 브라우저의 미리 가져오기만으로 데이터가 변경되는 사고가 나고, CSRF(Cross Site Request Forgery) 방어의 전제도 무너진다. 메서드 규약을 지키는 것은 스타일 문제가 아니라 웹 인프라 전체와의 약속을 지키는 일이다.

면접에서 이렇게 물어본다

  • GET과 POST의 차이를 의미론과 성질 중심으로 설명해 보라.
  • 멱등성이 무엇이고, 어떤 메서드가 멱등한지, 실무에서 왜 중요한지 말해 보라.
  • PUT과 PATCH의 차이를 예를 들어 설명해 보라.
  • 결제 API에서 POST 중복 요청 문제를 어떻게 해결하겠는가.
  • OPTIONS 메서드는 언제 쓰이며 CORS 사전 요청과 어떤 관계인가.
웹 문서 전체 보기

이 개념, 내 코드에서는 어떻게 물어볼까요

데브핏(DevFit)에 채용공고 URL을 붙여 넣고 레포지토리를 연결하면, 내가 쓴 커밋에서 예상 질문과 어필 포인트를 만듭니다. 하루 10회까지 무료입니다. 합불 판정이나 지원자 랭킹은 만들지 않고, 최종 판단은 사람이 합니다.

공고 넣고 시작하기