소프트웨어 안전성 분석과 위험 통제 설계

안전필수 시스템에서 안전성을 따로 다루는 이유

소프트웨어 안전성은 소프트웨어가 위험한 상황을 일으키지 않으면서 의도된 기능을 안전하게 수행하는 성질이다. 자동차, 항공, 의료, 원자력처럼 결함이 인명 손실·심각한 재산 피해·환경 파괴로 이어질 수 있는 안전필수 시스템에서는 이 성질이 개발의 전제가 된다.

신뢰성이 기능을 정확히 수행하는 데 초점을 둔다면, 안전성은 위험 상태 자체를 막는 데 중심을 둔다. 기능이 정상적으로 동작하는지와 별개로, 실패했을 때 어떤 위험으로 이어지는지까지 다뤄야 한다.

위험을 평가하는 기준

위험(Hazard)은 잠재적으로 위험한 상황이나 조건을 뜻한다. 위험성(Risk)은 그 위험이 발생할 가능성과 결과의 심각도를 함께 본 값이며, 다음과 같이 표현할 수 있다.

위험성 = 위험 발생 확률 × 위험 심각도

심각도는 인명 손실이나 시스템 파괴에 이르는 치명적(Catastrophic), 중상 또는 심각한 시스템 손상에 해당하는 심각(Critical), 경상이나 시스템 기능 저하를 뜻하는 한계적(Marginal), 경미한 부상과 미미한 시스템 영향을 뜻하는 경미(Negligible)로 구분할 수 있다.

발생 확률은 지속적으로 발생하는 빈번(Frequent)부터 여러 번 발생할 수 있는 가능성 높음(Probable), 간헐적인 가끔(Occasional), 가능성이 낮은 드묾(Remote), 예외적 상황에서만 일어나는 가능성 희박(Improbable), 발생 가능성이 없는 불가능(Impossible)까지 분류한다.

심각도와 확률을 조합하면 어떤 위험을 허용할 수 있는지 판단하는 매트릭스를 만들 수 있다.

⤢✕

개발 흐름에 맞춰 위험을 좁혀 가는 분석

예비 위험 분석(PHA: Preliminary Hazard Analysis)은 시스템 요구사항을 분석하는 시점에 시작한다. 시스템 수준의 위험과 위험 상황을 찾고, 위험성 평가 기준을 정한 뒤 초기 평가를 수행한다.

시스템 위험 분석(SHA: System Hazard Analysis)은 시스템 설계 단계에서 서브시스템 간 인터페이스, 시스템 기능, 통합 과정의 위험을 상세하게 다룬다.

상세 설계 단계의 서브시스템 위험 분석(SSHA: Subsystem Hazard Analysis)에서는 개별 서브시스템의 기능별 위험, 컴포넌트 수준 위험, HW/SW 인터페이스 위험을 분석한다.

소프트웨어 설계와 구현 단계에서는 소프트웨어 위험 분석(SwHA: Software Hazard Analysis)을 수행한다. 안전 요구사항, 설계, 코드, 인터페이스에 특화된 위험을 대상으로 한다.

시스템 테스트와 배포 단계에는 운영 및 지원 위험 분석(O&SHA: Operating and Support Hazard Analysis)이 이어진다. 운영 절차와 유지보수, 사용자 인터페이스에서 생길 수 있는 위험을 분석한다.

분석 관점에 따라 선택하는 기법

FMEA로 고장 모드와 영향을 추적하기

FMEA(Failure Mode and Effects Analysis)는 잠재적인 고장 모드와 그 영향을 찾는 귀납적 분석 기법이다. 시스템 구성요소를 식별하고, 각 구성요소의 고장 모드와 원인을 정의한 뒤 영향과 위험성 우선순위(RPN)를 평가한다. RPN은 심각도 × 발생도 × 검출도로 산출한다.

자율주행차의 라이다 센서를 예로 들면, 센서 데이터 오류는 환경 간섭이나 하드웨어 결함에서 발생할 수 있다. 그 결과 장애물을 감지하지 못해 충돌 위험이 생길 수 있으며, 중복 센서 시스템과 자가 진단 기능을 개선책으로 둘 수 있다.

FTA로 정상사건의 원인을 거꾸로 찾기

FTA(Fault Tree Analysis)는 원치 않는 사건인 정상사건(Top Event)에서 출발해 원인을 역으로 추적하는 연역적 기법이다. 정상사건을 정하고 직접 원인을 식별한 다음, AND·OR 논리 게이트로 원인을 연결해 기본 사건(Basic Event)까지 분석한다.

⤢✕

HAZOP과 STPA가 보는 위험

HAZOP(Hazard and Operability Study)은 가이드워드로 시스템의 이탈 상황을 체계적으로 찾는다. No/None은 의도된 기능의 완전 부재, More/Less는 양적 증가 또는 감소, As Well As는 추가 기능 발생, Part Of는 일부만 수행, Reverse는 의도와 반대 수행, Other Than은 전혀 다른 기능 수행을 뜻한다. 분석 대상을 정한 뒤 가이드워드를 적용하고, 이탈의 원인과 결과를 분석해 안전 대책을 수립한다.

STPA(System Theoretic Process Analysis)는 시스템 이론을 바탕으로 복잡한 소프트웨어 집약 시스템을 분석하는 방법이다. 시스템 제어 구조를 모델링하고 안전하지 않은 제어 행동(UCA)을 식별한 뒤 원인 시나리오와 안전 제약조건을 도출한다.

코드와 운영에 반영하는 안전 기능

방어적 프로그래밍(Defensive Programming)은 예외 처리, 경계값 검사, 타입 검사 같은 방어 기제를 코드 안에 두는 방식이다. 입력 데이터 유효성 검증과 예외 상황 처리 로직이 여기에 해당한다.

내결함성 설계(Fault Tolerance)는 결함이 발생해도 안전 기능을 유지하도록 구성한다. 다중화(Redundancy), 다양성(Diversity), 독립성(Independence)을 사용하며, 의료기기의 2-out-of-3 로직이나 다중 프로세서 운영이 사례가 된다.

안전 감시(Safety Monitoring)는 시스템 상태를 모니터링하고 이상 상태를 감지해 대응하는 기능이다. 워치독 타이머와 자가 진단 루틴을 활용할 수 있다. Fail-Safe는 결함이 발생했을 때 안전한 상태로 전환하는 방식으로, 원자력 발전소 비상 정지 시스템이 사례다.

안전 대책은 개발 단계마다 달라진다. 설계 단계에서는 안전 요구사항을 명확히 하고 안전 아키텍처를 설계하며, 안전 중요 기능을 분리·격리한다. 구현 단계에서는 MISRA C 같은 안전 코딩 표준, 정적 코드 분석, 강화된 코드 리뷰 프로세스를 적용한다.

검증 단계에서는 안전 요구사항 기반 테스트 케이스, 결함 주입 테스트(Fault Injection Testing), 형식 검증(Formal Verification)을 수행한다. 운영 단계에서는 안전 관련 업데이트 관리, 인시던트 대응 프로세스, 지속적인 모니터링과 개선이 필요하다.

적용 대상에 따라 달라지는 통제 방식

인슐린 펌프 제어 소프트웨어에서는 과다 투여, 투여 실패, 알람 오작동을 위험으로 식별할 수 있다. FMEA와 FTA를 적용하고, 인슐린 최대 투여량 제한 로직, 이중 센서를 통한 투여량 확인, 배터리 부족 시 단계적 경고 시스템으로 대응한다.

자율주행 결정 시스템에서는 잘못된 장애물 인식, 제어 지연, 시스템 장애가 분석 대상이다. STPA와 HAZOP을 적용해 다중 센서 융합 및 검증 알고리즘, 독립적으로 구현한 비상 브레이크 시스템, 운전자 개입 기능의 우선순위를 설계한다.

비행 제어 소프트웨어는 제어면 오작동, 자동 조종 실패, 센서 데이터 오류를 다룬다. FTA와 FMEA를 사용하며, 다중 채널 비행 제어 컴퓨터(FCCs), 다양한 알고리즘의 처리 결과 비교 검증, 물리적·기능적 격리를 통한 독립성 보장이 안전 대책이 된다.

안전성 분석이 넓어지는 영역

인공지능 시스템은 블랙박스 특성 때문에 기존 방법론의 한계를 극복할 새로운 안전성 분석 기법이 필요하다. 학습 데이터의 안전성과 알고리즘 편향성도 분석 대상에 포함된다.

사이버-물리 시스템(CPS)에서는 하드웨어·소프트웨어·네트워크를 통합해 안전성을 분석하고, 실시간 안전성 모니터링과 대응 방법론을 마련해야 한다. 디지털 트윈은 가상환경에서 다양한 시나리오를 시험하고 운영 중 안전성을 예측해 선제적으로 대응하는 데 활용할 수 있다.

보안 취약점이 안전성에 미치는 영향을 함께 분석하고, 안전과 보안을 통합한 위험 관리 체계를 구축하는 일도 남아 있다.