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 사전 요청과 어떤 관계인가.
웹에서 같이 읽기
- 웹 인증 방식 총정리 (Authentication)웹 서비스의 인증은 요청을 보낸 사용자가 누구인지 확인하는 절차다. HTTP는 무상태 프로토콜이므로 로그인 이후 요청마다 사용자를 식별할 수단이 필요하며, 세션, 토큰, API 키, OAuth를 비교해 각 방식의 적합한 상황을 정리한다.
- 쿠키와 세션 (Cookie, Session)쿠키는 서버가 브라우저에 저장하도록 지시하는 작은 키와 값의 쌍이고, 세션은 쿠키를 운반 수단으로 삼아 사용자별 상태를 서버 저장소에 보관하는 기법이다. 두 개념의 동작 원리와 보안 속성, 위협 대응을 다룬다.
- CSR과 SSR (Client Side Rendering, Server Side Rendering)CSR은 브라우저가 자바스크립트로 화면을 그리는 방식, SSR은 서버가 완성된 HTML을 내려보내는 방식이다. 초기 로딩, SEO, 서버 부하 관점의 차이와 SSG, ISR을 포함한 혼합 전략까지 정리한다.
- CSRF와 XSS (Cross Site Request Forgery, Cross Site Scripting)XSS는 공격자의 스크립트를 피해자 브라우저에서 실행시키는 공격이고, CSRF는 로그인된 브라우저를 속여 피해자 명의의 요청을 보내는 공격이다. 두 공격이 악용하는 신뢰 관계의 차이와 방어 수단을 정리한다.
이 개념, 내 코드에서는 어떻게 물어볼까요
데브핏(DevFit)에 채용공고 URL을 붙여 넣고 레포지토리를 연결하면, 내가 쓴 커밋에서 예상 질문과 어필 포인트를 만듭니다. 하루 10회까지 무료입니다. 합불 판정이나 지원자 랭킹은 만들지 않고, 최종 판단은 사람이 합니다.
공고 넣고 시작하기