길리랩blog

DEV·STG·PROD 분리로 릴리스 신뢰성 확보하기

DEV·STG·PROD 환경 분리 원칙과 아티팩트 프로모션, 데이터 마스킹, 접근 제어, 릴리스 게이트를 통해 재현 가능한 검증과 안정적인 배포 체계를 설계하는 방법

2026-08-14 · 최초 발행 2025-12-23

환경을 나누는 일은 릴리스의 검증 대상을 고정하는 일이다

소프트웨어 품질과 배포 안정성은 환경을 어떻게 분리하느냐에 크게 좌우된다. DEV·STG·PROD를 구분하면 변경 영향 범위를 통제할 수 있고, 반복 가능한 테스트와 안전한 배포의 기반도 마련된다. CI/CD의 도입 수준과 별개로 환경별 기준선, 데이터 정책, 접근 제어, 프로모션 절차는 갖춰야 한다.

DEV는 빠른 피드백과 실험을 위한 환경이다. 불안정을 허용하고 자원을 제한하며, 외부 통신에는 모의 또는 샌드박스를 적용한다.

STG는 운영과 가까운 기준선과 데이터 특성을 재현해 검증하는 환경이다. 카나리, 블루그린, 드라이런 절차도 이곳에서 확인한다.

PROD는 고객 트래픽을 처리하는 본 환경이다. 변경은 최소화하고 가드레일은 강화하며, 자동 롤백과 관측을 중심으로 운영한다.

환경을 가로지르는 핵심 원칙은 프로모션이다. 이미지나 패키지처럼 동일한 아티팩트를 DEV에서 STG, 다시 PROD로 승격하고 환경별 설정만 달리한다. 브랜치별 재빌드나 체리픽은 지양하며 아티팩트 불변성을 지킨다.

STG와 PROD는 아키텍처·구성·버전을 동형으로 유지하는 환경 패리티가 필요하다. 비용과 위험의 균형을 고려하되, 환경 간 차이는 환경 변수, 시크릿, 리소스 할당, 통합 엔드포인트로 제한한다.

상위 환경으로 올리기 전에 통제할 항목

단일 소스 아티팩트는 단계적으로 승격한다. 상위 환경 배포는 테스트 합격, 품질 지표, 승인으로 구성된 게이트를 통과한 경우에만 허용한다. 이렇게 하면 재빌드 없이 배포 일관성을 유지할 수 있다.

애플리케이션 코드와 Config·Secret도 분리해야 한다. Kustomize, Helm, IaC를 이용해 선언적으로 관리하고, 시크릿은 KMS, HashiCorp Vault, Sealed Secrets 같은 전용 백엔드에서 버전과 권한을 관리한다.

데이터 정책은 환경마다 달라야 한다. STG에는 비식별·마스킹 데이터를 사용하고 데이터 동기 주기와 대표성을 확보한다. DEV에는 합성 데이터와 샘플 세트를 기본으로 적용하며 민감정보 반입을 금지한다.

네트워크와 권한 역시 독립적으로 통제한다. VPC·서브넷·네임스페이스·보안그룹·네트워크 폴리시로 동서 및 남북 트래픽을 제어하고, IAM/RBAC로 환경별 최소 권한 원칙을 적용한다. PROD 직접 셸 접근은 차단하고 점프호스트와 브레이크글래스 절차는 제한적으로 운영한다.

STG에서는 카나리, 셰도우 트래픽, 로드 테스트로 품질 가드레일을 실행한다. 에러율, 레이턴시, 자원 사용량, 비즈니스 KPI를 자동 승인 또는 차단과 연결한다.

프로모션과 롤백이 이어지는 배포 흐름

⤢✕CI 빌드/테스트 성공자동 배포테스트 통과 및 커버리지 ='80%'승인 '체크리스트/변경관리CAB'카나리 '10% 트래픽' + 데이터'마스킹'예락 전략 '온라인/롤링 검증'아니오개발자 커밋 'main'컨테이너 이미지 태그'app:dev-'DEV 배포(리소스 쿼터/모의의존성)프로모션 요청STG 배포(운영 유사 구성)관측 지표 'SLO 충족?'DB 마이그레이션 '프리/포스트'점검PROD 배포(오토 롤백 구성)자동 롤백 및 원인 분석'로그/트레이스'

코드·설정·시크릿이 입력되면 CI 빌드와 테스트, 정책과 게이트, 배포 자동화를 거쳐 상위 환경 승격과 변경 이력·감사 로그를 남긴다. 게이트에서 탈락하면 롤백, 알림, 이슈 등록으로 이어진다. 데이터 일관성을 위해서는 마이그레이션의 프리·포스트 단계를 나누고 락을 최소화하는 전략을 택한다.

환경별로 달라지는 운영 기준선

항목 DEV STG PROD
성능(목표) 최소 스펙, 기능 검증 중심 운영 대비 70~100% 부하 재현 SLO 중심, 피크 대응
확장성 오토스케일 제한 운영과 동일 정책(규모 축소 가능) 수평/수직 확장 완전 활성
데이터 일관성 합성/샘플 데이터 마스킹된 운영 근사 데이터 실운영 데이터
안정성 불안정 허용 배포/롤백 시나리오 검증 안정성 최우선, 배포 윈도우 제한
운영 편의 디버그/프로파일링 허용 제한적 허용, 추적 강화 제한적, 보안/감사 최우선

환경 분리를 적용하는 방식

마이크로서비스와 쿠버네티스에서는 Argo CD로 DEV·STG·PROD 애플리케이션 디렉토리를 분리하고, 동일 이미지 태그를 프로모션할 수 있다. STG에서는 생성 로그 리플레이 방식의 셰도우 트래픽 재생과 에러 버짓 기반 자동 게이트를 구성한다. PROD는 카나리에서 점진적 확장, 전체 전환으로 이어지며 실패하면 이전 리비전으로 자동 롤백한다.

데이터 플랫폼과 ETL에서는 DEV에 합성 스키마와 테스트 픽스처를 두고, STG에서 마스킹된 스냅샷 및 스키마 진화를 검증한다. 스키마 마이그레이션은 프리(논파괴), 애플리케이션 배포, 포스트(파괴) 순서로 분리한다.

모바일과 백엔드의 릴리스 링에서는 STG에서 A/B 플래그를 검증한 뒤 내부, 베타, 일반 운영 링으로 확장한다. 서버 기능 플래그 토글은 클라이언트 배포와 백엔드 변경 사이의 결합도를 낮춘다.

Kustomize로 환경별 설정을 분리하는 예시

전제조건은 kubectl 1.26+, kustomize 5.x, 이미지 레지스트리 접근 권한이다.

공통 Deployment와 Service는 base에 두고, overlays/dev|stg|prod에서 리소스 할당, 환경 변수, 시크릿 참조를 달리한다.

# base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: app
          image: registry.example.com/app:dev
          env:
            - name: APP_ENV
              value: base
# overlays/stg/kustomization.yaml
resources:
  - ../../base
nameSuffix: -stg
patches:
  - target:
      kind: Deployment
      name: app
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 2
      - op: replace
        path: /spec/template/spec/containers/0/image
        value: registry.example.com/app:${IMAGE_TAG}
      - op: add
        path: /spec/template/spec/containers/0/env/-
        value:
          name: APP_ENV
          value: stg

STG 배포 명령은 다음과 같다.

  • IMAGE_TAG=stg-1.2.3 kustomize build overlays/stg | kubectl apply -f -

자동 게이트를 도입하면 DEV에서 PROD까지의 평균 소요 시간을 20% 단축할 수 있다. 배포 실패율은 15%에서 5% 이하로 낮추고 롤백 시간은 50% 단축하는 것을 목표로 삼을 수 있다. STG 재현성 향상은 운영 장애 사전 검출률을 30% 이상 높이는 기반이 된다. 민감정보 노출 사고 0건과 접근 감사 100% 추적 가능성도 환경 분리 체계가 지향하는 기준이다.

환경 분리CI/CD릴리스 관리테스트 데이터관측성