151. 요구사항 확인 및 검증 (V&V, Verification & Validation)

핵심 인사이트 (3줄 요약)

본질: V&V는 소프트웨어 품질 보증(QA)의 절대적 기둥으로, 명세서(문서)나 규칙에 맞게 개발 중인지 확인하는 **검증(Verification)**과, 최종 산출물이 진짜 고객(사용자)의 요구(Needs)를 만족시키는지 확인하는 **확인(Validation)**이라는 두 가지 다른 차원의 테스트 철학이다.

가치: "명세서대로 완벽히 코딩했는데, 정작 고객이 원한 프로그램이 아닌" 끔찍한 IT 업계의 고질병(Validation 실패)을 막고, 요구사항 단계에 숨어있는 논리적 모순과 누락을 코드 한 줄 짜기 전에 잡아내어 재작업(Rework) 비용을 수백 배 아껴준다.

융합: 고전적인 V-모델 아키텍처에서 검증(V)은 왼팔(개발 단계의 리뷰, 단위 테스트)을, 확인(V)은 오른팔(인수 테스트, 알파/베타 테스트)을 담당하며, 현대 애자일에서는 이 두 과정이 2주 단위 스프린트 리뷰와 BDD(행동 주도 개발) 속으로 완전히 녹아들어 동시다발적으로 실행된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: **V&V(Verification and Validation)**는 소프트웨어가 명세된 요구사항을 정확히 충족하는지, 그리고 사용자의 실제 목적을 달성하는지를 평가하는 일련의 활동이다.
- 검증 (Verification): "Are we building the product right?" (제품을 제대로 만들고 있는가?). 개발 과정이 설계서나 표준 규약을 잘 따르고 있는지 평가하는 내부자적 시각.
- 확인 (Validation): "Are we building the right product?" (올바른 제품을 만들고 있는가?). 최종 결과물이 고객의 실제 비즈니스 가치와 요구를 충족하는지 평가하는 외부(고객)적 시각.
필요성: 프로젝트를 하다 보면 개발자들은 억울해한다. "저는 기획자가 준 기획서(명세서)에 적힌 조건 그대로 100% 똑같이 구현(Verification 통과)했는데요?" 하지만 오픈 날 시스템을 본 사장님은 분노한다. "아니, 내가 언제 로그인을 이렇게 복잡하게 해달라고 했어! 당장 다 뜯어고쳐!" (Validation 실패). 문서를 완벽하게 따랐다고 해서 비즈니스가 성공하는 것이 아니다. 문서 자체에 구멍이 있거나 고객의 본심을 담지 못했다면 그 프로젝트는 껍데기뿐인 깡통이다. 과정(문서)의 완벽함과 결과(고객 만족)의 완벽함을 이원화하여 통제할 이중 거름망이 절실히 필요했다.
💡 비유: **검증(Verification)**은 요리사가 주방 벽에 붙은 레시피(명세서)에 적힌 대로 "소금 5g, 간장 2스푼"을 한 치의 오차도 없이 냄비에 넣고 있는지 계량컵으로 확인하는 것입니다. **확인(Validation)**은 그렇게 만들어진 찌개를 식당 홀에 있는 손님(고객)이 한 숟갈 떠먹어보고 "아휴, 내가 원한 얼큰한 맛이 아니네!"라고 평가하는 것입니다. 레시피를 완벽히 따랐어도(검증 성공), 손님 입맛에 안 맞으면(확인 실패) 그 식당은 망합니다.
등장 배경:
1. 폭포수 모델의 대참사: 1년 동안 문서를 쓰고 1년 동안 코딩한 뒤 마지막 날 고객에게 짠! 하고 보여줬는데 엎어지는 끔찍한 참사가 일상이었다.
2. Boehm(보엠)의 정의: 소프트웨어 경제학의 거두 배리 보엠이 Verification과 Validation이라는 철학적 질문표를 제안하며 테스팅의 뼈대를 나눴다.
3. V-모델(V-Model)의 탄생: 폭포수의 한계를 타파하기 위해, 개발을 내려가는 왼쪽 선(V)과 테스트를 올라가는 오른쪽 선(V)을 1:1로 매핑시켜 매 단계마다 깐깐하게 검문(V&V)하는 방어 아키텍처가 전 세계 표준으로 자리 잡았다.

┌─────────────────────────────────────────────────────────────┐
│          검증(Verification) vs 확인(Validation) 딜레마 예시          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [ 고객의 진짜 속마음 ]                                           │
│ "출근할 때 안 막히고 빠르게 이동할 수 있는 탈것을 만들어 줘."             │
│                                                             │
│ [ 기획자의 명세서 (SRS) 작성 ]                                    │
│ "바퀴가 4개 달리고 최고속도 300km/h로 달리는 스포츠카를 개발할 것."        │
│                                                             │
│ 🛠️ [ 개발자 & QA의 행동 ]                                        │
│  - 엔진 스펙을 측정하고, 바퀴 4개를 달고, 300km/h 주행 테스트를 통과함!  │
│  ➔ ✅ 검증 (Verification) 완벽하게 성공! (명세서 100% 충족)           │
│                                                             │
│ 💥 [ 오픈 당일 고객의 반응 ]                                        │
│ 고객: "강남대로 출근길엔 300km 스포츠카는 차가 막혀서 아무 짝에도 쓸모가   │
│       없네. 좁은 길을 쇽쇽 빠져나가는 전동 킥보드가 필요한 거였는데!"       │
│ ➔ ❌ 확인 (Validation) 처참하게 실패! (제품은 쓰레기통으로 감)          │
│                                                             │
│ 🌟 결론: 검증(V)은 명세서(문서)와 제품을 대조하는 행위고,                   │
│    확인(V)은 제품과 고객의 진짜 비즈니스 목적을 대조하는 행위다.               │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] IT 프로젝트에서 흔히 발생하는 '요구사항 왜곡'의 파국을 극명하게 보여준다. 개발자와 QA는 '명세서'가 진리인 줄 알고 검증(Verification)에만 목숨을 건다. 하지만 기획 단계에서 고객의 요구가 왜곡되어 명세서에 잘못 박혀버렸다면, 그 이후의 완벽한 개발은 완벽하게 잘못된 방향으로 달려가는 폭주 기관차일 뿐이다. V&V의 사상은 개발자에게 "문서만 보고 코딩하지 말고, 이 기능이 진짜로 고객의 비즈니스 가치를 창출하는가(Validation)를 개발 중간중간 프로토타입이나 데모(Demo)로 고객에게 던져서 끊임없이 의심하라"는 공학적 경고다.

📢 섹션 요약 비유: 검증(Verification)은 설계도에 적힌 대로 나사를 10번 꽉 조였는지 검사하는 '공장 반장님'의 시선이고, 확인(Validation)은 다 완성된 자동차를 타보고 승차감이 푹신한지 따져보는 '구매자'의 시선입니다. 둘 중 하나라도 통과 못 하면 차는 안 팔립니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 검증 (Verification)의 아키텍처와 도구

"우리는 시스템을 명세서(Spec)에 맞게 올바르게(Right) 만들고 있는가?"

수행 시점: 코드가 완성되기 전, 시스템 생명주기(SDLC)의 앞단과 중간중간 계속해서 일어난다.
수행 주체: 아키텍트, 개발자, 리뷰어, QA 엔지니어 (내부자)
주요 기법 (정적 테스트 위주): 프로그램을 실행(Run)하지 않고 서류를 눈으로 뚫어져라 쳐다보는 깐깐한 서류 심사다.
- 워크스루 (Walkthrough): 작성자가 발표하고 동료들이 자유롭게 피드백하는 캐주얼한 비공식 리뷰.
- 인스펙션 (Inspection): 가장 엄격함. 작성자는 쏙 빠지고, 훈련된 전문 인스펙터들이 체크리스트를 들고 도면/코드의 결함을 찾아내 문서화하는 공식 심사.
- 정적 코드 분석 (Static Analysis): SonarQube 같은 툴이 소스코드를 컴파일하지 않고 텍스트로만 긁어서 보안 취약점이나 코딩 컨벤션 위반을 때려잡음.

2. 확인 (Validation)의 아키텍처와 도구

"우리는 고객이 진짜 원하는 올바른(Right) 시스템을 만들었는가?"

수행 시점: 주로 생명주기(SDLC)의 뒷단, 실제 동작하는 껍데기나 최종 산출물이 나왔을 때 일어난다.
수행 주체: 실제 사용자, 고객, 현업(PO/비즈니스 담당자)
주요 기법 (동적 테스트 위주): 프로그램을 실제로 실행(Execute)하여 화면을 눌러가며 비즈니스 흐름을 체험하는 실전 테스트다.
- 알파 테스트 (Alpha Test): 사용자가 '개발자 환경(회사 내부)'에 와서 통제된 상태로 써보며 버그를 찾음.
- 베타 테스트 (Beta Test): 실제 사용자들에게 앱을 뿌려서, 통제되지 않은 '실제 환경'에서 자유롭게 굴려보며 피드백을 받음.
- 인수 테스트 (Acceptance Test, UAT): 고객이 시스템에 잔금을 치르고 인수(Take-over)할지 말지 최종 결정하기 위해 직접 돌려보는 끝판왕 테스트.

Ⅲ. 융합 비교 및 다각도 분석

딜레마: V-Model의 양날개 (검증과 확인의 매핑)

소프트웨어 공학의 바이블인 **V-모델(V-Model)**은 V&V 철학을 생명주기 다이어그램으로 완벽히 형상화한 작품이다.

좌측 (개발/설계 단계) ➔ 검증(Verification)	우측 (테스트 단계) ➔ 확인(Validation) & 검증	융합의 의미 (Mapping)
1. 요구사항 분석	➔ 인수 테스트 (UAT)	(Validation) 시스템이 사용자의 1번 요구사항(비즈니스 목적)을 달성했는가?
2. 시스템/아키텍처 설계	➔ 시스템 테스트 (System Test)	(Validation & Verification) 서버, DB, 네트워크가 2번 설계도대로 완벽하게 연동되어 하나의 시스템으로 도는가?
3. 상세 설계 (모듈 설계)	➔ 통합 테스트 (Integration Test)	(Verification) 3번 도면대로 A모듈과 B모듈 사이의 API 인터페이스(데이터)가 뻑 안 나고 잘 오가는가?
4. 코딩 (구현)	➔ 단위 테스트 (Unit Test)	(Verification) 4번 명세서대로 함수(Method) 하나하나가 `If-Else` 논리 분기를 예외 없이 통과하는가?

(V자 모양을 상상하라. 왼쪽으로 한 계단씩 깊게 내려갈수록 문서는 구체적이 되고, 오른쪽으로 계단을 하나씩 밟고 올라올 때마다 왼쪽에서 만든 문서(기준)를 잣대로 삼아 맞은편 대각선 테스트를 수행한다).

과목 융합 관점

애자일 (Agile & DevOps): 전통적 V-모델은 1년 뒤에 오른쪽 끝(인수 테스트)에 도달해서야 "고객이 원한 게 이게 아닌데요?"라며 핵폭탄이 터지는 치명적 약점이 있었다. 이를 분쇄한 것이 현대 **애자일의 스프린트 리뷰(Sprint Review)**다. 2주마다 아주 작은 단위로 쪼개어 코드를 짜고, 2주 차 마지막 날 고객을 불러 "이 버튼 눌러보세요. 이거 원하신 거 맞아요?"라고 2주마다 확인(Validation)을 강제한다. 폭포수 시대의 V-모델이 거대한 '빅뱅(Big-bang) V&V'였다면, 현대 애자일은 아주 작은 V-모델 톱니바퀴를 1년에 20바퀴 돌리는 '극단적 미니 V&V 융합'이다.
📢 섹션 요약 비유: V-모델은 옷을 맞출 때, 왼쪽으로 내려가면서 치수를 재고 옷감을 고르는 과정(설계)이고, 오른쪽으로 올라오면서 옷을 가봉해서 핀을 찌르고 입어보는 과정(테스트)입니다. 1년 내내 연락 한 통 없다가 다 만든 양복을 던져주는 게 폭포수(빅뱅 실패)라면, 소매 하나 달 때마다 고객을 불러서 입혀보는(확인) 게 애자일 방식의 수선법입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 동료 리뷰(Walkthrough)의 형식화와 버그 방치: A 기업 개발팀은 매주 금요일 작성한 코드와 설계 문서(DFD, ERD)를 모니터에 띄워놓고 10명이 모여서 1시간 동안 워크스루(Walkthrough) 리뷰 회의를 한다. 하지만 1시간 내내 개발자 한 명이 줄줄 읽기만 하고, 나머지 9명은 하품을 하다가 "네, 수고하셨어요" 하고 서류에 도장만 찍고 해산한다. 다음 달 프로덕션 서버에서 이 문서의 허점 때문에 대형 DB 데드락(Deadlock)이 터졌다.
- 판단: 가장 흔한 정적 검증(Verification) 파괴 안티패턴이다. 워크스루는 훈련되지 않은 눈으로 대충 훑기 때문에 결함 발견율이 30%를 밑돈다. 실무 아키텍트는 핵심 코어 모듈 결제 설계서에 대해서는 반드시 인스펙션(Inspection) 제도를 융합해야 한다. 코드 작성자는 입을 다물게 하고, 훈련된 보안 전문가와 DB 튜너가 '보안 체크리스트', '인덱스 체크리스트'라는 깐깐한 칼날(검증 지표)을 들고 문서의 숨통을 쪼이는 공식적인 감식 절차를 강제해야 런타임 오류를 사전에 폭파시킬 수 있다.
시나리오 — Validation 부재로 인한 B2B 솔루션 사업 철수: 스타트업이 병원용 전자차트(EMR) 솔루션을 만들었다. 뛰어난 엔지니어들이 1년간 기획서에 있는 모든 기능을 세계 최고 속도의 React와 Node.js로 완벽하게 구현(Verification 완료)했다. 시스템 뻗음 한 번 없이 QA 단위/통합 테스트를 100점 맞았다. 하지만 실제 종합병원에 시스템을 깔아주자 의사들이 "클릭을 3번이나 해야 처방전이 나오네? 옛날 텍스트 시스템이 훨씬 편하다!"며 마우스를 집어 던졌고 결국 전면 반품 처리되었다.
- 판단: Verification(개발 명세 검증)은 100점이었으나 Validation(고객 효용 확인)이 0점인 비극이다. 책상물림 기획자가 쓴 가짜 명세서에 속아 넘어간 것이다. 제품 개발 초기에 간호사와 의사 옆에 찰싹 붙어 앉아 그들이 마우스를 몇 번 누르는지 관찰하는 **섀도잉(Shadowing)**이나 뼈대만 있는 껍데기 화면을 눌러보게 하는 **프로토타이핑(Prototyping)**을 통해 끊임없이 Validation을 조기 수행하지 않으면 아무리 코드를 잘 짜도 쓰레기를 양산할 뿐이다.

  ┌─────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: V&V를 융합한 BDD (행동 주도 개발) 파이프라인        │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [ 과거의 단절된 V&V ]                                           │
  │ 기획자(문서작성) ➔ 개발자(코딩/Verification) ➔ QA/고객(Validation) │
  │ 💥 각자의 세계가 끊겨 있어서 막판에 서로 딴소리하며 무너짐.                │
  │                                                             │
  │        ======= [ 모던 아키텍처: BDD (Given-When-Then) ] ========│
  │                                                             │
  │ [ V&V가 하나의 텍스트 파일(Gherkin) 안에서 완벽히 융합됨 ]            │
  │                                                             │
  │ 🧔 고객/기획자의 목소리 (Validation의 잣대):                       │
  │   Feature: 장바구니에서 상품 1개를 지우면 총액이 깎여야 한다.           │
  │                                                             │
  │ 🧑‍💻 개발자/QA의 실행 가능한 명세 (Verification의 잣대):               │
  │   Given 장바구니에 10,000원짜리 사과와 5,000원짜리 바나나가 있다.       │
  │   When  고객이 바나나의 '삭제' 버튼을 누른다.                       │
  │   Then  장바구니 총 결제액은 10,000원으로 갱신되어 화면에 떠야 한다.      │
  │                                                             │
  │ 🌟 실무 효과: 이 영어(한글) 텍스트 파일 1장이 기획자에겐 "고객이 원한 비즈니스│
  │ 시나리오(Validation)"가 되고, 개발자 빌드 서버에선 "정확히 금액이 1만원이│
  │ 나오는지 기계가 돌려보는 테스트 코드(Verification)"로 100% 동기화된다! │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] V&V의 오랜 철학적 숙제는 "문서(확인용)와 코드(검증용)가 따로 노는 이중 관리의 저주"였다. 현대 애자일 생태계는 이를 BDD(Behavior-Driven Development)라는 날카로운 아키텍처로 박살 냈다. 고객이 비즈니스 언어로 적어준 Gherkin 문법 텍스트가, Cucumber 같은 테스트 엔진을 거치면 서버 내부에서 진짜 Java 브라우저 봇(Selenium)을 띄워 삭제 버튼을 누르고 총액이 10,000원인지 수학적으로 비교(Assert)하는 자동화 코드로 작동한다. Validation 잣대와 Verification 잣대가 마침내 물리적으로 하나의 몸(Single Source of Truth)으로 융합된 경이로운 진화다.

도입 체크리스트

기술적: 개발자가 코드를 짜서 Github에 올릴 때마다(Push), Jenkins나 GitHub Actions 파이프라인에서 SonarQube 정적 코드 분석기(Static Verification)와 JUnit 단위 테스트(Unit Verification)가 자동으로 돌아가 품질 게이트(Quality Gate)를 막아서고 있는가?
운영·보안적: 보안 검증 시, 해커가 코드를 어떻게 깰지 예측하는 동적 애플리케이션 보안 테스팅(DAST) 툴이 QA 인프라에 물려 있어서, 실행 중인 앱의 화면 폼(Form)에 강제로 SQL 인젝션과 XSS 스크립트를 수만 번 때려 부어 보안 Validation을 검증하고 있는가?

안티패턴

개발자에게 인수 테스트(UAT) 맡기기: 외주 업체(SI)가 코드를 다 짜놓고 기한이 쪼들리자, "우리가 테스트 스크립트 1,000개 다 눌러서 합격(Pass) 찍어놨으니, 고객님은 그냥 최종 사인만 하세요"라며 서류 뭉치를 들이미는 사기 행각. 단위 테스트와 시스템 테스트(검증)는 개발자가 하는 게 맞지만, **인수 테스트(확인, Validation)**는 절대적으로 현업 비즈니스 로직을 아는 '고객(비개발자)'이 직접 마우스를 잡고 굴려봐야 한다. 개발자 눈에는 예외 처리(NullPointerException) 방어만 보이지, "현장 결재 동선이 꼬이는" 비즈니스 결함은 절대 보이지 않는다.
📢 섹션 요약 비유: 검증(V)은 내가 산 계산기가 "1 더하기 1을 2로 정확하게 출력하는가(기계적 결함 제로)"를 따지는 것이고, 확인(V)은 "내가 지금 사과 개수를 세야 하는데 굳이 복잡한 공학용 계산기가 필요한 게 맞나(목적의 적합성)?"를 고민하는 것입니다. 완벽하게 작동하는 기계라도 쓸데가 없으면 쓰레기입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	V&V 프로세스 무시 (코딩 직행)	체계적 V-Model / BDD 인프라 구축	개선 효과
정량	배포 후(Production) 치명적 비즈니스 버그 폭발	코딩 전 인스펙션으로 설계 단계에서 결함 적발	프로덕션 장애 발생 건수 및 수정 비용 90% 이상 사전 증발
정량	고객 변심으로 시스템 구조 전체 재작업	지속적 프로토타이핑(Early Validation) 융합	요구사항 변경(Scope Creep)에 따른 재작업/폐기 비용 수직 감소
정성	"나는 명세서대로 만들었어!" 소모적 논쟁	검증과 확인의 주체(개발 vs 고객) 명확화	프로젝트 납품 시 고객 인수 거부(Rejection) 사태 완벽 방어

미래 전망

AI 융합 검증 (AI-Augmented V&V): 사람의 눈으로 서류의 오타와 모순을 찾던 리뷰(Walkthrough)의 시대가 종말을 맞고 있다. 기획서 텍스트 1,000장을 ChatGPT에 털어 넣고 "이 요구사항 명세서 안에서 서로 충돌(모순)하거나 예외 처리가 빠진 엣지 케이스(Edge Case)를 찾아내"라고 지시하면, AI가 1분 만에 논리적 허점을 수백 개 찾아내 표로 뱉어낸다. 정적 검증(Static Verification) 영역에서 AI는 이미 인간의 꼼꼼함을 초월했다.
카오스 엔지니어링 (Chaos Engineering)의 Validation 편입: 클라우드 MSA 시대에는 기능 테스트를 넘어서, 넷플릭스 카오스 몽키(Chaos Monkey)처럼 멀쩡히 도는 운영 서버 중 하나를 무작위로 쏴서 죽여버렸을 때, "고객이 화면에서 넷플릭스 영상을 버퍼링 없이 계속 볼 수 있는가(Resilience Validation)?"라는 복원력 테스트 자체가 궁극의 비기능 확인(Validation) 잣대로 떠오르고 있다.

참고 표준

IEEE Std 1012: 소프트웨어 검증 및 확인(Verification and Validation) 프로세스에 관한 국제 표준 가이드라인
ISO/IEC/IEEE 12207: 소프트웨어 수명주기 프로세스 내 V&V 활동의 역할을 정의한 바이블

"정확히 조준되지 않은 활시위는, 화살이 아무리 빠르게 날아가도 과녁을 벗어난다." 소프트웨어 공학에서 코딩의 속도(Velocity)보다 중요한 것은 0점 사격(V&V)이다. 검증(Verification)은 화살이 튼튼하고 깃이 잘 달려있는지를 깐깐하게 점검하여 중간에 부러지지 않게 하는 장인의 돋보기다. 반면 확인(Validation)은 우리가 지금 활시위를 당겨 겨누고 있는 저 방향이, 고객이 돈을 주고 맞춰 달라고 부탁한 진짜 호랑이 과녁이 맞는지를 두 눈 부릅뜨고 확인하는 망원경이다. 눈앞의 코드 에러만 쳐다보는 엔지니어는 화살만 깎고, 시스템 너머의 고객 비즈니스를 바라보는 아키텍트는 과녁을 응시한다. 둘 중 하나라도 눈을 감으면 소프트웨어는 허공으로 날아가 버릴 뿐이다.

📢 섹션 요약 비유: V&V는 수술실의 마지막 점검표입니다. 간호사가 "가위 10개, 메시 5개 수량 맞습니다"라고 기계적으로 세는 것은 **검증(Verification)**입니다. 마취 직전에 의사가 환자 얼굴을 보며 "환자분 성함이 홍길동 맞으시죠? 오늘 맹장 떼러 오신 거 맞죠?"라고 진짜 수술 목적과 사람이 일치하는지 더블 체크하는 것이 **확인(Validation)**입니다. 이 두 개가 합쳐져야만 의료 사고(프로젝트 대실패)가 생기지 않습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
V-모델 (V-Model)	V&V의 철학을 왼쪽 개발 단계(설계)와 오른쪽 테스트 단계(검증)로 1:1 매핑하여 생명주기 전체를 품질 검문소로 만들어버린 클래식 공학의 상징이다.
인수 테스트 (Acceptance Test, UAT)	V&V의 오른쪽 꼭대기 종착지. 개발자가 아닌 돈을 내는 진짜 고객(Customer)이 직접 시스템을 돌려보고 "이거 내가 원한 거 맞아"라고 사인(Validation)하는 최종 관문이다.
단위 테스트 (Unit Test)	V&V의 가장 밑바닥을 받치는 주춧돌. 함수 1개가 `If-Else` 로직을 예외 없이 완벽하게 통과하는지 기계적으로 증명하는 순수한 검증(Verification)의 영역이다.
정적 분석 (Static Analysis)	런타임 환경 없이 SonarQube 같은 기계가 소스코드 텍스트 자체를 뜯어보고 냄새(Code Smell)와 취약점을 박살 내는 극강의 자동화 검증(Verification) 툴이다.
BDD (행동 주도 개발)	고객의 비즈니스 요구어(Validation)와 개발자의 자동화 테스트 코드(Verification)를 `Given-When-Then` 텍스트 하나로 융합시켜 이원화된 딜레마를 박살 낸 애자일 무기다.

👶 어린이를 위한 3줄 비유 설명

내가 레고 블록을 조립할 때 설명서에 그려진 대로 빨간색 블록을 3번 자리에 정확히 꽂았는지 엄마가 채점하는 걸 **'검증(Verification)'**이라고 해요.
하지만 설명서대로 완벽하게 경찰차를 다 만들었는데, 막상 내 동생이 "난 소방차가 갖고 싶었는데?"라며 엉엉 울어버린다면 그건 **'확인(Validation)'**에서 실패한 거예요.
그래서 훌륭한 레고 장인은 설명서대로 잘 조립하는지 계속 쳐다보면서도, 중간중간 동생한테 "너 진짜 경찰차 갖고 싶은 거 맞지?"라고 계속 물어봐야만 한답니다!