문서는 고쳤는데 관리 화면은 예전 모습이라면 무엇부터 확인해야 할까. 나는 관제탑의 오래된 작업 대화와 현재 코드를 함께 읽었다. 계속 진행을 지켜보는 대신 결과 폴더의 변화를 감지해 달라는 요구가 있었다. 그 요구를 따라가니 감시 횟수보다 더 중요한 질문이 남았다. 변화를 본 뒤 전달이 끝나지 않았을 때, 아직 해야 할 일을 어디에 남기는가.
일을 시키는 곳과 결과를 보여 주는 곳
당시 대화에서는 담당 작업에 명령을 전달하고 글 한 편을 마치면 끝내는 흐름을 원했다. 관제탑은 중간 과정을 계속 따라다니기보다 결과 폴더의 생성·수정·이동을 읽는 역할이었다. 이 기록은 이번에 다른 채팅에 명령을 보내라는 허가가 아니다. 나는 당시 요구와 실제 감지 코드의 책임을 비교하는 자료로 읽었다.
그 구분은 고객이 보는 완료 문구에도 영향을 준다. 파일이 바뀌었다는 소식, 관리 화면에 그 상태를 반영한 결과, 원고가 검수를 통과한 결과는 다른 사실이다. 변화 하나를 보았다는 이유로 품질과 발행까지 끝났다고 말할 수 없다. 이번 글은 그중 변화 감지 이후의 화면 전달 대기만 좁혀 다룬다.
폴더 지문은 전체 내용을 읽은 증명서가 아니었다
현재 감지기는 프로그램별 패널의 수정 시각 지문을 비교한다. 글 폴더와 그 안의 일부 파일, 정의 파일의 변화가 신호가 된다. 코드에는 표시할 폴더와 내부 파일의 개수 제한이 있고 수정 시각도 정수 초로 들어간다. 모든 파일 바이트를 비교하는 완전한 수집이나 암호학적 내용 검증으로 설명하지 않았다.
변화가 보이면 스냅샷 캐시를 비우고 pending을 참으로 만든다. 정의 파일 변화에는 별도 연결 검사도 있다. 이 단계는 새 화면 자료를 준비할 이유가 생겼다는 뜻이다. 감지 자체를 개선하는 질문과 이미 감지한 자료의 전달을 잊지 않는 질문은 다르다. 이번 합성 예제는 후자만 맡기고 원래 지문 계산을 복제하지 않았다.
실패를 반환한 뒤에도 대기가 지워지는 경로
원래 push_snap은 설정이 없거나 전송 호출에서 예외가 나면 None을 반환할 수 있다. 감시 루프는 전송 간격이 되면 이 함수를 부르고, None이 아닐 때 마지막 성공 시각을 바꾼다. 그런데 그 다음의 pending 해제는 반환값과 별개로 실행된다. 전송을 시도했다는 이유로 남은 대기를 없앨 수 있는 위치였다.
그 뒤 폴더 지문이 그대로라면 이 루프에서는 pending을 다시 참으로 만들 변화가 없다. 다른 수집이나 전송 경로가 화면을 갱신할 수 있으므로 영구 단절을 단정하지 않는다. 실제 장애가 발생했다는 운영 로그도 이번에 확인하지 않았다. 선택한 소스의 조건문을 따라 확인한 한계이며, 원래 프로그램을 실행하거나 고친 결과와 구별했다.
모든 사건을 남길지 최신 상태를 합칠지
기존 ERP 알림 글에서는 업무 사건과 수신 대상마다 outbox 행을 남겼다. 서로 다른 주문 변경을 최신 한 건으로 덮어쓰면 필요한 알림이 사라질 수 있기 때문이다. 이번에 전달하려는 것이 현재 파일 개수와 목록 같은 교체 가능한 화면 상태라면 요구가 다르다. 사이에 여러 번 바뀌었어도 최신 스냅샷 한 벌로 합칠 여지가 있다.
그래서 새 모듈은 사건 큐를 또 만들지 않고 관측한 최신 번호와 확인했다고 선언한 번호를 나눴다. 두 값이 다르면 대기가 남는다. 무엇을 합쳐도 되는지는 서비스의 의미로 결정해야 한다. 이 구조를 입금·삭제·메일 발송 명령의 자동 재실행에 붙이는 것은 이번 예제의 범위를 벗어난다.
이전 답이 새 대기까지 지우지 않도록
전송 시도를 예약한 순간의 revision을 Ticket에 붙였다. 그 사이 새 변화가 들어와도 이전 Ticket의 확인 선언은 그 번호까지만 반영한다. 최신 revision이 더 크면 대기는 그대로 남는다. 확인 시점의 모든 상태를 한꺼번에 처리했다고 쓰는 방식보다, 실제로 어떤 버전을 다루었는지 남기는 편이 명확했다.
이 판단은 독립 합성 코드에서 검증했다. 원래 관제탑에는 이 변경을 적용하지 않았다. 새 모듈도 단일 호출자의 메모리 상태만 다루며 프로세스 간 잠금, 재시작 복구와 수신 측 순서 검사는 없다. 작은 상태 계산을 실제 동기화 시스템 전체의 보장으로 넓히지 않는 것이 공유할 때의 조건이다.
재시도 전에 무엇을 모르는지 남긴다
원래 함수의 None은 설정 부재와 예외를 함께 담을 수 있어 그대로 알려진 미적용으로 바꿀 수 없다. 새 예제는 적용되지 않았다는 근거가 있는 not_applied와 결과를 모르는 unknown을 분리했다. 전자는 간격 뒤 대기를 예약할 수 있고 후자는 별도로 확인한 결과가 들어올 때까지 막는다. 시간이 지나면 불확실성이 저절로 사라지는 것은 아니다.
화면 문구도 변화 감지, 반영 대기, 결과 확인 필요처럼 근거에 맞춰 나눠 볼 수 있다. 이것은 이번 글에서 제안하는 설명 방식이며 원래 운영 UI를 바꾼 보고는 아니다. confirmed도 호출자의 선언일 뿐 서버 영수증 인증이 아니므로, 제작자는 누가 어떤 결과를 읽고 그 말을 했는지 연결해야 한다.
확인한 코드와 남겨 둔 책임
20개 시험에서 조용한 폴더의 대기 유지, 새 변화가 남는 확인 순서, 간격, 미확정 차단과 잘못된 Ticket을 확인했다. 실제 공개 ZIP의 바이트와 해시를 비교하고 추출 폴더에서도 시험한다. 인라인 선택기는 저장된 합성 기록을 읽는다. 이 결과를 원래 감시기나 외부 네트워크의 신규 성공으로 소개하지 않는다.
운영에 적용하려면 영속 대기 장부, 재시도 한도와 취소, 실제 결과 조회, 수신 측 버전 정책까지 결정해야 한다. 내가 이번에 남긴 것은 그 결정을 시작할 명확한 경계다. 변화가 더 생기지 않는다는 이유로 아직 전달하지 못한 상태까지 사라지지 않게 하려면, 감지의 수명과 전달 대기의 수명을 따로 설계해야 했다.