검증과 확인

검증과 확인은 만든 소프트웨어가 옳은지 두 방향에서 따지는 일입니다. 검증은 정해 둔 요구대로 만들었는지 봅니다. 확인은 만든 것이 사용자가 바라던 것인지 봅니다. 둘은 서로 다른 잘못을 잡아서 하나로 다른 하나를 대신할 수 없습니다.

쉽고 빠른 이해

검증과 확인은 만든 것을 두 질문으로 따지는 일입니다. 「적어 둔 대로 만들었나」가 검증입니다. 「사용자가 바란 것을 만들었나」가 확인입니다.

둘을 가르는 까닭은 적어 둔 요구사항 자체가 틀릴 수 있어서입니다. 테스트가 전부 통과해도 사용자가 못 쓰는 기능이 나올 수 있습니다.

어떻게 도는가:

사용자가 바라는 것을 요구사항으로 적습니다
만든 것을 요구사항과 맞춰 봅니다. 리뷰와 테스트가 이 일을 합니다
만든 것을 사용자에게 써 보게 해서 바라던 것이 맞는지 묻습니다

둘 다 하지만 무게는 상황에 따라 다릅니다. 요구가 분명하면 검증에, 요구가 흐린 새 제품이면 확인에 품을 더 들입니다.

대가가 있습니다. 같은 물건을 두 기준으로 따지니 품이 듭니다. 확인은 사용자의 시간을 빌려야 합니다. 기계에 다 맡길 수도 없습니다.

상세

맞춤 양복을 맞추는 장면을 떠올려 봅니다. 재단사는 받아 적은 치수표대로 잘랐는지 줄자로 다시 잽니다. 그다음 손님이 입어 보고 자기가 원하던 옷이 맞는지 거울 앞에서 따집니다.

검증과 확인은 소프트웨어를 이렇게 두 번 따져 살피는 일입니다. 영어로는 verification and validation 이라고 합니다. 줄여서 V&V 라고 씁니다.

검증(verification)은 만든 것이 앞서 정해 둔 요구와 설계에 맞는지 따집니다. 확인(validation)은 만든 것이 사용자의 실제 필요에 맞는지 따집니다.

요구사항과 산출물

검증과 확인을 가르려면 무엇을 놓고 맞춰 보는지부터 알아야 합니다. 이 소절은 그 재료가 되는 낱말들을 세웁니다.

요구사항은 소프트웨어가 무엇을 해야 하는지 적어 둔 문장입니다. 「고객 한 명의 최신 주문을 20건까지 돌려준다」 같은 문장 하나가 요구사항 하나입니다.

요구사항을 모은 문서를 요구사항 명세라고 부릅니다. 무엇을 만들지 여럿이 합의하려면 이런 문장이 글로 남아 있어야 합니다.

산출물은 개발 단계마다 나오는 결과물입니다. 설계 문서, 코드, 빌드한 프로그램이 모두 산출물입니다. 검증과 확인이 따지는 대상이 이 산출물입니다.

두 질문

검증과 확인은 흔히 두 질문으로 줄여 부릅니다. 검증은 「제품을 올바르게 만들고 있나」를 묻습니다. 확인은 「올바른 제품을 만들고 있나」를 묻습니다. 낱말 순서만 바뀌었지만 맞춰 보는 상대가 다릅니다.

검증이 맞춰 보는 상대는 문서입니다. 요구사항이나 설계 문서에 적힌 대로 코드가 도는지 봅니다. 기준이 글로 있으니 판정이 분명합니다. 테스트 코드로 짜 두면 기계가 되풀이해 돌립니다.

확인이 맞춰 보는 상대는 사람입니다. 사용자가 이 소프트웨어로 하려던 일을 해낼 수 있는지 봅니다. 그 필요는 문서에 다 적혀 있지 않습니다. 그래서 끝내는 사용자가 써 봐야 판정이 납니다.

아래 표는 두 쪽을 같은 축으로 나란히 놓습니다. 대표 활동에 적힌 이름들은 표 바로 아래에서 풉니다.

	검증	확인
묻는 것	적어 둔 대로 만들었나	바라던 것을 만들었나
맞춰 보는 상대	요구사항 · 설계 문서	사용자의 실제 필요
주로 하는 사람	개발자 · 품질 보증 담당	사용자 · 고객 · 기획
대표 활동	코드 리뷰 · 정적 분석 · 단위 테스트 · 통합 테스트	인수 테스트 · 사용성 테스트 · 베타 테스트
잡아내는 잘못	요구사항과 다르게 짠 코드	요구사항 자체가 틀린 것

검증 쪽의 코드 리뷰와 정적 분석은 프로그램을 돌리지 않습니다. 사람이나 도구가 코드를 읽어 요구사항과 어긋난 곳을 찾습니다. 단위 테스트와 통합 테스트는 코드를 돌려 적어 둔 동작과 맞는지 봅니다.

확인 쪽의 인수 테스트는 사용자가 이 소프트웨어를 받아들일지 정하려고 하는 시험입니다. 사용성 테스트는 사용자가 헤매지 않고 쓸 수 있는지 지켜봅니다. 베타 테스트는 출시 전에 일부 사용자에게 먼저 써 보게 합니다.

단계마다 거는 검증과 처음으로 되짚는 확인

이 소절은 개발이 여러 단계를 거칠 때 검증과 확인이 어디에 걸리는지를 그림 하나로 봅니다.

개발은 사용자의 필요에서 출발합니다. 그 필요는 요구사항으로 적습니다. 요구사항은 설계로 풉니다. 설계는 코드로 옮깁니다.

검증은 이웃한 두 단계 사이에 걸립니다. 설계가 요구사항을 빠짐없이 담았는지, 코드가 설계대로 짜였는지를 봅니다. 확인은 맨 끝과 맨 처음을 잇습니다. 다 만든 소프트웨어를 들고 출발점이던 사용자의 필요로 돌아가 맞춰 봅니다.

flowchart TD
    N["사용자의 필요"] --> R["요구사항"]
    R --> D["설계 문서"]
    D --> C["코드"]
    C --> P["다 만든 소프트웨어"]
    D -.->|검증 · 요구사항을 담았나| R
    C -.->|검증 · 설계대로인가| D
    P -.->|확인 · 필요에 맞나| N

그림에서 검증의 점선은 짧고 확인의 점선은 깁니다. 검증은 한 칸씩 되짚어서 단계 사이의 어긋남을 일찍 잡습니다. 확인은 처음까지 한 번에 되짚어서 요구사항이 애초에 잘못 적힌 것을 잡습니다.

그림은 확인을 끝에서 한 번 하는 꼴로 그렸습니다. 요구가 흐리면 다 만들기 전의 중간 산출물을 들고도 확인합니다. 이 이야기는 아래 「비중을 정하는 기준」에서 이어집니다.

한쪽만 하면 새는 잘못

둘 중 하나를 빼면 무엇이 새는지 주문 목록 API(Application Programming Interface, 응용 프로그램 인터페이스) 한 가지로 따라가 봅니다.

요구사항에 「주문 목록 API 는 고객 한 명의 최신 주문을 20건까지 돌려준다. 주문이 없으면 빈 목록을 돌려준다」라고 적혀 있다고 합시다. 개발자는 이 기능을 짜고 20건이 최신순으로 오는지, 주문이 없을 때 빈 목록이 오는지 테스트합니다. 테스트는 통과합니다. 검증은 여기서 끝납니다.

그런데 이 API 를 쓰는 고객센터 직원은 주문 번호로 한 건을 찾아야 했습니다. 최신 20건만 보이면 일주일 전 주문은 찾을 수 없습니다. 적힌 대로 만들었지만 쓸모가 없습니다. 이것은 검증으로는 못 잡고 확인으로만 잡히는 잘못입니다.

거꾸로 확인만 하면 다른 잘못이 샙니다. 직원이 시연에서 써 보고 만족해도 주문이 하나도 없는 고객을 조회하면 빈 목록 대신 오류가 날 수 있습니다. 시연에서 안 밟은 경우라도 요구사항에는 적혀 있습니다. 요구사항을 한 줄씩 맞춰 보는 검증이 이런 잘못을 잡습니다.

비중을 정하는 기준

둘 다 늘 하지만 어느 쪽에 품을 더 들일지는 상황이 정합니다. 이 소절은 그 비중을 무엇이 가르는지 봅니다.

요구가 분명하고 잘 안 바뀌면 검증에 품을 더 들입니다. HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 프로토콜) 같은 통신 규격을 구현하는 라이브러리가 그렇습니다. 규격 문서가 곧 사용자의 필요라서 문서와 맞춰 보는 일이 대부분을 차지합니다.

요구가 흐린 새 제품이면 확인을 일찍, 자주 합니다. 사용자도 무엇을 원하는지 처음부터 다 말하지 못하기 때문입니다. 그래서 작게 만들어 보여 주고 반응을 보는 짧은 주기로 돕니다. 이렇게 보여 주려고 일부만 만든 시제품을 프로토타입이라고 부릅니다.