396. 확인 (Validation) - 올바른 제품을 만들었는가
⚠️ 이 문서는 소프트웨어 테스팅의 양대 산맥 중 하나로, "설계도대로 완벽하게 코딩했는가(Verification)"를 넘어서, "그렇게 만든 제품이 진짜로 고객이 원하던 그 제품이 맞는가?"를 최종적으로 증명하는 실행 기반 테스트인 '확인(Validation)'을 다룹니다.
핵심 인사이트 (3줄 요약)
- 본질: 확인(Validation)은 완성된 소프트웨어를 직접 실행(Dynamic Testing)해 보면서, 원래 고객이 요구했던 비즈니스 목적과 사용자 요구사항을 100% 충족하는지 최종 평가하는 과정이다. (Are we building the right product?)
- 가치: 아무리 버그 하나 없이 완벽하게 짜인 코드라도, 애초에 고객이 원한 기능이 아니라면 쓸모가 없다. Validation은 이 **'요구사항의 본질적 오류(오류 부재의 궤변)'**를 막아내는 최후의 방어선이다.
- 기술 체계: 주로 개발의 후반부에 진행되며 시스템 테스트(System Test), 인수 테스트(Acceptance Test), 알파/베타 테스트, 블랙박스 테스트(Black-box Test) 기법들이 Validation의 영역에 속한다.
Ⅰ. 개요: 완벽한 설계도의 함정 (Context & Necessity)
건축가가 집을 짓는다. 도면에 10cm 오차도 없이 벽돌을 쌓았고(Verification 완료), 페인트도 완벽하게 칠했다. 하지만 주인이 와서 이렇게 말한다. "어? 저는 한옥을 지어달라고 했는데요?"
소프트웨어 공학에서도 똑같은 비극이 일어난다. 개발자들은 스펙 명세서(SRS)에 적힌 대로 완벽하게 코드를 짜고(Verification), 단위 테스트도 100% 통과시켰다. 하지만 실제로 고객이 프로그램을 돌려보더니 "이거 제가 원하던 기능이 아니에요. 너무 불편해서 못 쓰겠어요"라고 한다면 그 프로젝트는 실패한 것이다.
그래서 소프트웨어 공학의 아버지 배리 보임(Barry Boehm)은 테스팅을 두 가지 질문으로 분리했다.
- Verification (검증): "우리가 제품을 올바르게 만들고 있는가?" (설계도대로 짰나? 꼼꼼히 확인)
- Validation (확인): "우리가 올바른 제품을 만들었는가?" (애초에 그 설계도가 고객이 원하던 게 맞나? 실행해 봐!)
📢 섹션 요약 비유: 검증(Verification)이 "레시피에 적힌 대로 소금을 정확히 10g 넣었는가?"를 저울로 재보는 과정이라면, 확인(Validation)은 다 만들어진 요리를 손님에게 직접 먹여보고 "이 요리가 진짜로 손님이 먹고 싶어 하던 찌개가 맞습니까?"라고 물어보는 과정입니다.
Ⅱ. 확인(Validation)의 핵심 특징
확인 과정은 개발자가 코드를 눈으로 훑어보는 '정적 분석'이 아니다. 진짜 프로그램에 전원을 넣고 돌려보는 '동적 분석'이다.
1. 대상: 완성된 소프트웨어 (실행 환경)
- 리뷰(Review)나 인스펙션(Inspection) 단계는 이미 끝났다.
- Validation은 컴파일이 완료되고 실제 구동 가능한 프로그램(실행 파일, 웹 서버 등)을 대상으로 이루어진다.
2. 기법: 동적 테스팅 및 블랙박스 테스트
- 소스 코드 내부가 어떻게 돌아가는지는 알 바가 아니다. (블랙박스)
- 오직 입력(Input)을 넣었을 때, 고객이 기대하는 올바른 출력(Output)과 화면(UI)이 나오는지만을 집중적으로 테스트한다.
3. 참여자: 고객 및 최종 사용자 (End User)
- Verification이 개발자와 QA 엔지니어들끼리의 싸움이라면, Validation은 고객이 직접 참여해야 의미가 완성된다.
- 특히 UAT(User Acceptance Testing, 사용자 인수 테스트)가 가장 대표적인 Validation 활동이다.
┌───────────────────────────────────────────────────────────────────────────────────────────┐
│ 검증(Verification) vs 확인(Validation) 비교 요약 표 │
├───────────────────────────────────────────────────────────────────────────────────────────┤
│ 특징 │ Verification (검증) │ Validation (확인) │
│────────────┼───────────────────────────────┼──────────────────────────── │
│ 철학적 질문│ Are we building the │ Are we building the │
│ │ product right? (제대로 만드나?)│ right product? (맞는 제품인가?) │
│────────────┼───────────────────────────────┼──────────────────────────── │
│ 평가 기준 │ 설계 명세서 (Design Spec) │ 사용자 요구사항 (Requirements) │
│────────────┼───────────────────────────────┼──────────────────────────── │
│ 수행 방법 │ 정적 테스트 (리뷰, 인스펙션, 워크스루)│ 동적 테스트 (실행, 블랙박스 테스트) │
│────────────┼───────────────────────────────┼──────────────────────────── │
│ 주요 단계 │ 요구분석, 설계, 코딩 단계 │ 시스템 테스트, 인수 테스트 단계 │
└───────────────────────────────────────────────────────────────────────────────────────────┘
Ⅲ. 확인(Validation)을 위한 대표적 테스트 종류
1. 시스템 테스트 (System Test)
개발팀이 자체적으로 만든 시스템이 완전한 환경(OS, 하드웨어) 위에서 정상적으로 돌아가는지, 비기능적 요구사항(성능 1초 이내 응답, 동시 접속 1만 명)을 만족하는지 확인한다.
2. 인수 테스트 (Acceptance Test)
고객이 프로젝트의 대금을 지불(인수)하기 직전에, "내가 원했던 기능이 다 돌아가나?"를 최종적으로 확인하는 테스트.
- 알파 테스트 (Alpha Test): 개발사 내부 통제 환경에서, 고객 측 대표자가 개발자와 함께 돌려보는 테스트.
- 베타 테스트 (Beta Test): 불특정 다수의 실제 사용자에게 프로그램을 던져주고, 그들의 실제 환경에서 돌려보며 버그나 불만 사항을 수집하는 테스트. (게임 회사들의 오픈 베타 서비스)
Ⅳ. 결론
"스펙(Spec)의 완벽함이 비즈니스의 완벽함을 보장하지 않는다." 개발자들은 흔히 "명세서대로 다 짰으니 내 책임은 끝났다"고 말한다 (Verification 중심적 사고). 하지만 소프트웨어의 진정한 가치는 그 코드가 얼마나 우아한가가 아니라, 사용자의 삶과 비즈니스 문제를 실제로 해결해 주는가에 있다. 확인(Validation)은 책상머리에서의 설계가 현실의 차가운 시장과 만나는 충돌 테스트(Crash Test)이며, 아무리 늦더라도 반드시 거쳐야 하는 개발 생명주기의 대미를 장식하는 핵심 관문이다.
📌 관련 개념 맵
- 대척점 개념: 검증 (Verification - Are we building the product right?)
- 테스트 기법: 동적 테스트 (Dynamic Testing), 블랙박스 테스트 (Black-box Testing)
- 테스트 단계: 인수 테스트 (UAT, Alpha/Beta), 시스템 테스트
- 개발 방법론 모델: V-모델 (V-Model - 요구사항 분석 단계와 인수 테스트 단계가 매핑됨)
👶 어린이를 위한 3줄 비유 설명
- 로봇 공장에 장난감 로봇을 주문했어요. 공장 사람들은 도면(설계도)을 보고 "나사 100개, 톱니바퀴 50개 정확히 끼웠어!"라고 확인했어요. 이건 **검증(Verification)**이에요.
- 드디어 로봇이 배달 왔어요! 전원을 켜고 로봇을 움직여 보면서, "내가 진짜 원하던 빨간색 총 쏘는 로봇이 맞나?" 직접 가지고 놀아보는 것이 바로 **확인(Validation)**이랍니다.
- 도면대로 완벽하게 만들었어도, 내가 원하던 로봇이 아니라 엉뚱한 청소 로봇이라면 이 공장의 확인(Validation)은 실패한 거예요!