요구·코드·리스크를 연결하는 테스트 커버리지 관리
요구사항·코드·리스크 커버리지를 하나의 추적성 체계로 관리하고, CI 게이트와 기준선으로 릴리스 품질을 관리하는 방법
2026-08-14 · 최초 발행 2025-12-23
릴리스 판단에 필요한 것은 연결된 커버리지다
테스트 활동을 통제하려면 요구사항, 소스코드, 리스크 레지스터를 따로 보지 않아야 한다. 테스트 커버리지 관리는 이 세 축을 일관된 데이터 모델로 묶고, 커버리지 지표와 게이트를 통해 품질을 정량적으로 보증하는 체계다.
요구 커버리지는 요구사항과 테스트케이스의 양방향 추적성을 확인한다. 유효 요구사항 수를 분모로, 검증이 끝난 요구사항 수를 분자로 삼아 충족률을 측정한다. 요구사항이 바뀌면 연결된 테스트 아티팩트도 함께 관리해야 최신성과 완전성을 유지할 수 있다.
코드 커버리지는 라인, 분기, 함수, 조건(MC/DC) 단위에서 테스트가 실행한 비율을 본다. 측정 대상 코드 수와 테스트로 실행된 코드 수의 관계로 계산하며, 단위·통합·E2E 레벨은 분리해 측정하는 편이 낫다. 실행 비율만으로 테스트 강도를 판단하기 어려운 부분은 Mutation testing으로 보완한다.
리스크 커버리지는 리스크 레지스터의 심각도×발생도×검출도를 바탕으로 테스트를 설계하고 우선순위를 정한다. 고위험 항목을 먼저 검증하고, 잔여 리스크(Residual Risk) 지표를 릴리스 의사결정에 사용한다.
추적성 데이터와 게이트를 운영하는 방식
추적성 매트릭스(TRM)에는 요구, 테스트, 코드, 리스크를 연결할 표준 ID 체계가 필요하다. REQ-123, RISK-45, MOD-auth처럼 일관된 키를 사용하면 변경이 발생했을 때 영향 범위를 추적할 수 있다. TRM 자동 생성·검증 스크립트는 누락되거나 고립된(Orphan) 항목을 찾는 데 쓴다.
CI에서는 코드 커버리지(XML/JSON), 테스트 결과(JUnit/Allure), 요구·리스크 목록(CSV/ALM API)을 취합한다. 스키마를 표준화한 뒤 단일 저장소(Data Mart)에 적재하고, 중복과 불일치를 검출하는 규칙을 함께 둔다.
게이팅 정책에는 최소 기준과 예외 처리 흐름이 들어간다. 예를 들어 핵심 요구 커버리지는 100%, 코드 분기 커버리지는 80% 이상, 고위험 항목 테스트는 100%를 기준으로 둘 수 있다. 리스크 수준에 따라 임계치를 달리 적용하고, Defer/Accept 같은 합리적 예외는 승인 워크플로우로 관리한다.
대시보드는 팀·모듈·릴리스 단위로 지표를 보여주고, 주간 리뷰에서 활용한다. 임계치 미달이나 급격한 하락은 알림 대상으로 둔다. QA Lead는 정책을 맡고, 개발팀은 테스트와 리팩터링을 담당하며, 제품·보안 조직은 리스크 승인을 맡는 RACI를 정할 수 있다.
감사, 모노레포, 레거시 환경에서의 활용
금융·의료처럼 규제를 받는 환경에서는 요구·리스크 100% 커버리지 증빙과 변경 이력 보관에 활용할 수 있다. ISO 14971, IEC 62304, SOX 등의 표준 적용 시 릴리스 게이트에 리스크 잔여값 임계치를 포함하면 감사 대응 리드타임을 줄일 수 있다.
대규모 모노레포에서는 모듈 태깅과 테스트 임팩트 분석(TIA)으로 변경 범위의 커버리지를 보장한다. 병렬 계측과 샤딩은 커버리지 수집 시간 최적화에 사용한다.
레거시 개편은 베이스라인 커버리지를 먼저 산정하고 회귀 스위트를 우선 강화하는 방식으로 시작할 수 있다. 이후 +5%/스프린트처럼 임계치를 점진적으로 올리고 기술부채 버젯을 관리한다.
측정 기준선과 예외를 함께 관리한다
기준선은 기능과 위험도에 맞춰 구분한다. 요구 커버리지는 핵심 기능 100%, 일반 기능 ≥ 95%를 기준으로 둘 수 있다. 코드 커버리지는 라인 ≥ 7080%, 분기 ≥ 7080%, 핵심 로직은 MC/DC 또는 Mutation Score ≥ 60%를 권장한다. 리스크 커버리지는 High=100%, Medium≥90%, Low≥80%를 기준으로 잡는다.
측정식도 같은 방식으로 고정한다.
- 요구 커버리지(%) = "검증 완료 요구 수"/"총 요구 수" × 100
- 코드 커버리지(%) = "실행된 요소 수"/"총 요소 수" × 100
- 리스크 커버리지(가중) = Σ("테스트 커버된 리스크 점수")/Σ("총 리스크 점수") × 100
코드 커버리지는 단위·통합·E2E 레벨별로 나누어 보고한다. 높은 커버리지가 높은 결함 탐지력을 뜻하지는 않으므로, 취약한 테스트는 Mutation testing으로 보강해야 한다. 계측 오버헤드와 빌드 시간 증가는 변경 기반 샘플링이나 부분 계측으로 다룬다.
| 항목 | 요구 커버리지 | 코드 커버리지 | 리스크 커버리지 |
|---|---|---|---|
| 성능(계산 비용/속도) | 중: 매핑·집계 비용 존재 | 중~고: 대형 코드베이스 계측 비용 큼 | 중: 스코어 계산 가벼움 |
| 확장성(대규모 적용) | 중~고: ALM 연계시 양호 | 고: CI 병렬화·샤딩으로 확장 | 중: 리스크 정의 품질에 의존 |
| 일관성(변경 내성) | 중: 요구 변경 영향 큼 | 중: 리팩터·생성 코드 변동 영향 | 고: 레지스터 관리 성숙도에 좌우 |
| 안정성(도구/파이프라인) | 고: 단순 포맷 운영 가능 | 중: 언어·런타임별 편차 | 중~고: 프로세스 준수 필요 |
| 운영 편의(설치/유지) | 중: TRM 체계 필요 | 중: 언어별 도구 혼재 | 중: 리스크 워크플로우 요구 |
기준선부터 자동 검증까지 이어 붙이기
처음에는 REQ, TEST, RISK, MOD의 표준 ID와 명명 규칙을 정의한다. ALM, 이슈 트래커, SCM 태그를 정비하고 최소 임계치, 예외 승인 프로세스, 라벨링과 소유권을 함께 정한다.
구현 단계에서는 CI에 계측 단계를 추가하고 결과 수집 저장소를 구성한다. 리포트 스키마는 XML/JSON/CSV 기준으로 표준화하며, TRM의 누락·고아·중복을 확인하는 자동 검증 스텝과 Threshold 게이트를 적용한다.
운영에서는 스프린트·릴리스 리뷰마다 갭을 분석해 액션을 등록한다. 위험도가 바뀌면 임계치를 재조정하고, 대시보드 경향 분석은 품질 OKR과 연결한다. 필요에 따라 Mutation/MC/DC 적용 범위를 넓힌다.
이 체계를 적용하면 결함 유출율(Prod Defect Leakage)은 2040% 감소하고, 고위험 영역의 결함 발견률은 증가한다. 회귀 테스트 시간은 1530% 단축되며 릴리스 게이트 재시도율도 감소한다. 변경 영향 범위의 가시성과 릴리스 의사결정 신뢰도를 높이고, 지표와 정책을 팀 간 공통 언어로 정착시키는 효과도 기대할 수 있다.