FMEA 실무 ①: 시스템·HW·SW FMEA와 핵심 개념

고장·리스크 분석 · FMEA 실무 시리즈 1/5

“FMEA 표를 받았는데, 첫 칸부터 뭘 써야 할지 모르겠어요.”

처음이라면 자연스러운 질문입니다. 표의 빈칸을 한꺼번에 채우려 하지 마세요. 먼저 제품이 해야 할 일 하나를 고르고, 그 일이 잘되지 않는 모습을 문장으로 써보면 됩니다. 이번 글은 전동식 냉각수 펌프를 예로 들어 그 첫 문장을 함께 만들어봅니다. 대화와 분석 내용은 교육용 가상 예시이며, 실제 고객 자료나 시험 기록은 아닙니다.

고장 보고서가 아니라, 설계에 미리 던지는 질문

FMEA(Failure Mode and Effects Analysis)는 ‘고장모드 및 영향 분석’입니다. 아직 고장이 나지 않았어도 “어떤 식으로 일을 못 할 수 있고, 그러면 무엇이 달라질까?”를 살펴보는 활동이지요. 고장 보고서가 이미 생긴 문제를 조사한다면, FMEA는 설계 중에 실패 가능성을 찾아 예방할 기회를 만드는 쪽에 가깝습니다. 실제 고장 사례도 참고할 수 있습니다.

왜 하느냐고요? 표나 점수를 만드는 것이 목적은 아닙니다. 고객에게 문제가 생기기 전에 설계·공정의 실패 가능성을 찾아, 무엇을 바꾸고 시험할지 정하는 것입니다. 새 명령이 끊겼는데 펌프가 옛 명령을 계속 쓸 가능성을 일찍 알면, 시간 조건을 설계와 시험에 반영할 수 있습니다. 변경이 어려워지기 전에 개선하는 것이지요. 다만 FMEA 자체가 무고장이나 안전 승인을 보장하지는 않습니다.

이번 예제의 EWP는 Electric Water Pump, 즉 전기로 구동하는 냉각수 펌프입니다. 냉각수를 순환시켜 냉각 기능을 돕습니다. 제어기는 펌프를 어떻게 움직일지 명령을 받고, 그 명령을 사용할 수 있는지 판단합니다. 정상 흐름을 아주 작게 그리면 ‘냉각 요구 → 펌프 명령 수신 → 명령 유효성 판단 → 모터 구동 → 냉각수 순환’입니다. 실제 제품의 구조와 조건은 설계 자료로 확인해야 합니다.

명령을 받아 냉각수를 보내는 정상 기능을 단순화한 그림입니다. 실제 구조는 설계 자료로 확인합니다. 그림을 누르면 크게 볼 수 있습니다.

이 흐름에서 오늘은 ‘명령이 아직 유효한지 판단하는 일’만 잡겠습니다. 냉각 시스템 전체를 한 번에 분석하려고 하면 원인과 결과가 너무 많아집니다. 작은 대상부터 쓰되, 그 실패가 상위 냉각 기능에 미치는 영향은 놓치지 않는 것이 출발점입니다.

‘통신두절’ 한 단어를 네 칸으로 풀어봅시다

“고장모드 칸에 통신두절이라고 쓰면 되나요?” 대상에 따라 가능할 수도 있지만, 지금 고른 ‘명령 유효성 관리’의 실패를 설명하기에는 부족합니다. 메시지가 오지 않는 상황과, 그때 소프트웨어가 잘못 판단하는 일을 구별해야 하거든요. 메시지가 끊겨도 설계한 대로 과거 명령을 무효화한다면, 오늘 찾으려는 판단 실패는 일어나지 않을 수 있습니다.

기능은 대상이 해야 할 일입니다. 여기서는 ‘수신 명령의 유효성을 판단하고, 무효화하거나 정상 상태로 복귀시키기’입니다. ‘정상 동작’보다 이렇게 동사로 쓰면 어떤 실패를 찾아야 할지 보입니다.

고장모드는 그 기능이 실패하는 모습입니다. ‘유효하지 않은 과거 명령을 계속 유효하게 판단한다’고 써보세요. 새 명령이 없다는 사실 자체보다, 분석 대상이 무엇을 잘못하는지 드러납니다.

원인은 왜 그런 실패가 생길 수 있는지입니다. 이 예제에서는 ‘새 수신이 없어도 유효 플래그를 유지하는 상태 갱신 로직 오류 후보’입니다. 유효 플래그는 명령을 사용해도 되는지 표시하는 값이고, 상태 갱신 로직은 그 값을 조건에 따라 바꾸는 처리입니다. 아직 코드를 확인한 사실이 아니라 확인할 후보라는 점도 같이 적습니다.

영향은 그 실패 때문에 상위에서 생길 수 있는 결과입니다. ‘현재 냉각 요구와 다른 펌프 명령이 유지되어 상위 냉각 기능에 영향을 줄 수 있다’로 연결합니다. 이 정보만으로 차량의 최종 결과까지 단정하지는 않습니다.

같은 SW 기능의 원인 후보, 실패 모습, 상위 영향을 나눠 읽어보세요. 그림을 누르면 크게 볼 수 있습니다.

작성 전에는 ‘통신두절’만 있었지만, 작성 후에는 ‘상태 갱신 오류 후보 → 과거 명령을 유효하게 판단 → 현재 요구와 다른 명령 유지’라는 연결이 생겼습니다. 이 연결이 있어야 설계자는 무엇을 확인할지, 시험 담당자는 어떤 상황을 만들어볼지 이야기할 수 있습니다. 같은 현상도 분석 대상을 바꾸면 원인이나 영향이 될 수 있으니, 문장 위에 대상을 먼저 적어두세요.

시스템·HW·SW와 DFMEA는 어떻게 다른가요?

시스템은 여러 요소가 함께 냉각 기능을 제공하는지를 봅니다. HW, 즉 하드웨어는 회로와 부품이 필요한 구동 전류를 제공하는지 봅니다. SW, 즉 소프트웨어는 명령을 판단하고 상태를 바꾸는 처리가 맞는지 봅니다. 서로 따로 쓰고 끝내는 문서가 아니라, 아래쪽의 실패와 위쪽의 영향을 연결하는 관점입니다.

이처럼 제품 설계를 살펴보는 분석이 DFMEA(Design Failure Mode and Effects Analysis, 설계 고장모드 및 영향 분석)입니다. 지금은 제품 설계의 작은 SW 기능을 보는 DFMEA 예제로 생각하시면 됩니다.

PFMEA(Process Failure Mode and Effects Analysis, 공정 고장모드 및 영향 분석)는 만드는 과정을 봅니다. 예를 들어 잘못된 소프트웨어를 제품에 넣는 공정이나 검사 누락을 다루는 쪽이지요.

FMEA-MSR(Supplemental FMEA for Monitoring and System Response, 감시 및 시스템 반응을 위한 보완 FMEA)은 운전 중 이상을 알아차리고 시스템이 반응하는 방식을 보완 분석합니다. MSR은 Monitoring(감시)과 System Response(시스템 반응)를 뜻합니다. 설계 분석표에 진단 코드 칸 하나를 붙이면 끝나는 작업은 아닙니다.

‘수행’과 ‘작성’, 어느 말이 맞나요?

둘 다 쓰지만 범위가 다릅니다. 팀이 분석·평가·개선·효과 확인을 하는 전체 활동은 FMEA를 수행한다, 결과를 표에 기록하는 일은 FMEA를 작성한다고 말합니다. 변경을 반영하면 개정·갱신한다고 하세요. “FMEA를 수행하고 결과표를 작성·갱신한다”로 기억하면 됩니다. 표 작성 완료가 분석과 조치의 완료를 뜻하지는 않습니다.

언제 시작하고, 언제 다시 보나요?

DFMEA는 제품 구상과 기능·요구·구조를 정하는 개발 초기부터 시작합니다. 설계 확정 전에 분석 결과로 설계를 바꿀 수 있어야 합니다. 처음에는 미확정 조건을 표시한 초안으로 시작하고, 설계·검증 결과가 구체화되면 갱신합니다.

PFMEA는 공정 흐름과 제조 방법을 계획할 때 시작합니다. 설비·치구·검사 방법 확정 전에 위험을 검토하고, 시험 생산 결과를 반영합니다. 양산 중에도 설계·공정 변경, 새로운 사용 조건, 시험 실패나 현장 문제가 생기면 관련 행과 조치를 다시 봅니다. 제출 직전에 한 번 만들고 끝내는 문서가 아닙니다.

고객사에는 언제 제출하나요?

공통 제출 날짜는 없습니다. 프로젝트 시작 때 고객별 요구사항, 개발 일정, 제출물 목록과 부품승인 절차를 확인하세요. 합의한 설계·공정 검토 시점에 초안이나 갱신본을 검토받고, 부품승인 단계에는 요구된 최신 자료를 준비하도록 일정을 잡습니다.

PPAP(Production Part Approval Process, 생산부품 승인 절차)에는 FMEA 관련 요구가 있습니다. 어떤 FMEA를 준비하고 원문을 제출할지, 보관 후 요청 시 보여줄지, 누구의 검토·승인이 필요한지는 설계 책임·제출 수준·고객 요구에 따라 확인합니다. 별도 부품승인 절차를 쓰는 고객도 그 고객 기준을 따릅니다. PPAP 때까지 분석을 미루라는 뜻은 아닙니다.

가상 일정 예: 설계 검토 전 DFMEA 초안 → 공정 준비 검토 전 PFMEA 갱신본 → 부품승인 기한 전 요청된 최신 FMEA 자료. 실제 날짜와 검토 횟수는 고객과 합의합니다. 담당자에게 “어떤 FMEA·버전을, 언제까지, 어떤 형식으로, 누가 확인해 제출하나요?”라고 물어보세요. 전달과 고객의 검토·승인은 별개이며, 남은 조치를 숨기고 완료로 표시하면 안 됩니다.

첫 회의에 가져갈 것과 오늘 남길 것

첫 회의에는 요구사항, 구조도와 인터페이스 자료, 관련 설계 설명을 가져오세요. 요구사항은 ‘무엇을 어떤 조건에서 해야 하는지’를 정한 문서이고, 인터페이스는 요소 사이에 주고받는 정보와 조건입니다. 기존 검토·시험과 알려진 문제도 가져오세요. 자료 버전을 남겨야 설계 변경 전후를 비교할 수 있습니다.

혼자 모든 칸을 맞히려 하지 않으셔도 됩니다. 시스템 담당자에게는 상위 냉각 요구와 영향을, SW 담당자에게는 상태 처리와 원인 후보를, HW 담당자에게는 구동부 연결을 물어봅니다. 시험 담당자는 그 실패를 관찰할 수 있는지 함께 살펴봅니다. 모르는 조건은 빈칸을 추측으로 채우기보다 ‘확인 필요’로 쓰고, 누구에게 확인할지도 남기세요.

첫 작업 결과는 거창할 필요가 없습니다. 종이 한 장에 ‘대상: 명령 유효성 관리’를 적고, 자료 버전과 분석 범위를 붙인 뒤 기능·원인 후보·고장모드·영향을 각각 한 문장으로 써보세요. 실제 적용에는 프로젝트가 정한 공식 양식과 판단 기준이 필요하며, 이 한 줄은 전체 FMEA가 아닌 첫 초안입니다.

다음 편에서는 이 한 줄을 표에 옮기고, 현재 검토·시험의 범위를 함께 읽어보겠습니다.