BABY DAY를 운영하면서 가장 크게 바뀐 규칙 중 하나는 코드를 고쳤다고 바로 운영에 배포하지 않는 것이었다.
개발 중에는 작은 수정이 빠르게 반복된다. UI 간격 하나, 기록 카드의 정렬 하나, 알림 문구 하나처럼 눈에 보이는 변경은 곧바로 반영하고 싶어진다. 하지만 실제 사용자가 기록을 쌓는 서비스에서는 배포 자체가 하나의 작업이었다.
실제 배포에서 .env 누락으로 먼저 막혔다
9월 26일 운영 반영을 준비할 때 첫 시도는 애플리케이션 코드가 아니라 운영 환경값 누락 때문에 BLOCKED가 됐다. 로컬 소스와 빌드만 보고 있었다면 “코드는 정상인데 왜 배포가 안 되지?”라는 상태가 길어질 수 있었다.
필요한 환경값을 다시 확인한 뒤에는 다음 순서로 재검증했다.
- 운영 환경 설정 확인
- 데이터베이스와 백업 상태 확인
- 빌드·배포 절차 통과 확인
/api/health응답이 200인지 확인- 실제 사용자가 보는 핵심 화면 확인
이 과정을 모두 통과한 뒤에야 PASS로 판단했다. 이 경험 때문에 배포 체크리스트에서 환경값과 데이터 확인을 코드 테스트보다 앞쪽에 두게 됐다.
빌드가 된다고 배포 가능한 것은 아니었다
소스만 보면 정상이고 로컬에서도 문제가 없더라도, 운영에서 필요한 환경값이 갖춰지지 않으면 배포는 성공으로 볼 수 없다.
그 뒤 배포 전 확인 순서를 따로 두기 시작했다.
- 운영 환경 설정이 준비됐는지
- 데이터베이스와 백업 상태가 정상인지
- 빌드와 기본 테스트가 통과하는지
- 배포 후
/api/health같은 최소 헬스체크가 정상인지 - 실제 사용자가 보는 핵심 화면이 열리는지
이 과정을 통과해야 비로소 운영 반영 후보가 된다.
로컬 확인과 운영 반영을 분리했다
AI나 자동화가 수정한 뒤에는 먼저 로컬에서 확인한다. 화면이 의도대로 보이는지, 기존 기능이 깨지지 않았는지, 브라우저가 정말 최신 소스를 보고 있는지를 확인한다.
여기까지 끝나도 자동으로 운영에 올리지는 않는다.
운영 배포는 별도의 승인 단계로 남겨뒀다. 작은 수정 여러 개가 동시에 쌓일 때 어떤 변경까지 운영에 포함되는지 사람이 마지막으로 알아야 하기 때문이다. 현재 BABY DAY에서는 운영 반영은 명시적으로 지시한 경우에만 실행하는 것을 기본 규칙으로 두고 있다.
배포 체크리스트가 작업 기억을 대신한다
배포할 때마다 같은 질문을 머릿속으로 반복하면 빠뜨리는 항목이 생긴다.
그래서 환경, 데이터, 빌드, 헬스체크, 주요 화면 확인을 체크리스트로 남겼다. 자동화가 할 수 있는 것은 자동으로 검사하고, 제품 판단이 필요한 부분만 사람이 본다.
이렇게 하니 배포 속도가 느려진 것이 아니라 오히려 되돌아가는 시간이 줄었다.
BABY DAY에서 운영 배포는 이제 “코드 push의 다음 단계”가 아니다.
사용자 데이터가 있는 환경에 변경을 허용하는 별도의 승인 작업으로 다룬다.
이 기준이 실제 데이터 복구에서 왜 중요했는지는 수유 기록 시간이 한꺼번에 이상해졌을 때 데이터 복구를 먼저 한 이유에 정리했다.