V-Model로 개발 단계와 테스트를 연결하는 방법
V-Model의 개발·테스트 대응 구조, 요구사항 추적성, 시프트-레프트 품질 관리와 적용 시 고려할 제약을 정리한다.
2026-08-14 · 최초 발행 2025-12-17
개발 산출물과 테스트 산출물을 맞물리는 구조
V-Model은 폭포수 모델의 선형 개발 단계에 검증과 테스트 활동을 대응시킨 프로세스 모델이다. V의 왼쪽은 정적 검토와 설계 검증을 수행하는 Verification 영역이며, 오른쪽은 실행을 통해 확인하는 Validation 영역이다.
요구사항 정의는 인수 테스트와, 상위 설계는 시스템 테스트와 연결된다. 하위 설계는 통합 테스트, 구현은 단위 테스트의 기준이 된다. 이 대응 관계를 통해 요구사항에서 테스트 케이스, 결함, 증적으로 이어지는 추적성을 확보한다. 개발 단계가 진행되는 동안 각 테스트의 계획과 설계도 함께 시작하는 것이 핵심이다.
추적성과 품질 게이트를 앞단에 둔다
요구사항에서 테스트 케이스, 테스트 결과, 로그와 리포트 같은 증적까지 연결하면 변경이 발생했을 때 영향을 받는 회귀 범위를 산정하기 쉬워진다. Requirements Traceability Matrix는 이 연결을 관리하는 기준이 된다.
요구·설계 단계에서는 테스트 전략, 테스트 계획, 테스트 설계를 병행해 수립한다. 결함을 초기 단계에서 발견하고 격리할 수 있어 수정 비용 곡선을 평탄화하는 데 도움이 된다.
각 단계의 요구 명세, 설계 문서, 코드, 테스트 케이스에는 품질 기준과 승인 게이트를 둔다. 형상 관리의 버전·변경 이력, 워크스루와 인스펙션 같은 리뷰 절차도 정적 검증의 일부로 표준화한다.
테스트 우선순위는 심각도×발생도로 판단한 위험도를 기준으로 정할 수 있다. ISO 26262, IEC 62304처럼 안전·규제 표준이 적용되는 환경에서는 문서와 증적의 정합성을 유지하는 데도 적합하다.
다만 예측가능성과 문서 일관성을 얻는 대신, 요구 변화가 잦은 환경에서는 플렉서빌리티가 제약될 수 있다. 문서·증적 비용이 늘고 일정이 경직될 수 있다는 점도 함께 고려해야 한다.
적용이 잘 맞는 프로젝트
임베디드, 자동차, 의료기기, 국방 도메인에서는 규제 표준 적합성을 위해 요구사항부터 테스트까지 추적 매트릭스를 운영할 수 있다. HIL/SIL 테스트, 코드 커버리지, 독립 검증 조직(IV&V)도 이 구조와 함께 적용된다.
엔터프라이즈 SI와 패키지 통합 프로젝트에서는 비즈니스 요구 명세서와 인수 기준(AC)을 정합화하고, 시스템·통합 테스트 계획을 선행해 수립한다. 인터페이스 계약서는 통합 테스트 케이스 설계의 기준이 되며, 결함 SLA 운영에도 연결된다.
ERP와 패키지 커스터마이징에서는 표준 기능과 커스터마이징 범위를 구분하고 회귀 테스트 세트를 고정화할 수 있다. 변경 관리(CR)와 테스트 영향도 분석 자동화 도구를 연계하는 방식도 가능하다.
후기 결함을 앞단으로 옮겼을 때의 효과
릴리스당 시스템·인수·운영 단계의 후기 결함이 100건이고, 후기 수정 비용 가중치가 15배이며, 조기 결함 전환율이 30%라고 가정한다. 이때 전환 결함은 30건이고, 30건 × (15−1)에 따라 420 공수를 절감한다. 이는 후기 수정 15 대비 단위 단계 1로 환산한 값이다.
이 구조는 총 테스트·품질 비용 절감, 출시 지연 리스크 감소, 결함 유출률과 재오픈률 개선으로 이어질 수 있다. 요구사항과 테스트의 일관성이 강화되면 수용 기준이 명확해지고 이해관계자 합의 비용도 줄어든다. 감사·컴플라이언스 대응, 회귀 안정성, 팀 간 의사소통 구조화에도 유리하다.
폭포수·V-Model·애자일의 운영 특성
| 항목 | 폭포수 | V-Model | 애자일 |
|---|---|---|---|
| 예측가능성 | 중간 | 높음 | 중간 |
| 일관성(문서·증적) | 중간 | 높음 | 낮음~중간 |
| 안정성(릴리스 품질) | 중간 | 높음 | 중간~높음 |
| 확장성(변경 대응) | 낮음 | 낮음~중간 | 높음 |
| 운영 편의(프로세스 성숙) | 중간 | 높음 | 팀 성숙도 의존 |