staging은 언제부터 prod의 사촌이 됐나
env 동기화 부채가 쌓이는 패턴과 한 가지 대응.
어느 날 staging이 낯설어졌다
배포 전 staging에서 돌렸는데 prod에서 터진다. 원인을 파고 들면 보통은 코드가 아니다.
- staging DB는 3개월 전 스냅샷
- 환경변수 키 이름이 prod랑 미묘하게 다름 (
PAYMENT_KEYvsPAYMENT_API_KEY) - prod에만 붙어 있는 사이드카 컨테이너
- staging엔 아직 옛날 버전 Redis
하나씩 보면 “아 이건 그때 임시로”다. 막상 쌓이면 staging은 prod의 복사본이 아니라 6개월 전 prod의 화석이 된다.
부채가 쌓이는 속도
팀이 빠르게 움직일수록 역설적으로 staging은 더 빨리 drift한다. prod에 핫픽스 하나 박을 때 staging 반영은 “나중에”가 된다. 인프라 변경은 더하다. ALB 리스너 규칙을 prod에 추가했는데 staging IaC는 건드리지 않는다. Terraform state가 갈라지기 시작하는 순간이다.
2026년 기준, 내가 겪은 팀들 패턴:
- 초기 3개월: staging ≈ prod. 거의 동일.
- 6개월: 환경변수 5~10개 차이. 체감은 없음.
- 1년: staging 배포 성공이 prod 배포 성공을 보장 못함. 팀이 알게 됨.
- 1.5년: staging 배포를 안 믿어서 아무도 진지하게 테스트 안 함.
마지막 단계가 가장 위험하다. 도구를 안 믿으면 쓰지 않게 되고, 쓰지 않으면 더 멀어진다.
동기화를 “일”로 만드는 법
회고나 다음 분기 계획에 넣으면 안 된다. 거기 들어간 항목은 보통 실행 안 된다.
실제로 효과 있었던 것들:
- IaC 모듈 공유: prod와 staging이 같은 Terraform 모듈을 쓰고, 값만 다른 tfvars로 분기. 모듈이 바뀌면 둘 다 바뀐다.
- 환경변수 키 목록 체크: CI에서 prod
.env.keys와 staging.env.keysdiff를 뽑아 PR에 코멘트. 값이 아니라 키 목록만. 보안 문제 없음. - 스냅샷 주기 명시: staging DB는 매주 월요일 prod 스냅샷 복원. 달력에 자동화. “언젠가 하기”는 안 됨.
세 개 다 공통점이 있다. 사람이 기억하지 않아도 된다.
다음 한 가지
CI에 env 키 diff 체크 하나만 추가한다. 값 말고 키 목록. 거기서 보이는 것만 정리해도 drift 속도가 눈에 들어온다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.