완료한 항목의 본문을 고친 뒤 같은 실행 셀을 누를 수 있다. 그때 화면에 예전 성공만 다시 나오면 새 본문도 처리된 것처럼 보인다. 나는 같은 항목 ID를 찾았다는 사실보다 내용과 정의가 그대로인지 먼저 확인하게 했다. 이 글에서는 ID의 역할보다 수정 후 어떤 검토를 다시 해야 하는지에 초점을 맞췄다.
준비 뒤 입력이 바뀔 수 있다는 전제로 본다
노트북의 입력 셀과 준비 셀, 실행 셀은 따로 있다. 사용자가 준비를 확인한 뒤 입력을 고칠 수도 있다. Workflow.run이 준비를 다시 요청하고 runItem이 입력을 다시 해석하는 이유다. 과거 준비 결과를 영구 실행 허가처럼 보관하지 않는다.
이 단계에서 쓰는 입력은 정의 기본값과 이번 값을 합친 자료다. 입력 지문의 의미를 설명할 때도 어떤 값이 실제 비교에 들어가는지 봐야 한다. 나는 본문 한 칸을 고쳤다는 화면상의 사실과 실행기에 전달된 최종 자료를 같은 것으로 추정하지 않는다. 값이 만들어지는 경로를 다시 읽어야 한다.
입력 변경을 완료 결과보다 먼저 검사한다
이전 항목을 찾으면 입력 지문과 정의 hash를 먼저 대조한 뒤 succeeded 결과를 재사용한다. 순서가 반대라면 과거 성공이 있다는 이유로 달라진 입력의 검토를 건너뛸 수 있다. 입력 지문이 다르면 INPUT_CHANGED로 멈추고 정의가 다르면 PROGRAM_CHANGED로 멈춘다.
정의가 같은지와 값이 같은지는 서로 다른 질문이다. 본문만 고친 경우에는 실행 코드의 재검증보다 새 자료를 어떻게 처리할지 판단해야 한다. 코드가 바뀐 경우에는 이전 결과가 어느 버전의 결과인지 확인해야 한다. 나는 이 두 변경을 하나의 “다시 시도” 문구로 묶지 않으려 했다.
지문 비교는 문장의 뜻을 판단하지 않는다
항목 지문은 정렬한 키와 값으로 만든다. 키 순서가 달라지는 것과 문자열 공백이 달라지는 것은 다른 변화다. 의미가 비슷한 두 문단을 같다고 보지 않으며 원문이 달라지면 다른 입력이 될 수 있다. 검토자가 읽은 내용과 실제 전달할 내용의 경계를 지키는 비교다.
hash가 같다고 사실과 문장이 옳다는 뜻도 아니다. 과거 글의 날짜나 숫자가 이번에도 맞는지는 별도 검토가 필요하다. 나는 코드의 동일성 검사를 내용 판단 대신 쓰지 않는다. 지문은 달라졌음을 알려 주는 도구이며 어떻게 처리해야 하는지 결정하는 편집자가 아니다.
오류를 없애려고 ID부터 바꾸지 않는다
입력이 바뀌었다는 오류를 받았을 때 곧바로 item ID나 jobId를 바꾸면 예전 원장의 연결을 벗어나게 된다. 정상적인 새 업무라면 새 항목이 필요할 수 있지만 이미 전달된 변경이 불확실한 경우에는 먼저 원래 결과를 읽어야 한다. 새 ID가 그 불확실함을 없애 주지 않는다.
사용자에게는 이전 입력과 이번 자료가 다른지, 원래 작업이 실제 완료됐는지, 새 수정이 별도 실행을 필요로 하는지 설명할 수 있어야 한다. 나는 자동으로 항목을 재생성해 오류 표시만 없애는 흐름을 피한다. 변경 원인을 드러낸 거절이 실제로 필요한 질문을 남겨 준다고 봤다.
진단에는 입력 전체를 다시 싣지 않는다
program.status는 항목 지문과 정의 hash를 빼고 상태와 실행 위치, 결과·오류를 반환한다. 입력 사전을 직접 다시 보내는 구조는 아니다. 다만 result 안에는 실제 처리 결과가 있고 그 결과가 입력 일부를 포함할 수도 있다. 이 필터를 모든 민감 자료가 제거되는 익명화라고 설명하지 않는다.
기존 시험은 입력 변경·정의 변경·프로필 변경을 따로 거절하고 미확정 변경을 재실행하지 않는지 본다. 시험 결과의 출력 대역과 실제 현장 자료는 다르다. 이번 글에서는 코드를 읽었고 고객의 실제 입력을 새로 비교하거나 보내지 않았다. 진단에 필요한 최소 근거와 공개 가능한 설명의 범위도 따로 유지했다.
수정이 있었다면 성공 문구도 다시 읽어야 한다
운영자는 값 하나를 바꿨을 뿐인데 프로그램은 이미 끝났다고 말할 수 있다. 그 간극을 막으려면 성공 문구가 어떤 입력과 정의의 결과인지 연결돼 있어야 한다. 나는 기록의 재사용을 빠른 응답보다 정확한 설명을 제공하는 기능으로 보고 있다.
견적 금액과 보고 기간, 첨부 자료를 바꾸는 회사 프로그램도 같다. 과거 완료가 현재 수정의 완료로 번지지 않게 해야 한다. 무엇이 달라졌는지 말해 주고 필요한 검토를 다시 요청하는 것이 편의를 떨어뜨리는 일만은 아니다. 잘못된 완료를 믿고 다음 업무로 넘어가는 비용을 줄이는 방법이기도 하다.