Engineering Foundation Model을 위한 데이터 조건

Engineering Foundation Model은 공학 문제를 넓게 다루고, 재사용 가능한 물리·설계 표현을 학습하는 모델입니다. 이런 모델을 만들려면 데이터 기준부터 달라져야 합니다. 이미지 모델은 픽셀과 캡션의 규모가 중요하고, 언어 모델은 토큰의 다양성이 중요합니다. 공학 모델은 형상, 토폴로지, 재료, 경계조건, 해석 설정, 결과장, 측정값, 요구사항, 의사결정 맥락이 함께 맞아야 합니다.

최근 연구도 같은 방향을 가리킵니다. 2024년 The Well은 15TB 규모의 물리 시뮬레이션 데이터를 공개했고, PDEBench는 PDE 기반 Scientific ML benchmark의 기본 조건을 정리했습니다. 2025년 PhysiX와 GPhyT는 대규모 시뮬레이션 데이터가 물리 예측 모델에 유효하다는 점을 보였지만, 2026년 bias-aware benchmark는 현재 모델이 아직 범용 물리 모델이라기보다 조건부 generalist에 가깝다고 지적합니다. 데이터가 많아도 분포, regime, 시간 스케일, 초기 조건, OOD split을 잘못 설계하면 모델은 물리가 아니라 데이터셋의 지름길을 학습합니다.

1. CAD 파일만으로는 공학 데이터가 아닙니다

공학 모델의 최소 단위는 CAD 파일이 아니라 “해석 가능한 사건”입니다. 같은 bracket CAD도 재료, 고정면, 하중 위치, 접촉 처리, mesh 수렴 여부에 따라 다른 sample이 됩니다. 따라서 engineering dataset의 기본 record는 geometry asset이 아니라 simulation 또는 experiment episode여야 합니다.

하나의 episode에는 요구사항 또는 설계 질문, CAD/B-rep 또는 mesh geometry, feature와 boundary tag, material property, manufacturing assumption, load case, boundary/initial condition, solver version, mesh strategy, convergence log, field output, scalar QoI, validation data, uncertainty, 그리고 이 결과가 쓰인 설계 의사결정이 포함되어야 합니다.

2. Foundation model을 위한 레코드 스키마

공학 데이터는 사람이 읽기 쉬운 파일명보다 기계가 읽을 수 있는 schema가 중요합니다. 다음과 같은 레코드가 있어야 pretraining, retrieval, fine-tuning, evaluation, audit가 가능합니다.

{
  "sample_id": "sim_enclosure_drop_v03_000184",
  "artifact": {
    "cad": "s3://.../enclosure_v03.step",
    "mesh": "s3://.../enclosure_v03_mesh.msh",
    "geometry_tags": ["front_shell", "boss_m3_01", "usb_c_cutout"]
  },
  "physics": {
    "domain": "structural",
    "analysis_type": "linear_static",
    "material": "PA12_SLS_candidate",
    "load_case": "corner_drop_equivalent_static",
    "boundary_conditions": ["screw_boss_fixed", "corner_force_120N"]
  },
  "solver": {
    "name": "CalculiX",
    "version": "2.21",
    "mesh_size_mm": 1.2,
    "convergence": {"residual": 1e-6, "qoi_delta": 0.018}
  },
  "outputs": {
    "fields": ["displacement", "von_mises_stress"],
    "qoi": {"max_displacement_mm": 1.8, "boss_peak_mpa": 42.1},
    "validity": "screening_only"
  },
  "evidence": {
    "test_data": "coupon_boss_pullout_v02.csv",
    "uncertainty": ["material_batch_unknown", "static_equivalent_drop"],
    "decision": "increase boss OD from 5.5mm to 6.8mm"
  }
}

이 정도 구조가 없으면 모델은 field를 예측할 수 있어도 왜 그 field가 생겼는지, 어떤 조건에서 믿을 수 있는지, 설계자가 무엇을 바꿔야 하는지 알기 어렵습니다.

3. Geometry는 모양이 아니라 의미를 가져야 합니다

Engineering Foundation Model의 geometry 데이터는 단순 point cloud나 triangle mesh만으로 부족합니다. 실제 제품 설계에서는 face, edge, feature, part hierarchy, assembly relationship, interface가 의미를 갖습니다. 구멍은 그냥 원형 패턴이 아니라 fastener interface일 수 있고, 얇은 rib는 stiffness feature일 수 있으며, 작은 fillet은 stress concentration을 줄이는 설계 의도입니다.

따라서 geometry record에는 적어도 세 수준이 필요합니다. 첫째, B-rep 또는 parametric CAD처럼 수정 가능한 표현. 둘째, solver가 사용하는 mesh와 element quality. 셋째, semantic tag입니다. 예를 들어 “이 면은 고정면”, “이 edge는 접촉 후보”, “이 boss는 M3 insert”, “이 cutout은 USB-C clearance” 같은 의미가 있어야 모델이 CAD와 물리를 연결합니다.

4. Boundary condition은 데이터의 절반입니다

많은 CAE dataset은 geometry와 field output을 공개하지만 boundary condition provenance가 약합니다. 그러나 물리해석에서 boundary condition은 결과를 지배합니다. 같은 mesh와 material이라도 point load, distributed load, contact load, thermal load, prescribed displacement 중 무엇을 쓰는지에 따라 stress field가 달라집니다.

데이터셋에는 하중의 출처가 남아야 합니다. 사용자 요구사항에서 온 값인지, 실험 측정값인지, 표준 시험 조건인지, 보수적 가정인지, 최적화 과정에서 생성된 synthetic condition인지 구분해야 합니다. 이 구분이 없으면 foundation model은 “현실의 물리”와 “사람이 임의로 만든 training condition”을 섞어 학습합니다.

5. Solver provenance와 수렴 정보가 없으면 field는 라벨이 아닙니다

Engineering dataset에서 field output은 ground truth가 아니라 solver-generated label입니다. solver, turbulence model, time step, nonlinear setting, contact formulation, material law, mesh strategy, residual, convergence failure 여부가 함께 있어야 합니다. DoMINO가 engineering-specific metric과 in-distribution/OOD evaluation을 강조한 이유도 이 때문입니다. ML surrogate는 고전 solver보다 빠를 수 있지만, 그 학습 라벨 자체가 어떤 solver assumption에서 왔는지 알아야 합니다.

CFD에서는 mesh downsampling이 정확도와 일반화에 영향을 줄 수 있고, structural FEA에서는 singularity와 local mesh refinement가 peak stress를 크게 바꿀 수 있습니다. 따라서 foundation model용 데이터는 field array뿐 아니라 mesh independence check, residual history, failed run, solver warning도 보존해야 합니다. 실패한 해석도 중요한 데이터입니다. 모델이 “어떤 설정이 위험한지”를 배울 수 있기 때문입니다.

6. Multi-fidelity를 명시해야 합니다

공학 데이터는 fidelity가 다양합니다. 빠른 linear static screening, coarse CFD, high-fidelity LES, coupon test, component test, full product test가 모두 같은 “정답”이 아닙니다. Foundation model을 만들려면 fidelity level을 숨기지 말고 feature로 넣어야 합니다.

L0: 요구사항, 자연어 브리프, rough hand calculation.
L1: low-fidelity simulation, coarse mesh, fast screening.
L2: engineering-grade simulation, convergence checked, documented assumptions.
L3: physical coupon/component test와 비교된 validated model.
L4: field operation data 또는 certification evidence와 연결된 model.

이 계층을 명시하면 모델은 빠른 screening과 인증 수준 판단을 혼동하지 않습니다. RHXY Sim 같은 제품에서도 결과를 “screening”, “design review”, “validated evidence”로 구분해야 합니다.

7. Unit, coordinate, nondimensionalization은 사소한 전처리가 아닙니다

공학 데이터에서 단위 오류는 치명적입니다. mm와 m, MPa와 Pa, Celsius와 Kelvin, rpm과 rad/s, gauge pressure와 absolute pressure가 섞이면 모델은 물리를 배울 수 없습니다. 좌표계도 마찬가지입니다. 자동차 공력 데이터에서는 전방 방향, 지면 기준, yaw angle 정의가 중요하고, 구조 해석에서는 local coordinate와 global coordinate가 다를 수 있습니다.

Foundation model 데이터셋은 raw value와 normalized value를 모두 관리해야 합니다. 또한 Reynolds number, Mach number, Biot number, Fourier number, slenderness ratio 같은 nondimensional group을 함께 저장하면 모델이 단순 수치 범위가 아니라 regime을 구분하는 데 도움이 됩니다.

8. Train/test split은 무작위가 아니라 regime 기반이어야 합니다

2026년 physics foundation model bias-aware benchmark의 중요한 메시지는 평균 점수 하나로 일반화를 판단하면 안 된다는 것입니다. 모델이 어떤 PDE family, temporal scale, initial condition complexity, distribution shift에서 강하고 약한지 분리해야 합니다. 공학 데이터셋도 random split만으로는 부족합니다.

예를 들어 자동차 공력 surrogate라면 같은 vehicle family의 작은 shape variation을 train/test에 섞는 split은 쉽습니다. 진짜 어려운 split은 다른 body type, 다른 yaw regime, 다른 ground clearance, 다른 mesh policy, 다른 Reynolds range를 test로 빼는 것입니다. 제품 구조 해석도 같은 bracket family가 아니라 다른 fastening topology, 다른 material, 다른 manufacturing process를 OOD로 둬야 합니다.

9. Evaluation metric은 engineering decision과 연결되어야 합니다

Field L2 error가 낮아도 설계 결정에는 실패할 수 있습니다. 최대 drag coefficient, pressure drop, hot spot temperature, bolt reaction, displacement at interface, safety margin, fatigue damage index 같은 quantity of interest가 맞아야 합니다. DoMINO가 engineering-specific metric을 사용한 것도 field 전체 평균보다 실제 설계 지표가 중요하기 때문입니다.

실무형 benchmark는 다음 metric을 함께 봅니다. field error, scalar QoI error, ranking accuracy, constraint violation rate, OOD degradation, rollout stability, uncertainty calibration, failure localization accuracy, 그리고 “어떤 설계 변경을 추천했을 때 실제로 개선됐는가”입니다.

10. Experiment와 simulation을 연결해야 합니다

Foundation model이 공학 현장에서 쓰이려면 simulation-only dataset만으로 부족합니다. coupon test, component test, field sensor, inspection image, failure analysis report와 연결되어야 합니다. NASA Handbook의 verification/validation 구분처럼, simulation은 요구사항을 만족하는지 보는 evidence의 하나일 뿐이고, 실제 사용 환경 validation은 별도입니다.

데이터 레코드는 “solver label”과 “test evidence”를 구분해야 합니다. 예를 들어 boss stress field는 FEA output이고, insert pull-out force는 coupon test입니다. 둘을 같은 sample graph에 연결하면 모델은 해석 결과와 실제 파손 사이의 차이를 학습할 수 있습니다.

11. 데이터 품질 게이트

Engineering Foundation Model용 데이터는 ingest 전에 gate를 통과해야 합니다.

Completeness: geometry, material, boundary condition, output, provenance가 모두 있는가.
Consistency: 단위, 좌표계, naming, tag schema가 일관적인가.
Numerical quality: mesh quality, residual, convergence, failed run status가 기록됐는가.
Physical plausibility: conservation law, sign convention, expected scaling을 위반하지 않는가.
Traceability: 어떤 요구사항, 설계 변경, 테스트와 연결되는가.
License/security: 고객 CAD, 제조 IP, export control, 개인정보, NDA 제한이 분리됐는가.
OOD annotation: 이 sample이 어떤 regime, geometry family, material family에 속하는가.

12. RHX.LAB이 봐야 할 데이터 전략

RHX가 Engineering Foundation Model을 준비한다면 데이터 전략은 “많이 모으기”가 아니라 “학습 가능한 engineering episode를 쌓기”여야 합니다. RHXY Plan은 requirement와 decision context를 만들고, RHXY Sim은 load case, solver provenance, field output, QoI를 만들며, RHXY Render는 geometry와 material state, review context를 연결합니다. 여기에 prototype test와 field feedback이 붙어야 비로소 foundation model 학습 데이터가 됩니다.

공학용 foundation model은 제품을 대신 설계하는 도구가 아닙니다. 요구사항을 해석 조건으로 바꾸고, CAD feature와 물리 field를 연결하고, OOD 조건에서 불확실성을 표시하며, 다음 실험을 제안하는 시스템에 가깝습니다. RHX 블로그가 공학 매거진의 밀도를 가지려면 데이터 조건도 이 수준에서 다뤄야 합니다.

Engineering Foundation Model을 위한 데이터 조건

읽기 전에 보는 검토 지도

Episode

Schema

Validation

Learning