자동화가 실패했다고 들으면 어느 단계까지 했는지부터 알아야 한다. 버튼을 찾지 못해 멈춘 것과 눌렀지만 결과를 못 읽은 것은 다른 상황이다. 나는 북극성의 단계 기록에 prepared와 dispatched를 남겨 복구가 같은 행동의 무조건 반복이 되지 않게 했다.
계획 기록은 행동의 실행 증거가 아니다
execute는 계약을 파싱하고 단계 ID를 만든 뒤 prepared 체크포인트를 남긴다. 이것은 그 단계를 준비했다는 기록이다. 실제 드라이버에 전달하는 시점에는 dispatch 콜백으로 dispatched를 저장하고 실행 세대를 다시 확인한다.
prepared만 있다고 사용자가 요청한 입력이 이미 들어갔다고 보고하면 안 된다. 반대로 화면에 변화가 없다고 전송되지 않았다고 단정해서도 안 된다. 단계 기록과 실제 결과를 함께 읽어야 한다. 나는 의도·전달·확인을 서로 다른 근거로 남기는 쪽을 택했다. 앞선 체크포인트 저장이 실패하면 기록 없이 그냥 행동을 계속하는 것도 정상 경로로 두지 않는다.
전달 뒤 오류는 더 보수적으로 다룬다
catch는 dispatched 여부와 OUTCOME_UNKNOWN 오류를 보고 outcome_unknown으로 남길지 판단한다. 이미 전달한 변경은 오류가 났다고 자동으로 없어지지 않기 때문이다. 처음부터 대상을 찾지 못한 오류와 같은 복구 정책을 쓰지 않는다.
체크포인트를 먼저 썼지만 실제 네이티브 이벤트 직전에 중단되는 틈도 있다. 따라서 dispatched 기록을 외부 서버의 확정 처리 증거로 과장하지 않는다. 기록은 재전송을 보수적으로 막는 근거이고 서버 저장의 성공 영수증은 별도다. 이 경계가 있어야 불확실성을 억지로 확정하지 않는다.
입력 내용의 미확정도 다음 작업에 이어진다
fill이나 rich text 전달 뒤 확인하지 못하면 특정 조건에서 pendingInput을 남긴다. 작업과 단계, 탭과 대상, 기대 입력이 다음 읽기 확인의 재료가 된다. 원고가 일부만 들어갔을 수도 있으므로 새로 쓰기 전에 기존 입력을 읽어야 한다.
이 자료는 내부 복구용이며 실제 원고를 공개 로그나 글로 옮기는 재료가 아니다. 민감 입력을 제외하는 조건도 있지만 그 자체를 모든 자료의 익명화로 부르지 않는다. 공개 제작기에는 상태와 규칙을 설명하고 실제 고객의 본문과 식별 정보는 넣지 않는다.
처음 클릭 전 실패와 부분 완료를 구별한다
flow에는 아직 완료된 단계가 없고 첫 클릭이 not_dispatched이며 replan 가능한 좁은 경우의 처리가 있다. 이 경우와 이전 단계가 이미 성공한 부분 실행을 같은 재계획으로 다루지 않는다. 원래 불확실하거나 부분 진행한 상태의 보호는 유지한다.
앞 단계를 다시 하면 이미 저장하거나 이동한 결과를 반복할 수 있다. 실패한 지점만 고친다고 말하려면 완료 단계와 전달 여부를 알아야 한다. 복구 계획을 새로 세우는 일과 원래 절차를 처음부터 다시 실행하는 일은 다르다. 나는 그 차이를 기록에서 읽을 수 있어야 한다고 봤다.
모든 재시작을 안전한 재실행으로 부르지 않는다
작업 실행 세대가 바뀌면 늦은 호출을 거절하고 미확정 결과는 별도 확인으로 이어진다. 브라우저를 다시 열었다고 이미 전달된 행동이 미전송으로 바뀌지 않는다. 로컬 영수증과 지속 원장, 외부 결과의 수명도 각각 다르다.
이 글은 현재 체크포인트와 오류 분류, flow의 복구 조건을 읽었다. 새 운영 예약을 일부러 중단해 재전송을 시험한 보고서는 아니다. 코드가 기록하는 단계와 실제 시스템 전체에서 정확히 한 번을 보장한다는 주장은 나눈다. 실패 기록을 정직하게 해석하는 것이 복구 기능의 일부다.
오류 안내에는 다음 확인 방향이 있어야 한다
사용자에게 실패라고만 보여 주면 다시 실행하는 것이 유일한 선택처럼 보인다. 준비 중 실패인지 전달 뒤 확인 필요인지 설명하면 먼저 읽을 대상이 달라진다. 에이전트도 그 상태를 받아 같은 버튼 대신 기존 결과를 확인할 수 있다.
회사 업무 프로그램의 저장·발송·승인에도 같은 질문을 적용할 수 있다. 어디까지 의도했고 어디까지 전달했으며 무엇을 확인했는지 남긴다. 나는 오류를 숨기는 자동 복구보다 전달 단계에 맞는 복구를 설명할 수 있는 구조를 원했다. 그래야 프로그램을 다루는 사람이 결과를 과신하지 않고 필요한 다음 일을 고를 수 있다.