컨테이너 안 파일에 쓰는 코드

지난 이 주의 기록을 훑으며 조치가 필요한 항목을 추리다가 월목표 기능이 로컬 파일 기반이라 운영 반영이 필요하다는 메모를 발견했다. 확인하려고 파일을 열었는데 내 체크아웃이 오래돼 그 코드가 없었으므로 체크아웃을 바꾸지 않고 원격 리비전의 파일을 직접 읽었다.

Open Table of contents

요청이 만든 상태를 둘 곳

코드는 갱신 요청의 내용을 컨테이너 안의 파일에 그대로 기록하는 형태였다. 읽기도 같은 파일을 열어 돌려준다.

요청이 상태를 만드는데 그 상태를 둘 자리가 컨테이너 내부라는 것이 문제의 전부다. 그 자리는 컨테이너의 수명과 함께 사라지고 인스턴스마다 따로 존재한다.

이 코드를 로컬에서 돌리면 완벽하게 동작하는데 저장하면 남고 다시 읽으면 나오며 재시작해도 유지된다. 테스트도 전부 통과한다.

운영은 무상태 컨테이너 환경이라 재배포 시점에 파일이 사라지고 인스턴스가 여럿이면 저장한 곳과 읽는 곳이 달라진다. 같은 코드가 실행 환경에 따라 맞기도 하고 틀리기도 한다.

코드 자체는 정상이라 파일 쓰기도 읽기도 오류 처리도 문제가 없다. 틀린 것은 코드와 실행 환경의 조합이다.

리뷰어가 배포 형태를 함께 떠올려야 발견되는데 그 정보는 코드 어디에도 적혀 있지 않다. 그래서 이 유형은 리뷰를 통과하고 배포 이후에만 드러난다.

메모에는 운영 반영이 필요하다고만 적혀 있었지만 브랜치를 올리는 것만으로는 해결되지 않는다. 오히려 배포하면 틀린 동작이 운영에 나가 담당자가 입력한 값이 다음 배포에 사라진다.

선행 조건이 있는 작업을 배포하면 된다고 적으면 그 조건 자체가 기록에서 사라진다. 무엇을 먼저 해야 하는지를 같은 줄에 적어야 다음에 읽는 사람이 순서를 지킨다.

객체 저장소로 옮기면 되겠다고 생각하고 코드를 더 봤는데 그 저장소에 쓰는 경로가 아예 없었다. 읽기만 있고 쓰기는 구현되지 않은 상태였다.

쓰기 구현과 권한 부여와 저장소 정책 변경이 함께 필요하므로 경로만 바꾸면 되는 작업이 아니었다. 그래서 로컬 파일에 쓰는 엔드포인트를 발견하면 배포 대상이 무상태인지부터 확인하고 같은 구조를 새로 추가하지도 말라고 기록에 남겼다.