Validation vs Verification · Validation vs Verification

“고객이 확인하는 Validation, 엔지니어가 검토하는 Verification. 검수 분쟁의 핵심 구분.”

두 질문의 차이

Verification(확인)과 Validation(검증)은 번역어가 비슷해 자주 뒤섞이지만, 던지는 질문이 근본적으로 다르다. Verification은 '우리가 제품을 올바르게 만들었는가'를 묻는다.

즉 정해진 명세와 설계를 정확히 따랐는지 검토하는 활동이다. Validation은 '우리가 올바른 제품을 만들었는가'를 묻는다.

즉 그 결과물이 고객의 실제 요구와 사용 맥락을 충족하는지를 확인하는 활동이다. 한쪽은 명세 준수의 문제이고, 다른 한쪽은 목적 부합의 문제다.

주체와 기준으로 본 두 활동

Verification은 주로 개발 조직 내부에서 이루어진다. 설계 검토, 코드 리뷰, 단위·통합 시험처럼 명세서를 기준 삼아 산출물이 규격에 맞는지 따지는 작업이며, 외부 사용자 없이도 수행할 수 있다.

Validation은 최종 사용자나 발주 고객의 관점이 개입한다. 만들어진 기능이 규격대로 동작하더라도, 정작 현업의 업무를 제대로 지원하지 못하면 Validation에서 실패한다.

그래서 Verification은 엔지니어가 검토하는 영역, Validation은 고객이 확인하는 영역으로 흔히 나뉜다.

생명주기상 Verification은 각 단계의 산출물이 나올 때마다 그 단계 안에서 반복적으로 수행된다. 요구사항 명세서가 설계로, 설계가 코드로 옮겨갈 때마다 앞 단계와의 정합성을 점검하는 식이다.

Validation은 상대적으로 뒤쪽, 사용자가 실제로 결과물을 마주하는 인수·검수 국면에서 비중이 커진다. 다만 Validation을 끝에만 몰아 두면 초기 가정의 오류를 늦게 발견하므로, 성숙한 조직은 프로토타입이나 중간 데모로 검증 활동을 앞당겨 분산한다.

확인과 검증의 핵심 대비

검수 단계의 갈등은 대개 이 두 개념의 혼동에서 비롯된다. 수행사는 명세대로 만들었음을 근거로 완료를 주장하고(Verification 관점), 발주사는 실제 업무에 쓸 수 없다며 미완을 주장한다(Validation 관점).

양측 모두 자기 기준에서는 옳기에 합의가 어렵다. 이 충돌을 줄이는 길은 요구사항 명세서를 가능한 한 검증 가능한 형태로 다듬어 두는 것이다.

'사용하기 편할 것' 같은 모호한 문장은 Validation 분쟁의 씨앗이 되므로, 무엇으로 충족을 판정할지 합의된 기준을 명세에 미리 박아 둬야 한다.

두 활동의 품질은 결국 요구사항 명세서의 작성 수준에 좌우된다. 명세가 측정 가능하고 판정 기준이 명확하면 Verification은 기계적으로 확인되고, Validation도 객관적 합의에 이르기 쉽다.

반대로 명세가 추상적이면 양쪽 모두 주관적 해석에 휘둘린다. 그래서 분석·설계 단계에서 각 요구사항에 '무엇을 어떻게 측정해 합격으로 볼 것인가'라는 수용 기준을 함께 정의하는 것이 분쟁 예방의 핵심이다.

좋은 명세서는 그 자체로 검증 절차의 절반을 미리 정해 둔 문서다.

Verification과 Validation은 어느 한쪽으로 다른 쪽을 대체할 수 없다. 명세를 완벽히 준수해도 그 명세가 고객 요구를 잘못 옮겼다면 결과물은 쓸모를 잃는다.

반대로 고객 만족만 좇아 명세 검토를 건너뛰면 품질과 책임 추적이 흔들린다. 두 활동을 단계마다 짝지어 운용해야 '올바르게 만들면서 올바른 것을 만드는' 균형이 성립한다.

검수 분쟁을 줄이려는 PM이라면 이 구분을 팀과 고객 모두에게 명확히 공유하고, 각 요구사항이 어느 활동으로 어떻게 판정되는지를 사전에 정렬해 둬야 한다.