저장된 값은 다음 배포용이다

설정 값이 두 곳에 있고 둘이 어긋나면 문제가 되는 구조여서 어긋남을 검사하는 스크립트를 만들었다. 리뷰에서 저장소의 값이 지금 돌고 있는 값이 맞느냐는 지적을 받았다.

Open Table of contents

빌드 시점의 사본

빌드 설정을 직접 열어 보니 빌드 단계에서 저장소의 설정 파일을 한 번 복사해 오고 있었다. 실행 중인 프로세스는 그 빌드 시점의 사본을 쓴다는 뜻이다.

저장소의 값은 다음 배포가 쓸 값이고 실행 중인 값은 마지막 빌드 시점의 값이다. 저장소를 갱신해도 재배포 전까지는 아무것도 안 바뀐다.

내 검사기는 저장소 값과 코드의 목록을 비교하고 있었으므로 다음 배포 후의 상태를 검사하는 셈이었다. 지금 상태가 아니었다.

이것을 알고 나니 배포 순서가 정해졌다. 저장소 설정을 갱신하고 그 값을 쓰는 서비스를 재배포해 완료를 확인한 뒤 그다음 서비스를 배포해야 하며 가운데 두 단계를 건너뛰면 새 목록을 쓰는 쪽과 옛 목록으로 도는 쪽이 어긋난 채로 돈다.

검사기의 문서 주석에 그 전제를 적었다. 이 검사가 무엇과 무엇을 비교하는지와 실행 중인 값은 마지막 빌드 시점의 사본이라는 것과 배포 순서를 함께 남겼다.

안 적으면 다음 사람이 검사를 통과했으니 지금 상태도 맞겠거니 하고 읽는다. 검사기가 무엇을 검사하는지를 그 자리에 명시해야 오해가 안 생긴다.

더 큰 지적도 있었는데 설정이 상위 단위 목록이라 하위 식별자가 없다는 점이었다. 상위 단위가 양쪽에 있으면 검사가 통과하지만 그 하위 항목 중 하나가 폐기됐거나 오타여도 잡히지 않는다.

그래서 이 검사가 폭주 실패 모드 전체가 아니라 상위 단위 부분집합만 닫는다고 적었다. 무엇을 못 잡는지를 적지 않으면 검사가 있으니 안전하다고 생각하게 된다.

가장 근본적인 지적은 검사기가 설정만 비교하고 실제 발생을 안 본다는 것이었다. 저장소만 넓히고 코드를 배포하면 둘이 맞으니 검사는 통과하는데 실행 중인 값은 여전히 옛것이라 문제가 그대로 남는다.

검사기가 막으려던 바로 그 시나리오가 검사를 통과한다. 그래서 보장하는 것보다 보장 안 하는 것을 적는 쪽이 중요한데 검사가 있다는 사실 자체가 안심을 만들기 때문이다. 이 지적을 받고 추측으로 답하지 않고 빌드 설정 파일의 그 줄을 직접 열어 확인했다.