1장. 완성된 FMEA가 불량을 막지 못하는 이유
이 장에서 얻어 가는 것
이 장은 FMEA 표를 작성하는 순서를 알려 주는 장이 아니다. 그보다 먼저, 왜 많은 조직에서 FMEA가 승인된 뒤에도 동일한 불량과 고객 지적이 반복되는지 원인을 분해한다.
그리고 다음 장부터 기능 중심 FMEA를 작성하기 전에 반드시 확인해야 할 위험관리의 기준을 세운다. 이 장을 읽고 나면 다음 질문에 답할 수 있어야 한다.
- FMEA의 목적은 문서 제출인가, 위험 감소인가?
- 문서가 완성된 상태와 위험이 관리되는 상태는 어떻게 다른가?
- 예방관리와 검출관리는 왜 서로 대체할 수 없는가?
- DFMEA, PFMEA, Control Plan이 서로 다른 내용을 갖게 되는 이유는 무엇인가?
- 자전거 제동 요구사항을 설계·공정·현장까지 어떻게 추적해야 하는가?
- Smart FMEA는 이 단절을 어떤 관계와 화면으로 드러내는가?
FMEA의 목적을 다시 정의하라
FMEA는 Failure Mode and Effects Analysis의 약자다. 잠재적인 고장형태와 그 영향을 미리 분석하고, 고장이 발생할 가능성과 고장을 발견하지 못할 가능성을 줄이기 위한 방법이다.
이 정의는 익숙하지만 현장에서는 종종 다른 방식으로 실행된다. 고객 제출용 양식을 채우고, 회의록에 승인 서명을 남기고, 심사 때 파일을 제시하면 FMEA 활동이 끝났다고 생각하는 것이다.
그러나 양식의 완성은 위험 감소의 증거가 아니다. FMEA를 작성했다는 사실은 “위험을 생각해 보았다”는 기록일 뿐이다. 실제로 위험이 감소했는지 확인하려면 최소한 다음 네 가지가 연결되어야 한다.
| 연결되어야 할 요소 | 확인할 질문 | 결과로 남아야 할 것 |
|---|---|---|
| 요구사항과 기능 | 이 특성은 어떤 고객·법규·도면·기능 요구에서 출발했는가? | 요구사항 출처, 버전, 적용범위 |
| 기능과 고장사슬 | 기능이 실패하면 어떤 고장형태와 영향이 발생하는가? | 기능, 고장형태, 고장영향, 고장원인 |
| 고장원인과 관리 | 원인이 발생하지 않게 하거나 발생 즉시 찾아내는 방법은 무엇인가? | 예방관리, 검출관리, 시험·검사 방법 |
| 관리와 실행 | 누가, 언제, 어떤 설비와 기준으로 관리하고 이상 시 무엇을 하는가? | Control Plan, 작업표준, PM, 반응계획 |
이 네 가지가 이어지지 않으면 FMEA는 위험관리 문서가 아니라 위험을 설명하는 문서에 머문다. 설명은 잘하지만 예방하지 못하는 문서다.
FMEA는 결과표가 아니라 의사결정 기록이다
FMEA의 각 행에는 숫자와 문장이 들어간다. 그러나 본질은 숫자나 문장의 양이 아니다. 한 행은 다음과 같은 기술적 의사결정의 결과여야 한다.
어떤 기능을 수행해야 하는가 → 그 기능이 어떻게 실패할 수 있는가 → 왜 실패하는가 → 무엇으로 예방할 것인가 → 무엇으로 검출할 것인가 → 남은 위험을 누가 승인할 것인가
이 흐름이 살아 있으면 FMEA의 행은 설계·공정·검사·작업·개선활동을 연결하는 기준점이 된다. 반대로 이 흐름이 없으면 같은 표현이 여러 문서에 반복되어도 어느 문서가 원본이고 어느 문서가 파생 결과인지 알 수 없다.
완성된 FMEA와 관리되는 위험은 다르다
현장에서 “FMEA가 완성되었다”는 표현은 여러 상태를 포함한다. 필수 셀이 모두 입력된 상태일 수도 있고, 검토 회의가 끝난 상태일 수도 있고, 고객에게 제출할 수 있는 파일이 된 상태일 수도 있다. 이 세 가지는 서로 다르다.
문서 완성도의 네 단계
| 단계 | 보이는 상태 | 실제 의미 | 다음에 해야 할 일 |
|---|---|---|---|
| 1단계 입력 완료 | 필수 컬럼과 점수가 채워져 있다. | 빈칸이 없을 뿐, 근거와 실행이 확인되지 않았다. | 출처·기능·고장사슬·관리방법을 검토한다. |
| 2단계 검토 완료 | 회의에서 행을 읽고 수정했다. | 팀의 의견이 반영되었지만 문서 간 관계는 불분명할 수 있다. | DFMEA·PFMEA·CP의 대응 관계를 확인한다. |
| 3단계 승인 완료 | 책임자와 고객의 승인을 받았다. | 현재 시점의 설계·공정에 대한 승인 기록이 있다. | 양산 실행과 변경 영향범위를 확인한다. |
| 4단계 위험관리 완료 | 예방·검출·반응이 현장에서 실행되고 결과가 축적된다. | 문서가 실제 위험 감소를 지지한다. | 측정결과·SPC·문제해결·LLD를 환류한다. |
많은 조직은 1단계나 2단계를 4단계로 착각한다. 승인 서명이 있다는 이유만으로 현장의 위험이 통제되었다고 판단한다. 하지만 승인된 FMEA와 실제 작업조건이 다르면 승인된 문서는 과거의 의도를 보관할 뿐 현재의 위험을 줄이지 못한다.
숫자가 있다고 판단이 있는 것은 아니다
S/O/D는 위험을 비교하고 우선순위를 정하기 위한 판단 도구다. 숫자가 입력되었다고 판단의 근거가 자동으로 생기는 것은 아니다. 예를 들어 심각도 8, 발생도 4, 검출도 6이라는 숫자가 있어도 다음 질문에 답할 수 없다면 그 점수는 재검토해야 한다.
- 심각도 8은 최종 사용자, 고객, 법규, 안전 중 무엇을 근거로 했는가?
- 발생도 4는 실제 공정능력, 과거 데이터, 유사 공정, 산업체 지식 중 무엇을 반영했는가?
- 검출도 6은 어떤 검사장비와 검사주기, 표본 수, 측정시스템을 전제로 했는가?
- 예방관리와 검출관리가 변경되면 점수도 재평가되는가?
Smart FMEA의 추천기능은 이런 질문을 대신 결정하지 않는다. 추천은 과거 확정값과 산업체 지식을 바탕으로 검토 후보를 제시하는 기능이다. 최종 점수와 관리방법은 해당 제품·공정·고객 요구사항을 이해한 엔지니어가 확정해야 한다. 사람이 확정하는 과정은 수동 입력이 아니라 엔지니어의 창의적 문제해결이다.
형식적인 FMEA에서 반복되는 다섯 가지 징후
FMEA가 실제 위험관리와 멀어졌는지는 파일을 열어 몇 개의 행을 보는 것만으로도 어느 정도 확인할 수 있다. 다음 징후가 여러 개 보이면 문서 작성량을 늘리기보다 분석 구조를 다시 세워야 한다.
징후 1. 고장형태가 불량명 목록으로 끝난다
“스크래치”, “미체결”, “치수 불량”, “기능 불량”은 현상일 수 있지만, 그 자체로 충분한 고장형태는 아니다. 어떤 기능의 합격조건을 충족하지 못했는지, 어느 위치와 조건에서 실패했는지가 빠져 있기 때문이다.
| 형식적인 문장 | 기능에 연결된 문장 | 차이 |
|---|---|---|
| 브레이크 불량 | 건식 조건에서 요구 제동력을 확보하지 못함 | 합격조건과 사용조건이 드러난다. |
| 패드 불량 | 패드가 로터에 균일하게 접촉하지 못해 제동력이 부족함 | 기능 실패의 메커니즘이 드러난다. |
| 조립 불량 | 케이블 체결과 레버 유격이 규정 범위를 벗어나 제동 입력이 전달되지 않음 | 공정 원인과 기능 영향이 연결된다. |
형식적인 문장은 검색하기 쉬울 수 있지만 예방책을 설계하기 어렵다. 기능에 연결된 문장은 원인과 관리방법을 구체화할 수 있다.
징후 2. 원인이 “작업자 실수”로 수렴한다
작업자 실수는 원인의 최종 설명이 아니다. 왜 실수가 발생할 수 있었는지까지 내려가야 한다. 작업표준이 불명확했는지, 조정값이 표시되지 않았는지, 부품이 혼입될 수 있었는지, 치공구가 조립 방향을 강제하지 못했는지, 검사장비가 이상을 알려 주지 못했는지를 구분해야 한다.
“작업자 실수”로 끝나면 대책은 교육과 주의 환기에 머문다. 반면 메커니즘까지 내려가면 잘못된 방향으로는 조립되지 않는 치공구, 모델·부품번호를 확인하는 바코드 인터록, 체결결과를 저장하는 시스템, 레버 유격 게이지, 기준 밖이면 다음 공정으로 넘어가지 못하는 판정 로직으로 바뀔 수 있다.
FMEA의 목적은 사람에게 책임을 배분하는 것이 아니라 고장이 발생하는 구조를 바꾸는 것이다.
징후 3. DFMEA 문장이 PFMEA에 그대로 복사된다
설계 고장과 공정 고장은 관련되어 있지만 동일하지 않다. DFMEA는 설계가 기능을 충족하지 못하는 위험을 분석한다. PFMEA는 제조공정이 설계 요구를 실현하지 못하는 위험을 분석한다.
| 구분 | DFMEA에서 묻는 질문 | PFMEA에서 묻는 질문 |
|---|---|---|
| 대상 | 제품·부품 설계 | 제조공정·작업조건 |
| 핵심 원인 | 재료, 치수, 구조, 인터페이스, 설계조건 | 사람, 설비, 자재, 방법, 측정의 변동 |
| 대표 예방 | 설계계산, 설계규칙, 공차설계, DV 검증 | 지그 포카요케, 공정조건 잠금, 자재확인, 자격관리 |
| 대표 검출 | 해석, 시험, 설계검증, 설계리뷰 | 자동검사, 치수검사, 기능검사, 공정감시 |
| 책임 | 설계 요구와 제품 위험 | 공정이 요구를 실현하는 능력 |
복사·붙여넣기는 작성 시간을 줄이는 것처럼 보이지만, 설계 위험과 공정 위험의 경계를 흐리게 만든다. Smart FMEA에서 DFMEA와 PFMEA를 연동한다는 말은 같은 문장을 복사한다는 뜻이 아니다. 설계의 부품 요구사항이 어느 공정에서 실현되는지 관계를 지정하고, 그 공정에서 발생 가능한 별도의 원인을 다시 분석한다는 뜻이다.
징후 4. Control Plan의 컬럼은 채워졌지만 현장은 다르게 움직인다
Control Plan에 검사방법과 주기가 입력되어 있어도 작업표준서의 단위·특성·규격이 다르거나, 검사장비의 상태와 이상대응이 정의되지 않았거나, 결과가 분석되지 않으면 실행은 보장되지 않는다.
Control Plan은 표의 마지막 문서가 아니다. PFMEA의 위험을 작업자의 행동과 설비의 조건으로 전환하는 중간 관문이다. 따라서 CP에서 자동검사, EP, SPC를 선택할 때에도 “컬럼에 무엇을 입력할까?”보다 “이 특성을 어떤 위험을 줄이기 위해 어떻게 관리할까?”를 먼저 결정해야 한다.
징후 5. 과거 문제가 다음 FMEA에 나타나지 않는다
RMA, ABN, CIP, 현장 이상, 개발 실패, 공정변경(PCN)에는 다음 FMEA를 더 강하게 만들 수 있는 정보가 들어 있다. 그런데 이 정보가 보고서 파일에만 남으면 새 프로젝트의 분석자는 같은 고장형태와 원인을 다시 놓칠 수 있다.
LLD는 파일 저장소가 아니라 판단 후보의 저장소여야 한다. 고장영향, 고장형태, 고장원인, 기존 관리의 실패, 개선대책, 적용범위, 확정상태가 구조화되어야 지식을 재사용할 수 있다.
예방관리와 검출관리를 혼동하지 마라
FMEA에서 가장 자주 발생하는 오해 중 하나는 검출검사를 강화하면 예방관리가 없어도 된다는 생각이다. 검출은 이미 발생한 원인이나 고장형태를 찾아내는 활동이고, 예방은 원인이 발생하지 않게 하거나 발생 가능성을 낮추는 활동이다.
예방관리는 원인의 발생 가능성을 낮춘다
자전거 브레이크 조립에서 케이블 체결토크 부족이 원인이라면 예방관리에는 규정 토크 범위를 가진 체결공구, 체결 순서와 접근방향을 고정하는 작업방법, 체결 완료 신호와 결과를 저장하는 설비조건, 올바른 케이블과 부품을 확인하는 자재 식별, 레버 유격을 확인할 수 있는 기준 표시가 들어갈 수 있다.
이 방법들은 “토크 부족이 발생할 가능성”을 낮춘다. 예방관리의 수준이 높아질수록 공정에서 불량을 만들 가능성이 줄어든다.
검출관리는 발생한 위험이 다음 단계로 넘어가는 것을 막는다
같은 원인이 이미 발생했거나 예방관리가 완벽하지 않을 수 있다면 검출관리가 필요하다. 체결토크 결과가 하한 미만이면 다음 공정을 허용하지 않는 인터록, 레버 유격 측정, 최종 제동력 시험의 자동판정, 제품 식별번호와 검사결과의 연계가 예가 된다.
검출관리는 불량 유출을 줄이지만 원인을 없애지는 않는다. 같은 불량을 반복해서 검출하는 조직은 검사비용과 재작업비용이 계속 발생한다. 따라서 검출이 강화되었다는 이유로 발생도 평가를 낮추거나 예방대책을 삭제해서는 안 된다.
| 비교 항목 | 예방관리 | 검출관리 |
|---|---|---|
| 목적 | 원인 발생을 막거나 줄인다. | 발생한 원인·고장·결과를 찾아낸다. |
| 개입 시점 | 원인이 발생하기 전 | 원인 또는 고장이 발생한 후 |
| 대표 수단 | 설계규칙, 공정조건 잠금, 포카요케, 자재확인 | 검사, 시험, 자동판정, 샘플링, 격리 |
| 위험에 미치는 영향 | 발생도와 원인 자체에 영향을 준다. | 검출도와 유출 위험에 영향을 준다. |
| 한계 | 예방이 약하면 변동이 누적된다. | 검사비용과 오검출·미검출 위험이 남는다. |
검출할 수 있다는 말과 검출이 효과적이라는 말은 다르다
“최종검사에서 확인한다”는 문장은 검출관리로서 충분하지 않다. 시험기가 실제 제동력을 재현하는지, 센서와 하중계는 언제 점검·교정하는지, 측정결과의 단위와 합격기준이 고객 FS·도면·내부 SPEC과 같은지, 전수인지 샘플인지, 측정시스템 분석이 필요한지, 불합격품을 어떻게 격리하는지까지 구체적이어야 한다.
자전거 FMEA 사례: 문서가 모두 있는데 제동 불량이 반복된다면
이 책 전체에서 사용하는 자전거 사례를 1장의 기준점으로 삼자. 아래 사례는 Smart FMEA 공개용 시연 데이터를 바탕으로 재구성한 교육용 시나리오다. 특정 고객의 공식 규격이나 법규값이 아니며, 실제 프로젝트에서는 최신 고객 FS·도면·시험규격을 사용해야 한다.
상황
자전거 조립공장은 브레이크 어셈블리에 대해 다음 학습용 요구사항을 관리하고 있다.
건식 조건에서 제동력 50N 이상을 확보한다.
이 값은 이 책의 설명을 위한 시연값이다. 자전거 종류, 시험장비, 시험조건, 법규와 고객 요구가 달라지면 적용 기준도 달라질 수 있다.
공장에는 DFMEA, PFMEA, Control Plan, 작업표준서가 모두 있다. 최종 제동력 검사도 수행한다. 그런데 고객 반품에서 제동감 부족이 반복된다. 문서를 확인해 보니 다음과 같은 단절이 발견된다.
| 문서 | 기록된 내용 | 발견된 단절 |
|---|---|---|
| DFMEA | 브레이크 기능: 자전거를 감속·정지시킨다. | 요구 제동력과 시험조건의 출처가 불명확하다. |
| PFMEA | 브레이크 조립: 케이블을 체결한다. | 레버 유격과 케이블 체결의 관계가 분석되지 않았다. |
| Control Plan | 브레이크 기능검사, 작업자 검사 | 검사장비·샘플·합격기준·반응계획이 구체적이지 않다. |
| 작업표준서 | 케이블을 연결하고 브레이크를 조정한다. | 조정값과 불합격 처리방법이 문서마다 다르다. |
| 예방보전 | 조립설비 일상점검 | 제동력 시험기 센서 점검기준이 별도 관리되지 않는다. |
| RMA | 제동감 부족 | 원인·관리 실패·개선결과가 다음 FMEA에 연결되지 않았다. |
중요한 점은 “검사가 없었다”가 아니라 “요구사항부터 현장 결과까지 연결된 관리선이 없었다”는 것이다.
위험관리 관점에서 다시 작성하는 흐름
먼저 요구사항의 출처와 적용조건을 확인한다. 그다음 DFMEA에서 기능과 고장사슬을 정의한다. 이후 BOM과 PFD를 기준으로 어떤 부품과 공정이 요구사항을 실현하는지 지정하고, PFMEA에서 조립공정의 원인을 분석한다. 마지막으로 Control Plan·작업표준·예방보전·MSA·SPC의 적용 여부를 결정한다.
| 분석 단계 | 자전거 제동 사례의 질문 | 산출되는 판단 |
|---|---|---|
| 요구사항 | 건식 제동력 50N 이상은 어느 문서·버전·모델에 적용되는가? | 출처와 적용범위 확정 |
| 기능 | 레버 조작을 제동력으로 변환해 안전하게 감속·정지하는가? | 제품 기능 정의 |
| 고장영향 | 요구 제동력을 확보하지 못하면 사용자가 어떤 영향을 받는가? | 고장영향과 심각도 근거 |
| 고장형태 | 제동력이 기준 미만인가, 작동이 불안정한가? | 검증 가능한 고장형태 |
| 설계원인 | 패드 재료·면적·캘리퍼 구조가 요구를 만족하는가? | DFMEA 설계 원인·DV 계획 |
| 공정원인 | 패드 방향·케이블 체결·레버 유격이 변동하는가? | PFMEA 4M 원인 |
| 예방·검출 | 잘못 조립되는 것을 어떻게 줄이고, 기준 미달 제품이 유출되지 않게 하는가? | 지그·조건 잠금·기능시험·격리 |
| 현장·환류 | 작업자·설비가 어떻게 관리하고, 반품 결과를 어떻게 재사용하는가? | WS·PM·반응계획·LLD |
Smart FMEA 구현 사례: 문서가 아니라 관계를 보여 주는 화면
Smart FMEA에서 중요한 차별화 포인트는 여러 문서를 한 폴더에 저장하는 데 있지 않다. 문서 간 관계를 기술적 계보로 관리하는 데 있다.
1) 원문과 해석을 분리해 보존한다
고객 FS, 도면 SPEC, Function Specification은 각각 다른 출처와 책임을 가진다. 원문을 내부 문장으로 바꾸어 덮어쓰지 않고, 원문·번역·내부 해석·설계 요구사항을 구분해 관리해야 고객 문서가 개정되었을 때 영향범위를 찾을 수 있다.
2) 연결되지 않은 대상을 진단한다
DFMEA의 브레이크 패드 요구사항이 존재해도 PFD의 조립공정과 연결되지 않으면 PFMEA로 전개되지 않는다. PFMEA에 제동력 관리가 있어도 Control Plan에 검사방법이 없으면 현장 실행으로 내려가지 않는다. Smart FMEA는 연결됨·제안됨·미연결·충돌·폐기됨 상태를 구분해 누락을 드러낸다.
| 상태 | 의미 | 엔지니어의 조치 |
|---|---|---|
| 연결됨 | 출처·대상·관계가 확인되었다. | 기준과 실행결과를 검토한다. |
| 제안됨 | 유사사례나 마스터 지식으로 후보가 제시되었다. | 적용 가능성을 검토하고 확정 또는 거부한다. |
| 미연결 | 다음 단계로 전개된 대상이 없다. | 누락 원인과 책임자를 지정한다. |
| 충돌 | 문서마다 규격·단위·관리방법이 다르다. | 최신 승인 문서와 기술적 근거로 조정한다. |
| 폐기됨 | 개정 또는 적용범위 변경으로 더 이상 유효하지 않다. | 하위 관계와 추천 가중치를 정리한다. |
3) 추천과 확정을 구분한다
과거에 확정된 자전거 제동 사례가 있다고 해서 모든 새 모델에 같은 S/O/D와 대책을 자동 확정할 수는 없다. 사용환경, 차체 구조, 제동방식, 패드 재료, 시험조건이 달라질 수 있기 때문이다.
Smart FMEA의 추천은 유사한 기능과 고장형태, 같은 산업체에서 사용된 예방·검출관리, 과거 확정값과 근거, LLD의 RMA·ABN·CIP 개선사례, 같은 BOM 부품과 PFD 공정의 연결 이력을 빠르게 제시한다. 적용범위와 기술적 책임은 엔지니어에게 있다.
4) 현장의 결과를 다시 지식으로 돌려보낸다
최종 제동력 검사에서 불합격이 발생했다면 단순히 불량 수량으로 끝내서는 안 된다. 어떤 조건에서 발생했는지, 예방관리가 왜 막지 못했는지, 검출관리가 언제 발견했는지, 개선 후 재발이 줄었는지 기록해야 한다. 엔지니어가 확정한 결과만 LLD의 추천 지식으로 등록하면 다음 FMEA 작성자가 더 강한 출발점을 가질 수 있다.
이 구조를 “자가발전”이라고 부를 수 있지만, 자동으로 정답이 생성된다는 뜻은 아니다. 사람이 검토하고 확정한 판단이 회사의 지식이 되고, 그 지식이 다음 프로젝트에서 후보로 재사용되는 인간 승인형 순환을 의미한다.
해외 고객이 FMEA에서 실제로 확인하는 것
해외 고객의 심사나 기술검토에서 FMEA 파일의 행 수만 확인하는 경우는 드물다. 고객은 요구사항이 실제 제품과 공정에 반영되었는지, 변경이 발생했을 때 영향범위를 찾을 수 있는지, 문제가 생겼을 때 다시 발생하지 않도록 시스템이 학습하는지를 확인한다.
다음 질문에 답할 수 있으면 FMEA는 제출문서에서 고객 대응 도구로 바뀐다.
- 이 특별특성은 고객의 어느 요구사항에서 시작했는가?
- 요구사항이 DFMEA의 어느 기능과 부품 요구사항에 연결되는가?
- 해당 설계 요구사항을 검증하는 DV 시험은 무엇인가?
- 이 요구사항을 실현하는 PFD 공정은 무엇인가?
- 공정에서 발생할 수 있는 4M 원인은 무엇인가?
- 예방관리와 검출관리는 각각 무엇이며 서로 어떤 한계가 있는가?
- Control Plan의 검사방법과 작업표준서의 실행방법이 일치하는가?
- 검사에 사용하는 설비의 점검·교정·예방보전 기준은 있는가?
- 측정값을 믿을 수 있다는 MSA 근거가 있는가?
- SPC를 적용했다면 변동을 줄이기 위한 반응계획이 있는가?
- 최근 RMA·ABN·CIP·PCN이 관련 FMEA에 반영되었는가?
- 변경된 판단과 승인자는 추적 가능한가?
이 질문에 답하기 위해 필요한 것은 화려한 화면이 아니다. 원문, 관계, 근거, 책임, 실행결과가 연결된 기록이다. Smart FMEA의 화면은 그 연결을 빠르게 찾고 누락을 드러내기 위한 도구다.
1장 실무 적용: 한 시간 진단법
새로운 프로젝트나 기존 FMEA를 처음 검토할 때 다음 순서로 진단한다. 이 절차는 시스템 메뉴를 외우기 위한 것이 아니라 위험관리의 상태를 빠르게 판단하기 위한 것이다.
1단계. 대표 특별특성 하나를 선택한다
안전·기능·고객 중요도가 높은 특성 하나를 선택한다. 자전거 사례에서는 “건식 제동력 50N 이상”을 선택한다. 실제 프로젝트에서는 고객 FS, 도면, 법규 또는 내부 기준에서 출처가 분명한 항목을 선택한다.
2단계. 출처에서 현장까지 경로를 그린다
고객 FS 또는 내부 요구사항 → Function Specification·도면 SPEC → DFMEA → DV·SC&D → BOM·PFD → PFMEA → Control Plan → WS·PM → MSA·SPC → 결과·LLD
각 화살표 사이에서 “무엇이 이어졌는가?”를 기록한다. 문서 이름만 연결하지 말고 특성, 공정, 시험방법, 설비, 반응계획을 확인한다.
3단계. 끊긴 지점에 상태를 부여한다
끊긴 지점을 미연결·충돌·폐기 중 하나로 분류한다. 미연결은 작성 누락일 수 있고, 충돌은 서로 다른 문서가 같은 대상을 다르게 설명하는 문제일 수 있다. 폐기는 개정·제품변경·고객변경으로 더 이상 유효하지 않은 관계를 뜻한다.
4단계. 예방과 검출을 분리해 다시 묻는다
현재 관리가 모두 검사에 의존하고 있으면 발생원인을 줄이는 예방책이 부족할 가능성이 높다. 반대로 예방대책만 있고 확인방법이 없으면 발생한 변동이 고객까지 유출될 수 있다. 두 관리의 목적과 한계를 별도로 기록한다.
5단계. 확정해야 하는 사람과 증거를 지정한다
추천된 관리방법을 그대로 채택하지 말고, 설계·공정·품질·생산·설비 담당자가 어떤 근거로 확정할지 정한다. 확정된 값과 보류된 후보를 분리해 남긴다. 이 과정이 추후 고객 질문에 대한 답변이 된다.
장 마무리: FMEA를 다시 현장으로 가져오는 다섯 가지 원칙
- FMEA의 완성은 빈칸이 없는 상태가 아니라 위험을 줄이는 결정이 연결된 상태다.
- 고장형태는 불량명으로 끝내지 말고 기능과 합격조건의 실패로 정의한다.
- DFMEA와 PFMEA는 같은 문장을 복사하는 관계가 아니라 설계 요구사항과 공정 실현조건의 관계다.
- 예방관리는 발생 가능성을 낮추고 검출관리는 발생한 위험의 유출을 막는다. 두 관리를 서로 대체하지 않는다.
- 시스템은 근거와 후보를 추천할 수 있지만, 적용범위와 최종 결론은 엔지니어가 창의적 문제해결을 통해 확정한다.
다음 장에서는 이 원칙을 실제 작성 방법으로 전환한다. 고장형태부터 먼저 적는 습관을 멈추고, 구조·기능·요구사항의 관계에서 분석을 시작한다.
1장 실무 체크리스트
- FMEA의 목적을 고객 제출이 아니라 위험 감소로 정의했는가?
- 대표 특별특성 하나를 출처부터 현장까지 추적했는가?
- 고객 FS·도면 SPEC·Function Specification의 출처와 버전을 확인했는가?
- 기능과 합격조건을 먼저 정의한 뒤 고장형태를 작성했는가?
- DFMEA와 PFMEA의 원인 메커니즘을 구분했는가?
- 예방관리와 검출관리를 서로 다른 목적의 통제로 작성했는가?
- Control Plan의 특성·규격·검사방법·주기·반응계획이 작업표준과 일치하는가?
- 검사설비의 MSA·교정·예방보전 기준이 있는가?
- RMA·ABN·CIP·PCN 결과가 관련 FMEA와 LLD에 연결되어 있는가?
- 시스템 추천과 엔지니어 최종확정을 구분했는가?
용어 정리
- FMEA — 잠재 고장과 영향을 분석하고 위험을 줄이는 예방 중심의 품질기법
- DFMEA — 제품·부품 설계가 기능과 요구사항을 충족하지 못하는 위험을 분석하는 활동
- PFMEA — 제조공정이 설계 요구사항을 실현하지 못하는 원인과 관리방법을 분석하는 활동
- Control Plan — PFMEA의 위험을 제품·공정특성, 검사, 반응계획으로 전개한 실행계획
- 예방관리 / 검출관리 — 고장원인의 발생 가능성을 낮추는 관리 / 발생한 위험이 유출되지 않게 찾는 관리
- LLD — 엔지니어가 검토·확정한 문제해결 결과를 다음 프로젝트에 재사용하는 지식 저장소
- PCN — Process Change Notification. 공정변경을 통보하고 관련 문서의 영향을 검토하는 활동
사례 사용 안내
이 장의 자전거 제동력 50N, 레버 유격 10~15mm 및 관련 문장은 Smart FMEA 공개용 시연 패키지를 바탕으로 한 교육 사례다. 특정 고객의 공식 규격이나 법규 요구값을 의미하지 않는다. 실제 업무에서는 최신 승인 고객 FS, 도면, 법규, 시험규격과 엔지니어의 검토 결과를 사용해야 한다.
다음 장에서 계속됩니다
고장형태부터 적는 습관을 멈추고, 구조·기능·요구사항의 관계에서 분석을 시작하는 방법을 다룬다.