하드웨어에서 Verification와 Validation의 차이점은 무엇일까요?

하드웨어 설계는 때때로 테스트 벤치에서는 완벽해 보일 수 있습니다. MCU는 160MHz에서 안정적으로 동작하고, 센서는 I²C로 통신하며, 전원 공급 장치는 최대 부하에서도 12V를 유지합니다. 하지만 모든 요구사항을 충족하는 제품이라도 실제 사용자에게 전달되면 기대에 못 미칠 수 있습니다.

검증과 타당성 확인(V&V)은 요구사항 충족과 실제 사용 환경에서의 요구 충족 사이의 간극을 다룹니다. 일부 하드웨어 팀은 이 두 용어를 혼동합니다. V&V를 하나의 단계로 취급하거나, 프로토타입이 작동하는 것처럼 보인다는 이유로 둘 중 하나를 건너뛰는 팀은 감사 단계나 제품이 현장에 배치된 이후에 문제를 발견할 수 있습니다.

이 글에서는 하드웨어 개발에서 verification과 validation이 무엇을 의미하는지, 그리고 둘이 어떻게 다른지 설명합니다. 또한 V-Model을 통해 V&V가 요구사항과 어떻게 연결되는지, V&V 계획을 어떻게 수립하는지, 그리고 흔히 발생하는 실수를 어떻게 피할 수 있는지도 다룹니다.

핵심 요약

• Verification은 하드웨어가 정의된 기술 요구사항을 충족하는지 확인합니다. 
• Validation은 완성된 제품이 설계 목적에 맞는 요구를 충족하는지 확인합니다.
• V&V는 초기부터 시작되어야 하며, 하드웨어 개발 전반에 걸쳐 요구사항을 계획된 활동, 승인 기준, 결과, 그리고 이를 뒷받침하는 증거와 연결해야 합니다.

Verification이란?

Verification은 하드웨어가 정의된 요구사항 및 엔지니어링 사양과 일치하는지 확인하는 과정입니다. 즉, 다음 질문에 답합니다: 우리는 제품을 올바르게 만들고 있는가?

Verification의 목적은 가정을 증거로 대체하는 것입니다. 회로가 제대로 동작할 것이라고 추정하는 대신, 팀은 설계 또는 실제 프로토타입을 정의된 요구사항과 비교하고, 이를 충족하는지 여부를 보여주는 증거를 확보합니다.

Verification에는 다음과 같은 활동이 포함될 수 있습니다:

• 요구사항 검토: 요구사항이 명확하고, 일관되며, 달성 가능하고, 추적 가능하며, 검증 가능한지 확인합니다.
• 설계 검토: 회로도, PCB 레이아웃, 기구 도면, 인터페이스를 정의된 요구사항 및 설계 규칙과 비교합니다.
• 해석 및 시뮬레이션: 계산이나 모델을 사용해 열 여유도, 신호 무결성, 타이밍, 전력 소비와 같은 파라미터를 확인합니다.
• 검사: 실제 하드웨어, 치수, 조립 상태, 부품, 연결 상태를 설계 문서와 대조하여 확인합니다.
• 시험 및 측정: 하드웨어를 측정하고 그 결과를 요구 한계값 또는 예상 설계 동작과 비교합니다.

Validation이란?

Validation은 하드웨어가 의도된 용도, 사용자, 그리고 운영 환경에서 실제로 제대로 작동하는지 확인하는 과정입니다. 즉, 다음 질문에 답합니다: 우리는 올바른 제품을 만들고 있는가?

Validation의 주요 목적은 제품이 실제로 해결하도록 설계된 문제를 해결한다는 증거를 제공하는 것입니다. 설계가 모든 기술 요구사항을 충족하더라도, 실제 운용 조건에서 기대한 대로 성능을 내지 못하면 부족할 수 있습니다. Validation은 완전한 시스템이 이해관계자가 실제로 필요로 하는 작업에 적합하다는 확신을 제공합니다.

Validation에는 다음과 같은 활동이 포함될 수 있습니다:

• 요구사항 타당성 확인: 요구사항이 이해관계자의 필요와 제품이 실제 사용 중 맞닥뜨릴 조건을 제대로 반영하는지 확인합니다.
• 시스템 수준 시험: 완전한 제품을 평가하여 모든 요소가 의도대로 함께 동작하는지 확인합니다.
• 사용 사례 시험: 제품이 설계된 작업과 시나리오를 수행할 수 있는지 확인합니다.
• 환경 시험: 현실적인 온도, 습도, 진동, 부하 또는 기타 운용 조건에서 제품을 평가합니다.
• 현장 시험: 의도된 환경에서 하드웨어를 실제로 운용하여 실험실에서는 드러나지 않을 수 있는 문제를 찾아냅니다.
• 사용자 평가: 대표 사용자들이 제품을 사용해 보게 하고, 실제 작업 흐름과 요구를 지원하는지 확인합니다.

하드웨어 개발 프로세스에서의 verification과 validation.

Verification과 Validation의 차이

V&V는 시험, 측정, 검사, 해석과 같은 동일한 엔지니어링 도구를 사용하는 경우가 많습니다. 차이는 그 결과로 무엇을 입증하려는가에 있습니다.

예를 들어, 열 챔버 시험은 제품이 명시된 −20°C~60°C 범위에서 동작함을 verification할 수 있습니다. 반면 validation은 그 범위가 실제 요구와 맞는지를 묻습니다. 제품이 햇빛에 노출되는 인클로저에 설치되어 내부 온도가 75°C에 도달한다면, verification은 통과해도 실제 사용에서는 실패할 수 있습니다. 동일한 챔버도 완성된 제품이 현장에서 겪을 것으로 예상되는 온도 프로파일로 시험을 수행하면 validation을 지원할 수 있습니다.

Verification은 일반적으로 정의된 요구사항에 대해 더 직접적인 합격/불합격 결과를 제공하며, 개별 요구사항, 설계, 또는 하드웨어 요소에 적용할 수 있습니다. Validation은 통합된 시스템을 더 넓은 관점에서 보고, 그 전체 동작이 의도된 용도에 대해 수용 가능한지를 평가합니다.

요구사항 중심 프로세스에서 verification은 개별 기술 요구사항이 충족되었다는 증거를 축적합니다. 그리고 validation은 완성된 제품이 실제 운용 조건에서 이해관계자의 요구를 충족하는지 확인하며, 요구사항 자체가 불완전하거나 잘못되었음을 드러낼 수도 있습니다.

V&V는 V-Model에 어떻게 들어맞는가

V-Model은 하드웨어 개발 프로젝트 전반에서 V&V를 어떻게 구성할지 보여줍니다.

V-Model은 시스템 수명주기를 V자 형태로 나타냅니다. 왼쪽은 이해관계자의 요구와 기대에서 시작해 이를 시스템 및 서브시스템 요구사항으로 바꾸고, 다시 아키텍처와 상세 설계로 구체화합니다. V의 바닥은 구현 단계입니다. 오른쪽은 통합 과정을 거쳐 다시 위로 올라가며, 부품, 서브시스템, 완성 제품 수준에서 시험이 수행됩니다.

시스템 엔지니어링 프로세스의 V-Model.

왼쪽의 각 수준은 오른쪽의 시험 수준과 짝을 이루며, 이러한 대응 관계가 추적성을 만들어 냅니다. 각 요구사항은 이를 확인하는 V&V 활동 및 증거와 연결되며, 팀은 설계가 진행 중일 때 이미 그 활동을 계획합니다. 

예를 들어, 12V 입력이 최대 부하에서 ±5% 이내를 유지해야 한다는 요구사항은 여러 수준에서 확인할 수 있습니다. 회로도상의 부품 정격 확인, 보드의 전력 시뮬레이션, 그리고 조립된 제품에서의 측정이 그 예입니다.

이 구조 안에서 V&V는 서로 다른 역할을 합니다:

• Verification은 각 수준에서 구축된 결과물이 왼쪽에 정의된 해당 요구사항 및 설계와 일치하는지 확인합니다. 검토, 해석, 시뮬레이션은 왼쪽에서 시작되고, 시험과 측정은 오른쪽을 따라 진행됩니다.
• Validation은 좌측 상단의 이해관계자 요구를 기준으로 확인합니다. 이는 먼저 요구사항이 그 필요와 맞는지 확인하는 것에서 시작하고, 우측 상단에서 시스템 수준 점검으로 다시 나타납니다. 즉, 완성된 제품이 이해관계자의 요구와 의도된 용도를 충족하는가를 묻는 것입니다.

V&V 계획은 어떻게 수립하는가

하드웨어가 시험 단계에 도달할 무렵이면, 팀은 이미 무엇을 확인할지, 그것이 어떤 요구사항과 연결되는지, 결과를 어떻게 판단할지, 그리고 어떤 증거를 확보해야 하는지를 알고 있어야 합니다. V&V 계획은 이러한 결정을 하나의 문서로 정리합니다.

일반적으로 V&V 계획은 여섯 가지 결정을 포함합니다:

• 범위 정의: 계획이 어떤 제품, 서브시스템, 또는 하드웨어 기능을 다루는지, 무엇이 범위 밖인지, 그리고 위험도를 기준으로 V&V 노력을 어디에 우선 투입할지 결정합니다.
• V&V 활동을 요구사항과 연결: 기술 요구사항은 verification 활동에, 이해관계자 요구는 validation 활동에 연결합니다. 그러면 각각이 증거로 이어지는 명확한 경로를 갖게 됩니다.
• 방법 선택: 각 요구사항을 검사, 해석, 입증, 시험 또는 다른 적절한 방법으로 어떻게 verification할지, 그리고 각 이해관계자 요구를 사용 사례 시험, 환경 시험, 사용자 평가 또는 현장 시험으로 어떻게 validation할지 결정합니다.
• 조건 및 승인 기준 정의: 하드웨어 구성, 운용 조건, 장비, 그리고 해당 활동의 합격 또는 불합격을 결정하는 측정 가능한 결과를 명시합니다.
• 누가 무엇을 언제 할지 계획: 책임, 필요한 자원, 일정을 지정하고, 각 활동을 프로토타입, EVT, DVT, PVT 빌드와 같은 적절한 하드웨어 개발 단계에 맞춥니다.
• 결과와 증거를 어떻게 확보할지 결정: 각 결과를 어떻게 기록하고 이를 뒷받침하는 증거와 어떻게 연결할지, 그리고 설계 변경 후 어떤 활동을 반복해야 하는지 정의합니다.

흔한 함정 및 이를 피하는 방법

소프트웨어 버그는 업데이트로 수정할 수 있는 경우가 많지만, 하드웨어 설계의 문제는 보드가 제작되기 전에 수정하는 것이 가장 쉽습니다. 이러한 문제 중 상당수는 요구사항을 작성하는 방식과 V&V를 계획하는 방식에서 시작됩니다.

아래 표는 흔한 V&V 함정과 이를 방지하는 데 도움이 되는 모범 사례를 보여줍니다.

V&V의 이점

개발 후반의 하드웨어 변경은 소프트웨어 변경보다 비용이 더 많이 드는 경향이 있습니다. 보드 재설계, 금형 변경, 또는 인증 시험 실패는 실제로 시간과 예산을 소모하며, 이미 출하된 장치의 하드웨어는 패치하기가 어렵습니다. 이 때문에 하드웨어 개발에서 검증과 타당성 확인은 특히 중요합니다. 두 가지를 함께 사용하면 팀은 네 가지 주요 이점을 얻을 수 있습니다:

• 문제의 조기 발견: 리뷰, 시뮬레이션, 초기 프로토타입을 통해 요구사항의 공백, 설계 오류, 누락 사항을 드러낼 수 있습니다. 이 단계에서의 수정은 대개 사양서나 회로도의 변경으로 끝납니다.
• 각 요구사항에 대한 증거: 검증은 모든 요구사항을 결과와 연결하므로, 팀은 무엇을 어떤 방식으로 확인했고 결과가 어땠는지 보여줄 수 있습니다. 이러한 증거는 규정 준수에도 도움이 되며, 의료기기와 같은 규제 대상 하드웨어는 일반적으로 설계 관리의 일부로 이를 요구합니다.
• 실제 사용 환경과의 적합성: 타당성 확인은 완성된 제품 전체를 사용 환경, 사용자, 작업 맥락에 비추어 평가합니다. 이를 통해 센서 드리프트나 햇빛 아래에서의 디스플레이 눈부심처럼, 요구사항별 점검만으로는 놓칠 수 있는 문제까지 다룰 수 있습니다.
• 다음 개발 주기를 위한 입력: 측정된 여유도와 고장 분석 결과는 설계 변경, 향후 개정, 그리고 차세대 제품 개발에 방향을 제시합니다. 또한 어떤 요구사항을 더 엄격하게 하거나 완화해야 하는지도 보여줍니다.

검증 및 타당성 확인 관리를 위한 소프트웨어 도구

하드웨어 개발에는 많은 요구사항과 시험 결과가 수반되며, 이를 프로젝트 전반에 걸쳐 수작업으로 추적하는 것은 어려울 수 있습니다. 그 결과 팀은 다음과 같이 흩어진 파일과 서로 연결되지 않은 도구들의 조합에 의존하게 될 수 있습니다:

• 스프레드시트와 문서: 요구사항과 테스트 케이스가 제한적인 소규모 프로젝트에는 실용적입니다. 하지만 V&V 범위가 커질수록 추적성과 감사 대응 상태를 유지하려면 수작업 관리가 필요해지고, 기록 간 동기화가 어긋날 수 있습니다.
• 이슈 추적 도구(예: Jira, GitHub): 이러한 도구는 링크, 필드, 태그를 통해 V&V 작업을 정리하고 관련 항목을 연결하도록 조정할 수 있습니다. 하지만 요구사항 추적성과 완전한 V&V 커버리지를 유지하려면 대개 추가 설정과 맞춤형 플러그인이 필요합니다.
• 전용 요구사항 관리 도구: 요구사항 구조화와 추적성을 위해 설계되었습니다. 하지만 도구에 따라 테스트 계획 수립과 증거 수집을 위해 별도 모듈이나 외부 테스트 도구와의 연동이 필요할 수 있습니다. 

공유 작업 공간에서 요구사항과 함께 V&V 활동을 계획하고 추적하려는 팀에게, Requirements Portal은 요구사항을 검증 계획, 테스트 실행, 증거, 변경 이력과 연결해 줍니다. 이를 통해 팀은 무엇이 이미 검증되었고 무엇에 아직 주의가 필요한지 확인할 수 있습니다.

결론 및 다음 단계

요약하면, 검증은 하드웨어가 사양을 충족한다는 것을 입증하고, 타당성 확인은 그것이 실제로 사용자에게 제대로 작동한다는 것을 입증합니다. 이를 제대로 수행하려면 V&V는 마지막 점검표에 그쳐서는 안 됩니다. 제품 개발 프로세스의 첫날부터 내재화되어야 합니다.

V&V 프레임워크에 대한 이해를 더 깊게 하고 싶다면, 다음 자료들이 유용합니다:

• NASA Systems Engineering Handbook은 우주급 하드웨어 제품의 V&V를 계획하고 수행하는 데 실질적인 지침을 제공합니다.
• Guide to the Systems Engineering Body of Knowledge (SEBoK)는 V&V에 대한 보다 폭넓은 시스템 엔지니어링 관점을 제공합니다.
• INCOSE V&V Across Product Lifecycle는 다양한 생애주기 단계에서의 V&V, V-모델, V&V 방법, 테스트 케이스, 성공 기준을 다룹니다.

이론에서 실무로 옮길 준비가 되었다면, Requirements Portal을 사용해 테스트 케이스를 요구사항 및 전자 설계와 연결하고, 커버리지를 추적하며, 엔지니어링 증거를 수집해 보세요.

자주 묻는 질문

Verification은 Validation과 같은가요?

아니요. Verification은 하드웨어가 정의된 요구사항을 충족하는지 확인합니다. Validation은 요구사항과 제품이 실제 사용에서 이해관계자의 필요를 반영하는지 확인합니다.

Verification과 Validation 중 무엇이 먼저인가요?

둘 다 초기에 계획되어야 하며, 어느 하나도 단일 단계로 끝나는 활동이 아닙니다. Verification은 설계가 진행됨에 따라 리뷰, 해석, 시뮬레이션으로 시작됩니다. Validation은 요구사항이 이해관계자의 필요와 맞는지 확인하는 것에서 시작하며, 통합된 제품의 형태가 갖춰질수록 그 비중이 커집니다.

흔한 V&V 방법에는 어떤 것들이 있나요?

일반적인 V&V 방법에는 리뷰, 검사, 해석, 시뮬레이션, 시연, 시험이 포함됩니다. 동일한 방법이라도 정의된 요구사항을 확인하는지, 아니면 의도된 사용 맥락에서 제품을 평가하는지에 따라 Verification 또는 Validation 모두를 지원할 수 있습니다.