2026년 팀 생산성 격차를 만드는 지점은 코드 작성 속도보다 메인 브랜치 신뢰도입니다. 개발자 개인 속도가 아무리 빨라도, 머지 직전 충돌과 불안정한 테스트 때문에 배포가 밀리면 조직 전체 리드타임은 느려집니다. 특히 PR 수가 늘어날수록 “내 PR은 통과했는데 main에서는 실패” 패턴이 반복되고, 결국 핫픽스와 재실행 비용이 눈덩이처럼 쌓입니다.

그래서 요즘 릴리스 엔지니어링에서 많이 보이는 조합이 Merge Queue + Flaky Test Quarantine입니다. 핵심은 단순합니다. 머지를 선착순으로 처리하지 않고, 큐에서 재검증된 변경만 main에 반영합니다. 동시에 흔들리는 테스트는 품질을 포기하는 대신, 격리하고 추적 가능한 부채로 관리합니다.

이 글에서 얻는 것

  • Merge Queue가 단순 편의 기능이 아니라, trunk 안정성을 지키는 운영 메커니즘이라는 점을 이해할 수 있습니다.
  • Flaky Test를 “개발자 탓”으로 두지 않고, 격리·예산·복구 SLA로 관리하는 실무 기준을 적용할 수 있습니다.
  • 배포 속도와 품질 사이에서 무엇을 우선하고 어떤 지표로 판단할지 **의사결정 기준(숫자·조건·우선순위)**을 가져갈 수 있습니다.

핵심 개념/이슈

1) Merge Queue의 본질은 충돌 해결이 아니라 “검증 순서 제어”다

기존 방식은 각 PR이 개별적으로 테스트를 통과하면 머지됩니다. 문제는 머지 시점마다 베이스(main)가 달라지기 때문에, PR 단위 성공이 브랜치 단위 성공을 보장하지 않는다는 점입니다.

Merge Queue는 이 순서를 제어합니다.

  1. PR을 큐에 넣고
  2. 큐 순서대로 최신 main 기준 재검증하고
  3. 통과한 변경만 머지합니다.

즉 “리뷰 통과”와 “메인 반영 가능”을 분리해 처리합니다. 이 접근은 PR 리스크 스코어링/테스트 영향 분석과 결합될 때 더 강해집니다.

2) Flaky Test를 방치하면 CI는 신뢰 시스템이 아니라 확률 게임이 된다

플래키 테스트는 코드 변경이 없어도 성공/실패가 바뀌는 테스트입니다. 비율이 2~3%만 넘어도 팀 체감은 급격히 나빠집니다.

  • 재실행 횟수 증가
  • 원인 분석 시간 증가
  • “CI 실패 = 무시 가능” 문화 확산

그래서 선진 팀은 flaky를 “기술적 부채”가 아니라 운영 부채로 다룹니다.

  • flaky 판정 기준: 최근 20회 중 2회 이상 비결정적 실패
  • quarantine 대상: 원인 미확정 flaky 테스트
  • 복구 SLA: 핵심 경로 48시간, 비핵심 7일

테스트 운영 기본은 테스트 전략 심화와 CI/CD 파이프라인 운영을 함께 보면 설계가 수월합니다.

3) 최근 트렌드는 “통과율”보다 “신뢰 가능한 통과율”

과거에는 CI pass rate만 보고 상태를 판단했습니다. 하지만 pass rate 95%라도 flaky가 많으면 실제 신뢰도는 낮습니다. 그래서 다음 지표가 같이 등장합니다.

  • deterministic_pass_rate (재실행 없는 1회 통과율)
  • queue_wait_p95 (머지 대기 시간)
  • retest_count_per_pr
  • quarantine_backlog

즉 숫자 해석도 바뀝니다. “통과했다”가 아니라 “재현 가능하게 통과했다”를 봅니다.

4) Merge Queue와 Quarantine을 함께 써야 하는 이유

Merge Queue만 도입하면 flaky가 많은 조직에서는 큐 병목이 심해집니다. 반대로 quarantine만 하면 main 안정성은 일시적으로 좋아져도, 병합 타이밍 충돌 문제는 남습니다.

둘을 함께 운영하면 효과가 분리됩니다.

  • Merge Queue: 브랜치 일관성 문제 해결
  • Quarantine: 테스트 신뢰도 문제 해결

이 구조는 플랫폼 엔지니어링 Golden Path처럼 팀 공통 규칙으로 굳혀야 지속됩니다.

실무 적용

1) 의사결정 기준(숫자·조건·우선순위)

우선순위는 main 안정성 > 복구 가능한 개발 편의 > 개별 PR 속도 순서로 두는 것이 현실적입니다.

권장 초기 기준:

  • Merge Queue 강제 대상: main 직접 머지 금지, 큐 경유 100%
  • 큐 대기 목표: queue_wait_p95 <= 30분
  • flaky 임계치: 테스트 단위 flaky rate >= 5%면 quarantine 후보
  • quarantine 상한: 전체 테스트의 8% 초과 금지(초과 시 기능 배포보다 테스트 복구 우선)
  • 긴급 예외: P0 장애 핫픽스만 2인 승인으로 큐 우회

2) 3주 전환 플랜

1주차: 측정과 가시화

  • 최근 4주 PR 기준 재실행 횟수, flaky 후보, 큐 대기 추정치 산출
  • 서비스/모듈별 실패 상위 테스트 목록 공개

2주차: Merge Queue 단계 도입

  • 고위험 레포부터 큐 강제
  • 병렬 실행 가능한 테스트는 shard 확장
  • 큐 대기 30분 초과 시 리스크 기반 우선순위 적용

3주차: Flaky Quarantine 운영화

  • quarantine 라벨/대시보드/담당자 지정
  • 복구 SLA와 만료 정책(예: 14일) 설정
  • 만료 초과 flaky가 많은 팀은 신규 테스트 추가보다 복구 우선

3) 운영 규칙 예시

  • flaky 테스트는 삭제하지 않고 격리 + 원인 티켓 필수
  • quarantine 상태에서도 주 1회는 복구 검증 실행
  • PR 템플릿에 “테스트 영향 범위” 체크 항목 추가
  • 큐 우회는 P0 장애와 보안 패치만 허용

계약 테스트가 많은 조직이라면 Consumer-Driven Contract Testing과 연계해, flaky 발생 위치(단위/통합/계약)를 분리 추적하는 것이 좋습니다.

트레이드오프/주의점

  1. 초기에는 체감 속도가 느려질 수 있다
    큐를 도입하면 “즉시 머지” 문화가 줄어듭니다. 대신 롤백/재배포/핫픽스 비용이 같이 줄어드는지 함께 봐야 합니다.

  2. quarantine 남용은 품질 부채 은닉으로 이어진다
    격리는 임시 조치여야 합니다. 만료일 없는 quarantine은 사실상 테스트 폐기와 같습니다.

  3. 지표를 잘못 잡으면 팀이 숫자 게임을 한다
    pass rate만 압박하면 재실행 남발로 지표를 꾸밀 수 있습니다. deterministic 지표를 같이 봐야 합니다.

  4. 모든 레포에 동일 강도를 강제하면 역효과가 난다
    릴리스 빈도와 위험도가 다른데 정책이 같으면 반발이 커집니다. 핵심 제품군부터 적용하고 점진 확대가 안전합니다.

체크리스트 또는 연습

체크리스트

  • main 브랜치 머지가 Merge Queue 경유로 표준화되어 있다.
  • flaky 판정 기준(횟수/기간)이 숫자로 정의되어 있다.
  • quarantine 테스트는 담당자·복구 SLA·만료일이 있다.
  • queue_wait_p95, deterministic_pass_rate를 주간 리뷰한다.
  • 큐 우회 정책이 문서화되어 있고 실제로 제한적으로만 사용된다.

연습 과제

  1. 최근 2주 PR 50건을 기준으로 재실행 횟수, 머지까지 리드타임, main 실패율을 계산해 Merge Queue 도입 전/후 가설을 세워보세요.
  2. flaky 상위 10개 테스트를 뽑아 “환경 의존/시간 의존/경합 의존”으로 분류하고, 복구 우선순위를 정해보세요.
  3. 팀별 quarantine 비율과 만료 초과 건수를 지표화해, 다음 스프린트 목표(예: 8%→5%)를 설정해보세요.

관련 글