노트북 실행 셀을 다시 눌렀을 때 모든 항목을 처음부터 처리하면 완료된 전송까지 반복될 수 있다. 반대로 같은 입력은 언제나 과거 결과만 보여 준다면 다음 주의 새 업무를 할 수 없다. 나는 업무 묶음과 항목의 식별자를 남겨 이어하기와 새 회차를 구분하고 그 안에서 입력과 정의가 바뀌지 않았는지 확인했다.

업무 묶음과 그 안의 항목을 함께 식별한다

프로젝트 업무 노트북은 job_id와 각 item.id를 전달한다. 원장은 프로그램과 프로젝트 context의 key, 업무 ID로 위치를 나누고 항목별 입력 지문과 정의 hash, 상태와 runId를 남긴다. 표시 제목이 같은 항목도 ID가 다르면 다른 처리 단위다.

같은 업무를 이어갈 때는 이 ID를 유지해야 한다. 셀을 다시 실행할 때마다 무작위 새 ID를 만들면 원래 항목의 완료 기록을 찾을 수 없다. 나는 식별자를 기술자가 알아서 바꾸는 내부 값보다 이어하기의 의미를 보존하는 업무 자료로 봤다. 새 회차와 같은 회차를 구분하는 기준을 코드 밖에서도 설명할 수 있어야 했다.

입력과 정의가 같아야 완료 결과를 재사용한다

같은 항목을 찾으면 먼저 입력 지문을 비교한다. 다르면 NOTEBOOK_ITEM_INPUT_CHANGED이고 정의 hash가 다르면 PROGRAM_CHANGED다. 두 값이 맞고 이전 상태가 succeeded일 때 저장 결과와 runId를 reused로 돌려준다. 이전 성공 문구만 보고 달라진 자료를 완료 처리하지 않는다.

입력 지문은 키와 값을 정렬한 뒤 만든다. 살아 있는 SDK 실행의 JSON 직렬화 지문과는 구성 방식이 다르다. 나는 여러 층이 모두 같은 비교를 한다고 뭉뚱그리지 않는다. 원장에는 어떤 기준으로 같은 항목이라고 보았는지 남아야 다른 PC나 다른 대화에서도 이어하기의 조건을 이해할 수 있다.

실행 의도를 먼저 저장하고 실제 작업을 부른다

새 항목은 running 상태와 입력 지문, hash를 원장에 저장한 뒤 ports.execute를 호출한다. 첫 행동 뒤에야 원장을 만들면 그 사이 앱이 꺼졌을 때 실행 여부를 설명할 자료가 없을 수 있다. 작업이 돌아온 뒤에는 실제 runId와 결과, 확인한 단계와 오류를 기록한다.

파일 저장은 임시 파일을 쓴 뒤 rename하는 경로다. 이것을 모든 저장장치의 무손실 트랜잭션으로 확대하지 않는다. 저장이 실패하거나 기록이 잘못됐을 때도 완료로 꾸미지 않아야 한다. 나는 실행을 했는지보다 먼저 “실행하려던 항목이 무엇이었는지” 남기는 순서를 중요하게 봤다.

실패 항목을 모두 다시 실행하는 규칙은 없다

이전 항목이 성공하지 않았다고 무조건 재실행하지 않는다. 읽기 전용 절차와 전용 전달 원장을 가진 제한된 업무, 전달 전 실패가 확인된 경우처럼 실제 조건을 검사한다. 일반 클릭과 변경의 결과가 불확실하면 NOTEBOOK_ITEM_NEEDS_REVIEW로 멈춘다.

새 job_id를 만들어 이 보호를 피하는 것은 이어하기가 아니다. 먼저 원래 서비스 결과를 확인해야 한다. 새로운 회차가 정말 필요하다면 새 의도와 대상, 입력을 확인하고 별도 업무로 시작한다. 나는 ID 변경을 오류를 없애는 편법으로 안내하지 않고 업무 수명을 명시하는 선택으로 남겼다.

시험은 완료 항목의 실행 횟수를 센다

기존 단위 시험은 서비스를 새로 만든 뒤 같은 완료 항목을 부르면 reused이고 execute 횟수가 늘지 않는지 확인한다. 별도 읽기 항목의 실패는 조건에 따라 이어서 완료되고 이전 실패 이력이 남는지도 본다. 미확정 변경은 다시 호출해도 실행 횟수가1에 머물러야 한다.

입력 변경과 다른 프로필 접근은 거절되고 프로젝트 key가 달라지면 다른 원장 목록을 읽는다. 이 근거는 소유한 임시 폴더와 execute 대역을 사용하는 기존 시험이다. 이번 집필에서 실제 업체 전송이나 브라우저 행동을 새로 반복하지 않았다. 대역 시험의 완료를 실제 외부 처리의 완료로 옮기지 않는다.

같은 입력도 다른 업무일 수 있다는 것을 남긴다

매주 같은 제목의 보고서를 처리해도 이번 주 업무는 지난주와 다른 회차일 수 있다. 입력값만으로 모든 중복을 판단하면 필요한 새 작업까지 막을 수 있다. 그래서 업무 ID와 항목 ID를 두고 그 안에서는 내용이 바뀌지 않았는지 대조한다. 동일 내용과 동일 업무를 나눈 것이다.

다른 사람이 이어서 작업할 때는 어떤 ID를 유지해야 하는지, 어느 항목이 완료됐고 어디서 실제 결과를 읽어야 하는지 알 수 있어야 한다. 나는 이어하기를 모든 것을 다시 시도하는 버튼으로 만들기보다 기존 사실을 먼저 읽고 남은 일만 수행하는 구조로 만들려 했다. 원장은 그 판단을 대화 기억 밖에 남기는 방법이다.