V 모델로 개발 단계와 테스트를 연결하는 방법
V 모델의 개발·테스트 대응 구조, 산출물, 장단점과 규제 산업 및 DevOps 환경에서의 활용 방식을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
개발 산출물에 테스트를 미리 연결하는 V 모델
V 모델은 폭포수 모델을 확장한 소프트웨어 개발 생명주기 방법론이다. 개발 과정은 왼쪽으로 내려가고, 구현 뒤의 테스트 과정은 오른쪽으로 올라가는 V자 구조를 이룬다. 핵심은 각 개발 단계에 대응하는 테스트 활동을 미리 정해 Verification과 Validation을 개발 전 과정에 포함하는 데 있다.
요구사항 분석은 인수 테스트와, 시스템 설계는 시스템 테스트와, 아키텍처 설계는 통합 테스트와, 상세 설계는 단위 테스트와 각각 연결된다. 구현이 끝난 뒤에 테스트를 별도 단계로 취급하는 대신, 설계 시점부터 무엇을 검증할지 함께 준비하는 방식이다.
요구사항에서 구현까지 남겨야 할 산출물
요구사항 분석에서는 고객 요구사항을 수집·분석해 개발 목표와 범위를 정한다. 기능적·비기능적 요구사항 명세서(SRS: Software Requirements Specification)를 작성하고, 이해관계자와 합의한 방향을 기준으로 요구사항 명세서, 사용자 스토리, 유스케이스 문서를 남긴다.
시스템 설계 단계에서는 전체 구조와 핵심 컴포넌트를 정의한다. 하드웨어와 소프트웨어 요구사항을 명세하고, 시스템 아키텍처와 주요 인터페이스를 설계한다. 이 단계의 결과물은 시스템 설계 문서와 아키텍처 다이어그램이다.
아키텍처 설계는 모듈 구조와 컴포넌트 사이의 관계에 초점을 둔다. 데이터 흐름과 통신 방식을 설계하고 기술 아키텍처 및 프레임워크를 선정한다. 아키텍처 설계 문서와 모듈 명세서가 뒤따른다.
상세 설계에서는 개별 모듈과 컴포넌트의 내부를 구체화한다. 알고리즘, 데이터 구조, 클래스, 인터페이스 세부 사항을 정리하며, 상세 설계 문서와 클래스 다이어그램, 시퀀스 다이어그램을 산출한다.
구현 단계는 설계 문서를 바탕으로 코드를 작성하는 구간이다. 프로그래밍 표준과 코딩 가이드라인을 따르며 기능을 구현하고 단위 수준의 테스트를 수행한다. 소스 코드와 빌드 결과물이 이 단계의 결과물이다.
설계의 대응 관계를 따라가는 테스트
단위 테스트는 개별 모듈 또는 컴포넌트의 기능을 확인한다. 상세 설계 문서를 기준으로 개발자 중심의 테스트를 수행하며, 단위 테스트 계획서·테스트 케이스·테스트 결과 보고서를 남긴다.
통합 테스트는 모듈 간 인터페이스와 상호작용을 검증한다. 아키텍처 설계 문서에 대응하며, 컴포넌트를 결합하면서 생기는 문제를 식별한다. 상향식(Bottom-up), 하향식(Top-down), 샌드위치(Sandwich) 접근법을 사용할 수 있고, 통합 테스트 계획서·테스트 케이스·결과 보고서가 산출된다.
시스템 테스트는 전체 시스템의 기능과 성능을 대상으로 한다. 시스템 설계 문서와 연결되며, 기능·성능·보안·호환성 등 다양한 측면을 시험한다. 시스템 테스트 계획서, 테스트 케이스, 결과 보고서가 필요하다.
인수 테스트는 요구사항 명세서에 맞춰 고객 관점에서 시스템을 검증하는 단계다. 사용자 환경에서의 동작을 확인하고 고객 또는 최종 사용자가 참여한다. 알파 테스트, 베타 테스트, 사용자 인수 테스트(UAT)가 여기에 속하며, 인수 테스트 계획서·결과 보고서·사용자 피드백을 남긴다.
문서화와 검증이 강점이 되는 조건
V 모델은 단계별 개발 활동과 테스트 활동의 관계가 명확하다. 품질 보증 활동이 개발 프로세스 전체에 통합되고, 초기부터 테스트 계획을 세울 수 있어 오류를 일찍 발견하는 데 도움이 된다.
산출물이 분명하므로 프로젝트 진행 상황을 파악하기 쉽고, 산업 표준 준수 관점에서도 관리 효율성을 기대할 수 있다. 상세한 문서는 지식 전달과 유지보수에 쓰이며, 이후 유사 프로젝트의 참조 자료가 될 수 있다.
반대로 요구사항이 바뀌면 대응이 어렵다. 폭포수 모델처럼 한 단계가 끝난 뒤 다음 단계로 넘어가는 성격이 있어 유연성이 낮다. 작동하는 소프트웨어를 확인하는 시점도 늦고, 사용자 피드백 반영이 지연될 수 있다.
계획과 문서화에 많은 시간과 비용이 들기 때문에 소규모 프로젝트에는 과도한 오버헤드가 될 수 있다. 개발 후반에 중대한 문제가 발견되면 비용과 시간이 크게 들며, 예상하지 못한 위험에 대한 대응도 제한적이다.
규제와 안전성이 개발 기준인 분야
금융권에서는 정확성과 안정성이 중요한 시스템에 V 모델을 적용할 수 있다. 금융 규제와 보안 요구사항을 요구사항 분석에 반영하고, 인수 테스트에서 금융 감독원 기준 준수와 보안 감사를 확인하는 흐름이다.
의료기기 소프트웨어는 인체와 관련된 중요 시스템이며 FDA 등 규제 기관의 승인이 필요한 분야다. 철저한 검증과 확인으로 환자 안전을 보장하고, 의료기기 소프트웨어 개발 관련 IEC 62304 표준과 엄격한 문서화 요구사항을 충족하는 방법론으로 활용할 수 있다.
항공기와 우주선의 제어 시스템처럼 고신뢰성이 요구되는 시스템에도 적용된다. DO-178C 항공 소프트웨어 인증 표준을 준수하는 프로세스를 세우고, 단계별 검증과 개발부터 테스트까지 추적 가능한 문서화 체계를 마련하는 데 사용된다.
폭포수·애자일·스파이럴과의 차이
폭포수 모델과 V 모델은 순차적인 개발 과정과 문서화 중심 접근법을 공유한다. 차이는 V 모델이 각 개발 단계에 대응하는 테스트 활동을 명시한다는 점이다. 폭포수 모델보다 품질 보증 활동이 강화된 형태로 볼 수 있다.
애자일은 반복적 요구사항 개발, 작동하는 소프트웨어, 반복적 개발, 지속적 테스트에 무게를 둔다. V 모델은 전체 요구사항을 사전에 정의하고 문서와 단계적 진행, 전체 기간의 테스트 계획을 중심에 둔다.
스파이럴 모델은 반복적으로 진행하면서 위험 관리를 중심에 두고 프로토타이핑을 강조한다. 이에 비해 V 모델은 선형적 진행에 가깝고 위험 관리에는 제한이 있다.
애자일과 CI/CD 환경에서의 활용
하이브리드 방식은 V 모델의 체계적인 검증 구조와 애자일의 유연성을 결합한다. 개발은 애자일 방식으로 진행하되 테스트 전략에는 V 모델 구조를 적용하며, 규제가 엄격한 산업에서 애자일을 도입할 때 활용할 수 있다.
지속적 통합(CI)과 지속적 배포(CD) 환경에서도 V 모델의 테스트 구조를 사용할 수 있다. 자동화된 테스트를 검증 단계에 맞춰 구성하고, 파이프라인에 단위 테스트에서 통합 테스트, 시스템 테스트, 인수 테스트로 이어지는 체계를 반영하는 방식이다.
자율주행차와 의료기기처럼 안전이 중요한 시스템에서는 V 모델 기반 접근법이 여전히 선호된다. 기능 안전성 표준(ISO 26262, IEC 61508 등)을 준수하는 방법론으로 활용하고, 요구사항부터 검증까지의 추적성(Traceability)을 확보하는 프레임워크로 삼을 수 있다.