소프트웨어 안전: 위험원 분석과 결함 허용 설계

안전은 위험이 0인 상태가 아니다. 허용할 수 없는 위험이 없는 상태, 바꿔 말해 허용 가능한 위험만 남은 상태다. 위험은 위험원(hazard, 해를 끼칠 수 있는 잠재 원인)이 실제 피해로 이어질 발생 가능성과 심각도의 조합으로 판단한다. 소프트웨어 안전은 소프트웨어가 그런 허용 불가 위험의 원인이 되지 않게 하는 것이다.

왜 소프트웨어 안전인가

항공기 기능에서 소프트웨어가 차지하는 비중은 1960년대 F-4의 약 8%에서 2000년대 F-35의 약 90%로 늘었다. 자동차의 구동·조향·제동, 방사선 치료기, 철도 신호처럼 사람의 생명이 걸린 기능이 기계에서 소프트웨어로 넘어가고 있다. 이런 시스템을 안전 필수 시스템(Safety-critical System) 이라 한다.

결함은 소프트웨어 → 컴포넌트 → 시스템 → 차량·항공기로 전파되며 고장, 위험원, 사고로 커진다. 용어는 에러·결함·고장에 있다.

안전을 확보하는 네 가지 전략

앞의 셋은 결함을 줄이는 쪽이고, 마지막은 결함이 남아 있다고 가정하는 쪽이다. 안전 필수 시스템은 넷 다 쓴다.

중복성과 다양성

Ariane 5는 중복성은 있었지만 다양성이 없었다. 소프트웨어 결함은 복제본 모두에 똑같이 들어 있으니, 같은 코드를 두 벌 돌려서는 막을 수 없다. 서로 다른 팀이 같은 명세로 따로 구현하고 결과를 투표로 고르는 방식을 N-버전 프로그래밍이라 한다. 서버 쪽 이중화 패턴은 고가용성과 이중화에 있다.

안전 표준

일반 개발 프로세스에 안전을 위해 반드시 해야 할 활동과 기법을 더한 것이 안전 표준이다. 전기·전자·프로그래머블 시스템의 기능 안전 표준 IEC 61508이 뿌리(메타 표준)이고, 분야별 표준이 여기서 갈라져 나왔다.

무결성 등급에 따라 기법이 세진다

IEC 61508은 요구되는 안전 수준을 SIL(Safety Integrity Level) 1~4로 나누고, 등급이 높을수록 더 많은 기법을 "권장"에서 "강력 권장"으로 올린다. 자동차는 ASIL AD, 항공은 DAL AE로 비슷한 등급을 쓴다.

커버리지 기준의 차이는 화이트박스 테스트에 예제로 정리했다. 결함 주입 테스트도 쓰인다. 정상 코드에 일부러 비정상 조건(연산자 바꾸기, 센서 값 끊기)을 넣어, 시스템이 예외 상황에서 안전하게 반응하는지 본다.

안전 개발 생명주기

V-모델의 각 단계 옆에 안전 활동이 나란히 붙는다. 요구사항 단계에는 안전 요구사항과 안전 분석, 설계에는 안전 아키텍처·상세 설계, 구현에는 안전 코딩 규칙, 테스트 단계마다 안전 테스트가 짝을 이룬다.

안전 분석 기법

안전 분석은 사고를 일으킬 수 있는 상태나 조건을 찾고 그 원인을 따지는 일이다. 예로 스마트 전기 포트(물을 끓이고 보온하는 제어 소프트웨어가 들어 있다)를 쓴다.

FMEA: 부품 하나가 고장 나면?

FMEA(Failure Mode and Effect Analysis) 는 아래에서 위로 간다. 구성 요소마다 고장 모드를 나열하고, 그 영향과 원인, 대책을 표로 정리한다. 심각도·발생도·검출도를 곱한 위험 우선순위(RPN)로 순서를 매기는 경우가 많다.

FTA: 이 사고는 어떻게 일어나나?

FTA(Fault Tree Analysis) 는 위에서 아래로 간다. 피하고 싶은 사고를 꼭대기에 두고, 그것을 일으키는 원인을 AND·OR 게이트로 분해한다.

flowchart TD
  top["포트 과열 화재"] --- g1{"AND"}
  g1 --- e1["가열이 멈추지 않음"]
  g1 --- e2["온도 퓨즈 미작동"]
  e1 --- g2{"OR"}
  g2 --- e3["센서가 낮은 값"]
  g2 --- e4["제어 SW 끄기 누락"]
  e4 --- g3{"OR"}
  g3 --- e5["입력값 오류"]
  g3 --- e6["로직 오류"]

AND 게이트 위에 있는 사고는 아래 원인이 모두 일어나야 생긴다. 독립된 온도 퓨즈를 하나 두는 것만으로 소프트웨어 결함이 곧바로 화재로 이어지는 길이 끊긴다. 결함 허용 설계의 효과가 트리에서 바로 보인다.

HAZOP: 이 값이 기준에서 벗어나면?

HAZOP(Hazard and Operability Study) 은 설계의 각 요소와 변수에 안내어(guideword) 를 대입해 이탈 상황을 체계적으로 상상한다. 형식은 "만약 [대상].[변수]가 [안내어]라면? → [이탈]"이다.

FMEA는 부품에서 결과로, FTA는 사고에서 원인으로, HAZOP은 변수의 이탈에서 출발한다. 서로 빈틈을 메우므로 함께 쓴다.

정리

• 안전은 위험 0이 아니라 허용 불가 위험이 없는 상태다.
• 결함 예방·검출·제거로 결함을 줄이고, 결함 허용으로 남은 결함이 사고가 되지 않게 막는다.
• 소프트웨어 결함은 복제본에 똑같이 있으므로 중복성만으로는 부족하고 다양성이 필요하다.
• 안전 표준은 무결성 등급이 높을수록 정적 분석, 정형 인스펙션, MC/DC 같은 강한 기법을 요구한다.
• FMEA(상향), FTA(하향), HAZOP(이탈)으로 위험원을 찾고 원인을 끊는다.

관련 노트: 소프트웨어 테스트, 복원력 패턴, 정적 분석, 요구공학, 정보 시스템 보안, 장애 회고