첫 프로토타입 전에 정리해야 할 제품 요구사항 체크리스트

첫 프로토타입을 빨리 만드는 것은 중요합니다. 하지만 “일단 만들어보자”만으로 시작하면 출력물은 남아도 제품 판단은 흐려집니다. NASA Systems Engineering Handbook은 명확한 요구사항이 개발자와 이해관계자 사이의 합의 기반이 되고, 누락과 오해를 초기에 줄이며, verification과 validation 계획의 기준선이 된다고 설명합니다. 하드웨어 프로토타입도 같은 원칙을 적용해야 합니다.

프로토타입은 작은 완성품이 아니라 물리적 질문지입니다. 어떤 요구사항을 검증할지, 어떤 가정을 시험할지, 어떤 데이터를 남길지 정하지 않으면 프로토타입은 회의용 물체가 되고, 다음 버전으로 이어지는 증거가 되지 못합니다.

1. 요구사항은 방향성보다 검증 가능성이 먼저입니다

“가볍고 튼튼해야 한다”는 방향성은 좋지만 요구사항으로는 약합니다. “배터리 포함 450 g 이하”, “손잡이 끝단에 80 N 하중을 10초간 가했을 때 영구 변형 없음”, “실내 35도 환경에서 표면 온도 45도 이하”처럼 측정 방법과 기준이 있어야 합니다. NASA Handbook의 요구사항 metadata도 requirement ID, rationale, traceability, owner, verification method를 함께 관리하라고 합니다.

2. Verification과 validation을 구분해야 합니다

Verification은 “요구사항을 만족했는가”에 가깝습니다. 치수, 무게, 강도, 전류, 온도, 방수 등 명시된 조건을 test, analysis, inspection, demonstration으로 확인합니다. Validation은 “사용자가 의도한 환경에서 정말 쓸 수 있는가”에 가깝습니다. 요구사항을 통과한 제품도 사용자가 불편하면 validation에는 실패할 수 있습니다.

3. 첫 프로토타입 전에 정해야 할 최소 정보

• 사용자와 context: 누가, 어디서, 어떤 자세와 빈도로 쓰는가.
• 운용 환경: 온도, 습도, 먼지, 물, 진동, 충격, UV, 세척 조건.
• 핵심 기능: 첫 버전에서 반드시 작동해야 하는 기능과 제외할 기능.
• 인터페이스: 센서, 보드, 배터리, 나사, 힌지, 케이블, 손이 닿는 영역.
• 제작 방식: 3D 프린팅, CNC, 판금, 사출, 혼합 제작 중 무엇을 가정하는가.
• 검증 방법: 측정, 실험, 해석, 시각 검토 중 어떤 방식으로 판단할 것인가.
• 판단 질문: 이번 프로토타입이 통과하면 무엇을 결정하고, 실패하면 무엇을 바꿀 것인가.

4. 프로토타입은 기록하지 않으면 사라집니다

physical prototype metadata 연구는 76명의 사용자로부터 17개월 동안 800개 이상의 물리적 프로토타입을 수집하며, 누가, 왜, 언제, 어디서 만들었는지 같은 맥락 정보가 나중의 재사용과 학습에 중요하다는 점을 보여줍니다. 제품 팀도 프로토타입마다 모델 버전, 재료, 제작 설정, 테스트 조건, 실패 사진, 변경 이유를 남겨야 합니다.

특히 3D 프린트 설정, 적층 방향, infill, 후가공, 사용한 나사와 insert, 테스트 fixture는 다음 결과 해석에 직접 영향을 줍니다. “v2가 v1보다 튼튼했다”가 아니라 “v2는 리브 방향을 바꾸고 80% infill, flat orientation, M3 heat-set insert로 80 N 하중에서 균열이 없었다”처럼 남아야 합니다.

5. VLM과 AI 리뷰는 보조 도구로 써야 합니다

GPT-4V와 LLaVA를 엔지니어링 설계 업무에 평가한 연구는 시각언어모델이 conceptual design, detailed design, manufacturing/inspection, engineering education에서 가능성을 보이지만 한계도 명확하다고 정리합니다. AI는 사진에서 문제 후보를 찾거나 체크리스트를 확장하는 데 도움을 줄 수 있지만, 치수 측정, 하중 시험, 재료 데이터, safety 판단을 대체하지는 못합니다.

6. 첫 브리프를 채우는 예시

7. RHXY Plan에 넣어야 할 첫 브리프 구조

첫 프로토타입 전에는 긴 문서보다 traceable brief가 더 중요합니다. RHXY Plan이 다뤄야 할 입력은 제품 한 문장, 사용자 context, 상위 요구사항, 부품 후보, 제작 가정, verification method, 남은 risk입니다. 이 brief가 있어야 RHXY Sim에서 load case를 만들고, RHXY Render에서 같은 제품 의도를 리뷰 장면으로 전달할 수 있습니다.

7. Worked example: 휴대용 공기질 센서 PRD 초안

예를 들어 책상 위에서 쓰는 휴대용 공기질 센서를 만든다고 가정해보겠습니다. “작고 예쁜 센서”라는 설명만으로는 프로토타입을 평가할 수 없습니다. 첫 번째 프로토타입은 다음과 같은 requirement matrix를 가져야 합니다.

이 표는 제품을 느리게 만드는 문서가 아닙니다. 오히려 첫 제작에서 무엇을 생략해도 되는지 알려줍니다. 예를 들어 v01에서 센서 정확도는 평가하지 않고, housing 크기, connector 주변 강성, vent 위치, 필터 접근성을 먼저 볼 수 있습니다.

8. Prototype metadata 예시

이 정도 metadata가 남으면 v02는 감이 아니라 증거에서 시작합니다. “좀 더 튼튼하게”가 아니라 “boss root fillet을 키우고, connector clearance를 늘리고, 필터 cover affordance를 바꾼다”가 됩니다.

참고 자료

• NASA Systems Engineering Handbook
• Understanding and Capturing Physical Prototyping Activities
• Evaluating Vision-Language Models for Engineering Design