품질 게이트 설계하기: 무엇이 배포를 막아야 하는가

개념

품질 게이트(Quality Gate)란

레슨 1에서 "파이프라인이 실패하면 병합·배포가 차단된다"고 배웠다. 품질 게이트는 이 차단의 구체적인 기준을 정의한 것이다 — 모듈 8(레슨 4)에서 배운 종료 기준(Exit Criteria)이, CI/CD 파이프라인 안에서 자동으로 강제되는 형태로 나타난 것이다.

종료 기준(모듈 8): "심각도 높음 결함 0건, 커버리지 90% 이상이어야 릴리스 가능"
품질 게이트: 이 기준을 파이프라인이 자동으로 확인하고, 미달이면 배포를 막는다

게이트로 쓸 수 있는 기준들

테스트 통과 여부 — 단위·통합·API·UI 테스트(모듈 10, 12, 13)가 전부 통과했는가
커버리지 임계값 — 모듈 10(레슨 5)에서 배운 커버리지가 최소 기준(예: 80%) 이상인가
정적 분석(Lint) — 코드 스타일이나 명백한 버그 패턴을 자동으로 검사하는 도구를 통과했는가
보안 취약점 스캔 — 알려진 취약점이 있는 라이브러리를 쓰고 있지 않은가
성능 기준 — 응답 시간이 기준치를 넘지 않는가(모듈 16과 연결)

모든 걸 게이트로 만들면 안 된다

레슨 1에서 배운 병목 문제를 여기서도 조심해야 한다. 모든 검사를 "통과해야만 배포 가능"으로 설정하면, 파이프라인이 자주 막혀 개발 속도가 크게 느려진다. 그래서 게이트를 설계할 때는 다음을 구분해야 한다.

차단(Blocking) — 반드시 통과해야 배포 가능
  예: 핵심 흐름의 회귀 테스트 실패, 심각도 높음 보안 취약점
 
경고(Warning) — 통과 안 해도 배포는 되지만 알림을 준다
  예: 커버리지가 목표보다 살짝 낮음, 사소한 코드 스타일 위반

이 구분은 모듈 6(레슨 1)에서 배운 심각도 판단과 정확히 같은 논리다 — 모든 문제를 같은 무게로 다루면 안 된다.

게이트가 너무 느슨하면 생기는 문제

반대로 게이트를 너무 느슨하게 설정하면, 실제로 문제가 있는 코드도 배포를 막지 못한다. "테스트가 몇 개 실패해도 그냥 넘어가는 게 관행이 됐다"는 상황은, 모듈 11(레슨 4)에서 배운 자동화 부채가 조직 차원에서 굳어진 상태다 — 게이트가 있으나 마나 한 장식이 되어버린다.

게이트 설계는 트레이드오프의 연속이다

너무 엄격함: 개발 속도 저하, 사소한 문제로도 팀 전체가 발이 묶임
너무 느슨함: 결함이 그대로 배포됨, 게이트의 의미가 사라짐

정답은 하나로 고정되지 않는다. 모듈 11(레슨 2)에서 배운 리스크 기준(반복성·안정성·회귀 가치)을 게이트 설계에도 적용해서, 리스크가 큰 영역은 엄격하게, 리스크가 작은 영역은 유연하게 가져가는 것이 현실적이다.

실무에서 왜 필요한가

"이 PR, 테스트 몇 개 실패했는데 그냥 머지해도 되나요?"라는 질문에 답할 기준이 명확한 팀과, 매번 사람이 즉흥적으로 판단하는 팀은 품질 일관성이 크게 다르다. QA가 품질 게이트 설계에 관여하면, 모듈 8(레슨 3)에서 배운 조직 테스트 전략을, CI/CD라는 구체적인 자동 강제 장치로 실현할 수 있다.

실습 과제

과제 1 — 차단 vs 경고 분류하기 (15분)

다음 다섯 가지 검사 결과를 차단(Blocking)과 경고(Warning) 중 어디에 배정할지 판단하고 이유를 적는다.

결제 흐름 E2E 테스트 실패
코드 스타일(들여쓰기) 위반 3건
알려진 심각한 보안 취약점이 있는 라이브러리 사용
커버리지가 목표(80%)보다 2%p 낮음
로그인 API 응답 시간이 평소보다 500ms 느려짐

과제 2 — 게이트 완화 요청 대응하기 (10분)

"이번 릴리스가 급해서 품질 게이트를 이번만 건너뛰고 배포하고 싶다"는 요청을 받았다고 하자. 이 요청을 받아들이기 전에 QA로서 확인해야 할 질문 2가지를 적는다.

자가 체크리스트

품질 게이트가 모듈 8의 종료 기준과 어떻게 연결되는지 설명할 수 있다
게이트로 쓸 수 있는 기준들을 나열할 수 있다
차단(Blocking)과 경고(Warning)를 구분하는 기준을 설명할 수 있다
게이트가 너무 엄격하거나 너무 느슨할 때 각각 생기는 문제를 설명할 수 있다

흔한 실수

모든 검사를 예외 없이 차단으로 설정한다. 사소한 문제로도 팀 전체 배포가 막혀 오히려 게이트를 우회하려는 시도가 늘어난다.
게이트를 한 번 정하고 다시 검토하지 않는다. 리스크 수준은 프로젝트가 진행되며 바뀌므로, 주기적으로 게이트 기준을 재검토해야 한다.
"급하니까 이번만"이라는 예외를 습관적으로 허용한다. 예외가 반복되면 게이트의 실질적 효력이 사라진다.

참고 자료

SonarQube — Quality Gates 공식 문서 — 품질 게이트 설계의 실무적 참고 자료
ISTQB — Exit Criteria 관련 개념(모듈 8 레슨 4와 동일한 원리)의 공식 정의