Idempotency

사용자가 결제 버튼을 눌렀는데 응답이 오지 않아 한 번 더 누릅니다. 서버는 첫 번째 요청을 이미 처리했지만, 응답이 네트워크에서 유실됐습니다. 이제 같은 결제 요청이 두 번 서버에 도착한 셈입니다. 서버가 둘 다 처리하면 금액이 두 번 빠져나갑니다. 메시지 큐에서도 비슷한 일이 생깁니다. 소비자가 메시지를 처리하고 커밋하기 직전에 죽으면, 큐는 그 메시지를 다시 전달합니다. 재고가 두 번 줄거나, 포인트가 두 번 쌓이거나, 같은 알림이 두 번 발송됩니다. '정확히 한 번'을 보장하기 어려운 인프라에서 중복 실행의 부작용을 막을 방법이 필요합니다.

온프레미스 환경에서 동기식 트랜잭션이 중심이던 시절에는 요청이 정확히 한 번 처리되는 것을 상대적으로 강하게 보장할 수 있었습니다. 클라우드로 넘어오면서 네트워크는 더 불안정해졌고, 메시지 큐, 이벤트 스트림, 비동기 처리가 기본이 되었습니다. 대부분의 메시지 시스템은 '적어도 한 번 전달(at-least-once delivery)'을 기본으로 제공하고, '정확히 한 번(exactly-once)'은 예외적인 경우에만 보장됩니다. 동시에 Circuit Breaker와 재시도 정책이 보편화되면서, 같은 요청이 의도적으로 다시 실행되는 상황이 정상 운영의 일부가 되었습니다. 이 환경에서 Idempotency는 선택이 아니라 재시도 기반 설계의 안전망으로 자리를 잡았습니다.

구현 방식은 크게 세 단계입니다. 먼저 요청에 고유한 식별자(Idempotency Key)를 붙입니다. 클라이언트가 생성한 UUID이거나, 요청 내용을 해싱한 값일 수 있습니다. 처리하는 쪽은 그 키를 기준으로 이미 처리된 요청인지 확인합니다. 이미 같은 키로 처리된 기록이 있으면 상태를 다시 변경하지 않고 이전 결과를 돌려주거나 안전하게 무시합니다. 핵심은 실행 횟수를 세는 것이 아니라, 같은 키에 대해 최종 상태가 한 번 반영된 것과 같게 유지하는 데 있습니다. 키 확인과 상태 변경은 원자적으로 처리되어야 중간에 죽어도 두 번 실행되지 않습니다.

Idempotency와 Circuit Breaker는 모두 재시도와 함께 언급되지만 다루는 문제가 다릅니다. Circuit Breaker는 실패 빈도가 임계치를 넘을 때 호출 자체를 잠시 막아 시스템을 보호하는 패턴이고, Idempotency는 호출이 실행됐든 차단됐든 결국 다시 실행될 때 결과가 중복 반영되지 않게 하는 속성입니다. 둘은 서로 대체하지 않고 함께 동작합니다. Circuit Breaker가 없어도 Idempotency는 필요하고, Idempotency가 없으면 Circuit Breaker로 호출을 막더라도 재전달 시점에서 문제가 생깁니다.

결제 처리, 주문 생성, 포인트 적립, 알림 발송, 재고 차감처럼 중복 실행이 비용이나 데이터 손상을 만드는 흐름에서 Idempotency는 거의 필수입니다. '같은 API가 여러 번 호출될 수 있는데 결과는 한 번만 반영돼야 한다'거나 '큐 소비자가 재시작되면 같은 메시지를 다시 처리할 수 있다'는 상황이 신호입니다. 다만 Idempotency Key의 유효 기간과 저장 공간을 어떻게 관리할지, 오래된 키를 언제 만료시킬지는 처음 설계할 때 함께 정해야 합니다. 이를 어설프게 두면 오래된 요청이 새로운 요청으로 오인되거나, 반대로 정상 재시도가 중복으로 판정되는 경우가 생깁니다.