품질 게이트

품질 게이트(Quality gate)는 변경 사항이 다음 단계, 즉 머지, 스테이징 배포, 운영 릴리스로 넘어가기 전에 충족해야 하는 조건의 집합입니다. 각 조건은 측정 가능하고 자동으로 검사되며, 하나라도 실패하면 파이프라인이 멈춥니다. 게이트는 “누군가 보기에 괜찮은 것 같다”는 판단을 명시적이고 합의된 기준으로 대체합니다.

일반적인 게이트 조건

• 차단(blocking) 대상 테스트가 모두 통과합니다(단위 테스트, API 테스트, E2E 테스트 중 스모크 부분 집합).
• 새 코드의 라인 커버리지나 브랜치 커버리지가 합의된 수치 아래로 떨어지지 않습니다.
• 정적 분석이나 의존성 스캔에서 새로운 치명(critical) 또는 높음(high) 등급 결과가 없습니다.
• 성능 임계값을 지킵니다. 예를 들어 짧은 부하 테스트에서 p95 지연 시간이 500 ms 미만입니다.
• 빌드가 재현 가능하고 산출물(artifact)에 서명이나 버전이 붙어 있습니다.

예시

Jest의 커버리지 게이트입니다. 커버리지가 이 수치 아래로 떨어지면 jest --coverage가 0이 아닌 코드로 종료되고 CI 잡이 실패합니다.

// jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 80,
      lines: 85,
    },
  },
};

이것만으로는 잡 하나를 실패시킬 뿐입니다. 이 잡을 브랜치 보호 규칙의 필수 상태 검사(required status check)로 지정해, 통과할 때까지 머지 버튼이 비활성화되도록 해야 비로소 게이트가 됩니다. SonarQube 같은 도구는 여러 조건을 이름 붙은 게이트 하나로 묶어 단일 합격/불합격 결과를 냅니다.

왜 중요한가

게이트는 “준비 완료”의 정의를 눈에 보이게, 그리고 일관되게 만듭니다. 또한 논쟁을 적절한 시점으로 옮겨 줍니다. 팀은 릴리스할 때마다 다투는 대신, 임계값을 정할 때 한 번만 논의하면 됩니다.

흔한 실수

• 조작할 수 있는 수치로 게이트를 거는 것. 커버리지 90%를 강제하는 규칙은 아무것도 검증하지 않고 코드만 실행하는 테스트를 부추깁니다. 새 코드의 커버리지에 게이트를 걸고, 테스트 자체를 리뷰하십시오.
• 게이트 안의 불안정한(flaky) 검사. 무작위로 실패하는 게이트는 결국 우회됩니다. 결정적인 검사만 차단 대상으로 두고, 나머지는 알림과 함께 비차단으로 실행하십시오.
• 너무 많은 게이트를 너무 늦게. 릴리스 직전에만 조건 열 개를 검사하면 아무도 고칠 시간이 없는 실패 더미가 쌓입니다. 비용이 적은 검사는 앞쪽, 모든 풀 리퀘스트에 배치하십시오.
• 조용한 우회. 게이트를 건너뛸 수 있다면 누가 왜 건너뛰었는지 기록하십시오.