스물두줄

정보관리기술사 · 개념서 · 소프트웨어 공학

소프트웨어 안전성 분석

설명 영상 소프트웨어 안전성 분석 · 3:02

왜 배우는가: 소프트웨어 안전성 분석은 제어 소프트웨어가 자동차·철도·항공·원자력·의료 등 사람의 생명과 직결되는 분야로 확산되면서 필수 역량이 되었다. 세 차례 기출에서 필요성, FTA·FMEA·HAZOP의 개별 설명과 비교가 반복 출제되어 개념의 출발점을 정확히 잡아야 한다.

출제 이력: 제131회 3교시 4번, 제119회 4교시 4번, 제108회 2교시 3번

1. 한 줄 정의와 핵심 키워드

소프트웨어 안전성 분석은 소프트웨어 결함이나 오동작이 인명·재산·환경 피해로 이어지는 위험(Hazard)을 개발 단계에서 식별·평가하고 제거·통제하는 체계적 활동이다.

  • 핵심 키워드: 위험(Hazard), 안전필수(Safety-Critical) 시스템, 위험 식별, 위험 평가, 고장 원인 분석, 안전 요구사항, 기능 안전, 무결성 수준(SIL)

이 정의는 답안지 첫 줄에 그대로 쓸 수 있다. 위험은 사고로 이어질 수 있는 상태이고, 사고는 그 상태가 실제 피해로 이어진 결과다. 따라서 안전성 분석은 결함을 찾는 것이 아니라, 결함이 어떤 피해로 이어지는지를 기준으로 분석 범위를 정하는 활동이다.

2. 개념 풀이

쉽게 말하면, 소프트웨어가 틀렸을 때 사람이 다치거나 설비가 망가질 수 있는지를 미리 따져 보는 일이다. 같은 버그라도 게임 화면이 깨지는 것과 항공기 제어값이 틀어지는 것은 피해가 전혀 다르다. 그래서 안전성 분석은 기능이 맞는지보다 어떤 기능이 잘못되면 어떤 피해가 생기는지를 먼저 본다.

정식으로는 시스템의 위험을 식별하고, 그 위험의 원인과 영향을 분석하고, 위험을 줄이기 위한 안전 요구사항을 도출하여 설계와 검증에 반영하는 전 생명주기 활동으로 정의한다. 소프트웨어 안전성 분석은 이 활동 중 소프트웨어가 담당하는 기능과 인터페이스에 초점을 맞춘다.

핵심 용어를 정리하면 다음과 같다.

  • 위험(Hazard): 사고를 일으킬 수 있는 시스템의 조건이나 상태다. 소프트웨어 결함 자체보다 결함이 만드는 위험 상태를 가리킨다.
  • 사고(Accident): 위험이 실제 인명·재산·환경 피해로 나타난 사건이다.
  • 안전필수(Safety-Critical) 시스템: 오동작이 사고로 직결되는 시스템이다. 항공 제어, 철도 신호, 원전 계측, 의료기기가 해당한다.
  • 기능 안전(Functional Safety): 전기·전자·프로그램 가능 전자 시스템이 안전 관련 기능을 정확히 수행하도록 보장하는 것이다. 국제 기준은 IEC 61508이다.
  • 무결성 수준(SIL, Safety Integrity Level): 안전 기능의 신뢰도 요구 수준을 등급으로 나타낸 값이다.

3. 등장 배경과 필요성

과거 안전필수 시스템의 제어는 기계식·아날로그 회로가 맡았다. 이 시기에는 부품 고장을 중심으로 안전을 따지면 되었다. 제어 기능이 소프트웨어로 옮겨 가면서 상황이 달라졌다. 소프트웨어는 마모되거나 노화되지 않지만, 설계 단계의 요구사항 누락이나 논리 오류가 그대로 고장 원인이 된다.

기술 환경의 변화도 필요성을 키웠다. 자동차는 한 대에 수많은 전자제어장치가 들어가고, 철도와 항공은 소프트웨어가 신호와 운항을 직접 제어한다. 원자력과 국방 분야도 같은 흐름이다. 이 상황에서 사고의 상당 부분은 사용자 조작 실수보다 설계 과정의 안전성 검증 부족에서 비롯된다는 점이 지적되어 왔다.

소프트웨어 안전성 분석이 필요한 이유는 다음과 같다.

  • 사고 예방: 위험을 사고 전에 찾아 제거하여 인명·재산 피해를 막는다.
  • 규격 준수: IEC 61508과 DO-178C 같은 안전 규격은 안전 분석 결과를 인증 요건으로 요구한다.
  • 비용 절감: 결함을 요구사항 단계에서 찾으면 운영 단계에서 찾는 것보다 수정 비용이 낮다.
  • 책임 대응: 사고 후에도 위험을 체계적으로 분석했음을 입증할 근거가 된다.

특히 안전 요구사항은 결함을 찾은 뒤가 아니라 설계 전에 위험 기준으로 정해야 한다. 이 점이 소프트웨어 안전성 분석을 일반 품질 시험과 구분하는 핵심이다.

DO-178C는 위험 분석의 심각도에 따라 소프트웨어 등급을 A부터 E까지 나누며, A와 B 등급에 더 엄격한 활동을 요구한다. 이처럼 분석 결과가 곧 등급과 관리 수준을 결정한다는 점이 필요성을 뒷받침한다.

이어지는 내용

로그인하면 하루 5페이지까지 무료로 전체를 읽을 수 있습니다.

앱에서 이 단원 읽기