3장. 고객 RFQ를 끝까지 추적하는 법
이 장에서 얻어 가는 것
고객 RFQ의 요구를 내부 FMEA에 옮기는 일은 번역 작업이 아니다. 요구사항의 출처와 버전, 적용범위를 보존하면서 제품 기능과 특별특성을 정의하고, 설계검증과 공정관리의 책임으로 분해하는 일이다.
이 장에서는 자전거 브레이크의 교육용 RFQ 요구를 중심으로 고객 요구사항과 내부 요구사항을 구분하고, 법규·산업표준·고객별 요구사항의 관계를 확인한다. 이어 특별특성을 선정하고, 요구사항을 DFMEA·DV·PFMEA·Control Plan·WS·PM·MSA·SPC와 연결한다. Ford SCCAF, Qualcomm의 CIP·ABN·RMA, 현대차 CP의 자동검사·EP·SPC는 요구사항 추적성이라는 관점에서 교육 시나리오로 다룬다.
- 외부 요구사항과 내부 요구사항을 구분한다.
- 특별특성의 선정 근거를 만든다.
- 출처·버전·적용범위를 추적한다.
- 고객 RFQ 요구를 설계·공정·현장 관리로 변환한다.
- 변경·이상·반품 결과를 다음 FMEA에 환류한다.
고객 RFQ는 기술적 계약이다
고객 RFQ의 요구사항은 짧아도 여러 의무를 포함한다. “건식 조건에서 제동력 50N 이상을 확보한다”라는 교육용 RFQ 요구를 보면 어느 제품과 모델에 적용되는지, 어떤 조건에서 시험하는지, 기준이 하한인지 목표인지, 어떤 고객 문서에서 왔는지, 개정번호와 승인상태가 무엇인지 확인해야 한다.
| RFQ 요소 | 확인할 내용 | 누락될 때 생기는 문제 |
|---|---|---|
| 대상 | 어느 제품·어셈블리·모델에 적용되는가? | 다른 모델에 잘못 전개한다. |
| 동작 | 확보·유지·방지 중 무엇을 요구하는가? | 기능과 관리의 방향이 흐려진다. |
| 조건 | 건식·습식, 하중, 속도, 온도는 무엇인가? | 시험결과를 비교할 수 없다. |
| 기준 | 50N 이상인지, 범위인지, 한계인지? | 판정기준과 S/O/D 근거가 달라진다. |
| 출처·버전 | RFQ·FS·도면·계약·법규, 개정번호·발행일·승인상태 | 고객 질문에 근거를 제시하지 못하거나 폐기 요구를 사용할 수 있다. |
고객 RFQ의 요구를 내부 문장으로 바꿀 때 가장 위험한 행동은 원문을 삭제하고 요약문만 남기는 것이다. 내부 해석은 필요하지만 원문과 해석을 나란히 보존해야 한다. 원문은 고객의 표현을 지키고, 해석은 설계·공정·검증 담당자가 이해할 수 있게 만든다.
외부 요구사항과 내부 요구사항을 분리하라
외부 요구사항은 고객 FS, 고객 도면, 계약서, 법규, 인증기준, 산업표준처럼 조직 외부에서 준수해야 하는 요구사항이다. 내부 요구사항은 외부 요구사항을 달성하기 위해 조직이 추가로 설정한 설계·공정·검사 기준이다.
고객이 제동력 50N 이상을 요구했을 때 내부 공정은 조립 중간검사에서 55N을 관리 한계로 사용할 수 있다. 다만 내부 한계가 고객 요구를 대신한다고 오해하면 안 된다. 고객 요구 50N은 최종 기능의 승인 기준이고, 내부 55N은 공정 변동을 고려한 관리 기준일 수 있다. 두 기준의 목적과 적용시점을 구분해 기록한다.
| 구분 | 예시 | 관리 원칙 |
|---|---|---|
| 고객 요구사항 | 건식 제동력 50N 이상 | 원문·출처·버전을 보존한다. |
| 법규·인증 | 안전 관련 최소 성능 | 고객 요구와 비교해 더 엄격한 기준을 적용한다. |
| 산업표준 | 시험방법·측정조건 | 시험의 재현성과 비교 가능성을 확보한다. |
| 내부 요구사항 | 공정 중간관리 55N, 조정 범위 | 고객 요구를 달성하기 위한 근거를 남긴다. |
법규·산업표준·고객 요구사항의 우선순위
요구사항이 여러 출처에서 들어오면 단순히 최신 문서 하나를 선택할 수 없다. 법규와 인증 조건, 계약상 고객 요구, 승인된 도면과 FS, 산업표준, 내부 기준을 적용범위와 우선순위로 비교해야 한다.
- 해당 요구사항이 법규·안전·인증에 해당하는지 확인한다.
- 계약·고객 FS·도면 중 승인권한이 높은 문서를 확인한다.
- 산업표준의 시험방법과 고객이 지정한 시험방법을 비교한다.
- 단위·조건·모델·개정번호가 같은지 확인한다.
- 충돌을 해소하기 전에는 임의로 한쪽을 삭제하지 않는다.
- 기술검토와 고객 질의·승인 결과를 근거로 남긴다.
요구사항의 충돌은 FMEA의 문장 문제로 끝나지 않는다. DV 시험조건, 특별특성, 검사주기, 공정능력 목표, 출하판정이 모두 영향을 받는다. Smart FMEA에서는 충돌 상태를 별도로 표시하고, 연결된 하위 문서와 담당자를 함께 보여 주어야 한다.
특별특성은 중요한 것만 표시하는 장식이 아니다
특별특성은 제품·공정의 안전, 법규, 기능, 고객 중요도 또는 변동 민감도 때문에 강화된 관리가 필요한 특성이다. 모든 특성을 특별특성으로 표시하면 실제 우선순위가 사라지고, 중요한 특성을 일반 특성으로만 두면 관리수준이 부족해질 수 있다.
| 선정 질문 | 예라면 이어지는 조치 |
|---|---|
| 실패하면 안전·법규·규제 영향이 있는가? | 설계·공정·검사 책임을 강화한다. |
| 고객이 명시적으로 중요 특성으로 지정했는가? | 고객 표기와 내부 표기를 연결한다. |
| 제품 기능을 직접 결정하고 다른 특성으로 대체하기 어려운가? | DFMEA와 DV의 핵심 특성으로 관리한다. |
| 공정 변동이 제품 기능에 큰 영향을 주는가? | PFMEA·CP·SPC·반응계획을 검토한다. |
| 검출만으로 유출을 막기 어려운가? | 예방관리·포카요케·인터록을 우선 검토한다. |
자전거 브레이크에서는 제동력과 레버 유격이 기능 특성이 될 수 있다. 케이블 체결토크는 제품 성능을 만들기 위한 공정특성이다. 패드 방향은 오조립 시 기능을 잃는다면 공정 특별특성 또는 강화관리 대상이 될 수 있다.
고객 RFQ를 DFMEA·PFMEA·CP로 전개하는 표준 경로
고객 RFQ의 요구 하나를 여러 문서에 반복해서 복사하는 방식으로는 추적성을 만들 수 없다. 요구사항의 의미를 각 문서의 책임에 맞게 변환해야 한다.
| 단계 | 자전거 제동 사례에서의 변환 | 남겨야 할 연결 |
|---|---|---|
| 고객 RFQ·FS | 건식 조건 제동력 50N 이상 | 문서 ID·조항·개정·적용 모델 |
| Function Specification | 레버 입력을 제동력으로 변환한다. | 기능·조건·검증기준 |
| DFMEA | 설계가 요구 제동력을 확보하지 못함 | 구조·부품·고장영향·설계원인 |
| DV·SC&D | 건식 조건 기능시험으로 기준을 검증함 | 시험방법·샘플·판정·결과 |
| BOM·PFD | 패드·캘리퍼·케이블 조립공정이 기능을 실현함 | 부품과 공정의 위치 |
| PFMEA | 패드 방향·체결토크·유격조정이 변동함 | 4M 원인·예방·검출 |
| Control Plan | 제동력 시험, 유격 측정, 반응계획 | 특성·규격·방법·주기·대응 |
| WS·PM·MSA·SPC | 작업·설비·측정·변동을 관리함 | 실행자·설비·점검·분석·환류 |
핵심은 문서의 개수가 아니라 연결의 방향이다. 고객 RFQ를 DFMEA에 붙이고 끝내는 것이 아니라, 요구사항이 어떤 기능으로 해석되었고 어떤 공정에서 실현되며 어떤 결과로 확인되는지 추적해야 한다.
Ford SCCAF 관점으로 특별특성을 전개하기
Ford 완성차 요구사항에 대응하는 협력사에게 중요한 차별화 포인트는 고객이 중요하게 보는 특성을 설계 측과 공정 측의 실행으로 끌어내리는 능력이다. 이 책에서는 공개 가능한 기법 설명을 위해 이를 SCCAF 관점의 교육 시나리오로 재구성한다. 특정 고객의 비공개 양식이나 실제 프로젝트 자료를 공개하는 것이 아니다.
| 구분 | 질문 | 자전거 사례 |
|---|---|---|
| 설계 측 특별특성 | 제품이 기능을 만족하지 못하면 어떤 위험이 생기는가? | 건식 제동력, 패드 접촉, 레버 유격 |
| 공정 측 특별특성 | 제조 변동이 설계 요구를 깨뜨릴 수 있는가? | 패드 방향, 케이블 체결토크, 조정순서 |
| 설계 검증 | 설계가 요구를 만족하는지 어떻게 확인하는가? | DV 기능시험, 내구·환경 조건 |
| 공정 관리 | 공정에서 변동을 어떻게 예방·검출하는가? | 포카요케, 자동검사, SPC, 반응계획 |
SCCAF를 단순한 기호 표시로 사용하면 특별특성의 의미가 약해진다. 특성의 출처, DFMEA 기능, PFMEA 공정원인, CP 관리방법이 한 계보로 연결되어야 고객의 질문에 답할 수 있다.
CIP·ABN·RMA를 요구사항 개선으로 환류하기
개발 이상, 승인 전 문제, 시장 반품은 서로 다른 이름으로 관리될 수 있지만 공통점이 있다. 요구사항이 설계·공정·검출 중 어느 지점에서 충분히 반영되지 않았는지 알려 주는 신호라는 점이다.
이 책에서는 Qualcomm 프로젝트에서 활용되는 문제해결 흐름을 설명하기 위해 CIP·ABN·RMA를 교육 시나리오로 사용한다. CIP는 개선활동, ABN은 비정상 또는 이상 상태 보고, RMA는 고객 반품·반환 이력의 예로 다룬다. 실제 조직의 약어 정의와 프로세스는 고객·회사별 기준을 확인해야 한다.
| 사건 | 요구사항 추적에서 확인할 질문 | FMEA 환류 |
|---|---|---|
| CIP | 개선 전후에 어떤 요구사항과 위험이 달라졌는가? | 대책·S/O/D·검증결과 갱신 |
| ABN | 요구사항을 충족하지 못한 이상이 어느 단계에서 발견됐는가? | 고장형태·원인·검출관리 보완 |
| RMA | 고객 사용조건에서 어떤 기능 실패가 발생했는가? | 영향·조건·LLD·유사제품 재검토 |
반품을 단순히 “제동감 부족”으로 저장하면 다음 프로젝트에 도움이 되지 않는다. 고객 사용조건, 제품 식별, 발생 시점, 시험 재현성, 기존 관리의 실패, 개선 후 검증을 함께 구조화해야 한다. 그 후 엔지니어가 확정한 내용만 LLD와 추천지식으로 보낸다.
현대차 CP의 자동검사·EP·SPC 컬럼 활용
Control Plan의 컬럼은 기입 형식이 아니라 위험관리의 선택이다. 이 책에서는 현대자동차 프로젝트에서 중요한 CP 실행 관점을 일반화해 자동검사, EP, SPC를 다음처럼 판단한다.
| 관리 선택 | 적용하기 좋은 상황 | 자전거 사례 | 함께 정의할 것 |
|---|---|---|---|
| 자동검사 | 반복 특성을 일관되게 판정하고 결과를 저장할 때 | 제동력 기능시험, 레버 유격 측정 | 측정시스템, 기준, 인터록, 데이터 보존 |
| EP(Error Proofing) | 오조립 시 기능을 잃고 사후검출 비용이 큰 경우 | 패드 방향·부품 식별·체결순서 | 방지 구조, 우회 방지, 이상반응 |
| SPC | 연속 데이터로 공정 변동과 추세를 관리할 때 | 제동력, 체결토크, 휠 편차 | 표본, 관리도, 이상신호 반응, 능력 |
자동검사는 검사장비를 설치하는 것으로 끝나지 않는다. 기준 밖 제품이 다음 공정으로 넘어가지 않도록 판정과 반응을 연결해야 한다. EP는 작업자 주의문이 아니라 잘못된 조작이 구조적으로 어렵거나 즉시 차단되도록 만드는 예방관리다. SPC도 관리도를 띄우는 데 그치지 않고, 변동 신호가 발생했을 때 누가 어떤 조치를 취하는지 CP에 적어야 한다.
출처·버전·적용범위의 세 가지 식별자
출처
문서명만으로는 부족하다. 고객 FS의 문서번호, 조항, 페이지, 도면번호, 시험규격, 계약 또는 질의회신을 함께 기록한다.
버전
개정번호와 발행일, 승인상태를 기록한다. 최신 파일이라는 이유만으로 승인된 요구사항이라고 가정하지 않는다. 변경 이력과 적용 시작 시점을 확인한다.
적용범위
모델, 제품군, 공장, 라인, 공정단계, 고객, 생산시점까지 확인한다. 한 모델의 요구사항을 Family 전체에 자동 확장하면 예외와 특별조건이 사라질 수 있다.
Master·Family·Part FMEA의 계층을 요구사항 관리에 적용하면 공통 요구와 프로젝트 고유 요구를 분리할 수 있다. 상위 요구가 바뀌면 하위 문서를 무조건 덮어쓰지 말고 영향범위를 찾아 엔지니어가 확정한다.
공정변경(PCN)으로 요구사항의 영향을 추적하기
공정변경은 설비 교체나 작업순서 변경처럼 보이는 작은 사건일 수 있지만, 제품특성과 특별특성에 영향을 줄 수 있다. 케이블 체결공구를 바꾸면 체결토크 분포, 검사방법, MSA, SPC 관리한계와 제동력 결과가 달라질 수 있다.
변경된 것은 공정 하나가 아니라, 요구사항을 현장 품질로 만드는 연결망일 수 있다.
- 변경 전후의 공정단계와 4M이 무엇인가?
- 관련 제품특성과 고객 요구사항은 무엇인가?
- PFMEA·Control Plan·WS·PM·검사기준에 영향이 있는가?
- 재검증 또는 초기능력·MSA·SPC 확인이 필요한가?
- 고객 승인과 적용 시점을 어떻게 관리하는가?
- 변경 결과가 LLD와 다음 FMEA에 환류되었는가?
고객 RFQ 추적 실습
다음 교육용 고객 RFQ를 기준으로 직접 추적해 보자.
“건식 조건에서 제동력 50N 이상을 확보하고, 레버 유격은 10~15mm 범위로 관리한다.”
| 질문 | 기록할 답 |
|---|---|
| 출처와 버전은? | 고객 RFQ·FS 또는 승인 내부 요구사항의 문서 ID·개정 |
| 적용 모델과 시점은? | 모델·제품군·공장·양산 시작일 |
| 제품 기능은? | 레버 입력을 안정된 제동력으로 변환 |
| 고장형태는? | 제동력 미달, 유격 범위 이탈 |
| 고장영향은? | 감속 부족, 작동감 저하, 정지거리 영향 |
| 설계·공정원인은? | 패드 재료·정렬·구조·공차 / 케이블 체결·조정·부품 방향 |
| 예방·검출관리는? | 지그·EP·조건 잠금·자재 식별 / 자동 기능검사·유격 측정·격리 |
| 검증과 환류는? | DV·MSA·SPC·RMA/ABN/CIP·LLD |
이 표를 채운 뒤 각 답에 실제 문서와 승인자를 연결한다. 답이 없거나 서로 다른 문서를 가리키면 그것이 바로 다음 개선과제다.
3장 실무 체크리스트
- 고객 RFQ 원문과 내부 해석을 분리해 보존했는가?
- 출처·조항·개정번호·승인상태·적용범위를 기록했는가?
- 법규·산업표준·고객 요구·내부 기준의 관계를 확인했는가?
- 특별특성 선정 근거가 안전·법규·기능·고객·공정변동과 연결되는가?
- 요구사항이 DFMEA의 기능과 DV 시험으로 전개되었는가?
- BOM과 PFD를 통해 PFMEA의 공정단계와 연결했는가?
- CP의 자동검사·EP·SPC 선택과 반응계획을 정의했는가?
- WS·PM·MSA가 Control Plan의 관리방법과 일치하는가?
- RMA·ABN·CIP 결과가 원인·관리 실패·개선검증과 함께 저장되는가?
- 공정변경(PCN)의 영향범위와 고객 승인 상태를 추적하는가?
- 추천과 엔지니어 최종확정을 구분하는가?
- 고객 RFQ — 고객이 제품의 기능·성능·조건·판정기준을 요청하고 확인하는 요구사항 문서
- 특별특성 — 안전·법규·기능·고객 중요도 또는 변동 민감도 때문에 강화관리가 필요한 특성
- SCCAF — 고객 중요특성을 설계 측·공정 측 관리와 추적성으로 전개하는 관점의 교육 표현
- DV — Design Verification. 설계가 요구사항을 만족하는지 확인하는 검증
- CIP·ABN·RMA — 개선활동·이상 상태·고객 반품을 FMEA와 LLD로 환류하는 문제지식 흐름
- PCN — Process Change Notification. 공정변경과 영향범위를 검토·통보하는 활동
사례 사용 안내
Ford SCCAF, Qualcomm CIP·ABN·RMA, 현대차 CP 자동검사·EP·SPC 설명은 고객 대응 기법을 이해하기 위한 공개용 교육 시나리오다. 특정 고객의 비공개 양식이나 실제 프로젝트 데이터를 공개하는 내용이 아니다. 자전거 제동력 50N과 레버 유격 10~15mm도 교육용 예시이며 실제 업무에서는 최신 승인 문서를 사용해야 한다.
1부를 마무리하며
1부에서는 FMEA의 목적을 다시 정의하고, 기능에서 고장을 분석하고, 고객 요구사항을 현장까지 추적하는 기준을 세웠다. 다음 부부터는 이 판단을 Smart FMEA의 Master·Family·Part 구조와 연결형 데이터로 전환한다.