이전에 다루었던 FHA, IHA, PHA는 시스템을 거대한 하나의 생명체처럼 바라보는 분석 방법이었다. 여러 장기가 서로 신호를 주고받으며 작동하는 것처럼, 시스템도 서로 연결된 하드웨어와 서브시스템 간의 상호작용 속에서 위험이 발생할 수 있다는 전제에서 출발한다. 그러나 우리가 다루는 현대 시스템에는 보이지 않는 또 하나의 세계가 존재한다. 바로 소프트웨어다. 하드웨어가 실제 몸의 장기라면, 소프트웨어는 그 장기들을 움직이게 하는 ‘의도와 규칙의 언어’에 가깝다. 그리고 그 언어는 하나의 안전 코드를 중심으로 위에서 아래로 점차 작고 정교하게 분해되며, 작은 코드 조각들이 서로 대화를 나눌 때 비로소 전체 시스템이 움직인다. 이런 보이지 않는 대화 속에서 발생하는 위험을 다루기 위해 도입되는 분석이 바로 SFMEA다. 하드웨어에서 사용하던 FMEA의 원리를 소프트웨어라는 손에 잡히지 않는 논리 구조에 적용하는 방식이다.
소프트웨어 FMEA가 필요한 이유는 단순하다. 세상이 바뀌었기 때문이다. 과거의 FMEA는 물리적 부품의 고장이 언제, 어떤 확률로, 어떤 환경에서 나타날지를 중심으로 고장의 모드룰 식별하고 평가했다. 하지만 오늘날 시스템의 사고 원인을 살펴보면, 물리적 파손보다도 코드의 로직 오류, 조건 처리 문제, 인터페이스 불일치, 타이밍 오류가 훨씬 더 많은 비중을 차지한다. 하드웨어는 마모나 부담 같은 외적 요인에 의해 ‘언젠가’ 고장 날 수 있지만, 소프트웨어는 한 번 잘못 작성된 로직이 있다면 그 결함은 특정 조건만 갖춰지면 ‘언제든지 반복적으로’ 나타난다. 그래서 소프트웨어의 실패는 확률의 문제가 아니라 구조적 오류의 문제이며, 이러한 특성 때문에 전통적인 FMEA만으로는 소프트웨어 기반 시스템의 위험을 설명하기 어렵다. SFMEA는 바로 이 문제를 정면으로 바라본다.
현재는 하드웨어보다 소프트웨어에서의 결함이 사고의 기폭제가 되는 사례가 압도적으로 많아졌다.
코드의 로직 오류
경계 조건 미처리
통신 지연·타이밍 문제
예외 상황 미핸들링
데이터 타입 오류
인터페이스 불일치
이런 문제는 물리적 고장이 아니라 설계 결함에서 비롯되기 때문에, 전통적인 FMEA만으로는 식별하기 어려우며, 소프트웨어 특유의 오류 생성 메커니즘을 반영한 SFMEA가 반드시 필요하다.
그렇다면 SFMEA는 기존 FMEA와 무엇이 다를까? 가장 큰 차이는 ‘고장의 정의’에 있다. 하드웨어의 고장은 물리적 손상이나 기능 상실을 의미하지만, 소프트웨어의 고장은 그 자체로 고장이 아니다. 소프트웨어는 부서지지 않는다. 대신 설계나 구현의 논리 구조가 잘못되면 부적절한 판단, 예상하지 못한 순서, 전달되지 못한 데이터, 처리되지 못한 예외 상황이 형태를 바꿔 오류로 나타난다. 즉, 고장의 본질이 ‘물리적 결과’가 아니라 ‘논리적 잘못’이다. 그렇기 때문에 소프트웨어 FMEA는 고장을 발생시키는 모든 경로를 추적하는 데 집중하고, 기능—모듈—로직—인터페이스로 이어지는 계층적 탐색을 통해 코드가 어떤 상황에서 어떤 방식으로 실패할 수 있을지를 그림처럼 펼쳐낸다. 이는 더 이상 확률을 따지는 작업이 아니라, 존재하는 위험을 논리적으로 증명하는 분석이다.
고장개념:
하드웨어 FMEA: 물리적 Failure 중심
소프트웨어 FMEA: 논리적 Fault/Defect 중심
고장 원인:
하드웨어 FMEA: 마모, 파손, 전기적 고장 등
소프트웨어 FMEA: 코드 오류, 잘못된 조건 처리, 인터페이스 mismatch 등
고장 발생 방식:
하드웨어 FMEA: 확률 기반(수명·환경 영향)
소프트웨어 FMEA: 결정적(deterministic) — 존재하는 오류는 언젠가 반드시 발생
분석 단위:
하드웨어 FMEA: 부품(Components)
소프트웨어 FMEA: 기능(Function), 모듈(Module), 로직(Logic), 인터페이스
고장 발생 방식:
하드웨어 FMEA: 확률 기반(수명·환경 영향)
소프트웨어 FMEA: 결정적(deterministic) — 존재하는 오류는 언젠가 반드시 발생
사고 전개:
하드웨어 FMEA: 물리적 연쇄
소프트웨어 FMEA: 잘못된 판단·명령으로 확산
SFMEA의 수행 과정은 마치 보이지 않는 지도를 하나씩 밝혀가는 과정과 비슷하다. 먼저 분석자는 어떤 소프트웨어 기능을 들여다볼지 범위를 정한다. 그 기능이 어떤 입력을 받아 어떤 판단을 하고 어떤 출력을 내는지 간단한 그림으로 흐름을 정리하면서, 서로 어떤 인터페이스를 갖는지 개론적인 구조를 잡는다. 이후에는 상위 기능을 더 작은 기능으로 나누어 각각이 수행해야 하는 역할과 의존 관계를 이해한다. 그렇게 기능 단위로 내려가다 보면, 어떤 부분에서 잘못된 판단이 일어날 수 있는지, 어떤 변수나 조건이 예상하지 못한 결과를 만들 수 있는지 하나씩 드러난다. 예외 처리가 누락된 구간, 데이터 포맷이 맞지 않을 가능성, 타이밍이 조금만 어긋나도 문제를 일으키는 코드 등, 잠재적 실패 모드가 서서히 표면으로 떠오른다. 이후 분석자는 이러한 실패가 왜 발생하는지를 소프트웨어 요구사항, 설계 오류, 외부 모듈과의 호환성 문제 등으로 추적하며, 각각의 실패가 시스템 전체에 어떤 영향을 퍼뜨릴지 정성적으로 검토한다. 마지막으로 발견된 위험을 해결하기 위한 설계 보완, 로직 정제, 인터페이스 규정 강화, 테스트 케이스 생성 등을 수행하며 분석은 하나의 문서로 완성된다. 이 모든 과정은 실제 시스템이 움직이기 훨씬 전, 코드가 컴파일되기 전 단계에서 이루어진다는 점에서 큰 의미를 가진다.
아래 단계는 항공·방산·원전 등에서 통용되는 SFMEA 절차를 정리한 것이다.
1) 분석 범위 정의
어떤 기능/모듈/서브루틴을 분석할 것인지 결정
입력–처리–출력 흐름을 간단한 블록 다이어그램으로 정리
인터페이스 대상(센서, Actuator, 다른 소프트웨어 모듈) 명시
2) 기능(Function) 단위 분해
상위 기능을 더 작고 테스트 가능한 단위로 분리
각 기능의 목적, 수행 조건, 의존성 식별
3) 잠재적 실패모드 도출
각 기능이 어떻게 잘못될 수 있는지 체계적으로 탐색한다. 예:
잘못된 값 계산
조건식 논리 오류
무한 루프
예외 미처리
값 Overflow/Underflow
인터페이스 데이터 포맷 불일치
타이밍/동기화 오류
4) 실패 원인 분석
요구사항 결함
설계 미비
통신 지연
코드 구현 오류
데이터 처리 규칙 미준수
외부 모듈과의 프로토콜 불일치
5) 실패 영향(Efffect) 평가
모듈 수준 영향
서브시스템 수준 영향
전체 시스템 영향
안전·운용 측면에서의 파급효과 등
6) 심각도/발견 가능성 평가
하드웨어 FMEA처럼 RPN을 쓸 수도 있으나, 소프트웨어는 비교적 결정적이므로 SwCI 레벨로 평가하는 경우가 많다.
Note:
SwCI: 특정 소프트웨어가 시스템의 안전성·무결성에 어느 정도 영향을 미치는지를 등급(Level)으로 구분한 기준
SwCI Level은 왜 필요한가?
시스템 전체의 안전 무결성 등급(SIL, DAL 등)을 그냥 소프트웨어 전체에 동일하게 적용하면, 중요하지 않은 부분까지도 과도한 기준을 적용하게 되어 비효율적 개발, 불필요한 검증 비용이 발생한다. 그래서 소프트웨어 내부에서도 “어떤 부분이 안전에 진짜로 중요한지” 구분해야 하는데,
이때 사용되는 것이 바로 SwCI Level이다.
SwCI Level의 의미 (개념적 설명)
일반적으로 SwCI Level은 다음과 같은 의미를 갖습니다:
- 높은 Level: 해당 소프트웨어 기능이 실패하면 시스템 안전에 직접적·심각한 영향을 미침 → 더 엄격한 개발 표준, 검증 활동, 테스트 강도가 요구됨
- 낮은 Level: 실패해도 안전성 영향이 적거나 다른 보호장치가 있음
→ 요구되는 검증 수준이 상대적으로 낮음
즉, 소프트웨어 요소별 ‘안전 기여도’를 구분하는 기준이며, 이를 바탕으로 개발·검증 활동을 차등 적용하는 방식이다.
7) 설계·코드 개선책 정의
요구사항 명확화
예외 처리 추가
인터페이스 제약조건 강화
타이밍 검증 로직 구현
State Machine 정제
단위 테스트 강화
정적 분석 도구 적용
8) 개선 검증 및 문서화
수정된 로직의 테스트 케이스 생성
추적성(Traceability) 확보
리뷰·검증 기록 작성
SFMEA의 강점은 단순히 결함을 찾는 데 그치지 않는다. 소프트웨어가 정의한 ‘보이지 않는 규칙’이 시스템의 목적과 얼마나 잘 맞아떨어지는지를 검증하는 과정이기도 하다. 특히 여러 모듈이 복잡하게 얽혀 움직이는 현대 시스템에서는, 실제 사고의 상당수가 인터페이스 문제에서 비롯된다. SFMEA는 이러한 상호작용의 취약지점을 드러내어, 설계 단계에서 조기에 대응할 수 있도록 한다. 나아가 분석 과정에서 도출된 위험 요소들은 요구사항 문서나 안전 요구 문서로 이어지며, 이후의 코드 구현과 테스트 기준을 형성하는 기반이 된다. 즉 SFMEA는 단순히 분석 도구가 아니라 안전 요구사항을 만들어내는 핵심 엔진이다.
보이지 않는 논리적 결함을 조기에 드러낸다:
코드는 눈으로 보이지 않지만, 잘못된 한 줄이 시스템 전체를 오작동시킨다. SFMEA는 이러한 위험을 구조적으로 끌어올린다.
요구사항–설계–구현 사이의 정합성을 높인다:
소프트웨어는 단계마다 다른 사람이 작업할 때가 많다. SFMEA는 틀어지는 부분을 정리하는 역할을 한다.
인터페이스 기반 위험을 미리 식별:
여러 모듈이 대화하며 움직이는 시스템이기 때문에, 데이터 포맷·타이밍·프로토콜 문제를 조기에 발견할 수 있다.
안전 요구사항 도출의 기반이 된다:
SFMEA에서 나온 위험 항목은 이후 SRS(Safety Requirements Specification)을 결정하는 핵심 재료가 된다.
이러한 특성 덕분에 SFMEA는 많은 산업에서 필수적으로 자리 잡고 있다. 항공기의 비행제어 로직, 자율주행 차량의 판단 알고리즘, 철도 신호 시스템, 의료기기의 제어 소프트웨어, 발전소의 감시·제어 시스템 등, ‘한 줄의 코드 오류가 사람의 생명과 직접 연결될 수 있는 분야’일수록 SFMEA는 초기 단계에서 반드시 수행된다. 코드는 하드웨어처럼 눈에 보이지 않지만, 그 논리의 흐름은 기계보다 더 넓은 충격을 만들어낼 수 있기 때문이다.
SFMEA는 특히 논리적 판단이 안전과 직결되는 산업에서 SwCI level과 함께 매우 중요하게 사용된다:
항공기 비행제어 소프트웨어 (DO-178 계열)
자율주행 차량 알고리즘 (ISO 26262 소프트웨어 안전 요구사항)
철도 ATP/ATO 제어 로직 (EN 50128/50129)
의료기기 제어 소프트웨어
드론·군용 플랫폼의 임무 컴퓨터
발전소의 감시·제어 시스템(SCADA) (디지털 계측제어)
로봇 제어 및 작업 경로 생성 시스템
각 산업마다 세부 등급 이름은 조금씩 다르지만, “소프트웨어 구성요소의 안전 기여도에 따른 분류”라는 목적은 동일하다.
결국 SFMEA는 프로그램을 단순한 텍스트가 아닌 하나의 ‘논리적 생명체’로 보고, 그 생명체가 어떤 상황에서 잘못된 행동을 보일지 미리 상상하는 작업이다. 그리고 그 상상력은 단순히 사고를 예방하는 것을 넘어, 시스템을 더 정교하게 만들고 설계 품질을 끌어올리는 기반이 된다. 보이지 않는 위험을 드러내는 분석, 그것이 바로 SFMEA가 존재하는 이유다.