AI 브라우저 에이전트가 거래처 관리자 페이지에 주문 정보를 입력하고 저장을 눌렀습니다. 그런데 완료 화면이 뜨기 전에 연결이 끊겼습니다. 에이전트 기록에는 실패로 남았지만, 거래처 시스템에는 주문이 이미 생성됐을 수 있습니다.

이때 다시 누르면 주문이 두 건 들어갈 수 있습니다. 반대로 다시 누르지 않으면 주문이 빠질 수도 있습니다. 문제는 AI가 버튼을 잘못 누른 데 있지 않습니다. 버튼을 누른 뒤 실제로 무엇이 일어났는지 모르는 상태를 실패로 처리한 데 있습니다.

브라우저 에이전트가 주문과 예약까지 처리하는 시대에는 실행 전 승인만으로 부족합니다. 승인된 일이 실제 시스템에 한 번만 반영됐는지 확인하는 장치가 따로 필요합니다.

승인과 결과 확인은 다른 통제입니다

주문을 실행하기 전에 담당자가 상품·수량·가격을 승인했다고 가정해 보겠습니다. 이 승인은 ‘이 주문을 만들어도 되는가’를 확인합니다. 저장 버튼 뒤에서 주문이 한 건 생성됐는지, 두 건 생성됐는지까지 증명하지는 않습니다.

Anthropic의 컴퓨터 사용 도구 문서는 현실에 영향을 주는 행동 전에는 사람의 확인을 받고, 실행 뒤에는 행동과 로그를 검증하라고 나눠 설명합니다.[1] 좌표를 잘못 선택하거나, 화면에 보인 상태만으로 작업이 끝났다고 가정할 수 있기 때문입니다.

승인은 무엇을 실행해도 되는지 확인합니다. 결과 대조는 승인한 일이 실제로 한 번만 반영됐는지 확인합니다. 승인을 받았다는 사실은 실행 성공의 증거가 아닙니다.

따라서 자동화 기록에도 두 사건을 분리해야 합니다.

  • 승인됨: 실행할 대상과 값이 확정됨
  • 반영 확인됨: 목적 시스템의 주문 ID와 상태를 확인함

승인됨 뒤에 바로 완료를 붙이면, 연결이 끊긴 순간부터 실제 주문과 자동화 기록이 어긋납니다.

응답 없음은 실패가 아닙니다

주문 생성처럼 외부 상태를 바꾸는 한 번의 실행에는 세 가지 결과가 있습니다.

상태확인한 사실다음 행동
반영 확인목적 시스템에서 주문 ID와 상태를 찾음결과를 기록하고 종료
미반영 확인요청이 적용되지 않았음을 확인함원인을 고친 뒤 재시도 검토
결과 미확인요청은 보냈지만 적용 여부를 모름자동 재시도를 멈추고 실제 상태 대조

로딩 표시가 멈췄거나 응답을 받지 못했다는 사실만으로는 미반영 확인이 되지 않습니다. 서버가 주문을 저장한 직후 응답 채널만 끊겼을 수 있습니다.

RFC 9110에 따르면 비멱등 요청은 원래 요청이 적용되지 않았음을 알 수 있거나, 반복해도 같은 의도된 결과가 보장될 때만 자동으로 재시도할 수 있습니다.[2] 브라우저 클릭 전체가 HTTP 요청 하나와 같다는 뜻은 아닙니다. 다만 외부 상태를 바꾼 뒤 응답을 잃었을 때, 응답 없음 = 실패로 해석하면 안 된다는 원칙은 같습니다.

한 작업이 재고 차감·주문 생성·알림 발송처럼 여러 단계라면 일부 반영도 별도로 남겨야 합니다. 앞 단계가 끝났다는 사실을 지우고 전체 작업을 처음부터 반복하면 다른 중복이 생깁니다.

작업 ID를 적는 것만으로 중복이 막히지는 않습니다

같은 주문 의도에 고정된 작업 ID를 붙이는 것은 필요합니다. 예를 들어 승인된 주문 한 건에 operation-20260816-0042를 부여하고, 재시도할 때도 같은 ID를 사용합니다.

그러나 ID 문자열을 메모 칸에 적는 것과 목적 시스템이 중복 실행을 거부하는 것은 다른 통제입니다.

강한 중복 방지는 목적 시스템이나 그 앞의 지속 계층이 같은 작업 ID를 원자적으로 한 번만 접수하고, 두 번째 요청에는 새 주문을 만들지 않은 채 이전 결과를 돌려줄 때 가능합니다. 재시도 전체에 같은 작업 ID를 유지하고, 기존 결과를 먼저 확인하며, 동시 실행에서도 안전한 조건부 쓰기를 사용해야 합니다.[3]

반면 외부 관리자 페이지의 메모·참조번호에 작업 ID를 남기고 저장 전에 검색하는 방식은 대조에 유용한 단서입니다. 하지만 두 실행이 같은 시각에 검색해 모두 ‘아직 없음’을 확인한 뒤 각각 주문을 만들 수 있습니다. 이 구조를 완전한 멱등성이라고 부르면 안 됩니다.

외부 포털이 중복 거부를 지원하지 않는다면 사내 실행기에 지속 원장을 두고, 한 작업 ID를 동시에 하나만 처리하도록 잠가 중복 가능성을 낮출 수 있습니다. 그래도 저장 뒤 결과를 확인하지 못했다면 잠금을 풀고 다시 실행하지 않습니다. 결과 미확인으로 남겨 목적 시스템을 조회하거나 사람에게 대조를 요청합니다.

재시도를 결정하는 주체는 AI가 아니라 실행기입니다

AI는 화면에서 주문번호 후보를 찾고, 오류 문구를 분류하고, 다음 확인 화면을 제안하는 데 유용합니다. 그러나 로딩 아이콘이나 성공 메시지를 보고 재시도 여부까지 그때그때 판단하게 하면 같은 상황에서도 행동이 달라질 수 있습니다.

상태 전환은 제품의 실행기가 고정 규칙으로 관리해야 합니다.

  1. 승인된 입력과 작업 ID를 함께 고정합니다.
  2. 실행 전 지속 원장에서 해당 작업의 진행 상태를 잠급니다.
  3. 주문 변경은 한 번만 전송합니다.
  4. 목적 시스템의 주문 ID나 조회 가능한 사후 상태로 반영 여부를 확인합니다.
  5. 확인하지 못하면 자동 재시도를 차단하고 대조 대기함으로 보냅니다.

API를 사용하더라도 공급자가 같은 작업 ID의 중복 접수를 거부하는지, 권위 있는 결과 ID를 돌려주는지, 그 결과를 다시 조회할 수 있는지를 확인해야 합니다. API라는 이름만으로 이 다섯 단계가 생기지는 않습니다. 브라우저를 써야 한다면 주문 목록·참조번호·처리 시각처럼 결과를 다시 찾을 수 있는 경로와 사람에게 넘길 기준을 먼저 정해야 합니다.

세션 파일과 화면 로그도 보호해야 하지만, 이번 문제의 중심은 보안 설정 하나가 아닙니다. AI가 모르는 결과를 아는 척하지 못하게 실행 상태를 설계하는 일입니다.

가장 먼저 시험할 것은 연결이 끊기는 순간입니다

정상 화면에서 주문 한 건을 만드는 데모만으로는 중복 주문 위험을 찾기 어렵습니다. 저는 실제 반영 직전과 직후에 연결을 끊는 시험부터 하겠습니다.

  • 저장 직후 응답이 사라져도 주문을 다시 찾을 수 있는가
  • 같은 작업 ID가 동시에 두 번 들어오면 한 실행만 진행되는가
  • 주문 목록 반영이 늦어져도 자동 재시도가 멈추는가
  • 일부 반영 건을 처음부터 반복하지 않는가
  • 결과 미확인 건을 누가, 어떤 근거로 확정하는가

평가할 숫자도 단순 성공률만으로는 부족합니다. 중복 생성 건수, 결과 미확인 건수, 실제 상태를 대조하는 데 걸린 시간, 사람에게 넘어간 건수를 함께 봐야 합니다.

저라면 API와 브라우저 중 무엇이 더 최신인지부터 묻지 않습니다. 같은 작업 ID의 중복 접수를 거부하는지, 권위 있는 결과 ID를 돌려주는지, 그 결과를 다시 조회할 수 있는지를 먼저 확인합니다. 이 세 가지를 제공하는 연결 방식을 주문 변경 구간에 사용하겠습니다. 결과 미확인에서 자동으로 멈추는 일은 공급자가 아니라 사내 실행기가 책임져야 합니다.

브라우저는 API가 없는 시스템을 연결하는 좋은 다리입니다. 다만 상대 시스템이 중복 거부를 보장하지 않는다면 그 한계를 계약과 운영 문서에 그대로 남겨야 합니다. 완전한 보장을 말하는 대신 사내 실행기의 동시 실행 제한과 지속 원장으로 위험을 줄이고, 결과 미확인에서는 사람이 확인하도록 설계해야 합니다.

AI가 주문 버튼을 누르는 장면은 자동화의 시작입니다. 운영 가능한 자동화는 연결이 끊긴 뒤에도 실제 결과를 찾아내고, 찾지 못하면 다시 누르지 않는 시스템입니다.

출처