요청의 동일성을 정의합니다
누가 보냈는지와 어떤 업무를 실행하는지는 다릅니다. 재시도에 유지되는 요청 식별값과 새 요청에서 바뀌는 값을 정합니다. 공급자가 주는 전달 ID가 업무 이벤트 ID인지 단순 전송 시도 ID인지도 확인해야 여러 전달을 같은 업무로 묶을 수 있습니다.
상태 전이의 가정 예시
아래는 중복 처리의 논점을 설명하는 의사 절차입니다. 특정 데이터베이스에서 바로 실행하는 코드가 아니며 실제 트랜잭션과 실패 복구를 별도 설계해야 합니다.
receive(request_key)
atomically_reserve(request_key)
if completed: return recorded_result
if in_progress: return pending_state
if reserved:
validate_business_input
execute_required_action
persist_action_result
mark_request_completed
실패 지점
외부 작업은 성공했는데 완료 표시를 저장하기 전에 중단될 수 있습니다. 가정한 예로 CRM 항목 생성 뒤 서버가 종료되면 재시도에서 기존 항목을 확인할 방법이 필요합니다. 식별키를 넣었다는 사실만으로 모든 외부 부작용이 한 번만 실행된다고 보장하지 않습니다.
시험 순서
- 같은 요청을 순서대로 두 번 보냅니다.
- 같은 요청을 동시에 보내 결과를 확인합니다.
- 작업 전·후의 중단과 재시도를 시험합니다.
- 새 요청까지 잘못 막히지 않는지 확인합니다.
키의 유효 기간과 보존, 충돌 가능성을 검토합니다. 키 자체에 이메일이나 전화번호를 넣어 로그와 URL로 퍼뜨리지 않습니다. 운영자가 강제로 재처리할 때 기존 완료 결과를 어떻게 다룰지도 정합니다.
완료 증거
원장·외부 항목·알림의 실제 수를 시나리오별로 남깁니다. 중복 방지 실패와 사용자의 정당한 재문의 차이를 설명할 수 있어야 합니다. 업무가 한 번만 처리됐다는 주장은 시험한 범위에서 보고하고 외부 도구의 제약과 미확인 장애 구간도 함께 기록합니다.
자주 묻는 질문
- 이메일이 같으면 중복 요청으로 보면 되나요?
- 같은 사람이 서로 다른 업무를 요청할 수 있습니다. 고객 식별과 요청 식별을 구분하고 어떤 기간과 범위의 동일 요청을 묶을지 업무 기준으로 정해야 합니다.
- 처리 전에 조회만 하면 충분한가요?
- 동시에 도착한 두 요청이 모두 미처리로 판단할 수 있습니다. 사용하는 저장소와 실행 환경에서 원자적 확보·제약·잠금 등 지원하는 방식을 검토하고 동시 시험을 해야 합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.