고객 요구사항을 CTQ로 바꾸는 방법|CAD 설계값·공차·검증시험 연결

고객이 말하는 “튼튼한 제품”, “조립이 쉬운 구조”, “사용 중 흔들림이 없어야 한다”는 표현은 그대로 CAD 치수나 도면 공차로 입력할 수 없습니다. 먼저 제품이 수행해야 할 기능과 사용 조건, 사용자가 불편을 느끼는 실패 모드를 정의한 뒤 이를 측정 가능한 CTQ와 설계 입력값, 검증시험으로 연결해야 합니다.

CTQ는 단순히 중요한 치수 목록이 아닙니다. 고객 요구사항 → 기능 → 실패 모드 → CTQ → CAD 특징·치수·공차·재질 → 시험방법·판정기준이 하나의 ID로 연결돼야 설계 변경과 품질검사에서도 같은 기준을 사용할 수 있습니다.

고객 요구사항 VOC를 CTQ 설계 공정 검증으로 연결하는 APQP PLM 구조
APQP와 PLM은 고객 요구사항을 CTQ·설계특성·검증시험·변경이력으로 연결하는 데 함께 활용할 수 있습니다.

핵심 결론
정성 요구는 바로 수치화하지 말고 기능과 실패 모드부터 정의합니다.
CTQ는 무엇을 관리할지, 설계 입력값은 무엇을 조정할지, 검증시험은 어떻게 만족을 증명할지를 나타냅니다.
하중·수명·공차 같은 숫자는 근거와 승인 주체가 있을 때만 합격 기준으로 사용합니다.
시험에는 조건·시편 리비전·샘플 수·장비·측정 위치·판정 책임자를 포함합니다.
요구사항 ID를 CAD·PMI·도면·BOM·시험성적서에 동일하게 사용합니다.

고객 요구가 CAD 치수로 바로 이어지지 않는 이유

하나의 문장에 여러 설계 변수가 섞여 있음

“얇고 가벼우면서 튼튼해야 한다”는 요구에는 두께·재질·리브·체결점·하중 방향·외관·금형성·원가가 동시에 포함됩니다. 두께를 줄이면 강성이 낮아질 수 있고 리브를 늘리면 중량과 싱크마크가 증가할 수 있습니다.

설계자가 임의로 숫자를 정하면 안 되는 이유

튼튼함을 곧바로 ‘두께 2mm 이상’으로 바꾸면 왜 2mm인지, 어떤 하중과 사용 환경을 기준으로 하는지 설명할 수 없습니다. 숫자는 기능과 시험 결과 또는 고객·법규·사내 기준에 근거해야 합니다.

부서별 문서 사이에 연결 키가 없음

기획서는 사용자의 언어를, 산업디자인 자료는 외관과 조작감을, CAD는 형상과 치수를, 품질 문서는 검사 항목을 관리합니다. 동일한 요구사항 ID가 없으면 설계자는 임의의 치수를 정하고 품질팀은 측정하기 쉬운 항목을 CTQ로 선택할 수 있습니다.

제품 요구사항·CTQ·설계 입력값·검증시험 차이

구분핵심 질문작성 예시주요 담당
제품 요구사항고객이 원하는 기능과 경험은?사용 중 커버가 흔들리지 않아야 함제품기획·디자인
실패 모드요구를 만족하지 못하는 방식은?체결부 풀림·보스 균열·유격 발생설계·품질·시험
CTQ무엇을 측정하거나 평가할 것인가?상대 변위·체결 유지력·유격기획·설계·품질 공동
설계 입력값설계자가 무엇을 조정할 것인가?보스 두께·리브·홀 위치·재질·토크기구설계·제조기술
검증시험만족 여부를 어떻게 증명할 것인가?하중·진동·반복 체결 후 유격 측정시험·품질·설계
Siemens Teamcenter 요구사항 품질과 추적성 관리 공식 이미지
Teamcenter Requirements Engineering은 요구사항 품질을 검토하고 요구사항을 제품 데이터와 연결해 변경 영향을 추적하도록 지원합니다.

정성 요구사항을 CTQ로 바꾸는 5단계

1단계: 요구사항의 주체와 사용 조건 고정

누가 언제 어떻게 사용하는가

사용자, 조작 방향, 하중 위치, 반복 횟수, 온도·습기·진동, 장착 상태와 상대 부품 조건을 적습니다. 같은 ‘변형이 없어야 한다’도 손으로 누르는 버튼과 차량 진동을 받는 커버는 다른 시험이 필요합니다.

2단계: 기능과 실패 모드 분리

기능은 부품이 해야 할 일이고 실패 모드는 기능을 수행하지 못하는 방식입니다. 커버라면 내부 보호가 기능이며 충격 파손·체결부 이탈·이물 유입·조립 변형이 실패 모드가 될 수 있습니다.

DFMEA와 연결할 항목

실패 모드·영향·원인·예방관리·검출관리 항목을 CTQ 후보와 연결합니다. DFMEA에서 중요하다고 판단된 특성이 실제 도면과 시험계획에 반영됐는지 확인합니다.

3단계: 측정 가능한 CTQ 선정

파손은 균열·잔류변형, 이탈은 체결력·풀림량, 조립성은 삽입력·공구 접근·조립시간, 외관은 갭·단차·표면 결함과 관찰 조건으로 전환할 수 있습니다.

4단계: CAD 설계 입력값 연결

CTQ에 영향을 주는 기준면·치수·공차·재질·리브·보스·홀 패턴·체결 방법을 연결합니다. 한 CTQ는 여러 설계변수의 영향을 받을 수 있으므로 단일 치수로만 관리하지 않습니다.

5단계: 검증시험과 판정 기준 확정

시험방법에는 시편 리비전, 샘플 수, 장착 상태, 하중 방향과 크기, 유지시간, 반복 횟수, 온도, 측정장비, 측정 위치와 판정 책임자를 포함합니다.

요구사항 추적표 작성방법

ID고객 요구사항실패 모드CTQ설계 입력값검증시험·판정
REQ-01사용 중 커버가 흔들리지 않아야 함보스 균열·체결부 유격상대 변위·체결 유지보스·리브·스크루·토크·공차지정 하중과 반복 작동 후 유격 확인
REQ-02부품 간 단차가 눈에 띄지 않아야 함갭·플러시 과다지정 위치의 갭·단차데이텀·홀 위치·분할선·수축 공차정의 단면과 조명 조건에서 검사
REQ-03반복 사용 후 기능 유지마모·균열·풀림작동력 변화·균열·기능 유지재질·접촉면·필릿·표면처리수명시험 후 기능·외관 판정
REQ-04작업자가 쉽게 조립할 수 있어야 함오조립·공구 간섭·과도한 삽입력삽입력·조립시간·오조립률가이드·키잉·공구공간·공차표준 작업조건의 조립성 평가

표의 예시는 구조를 설명하기 위한 것이며 실제 하중·수명·허용 갭은 프로젝트 사양과 시험 근거로 확정해야 합니다. 기준이 아직 없다면 임의 숫자를 넣지 말고 결정 책임자와 결정 기한을 기록합니다.

Teamcenter 요구사항 검증 계획 시험 수행 모니터링 공식 프로세스
Teamcenter Requirements Validation은 요구사항과 시험을 마일스톤에 연결하고 수행 결과·충족 상태·근본원인을 추적하는 흐름을 제공합니다.

가상의 판금 브래킷 사례

고객 요구사항

“브래킷이 상대 부품을 안정적으로 지지하고 체결 후 흔들리지 않아야 한다”고 가정합니다.

기능과 실패 모드

  • 판이 휘어 상대 위치가 변경됩니다.
  • 홀 가장자리가 찢어지거나 변형됩니다.
  • 체결부가 풀려 유격이 발생합니다.
  • 공차 누적으로 조립되지 않습니다.

CTQ와 설계 입력값

CTQ는 하중 후 변위, 홀 위치·직경, 체결면 평면도, 체결 유지 상태로 정할 수 있습니다. 설계 입력은 판 두께, 굽힘 위치, 플랜지 길이, 홀과 가장자리 거리, 홀 공차, 재질과 체결 조건이 됩니다.

두께만 키우면 안 되는 이유

변위는 두께뿐 아니라 지지점 간 거리, 굽힘 형상과 방향, 체결 위치에 영향을 받습니다. 두께 증가는 중량·원가·절곡성·간섭에도 영향을 주므로 여러 설계안을 같은 CTQ 기준으로 비교합니다.

기획부터 검증까지 실무 운영 절차

기획 단계

감성 문장에 평가 대상과 조건을 붙입니다. ‘고급스러운 외관’이라면 외관면·조명·거리·샘플을, ‘쉬운 조립’이라면 작업 방향·공구 접근·삽입력·오조립 방지 조건을 정의합니다.

개념설계 단계

구조안을 외형 취향이 아니라 CTQ 영향으로 비교합니다. 리브 구조와 단판 구조를 강성·중량·금형성·외관·조립성·변형 위험으로 비교하고 가정값과 확정값을 구분합니다.

상세설계 단계

CAD의 기능면·체결 위치·인터페이스를 요구사항 ID와 연결하고, 도면과 PMI에는 검사 가능한 치수·공차·데이텀·재질·표면 조건을 표시합니다.

모든 치수를 CTQ로 지정하지 않기

모델에 존재하는 모든 치수가 CTQ는 아닙니다. 기능·안전·조립·내구·외관 실패에 직접 연결되는 특성을 우선 관리하고 나머지는 일반 관리치수로 구분합니다.

검증 단계

시험 결과를 파일로만 보관하지 말고 요구사항 ID와 시편 리비전에 연결합니다. 불합격 시에는 설계 변경 전에 시험 조건·시편 상태·조립·장비 교정·측정 정렬을 먼저 확인합니다.

Siemens NX Inspector PMI 특성을 개별 품질 특성으로 변환
NX Inspector는 PMI를 개별 추적 가능한 특성으로 변환해 설계·제조·품질 부서가 동일한 검사 항목을 관리하도록 지원합니다.
ADVERTISEMENT

NX Inspector와 Teamcenter 활용

NX Inspector에서 CTQ 특성 관리

PMI에 묶여 있는 동일 홀과 치수도 개별 특성 ID로 나누고 재질·공급사·시험 요구 같은 사용자 속성을 연결할 수 있습니다. 설계 변경 시 특성 정보가 함께 갱신되는지 확인합니다.

Teamcenter Requirements Engineering

요구사항과 제품구조·CAD·시험·변경 데이터를 연결하면 요구 변경이 어떤 CTQ와 도면, 시험 항목에 영향을 주는지 확인할 수 있습니다.

PLM이 문서 내용을 대신하지는 않음

시스템에 연결했다고 잘 작성된 요구사항이 되는 것은 아닙니다. 기능·실패 모드·시험 조건과 판정 기준을 먼저 명확히 작성한 뒤 PLM으로 리비전과 관계를 관리합니다.

현장에서 자주 놓치는 항목

  • CTQ와 전체 치수 혼동: 관리 우선순위가 흐려집니다.
  • 시험 조건 생략: 하중 방향·시간·횟수·온도가 없으면 재현할 수 없습니다.
  • 공차 근거 부족: 좁은 공차가 항상 좋은 품질을 의미하지 않습니다.
  • 데이텀과 검사 정렬 불일치: 설계와 측정 결과가 달라질 수 있습니다.
  • 외관 요구 단일 수치화: 조명·거리·질감·조립 상태도 필요합니다.
  • 변경 이력 단절: CAD 변경 후 관련 CTQ와 시험이 갱신되지 않습니다.

요구사항 추적표 체크리스트

  • 모든 요구사항에 고유 ID·출처·담당자가 있습니다.
  • 사용자·기능·사용 조건이 정의돼 있습니다.
  • 기능별 실패 모드와 영향이 구분돼 있습니다.
  • 각 실패 모드에 대응하는 CTQ가 있습니다.
  • CTQ가 측정 또는 평가 가능한 문장입니다.
  • CAD 치수·공차·재질·구조가 CTQ와 연결됩니다.
  • 가정값과 승인된 확정값이 구분됩니다.
  • 도면 데이텀과 검사 정렬 기준이 일치합니다.
  • 시험 조건·샘플 수·측정 방법·판정 책임자가 있습니다.
  • 시험 결과가 요구사항 ID와 시편 리비전에 연결됩니다.
  • 설계변경 시 도면·BOM·시험 영향도를 재검토합니다.

Siemens NX 공식 검증 영상

Siemens Designcenter NX 공식 Tips & Tricks 재생목록|NX Inspector·Validation·PMI와 제품데이터 검증 기능 확인

디크리노랗 관련글

고객 요구사항과 CTQ FAQ

CTQ는 모든 도면 치수와 같은 의미인가요?

아닙니다. CTQ는 기능·안전·조립·내구·외관에 큰 영향을 주고 실패 모드와 검증방법에 연결되는 우선 관리 특성입니다.

정성적인 외관 요구도 CTQ가 될 수 있나요?

가능합니다. 외관면·조명·거리·갭·단차·표면 결함·승인 샘플과 평가방법으로 구체화하면 추적할 수 있습니다.

설계 입력값이 정해지지 않았다면?

임의 수치를 넣지 말고 검토 가정으로 표시합니다. 근거·결정 담당자·기한과 영향을 받는 CTQ를 함께 기록합니다.

시험에서 불합격하면 바로 설계를 변경하나요?

시편 리비전·조립 상태·시험 조건·장비 교정·데이텀 정렬·측정 위치를 먼저 확인해 설계 문제인지 검증 문제인지 구분합니다.

추적표는 언제 작성해야 하나요?

제품기획 단계에서 요구사항 ID와 사용 조건을 만들고 개념설계에서 CTQ와 입력값을 보완합니다. 상세설계 완료 후 처음 만들면 이미 정해진 치수를 사후 정당화하기 쉽습니다.

마무리: 좋은 요구사항은 검증 가능한 설계 결정이다

고객의 정성적인 표현을 CTQ·CAD 설계 입력값·검증시험으로 바꾸는 목적은 문서를 늘리는 것이 아니라 설계 치수와 검사 기준의 근거를 하나로 연결하는 데 있습니다. 기능과 실패 모드를 먼저 정의하고 관리해야 할 특성과 설계변수, 시험방법을 같은 행에 배치하세요.

처음부터 모든 요구를 완벽하게 연결할 필요는 없습니다. 핵심 기능 하나를 선택해 요구사항 ID·CTQ·CAD 특징·도면·시험 결과를 연결하고 리뷰 과정에서 확장하면 됩니다. 중요한 것은 설계 변경 후에도 관련 도면·BOM·시험·품질 문서가 같은 요구사항을 계속 바라보는 것입니다.

ADVERTISEMENT

DecreYellow

제품디자인과 3D CAD 설계 실무를 기반으로 IT, 윈도우 오류 해결, CAD 소프트웨어, 디자이너 세금, 프리랜서·개인사업자 실무 정보를 정리하고 있습니다. 단순한 이론 설명보다 실제 업무와 블로그 운영, 프로그램 사용 경험을 바탕으로 초보자도 이해하기 쉽게 문제 원인과 해결 방법을 풀어내는 것을 목표로 합니다.

You may also like...