확인 과 검증 (Validation과 Verification), 제대로 알고 계신가요?

 

Validation과 Verification 의 차이를 명확히 알고 계시나요?

 

 

안녕하세요, QA여행 ( https://qajourney.tistory.com/ ) 입니다.

 

오늘은 가장 기본적이면서도 헷갈리기 쉬운 두 가지 개념인,

Validation(확인)과 Verification(검증) 에 대해 이야기해 보려고 합니다.

이 두 용어는 종종 혼용되지만, 사실은 소프트웨어 개발의 서로 다른 단계를 책임지는 중요한 두 개의 관문입니다.

 

두 질문의 차이 :

"Are we building the product right?" vs "Are we building the right product?"

 

이 둘의 차이를 가장 명확하게 보여주는 질문입니다.

• Verification (검증) : "우리가 제품을 올바르게 만들고 있는가?"
• Validation (확인) : "우리가 올바른 제품을 만들고 있는가?"

아직 감이 잘 안 오시나요?

하나씩 자세히 살펴보겠습니다.

 

Verification (검증) 이란?

Verification은 개발 과정 중에 우리가 정해진 명세, 조건, 표준을 잘 따라서 제품을 만들고 있는지를 확인하는 활동입니다.

즉, 설계도대로 집을 짓고 있는지, 벽돌은 규격에 맞는 것을 쓰는지 하나하나 점검하는 과정과 같습니다.

주로 문서 검토나 정적 분석을 통해 이루어지며, 소프트웨어를 직접 실행하지 않는 경우가 많습니다.

• 목표 : 프로세스를 점검하고, 설계나 코드 수준의 오류를 조기에 발견하는 것.
• 주요 활동 : 요구사항 명세서 검토, 디자인 리뷰, 코드 인스펙션, 동료 검토(Peer Review) 등.
• 핵심 : "이 기능은 명세서에 정의된 대로 구현되었는가?"

 

Validation (확인) 이란?

Validation은 개발이 완료된 (혹은 실행 가능한) 제품이 고객의 실제 요구사항과 기대를 충족하는지를 확인하는 활동입니다.

다 지어진 집에 실제 살아볼 사람이 방문해서

"내가 살기에 편한가?", "방 구조가 내가 원했던 대로인가?"를 최종 확인하는 과정에 비유할 수 있습니다.

소프트웨어를 직접 실행하며 동적으로 테스트합니다.

• 목표 : 최종 제품이 사용자의 목적에 부합하고, 시장에서 가치를 가질 수 있는지 판단하는 것.
• 주요 활동 : 기능 테스트, 통합 테스트, 시스템 테스트, 사용자 인수 테스트(UAT) 등.
• 핵심 : "이 제품이 사용자의 문제를 정말로 해결해 주는가?"

 

구분	Verification (검증)	Validation (확인)
관점	내부 프로세스, 규칙 준수	외부 고객, 실제 요구 충족
시점	개발 과정 중 (Before / During)	개발 완료 후 (After)
방법	정적 (리뷰, 분석, 검사)	동적 (실행, 테스트)
질문	제품을 올바르게 만들고 있는가?	올바른 제품을 만들고 있는가?

 

 

 

예시 : 온라인 쇼핑몰의 '장바구니' 기능

• Verification (검증) 예시 :
  • 기획서에는 "장바구니 담기 버튼은 #008CBA 색상의 파란색이어야 한다"고 명시되어 있습니다.
  • 디자이너는 UI 시안을 검토하며 버튼 색이 명세와 일치하는지 확인합니다.
  • 개발자는 코드 리뷰를 통해 해당 버튼의 CSS 코드가 #008CBA로 정확히 입력되었는지 검토합니다.
  • => 명세서(규칙)를 잘 따랐는지 확인했습니다.
• Validation (확인) 예시 :
  • 테스터가 실제 앱을 실행하여 '장바구니 담기' 버튼을 눌러봅니다.
  • 버튼 색은 명세대로 파란색이지만, 크기가 너무 작거나 위치가 애매해서 사용자가 누르기 어렵다는 사실을 발견합니다.
  • 결과적으로 이 버튼은 사용자의 "상품을 쉽고 빠르게 장바구니에 담고 싶다"는 근본적인 요구를 충족시키지 못합니다.
  • => 규칙대로 만들었지만, 사용자가 원하는 '올바른' 제품은 아니었던 것입니다.

 

 

Verification과 Validation은 어느 하나가 더 중요한 것이 아니라, 상호 보완적인 관계입니다.

Verification을 통해 개발 과정의 실수를 줄여 엉뚱한 길로 새는 것을 막고,

Validation을 통해 우리가 만든 결과물이 고객이 원하는 목적지에 정확히 도착했음을 보장합니다.

이 두 가지를 모두 충실히 수행할 때 비로소 사용자의 사랑을 받는 '좋은 소프트웨어'가 탄생할 수 있습니다.

 

 

QA 초기 시절, ISTQB 를 공부 중에 가장 많이 헷갈리는 단어 입니다.

제품이 올바르게 만들어 졌는지, 올바른 제품을 만드는 지를 생각하면 명확히 구분 하실 수 있으실 것입니다.

 

그럼 오늘도 현재 또는 미래의 QA 분들에게 도움이 되셨길 바라며...

혹시 궁금하신 내용들은 질문해 주시면 남겨주세요. 다음번 주제로 가져와 보겠습니다. ^^

 

그럼 오늘도 좋은 하루 되세요~