여러 실행 환경에 에이전트 기능을 배포하고 관리 문서 저장소를 검사하는 자동화가 있다. 어느 날 배포 흐름의 무결성 검사가 멈췄다. 로그를 따라가 보니 검사 로직이 망가진 게 아니라, 오래된 저장소 검사기를 불러오고 있었다.
현재 정본 저장소는 마크다운 파일만 보관한다. 그런데 예전 checker는 저장소의 manifest에 적힌 비마크다운 파일까지 그 안에서 찾으려고 했다. 검사기는 자기 규칙대로 일하고 있었지만, 그 규칙이 적용될 저장소의 계약과 맞지 않았다. 결과가 틀렸다기보다, 처음부터 다른 조건을 보고 있던 셈이다.
이런 문제는 실패 메시지 하나만 고쳐서는 해결되지 않는다. checker가 오류를 내면 사람은 흔히 규칙을 느슨하게 만들거나, 해당 검사를 건너뛰고 싶어진다. 그러면 검사가 통과해도 무엇을 검사했는지 설명할 수 없게 된다. 먼저 확인할 것은 결과가 아니라 경로다. 어떤 runtime의 checker를 불렀는지, 정본 저장소를 가리켰는지, manifest와 실제 파일 표면이 같은 계약을 쓰는지부터 맞춰야 한다.
경로를 현재 runtime checker로 바꾸고 정본 저장소를 명시하자, 그제야 실제 문제가 하나 보였다. 여러 실행 환경에 배포하는 UI 분석 기능 묶음에 오래된 포인터가 남아 있었다. 이 포인터는 완전한 8개 항목 successor 묶음으로 교체했고, 기존 항목의 정확한 내용을 이어 붙인 뒤 원자적으로 배포했다. 후속 배포 대상 전체를 다시 검사한 결과는 changed=false, blockers=[], remote_findings=[]였다.
마지막으로 경로 회귀 검사는 1/1을 통과했고, 로그 순환과 정본 저장소 불변식도 통과했다. 대화 제어기를 재시작하거나 기능 활성화 상태를 건드릴 필요는 없었다. 검사를 한 번 더 돌렸다는 사실보다, 올바른 checker가 올바른 저장소를 보았다는 증거가 남은 게 중요했다.
운영에서 “검사 완료”는 결과 한 줄로 끝나지 않는다. 검사기, 대상 표면, 계약, 발견된 변경을 함께 기록해야 한다. 그렇지 않으면 시스템은 틀린 답을 내는 대신, 아주 성실하게 다른 창고의 재고를 세고 있을 수 있다.