소스로 역추적한 주석의 뜻

여러 대에 걸린 배치 스케줄이 배정표대로 등록돼 있는지 점검하면서 표가 아니라 각 기계의 실제 등록 상태를 조회했다. 네 대를 훑는 동안 스크립트 헤더의 주석 하나가 표와 어긋나는 것을 발견했다.

Open Table of contents

표가 아니라 기계에 묻기

배정표에는 머신마다 몇 시에 무엇을 돌리는지 적혀 있지만 그것이 맞는지는 기계에 물어야 안다. 운영체제마다 조회 명령이 달라 각각의 방식으로 등록 목록을 뽑았다.

문서를 문서로 확인하면 순환이므로 문서에서 기계로 그리고 소스로 내려가야 한다. 표만 봤다면 전부 맞다고 판정하고 끝냈을 자리였다.

주석에는 삭제 작업 외부 스케줄을 이 스크립트가 관리하지 않는다는 문장이 있었다. 그것을 읽고 별도 삭제 작업이 어딘가 있어야 한다고 이해했는데 네 대 어디에도 없었다.

네 대 모두가 같은 항목을 빠뜨렸다고 보기는 어려운 상황이었다. 그래서 그 작업이 무엇을 부르는지부터 소스에서 확인하기로 했다.

소스에서 그 삭제 작업이 쓴다는 플래그를 찾으니 아예 없었고 실행 모드는 셋뿐이었다. 삭제만 수행하는 모드가 없으므로 그런 작업을 걸 방법 자체가 없었다.

정리 절차는 검증 모드 안에서 검증이 끝난 뒤에 이어서 호출되고 있었다. 즉 정리는 매일 도는 검증 스케줄에 딸려 돌고 있어 별도 작업이 필요 없는 구조였다.

주석 원문을 다시 읽으니 외부에 별도로 두는 경우라는 조건절이 앞에 있었다. 만약 외부에 둔다면 그것은 이 스크립트가 관리하지 않는다는 뜻이었다.

나는 그것을 외부에 두어야 하고 그것은 이 스크립트 밖이라는 뜻으로 읽었다. 조건부 안내를 필수 구성으로 읽으면 존재하지 않는 작업을 찾아 헤매게 된다.

주석이 말한 일 분 뒤라는 오프셋의 근거도 소스 두 곳의 주석에서 확인했다. 업로드를 수행하는 컨테이너와 정리 작업이 같은 볼륨을 공유하고 있었다.

같은 분에 돌리면 업로드가 쓰는 중인 파일을 정리가 지울 수 있으므로 순서를 보장하려고 미룬 것이었다. 이유를 알고 나니 굳이 외부에 두겠다면 그 머신의 업로드 시각 기준으로 밀어야 한다는 규칙이 명확해졌다.