소프트웨어 검증 및 확인

두 개의 서로 다른 질문

책마루 온라인 주문 시스템이 완성되어 오픈을 앞두고 있다고 하자. 이 시스템을 최종 점검할 때 사실은 서로 다른 두 가지 질문을 던지게 된다.

• "이 시스템은 배달 가능 여부를 우편번호만으로 3초 안에 판단하는가?" — 요구사항 명세서에 적힌 대로 동작하는지를 묻는 질문이다.
• "그런데 이 요구사항 자체가 손님과 사장님이 정말 원했던 것이 맞는가?" — 애초에 우리가 만들려던 것을 제대로 이해하고 반영했는지를 묻는 질문이다.

이 두 질문은 겉보기엔 비슷해 보이지만 완전히 다른 층위를 다룬다. 소프트웨어 공학은 이 둘을 각각 **검증(verification)**과 **확인(validation)**이라는 이름으로 구분한다. Boehm이 남긴 유명한 대구가 이 차이를 가장 간명하게 요약한다.

확인(validation): 올바른 제품을 만들고 있는가? (Are we building the right product?) 검증(verification): 제품을 올바르게 만들고 있는가? (Are we building the product right?)

확인은 첫 번째 "창조" — 즉 요구사항 분석이 올바르게 이루어졌는지를 점검하는 일이다. 고객의 요구사항을 정확히 이해해 요구사항 명세서(SRS)로 옮기고, 이후 변경이 생기면 그 변경을 적절히 관리하는 것까지 포함한다. 검증은 두 번째 "창조" — 즉 그렇게 이해된 요구사항이 설계, 구현, 시험 단계를 거치며 올바르게 반영되고 있는지를 점검하는 일이다. 요구사항이 설계에, 설계가 구현에 올바로 매핑되고 있는지를 단계마다 추적해서 확인한다.

책마루 예로 다시 정리하면, 확인은 "손님과 사장님이 원한 것이 정말 '우편번호 기반 30분 배달권 자동 판정'이 맞는가"를 검토하는 일이고, 검증은 "그렇게 정의된 요구사항이 설계 문서의 로직에, 그 로직이 실제 코드에 빠짐없이 반영되었는가"를 단계별로 점검하는 일이다.

추적성 — 두 산출물 사이의 끈

확인과 검증을 실제로 수행하려면 서로 다른 단계의 산출물 사이의 관계를 관리하는 능력이 필요하다. 이를 **추적성(traceability)**이라 부른다. 예를 들어 요구사항 분석 단계에서 밝혀진 고객의 요구가 다음 단계 산출물인 설계 문서에 올바로 반영되어 있는지 확인하는 것이 대표적인 추적 활동이다.

추적에는 두 방향이 있다.

• 전방향 추적(forward tracing): 특정 요구사항을 기준으로, 그 요구사항이 라이프 사이클 각 단계의 산출물에 어떻게 반영되었는지를 따라가는 것. 소프트웨어가 요구사항을 빠짐없이 만족하도록 개발되기 위해 반드시 필요하다.
• 역방향 추적(backward tracing): 반대로 특정 산출물(예: 어떤 코드 모듈)에서 출발해 그것이 어떤 요구사항에서 비롯되었는지를 거슬러 올라가는 것. 변경이 요구되어 재시험하는 회귀 테스트(regression test) 같은 작업을 할 때 유용하다.

이 관계를 표로 정리한 것이 **추적 매트릭스(traceability matrix)**다. 책마루 프로젝트를 예로 들면, "우편번호로 배달 가능 여부를 판단한다"는 요구사항 하나를 축으로 삼아, 이것이 어떤 유스케이스로, 어떤 화면 설계로, 어떤 클래스와 테이블로, 어떤 테스트 케이스로 이어지는지를 한 줄에 나란히 적어두는 것이다.

이렇게 해두면 나중에 "이 요구사항이 정말 구현에 다 반영되었는지"(전방향), 혹은 "이 코드가 왜 이렇게 짜여 있는지"(역방향) 둘 다 즉시 답할 수 있다. 예를 들어 DeliveryZoneDAO 클래스를 유지보수하던 개발자가 "이 클래스가 왜 이런 조건문을 갖고 있는지" 궁금해졌을 때, 역방향 추적으로 REQ-05까지 거슬러 올라가면 그 근거를 즉시 확인할 수 있다. 추적 매트릭스가 없으면 이 질문에 답하기 위해 매번 코드와 문서를 처음부터 다시 뒤져야 한다.

검증만 잘하고 확인을 소홀히 하면 벌어지는 일

두 개념의 차이가 그저 학술적인 구분처럼 느껴질 수 있지만, 실무에서는 이 둘 중 하나만 챙기고 다른 하나를 놓치는 실패가 반복해서 일어난다.

검증은 완벽했지만 확인이 부실했던 경우를 생각해보자. 책마루 개발팀이 "배달 가능 지역은 우편번호로 판정한다"는 요구사항을 정확히 코드로 옮기고, 그 코드가 요구사항 명세서와 한 치의 어긋남 없이 동작한다고 하자. 검증 관점에서는 나무랄 데가 없다. 그런데 애초에 이 요구사항 자체가 사장님이 원했던 것과 다르다면? 사장님은 "걸어서 갈 수 있는 거리"를 기준으로 삼고 싶었는데, 분석 단계에서 편의상 우편번호로 대체해버렸다면, 아무리 정확하게 구현해도 오픈 후 "우리 동네인데 왜 배달이 안 되냐"는 항의가 쏟아질 것이다. 이것이 확인의 실패다 — 제품을 올바르게 만들었지만, 애초에 올바른 제품이 아니었던 경우다.

반대로 확인은 잘 됐는데 검증이 부실한 경우도 있다. 요구사항 분석 단계에서 사장님과 여러 차례 논의를 거쳐 "우편번호 기반 판정"이 정말 사장님이 원하는 방식이라는 합의까지 이르렀다고 하자. 확인은 성공이다. 그런데 설계 단계에서 이 로직이 어딘가 누락되어, 실제 코드에는 특정 우편번호 목록이 빠진 채 배포된다면? 검증의 실패다 — 올바른 제품을 만들려 했지만, 실제로는 그렇게 만들어지지 않은 경우다. 두 실패의 원인이 다른 만큼 대응도 다르다. 확인 실패는 사용자와의 소통 부족에서, 검증 실패는 단계 간 산출물 관리 부실에서 비롯된다.

개발 생명주기 단계별 V&V 활동

확인과 검증을 합쳐 **V&V(Verification and Validation)**라 부르며, 이는 개발 생명주기 전반에 걸쳐 수행되는 분석과 점검 프로세스다. 각 단계마다 수행하는 V&V 활동의 성격이 조금씩 다르다.

계획과 요구사항 분석 단계

계획 단계의 V&V 활동은 프로젝트 관리 계획서나 품질 관리 계획서 같은 프로젝트 계획 문서를 평가하고, V&V 프로세스 자체를 확립하는 데 집중한다. 이 단계의 핵심 산출물이 **소프트웨어 검증 및 확인 계획서(SVVP)**다.

요구사항 분석 단계로 넘어가면, V&V 담당자는 개념 문서에 명시된 사용자 필요와 요구사항 명세서(SRS)의 요구사항을 서로 추적하여, SRS가 사용자의 필요를 올바로 반영했는지 확인한다. 이때 추적되지 않는 항목이 발견되면 예외사항으로 기록해 후속 조치가 이루어지도록 한다. 이 활동이 바로 확인(validation)의 핵심이다 — "사용자가 원한 것을 명세서가 제대로 담아냈는가."

설계와 구현 단계

설계 단계에서는 SRS를 바탕으로 소프트웨어 아키텍처, 구성요소(모듈 또는 클래스), 사용자 인터페이스, 데이터베이스 설계가 이루어진다. 이 단계의 V&V는 설계 문서가 요구사항에 맞게 작성되었는지를 검증하는 데 초점을 맞춘다 — 요구사항 분석 단계에서 정한 논리 모델이 설계 단계의 물리 모델로 발전하는 과정에서 누락되거나 잘못 매핑된 요소가 없는지 확인 가능성 분석을 통해 점검한다. 이 시점에 오류를 제거해두면 이후 작성될 코드에서 결함이 최소화된다.

구현 단계에서는 소스 코드가 설계 문서와 코딩 표준을 얼마나 준수하는지가 검증의 대상이다. 원시 코드 평가, 인터페이스 분석과 함께 구성 요소·통합·시스템·수락 시험을 위한 시험 사례와 절차가 이 단계에서 생성된다.

책마루 프로젝트를 예로 들면, "우편번호 기반 배달 판정" 요구사항이 화면 설계서의 DeliveryCheck 화면, 상세 클래스 명세서의 DeliveryZoneDAO 클래스, 테이블 명세서의 t_delivery_zone 테이블로 이어지는 흐름을 추적 매트릭스에 기록해두면, 구현 단계에서 이 항목들이 실제 소스 코드(DeliveryCheck.jsp, DeliveryZoneDAO.java)로 빠짐없이 옮겨졌는지를 검증할 수 있다.

시험, 설치, 운영 및 유지보수 단계

시험 단계의 V&V는 이전 단계에서 작성된 시험 사례와 절차를 기준으로 통합 시험, 시스템 시험, 수락 시험을 실행해 요구사항이 실제로 만족되는지를 보장하는 것이다. 이 시점에 수행하는 확인 기법이 **확인시험(validation testing)**이다 — 만들어진 소프트웨어가 정말 고객이 원하는 것인지, 요구사항을 만족하는지를 입증하는 시험이며, 요구사항 명세서가 그 판정 기준을 제공한다.

설치 및 점검 단계에서는 소프트웨어 산출물이 운영 환경에 온전히 통합되어 설치 패키지 안에 있는지 확인하고(설치 형상 감사), 설치된 소프트웨어가 V&V를 거친 소프트웨어와 일치하는지 검증한다(설치 점검). 이 단계 마지막에 V&V 담당자는 각 생명주기 단계에서 수행된 활동과 결과를 요약한 V&V 최종 보고서를 작성한다.

시스템이 오픈된 뒤 운영 및 유지보수 단계에서도 V&V는 끝나지 않는다. 소프트웨어를 정정하거나 변화하는 요구사항에 대응하는 활동을 검증·확인해야 하며, 이때 SVVP를 개정하고 제안된 변경의 영향력을 평가한다. 이 지점에서 20장에서 다룬 형상통제위원회의 역할과 겹치는 부분이 생긴다 — 고객 요구사항의 변경 관리는 형상관리의 변경 통제와 맞닿아 있다.

요구사항 확인에 쓰이는 기법

프로젝트 초기, 요구사항이 정말 사용자가 원하는 것인지 확인하기 위해 쓰이는 대표적인 기법이 세 가지 있다.

• 시제품 개발(prototyping): 시스템의 초기 버전을 만들어 시험해봄으로써, 개발자와 사용자가 필요한 시스템에 대해 같은 그림을 그리고 있는지 검사하는 방법. 책마루라면 배달 판정 화면의 종이 목업이나 클릭 가능한 프로토타입을 사장님에게 먼저 보여주는 식이다.
• 기술적 검토(technical review): 개발 프로세스 여러 지점에 적용되어 결함과 오류를 찾아 제거하는 데 사용된다. 19장에서 다룬 공식기술검토회가 이 범주에 속한다.
• 시뮬레이션(simulation): 복잡한 문제나 현상을 실제와 비슷한 모형으로 만들어 모의적으로 실험함으로써 특성을 파악하는 기법.

세 기법 모두 공통된 발상을 담고 있다 — 요구사항 명세서라는 문서만 붙들고 "이게 맞겠지"라고 추정하는 대신, 실제로 눈에 보이는 무언가(시제품, 검토 의견, 모의 실행 결과)를 사용자 앞에 내놓고 반응을 확인하라는 것이다. 문서만으로는 걸러지지 않는 오해가 실물 앞에서는 훨씬 빨리 드러난다. 책마루 사장님이 "배달 가능 지역"이라는 말을 들었을 때 머릿속에 그리는 그림과, 개발팀이 우편번호 목록으로 구현한 그림이 서로 다를 수 있다는 전제 위에서, 시제품 하나를 먼저 보여주는 편이 요구사항 문서를 백 번 검토하는 것보다 오해를 빨리 드러낸다.

V&V 계획 — SVVP

V&V 활동이 임기응변으로 흐르지 않으려면 개발 프로세스 초기(계획 단계)에 **소프트웨어 검증 및 확인 계획서(SVVP: Software V&V Plan)**가 수립되고 문서화되어야 한다. 국제 표준으로는 IEEE Standard for Software Verification and Validation Plans(IEEE 1012)가, 국내에는 한국정보통신기술협회(TTA)의 소프트웨어 검증 및 확인 표준이 관련 가이드라인을 제시한다.

SVVP는 각 생명주기 단계별로 어떤 V&V 작업을 수행할지, 어떤 도구와 기법을 쓸지, 결과를 어떻게 문서화할지를 미리 규정한 문서다. 책마루처럼 작은 프로젝트라면 이 계획서가 두툼한 별도 문서일 필요는 없다 — 다만 "요구사항 분석 결과를 사장님에게 어떻게 확인받을 것인가", "설계와 구현이 요구사항과 어긋나지 않는지 누가 언제 점검할 것인가"라는 질문에는 프로젝트 시작 시점에 미리 답을 정해두는 편이 좋다.

핵심 정리

• 확인(validation)은 "올바른 제품을 만들고 있는가"를, 검증(verification)은 "제품을 올바르게 만들고 있는가"를 묻는다 — 서로 다른 질문이며 둘 다 필요하다.
• 추적성은 서로 다른 단계의 산출물 사이의 관계를 관리하는 능력이며, 전방향 추적과 역방향 추적으로 나뉜다.
• V&V 활동은 계획·요구사항 분석·설계·구현·시험·설치·운영유지보수 등 개발 생명주기 전 단계에 걸쳐 수행되며, 각 단계마다 초점이 다르다.
• SVVP는 이런 V&V 활동을 프로젝트 초기에 미리 계획해두는 문서로, IEEE 1012 같은 국제 표준이 지침을 제공한다.

다음 장(22장)에서는 4장에서 개관했던 프로젝트 관리의 10개 지식 영역 중 범위·원가·일정 관리를 구체적인 기법과 함께 깊이 있게 다룬다.