요구분석 단계에서 FTA·FMEA·HAZOP로 안전 위험을 다루는 방법
FTA, FMEA, HAZOP를 조합해 소프트웨어 요구분석 단계의 위험을 식별하고 정량화하며 안전 요구와 검증 근거로 연결하는 방법을 정리한다.
2026-08-14 · 최초 발행 2025-10-14
안전 위험은 요구가 굳기 전에 구조화해야 한다
안전 필수 소프트웨어의 안전성 분석은 요구분석 단계에서 시작한다. 이 시점에 위험원을 찾아 영향, 발생 가능성, 검출 가능성을 검토해야 전체 생명주기에서 위험을 더 낮은 비용으로 제어할 수 있다.
Software Safety Analysis는 정성적·귀납적 기법인 FMEA와 HAZOP, 정량적·연역적 기법인 FTA를 함께 사용해 위험을 식별하고 평가하며 저감 조치를 설계하는 활동이다. 결과물은 위험 목록(Risk Register), 안전 요구(Safety Requirements), 저감 대책(Controls), 검증 근거(Test Cases, Coverage)로 이어진다.
FMEA와 HAZOP는 가능한 실패나 운영 편차에서 출발해 결과를 추정하는 상향식 접근이다. 반대로 FTA는 최상위 사고에서 시작해 원인의 논리를 펼치고 확률을 계산하는 하향식 접근이다. 초기 요구분석에서는 HAZOP와 FMEA로 위험의 범위를 넓게 잡고, 아키텍처 윤곽이 드러나면 FTA로 주요 사고 시나리오를 정량화하는 흐름이 적합하다.
분석 범위와 증거 체계를 먼저 잡는다
분석 전에 시스템 경계, 운영 시나리오, 외부 인터페이스, 환경 조건을 명확히 해야 한다. 안전 목표와 상위 사고(Top Event)를 정의하고, 분석에 사용한 가정과 제한사항도 함께 관리한다.
초기 설계 단계처럼 데이터가 부족할 때는 HAZOP와 FMEA가 위험을 빠르게 식별하고 우선순위를 매기는 데 적합하다. 고위험 시나리오가 드러난 뒤에는 FTA로 사고 확률과 기여도를 정량화한다.
이 과정에서 정성 분석과 정량 분석은 분리되지 않는다. FMEA의 RPN 또는 중요도가 높은 항목은 FTA의 기본 사건(Basic Event)으로 매핑할 수 있다. HAZOP에서 찾은 편차는 시나리오와 탐지·제어 요구로 연결하고, FTA의 Cut set에 미치는 영향까지 평가한다.
위험, 안전 요구, 설계 제어, 검증 항목은 양방향으로 추적되어야 한다. 표준(예: ISO 26262, IEC 61508, DO-178C/ARP4761, IEC 62304 등, 최신 정보 확인 필요)에 맞춰 근거 산출물 템플릿과 리뷰 게이트를 운영하고, FTA 도구, FMEA 스프레드시트/PLM, 요구관리 도구를 연계한다. 변경관리에서는 버전과 영향분석을 다루며 정기 재평가 주기도 수립한다.
위험 식별부터 검증 계획까지 이어지는 흐름
요구가 모호하면 시나리오를 구체화하고 비기능 요구를 추가한다. 데이터가 부족한 경우에는 보수적 가정을 두고 실험이나 로그 수집, 유사 시스템 데이터 참조를 수행한다. 모델이 실제 시스템과 맞지 않으면 인터페이스와 상태천이를 다시 모델링하고 동적 분석을 수행한다.
FMEA는 기능과 컴포넌트에서 위험을 끌어올린다
FMEA는 기능 분해, 컴포넌트 목록, 고장 유형 라이브러리, 과거 결함을 입력으로 사용한다. 각 항목에서 고장형태, 원인, 영향을 도출하고 심각도(S), 발생도(O), 검출도(D)를 산정한다. 이후 RPN=S×O×D를 계산해 한계값을 정하고 우선순위를 결정한다.
분석 결과로 RPN 상위 리스크, 감지 강화·설계 변경·시험 보강 같은 저감 조치, 잔여 위험 평가를 남긴다. 설계·품질·운영 인력이 함께 크로스체크하고, 척도 정의를 일관되게 적용할 기준과 예시 캘리브레이션 차트를 준비하는 것이 필요하다.
HAZOP은 운영 편차를 시나리오로 풀어낸다
HAZOP은 공정, 데이터 플로우, 상태 다이어그램과 노드 정의를 바탕으로 수행한다. No, More, Less, Early, Late, Reverse 같은 가이드워드를 노드와 조합해 편차를 찾고, 원인·결과·보호계층을 도출한다. 필요하면 LOPA와 연계할 수 있으며, 운영 절차·알람·인터록 요구도 함께 확인한다.
산출물은 편차 목록, 안전 및 운전 요구, 운영 절차와 인터페이스 개선안이다. 워크숍에서는 퍼실리테이션 규칙, 타임박싱, 중복 편차 병합 기준을 운영한다.
FTA는 상위 사고의 원인 구조를 정량화한다
FTA에는 상위 사고 정의, 시스템 논리와 상태, 기본 사건 데이터(λ, pfd, β-공통원인 등)가 필요하다. AND/OR 논리게이트로 원인 구조를 만들고 최소 컷셋을 산출한 뒤 사고 확률 또는 빈도를 계산한다. Birnbaum/CRI 중요도 분석은 각 원인의 기여도를 파악하는 데 사용한다.
결과는 P(top event) ≤ 목표와 같은 정량 위험 지표, 설계 대안 비교 근거, 검증 포커스가 된다. 데이터 불확실성은 분포와 신뢰구간을 포함한 민감도 분석으로 다루고, 시간 종속 사건에는 동적 FTA 또는 마코프/STA 연계를 적용한다.
각 기법이 강점을 보이는 지점
| 항목 | FMEA | HAZOP | FTA |
|---|---|---|---|
| 성능(위험 검출/원인 식별) | 구성요소/기능 수준 강점, 상호작용 누락 가능 | 운영 편차·시나리오 탐색 강점 | 상위 사고 경로·기여도 분석 강점 |
| 확장성(대규모 시스템) | 표준화 시 확장 가능, 관리 비용 증가 | 워크숍 시간·참여자 의존 높음 | 모듈화·재사용으로 확장 용이, 모델링 난이도 있음 |
| 일관성(재현성) | 정의·척도 표준화로 확보 | 퍼실리테이션 품질에 민감 | 모델·데이터 일관성 높음 |
| 안정성(결과 견고성) | 전문가 판단 편차 영향 | 팀 구성·가이드워드 의존 | 데이터 가정에 민감, 민감도 분석으로 보완 |
| 운영 편의(실무 적용성) | 스프레드시트로 즉시 적용 가능 | 초기 워크숍 세팅 필요 | 전문 툴·신뢰성 데이터 필요 |
산업별 안전 분석 연결 방식
자동차에서는 ISO 26262(최신 정보 확인 필요)에 따라 HARA 결과와 기능안전 목표를 설정하고, 시스템 FMEA로 기술안과 진단을 설계한다. 이어 안전 목표 관련 사건을 FTA로 정량화하고 ASIL 수준 달성을 검증한다.
항공에서는 ARP4761/DO-178C(최신 정보 확인 필요)와 FHA/SSA를 연계한다. 시스템 FTA로 최상위 사고 확률 한계 충족 여부를 확인하고, SW-FMEA로 소프트웨어 기능과 데이터 무결성을 확보한다.
의료기기에서는 IEC 62304(최신 정보 확인 필요) 관점에서 HAZOP으로 사용자 인터페이스와 알람 편차를 분석한다. SW-FMEA로 데이터 처리 오류를 저감하고 UTR/시뮬레이션 기반 검증을 수행한다.
프로세스와 플랜트에서는 IEC 61511/HAZOP 중심으로 노드별 HAZOP을 수행하고, LOPA로 보호계층 요구를 결정한다. SIF 설계 후에는 FTA/Markov로 SIL을 정량 검증한다.
초기 분석이 남기는 효과
요구분석 단계에서 적용하면 상위 위험 탐지 리드타임은 미적용 대비 3050% 단축된다. 고위험 결함을 후행 단계 전에 제거하면 결함 수정 비용은 310배 절감되며, 목표 사고 확률 충족률 향상과 인증 리스크 감소로 감사 지적건수도 20~40% 감소한다.
수치로 드러나는 효과 외에도 요구가 명확해지고 팀의 공통 상황 인식이 높아진다. 위험과 검증의 연결이 유지되므로 변경 영향 분석의 신뢰도가 높아지며, 설계 대안을 비교할 때도 더 객관적인 근거를 확보할 수 있다.
요구분석에서는 HAZOP와 FMEA로 위험을 폭넓게 식별하고, 상위 사고는 FTA로 정량화한다. 위험등록부, 안전 요구, 검증계획을 하나의 추적 체계로 묶어 변경관리와 정기 재평가에 연결해야 한다. 데이터 불확실성은 보수적 가정과 민감도 분석으로 관리하고, 표준과 도구 체계를 조기에 도입해 조직 역량으로 정착시킨다.