자동화 요청이 두 번 오면: 같은 작업을 한 번만 저장하는 실습

자동화가 답변을 못 받았다는 이유로 다시 시도했는데 같은 결과가 두 건 생길 수 있습니다. AI가 입력을 해석하는 단계와 작업을 실제로 실행하는 단계 사이에 요청을 구분하는 기준이 필요합니다. 이번에는 모델 호출 없이 그 실행 규칙만 시험합니다.

같은 요청을 두 번 전달했습니다

중복 요청 저장 실습 코드는 임시 DB에 request_id를 기본 키로 둡니다. 동일한 request-001을 두 번 전달하고 두 번째 저장을 건너뜁니다. 실제 메일이나 외부 API를 호출하지 않습니다.

python3 idempotent-task-demo.py

# 2026-10-23 실행 결과
deliveries: 2
stored_jobs: 1
outcomes: stored, duplicate_skipped
external_side_effects_tested: false

먼저 조회해서 없으면 저장하는 두 단계만 사용하면 동시 요청이 사이에 끼어들 수 있습니다. 이 예제에서는 DB의 고유 제약이 같은 키의 두 번째 저장을 막습니다. 코드의 핵심은 아래 한 문장입니다.

INSERT OR IGNORE INTO jobs VALUES (?, ?)

요청의 ID와 내용은 따로 확인합니다

실제 앱에서는 이미 처리한 ID로 전혀 다른 내용이 왔을 때도 조용히 무시하면 안 됩니다. 입력의 해시와 처리 결과를 보관하고, 같은 ID·다른 내용이면 충돌로 돌려주는 설계가 필요합니다. 예제는 동일한 입력 두 건만 전달하는 최소 실습입니다.

DB 한 행과 외부 발송은 같은 보장이 아닙니다

DB에 저장한 뒤 메일을 보내고, 완료 표시 전에 프로세스가 멈추면 재시도에서 또 보낼 수 있습니다. 반대로 먼저 완료 표시를 하고 발송에 실패하면 아무 메일도 가지 않을 수 있습니다. 외부 서비스가 지원하는 멱등 키와 상태 조회, 필요하면 발송 큐 같은 별도 설계가 필요합니다.

이 실습이 증명한 것은 동일한 요청 ID를 한 로컬 테이블에 중복 저장하지 않았다는 점입니다. 결제나 메일을 정확히 한 번 실행하는 시스템 전체를 검증한 것은 아닙니다. 성공 범위를 작게 적어야 다음 시험에서 무엇을 더 확인할지 알 수 있습니다.

처음 만드는 자동화라면 입력을 해석하는 모델을 붙이기 전에, 같은 요청 두 번과 처리 중 종료를 실행 계층에서 시험해보세요. 모델이 재시도를 제안하더라도 실행 여부는 저장된 작업 상태와 외부 결과를 근거로 판단해야 합니다.