같은 입력을 두 번 받아도 결과가 중복되지 않게

한 번 시작했다는 사실만으로는 충분하지 않습니다

사용자가 버튼을 다시 누르거나 실행 결과를 받지 못해 같은 요청을 반복할 수 있습니다. 중요한 것은 시작 횟수보다 그 반복으로 결과가 새로 중복 생성되는지입니다.

HTTP 표준에서 멱등성은 같은 요청을 여러 번 했을 때 의도한 서버 효과가 한 번의 효과와 같은 성질을 말합니다. 아래 업무 설계는 그 생각을 적용한 편집 예시이며 HTTP 메서드 이름만으로 전체 업무의 중복 방지가 보장되지는 않습니다.

무엇을 같은 작업으로 볼지 정의합니다

파일 이름이 같아도 내용이 달라질 수 있고, 같은 내용이어도 다른 고객에게 전달하는 업무는 별개일 수 있습니다. 입력의 고유 번호, 대상, 처리 단계와 규칙 버전을 조합해 업무의 식별 기준을 정하세요.

가상의 문서 전달이라면 “문서 번호 + 확정 버전 + 수신 대상 + 전달 단계”를 구분할 수 있습니다. 이는 키 설계 예시이며 모든 작업에 필요한 필드 목록은 아닙니다.

기록과 실제 결과를 함께 확인합니다

처리 기록에 시작 상태만 남아 있다면 작업 중인지 중단되었는지 확인해야 합니다. 완료 상태는 결과가 확인된 뒤 남기고, 실패·상태 불명 항목은 별도로 관리하세요.

기록과 결과의 변경이 따로 이루어지는 작업은 그 사이에 실패할 수 있습니다. 결과는 생성됐는데 완료 기록은 없을 때 어떤 방식으로 기존 결과를 찾을지 설계하고 시험합니다.

동시에 들어오는 같은 입력도 시험합니다

차례로 실행했을 때 중복이 없다고 동시에 실행해도 같다고 확정할 수는 없습니다. 같은 입력 두 개가 모두 “처리 기록 없음”으로 판단하는 상황을 고려해야 합니다.

사용하는 저장소나 도구에서 고유 제약·잠금·하나의 처리 담당자를 어떻게 지원하는지 확인하세요. 이 글은 구현 없이 “정확히 한 번 실행”을 약속하지 않습니다.

• 같은 입력을 순서대로 두 번 넣습니다.
• 가능한 시험 환경에서 동시에 들어오는 상황을 확인합니다.
• 결과 생성 후 기록 전에 중단된 상황을 확인합니다.
• 규칙 버전이 바뀔 때 다시 처리할 범위를 정합니다.

중복 방지와 재처리 허용을 나눕니다

잘못된 결과를 고치기 위한 재처리까지 막으면 복구가 어려워집니다. 일반 재실행과 의도한 재처리를 구분하고, 재처리 이유·대상·버전을 기록하세요.

데이터를 다시 읽는 작업과 외부에 메시지나 변경을 보내는 작업은 위험이 다릅니다. 반복해도 되는 동작과 확인이 필요한 동작을 나누어 실행 순서를 정합니다.