그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록API
API

HTTP 메서드의 멱등성이 뭔가요?

실무4/5
설계4/5
인간4/5
기초3/5

면접관의 질문 의도

메서드 분류를 외워 왔는지, 아니면 멱등성을 재시도·중복 처리 설계와 연결해 풀 수 있는지를 가른다.

큐레이션 답변

학습 자료

멱등성은 같은 요청을 한 번 보내든 여러 번 보내든 서버의 최종 상태가 같아야 한다는 성질이다. GET·PUT·DELETE는 스펙상 멱등하고, POST는 기본적으로 멱등하지 않다. 중요한 건 응답이 같다는 게 아니라 "상태가 누적되지 않는다"는 점이다. 결제·주문처럼 한 번만 처리돼야 하는 작업은 POST를 멱등 키와 함께 설계해 같은 요청이 두 번 와도 한 번만 반영되게 만든다.

좋은 답변 구조

  1. 01멱등성을 "여러 번 보내도 최종 상태가 같다"는 기준으로 정의한다
  2. 02GET·PUT·DELETE·POST 같은 메서드별 멱등성 유무를 짧게 정리한다
  3. 03POST처럼 멱등하지 않은 작업에서 멱등 키나 중복 방지 설계를 어떻게 더하는지 보여 준다
  4. 04재시도가 흔한 환경(타임아웃, 네트워크 단절)에서 왜 이 성질이 운영 안정성과 직결되는지 마무리한다

자주 실수하는 포인트

"같은 응답이 돌아온다"는 의미로 멱등성을 정의한다
POST는 무조건 멱등하지 않다고 단정하고 멱등 키 설계 가능성을 빠뜨린다
DELETE를 한 번 더 보냈을 때 404가 떨어지는 걸 "비멱등"으로 오해한다
PUT과 PATCH의 멱등성을 같은 기준으로 설명한다

실무 맥락

  • 결제·주문처럼 한 번만 실행돼야 하는 트랜잭션을 멱등 키로 보호하는 결제 게이트웨이 연동
  • 메시지 큐 컨슈머가 동일 메시지를 여러 번 받을 수 있는 at-least-once 처리 환경
  • 타임아웃 후 자동 재시도하는 클라이언트가 같은 요청을 두 번 만들어 내는 모바일 네트워크

본인 경험에 녹이는 힌트

결제·포인트 적립처럼 중복 처리 사고가 날 뻔한 경험을 멱등 키 도입 사례로 풀어낼 수 있다

메시지 큐 컨슈머에서 같은 이벤트를 여러 번 받아 처리한 경험이 있다면 "비즈니스 멱등성" 설계 이야기로 이어갈 수 있다

클라이언트 재시도 정책을 설계해 본 경험이 있다면 서버 멱등성과 한 쌍으로 묶어 설명할 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1POST에서 멱등성을 확보하려면 어떤 키와 저장 전략을 쓰나요
Q2PUT과 PATCH는 멱등성 관점에서 어떻게 다른가요
Q3메시지 큐 컨슈머에서 중복 처리를 막을 때 어떤 패턴을 쓰나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문