해석 결과와 시험 결과가 다르면 가장 먼저 “어느 쪽이 틀렸는가”를 결정하고 싶어진다. 하지만 Validation Engineering에서는 차이를 곧바로 오류로 판단하기보다, 무엇을 같은 조건에서 비교하고 있는지부터 확인하는 편이 중요하다.

이 글에서는 비교 정의를 고정한 뒤 verification, 입력·경계조건, 수치해, 측정 불확실성, 시험 셋업과 시간 기준을 차례로 점검하면서 해석값과 시험값의 차이를 좁혀 가는 실무 흐름을 정리한다.

차이가 보이면 먼저 비교의 정의부터 고정한다

해석값과 시험값이 다르다고 해서 해석 또는 실험 한쪽을 곧바로 정답·오답으로 분류할 수는 없다. simulation은 특정 **사용 목적(intended use)**을 위해 구성한 모델이므로, 첫 단계는 무엇을 비교해 어떤 의사결정에 쓸지 고정하는 일이다. [1]

프로젝트의 사용 목적과 시험·해석 방식에 맞춰 비교 조건을 먼저 정리한다. 물리량과 단위, 부호 규약, 좌표계, 비교 위치·영역, 시간 구간과 시간 기준 등을 기록하고, 계측 위치와 해석 결과를 추출한 위치가 서로 대응하는지도 확인한다. 시간 이력을 비교한다면 시험과 해석의 동기화 방법과 시간 기준 역시 함께 정리한다. 가정, 경계조건, 계측, 시간 기준, 시험 셋업은 결과 차이와 함께 검토할 항목이다.

Verification과 validation은 다른 질문에 답한다

Verification은 개념 모델과 방정식이 코드와 수치해에 올바르게 구현·해결됐는지 확인하는 과정이다. 반면 validation은 의도한 사용 목적에서 계산 모델이 현실을 얼마나 정확히 나타내는지 평가한다. [2]

따라서 solver가 안정적으로 계산을 끝냈다는 사실만으로 현실 재현성이 입증되지는 않는다. 반대로 시험과 차이가 난다는 사실만으로 구현 오류라고 단정할 수도 없다. 수치적 신뢰성의 증거와 현실 적합성의 증거를 분리해서 살펴야 원인 진단이 흐려지지 않는다.

결과 보기 전에 지표와 판정 요구사항을 정한다

평균값, 최대값, 시간 이력, 공간 분포 중 무엇이 사용 목적에 중요한지 먼저 정한다. 이어 그 지표를 어떤 판정 요구사항(acceptance requirement)과 연결할지 문서화한다. 비교 지표는 실험 불확실성, 수치 불확실성, 입력 불확실성과 분리해 해석해야 한다. [1]

오차율 하나는 유용한 요약값일 수 있지만, 그 자체가 보편적인 합격 판정은 아니다. 제공 자료에는 모든 물리 분야에 적용할 단일 허용오차나 합격 임계값이 없다. 따라서 기준은 프로젝트의 사용 목적과 판정 요구사항에 맞춰 사전에 정해야 한다. [1]

1차 점검: 입력과 경계조건이 같은 물리를 가리키는가

입력·경계조건부터 계측·동기화·모델 불확실성까지 이어지는 검증 문제 해결 흐름
비교 정의를 고정한 뒤 해석과 실험의 증거 사슬을 단계별로 점검한다.

모델 가정, 입력 데이터의 출처, 경계조건, 초기조건, 물성값, 시험 조건을 서로 대응시켜 확인한다. 특히 해석에 넣은 값이 시험에서 실제로 부여하거나 관측한 조건인지, 값의 적용 위치와 시간 기준이 일치하는지 확인한다. 가정과 경계조건은 예측값과 측정값을 비교할 때 함께 검토해야 한다.

입력값의 불확실성은 실험 및 수치 불확실성과 별개로 비교 결과에 영향을 줄 수 있다. [1] 다만 어떤 입력을 먼저 수정할지, 허용 범위를 얼마로 둘지는 문제와 사용 목적에 따라 달라진다.

아래 workflow에 나타난 입력·경계조건, 수치 설정, 계측·동기화·셋업 항목은 차이의 원인을 좁힐 때 확인하는 주요 범주이며, 모든 프로젝트에서 반드시 하나의 고정된 선후 순서로만 진행해야 한다는 뜻은 아니다.

2차 점검: mesh·이산화·solver를 validation 결론과 섞지 않는다

mesh, 시간·공간 이산화, solver 설정과 수렴 상태는 수치해가 신뢰할 만한지 확인하는 verification 측 증거로 관리한다. 수치 불확실성 역시 실험·입력 불확실성과 구분해 비교 지표를 읽어야 한다. [2] [1]

여기서 중요한 것은 모든 해석에 동일한 수렴값이나 mesh 판정법을 적용하는 것이 아니다. 사용하는 코드, 물리 문제, 사용 목적에 맞춘 verification 계획을 세우고, 변경한 조건과 관측한 결과를 남기는 편이 타당하다.

3차 점검: 측정 불확실성과 셋업·시간 기준·모델 가정을 분리한다

측정값은 자동으로 절대적 정답이 아니다. 측정 결과에는 불확실성 평가가 필요하며, 계측기 지시는 교정, 측정 모델, 반복성, 환경 등 여러 요소의 영향을 받을 수 있다. [3]

따라서 교정 상태, 측정 모델, 반복 측정 정보, 환경 조건, 센서 위치, 데이터 취득과 동기화 방식을 비교 기록에 포함한다. 시험 셋업의 교란 가능성도 별도의 원인 후보로 둔다. 이렇게 하면 관측된 차이를 해석 모델의 문제 하나로 성급하게 귀속하는 일을 줄일 수 있다.

measurement uncertainty를 확인한 뒤에도 차이가 남는다면 이를 곧바로 하나의 원인으로 단정하지 않는다. 시험 셋업, 시간 기준·synchronization, 그리고 모델 가정·단순화가 현재 intended use에 적절한지 등을 각각 원인 후보로 나누어 확인한다.

시험 셋업 점검

  • 확인할 증거: 시험 셋업과 계측 구성, 조건 기록, 반복 비교에서 같은 차이가 나타나는지 확인한다.
  • 변경한 조건: 셋업이나 계측 조건을 변경했다면 어떤 항목을 바꾸었는지 기록한다.
  • 비교 결과: 같은 물리량과 위치·시간 기준에서 결과의 차이가 어떻게 변했는지 남긴다.

시간 기준 / synchronization

  • 확인할 증거: 시험과 해석의 시간 기준, 동기화 방법, 비교 구간이 서로 일치하는지 확인한다.
  • 변경한 조건: 시간 기준이나 정렬 방법을 변경했다면 그 내용을 기록한다.
  • 비교 결과: 동일한 비교 지표를 사용해 정렬 전후의 차이를 확인한다.

모델 가정·단순화 점검

  • 확인할 증거: 사용 목적과 모델 가정·단순화, 입력·경계조건, 수치적 한계를 함께 검토한다.
  • 변경한 조건: 검토한 가정이나 단순화 가운데 무엇을 변경했는지 기록한다.
  • 비교 결과: 변경 전후의 예측 결과를 같은 기준에서 비교하고, 남아 있는 한계를 기록한다.

원인 후보를 점검할 때는 어떤 조건이 변경되었고 어떤 조건이 유지되었는지를 함께 기록한다. 여러 조건이 동시에 변경됐다면 그 사실도 남기고, 해당 변화들이 결과 해석에 미칠 수 있는 영향을 한계로 명시한다.

이 과정의 목적은 해석과 시험 중 어느 한쪽을 빠르게 정답으로 정하는 것이 아니다. 비교 조건과 불확실성을 정리하고, 관측된 차이를 설명할 수 있는 원인 후보를 단계적으로 좁히면서 판단 근거를 남기는 데 있다.

마무리: 결론보다 증거 사슬을 남긴다

보고서에는 사용 목적, 비교 정의, 모델 버전과 가정, 입력·경계조건 출처, 수치 verification 근거, 계측·시험 셋업 정보, 불확실성, 비교 지표, 판정 요구사항, 변경 이력과 한계를 남긴다.

NASA credibility 자료는 특정 셋업이나 timing 메커니즘의 직접 근거라기보다, 결과와 함께 evidence, assumptions, limits를 기록하고 verification·validation·uncertainty quantification을 연결하는 원칙을 설명하는 근거로 사용하는 편이 적절하다. [4]

결국 Validation Engineering의 핵심은 해석과 시험 중 누가 맞는지를 먼저 결정하는 데 있지 않다. 무엇을 비교했는지 정의하고, 수치해와 측정값이 가진 불확실성을 구분하며, 차이를 설명할 수 있는 후보를 확인하고 그 과정을 증거로 남기는 것에 가깝다.

자주 묻는 질문

해석값과 시험값이 다르면 어느 쪽이 틀린 건가요?
차이가 있다는 사실만으로 어느 한쪽을 즉시 오류로 판단할 수는 없다. 먼저 사용 목적과 비교 조건을 고정하고, 수치적 신뢰성과 시험 측 불확실성을 분리해 확인한다.

Verification과 validation은 같은 의미인가요?
아니다. verification은 계산 모델과 수치해가 의도대로 구현·해결됐는지를 확인하는 과정이고, validation은 intended use에서 모델이 현실을 얼마나 적절하게 나타내는지를 평가한다. [2]

오차율이 몇 % 이하면 validation에 합격한 건가요?
모든 문제에 적용할 수 있는 하나의 보편적인 허용오차는 없다. 프로젝트의 사용 목적과 판정 요구사항에 맞춰 기준을 정해야 한다. [1]

Solver가 충분히 수렴하면 validation도 끝난 건가요?
아니다. 수렴과 수치적 신뢰성은 verification 측 증거이며, 현실 재현성에 대한 validation 판단과 구분해야 한다. [2]

Mesh를 더 촘촘하게 만들면 항상 결과가 더 정확해지나요?
총 셀 수만으로 validation의 품질을 판단할 수는 없다. 사용하는 코드와 물리 문제, 사용 목적에 맞는 verification 계획과 수치적 신뢰성의 증거를 함께 확인해야 한다. [2]

측정값은 해석값보다 항상 더 신뢰할 수 있나요?
측정값도 교정, 측정 모델, 반복성, 환경 등 여러 요인에 따른 불확실성을 가진다. [3]

시간 이력 비교에서 synchronization을 왜 확인하나요?
시험과 해석의 시간 기준과 비교 구간이 서로 다르면 같은 현상을 직접 비교하기 어렵다. 따라서 시간 기준과 동기화 방법을 비교 조건과 함께 기록하고 확인한다.

여러 조건이 동시에 바뀌었다면 어떻게 해야 하나요?
변경된 조건과 유지된 조건을 함께 기록하고, 여러 조건의 동시 변경이 결과 해석에 미칠 수 있는 영향을 한계로 명시한다.

References

  1. National Institute of Standards and Technology — NISTIR 8298: Engineering Statistics Handbook for Validation of Computational Models — https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8298.pdf
  2. NASA Technical Reports Server — Development and Use of Engineering Standards for Verification and Validation of Computational Fluid Dynamics Simulations — https://ntrs.nasa.gov/api/citations/20160010173/downloads/20160010173.pdf
  3. National Institute of Standards and Technology — Measurement Uncertainty — https://www.nist.gov/itl/sed/topic-areas/measurement-uncertainty
  4. NASA Technical Reports Server — The Roles of Verification, Validation and Uncertainty Quantification in the NASA Standard for Models and Simulations — https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20070017454.pdf