Idempotency

네트워크와 분산 시스템에서는 '요청이 한 번만 온다'고 가정할 수 없습니다. 타임아웃 뒤 사용자가 다시 누르거나, 메시지 큐가 같은 작업을 재전달하거나, 소비자가 중간에 죽었다가 다시 처리할 수 있습니다. 이때 같은 요청이 두 번 실행되면 결제가 두 번 되고 재고가 두 번 줄어드는 식의 문제가 생깁니다. Idempotency는 이런 중복 실행 위험을 최종 상태 차원에서 제어합니다.

클라우드 환경과 메시지 기반 시스템이 일반화되면서, 적어도 한 번 전달되는 메시지와 네트워크 재시도는 예외가 아니라 기본 전제가 되었습니다. 사용자는 실패했는지 몰라 다시 누르고, 시스템은 성공 응답을 받지 못해 다시 시도합니다. 이런 현실에서 '정확히 한 번'만 믿는 설계는 쉽게 깨졌고, 반복을 견디는 Idempotency가 핵심 원칙으로 자리 잡았습니다.

보통 요청에는 고유 키를 붙이고, 처리하는 쪽은 그 키를 기준으로 이미 처리한 요청인지 확인합니다. 이미 같은 요청이 반영됐다면 새로 상태를 바꾸지 않고 같은 결과를 돌려주거나 안전하게 무시합니다. 핵심은 '실행 횟수'가 아니라 '최종 상태'를 한 번처럼 유지하는 데 있습니다.

Idempotency와 Circuit Breaker는 모두 재시도 이야기와 함께 나오지만 다루는 층이 다릅니다. Idempotency는 같은 요청이 다시 실행돼도 상태가 깨지지 않게 만드는 속성이고, Circuit Breaker는 실패하는 호출을 잠시 차단해 시스템 전체를 보호하는 패턴입니다. 즉 하나는 중복 실행의 안전성, 다른 하나는 호출 경로의 보호에 초점이 있습니다.

결제, 주문 생성, 포인트 적립, 메시지 소비처럼 중복 실행이 비용이나 데이터 손상을 만드는 흐름에서는 Idempotency가 거의 필수입니다. 특히 큐와 재시도, 분산 흐름을 쓰는 순간 이 속성은 선택이 아니라 안전장치가 됩니다. 다만 키 설계와 보관 기간을 어설프게 잡으면 오히려 애매한 중복 판정이 생길 수 있어, 운영 기준까지 함께 정해야 합니다.

다음에 볼 개념

함께 보면 좋은 개념