확인(Verification)

확인(Verification)이란

확인(Verification)은 산출물이 앞 단계에서 정한 명세와 설계대로 만들어지고 있는지를 점검하는 활동이다. 흔히 "제대로 만들고 있는가"라는 물음으로 요약되며, 그 판단의 잣대는 사용자의 기대가 아니라 엔지니어가 작성한 설계 명세다.

즉 확인은 결과물을 문서와 대조하는 작업으로, 요구사항 명세서·설계서·인터페이스 정의 같은 기준 문서가 있을 때 비로소 성립한다. 기준 문서가 부실하면 무엇과 대조해야 할지가 흐려져 확인 자체가 형식에 그친다.

따라서 확인의 품질은 앞 단계 명세의 명확성에 직접 묶여 있다.

확인과 검증의 차이

확인은 종종 검증(Validation)과 혼동되지만 두 활동은 보는 방향이 다르다. 확인이 "명세대로 제대로 만들고 있는가"를 묻는다면, 검증은 "애초에 옳은 것을 만들고 있는가"를 묻는다.

확인은 설계 문서를 기준으로 엔지니어가 내부적으로 점검하는 성격이 강하고, 검증은 실제 사용자의 요구와 목적에 비추어 결과물이 쓸모 있는지를 확인하는 성격이 강하다. 명세대로 정확히 구현했더라도 그 명세 자체가 사용자의 진짜 요구와 어긋났다면, 확인은 통과하지만 검증은 실패한다.

두 활동을 한데 묶어 버리면 명세의 결함과 구현의 결함을 구분하지 못해 책임 소재가 흐려진다.

설계 명세가 기준이 된다

확인은 주관적 인상이 아니라 문서화된 기준 위에서 이루어져야 한다. 엔지니어는 구현된 산출물을 요구사항 명세서와 설계 명세에 한 줄씩 대조하며, 명세에 적힌 항목이 빠짐없이 반영되었는지와 명세에 없는 것이 임의로 들어가지 않았는지를 함께 점검한다.

이 대조가 가능하려면 명세가 검증 가능한 형태로 작성되어 있어야 하며, 모호하거나 측정 불가능한 문장은 확인을 무력화한다. 예를 들어 "빠르게 응답한다"는 문장은 확인의 기준이 될 수 없고, 구체적 조건과 수치로 적힌 비기능 요구사항이라야 대조가 성립한다.

명세의 추적성이 확보되어 있으면 어떤 요구가 어디서 구현되었는지를 따라가며 누락을 잡아낼 수 있다.

단계마다 반복되는 활동

확인은 개발이 끝난 뒤 한 번만 하는 검사가 아니라 생명주기 각 단계의 경계마다 반복되는 활동이다. 분석 산출물은 요구와 대조해 확인하고, 설계 산출물은 분석 결과와 대조해 확인하며, 구현 산출물은 설계와 대조해 확인한다.

각 단계가 넘어가기 전에 이전 기준과의 일치를 점검하는 구조이므로, 결함이 다음 단계로 흘러가기 전에 가까운 지점에서 걸러진다. 결함은 발견이 늦어질수록 고치는 비용이 가파르게 커지기 때문에, 단계 경계마다 확인을 거는 것은 후반의 대규모 재작업을 막는 가장 현실적인 방어선이다.

확인을 마지막으로 미루면 누적된 어긋남이 한꺼번에 드러나 일정이 무너진다.

확인이 무력해지는 조건

확인은 기준 문서가 살아 있을 때만 의미가 있다. 명세가 갱신되지 않은 채 구현만 앞서 나가면, 엔지니어는 낡은 기준과 대조하게 되어 통과 도장을 찍어도 실제로는 어긋난 상태가 된다.

또 명세가 모호하게 작성되면 확인하는 사람마다 해석이 달라져 같은 산출물이 통과와 반려를 오간다. 따라서 확인을 제대로 돌리려면 변경 관리가 함께 작동해 명세와 구현이 같은 시점을 가리키도록 유지해야 한다.

확인은 독립된 검사 행위처럼 보이지만, 실제로는 명세·변경 관리·추적성이 함께 갖춰져야 기능하는 활동이다.

확인 결과의 문서화

확인의 결과는 통과 여부만 남기는 것으로 끝나지 않고, 무엇을 어떤 기준으로 대조했고 어떤 항목이 어긋났는지를 기록으로 남겨야 한다. 이 기록은 반려된 항목이 다시 구현되어 돌아왔을 때 재확인의 출발점이 되고, 검수 단계에서 발주 측에 점검 근거를 제시하는 자료가 된다.

또한 반복적으로 같은 유형의 어긋남이 발견된다면 그것은 명세 작성 방식이나 설계 관행에 문제가 있다는 신호이므로, 확인 기록은 다음 프로젝트의 품질 개선에도 쓰인다. 확인을 단순한 합격·불합격 판정으로만 다루면 이런 누적 학습의 기회를 잃는다.