---
title: "멱등성: 재시도해도 같은 효과를 유지하는 설계"
author: "Lee"
published_at: "2026-10-12T02:29:03.250Z"
updated_at: "2026-09-30T10:00:17.594Z"
tags: ["컴퓨터공학","분산시스템"]
canonical_url: "https://ariser.io/@writer_a1cd615ab19e/%EB%A9%B1%EB%93%B1%EC%84%B1-%EC%9E%AC%EC%8B%9C%EB%8F%84%ED%95%B4%EB%8F%84-%EA%B0%99%EC%9D%80-%ED%9A%A8%EA%B3%BC%EB%A5%BC-%EC%9C%A0%EC%A7%80%ED%95%98%EB%8A%94-%EC%84%A4%EA%B3%84"
ai_assisted: false
---

# 멱등성: 재시도해도 같은 효과를 유지하는 설계

[원문](https://ariser.io/@writer_a1cd615ab19e/%EB%A9%B1%EB%93%B1%EC%84%B1-%EC%9E%AC%EC%8B%9C%EB%8F%84%ED%95%B4%EB%8F%84-%EA%B0%99%EC%9D%80-%ED%9A%A8%EA%B3%BC%EB%A5%BC-%EC%9C%A0%EC%A7%80%ED%95%98%EB%8A%94-%EC%84%A4%EA%B3%84)

멱등성은 같은 연산을 여러 번 적용해도 한 번 적용한 것과 같은 효과가 남는 성질이다. 수학적으로 f(f(x))=f(x)라고 쓸 수 있다. 분산 서비스에서는 응답이 유실되었을 때 요청을 재시도해도 원치 않는 중복 변경이 생기지 않도록 하는 데 중요하다.

![응답이 유실되어 재시도해도 같은 요청 키의 결제 효과가 한 번만 남는 멱등성](/api/v1/media/bbe8958b-7336-4a27-bbb8-6fb7a4c2fd1e)

*멱등성은 메시지 전달 횟수보다 같은 논리 작업의 반복 효과를 다루는 성질이다.*

### 같은 응답과 같은 효과는 다르다

잔액을 100으로 설정하는 연산은 반복해도 최종 잔액이 100이다. 잔액에 100을 더하는 연산은 반복할 때마다 달라져 기본적으로 멱등하지 않다. 같은 자원을 삭제하는 요청은 첫 번째에 성공, 두 번째에 이미 없다는 응답을 줄 수 있어도 삭제 효과 자체는 같다.

클라이언트가 결제를 보낸 뒤 응답을 받지 못했다고 하자. 서버가 처리하지 못했을 수도 있고, 처리는 끝났지만 응답만 사라졌을 수도 있다. 클라이언트는 이 두 상황을 통신 실패 하나로 구별하기 어렵다. 그래서 재시도 정책에 중복 식별이 필요하다.

### 요청 키와 결과를 함께 기록한다

```text
Client creates operation key K and sends charge(K, amount=100).
Server commits the charge and records K with its result.
The response is lost.
Client retries charge(K, amount=100).
Server finds the completed K and returns its recorded result.
No second charge is created for the same logical operation.
```

요청 키는 같은 논리 작업의 재시도에서 유지하고, 새 결제에서는 새로 만든다. 키에 대한 작업 내용도 확인해야 한다. 같은 키로 금액 100과 200을 보내는 경우를 같은 작업으로 조용히 처리하면 API 의미가 불분명해진다.

중복 기록과 실제 변경을 별도로 저장하면 중간 장애에 취약하다. 결제 변경은 끝났지만 키 기록 전에 중단되면 재시도가 중복 효과를 낼 수 있다. 한 데이터베이스 안에서는 유일 제약과 트랜잭션으로 묶을 수 있고, 외부 결제망까지 포함하면 그 끝점의 중복 식별과 복구 흐름도 필요하다.

### 동시에 도착하는 재시도도 생각하기

두 요청이 동시에 “키가 없다”고 확인한 뒤 각각 실행하면 단순 조회 후 삽입은 안전하지 않다. 키의 유일성을 원자적으로 확보하고 진행 중과 완료 상태를 구별해야 한다. 아직 처리 중인 요청을 기다릴지 상태를 반환할지도 계약에 속한다.

기록을 일정 기간 뒤 지우면 그 이후의 오래된 재시도를 다시 처리할 수 있다. 따라서 보관 기간과 재시도 허용 기간을 함께 정한다. 키는 사용자나 작업 범위와 연결하여 서로 다른 요청을 우연히 혼동하지 않도록 한다.

멱등성은 네트워크가 정확히 한 번만 메시지를 전달한다는 보장이 아니다. 여러 전달을 한 논리 효과로 해석하는 서비스 설계다. 모든 부수 효과까지 자동으로 한 번이 되는 것도 아니다. 본체 변경, 알림, 외부 호출 각각의 중복 의미를 정해야 한다.

조회, 자원 상태 설정, 작업 생성 등에서 멱등성을 활용하면 재시도에 강한 API를 만들 수 있다. 중요한 질문은 “응답이 같았는가”보다 “같은 작업을 다시 받았을 때 관찰 가능한 효과가 어떻게 되는가”다.

### 참고 자료

- [AWS Builders Library · Making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
- [MIT · Distributed Systems](https://pdos.csail.mit.edu/6.824/)