선별 테스트 실행 vs 전체 회귀, 대조 분석

선별 실행과 전체 회귀, 어느 쪽을 믿어야 하나?

둘 다 단독으로는 답이 아니다. PR 경로에서 테스트 영향 분석(TIA) 기반 선별 실행은 median feedback time을 최대 96%까지 줄이지만, 동시에 실패의 최대 55%를 놓칠 수 있다는 결과가 확인됐다. 그래서 2026년 기준 실무 가이드는 PR에서는 부분 실행, 메인·나이틀리에서는 전체 suite 실행을 정석으로 권한다.

• 선별 실행은 테스트 실행 시간을 최대 66%, batching은 최대 98%까지 줄이지만 성능 편차가 크다.
• PR=부분 실행, main/nightly=전체 실행 구조가 정석 패턴이다.
• 캐시 재사용은 결정론적·hermetic한 unit test 영역에서만 공격적으로 쓸 수 있다.
• 플래키 테스트가 많은 저장소에서는 선별 실행이 "오류를 가리는 기술"로 전락할 수 있다.
• 롤백 안전성은 선별 정확도만으로는 보장되지 않고, 전체 회귀의 주기와 캐시 키 엄격화가 함께 필요하다.

두 선택지를 나란히 놓으면 이렇다. 한쪽은 영향받는 테스트만 골라 빠르게 돌리는 선별 실행, 다른 쪽은 전부 다시 돌려 확실히 잡는 전체 회귀다. 이번 분석에서는 이 둘을 실측 수치로 뜯어봤다. 전자는 PR 단위의 속도와 비용을 다스리고, 후자는 메인 브랜치와 배포 직전의 안전망 역할을 한다. 문제는 이 둘을 양자택일로 놓는 순간 생긴다 — 선별 실행만 쓰면 누락이 쌓이고, 전체 회귀만 쓰면 PR 피드백이 느려져 개발자가 CI를 무시하기 시작한다.

속도 절감 폭은 실제로 얼마나 차이가 나나?

차이는 크지만 균일하지 않다. Queensu MCIS/EMSE 연구는 test selection이 median feedback time을 최대 96%까지 단축했다고 보고했고, 같은 연구에서 테스트 실행 시간 자체의 절감폭은 test selection에서 최대 66%, batching에서는 최대 98%까지 나타났다. 다만 이 수치는 상한선이며, 같은 논문은 batching의 경우 성능 편차가 크다고 명시한다. 즉 선별 실행을 도입한다고 모든 저장소가 90%대 절감을 기대할 수 있는 건 아니고, 의존성 그래프의 복잡도와 테스트 스위트 구조에 따라 편차가 크게 벌어진다. 이 지점에서 흔히 놓치는 부분은 속도와 커버리지가 같은 방향으로 움직이지 않는다는 것이다. 속도가 96% 개선되는 동안 실패 탐지율은 오히려 떨어질 수 있고, 그 폭은 최대 55%에 달한다. 그래서 선별 실행의 도입 효과를 말할 때는 절감폭만 제시하고 누락 리스크를 빼는 방식은 불완전한 보고다.

캐시 재사용은 어디까지 안전하다고 볼 수 있나?

안전 범위는 생각보다 좁다. 2026년 CI 캐시 전략 문서는 캐시 재사용이 결정론적이고 hermetic한 unit test처럼 모든 입력이 알려진 경우에 가장 신뢰할 수 있다고 설명한다. 캐시 키는 code, test, configuration, runtime, relevant external inputs를 모두 포함해야 하며, 이 중 하나라도 불확실하면 fail-closed로 더 넓게 실행하라는 것이 같은 문서의 권고다. 실무에서 자주 발생하는 실수는 캐시 키를 코드 변경 여부로만 좁혀 잡는 것이다. 이 경우 설정 파일이나 런타임 버전이 바뀌어도 캐시가 그대로 재사용되면서 과거에는 맞았던 결과가 지금도 맞는 결과인 것처럼 취급된다. 같은 문서는 이전 pass만 재사용하고 failure는 다시 실행하는 분리 전략도 제안하는데, 이유는 실패 쪽이 인프라 문제나 flake 진단에 훨씬 민감하기 때문이다. 결과적으로 테스트 결과 캐시는 단순한 속도 기능이 아니라 "이 결과가 여전히 유효하다"는 주장이므로, 범위를 좁게 잡고 보수적으로 운용해야 한다.

플래키 테스트는 선별 실행을 어떻게 왜곡하나?

플래키 테스트는 선별 실행과 캐시 재사용 양쪽을 동시에 갉아먹는다. pytest 공식 문서는 테스트 격리와 상태 관리에서 스레드·teardown·동기화 문제가 불안정성의 주요 원인이 될 수 있다고 지적한다(pytest 공식 문서). 2026년 플래키 테스트 가이드는 원인을 시간, 실행 순서, 공유 가변 상태, 환경, 외부 의존성 같은 "hidden variables"로 분류하고, rerun-only-failures 같은 재시도 방식은 제한적으로만 쓰라고 권한다. 문제는 선별 실행 시스템이 이런 플래키 신호를 영향받지 않은 테스트의 우연한 실패로 오분류하기 쉽다는 점이다. 의존성 맵이 해당 테스트를 특정 변경과 무관하다고 판단하면, 그 테스트가 실제로는 공유 상태 문제로 실패하고 있어도 선별 로직은 이를 걸러내지 않는다. Playwright의 auto-wait, Cypress의 retrying assertions, Selenium의 WebDriverWait처럼 조건 기반 동기화를 먼저 갖춰야 선별 실행의 효과를 제대로 관측할 수 있다는 것이 2026년 가이드의 요지다. 순서를 바꿔 말하면, flake rate가 높은 저장소에서 선별 실행부터 도입하면 절감폭 수치는 좋아 보여도 실제 신뢰도는 오히려 낮아진다.

롤백 안전성은 선별 정확도만으로 지켜지나?

지켜지지 않는다. 선별 실행은 PR의 피드백을 빠르게 만들지만, 선택되지 않은 테스트가 실제 결함을 드러낼 가능성은 그대로 남는다. 그래서 2026년 가이드 문서와 캐시 전략 문서 모두 impacted subset과 full-suite backstop을 함께 두는 구조를 권장한다. 여기서 backstop의 역할은 단순한 이중 확인이 아니라, 선별 로직이 놓친 의존성 관계를 주기적으로 드러내는 감시망이다. 같은 문서는 의존성 맵을 정기적으로 재빌드해야 stale mapping을 줄일 수 있다고 강조하는데, 맵이 오래될수록 영향 없음으로 분류된 테스트가 실제로는 영향권에 들어와 있을 확률이 올라가기 때문이다. pytest의 캐시 관련 문서 역시 실행 이력을 재사용할 때 대상 범위를 명확히 관리해야 함을 보여준다(pytest 캐시 문서). 롤백을 안전하게 만드는 요소는 결국 세 가지로 나뉜다 — 선별 정확도, 전체 회귀의 실행 주기, 그리고 캐시 키의 엄격도. 이 중 하나만 강화하고 나머지를 방치하면, 전체 시스템의 실패 탐지력은 가장 약한 지점에 맞춰진다.

실측 수치로 보면 무엇이 다른가?

표에서 보이는 대로, 선별 실행의 강점은 속도이고 전체 회귀의 강점은 탐지력이다. 두 값은 서로 상쇄 관계에 있어서, 한쪽 수치만 보고 도입 여부를 정하면 반대쪽 리스크를 놓치게 된다.

하이브리드로 전환할 때 실제로 드는 비용은 무엇인가?

전환 비용은 도구 설치비가 아니라 유지 비용으로 나타난다. 먼저 의존성 맵을 구축하고 정기적으로 재빌드하는 파이프라인이 필요하다. 맵이 stale 상태로 방치되면 선별 실행의 정확도가 시간이 지날수록 떨어진다. 둘째, 캐시 키 설계를 code 변경 여부에서 code·test·configuration·runtime·external inputs 전체로 확장해야 하며, 기존에 빌드 캐시만 관리하면 된다고 여겼던 팀에는 추가 작업량으로 체감된다. 셋째, 실패 재실행과 성공 재사용을 분리하는 로직을 별도로 두어야 한다. 지금까지 하나의 캐시 계층으로 pass와 fail을 함께 다뤘다면, 이를 분리하는 과정에서 CI 설정 자체를 다시 짜야 한다. 넷째, 메인·나이틀리에 전체 suite를 유지하려면 그만큼의 실행 자원과 실행 시간대를 확보해야 한다 — 이는 PR 쪽에서 줄인 비용을 완전히 상쇄하지는 않지만, 일정 부분을 다시 필요로 한다. 마지막으로 플래키 테스트 격리·쿼런틴 프로세스를 먼저 정리해두지 않으면, 선별 실행 도입 이후에도 실패 원인 분석에 걸리는 시간은 줄어들지 않는다.

어떤 조건에서 어느 쪽에 무게를 둬야 하나?

정답은 저장소 특성에 달려 있다. 테스트 스위트가 결정론적이고 hermetic하며 의존성 맵이 자주 갱신되는 환경이라면, PR 경로에서 선별 실행을 공격적으로 쓰고 캐시도 넓게 재사용할 수 있다. 반대로 flake rate가 이미 높은 저장소라면, 선별 실행이나 캐시 재사용보다 테스트 격리와 동기화 조건 정비가 먼저다 — 이 순서를 지키지 않으면 선별 실행의 절감폭 수치는 실제 신뢰도를 반영하지 않는다. 롤백 리스크가 큰 배포 경로, 이를테면 메인 브랜치 머지 직후에는 선별 실행만으로 넘어가지 말고 전체 회귀를 backstop으로 반드시 유지해야 하며, 의존성 맵의 재빌드 주기를 실패 누락 허용치에 맞춰 조정해야 한다. 정리하면, 선별 실행은 테스트 스위트의 결정론성과 의존성 맵의 신선도라는 두 조건이 충족될 때만 전체 회귀의 대체재에 가까워지고, 그렇지 않으면 항상 backstop이 필요한 보조 수단으로 남는다.

핵심 정리

• PR 경로에는 TIA 기반 선별 실행으로 속도·비용을 줄이고, 메인/나이틀리에는 전체 suite로 누락을 잡는 하이브리드가 2026년 기준 정석이다.
• 선별 실행은 median feedback time을 최대 96%, 실행 시간을 최대 66~98% 줄이지만 실패의 최대 55%를 놓칠 수 있다.
• 캐시 재사용은 결정론적·hermetic한 unit test에 한정하고, 캐시 키는 code·test·configuration·runtime·external inputs를 모두 포함해야 한다.
• 플래키 테스트가 많은 저장소는 선별 실행보다 테스트 격리·동기화 정비를 먼저 해야 절감폭 수치가 실제 신뢰도를 반영한다.
• 롤백 안전성은 선별 정확도, 전체 회귀 주기, 캐시 키 엄격화 세 가지를 함께 설계해야 확보된다.

자주 묻는 질문

선별 실행 도입 초기에 가장 먼저 점검해야 할 것은?

의존성 맵의 최신성과 테스트 스위트의 결정론성이다. 맵이 stale 상태면 영향 없음으로 분류된 테스트가 실제로는 영향권에 있을 수 있고, 테스트가 비결정론적이면 선별 결과 자체를 신뢰하기 어렵다.

캐시 재사용과 선별 실행을 동시에 도입해도 되나?

가능하지만 순서가 중요하다. 캐시 키를 code·test·configuration·runtime·external inputs 전체로 엄격하게 설계한 뒤 선별 실행을 얹어야 하며, 반대로 하면 캐시 오염이 선별 로직의 오판으로 이어질 수 있다.

전체 회귀 실행 주기는 어느 정도가 적절한가?

저장소 변경 빈도와 실패 누락 허용치에 따라 달라지지만, merge to main과 nightly 시점을 최소 기준으로 삼는 것이 가이드의 권고다. 배포 직전 경로에서는 이보다 더 촘촘한 주기가 필요할 수 있다.

플래키 테스트를 먼저 줄이지 않고 선별 실행부터 도입하면 어떤 문제가 생기나?

절감폭 수치는 좋아 보이지만 실패 탐지의 신뢰도는 낮아진다. 선별 로직이 플래키 실패를 무관한 우연으로 처리하면서, 실제 결함과 환경 문제를 구분하지 못하는 상태로 굳어질 수 있다.

더 알아보기

CI/CD 파이프라인 신뢰성: 캐시·테스트·배포의 균형 — 이 주제의 종합 가이드