전수 테스트가 불가능한 이유와 위험 기반 우선순위 설계

대규모 분산 시스템과 다양한 모바일 환경, 잦은 배포가 겹치면 모든 경우를 테스트하는 계획은 곧바로 한계에 부딪힌다. 제한된 시간과 예산 안에서 품질 신호를 얻으려면, 전수 실행이 아니라 위험과 가치에 따라 테스트 범위를 설계해야 한다.

테스트 범위는 우선순위로 관리한다

Exhaustive Testing은 가능한 모든 입력, 상태, 경로, 환경 조합을 확인하려는 접근이다. 그러나 조합 폭증에 더해 연속값, 타이밍, 동시성, 환경 다양성, 비결정성이 결합하면 상태 공간은 무한하거나 천문학적으로 커진다.

이때 우선순위 전략은 위험과 가치를 점수화해 테스트 순서와 범위를 정하는 체계가 된다. 조합을 줄이고 변경 영향에 맞춘 회귀를 선택해, 중요한 검증부터 실행하는 방식이다.

위험 항목은 기능 실패의 영향도(Severity), 발생 가능성(Likelihood), 노출도 또는 사용 빈도(Exposure)에서 찾는다. 기본 점수는 Risk Score = S × L × E로 두고, 로그 스케일이나 가중치를 적용할 수 있다. 최근 변경 빈도와 결함 이력을 가중치로 추가하는 방법도 있다.

테스트 범위는 요구사항뿐 아니라 코드의 라인·분기·조건, 데이터 도메인, API·유스케이스, 인프라·구성까지 포함해 정의한다. 결과를 판정하는 오라클도 명세 기반 판정, 메트릭 허용오차를 이용한 비정밀 수치·성능 판정, ML·검색에 쓰이는 휴리스틱과 유사도 판정을 섞어 구성할 수 있다.

입력 조합은 Pairwise/t-wise 설계로 t차 상호작용까지 보장하는 최소 사례 집합을 만들고, 동치 분할과 경계값 분석으로 대표 입력을 고른다. 변경이 발생한 뒤에는 Test Impact Analysis(TIA)로 변경 파일과 테스트의 맵을 이용해 필요한 회귀만 실행한다. 최근 커밋이 커버하는 테스트를 먼저 실행하고, 미커버 영역을 보완하는 식이다.

조합은 생각보다 빠르게 감당 범위를 넘는다

파라미터가 8개이고 각 파라미터가 4개 값을 가진다고 가정해 보자. 계산을 단순화하면 4^8 = 4×4×4×4×4×4×4×4 = 16×16×16 = 256×16 = 4096처럼 보일 수 있지만, 정정하면 4^8 = 65,536 (16×16=256, 256×256=65,536)이다. 실무 시간 안에 모두 처리하기 어려운 규모다.

모바일 매트릭스는 환경 조건까지 더해진다.

• OS 5 × 디바이스 20 × 로케일 12 × 네트워크 4 = 5×20=100, 100×12=1,200, 1,200×4=4,800
• 피처 토글 10개(ON/OFF): 2^10 = 1,024
• 총 조합: 4,800 × 1,024 = 4,915,200 → 전수 실행 비현실

동시성도 별도의 폭증 요인이다. 스레드 3개가 각각 10스텝씩 상호작용한다면 경우의 수는 (30)! / (10!)^3이며, 근사치는 ~5.5×10^26 수준이다. 탐색 가능한 크기가 아니다. 실수 입력, 타임아웃, 네트워크 지터처럼 이산화하기 어려운 값까지 포함하면 전수 테스트를 정의하는 일 자체가 불가능해진다.

위험 신호를 앞에 배치하는 실행 흐름

테스트 계획의 입력은 요구사항과 변경 내역, FMEA·STRIDE 기반 위험 목록, 보유 테스트 자산, 운영 텔레메트리다. 이 정보를 바탕으로 위험 점수화와 커버리지 매핑을 수행하고, Pairwise/t-wise 설계, 경계값·동치 분할, 비용-가치 점수 계산을 거친다.

그 결과는 스모크 테스트에서 고위험 영역, 조합 축소, 경계값, 영향 기반 회귀로 이어지는 실행 목록이 된다. 정지 기준과 결함·커버리지 리포트도 함께 관리한다.

⤢✕

테스트 가치 점수는 위험 커버리지의 가중치와 결함 검출력(히스토리·유형 적합도)을 더하고, 실행 시간·플레이크·환경 준비 비용을 빼는 방식으로 구성한다. 실행은 가치 점수 내림차순으로 정하며, 점수가 같으면 최근 변경 영향도와 운영 빈도를 우선한다.

중단 조건도 사전에 둔다. 최근 1시간/100케이스당 신규 결함이 0인 경우처럼 결함 검출 기울기가 임계값 이하로 내려가면 정지할 수 있다. 위험 커버리지 80% 이상 또는 핵심 시나리오 100% 통과 역시 기준이 된다.

제품 환경별로 줄이는 방법

웹 API 배포 파이프라인에서는 변경 영향 분석으로 관련 엔드포인트 회귀만 실행하되, 공통 인증·권한 테스트는 항상 포함한다. 헤더와 파라미터 조합은 t=2 Pairwise로 줄이고, 페이징과 쿼터 한계는 경계값으로 확인한다.

모바일 앱은 운영 텔레메트리에서 상위 20% 기기·OS 조합을 선택해 사용량 80%를 커버한다. 나머지 조합은 클라우드 디바이스 팜에서 Pairwise로 실행하고, 네트워크는 오프라인·불안정·정상의 3단계 대표값으로 다룬다.

데이터 파이프라인에서는 스키마가 바뀌었을 때 스키마 경로를 기준으로 영향받는 테이블만 회귀한다. 샘플링 데이터는 최대 길이, NULL, 이상치 같은 경계값을 우선하며, 메트릭 이상 탐지의 분포 이동 테스트는 스모크 테스트로 올려 조기 경보를 확보한다.

임베디드와 IoT 환경은 하드웨어 제약을 고려해 시뮬레이터에서 t-wise 조합을 만들고, 실제 디바이스에서는 고위험·경계값만 실행한다. 전원과 온도 경계조건은 운영 스트레스 테스트와 나누어 야간 배치로 실행한다.

속도와 품질의 균형

이 접근은 전체 테스트 시간을 3060% 줄이고 배포 빈도를 높일 수 있다. 스모크와 고위험 테스트를 앞세우면 평균 결함 발견 시점을 2040% 앞당길 수 있으며, 불필요한 환경 할당과 디바이스 팜 사용량은 2550% 절감할 수 있다. 운영 상위 시나리오의 가용성을 개선하고 고객 영향 결함(escaped defects)을 2040% 줄이는 효과도 기대할 수 있다.

수치는 산업 평균 범주이며, 조직과 도메인에 따라 편차가 존재한다.

접근 방식	성능(탐지 속도)	확장성	일관성	안정성	운영 편의
Exhaustive Testing	낮음(신호 지연)	매우 낮음	이론적 높음(실행 불가)	이론적 높음	매우 낮음
위험 기반 우선순위	높음(빠른 신호)	높음	중간(모델 의존)	높음(핵심 경로 집중)	높음
Pairwise/t-wise	중간~높음	높음	높음(수학적 보장)	중간	중간(도구 필요)
변경 영향 회귀(TIA)	매우 높음	높음	중간(탐지 품질 의존)	중간	높음(CI 연동 용이)

편향과 누락을 관리하는 운영 원칙

위험 점수 산정과 커버리지 매핑은 자동화하고, 대시보드로 가시성을 확보한다. 운영 텔레메트리를 운영 프로파일에 반영해 주기적으로 리밸런싱하며, 플래키 테스트는 분리·격리하고 재시도와 휴리스틱을 적용해 신호 품질을 유지한다.

위험 기반 접근은 낮은 가능성이지만 영향이 큰 시나리오를 놓칠 수 있으므로 정기 샘플링과 혼합 전략이 필요하다. t-wise는 t를 넘는 상호작용 결함을 놓칠 수 있어 고위험 영역에서는 t를 높이거나 모델 기반 보완을 고려한다. TIA는 변경 추적이 누락되면 회귀 자체가 빠질 수 있으므로 정적·동적 커버리지를 함께 통합하는 편이 낫다.

전수 테스트의 한계를 인정하는 것은 검증을 포기하는 일이 아니다. 위험과 가치, 조합 축소, 변경 영향, 정지 기준을 하나의 흐름으로 묶고 텔레메트리 피드백으로 계속 조정해야 적은 테스트에서도 더 빠른 신호를 얻을 수 있다.