Network
HTTP 메서드에 대해서 설명해주세요
안전성과 멱등성으로 이해하는 HTTP 메서드 완전 정복 — GET, POST, PUT, PATCH, DELETE를 면접에서 막힘없이 설명합니다.
2026년 3월 11일 · 약 12분 읽기
Q. "HTTP 메서드의 종류와 각각의 특징, 그리고 PUT과 PATCH의 차이에 대해 설명해주세요."
예상 꼬리질문
답변 가이드
"HTTP 메서드는 클라이언트가 서버에 무엇을 하고 싶은지 알리는 동사입니다. GET(조회), POST(생성), PUT(전체 교체), PATCH(부분 수정), DELETE(삭제)로 REST API의 CRUD 연산을 표현합니다."
"안전한(Safe) 메서드는 서버 상태를 변경하지 않아 브라우저가 자유롭게 캐시·프리페치할 수 있습니다. 멱등한(Idempotent) 메서드는 동일한 요청을 여러 번 보내도 결과가 같아 타임아웃 시 안전하게 재시도할 수 있습니다."
"PUT은 리소스를 완전히 교체하고, PATCH는 일부만 수정합니다. POST는 멱등하지 않으므로 결제·주문 등 중요 작업은 Idempotency-Key 헤더로 중복을 방지합니다."
API를 설계할 때 "이 기능은 GET으로 해야 할까, POST로 해야 할까?"라는 질문을 해본 적 있으신가요? 단순히 "조회는 GET, 생성은 POST"라는 규칙만 외우고 있다면, PUT과 PATCH의 차이, 왜 DELETE는 멱등하다고 하는지 설명하기 어렵습니다.
HTTP 메서드는 단순한 이름표가 아닙니다. 각 메서드에는 안전성(Safety)과 멱등성(Idempotency)이라는 속성이 명시되어 있고, 이 속성들이 브라우저의 캐시 동작, 클라이언트의 재시도 전략을 결정합니다.
1. HTTP 메서드란? — 동사로 의도를 전달하다
꼬리질문: "HTTP 메서드의 종류와 각각의 역할이 무엇인가요?"
HTTP 요청은 세 부분으로 구성됩니다: 메서드(Method), URL(리소스), 본문(Body). URL이 "어디에" 요청하는지를 나타낸다면, 메서드는 "무엇을" 하고 싶은지를 나타냅니다.
메서드를 이해하는 데 가장 중요한 두 가지 속성이 있습니다. 안전성(Safe)은 메서드 호출이 서버의 상태를 변경하지 않음을 의미합니다. 멱등성(Idempotent)은 동일한 요청을 여러 번 보내도 최종 결과가 같음을 의미합니다.
아래 메서드 탐색기에서 각 메서드의 속성을 직접 확인해 보세요. 카드를 클릭하면 HTTP 예시까지 확인할 수 있습니다.
2. PUT vs PATCH — 전체 교체 vs 부분 수정
꼬리질문: "PUT과 PATCH의 차이가 무엇인가요?"
REST API 설계에서 가장 많이 혼동하는 부분이 PUT과 PATCH의 차이입니다.
PUT은 리소스를 완전히 교체합니다. 요청 본문에 포함되지 않은 필드는 서버에서 삭제됩니다. 반면 PATCH는 리소스를 부분적으로 수정합니다. 요청 본문에 포함된 필드만 변경되고, 나머지는 유지됩니다.
아래 시뮬레이터에서 직접 필드를 입력하고 PUT과 PATCH의 결과 차이를 확인해 보세요.
현재 리소스
PUT 요청 본문
입력한 필드만 교체됩니다. 비워두면 해당 필드가 삭제됩니다.
결과 리소스
요청을 실행하면
결과가 표시됩니다
PUT은 리소스를 완전히 교체합니다. 요청 본문에 포함되지 않은 필드는 서버에서 제거됩니다. 전체 필드를 항상 포함해야 하므로 주의가 필요합니다.
3. REST API 실습 — 메서드와 URL의 조합
꼬리질문: "RESTful API 설계 원칙을 설명해주세요"
RESTful API의 핵심은 리소스 중심 URL + 메서드로 동작을 표현하는 것입니다. URL에 동사를 포함하면 안 됩니다.
각 요청의 성공 응답 코드도 메서드에 따라 다릅니다. GET은 200 OK, POST(생성)는 201 Created + Location 헤더, DELETE는 204 No Content를 반환합니다.
아래 시뮬레이터에서 메서드와 엔드포인트를 선택해 요청을 직접 실행하고 리소스가 어떻게 변하는지 확인해 보세요.
요청 빌더
리소스 상태 (articles)
응답
요청을 실행하면 응답이 표시됩니다
4. 안전성 × 멱등성 매트릭스
꼬리질문: "안전성(Safety)과 멱등성(Idempotency)의 차이가 무엇인가요?"
안전성과 멱등성은 독립된 개념이지만 관계가 있습니다: 안전한 메서드는 반드시 멱등합니다. 반대로 멱등해도 안전하지 않을 수 있습니다 (PUT, DELETE).
POST가 멱등하지 않은 이유는 단순합니다: /orders에 POST를 두 번 보내면 주문이 두 개 생깁니다. 이를 해결하려면 Idempotency-Key 헤더를 사용합니다. 동일한 키로 재시도하면 서버가 중복을 감지해 한 번만 처리합니다.
아래 매트릭스에서 각 셀을 클릭해 해당 메서드의 특성을 확인해 보세요.
서버 상태를 변경하지 않고, 여러 번 호출해도 결과가 동일합니다. 브라우저가 자유롭게 캐시하고 재시도할 수 있습니다.
클릭하여 상세 보기
이론상
불가능
서버 상태는 변경하지만, 같은 요청을 여러 번 보내도 최종 상태는 동일합니다. 타임아웃 시 안전하게 재시도할 수 있습니다.
클릭하여 상세 보기
서버 상태를 변경하며, 동일한 요청을 여러 번 보내면 결과가 달라질 수 있습니다. 재시도 시 Idempotency-Key 등 별도 처리가 필요합니다.
클릭하여 상세 보기
면접 체크리스트
이 항목들을 자신 있게 설명할 수 있다면 HTTP 메서드 질문은 준비 완료입니다.
- - GET / HEAD / OPTIONS: 서버 상태를 바꾸지 않는다 — 캐시하고, 프리페치하고, 자유롭게 재시도한다
- - PUT / DELETE: 상태를 바꾸지만 멱등하다 — 타임아웃 시 재시도해도 안전하다
- - POST: 멱등하지 않다 — 중요한 작업은 Idempotency-Key로 중복을 방지한다
- - PATCH: 연산 방식에 따라 멱등할 수도, 아닐 수도 있다 — 절대값은 멱등, 증분은 비멱등
- - 더 알아볼 주제: HTTP 캐시 헤더(Cache-Control, ETag), CORS와 OPTIONS preflight
참고 자료
- RFC 9110 - HTTP Semantics §9 — HTTP 메서드 최신 공식 표준. 안전성·멱등성 정의가 명시되어 있는 원문
- MDN - HTTP request methods — 메서드별 상세 설명, 예시, 브라우저 호환성을 한 페이지에서 확인
- Stripe API - Idempotent Requests — 실무에서 Idempotency-Key를 사용하는 방법. 결제 API의 실제 구현 사례
- REST API Design Rulebook (O'Reilly) — REST API 설계 원칙과 HTTP 메서드 활용법을 체계적으로 정리한 책
의견을 들려주세요
서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.