소프트웨어 V&V: 확인과 검증으로 품질을 판단하는 기준
소프트웨어 V&V의 확인과 검증을 구분하고, 요구사항·설계·구현·인수 테스트에서의 역할을 정리한다.
2026-08-14 · 최초 발행 2026-04-17
요구사항에 맞게 만들었는지와 필요한 것을 만들었는지는 다르다
소프트웨어 품질 관리에서 Verification과 Validation은 자주 함께 언급되지만, 확인하는 대상과 관점은 분명히 구분된다. V&V는 개발 산출물이 요구사항에 맞는지, 그리고 완성된 소프트웨어가 사용자가 원하는 목적을 충족하는지를 입증하는 활동이다.
IEEE 610.12는 이 둘을 구별해 정의한다.
확인은 개발 산출물의 일관성을 점검한다
Verification은 “Are we building the product right?”라는 질문에 답한다. 각 개발 단계에서 만들어진 산출물이 그 단계의 시작 조건, 즉 요구사항을 만족하는지 결정하는 과정이다.
개발자 관점에서는 사용자의 특정 요구사항이 충족됐다는 사실을 객관적 증거로 확인하는 활동이 된다. 설계가 요구사항과 맞는지, 코드가 설계에 부합하는지처럼 개발 과정 내부의 일관성과 무결성을 살핀다.
검증은 완성된 제품이 목적에 맞는지 입증한다
Validation은 “Are we building the right product?”에 해당한다. 개발 과정의 마지막 단계 또는 그 이후에 소프트웨어가 사용자의 요구와 사용 목적에 일치하는지 판단한다.
이는 사용자 관점에서 사용자의 요구와 사용 목적에 부합함을 객관적으로 입증하는 일이다. 실제 환경에서 원하는 기능을 수행하는지, 비즈니스 가치를 만들어내는지를 확인한다.
개발 흐름에서 만나는 V&V
요구사항에서 설계와 구현으로 이어지는 과정에서는 내부 일관성을 확인하고, 통합과 인수 단계에서는 사용 목적의 달성 여부를 검증한다.
같은 품질 활동 안에서 달라지는 판단 기준
| 비교 항목 | 확인 (Verification) | 검증 (Validation) |
|---|---|---|
| 주요 질문 | 우리는 제품을 올바르게 만들고 있는가? | 우리는 올바른 제품을 만들고 있는가? |
| 관점 | 개발자/시스템 관점 | 사용자/비즈니스 관점 |
| 대상 | 중간 산출물 (문서, 코드, 설계) | 최종 소프트웨어 제품 (실행 파일) |
| 활동 예시 | FTR, 인스펙션, 워크스루, 정적 분석 | 인수 테스트, 베타 테스트, 시뮬레이션 |
| 목표 | 명세서와의 일치성 확인 | 사용자 의도와의 부합성 입증 |
확인 없이 검증만 수행하면 개발 과정의 기반이 약해질 수 있다. 반대로 검증이 빠지면 요구사항과 설계에 충실한 결과물이더라도 사용자가 원하지 않는 제품이 될 수 있다. 개발 단계에서는 Doing things right를, 최종 제품에서는 Doing the right thing을 함께 확인해야 한다.
Sources
- IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990).
- Pressman, R. S. (2014). Software Engineering: A Practitioner's Approach. McGraw-Hill.
- Boehm, B. W. (1984). Verifying and Validating Software Requirements and Design Specifications. IEEE Software.