소규모 팀 배포 절차: 브랜치·복구 조건·장애 회고
배포 대상 식별부터 중단 조건과 사후 기록까지 하나의 변경 단위로 관리합니다.
배포 체크리스트는 항목 수보다 문제가 생겼을 때 멈추고 복구할 수 있는지가 중요합니다. 소규모 팀도 변경 대상, 검증 결과, 중단 조건을 한 기록으로 연결하면 담당자의 기억에 덜 의존할 수 있습니다.
배포할 변경 식별하기
브랜치 이름만 적지 말고 커밋과 배포 산출물을 식별합니다. 같은 브랜치에 새 커밋이 추가될 수 있기 때문입니다. 의존성, 설정, DB 변경이 포함됐는지 따로 표시합니다.
짧은 브랜치와 작은 변경은 검토를 쉽게 할 수 있지만 팀의 릴리스 방식에 맞아야 합니다. 여러 버전을 유지하는 팀은 지원 브랜치와 수정 반영 규칙이 필요합니다. 브랜치 이름 규칙보다 보호 규칙과 누가 병합할지 명확히 하는 것이 우선입니다.
배포 기록 예제
| 항목 | 기록할 내용 |
|---|---|
| 대상 | 커밋, 이미지 식별자, 환경 |
| 검증 | 핵심 테스트와 실제 실행 결과 |
| 데이터 변경 | 호환 가능한지, 복구 방법 |
| 관찰 | 오류율·지연·핵심 사용자 경로 |
| 중단 | 사전에 합의한 악화 조건 |
| 복구 | 이전 산출물과 데이터 처리 방법 |
실제 숫자 기준은 서비스의 평상시 지표와 SLO를 바탕으로 정합니다. 다른 서비스의 임계값을 그대로 복사하지 않습니다.
Django 배포라면 추가로
운영에서 DEBUG를 끄고 허용 호스트, 비밀키, HTTPS 처리, 정적 파일 제공을 확인합니다. 다음 명령은 설정 점검이며 실제 배포 성공을 보장하는 테스트는 아닙니다.
python manage.py check --deploy
경고를 무조건 없애기 위해 이해하지 못한 보안 설정을 켜지 않습니다. 예를 들어 프록시에서 HTTPS를 종료한다면 신뢰할 수 있는 프록시가 헤더를 설정하는지 확인해야 합니다. 애플리케이션 서버와 프록시의 책임을 문서화합니다.
실패 후 회고에 남길 것
누가 실수했는지보다 어떤 정보와 보호 장치가 부족했는지 시간순으로 정리합니다. 탐지 시각, 사용자 영향, 조치, 복구 확인을 분리합니다. 조치는 담당자와 완료 조건을 갖추고 ‘주의하기’로 끝내지 않습니다.
DB 변경이 포함되면 앱만 되돌리는 것으로 복구되지 않을 수 있습니다. 스키마 변경 절차와 백업 복구를 배포 전에 확인합니다.