소프트웨어 안전성 확보를 위한 위험 분석과 검증

위해를 막는 소프트웨어의 조건

소프트웨어 안전성(Software Safety)은 시스템이 인명, 재산, 환경에 위해를 일으키지 않도록 하는 소프트웨어의 능력이다. 기능이 요구사항대로 동작하는지와 별개로, 잠재적 위험을 예방하고 통제하는 관점까지 포함한다.

안전성 판단에는 다음 상태가 함께 고려된다.

수용불가능 위험(Unacceptable Risk): 절대 발생해서는 안 되는 위험 수준
허용가능수준(Tolerable Level): 합리적으로 수용 가능한 위험 정도
위험 억제(Risk Mitigation): 위험을 허용 가능한 수준으로 감소시키는 활동
안전 상태(Safe State): 위험 상황에서도 피해를 최소화하는 시스템 상태

생명주기 단계에 맞춰 안전성을 분석하는 방법

안전성은 특정 테스트 단계에서만 확인할 수 있는 속성이 아니다. 개발 산출물을 검토하고, 요구사항에서 위험을 찾고, 구현을 방어적으로 만들며, 마지막에는 요구사항 충족을 검증하는 흐름으로 다뤄야 한다.

산출물에서 안전 요구사항의 흔적 확인하기

개발 중 만들어지는 문서와 결과물을 검토해 안전성 요구사항이 반영됐는지 확인한다. 검토 대상에는 요구사항 명세서, 시스템·소프트웨어 설계 문서, 소스 코드, 테스트 계획 및 결과, 사용자 매뉴얼이 포함된다.

동료 검토(Peer Review), 워크스루(Walkthrough), 인스펙션(Inspection), 기술적 검토(Technical Review)를 통해 산출물을 점검할 수 있다.

요구사항 단계에서 위험을 안전 요구사항으로 바꾸기

초기 요구분석 단계에서는 시스템이 만들 수 있는 위험을 식별하고, 이를 안전 요구사항으로 구체화한다.

FSD(Functional Safety Design)

기능 안전성 설계는 시스템이 안전 기능을 올바르게 수행하도록 하는 데 초점을 둔다. 안전 기능과 비안전 기능을 명확히 구분하고 격리하도록 설계한다.

FHA(Functional Hazard Analysis)

FHA는 시스템 기능이 실패했을 때 발생할 수 있는 위험을 분석한다. 기능별 위험 수준을 평가해 안전 요구사항을 도출하며, 항공기 자동착륙 시스템의 기능 실패 분석이 예가 될 수 있다.

PHA(Preliminary Hazard Analysis)

PHA는 초기 설계 단계에서 시스템 수준의 위험을 찾는 분석이다. 위험 목록과 초기 위험 평가를 작성하고, 주요 안전 요구사항을 도출하는 기초 자료로 사용한다.

⤢✕

FTA(Fault Tree Analysis)

FTA는 최상위 위험 사건에서 출발해 하위 원인으로 거슬러 내려가는 하향식 분석 기법이다. AND, OR 논리 게이트로 위험 원인의 조합을 표현하며, 정량적·정성적 위험 평가에 활용할 수 있다. 의료기기 과다 방사선 노출의 원인 체계 분석이 예다.

⤢✕

HAZOP(Hazard and Operability Study)

HAZOP은 안내어(가이드워드)를 사용해 이탈 상황을 체계적으로 분석한다. 시스템 파라미터에 가이드워드를 조합해 위험을 찾는다. 일반적 가이드워드로는 No/None, More, Less, As Well As, Part Of, Reverse, Other Than이 있다. 화학 공정 제어 시스템에서는 More 온도를 과열 위험으로 분석할 수 있다.

FMEA(Failure Mode and Effects Analysis)

FMEA는 컴포넌트 수준에서 고장 모드와 그 영향을 찾는 상향식 분석 기법이다. 고장의 심각도, 발생 가능성, 검출 가능성을 평가하고 RPN(Risk Priority Number) 계산으로 위험 우선순위를 결정한다. 자동차 브레이크 시스템의 컴포넌트별 고장 분석에 적용할 수 있다.

⤢✕

구현에서 오류를 안전 상태로 가두기

코딩 단계에서는 테스트와 방어적 프로그래밍으로 구현의 안전성을 높인다.

블랙박스 테스팅은 내부 구조를 보지 않고 입출력만으로 시스템을 시험한다. 동등 분할(Equivalence Partitioning), 경계값 분석(Boundary Value Analysis), 결정 테이블(Decision Table), 상태 전이 테스팅(State Transition Testing)이 주요 기법이다.

화이트박스 테스팅은 코드와 내부 구조를 고려한다. 구문 커버리지(Statement Coverage), 결정·분기 커버리지(Decision/Branch Coverage), 조건 커버리지(Condition Coverage), MC/DC(Modified Condition/Decision Coverage), 경로 커버리지(Path Coverage)를 사용한다.

방어적 프로그래밍에서는 예외 처리(Exception Handling), 입력 유효성 검증(Input Validation), 자원 누수 방지(Resource Leak Prevention), 안전한 메모리 관리(Safe Memory Management), 중복성 및 다양성(Redundancy and Diversity), 디버그 로깅(Debug Logging)을 적용한다.

안전 요구사항을 수학적으로 검증하기

도출한 안전 요구사항이 구현에 반영됐는지 확인하려면 정형적 방법을 사용할 수 있다.

정형적 명세(Formal Specification)는 수학적 표기법으로 요구사항을 모호하지 않게 표현하는 방식이다. Z 표기법, VDM(Vienna Development Method), B-Method, CSP(Communicating Sequential Processes)가 주요 기법이다.

정형적 검증(Formal Verification)은 수학적 증명을 통해 소프트웨어가 명세를 만족하는지 검증한다. 모델 검증(Model Checking), 정리 증명(Theorem Proving), 추상 해석(Abstract Interpretation), 등가성 검사(Equivalence Checking)가 여기에 속한다.

⤢✕

산업 환경에 따라 달라지는 안전성 기준

항공 우주 산업에서는 DO-178C를 항공 소프트웨어 안전성 표준으로 사용한다. 안전성 수준은 A(치명적)부터 E(영향 없음)까지 5단계로 나뉘며, 수준에 따라 요구되는 검증 활동도 달라진다. FTA와 FMEA를 통한 위험 분석이 필수다.

의료기기 산업의 IEC 62304는 의료기기 소프트웨어 생명주기 프로세스를 다룬다. 소프트웨어 안전 등급에 따른 개발 활동을 정의하며, HAZOP과 FMEA로 위험 분석을 수행한다. 추적성과 변경 관리도 중요하게 다뤄진다.

자동차 산업에서는 ISO 26262가 자동차 기능 안전 표준 역할을 한다. ASIL(Automotive Safety Integrity Level)은 A-D 등급으로 분류되며, FTA와 FMEA 등의 분석 기법을 적용하고 HW-SW 인터페이스 안전성 확보를 강조한다.

철도 산업의 IEC 62279는 철도 시스템 소프트웨어 안전성 표준이다. SIL(Safety Integrity Level)은 1-4 등급으로 구분한다. 정형 명세와 검증을 적극 활용하고, 다양성과 중복성 설계 원칙을 적용한다.

안전성을 개발 흐름 안에 정착시키기

안전성은 초기 요구사항 단계부터 고려해야 한다. 안전성 요구사항의 추적성을 확보하고, 변경 관리와 형상 관리에 연결하며, 위험을 지속적으로 모니터링하고 평가하는 방식이 필요하다.

분석 기법을 하나만 적용하기보다 여러 안전성 분석 기법을 조합하고, 설계 단계에서 안전 메커니즘을 구현해야 한다. 런타임 모니터링과 방어적 프로그래밍을 함께 적용하며, 고장을 감지했을 때 안전 상태로 전환할 수 있어야 한다.

기술적 통제만으로는 충분하지 않다. 안전성 마인드셋, 효과적인 의사소통과 지식 공유, 지속적인 교육과 역량 강화, 사고 및 근접 오류 분석과 학습이 함께 뒷받침돼야 한다. 안전-필수 시스템에서는 산업별 표준과 정형적 방법론을 상황에 맞게 적용해 수용불가능한 위험을 억제하고 허용가능한 안전 수준에 도달해야 한다.