FMEA[VisualPro Tech Brief] 안전 분석에서 나온 개선 조치, 지금 몇 건이 완료됐습니까?
요약
FMEA(고장 형태 및 영향 분석)나 STPA(시스템 이론 기반 위험 분석) 같은 안전 분석을 마치면, 찾아낸 고장원인마다 개선 조치가 나옵니다. 분석 표준은 조치에 책임자, 목표일, 상태, 증거를 적으라고 요구합니다. 그런데 분석 파일이 승인된 뒤 그 칸을 매주 누가 확인하는지는 정해져 있지 않은 경우가 많습니다. 프로젝트 매니저(PM)에게 이 조치들은 리스크 대장과 이슈 일정의 일부인데, 정작 PM의 일정표에는 들어와 있지 않은 경우가 많습니다. 이 글은 변속기 설계 FMEA(DFMEA)의 개선 조치 12건을 Recoble 워크보드로 옮겨, 안전 엔지니어는 고장원인별 추적을, PM은 담당·기한·지연 현황을 한 곳에서 보는 방법을 보여 줍니다.
분석은 승인됐는데, 조치는 누가 보고 있습니까?
분석 보고서가 승인되는 날은 분석팀에게는 끝이지만, 위험 측면에서는 시작입니다. 분석에서 정한 개선 조치가 설계와 시험, 정비 문서에 실제로 들어가야 위험이 줄어듭니다.
아래 화면은 VisualPro의 변속기 DFMEA 예제 프로젝트 중 6단계(최적화)입니다. 조치 우선순위(AP)가 H나 M인 고장원인 12건에 예방·검출 조치가 모두 적혀 있고, 조치 후 AP도 전부 L로 예측되어 있습니다. 분석 자체로는 잘 정리된 상태입니다.
조치 행을 하나 선택하면 아래쪽에 책임자, 목표 완료 일자, 상태 칸이 나옵니다. 화면 맨 아래에는 "증거에 대한 포인터로 취해진 조치" 칸도 있습니다.
이 예제의 12건을 조회해 보면 목표 완료 일자는 모두 채워져 있지만, 책임자 칸은 12건 모두 비어 있습니다. 예제 데이터라서 그럴 수 있습니다. 다만 실무에서도 비슷한 일이 생깁니다. 분석 회의에서는 "제어팀이 보기로" 정도로 넘어가고, 그 합의가 파일의 칸까지 내려오지 않는 것입니다.
조치 내용을 보면 사정이 하나 더 보입니다. 12건 중에는 "정비 매뉴얼에 필터 교환 주기 명시"처럼 설계팀 밖에서 처리해야 하는 일이 섞여 있습니다. 또 두 고장원인(유압 밸브 고착으로 인한 기어 변속 불능, 유압 제어 불능)은 완전히 같은 조치를 공유합니다. 분석 표에서는 두 줄이지만 실제로 처리할 일은 하나입니다.
PM에게 이 조치는 무엇인가: 리스크 대장과 이슈 일정의 빠진 줄
PM이 쓰는 리스크 대장(risk register)과 이슈 로그에는 보통 리스크마다 담당자, 대응 계획, 상태, 기한이 있습니다. FMEA에서 찾은 고장원인은 제품 리스크이고 리스크 대장은 주로 프로젝트 리스크를 다루니 대상은 다릅니다. 그래도 관리할 정보는 같습니다. 고장원인이 리스크이고, 예방·검출 조치가 대응 계획이며, 목표 완료일이 기한입니다.
그런데 두 목록은 대개 따로 삽니다. 안전 분석은 분석 도구 안에, 프로젝트 일정은 PM의 간트 차트나 이슈 트래커 안에 있습니다. 그래서 PM은 "AP가 H였던 조치 중 이번 달 기한인 것이 몇 건인지", "시험평가팀에 몰린 조치가 시험 일정과 겹치는지"를 분석 담당자에게 물어봐야 압니다. 안전 조치가 늦어지면 결국 일정 리스크가 되는데, 그 신호가 PM 화면에는 늦게 도착합니다.
기존 체계는 무엇을 묻고, 무엇을 묻지 않는가
조치를 관리하는 체계는 이미 있습니다. 먼저 이 체계들이 무엇을 요구하는지 인정하고 시작하겠습니다.
| 기존 체계 | 묻는 것 | 묻지 않는 것 |
|---|---|---|
| AIAG-VDA FMEA 핸드북 6단계(최적화) | 조치마다 책임자, 목표 완료일, 상태, 취해진 조치와 증거, 조치 후 S·O·D와 AP를 기록했는가 | 분석이 끝난 뒤 그 칸을 매주 누가 확인하는지, 여러 팀에 걸친 조치를 어디서 한눈에 보는지 |
| STPA Handbook (Leveson & Thomas, 2018) | 손실 시나리오에서 요구사항·제약을 빠짐없이 끌어냈는가 | 끌어낸 요구사항과 대책을 프로젝트 안에서 누가, 언제까지 완료하는지 |
| ISO 26262-8 6절 (안전 요구사항의 명세와 관리) | 안전 요구사항이 명세·추적·검증되는가 | 소프트웨어 요구사항이 아닌 조치(정비 문서, 공급사 확인)를 어디에서 관리할지 |
| 프로젝트 리스크 대장·이슈 로그 | 리스크·이슈마다 담당, 대응, 상태, 기한이 있는가 | 그 리스크가 어느 고장원인에서 나왔고, 대응이 분석상 AP를 얼마나 낮추는지 |
| ALM·이슈 트래커(Polarion, codebeamer, Jira 등) | 등록된 요구사항·이슈의 상태와 추적성 | 등록되지 않은 조치, 소프트웨어 팀 밖 담당자의 조치 |
AIAG-VDA 핸드북은 이미 책임자와 증거를 적으라고 합니다. 리스크 대장도 담당과 기한을 요구합니다. 새로 요구할 것은 없습니다. 물어야 할 것은 "그 칸이 실제로 채워지고, 누군가 매주 보고 있는가", 그리고 "안전 분석의 조치와 프로젝트 일정이 같은 화면에 있는가"입니다. 틈은 요구사항이 아니라 운영에 있습니다.
규칙 세 가지
도구보다 규칙이 먼저입니다. 아래 세 가지를 지키면 엑셀이든 ALM이든 추적이 됩니다.
AIAG-VDA 6단계에 이미 들어 있는 원칙을 분석 파일 밖에서도 지켜지게 만드는 장치라고 보면 됩니다. 이 세 가지는 PM의 리스크 대장 규칙과도 그대로 겹칩니다.
실제로 옮겨 본 과정: 변속기 DFMEA → Recoble
VisualPro의 변속기 DFMEA에서 AP H·M 고장원인 12건과 조치를 읽어 Recoble 워크스페이스에 옮겼습니다. 분석 데이터는 VisualPro MCP로 조회했고 Recoble 쪽 노트·워크보드·링크도 MCP로 만들었습니다. 사람이 손으로 옮겨도 구성은 같습니다.
1) 고장원인은 노트로 (안전 엔지니어의 근거)
고장원인 하나를 노트의 제목 하나로 두고, 그 아래에 구조, 기능, 고장형태, S/O/D, AP, 현재 예방·검출 관리를 표로 넣었습니다. 분석의 판단 근거가 이 노트에 남습니다.
2) 조치는 워크보드 항목으로 (조치·이슈 목록)
조치 하나가 항목 하나입니다. 같은 조치를 공유하는 두 고장원인(FC-01, FC-03)은 항목 하나로 합쳐 12건이 11건이 됐습니다. 사용자 정의 필드로 고장원인 번호, 담당팀, 조치 전후 AP, 심각도, 완료 조건, 검증 증거(파일)를 붙였습니다. 목표 완료일과 진행 상태(계획 → 시작 전, 진행 중 → 진행 중)는 VisualPro 값을 그대로 옮겼습니다. 담당팀은 이 글을 위해 조치 내용에 맞춰 예시로 배정한 값입니다.
담당자(사람) 열은 일부러 비워 두었습니다. 원본에 책임자가 없었기 때문입니다. 이 열이 비어 있다는 사실이 보드에서 바로 보인다는 점이 중요합니다. 주간 회의에서 "담당자 없는 조치 11건"을 화면 하나로 확인할 수 있습니다.
3) 링크로 고장원인과 조치를 잇고, 추적 표로 빈칸을 찾는다
「대책 / 대응 고장원인」이라는 링크 유형을 만들어 노트의 고장원인 제목과 워크보드 항목을 이었습니다. Recoble 추적 화면의 표 보기는 문서를 순서대로 놓고 링크를 따라 한 줄씩 펼칩니다.
12건이 모두 "연결됨"으로 나오고, FC-01과 FC-03이 같은 조치로 이어진 것도 보입니다. 마지막 줄의 "누락 1"은 고장원인이 아니라 노트 문서 전체를 나타내는 행입니다. 상단의 연결 누락 필터를 켜면 처리 결과가 붙지 않은 고장원인만 남으므로, 규칙 1을 회의 전에 점검하는 화면이 됩니다.
4) 같은 항목을 간트 차트로 (PM의 일정 화면)
PM에게는 같은 조치를 일정으로 보는 화면이 필요합니다. 워크보드에 간트 보기를 추가하면, 조치 11건이 목표 완료일까지의 막대로 펼쳐집니다. 별도 일정표를 만들지 않고 같은 데이터를 다른 보기로 보는 것이라, 분석 쪽에서 기한을 바꾸면 PM 화면도 함께 바뀝니다.
이 예제에서는 11월 30일(가터 스프링 홈 형상 변경)이 가장 이른 기한이고, 12월 중순부터 2027년 1월 중순 사이에 기한이 몰려 있습니다. 항목 사이에 선후 관계를 걸어 두면, 시험 일정처럼 다른 조치를 막는 항목이 무엇인지도 일정 위에서 볼 수 있습니다.
5) 대시보드로 매주 본다 (PM과 품질 관리자의 주간 점검)
전체 조치, 완료율, 기한 초과, 완료 건수와 상태·담당팀·AP 변화 분포를 대시보드 하나에 모았습니다. 오늘 기준으로 11건 모두 미완료이고 기한 초과는 아직 없습니다. 담당팀별로는 기구설계팀 5건, 제어SW팀 4건, 유압설계팀 2건입니다.
회의에서 결정이 필요한 항목(예: 조치를 하지 않기로 한 결정)은 회의 노트에 남기고 해당 항목에 링크합니다. 나중에 "왜 이렇게 정했나"를 항목에서 바로 찾을 수 있습니다.
이미 ALM이나 이슈 트래커를 쓰고 있다면
소프트웨어 안전 요구사항의 정본은 ALM에 두는 것이 맞고, 이중 관리는 피해야 합니다. 이 경우 워크보드는 두 가지 역할만 맡습니다. 하나는 정비 문서나 공급사 확인처럼 ALM에 넣기 어색한 조치를 같은 규칙으로 관리하는 장소입니다. 다른 하나는 고장원인별로 어떤 조치가 ALM의 어느 ID로 등록됐는지 이어 두는 작업 공간입니다. ALM이 없는 작은 팀이나 연구 과제라면 워크보드 하나로 전체를 운영해도 됩니다.
내일 확인할 것
- 지난 분석에서 AP H·M 고장원인(또는 손실 시나리오) 가운데 처리 결과가 비어 있는 것은 몇 건입니까?
- 조치하지 않기로 한 항목에 근거와 결정자가 남아 있습니까?
- 조치마다 "무엇이 있으면 완료인지" 완료 조건이 적혀 있습니까?
- 조치 책임자 칸이 비어 있는 건은 몇 건입니까?
- 안전 분석의 조치가 프로젝트 리스크 대장이나 일정표에 들어와 있습니까?
- 이번 달 기한인 AP H 조치는 몇 건이고, 담당 팀의 다른 일정과 겹치지 않습니까?
- 설계팀 밖(정비, 공급사, 시험)이 맡아야 하는 조치의 담당자는 자기 항목을 알고 있습니까?
마무리
자주 묻는 질문
Q1FMEA 도구에 책임자와 목표일 칸이 있는데, 별도 관리가 필요한가요?
칸을 채우는 것과 매주 확인하는 것은 다른 일입니다. 분석 도구는 분석하는 사람이 여는 곳이라서, 조치 담당자와 PM이 매주 보는 화면이 따로 있으면 칸이 비거나 기한이 지난 것이 드러납니다. 분석 도구의 값을 정본으로 두고, 워크보드는 진행 확인용으로 쓰는 구성을 권합니다.
Q2FMEA 조치를 프로젝트 리스크 대장에서 관리해도 되나요?
됩니다. 다만 리스크 대장만 쓰면 그 리스크가 어느 고장원인에서 나왔는지, 조치 뒤 AP가 어떻게 바뀌는지가 끊기기 쉽습니다. 이 글의 구성은 고장원인 노트와 조치 항목을 링크로 이어 두어, PM은 일정과 담당을, 안전 엔지니어는 근거와 추적을 같은 데이터에서 봅니다.
Q3안전 조치 일정이 늦어지면 어떻게 알 수 있나요?
워크보드 항목의 목표 완료일이 지나면 대시보드의 기한 초과 숫자가 올라가고, 간트 보기에서는 오늘 선보다 앞에서 끝난 채 미완료로 남은 막대로 보입니다. 주간 회의를 이 두 화면으로 시작하면 지연이 회의 안건으로 바로 올라옵니다.
Q4고장원인마다 조치를 꼭 하나씩 만들어야 하나요?
아닙니다. 이번 예제처럼 조치 하나가 고장원인 둘을 다룰 수 있습니다. 규칙은 "고장원인마다 처리 결과가 비어 있지 않다"입니다. 처리 결과는 기존 조치와의 연결이어도 되고, 근거를 적은 미조치 결정이어도 됩니다.
Q5STPA 결과에도 같은 방식을 쓸 수 있나요?
쓸 수 있습니다. 고장원인 자리에 손실 시나리오를, 조치 자리에 안전 요구사항과 대책을 놓으면 구성은 같습니다. STPA 대책에는 운영 절차나 HMI 문구처럼 소프트웨어 밖 항목이 더 많아서 이 구성이 더 쓸모 있을 수 있습니다.
Q6AI가 조치를 자동으로 만들어 주나요?
이번 예제에서 AI는 분석 데이터를 읽어 노트와 항목으로 옮기고 링크를 거는 일을 했습니다. 무엇을 조치로 삼을지, 조치하지 않기로 한 결정이 타당한지는 분석자와 책임자가 판단합니다.
- AIAG & VDA, FMEA Handbook, 1st Edition, 2019.
- ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes.
- Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide).
- Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT, 2018 — psas.scripts.mit.edu
- MIT PSASS, STAMP Tools — psas.scripts.mit.edu/home/stamp-tools
이 글의 분석 데이터는 VisualPro의 변속기 DFMEA 예제 프로젝트이며 특정 고객사의 실적이 아닙니다. 담당팀 배정은 설명을 위한 예시입니다. 화면은 2026년 10월 19일 Recoble·VisualPro에서 캡처했습니다. 발행: VWAY(VisualPro·Recoble 개발사).