[AX EO-3] 회의록에서 업무 등록까지: 중복 실행을 막는 Agent

PART 1등록 버튼을 다시 누르기 전에 결과를 확인합니다

“민서 님이 월요일까지 공급사의 납기 회신을 확인합니다.” Agent가 업무를 등록하다 시간 초과를 표시합니다. 다시 실행했더니 같은 일이 두 건 생깁니다. 설명을 위한 합성 사례입니다.

대상 시스템은 이미 저장했고 응답만 사라졌을 수도 있습니다. “외부에는 무엇이 남았나요?”를 먼저 확인해야 합니다. 요청을 보냈다는 기록과 실제 업무가 존재한다는 증거를 구분합니다.

회의 액션을 업무 한 건으로 만들고 담당자에게 알리는 흐름을 설계합니다. Agent는 문장을 읽고 담당자·기한의 모호함을 해결합니다. 등록 권한·상태·중복 방지는 하네스와 연동 코드가 담당합니다. 고정된 업무 흐름으로 구현해도 이 원칙은 같습니다.

업무 연결의 전체 그림은 기존 AX 실무 운영 글에서 보실 수 있습니다.

PART 2같은 업무의 이름표를 재실행해도 유지합니다

멱등성(idempotency)은 같은 논리 작업을 반복 요청해도 의도한 효과가 중복되지 않도록 만드는 성질입니다. 이를 위해 업무의 식별자와 전송 시도의 식별자를 나눕니다. 재시도마다 전송 번호는 바뀔 수 있지만 같은 업무의 키는 유지되어야 합니다.

프로젝트 P42의 회의 M0914에 액션 A007을 부여합니다. ‘월요일’은 담당자와 확인해 2026-09-21로 확정했다고 가정합니다. ID는 저장해 재사용합니다. 모델이 다시 읽거나 문장 순서가 바뀌어도 유지합니다.

표 1 · 업무 키는 유지하고 요청 내용의 변화는 따로 감지합니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

표 1의 ID와 지문 H1은 설명용 값입니다. H1은 실제 해시 계산 결과가 아닙니다.

업무 키에는 조직 범위도 포함합니다. 다른 회사의 같은 회의 번호와 구분하기 위해서입니다. 같은 키로 담당자나 기한이 달라지면 내용 지문의 차이를 확인합니다. 새 등록 키를 발급하면 업무가 하나 더 생깁니다.

기한 변경은 기존 TASK-418을 수정하는 별도 행동입니다. 수정 권한과 확정 내용을 확인하고 변경 작업에도 식별자를 부여합니다. AWS Builders’ Library의 멱등 API 설명도 요청 식별자와 변경된 의도를 구분합니다.

권한은 원천 문장만으로 생기지 않습니다. 예제에서는 지정 프로젝트에 확정된 액션을 등록하는 권한이 이미 부여됐다고 가정합니다. 담당자 미확정, 기한 추측, 프로젝트 밖 등록은 확인 대상으로 남깁니다. 이미 승인된 내용의 동일 재시도에 매번 승인을 다시 요구할 필요는 없습니다.

PART 3시간 초과는 ‘결과 미확인’으로 남깁니다

실행 원장은 등록 대기·실행 중·성공 확인·결과 미확인·사람 확인 필요를 구분합니다. 결과 미확인은 외부가 성공했을 가능성이 남은 상태입니다. 실패와 합치면 재등록 판단이 달라집니다.

대사는 원장과 대상의 실제 상태를 맞추는 일입니다. 업무 키로 찾은 TASK-418의 프로젝트·원천 액션·담당·기한을 비교합니다. 사람이 만든 유사 업무도 있으므로 제목만으로 같은 건이라 판단하지 않습니다.

외부 조회에서 아무것도 나오지 않아도 바로 재등록하지 않습니다. 검색 반영이 늦거나 첫 요청이 처리 중일 수 있습니다. 외부의 중복 방지·요청 상태 확인 기능이 없다면 기다리거나 사람 확인으로 넘깁니다.

예제의 테스트 시스템은 같은 키의 생성 요청에 기존 결과를 돌려주며, 키로 결과를 조회할 수 있다고 가정합니다. 실제 연동에서는 적용 범위·키 보존 기간·내용 불일치 처리도 확인합니다. 외부 멱등 기능에 키를 전달하는 원칙은 AWS Agentic AI Lens에서도 설명합니다.

PART 4응답이 사라진 등록 한 건을 끝까지 따라갑니다

Worker A가 원장에 업무 키를 확보한 뒤 등록을 보냅니다. 대상은 TASK-418을 만들고, 테스트 장치는 응답을 버립니다. Worker A는 결과 미확인으로 저장합니다. 실패를 넣기 위한 합성 경로이며 실측 로그가 아닙니다.

Worker B도 같은 이벤트를 받으면 두 실행이 동시에 ‘기록 없음’을 확인할 수 있습니다. 조회와 저장을 별개로 두면 안 됩니다. 원장에 업무 키의 유일성 제약을 두고 소유권을 조건부로 확보합니다. 나머지 실행은 기존 상태를 읽습니다.

실행 소유권에는 만료와 인계가 필요합니다. A가 종료되면 B가 진행을 이어받아야 하기 때문입니다. 다만 만료된 A가 뒤늦게 응답해 B의 새 상태를 덮어쓸 수도 있습니다. 소유권 세대 번호를 대조해 오래된 실행의 원장 갱신을 거부합니다. 그 검사가 외부 요청 자체를 취소해 주지는 않으므로 대상의 중복 방지 조건도 필요합니다.

기대 결과는 업무 한 건, 외부 ID TASK-418, 원장 성공 확인입니다. 전송 횟수가 한 번이어야 한다는 뜻은 아닙니다. 여러 전송이 같은 결과를 가리킬 수 있습니다. 전송 횟수만으로 성공 여부를 판단하지 않습니다.

PART 5등록과 알림은 서로 다른 완료 상태입니다

등록 후 담당자 알림을 보내려다 연결이 끊길 수 있습니다. 전체를 재실행하면 이미 존재하는 업무까지 다시 건드립니다. 등록 성공과 알림 상태를 별도로 저장하면 알림 단계에서 재개할 수 있습니다.

외부 등록을 확인한 뒤 로컬 성공 상태와 ‘보낼 알림’을 같은 트랜잭션으로 저장합니다. 별도 발송기가 그 알림을 전달합니다. 트랜잭셔널 아웃박스(transactional outbox)는 성공 기록만 남고 알림 의도가 사라지는 문제를 줄입니다. AWS의 아웃박스 패턴

알림에도 별도 키를 사용합니다. 예제는 A007:created:assignee:1입니다. 같은 등록 완료 알림의 재전송은 같은 키로 묶고, 담당자 변경 알림은 다른 업무 이벤트로 만듭니다. 발송기가 멈춰도 N007이 남으므로 다시 읽을 수 있습니다. 아웃박스 자체가 수신자의 중복 알림을 막아 주지는 않습니다.

알림 MSG-912도 전달 후 응답을 잃었다고 가정합니다. 원장에는 ‘등록 완료, 알림 미확인’이 남습니다. N007과 연결된 MSG-912의 발송 이력을 확인하면 전달 완료로 바꿉니다. 조회·중복 방지 기능이 없다면 자동 재발송을 멈추고 사람이 확인합니다.

사용자에게도 “TASK-418 등록은 확인했습니다. 담당자 알림은 전달 여부를 확인 중입니다.”라고 안내합니다. 확인된 등록과 미확인 알림을 구분해야 이어서 처리할 위치가 보입니다.

PART 6장애를 넣은 뒤 기대 결과와 대조합니다

첫 시험은 가짜 업무·알림 서비스에서 수행합니다. 응답을 버리고 실행을 중단할 수 있도록 준비합니다. 아래는 담당자에게 전달할 채워진 시험 명세입니다. 제품에서 바로 실행되는 명령은 아니며, 결과는 실행 후 기록합니다.

scenario: meeting_action_response_loss
tenant: demo
project: P42
meeting_id: M0914
action_id: A007
action: 공급사 납기 회신 확인
assignee: 민서
due_date: 2026-09-21
business_key: demo:P42:M0914:A007:create-task
faults:
  - 외부 업무 저장 직후 등록 응답 유실
  - 같은 원천 이벤트를 Worker B에도 전달
  - 알림 전달 직후 확인 응답 유실
expected:
  task_count_for_key: 1
  task_id: TASK-418
  registration_state: succeeded
  notification_before_reconciliation: unknown
  notification_after_verified_history: sent
observed: 미실행

표 2의 장애는 초기 상태를 복원하며 하나씩 넣은 뒤 결합합니다. 원천 키·시도 ID·외부 ID·상태 변경 이유를 기록합니다. 모델의 “등록했습니다” 문구는 완료 증거가 아닙니다.

표 2 · 재시도 횟수보다 외부 효과와 복구 상태를 확인합니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

출처: 이 글의 합성 인수 시험. 표의 결과는 기대 조건이며 실행 성과가 아닙니다.

일시 오류와 권한·입력 오류를 구분합니다. 재시도 간격을 늘리고 무작위 차이와 최대 횟수를 둡니다. AWS의 재시도 제한 지침에서 설명하는 원칙입니다. 한도를 넘기면 원천과 마지막 상태를 보존해 인계합니다.

PART 7외부 지원이 없으면 정확히 한 번을 약속할 수 없습니다

외부 시스템까지 포함한 exactly-once를 로컬 키 하나로 보장할 수는 없습니다. 외부가 요청을 처리한 뒤 응답을 잃었고, 조회도 중복 방지도 지원하지 않는다고 가정해 보겠습니다. 다시 보내면 중복될 수 있고, 보내지 않으면 누락될 수 있습니다. 원장을 정교하게 만들어도 이 불확실성을 없애지는 못합니다.

키 보존 기간도 확인합니다. 외부의 중복 방지 기간이 끝난 뒤 재전송하면 새 등록으로 처리될 수 있습니다. 이벤트 재전달·작업 재개·외부 키 보존 기간을 함께 봅니다. 원장 정리도 자료 보관 정책과 이 조건에 맞춥니다.

업무 등록은 성공하고 일정 등록은 실패할 수도 있습니다. 담당자가 이미 시작한 업무를 자동 삭제하면 문제가 됩니다. 보상 처리는 허용된 별도 행동으로 설계하고, 성공한 부분을 어떻게 유지할지 정합니다.

PART 8첫 입력은 회의 액션 한 건의 복구 경로입니다

이번 주에는 회의 액션 한 건의 업무 키를 적어봅니다. 이어 등록 응답을 잃는 시험을 합니다. 업무가 어디에 존재하며 어느 단계부터 이어야 하는지 설명할 수 있는지 확인합니다.

첫 입력:
“회의 액션 A007을 업무로 등록하는 흐름을 설계해 주세요.
같은 이벤트의 중복 전달과 외부 성공 후 응답 유실을 포함하고,
업무 키·외부 ID·결과 미확인·알림 상태를 분리해 주세요.
외부 시스템이 보장하지 않는 exactly-once는 약속하지 마세요.”

같은 업무의 키는 재시도 뒤에도 유지합니다. 미확인 결과는 대상 시스템과 대사합니다. 등록과 알림을 나누면 확인된 부분을 보존하며 복구할 수 있습니다.

다음 편에서는 이 과정을 성적표로 옮깁니다. 답변이 자연스러운지뿐 아니라 업무가 완료됐는지, 사람이 얼마나 고쳤는지, 복구가 가능한지를 함께 평가합니다.

이전: 사내 RAG의 권한과 최신성 시험 · 다음: Agent 성적표 · 전체 읽기 순서

공개 자료 확인 기준: 2026-09-13. 조직·회의·이름·업무 ID·장애 경로는 합성 예제이며 실제 고객 운영 성과가 아닙니다.