[매일메일] HTTP 메서드에서 멱등성이란 무엇인가요?

💡 매일메일은 기술면접 관련 질문을 메일로 매일 보내주는 구독 서비스입니다.

💡매일메일 챌린지는 제 개인적인 챌린지로 매일메일에서 보내주는 하루치 메일에 대한 답변을 블로그 포스트로 작성합니다.

 

HTTP 메서드에서 멱등성이란 무엇인가요?

(2024.12.17)

 

멱등성

수학이나 전산학에서 말하는 멱등성은 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 말합니다. HTTP 메소드의 멱등성도 이와 마찬가지로 동일한 요청을 한 번 보낸 것과 여러 번 연속으로 보낸 것과 같을 때 서버의 상태도 동일하게 유지된다면 멱등성 성질을 지닌다고 봅니다.

RFC 7231 문서의 경우 PUT, DELETE 와 Safe requests method인 GET이 멱등성을 가진다고 설명합니다.

A request method is considered "idempotent" if the intended effect on
the server of multiple identical requests with that method is the
same as the effect for a single such request. Of the request methods
defined by this specification, PUT, DELETE, and safe request methods
are idempotent.

 

HTTP 메소드 별 멱등성 여부를 표로 정리하자면 다음과 같습니다.

 

HTTP 메소드	멱등성
GET	O
PUT	O
DELETE	O
POST	X
PATCH	O / X

 

 

GET

GET의 경우 한 번을 호출하든 여러 번을 호출하든 리소스의 상태가 바뀌지 않으며 결과가 같아 안정성과 멱등성을 동시에 만족하는 HTTP 메소드라 할 수 있습니다.

 

멱등성 vs 안전성
멱등성을 여러 번 호출해도 리소스의 상태가 바뀌지 않는 안전성과 헷갈릴 수 있는데 멱등성은 리소스의 상태 불변을 보장하지 않습니다. 멱등성이 보장되어도 리소스의 상태가 바뀔 수 있습니다. PUT, DELETE가 안전성 성질이 없으나 멱등성 성질을 가진 이유입니다.

 

멱등성 vs 응답상태코드
멱등성과 응답상태 코드는 별개의 개념으로 봐야 합니다. 메소드를 여러 번 호출하여 서버 상태는 같아도 응답 상태가 다를 수 있습니다. PUT을 예로 들 수 있는데 아래 해당 메소드에서 이어 설명을 하겠습니다.

 

 

PUT

PUT 는 호출 시 서버로 데이터를 전송하여 값이 없다면 새로 생성하고 있다면 덮어 씌우는(대체하는) 메소드입니다. 값이 없을 시 새로운 자원을 생성한다는 점에서 POST 와 유사하다고 볼 수 있으나 한 번의 호출과 여러 번의 호출에서 계속 같은 값을 덮어씌운다는 점에서 서버의 상태가 없어 멱등성을 만족한다고 볼 수 있습니다.

 

PUT 요청의 경우 아래 표처럼 요청 조건마다 달라질 수 있습니다. 요청에 따라 다른 상태 코드를 응답한다고 하여 멱등성을 만족하지 못한다는 것은 아닙니다. 서버 상태는 동일하기에 멱등성을 지닙니다.

 

코드	상태	설명
200	OK	요청이 올바르게 수행되었음 (GET, PUT)
201	Created	서버가 새로운 리소스를 생성했음 (POST, PUT)
204	No Content	응답할 데이터가 없음 (HTTP Body 가 없음). (DELETE, PUT)

 

 

DELETE

DELETE는 단순 삭제 메소드입니다. 처음 요청 시 해당 데이터가 존재하면 삭제 되며 삭제 이후 여러 번 요청하더라도 해당 리소스는 존재하지 않아 204 No Content 응답상태코드를 반환할 것입니다.

매 요청마다 해당 리소스 삭제 상태이기에 멱등성을 만족합니다.

 

 

POST

POST 는 호출할 때마다 서버로 데이터를 전송하여 새로운 자원을 생성하거나 리소스의 상태를 변경하는 메소드입니다. 동일한 요청을 한 번 보낼 때와 여러 번 보낼 때 생성되는 자원의 개수가 달라 서버의 상태가 다르기에 멱등성을 만족하지 못합니다.

 

 

PATCH

PUT이 리소스의 대체라면 PATCH는 리소스의 수정입니다. PATCH도 PUT처럼 리소스를 대체하는 방식으로 설계한다면 멱등성을 보장할 수 있지만 기존 리소스의 증감을 통한 변경으로 설계한다면 멱등성을 보장할 수 없습니다.

 

💡 PATCH와 PUT가 맡은 기능은 거의 같지만 두 메소드의 진정한 차이점은 전체 교체, 일부 교체가 아니라 멱등성 보장여부 입니다.

 

예를 들어 요청 시마다 한 필드의 값을 1씩 증가한다고 하면 동일한 요청을 한 번할 때와 여러 번 할 때의 서버 상태는 달라지게 됩니다.

 

 

멱등적 설계의 중요성

 

멱등적 설계는 안정적인 시스템을 구축하는 데 매우 중요한 역할을 합니다.

 

 

네트워크 오류 상황 처리

• 클라이언트가 서버로 요청을 보냈지만 응답을 받지 못한 경우, 동일한 요청을 안전하게 재시도할 수 있습니다.
• PUT 요청으로 사용자 정보를 수정하는 중에 네트워크 오류가 발생해도, 재시도 시 동일한 결과를 보장받을 수 있습니다.

 

분산 시스템에서의 중복 요청 처리

• 여러 서버로 구성된 시스템에서 동일한 요청이 여러 번 전달되어도 데이터 일관성을 유지할 수 있습니다.
• 로드 밸런서를 통해 여러 서버로 분산되는 환경에서도 안전하게 작업을 처리할 수 있습니다.

 

결제 시스템 안정성

• 결제 요청이 중복으로 발생해도 한 번만 처리되도록 보장할 수 있습니다.
• 결제 승인 요청이 타임아웃되어 재시도하는 경우에도 이중 결제를 방지할 수 있습니다.

 

데이터 동기화

• 여러 시스템 간 데이터를 동기화할 때, 동일한 동기화 요청이 여러 번 발생해도 안전합니다.
• 특히 마이크로서비스 아키텍처에서 서비스 간 데이터 일관성을 유지하는 데 도움이 됩니다.

 

멱등성이 없는 POST 처리

• POST는 멱등성이 보장되지 않아 중복 요청 시 별도의 처리가 필요합니다.
• 아래와 같은 방법이 있습니다.
  • 요청마다 고유한 식별자(Idempotency Key)를 부여하여 중복 요청 확인
  • 클라이언트에서 요청 재시도 시 동일한 식별자 사용
  • 서버에서 이미 처리된 요청인지 확인 후 중복 요청 방지

 

API를 설계 시 가능한 한 멱등성을 보장하도록 설계하는 것이 바람직합니다. 특히 중요한 비즈니스 로직이나 결제와 같은 민감한 작업을 처리하는 API는 반드시 멱등성을 고려해야 하며, POST와 같이 멱등성이 없는 메소드를 사용할 때는 추가적인 안전장치를 마련해야 합니다.

 

 

---

 

 

모범 답안

---

 

 

질문의 목적

네트워크 통신과 데이터 일관성 관리에 대한 이해도를 평가하는 중요한 질문입니다. HTTP 메소드의 특성과 REST 아키텍처 원칙에 대한 이해를 바탕으로, 중복 요청 처리, 장애 상황 대응, 시스템 안정성 확보 방안을 설계할 수 있는지 확인합니다.

 

 

---

 

주요 개념

 

멱등성

 

사전적 정의
멱등법칙(冪等法則) 또는 멱등성(冪等性, idempotent)은 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질

 

HTTP 멱등성
동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말합니다.

 

 

HTTP 메소드의 속성

 

안정성
보안 취약성을 말하는 것이 아니라 HTTP 메소드를 호출해도 리소스의 상태가 변하지 않는 성질을 말합니다.

 

HTTP 메소드	안전성
GET	O
PUT	X
DELETE	X
POST	X
PATCH	X

 

GET 메소드의 경우 단순 데이터 조회 기능을 담당하기 때문에 리소스의 상태가 변하지 않아 안전성을 가집니다.
그 외 메소드의 경우 데이터 추가, 삭제, 변경이 일어나기 때문에 안전성을 가진다고 할 수 없습니다.

 

 

멱등성

RFC 7231

4.2.2. Idempotent Methods

A request method is considered "idempotent" if the intended effect on
the server of multiple identical requests with that method is the
same as the effect for a single such request. Of the request methods
defined by this specification, PUT, DELETE, and safe request methods
are idempotent.

Like the definition of safe, the idempotent property only applies to
what has been requested by the user; a server is free to log each
request separately, retain a revision control history, or implement
other non-idempotent side effects for each idempotent request.

Idempotent methods are distinguished because the request can be
repeated automatically if a communication failure occurs before the
client is able to read the server's response. For example, if a
client sends a PUT request and the underlying connection is closed
before any response is received, then the client can establish a new
connection and retry the idempotent request. It knows that repeating
the request will have the same intended effect, even if the original
request succeeded, though the response might differ.

 

 

캐시가능성
캐시가능성은 응답 결과 리소스를 캐싱해서 효율적으로 사용할 수 있는가를 말합니다.

4.2.3. Cacheable Methods
Request methods can be defined as "cacheable" to indicate that
responses to them are allowed to be stored for future reuse; for
specific requirements see RFC7234. In general, safe methods that
do not depend on a current or authoritative response are defined as
cacheable; this specification defines GET, HEAD, and POST as
cacheable, although the overwhelming majority of cache
implementations only support GET and HEAD.

 

GET, POST, PATCH 메소드는 스펙 상으로 캐시가 가능하다고 합니다. 그러나 실제로는 GET와 HEAD 만 캐시로 이용이 가능하고 POST 와 PATCH 는 지원되지 않습니다.

 

HTTP 메소드	캐시 가능성
GET	O
PUT	X
DELETE	X
POST	O
PATCH	O

브라우저의 캐시를 이용하려면 원본 리소스가 변경되지 않아야 하는데 POST, PATCH 의 경우 DELETE와 PUT 처럼 데이터 변경이 일어난다면 원본 데이터를 보장할 수 없어 캐시 데이터 불일치 문제가 발생하게 됩니다.

 

---

 

참고

• HTTP의 안정성.멱등성.캐시성 완벽 이해하기
• RFC7231
• HTTP 메소드의 멱등성과 DELETE 메소드가 멱등한 이유