운영 Compose 파일을 바꾼 뒤 Jenkins 배포가 설정 검사에서 멈췄습니다. 같은 파일을 root로 검사하니 통과했고, Jenkins 계정으로 실행하니 읽기 권한이 없었습니다. 파일은 root:root 소유에 모드가 0600이었습니다. 파일의 내용은 그대로 두고 Jenkins 그룹에 읽기 권한을 복구하자 같은 커밋의 재실행이 배포까지 성공했습니다. 이후 같은 문제가 다시 생겨 배포 네 건이 연속으로 실패했습니다.

Jenkins 계정으로 교체 전 검사

같은 파일시스템에서 새 파일을 준비한 뒤 이름을 바꾸면, 읽는 쪽에는 완성된 파일만 보입니다. 이때 새 경로의 권한은 옛 파일에서 이어지는 값이 아니라 교체해 넣는 파일이 가진 값입니다.

설치 도구는 자동 배포와 같은 잠금을 잡고, 대상 파일과 같은 디렉터리에 후보를 만들도록 했습니다. 먼저 운영 설정으로 후보를 검사한 뒤 root:jenkins와 0640을 적용하고, Jenkins 계정과 CI 설정으로 다시 검사했습니다. 두 검사를 통과한 경우에만 기존 파일을 백업하고 후보로 교체했습니다.

동일한 설정으로 운영 검증

격리 환경에서 0600 후보를 그대로 교체하면 root만 통과하는 실패를 재현했습니다. 새 도구에서는 YAML 오류, CI 필수 값 누락, 배포 잠금 사용 중인 경우에 기존 파일이 보존됐습니다. 운영에서는 내용이 같은 후보를 설치해 inode가 바뀌고 SHA-256은 같은 것을 확인했습니다. Jenkins 검사와 API readiness가 통과했고, 실행 중인 세 컨테이너의 ID도 일치했습니다. 최초 장애 때 실행된 교체 명령의 본문은 확인되지 않았습니다.

컨테이너까지 설정 전달 확인

별도로 녹음 저장소를 연결할 때는 저장소의 Compose 파일과 서버 설치본을 비교했습니다. 설치본에는 저장소 설정을 컨테이너 환경변수로 넘기는 줄 5개가 빠져 있었습니다. 이 상태에서는 .env에 값을 넣어도 백엔드가 받지 못했습니다.

설정을 반영한 뒤에는 실행 중인 컨테이너에서 변수 값 대신 길이만 확인했습니다. 앱 시작 로그에 저장소 설정이 없다는 경고가 나오지 않는 것도 확인했습니다. 이 확인은 설정이 컨테이너에 전달됐는지까지 보여 줍니다. 해당 키로 저장소 요청이 성공하는지는 별도의 확인이 필요합니다.