실수로 프로덕션에 바로 배포될 뻔한 걸 막아주는 Environment 설정

문제 발생

CI/CD 파이프라인이 main 브랜치에 push되면 자동으로 프로덕션까지 배포하도록 되어 있었는데, 실수로 검증 안 된 코드가 main에 바로 push되면서 곧장 프로덕션에 반영될 뻔한 상황이 있었습니다.

원인 분석

완전 자동화된 배포 파이프라인은 빠르다는 장점이 있지만, "사람이 마지막으로 한 번 확인한다"는 안전장치가 빠지면 어떤 실수든 여과 없이 프로덕션까지 도달합니다. 코드 리뷰나 CI 테스트를 통과했다고 해서 항상 안전한 것은 아닙니다 — 테스트로 못 잡는 종류의 실수(설정값, 배포 타이밍, 비즈니스 판단)도 있습니다.

해결 방안

GitHub의 Environment(저장소 Settings → Environments)에 보호 규칙을 설정하면, 특정 environment로의 배포에 조건을 걸 수 있습니다.

1. Required reviewers: 지정한 사람(또는 팀)이 승인해야만 해당 environment로의 job이 실제로 실행됩니다. 워크플로우가 이 job에 도달하면 실행이 일시 정지되고, 승인 대기 상태로 알림이 갑니다.

jobs:
  deploy-production:
    environment: production   # Settings에서 이 environment에 reviewer를 지정해둠
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

2. Deployment branches: 특정 environment는 지정한 브랜치(예: main)에서 시작된 워크플로우만 배포할 수 있도록 제한할 수 있습니다 — 임시 브랜치에서 실수로 프로덕션 배포 job이 실행되는 것을 막습니다.
3. Wait timer: 승인 없이도, 일정 시간(예: 10분)을 강제로 대기시켜 그 사이에 문제를 발견하면 워크플로우를 취소할 여유를 줄 수 있습니다.
4. Environment마다 별도의 secret을 등록할 수도 있어, staging과 production이 서로 다른 자격 증명을 쓰도록 격리하는 용도로도 함께 활용됩니다 — 보호 규칙과 자격 증명 분리를 같은 Environment 설정 화면에서 관리할 수 있습니다.
5. 이런 보호 장치는 배포 속도를 일부러 늦추는 트레이드오프입니다 — 프로덕션처럼 실수의 대가가 큰 environment에만 적용하고, staging/개발 environment는 계속 완전 자동으로 두는 식으로 균형을 맞추는 것이 일반적입니다.

공식 문서

• GitHub Docs: Managing environments for deployment