자동화가 같은 요청을 두 번 처리하지 않게 실행 키 남기기

요청 ID와 실행 키를 분리해 재전송과 새 요청을 구분합니다. 같은 키의 완료 결과 재사용, 처리 중 중복, 내용 충돌을 서로 다른 상태로 남기는 실행 기록표입니다.

아래 업무 ID, 사람·팀 이름, 날짜와 값은 구조를 설명하기 위한 가상 자료입니다. 실제 고객 정보나 현장 성과를 포함하지 않습니다.

같은 알림 두 개가 새 업무 두 개는 아니다

예약 확인 요청이 한 번 접수됐는데 전송 지연 때문에 같은 요청이 다시 들어왔다고 가정합니다. 첫 번째 실행이 이미 안내문을 등록했다면 두 번째 실행은 같은 등록을 반복해서는 안 됩니다. 반대로 고객이 같은 내용으로 두 건을 따로 요청했다면 내용이 같다고 하나를 버려서는 안 됩니다. 내용 유사성보다 요청자가 의도한 한 건을 식별하는 키가 필요합니다.

요청 ID는 업무 접수번호이고 실행 키는 해당 요청의 부작용 있는 처리를 묶는 식별자입니다. 요청을 다시 전송할 때는 같은 실행 키를 유지하고 의도적으로 새 업무를 만들 때는 새 키를 발급합니다. KEY-42 같은 문자는 샘플일 뿐이며 실제 키 생성·유일성·보관 기간은 연결한 시스템의 설계가 필요합니다.

키와 내용 버전을 함께 대조하기

같은 실행 키에 요청 내용을 바꾸면 기존 결과를 재사용해도 되는지 알 수 없습니다. 예약 대상이나 수량, 처리 범위가 바뀌었다면 내용버전도 바뀌어야 합니다. I-004는 KEY-44가 같지만 기존 v1과 새 v2가 달라 내용충돌로 보류합니다. 키가 같다는 한 가지 조건만으로 성공 결과를 복사하지 않습니다.

원본 입력은 키에 결합한 내용버전과 함께 보관하되 개인정보 전체를 키 문자열에 넣지 않습니다. 사람이 기억하기 쉬운 이름을 ID로 쓰면 다른 요청과 충돌할 수 있으므로 업무 ID와 생성 규칙을 분리합니다. CSV에서 동일 키를 찾는 일은 사후 대조에 도움이 되지만 동시에 들어오는 두 요청을 안전하게 잠그는 기능은 제공하지 않습니다.

완료·처리 중·결과 미확인을 나누기

완료 상태에는 대상 결과 ID가 있어야 합니다. 기존상태가 완료인데 결과 ID가 비어 있으면 재사용할 결과를 찾을 수 없으므로 대조필요로 남겨야 합니다. 기존 결과가 있는 경우에는 새 결과를 만들지 않고 그 결과가 현재 요청 범위와 같은지 확인합니다. 결과 ID가 지워졌거나 다른 업무를 가리키면 완료 표시를 신뢰할 수 없습니다.

처리 중인 키가 다시 들어오면 두 번째 작업자를 즉시 실행시키지 않습니다. 먼저 첫 실행의 소유자와 진행 상태를 확인합니다. 통신 시간초과는 대상 시스템에서 실패했다는 확정이 아닙니다. 서버에는 반영됐지만 응답만 사라질 수 있으므로 결과미확인은 “실패”가 아닌 “조회가 필요한 상태”로 취급합니다.

실행 권한을 확보하고 결과를 연결하는 순서

실제 자동화에서는 키를 기록하는 작업과 대상 변경이 어디에서 보장되는지 확인해야 합니다. CSV에 미리 처리중이라고 적어 놓는 것만으로 대상 시스템의 중복 실행이 차단되지 않습니다. 해당 도구가 요청 키나 조건부 변경을 지원하는지 확인하고, 지원하지 않으면 실행자를 한 명으로 제한하고 결과 대조를 더 엄격하게 운영해야 합니다.

대상 변경 후 결과 ID를 기록하기 전에 중단될 수 있는 틈도 설계에 포함합니다. 실행 결과가 불명확하면 무조건 처리전으로 돌리지 않습니다. 대상 시스템의 접수·완료 기록을 읽어 이미 처리됐는지 확인한 다음 완료 결과를 연결하거나 동일 키 재시도를 결정합니다. 이 글은 기록 구조를 다루며 외부 도구의 원자적 트랜잭션을 구현하지 않습니다.

보관 기간이 지난 키와 늦게 온 요청

키 기록을 짧게 보관하면 오래 지연된 재전송을 새 업무로 잘못 처리할 수 있습니다. 반대로 무기한 보관하면 잘못 재사용된 키가 새 요청을 막을 수 있습니다. 내부에서는 전송이 늦어질 수 있는 기간, 결과 기록의 보관 기간, 대상 시스템의 중복 방지 기간을 함께 확인하고 키 만료 후 요청을 별도 상태로 둡니다.

I-008의 기록만료는 완료나 실패를 뜻하지 않습니다. 이 표의 판단은 기존 결과와 원요청을 수동으로 확인할 때까지 실행하지 않는 것입니다. 키를 새로 발급해 바로 재처리하면 같은 업무가 두 번 실행될 수 있습니다. 새 업무로 인정하기로 결정했다면 원래 요청과 새 키의 관계, 결정자와 근거를 남겨야 합니다.

중복을 삭제하지 않고 설명할 수 있게 남기기

중복 요청 행을 지우면 어떤 재전송이 있었는지 알 수 없습니다. 같은 키의 결과 재사용, 처리 중 중복, 다른 내용 충돌을 구분해 남기고 실제 대상 변경이 몇 번 발생했는지 결과 ID로 대조합니다. 접수 건수와 새 실행 건수를 따로 세어야 재전송이 많다는 이유로 업무량이 두 배라고 해석하지 않습니다.

허용 범위를 넘어서는 키 충돌이나 결과 불일치는 자동 실행을 멈추고 조사합니다. 이미 두 결과가 만들어졌다면 하나를 조용히 삭제하지 않고 업무 영향을 확인합니다. 결제·발송·예약 취소처럼 되돌리기 어려운 처리는 제공 서비스의 공식 계약과 실제 지원 기능을 먼저 검토해야 하며 이 기록표만으로 안전한 반복 실행을 보장할 수 없습니다.

상태를 바꾸는 조건

작업표에 입력하는 순서

1. 하나의 요청 의도를 정하고 접수 ID와 실행 키를 연결합니다.
2. 같은 키의 기존 내용버전·상태·결과 ID를 조회합니다.
3. 키 누락과 내용 충돌은 신규 실행 전에 보류합니다.
4. 처리 중 또는 결과 미확인 건은 기존 실행을 먼저 대조합니다.
5. 새 실행은 해당 도구가 제공하는 처리권 확보 방식으로 시작합니다.
6. 결과 ID를 연결하고 재전송에는 같은 키를 유지합니다.

샘플 기록과 행별 해석

I-001 — 기존 키가 없는 신규 요청입니다. 신규대기는 실행 완료가 아니라 중복 여부를 대조하고 처리권을 확보할 준비가 됐다는 뜻입니다. 같은 시각에 다른 실행자가 들어올 수 있으므로 기록표만으로 동시에 처리하지 않습니다.

I-002 — 기존버전과 새버전이 v1로 같고 완료 결과 RES-42가 있습니다. 새 등록을 만드는 대신 RES-42를 확인합니다. 결과 재사용도 대상·범위가 일치하는지 읽어 보는 절차이며 표시만 복사하는 작업이 아닙니다.

I-003 — KEY-43은 기존 실행이 처리중입니다. 두 번째 요청은 중복보류이며 첫 실행의 결과가 나올 때까지 별도 실행하지 않습니다. 일정 시간 응답이 없다고 기존 결과 확인 없이 새 키를 만들면 중복 방지 의도가 사라집니다.

I-004 — 기존 v1을 v2로 바꾸면서 KEY-44를 유지한 입력입니다. 충돌 상태로 멈추고 정정인지 새로운 업무인지 확인합니다. RES-44가 있다는 이유로 변경된 v2 요청을 완료로 표시하지 않습니다.

I-005 — 실행 키가 빈 신규 요청입니다. 요청 ID가 존재한다고 키가 자동으로 만들어졌다고 해석하지 않습니다. 키 발급 기준을 확정하고 입력한 후 재검사하며 임의로 첫 열의 기록 ID를 복사하지 않습니다.

I-006 — 기존 실행의 결과가 확인되지 않았습니다. 오류 응답과 대상 반영 여부를 분리해 조회합니다. 결과가 발견되면 같은 요청에 연결하고, 없다는 근거가 충분할 때만 도구의 지원 범위 안에서 같은 키 재시도를 검토합니다.

I-007 — 기존 실행이 재시도가능으로 분류됐습니다. 이는 원인과 대상 결과를 확인한 뒤 붙이는 상태이며 모든 실패의 기본값이 아닙니다. 재전송 때 KEY-47을 유지하되 내용버전 v1도 유지해야 합니다.

I-008 — 기존 키의 기록 보관 범위가 끝났습니다. 신규와 동일하게 처리하지 않고 원요청과 대상 결과를 수동 대조합니다. 기록만료는 요청 효과가 사라졌다는 증거가 아니므로 새 실행 전에 판단 근거를 확보합니다.

이 글의 기록 양식 내려받기

자동화가 같은 요청을 두 번 처리하지 않게 실행 키 남기기 — CSV 양식

UTF-8 BOM이 있는 기록용 CSV입니다. 계산식·드롭다운·서식은 들어 있지 않습니다. 첫 행 9열, 설명용 데이터 8레코드가 있습니다.

모든 행은 가상 입력이며 실제 개인정보·성과 기록이 아닙니다.

CSV에 자동 차단·알림·권한 통제·실행 기능은 없습니다.

CSV 구조와 식별자 점검 도구에서 사본의 열 수와 문자열을 확인할 수 있습니다.

작업표 사용 범위

CSV는 열 이름과 샘플 값을 제공하는 기록 양식입니다. 상태 차단, 권한 확인, 알림, 자동 실행은 포함하지 않습니다. 파일을 가져온 도구에서 ID와 시각을 원문대로 보존하고, 담당자와 기준을 실제 업무에 맞게 바꿔야 합니다. 빈칸은 누락 여부를 확인하기 위한 입력이며 임의로 완료나 0으로 바꾸지 않습니다.

예상 결과를 대조할 입력

근거 자료와 적용 범위

공식 자료는 아래에 적힌 기능과 개념을 확인하는 데 사용했습니다. 업무 상태 이름, 담당 배정, 시간 기준과 샘플 숫자는 이 글에서 설계한 운영 예시입니다.

• AWS 재시도와 멱등 API 설계 — 호출자가 만든 요청 식별자와 재시도의 의도를 구분하는 설계 설명을 참고합니다. 이 글의 CSV가 같은 수준의 원자적 실행을 제공하지는 않습니다.
• Amazon EC2 API 멱등성 공식 문서 — 동일 토큰에 다른 매개변수를 넣는 경우를 포함한 제품 동작을 확인합니다. 다른 업무도구가 동일하게 동작한다고 가정하지 않습니다.