스모크·산티티 테스트로 설계하는 프로덕션 릴리즈 게이트

배포 직후의 실패를 게이트에서 차단한다

프로덕션 배포 직후 치명적 결함을 조기에 찾고, 롤백이나 완화를 자동화하려면 경량 검증 체계가 필요하다. Release/Production Verification은 변경 실패율을 낮추고 MTTR을 줄이며, DORA 지표 관점의 운영 품질을 높이기 위한 릴리즈 게이트다.

스모크 테스트는 배포 직후 서비스가 최소한 살아 있는지 확인한다. 의존성 연결, 인증과 권한, 핵심 API의 200 응답, 성능 임계치 충족 여부가 주요 대상이며, 실패하면 즉시 롤백 또는 트래픽 차단을 실행한다.

산티티 테스트는 스모크를 통과한 변경에 대해 얕고 빠르게 품질을 확인한다. 회귀 범위는 좁게 잡고 변경 사항과 인접한 기능을 중심으로 검증한다. 이 단계가 실패하면 카나리 확장을 멈추거나 프로모션을 보류한다.

둘은 역할이 다르다. 스모크는 시스템 생존성 게이트이고, 산티티는 기능 적합성 게이트다. 스테이징과 프로덕션 모두에 둘 수 있지만, 프로덕션에서는 트래픽과 데이터에 미치는 영향을 최소화해야 한다.

검증 범위와 데이터는 작게, 위험은 우선순위로 둔다

테스트 케이스는 사용자 가치가 높은 경로와 안전성, 결제, 인증처럼 위험도가 높은 영역부터 잡는다. 전체 검증은 1~5분 안에 끝나는 것을 목표로 한다.

프로덕션 검증에는 합성 계정이나 샘플 테넌트를 사용하고, 읽기 우선(Read-Only) 검증을 먼저 둔다. 쓰기 테스트가 필요하면 격리 테이블 또는 임시 리소스를 사용하고 자동 정리까지 포함한다.

배포 전략과의 연결도 게이트 설계에 포함된다. 카나리 배포는 1~5%에서 시작해 단계적으로 확대한 뒤 전면 전환한다. 블루그린 방식에서는 그린 활성화 전에 스모크를 수행하고, 활성화 뒤에 산티티를 수행한다. 기능 플래그는 신규 코드 경로의 노출을 제어하며, 실패 시 플래그 오프로 빠르게 완화할 수 있다.

관측성 신호로 승격 여부를 결정한다

게이트는 오류율, p95 지연, 실패 비율, 스로틀링, 포드 재시작 횟수 같은 SLI/SLO 기반 신호를 사용한다. 관찰 윈도우는 5~15분을 권장한다.

Kayenta 등의 카나리 자동분석을 사용하면 통계적 유의 탐지를 게이트에 연결할 수 있다. 기준을 통과하지 못하면 자동 롤백과 경보 발행으로 이어진다.

CI/CD에는 Deploy→Smoke→Sanity→Promote 순서로 스테이지형 게이트를 삽입한다. OPA, GitOps 같은 정책 코드로 승인지표를 검증하고, 변경관리에서는 이중 승인(two-person rule), 변경 창(Change Window), 자동화된 변경 기록을 연계한다.

DB 변경은 확장 가능한 변경(Expand)→코드 전환→축소(Cleanup) 순서로 단계화한다. 잠금 시간을 줄이고 롤백 경로를 확보하며, 이중 쓰기와 백필(backfill), 읽기 경로의 하위 호환성으로 가용성과 일관성을 유지한다.

릴리즈 검증의 흐름

⤢✕

스모크와 산티티가 보는 신호

항목	스모크 테스트	산티티 테스트
성능(실행 시간)	수십 초~1분 내 완료 목표	1~5분 내 완료 목표
확장성(병렬/샤딩)	단일/소수 케이스, 병렬성 낮음	기능별 그룹 병렬화 가능
일관성(데이터 영향)	읽기/경량 쓰기, 영향 최소	제한적 쓰기 허용, 자동 정리 필수
안정성(실패 탐지 민감도)	가용성·핵심 의존성 실패에 민감	기능 회귀·호환성 실패 탐지에 강점
운영 편의	단순 지표로 자동화 용이	변경 문맥 반영 필요, 유지보수 비용 존재

카나리·호환성·파이프라인에서의 검증

마이크로서비스 카나리에서는 5% 트래픽에 스모크를 수행하고, 오류율이나 지연이 상승하면 즉시 롤백한다. Kayenta 기반 자동분석 점수가 임계치인 예: 75에 미달하면 승격을 차단한다. 산티티는 변경된 서비스와 인접 도메인 API를 대상으로 구성하고, 트레이싱을 통해 교차 서비스 오류 전파 여부를 확인한다.

모바일 백엔드에서는 구버전 앱 클라이언트와의 프로토콜 호환성을 산티티 케이스로 유지한다. 헤더와 스키마가 진화할 때 다운네고시에이션을 점검하고, 신규 엔드포인트는 기능 플래그로 점진 노출한다. 실패하면 즉시 플래그를 꺼 사용자 영향을 막는다.

데이터 파이프라인 릴리즈의 스모크는 입력 소스 접근성, 스키마 버전 일치, 샘플 배치 실행 성공 여부를 확인한다. 산티티에서는 집계 결과의 행수와 분포를 간단히 검정한다. 문제가 발견되면 잡을 중지하고 오염 데이터를 롤백하거나 격리한다.

변경 실패율(CFR)은 20~~50% 상대적으로 감소할 수 있으며, 자동 게이트가 초기 결함을 막는다. 롤백과 플래그 오프를 자동화하면 MTTR은 30~~60% 단축을 기대할 수 있다. 서비스 신뢰도를 높이고 야간 장애를 줄이면서 릴리즈 빈도를 유지하거나 늘릴 수 있다.

GitHub Actions로 연결한 게이트

전제조건: GitHub Actions, kubectl ≥1.26, Kayenta 또는 등가 자동분석 API, Prometheus 지표 노출, 기능 플래그 서비스 연동 전제.

name: prod-release
on:
  workflow_dispatch:
jobs:
  deploy-canary:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy 5% canary
        run: kubectl apply -f k8s/canary-5.yaml
  smoke:
    needs: deploy-canary
    runs-on: ubuntu-latest
    steps:
      - name: Smoke checks
        run: |
          curl -fsS https://api.example.com/healthz
          curl -fsS -H "Authorization: Bearer $TOKEN" https://api.example.com/v1/ping
  gate-1:
    needs: smoke
    runs-on: ubuntu-latest
    steps:
      - name: SLI gate
        run: python scripts/check_sli.py --window 5m --latency-p95 300 --error-rate 0.5
  sanity:
    needs: gate-1
    runs-on: ubuntu-latest
    steps:
      - name: Sanity tests
        run: pytest -m "sanity and not destructive" -q
  canary-analysis:
    needs: sanity
    runs-on: ubuntu-latest
    steps:
      - name: Canary score
        run: python scripts/kayenta_score.py --threshold 75
  promote:
    needs: canary-analysis
    runs-on: ubuntu-latest
    steps:
      - name: Rollout 100%
        run: kubectl apply -f k8s/stable.yaml
      - name: Feature flag on
        run: python scripts/flags.py --set new_feature=true
  rollback:
    if: failure()
    runs-on: ubuntu-latest
    steps:
      - name: Rollback and flag off
        run: |
          kubectl rollout undo deployment/my-svc
          python scripts/flags.py --set new_feature=false

읽기 중심의 스모크를 우선하고, SLO 기반으로 게이트를 수치화하며, 자동 롤백과 플래그 오프를 함께 둔다. 합성 트랜잭션에는 아이덴포턴시를 보장한다.

산티티 범위를 넓히면 실행 시간이 늘어 릴리즈가 지연될 수 있다. 카나리 윈도우를 줄이면 탐지 민감도가 낮아질 위험이 있고, 지표가 과민하게 반응하면 불필요한 롤백이 증가할 수 있다.