제품 개발에서 중요한 것은 “아이디어를 CAD로 바꾸는 것” 하나가 아닙니다. 요구사항이 왜 생겼는지, 어떤 물리 조건을 만족해야 하는지, 어떤 후보를 비교했는지, 어떤 장면으로 이해관계자에게 공유했는지가 하나의 decision loop로 남아야 합니다. RHXY의 Plan, Sim, Render는 이 세 단계를 기능 이름이 아니라 데이터 흐름으로 연결하기 위한 구조입니다.
1. Plan은 prompt가 아니라 requirement graph입니다
Plan 단계의 출력은 제품 소개 문장이 아닙니다. 사용자, 환경, 부품 인터페이스, 제조 가정, 위험 조건, acceptance criteria가 연결된 requirement graph여야 합니다. NASA Systems Engineering Handbook이 요구사항의 rationale, traceability, verification method를 강조하는 이유도 여기에 있습니다. 요구사항은 문서가 아니라 이후 해석과 시험의 기준선입니다.
Plan record는 다음 질문에 답해야 합니다. 이 제품은 누구를 위한 것인가? 어떤 환경에서 쓰이는가? 실패하면 안 되는 상태는 무엇인가? 첫 CAD나 프로토타입이 확인해야 할 요구사항은 무엇인가? 어떤 요구사항은 test로, 어떤 것은 analysis로, 어떤 것은 inspection으로 검증할 것인가?
2. Sim은 contour 이미지가 아니라 evidence package입니다
Sim 단계의 목표는 빨간색 응력 이미지를 만드는 것이 아닙니다. 요구사항에서 온 load case를 만들고, geometry와 material assumption을 명시하고, solver provenance와 mesh quality를 남기며, 결과를 quantity of interest로 요약하는 것입니다. ASME V&V 40이 말하는 credibility 관점처럼, 해석의 신뢰 수준은 사용 목적과 risk에 맞춰 설명되어야 합니다.
초기 설계에서는 모든 해석이 certification evidence일 필요는 없습니다. 하지만 screening 해석인지, design review 해석인지, validation test와 연결된 해석인지는 분명해야 합니다. 이 구분이 없으면 팀은 빠른 결과를 과신하거나, 반대로 유용한 screening 결과를 무시합니다.
3. Render는 이미지 생성이 아니라 shared state입니다
Render 단계의 출력은 광고 이미지 한 장이 아닙니다. 모델 버전, 카메라, 재질, 조명, 배경, 남은 결정 질문을 포함한 shared scene state입니다. Edify 3D 같은 text-to-3D 연구와 DreamCAD 같은 editable CAD 연구가 보여주듯 생성 모델은 visual asset과 editable geometry를 빠르게 만들 수 있습니다. 하지만 제품 리뷰에서는 장면이 CAD 버전과 요구사항, 해석 결과와 연결되어야 합니다.
예를 들어 Sim에서 boss 주변 응력이 위험하다고 나오면 Render는 그 영역을 고객에게 감추기 위한 도구가 아니라, 팀이 어떤 변경을 했는지 설명하는 장면이 되어야 합니다. CMF 후보도 모델 버전과 함께 남아야 다음 회의에서 같은 기준으로 비교할 수 있습니다.
4. 세 단계의 연결 키
- Requirement ID: Plan의 요구사항이 Sim의 load case와 Render의 리뷰 질문으로 이어집니다.
- Geometry version: CAD, mesh, render scene이 같은 모델에서 왔는지 확인합니다.
- Material assumption: 해석 물성과 렌더 재질, 제조 후보가 분리되지 않게 합니다.
- Decision status: 후보, 보류, 검증 필요, 승인 같은 상태가 남아야 합니다.
- Evidence link: 해석 결과, 테스트 사진, 측정값, 고객 피드백이 같은 결정에 연결되어야 합니다.
5. Engineering Foundation Model 관점에서의 의미
Plan, Sim, Render가 따로 저장되면 데이터는 산출물의 무덤이 됩니다. 반대로 requirement, CAD, load case, solver output, render scene, prototype test가 하나의 episode로 묶이면 학습 가능한 engineering data가 됩니다. Engineering Foundation Model을 준비하려면 바로 이 episode 구조가 필요합니다. 모델이 배워야 하는 것은 “이미지 스타일”이나 “CAD 모양”만이 아니라, 제품 질문이 물리 조건과 시각적 설명으로 변환되는 과정입니다.
6. Evidence chain 예시
| 단계 | 산출물 | 다음 단계로 넘어가는 키 |
|---|---|---|
| Plan | REQ-004: 0.75 m 낙하 후 외관 파손 없음 | load_case_id: DROP-SCREEN-01 |
| Sim | corner rib root risk, equivalent static 120 N | geometry_change: rib R0.6 -> R1.5 |
| Prototype | corner coupon 3회 낙하, crack 없음, white mark 있음 | test_evidence_id: DROP-COUPON-v02 |
| Render | before/after corner detail scene | review_scene_id: RENDER-CORNER-v02 |
| Decision | v02 corner fillet 채택, full enclosure print 진행 | decision_id: DEC-017 |
7. RHXY가 제품 결정에 기여하는 방식
RHXY는 한 번에 정답을 내는 시스템이 아니라, 결정을 추적 가능하게 만드는 OS에 가까워야 합니다. Plan은 질문을 만들고, Sim은 물리 리스크를 드러내며, Render는 이해관계자가 같은 상태를 보게 합니다. 이 세 단계가 같은 evidence chain에 있을 때 팀은 “누가 맞는가”보다 “어떤 증거가 다음 결정을 지지하는가”를 이야기할 수 있습니다.