V-Model로 요구사항과 테스트를 함께 설계하는 방법

V-Model의 요구사항·설계·테스트 매핑 구조와 양방향 추적성, 게이트 기반 품질 관리, 규제·임베디드 환경 적용 방식을 정리한다.

2026-08-14 · 최초 발행 2025-12-21

요구사항을 남길 때 테스트의 근거도 함께 만든다

V-Model은 전통적인 폭포수 모델을 확장해, 왼쪽의 요구·설계 활동과 오른쪽의 검증·검증적합성 활동을 대응시키는 수명주기 모델이다. 개발 산출물이 완성된 뒤 테스트를 붙이는 방식이 아니라, 각 산출물에 어떤 테스트가 연결될지를 처음부터 함께 설계한다.

이 구조의 목적은 요구사항, 설계, 구현, 테스트 사이의 양방향 추적성을 확보하는 데 있다. 테스트 커버리지를 체계적으로 관리하고, 변경이 발생했을 때 영향을 받는 수정 범위와 테스트 갱신 범위를 예측할 수 있다.

안전, 보안, 규제 준수가 중요한 시스템과 임베디드·자동차(ISO 26262), 항공(DO-178C), 의료(IEC 62304), 국방 영역이 주요 적용 대상이다.

개발 산출물과 검증 활동을 연결하는 구조

왼쪽 단계에서는 요구사항 분석부터 시스템 요구 도출, 상위 설계(HLD), 상세 설계(LLD)까지 대상을 점진적으로 분해한다. 각 단계의 산출물은 구조적 일관성과 인터페이스 명세로 이어지며, 형상 관리 체계와도 연결된다.

오른쪽 단계는 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트로 진행된다. 각 테스트의 기준은 왼쪽에서 대응되는 산출물이다. 상세 설계는 단위 테스트와, 상위 설계는 통합 테스트와, 시스템 요구는 시스템 테스트와, 이해관계자 요구는 인수 테스트와 연결된다.

Verification과 Validation은 구분해 다룬다. Verification은 규격과 설계에 맞게 만들어졌는지 확인하는 활동이고, Validation은 결과물이 사용자 니즈에 적합한지 검토하는 활동이다.

요구사항과 테스트 케이스, 설계 요소와 테스트 시나리오 사이에는 양방향 링크를 둔다. 변경 요청이 들어오면 이 링크를 따라 수정 대상과 테스트 갱신 범위를 산정할 수 있다.

단계 종료 시점에는 완전성, 일관성, 검증가능성 같은 산출물 품질 기준을 게이트에서 확인한다. 결함이 발견되면 원인 단계로 회귀해 수정하고 재검증하는 루프를 명시한다.

테스트 전략, 환경, 데이터는 요구 단계부터 설계한다. 이때 커버리지 목표와 합격 기준을 정하고, 자동화 후보 및 성능·안전·보안 같은 비기능 요구를 검증하는 방법도 함께 마련한다.

요구부터 인수 테스트까지 이어지는 매핑

검증 매핑: 'LLD↔Unit Test'기준검증 매핑: 'HLD↔Integration'시나리오검증 매핑: 'REQ↔SystemTest' 항목검증 매핑:'Needs↔Acceptance' 케이스영향도 분석(양방향 추적)테스트 갱신 회귀 범위 산정이해관계자 요구(StakeholderNeeds)시스템 요구(SystemRequirements)상위 설계(Architecture/HLD)상세 설계(LLD)구현(Implementation)단위 테스트(Unit Test)통합 테스트(Integration Test)시스템 테스트(System Test)인수 테스트(AcceptanceTest)변경 요청(Change Request)

규제와 시스템 개발에서의 사용 방식

자동차 ECU에서는 ISO 26262 ASIL 요구를 정제한 뒤 HARA와 안전 요구를 HLD·LLD로 연결하고, 유닛 테스트-MCDC 커버리지 및 통합·시스템 안전 케이스를 구성할 수 있다. 의료기기 소프트웨어에서는 IEC 62304 클래스별 문서·테스트 산출물 매트릭스를 운영하고, 추적성 매트릭스를 심사 대응 자료로 사용한다.

임베디드와 펌웨어 개발에서는 드라이버·미들웨어의 인터페이스 계약을 기준으로 설계와 단위·통합 테스트 자동화 파이프라인을 구성한다. 하드웨어 인더루프(HIL)를 이용하면 시스템 테스트를 앞당길 수 있다. 실시간성이나 메모리처럼 리소스 제약과 관계된 비기능 요구는 성능 테스트와 명시적으로 매핑한다.

대규모 ERP나 코어 뱅킹 교체에서는 요구 카탈로그와 테스트 케이스를 1:1로 연결하고, 데이터 마이그레이션 검증 시나리오를 시스템·인수 테스트에 일찍 반영한다. 여러 팀이 함께 개발할 때는 상위 설계의 컴포넌트 경계를 기준으로 통합 테스트 계약을 정하고, 게이트 리뷰로 병렬 개발의 품질을 관리한다.

운영 체계에 녹이는 흐름

도입의 입력은 비즈니스 목표, 규제 요구, 상위 요구 목록, 커버리지·결함 밀도 목표를 포함한 품질 기준이다.

프로세스에는 단계, 게이트, 역할(RACI), 산출물 템플릿, 형상·추적 도구 설정이 포함된다. 이어 요구-설계-테스트 링크 규칙과 변경 영향도 분석 워크플로우를 정하고, 합격 기준·커버리지 목표·자동화 범위·환경·데이터 전략으로 테스트 전략을 구체화한다.

그 결과 요구/HLD/LLD 베이스라인, 테스트 케이스와 시나리오, 게이트 체크리스트, 추적성 매트릭스가 남는다.

요구사항이 변경되면 영향도 분석, 수정 범위 승인, 관련 테스트 갱신, 회귀 테스트 트리거 순서로 처리한다. 게이트를 통과하지 못했을 때는 결함을 요구·설계·구현으로 분류하고, 원인 단계로 회귀해 수정한 뒤 다시 검증한다.

품질과 심사 대응에 기대하는 변화

상류 설계 결함을 조기에 검출하는 것을 전제로, 결함 유출률 20~40% 감소와 재작업 비용 30% 절감을 기대한다(내부 벤치마크 기반 가정). 게이트 기반 진행 관리는 변동성을 낮추고 통합 단계 난이도를 평균 25% 완화하는 데 목적이 있다.

추적성과 증빙을 한곳에서 관리하면 심사 준비 리드타임을 30~50% 단축하고 불일치 지적 건수를 줄일 수 있다. 초기 테스트 설계는 중복을 제거하고 자동화 커버리지를 확대하는 기반이 되며, 단위 70%+, 통합 핵심 경로 60%+를 목표로 설정할 것을 권장한다.

안전·규제 도메인이나 대규모 시스템 전환에서는 핵심 컴포넌트부터 파일럿으로 시작하고, 자동화와 추적 도구 연계를 병행하면서 적용 범위를 넓힐 수 있다.

V-Model소프트웨어 테스트요구사항 추적성품질 관리검증과 검증적합성