SPRi - 소프트웨어정책연구소

위험원 분석 및 위험 평가 동향 및 시사점

송지환SW기반정책·인재연구실 책임연구원

2018.10.26

21112

글자크기

- SW가 여러 분야에서 중요한 역할을 수행함에 따라 SW 오류로 인한 사고 발생 가능성 역시 증대되고 있음
- 위험원 분석 및 위험 평가는 적절한 안전수준을 책정하고 이에 맞는 안전기능 추가로 잠재적인 사고 위험을 경감시킬 수 있음
- SW 안전이 확보될 수 있도록 위험원 분석 및 위험 평가에 대한 적극적인 홍보와 교육이 필요함

제4차 산업혁명의 도래로 여러 분야에서 안전한 SW의 개발이 중요해지고 있음

자동차, 항공, 철도, 의료 등 전통적으로 안전이 중요한(Safety-critical) 분야에서 SW의 역할이 점점 커지고 있음
2012년 국제전자제품박람회(CES, Consumer Electronics Show)에서 메르세데스-벤츠 자동차그룹의 디터 제체(Dieter Zetsche) 회장은“자동차는 이제 기름이 아니라 SW로 달린다.”라고 말해 큰 화제를 불러일으킴
SW가 핵심적인 역할을 하는 자율주행차가 2035년에는 전 세계 차량 판매량의 75%에 해당하는 9,500만 대가 팔릴 것으로 예상하며,1 2030년에는 제조원가에서 전자부품 및 SW가 차지하는 비중이 50%에 이를 것으로 전망함2
그림 1 세계 자율주행자동차 시장(좌) 및 전자부품/SW 제조원가 비중(우) 전망
※ 출처 :“자동차산업 핵심경쟁력의 중심이동”, 한국자동차산업협동조합 재인용(2014)
자동차 분야와 마찬가지로 항공, 철도, 의료 등 안전이 중요한 분야에서도 상태를 모니터링 하는 곳은 물론 기능을 제어하는 곳까지 SW의 비중이 점점 커지는 추세임
제4차 산업혁명의 도래로 일상생활의 작은 기기부터 대규모 시스템까지 SW가 제어하는 세상으로 점차 변화하고 있음
SW가 사회·산업 전반에 융합됨에 따라, 일상생활에서 사용하는 전자기기부터 대규모 시스템까지 폭넓은 분야에서 SW가 중요한 역할을 하고 있음
과거에는 상태를 보여주거나 감시하는 역할로 SW가 사용되었다면, 이제는 SW가 시스템 및 기기의 제어를 담당하는 역할로 점차 확대 사용되고 있음
자동차 분야를 예로 들면, 자동긴급제동시스템(AEB, Autonomous Emergency Braking), 첨단운전자지원시스템(ADAS, Advanced Driver Assistance System), 차선유지보조시스템(LKAS, Lane Keeping Assist System) 등 SW가 제어하는 시스템이 점차 늘고 있음
그림 2 SW가 핵심인 스마트카 주요 전장 부품
※ 출처 : MDS테크놀로지 홈페이지
이러한 기기나 시스템에서 SW의 오동작은 자칫 큰 사고로 이어질 수 있어 안전한 SW 개발이 중요해지고 있음
AECL 社3의 Therac-25 방사선 치료기의 사례에서 볼 수 있듯이 SW의 오동작은 생명과 재산을 앗아갈 수 있으며, SW의 오류로 원자력 발전소에 사고가 발생한다면 환경에까지 치명적인 악영향을 줄 수 있음
지금까지 SW의 오류로 발생한 여러 사고가 있어왔고, 더 많은 분야에서 SW의 비중이 증가함에 따라 SW 결함에 의한 사고는 더욱 증가할 것으로 예상함
Therac-25 사고
Therac-25는 AECL 社의 방사선 치료기 중 하나로 해당 모델부터 주요 기능이 SW로 제어되기 시작함(1982년 출시)
1985년부터 1987년까지 제어 SW의 오류로 6건의 치명적인 인명 피해가 발생함
SW 오류로 인해 발생한 첫 번째 인명 피해 사례로 기록됨
사고 개요
Therac-25는 낮은 방사선을 조사하는‘Electron 모드’와 강한 방사선을 조사하는‘X-ray 모드’가 존재
X-ray 모드에서는‘타깃(Target)’이라 불리는 장치가 환자와 치료기 사이에 위치하여 치료가 필요한 부분에만 방사선이 조사되게 함
Therac-25 이전 모델에서는 오퍼레이터가 타깃을 수동으로 위치시켰으나, Therac-25부터 SW가 이를 자동으로 위치시킴
SW 오류가 발생하여 X-ray 모드에서 타깃 없이 강한 방사선이 환자에게 조사되어 인명 피해 발생
※ 출처 : Wikipedia 내용 재구성

표 1 SW 오류로 인한 사고 사례

<표 1> SW 오류로 인한 사고 사례
도요타 급발진 사망사고(2009)	임진강 재해경보시스템 오동작 사망사고(2009)	신호기 고장 서울지하철 추돌사고(2014)	가변차로 신호등 오작동 차량 충돌사고(2017)	우버 자율주행차 보행자 사망사고(2018)

ECU 내 메모리 영역에서 간섭 현상이 bit-flip을 야기하여 차량 급발진 발생	임진강 경보제어 시스템의 수위정보를 전송하는 RTU 고장으로 서버 간 통신 오류로 경보 시스템이 오동작	2개의 신호기 고장으로 후속 열차의 자동정지장치가 미작동	SW 오류로 인해 신호등 제어시스템 에 문제가 발생한 것으로 추정	보행자를 인지하였으나 충돌 방지를 위한 비상브레이크가 작동하지 않아 사고 발생

※ 출처 : Google 이미지 및 뉴스기사 재정리

아직은 대다수 기업에서 안전한 SW 개발 활동에 대한 인식이 부족하거나 여건이 마련되어 있지 않음
- SW 안전과 관련된 업무를 수행하는 연구소나 기업조차 SW 안전에 대한 개념을 SW품질4이나 정보보안(Security)5과 혼동하는 경우가 있음
- 이러한 기관들은 SW 안전의 개념을 명확하게 설명하지 못하는 경우가 종종 있었으며, 설명하더라도‘SW 품질이 곧 SW 안전이다’라고 생각하거나‘정보보안과 SW 안전은 같은 의미다’라고 말하는 등 SW 안전에 대해 불명확한 개념을 갖고 있었음
- 일부 SW 개발 기업들은 SW 안전의 개념을 명확하게 파악하지 못하더라도 SW 안전 활동을 품질 보증 활동 등을 통해 부지불식간에 수행하는 경우도 있었음
- 그림 3 SW 안전 확보를 위한 SW 개발 절차 예시
- 안전한 SW가 중요하다는 것에 대해서는 어느 정도 공감대가 형성되고 있으나 실제 어떻게 해야 안전한 SW를 개발할 수 있는지에 대해서는 잘 모르는 경우가 많음
- 안전한 SW를 개발하기 위해 코딩 규칙을 따르고 정적 및 동적 분석을 수행하는 정도면 충분하다고 생각하는 경우가 대부분임
- SW 안전을 위해 위험원 분석(Hazard Analysis) 및 위험 평가(Risk Assessment)를 하고 SW 개발 생명주기(SDLC, Software Development Life Cycle) 전반에서 추가적인 안전 활동을 해야 한다는 것에 대해서는 잘 인식하지 못함
- 그림 3에서와 같이 일반 SW 개발 절차에 SW 안전 확보를 위한 추가 활동이 반드시 확보되어야 안전한 SW를 개발할 수 있음
- SW 안전의 정의
- SW 안전(software safety)은 소프트웨어 위해(危害)로부터 자유로운 상태를 의미하며, 인명, 상해, 질병, 환경훼손, 재산의 손괴 및 소실을 포함(IEEE Std. 1228-1994)
- SW 품질 및 정보보안과의 비교
- 특히, 스타트업이나 중소기업의 경우 안전한 SW를 개발하기 위한 전문 인력 확보가 힘들고 추가적인 개발 비용에 부담을 갖는 것이 현실임
- 국내 SW 안전 전문가6의 수가 극소수에 불과하여 스타트업이나 중소기업이 SW 안전 전문 인력을 확보하기가 현실적으로 거의 불가능함
- 높은 수준(등급)의 안전성을 요구할수록 더 큰 비용이 들어가지만, SW 안전을 위해 추가적인 비용을 지출하는 것이 중소기업 입장에서는 큰 부담이 될 수밖에 없음

안전한 SW 개발을 위해서는 무엇보다도 위험원 분석 및 위험 평가가 중요함

SW 안전을 확보하기 위해서는 요구사항분석 및 명세, 설계, 개발, 검증, 운영, 폐기 등 SW 개발 생명주기 전반에서 안전 관련 활동이 수행되어야 함
일반적인 SW 개발 절차는 시스템 개념 및 요구사항 정의로 시작하여 이를 명세화하고 설계 및 구현 후 검증 단계를 통해 시스템이 원하는 수준에 맞게 개발되고 동작하는지 확인함
일반적인 SW 개발 절차는 시스템 개념 및 요구사항 정의로 시작하여 이를 명세화하고 설계 및 구현 후 검증 단계를 통해 시스템이 원하는 수준에 맞게 개발되고 동작하는지 확인함 이러한 일반적인 SW 개발 방법론으로는 어느 수준의 안전 기능이 필요한지에 대해 정량적/정성적 분석이 불가능함
SW 개발 생명주기 각 단계에서 위험원 도출 및 위험 분석 등이 제대로 수행되었는지와 해당 요구사항이 잘 반영되었는지에 대해 철저하고 객관적인 검증이 요구됨

표 2 주요 분야별 기능 안전성 국제 표준 및 SW 안전 관련 표준

<표 2> 주요 분야별 기능 안전성 국제 표준 및 SW 안전 관련 표준
산업 분야	기능 안전성 국제 표준	SW 안전 표준
공통	IEC 61508	IEC 61508-3
자동차	ISO 26262	ISO 26262-6
철도	IEC 62278, IEC 62279	IEC 62279
항공	ARP 4761, DO-178C	DO-178C
원자력	IEC 60880, IEC 62138, IEEE7-4.3.2, IEC 61513	IEC 60880
의료	IEC 60601, IEC 62304, ISO 13606	IEC 62304

위험원 분석 및 위험 평가는 개발의 초기 단계부터 영향을 주기 때문에 SW 안전 활동 중 가장 중요한 부분임
개발의 모든 단계에서 안전 활동을 수행해야 하지만 개발 초기 단계인 요구사항명세 및 설계에 직접적인 영향을 주는 위험원 분석 및 위험 평가(HARA, Hazard Analysis and Risk Assessment) 수행이 가장 중요하다고 봄
HARA 수행을 통해 적절한 안전수준을 책정하고 이에 맞는 안전 기능 추가는 프로젝트 중간에 요구사항이나 설계 변경을 최소화하여 결과적으로 개발 기간을 단축하며 동시에 비용도 절감시킬 수 있고, 사고의 위험을 낮춤으로써 잠재적인 비용도 줄일 수 있게 됨
IEC 61508(산업공통), ISO 26262(자동차), IEC 62278/62279(철도), DO-178C(항공) 등 기능 안전성 국제 표준에서도 HARA 수행이 명시되어 있음

위험원 분석 및 위험 평가를 위한 대표적인 정형화 기법으로는 FMEA, FTA, HAZOP, STPA 등이 존재함
- (FMEA) 시스템의 발생 가능한 고장 모드(Failure Mode)를 정의하고 영향(Effect)과 원인(Cause)을 분석하여 고장률을 낮추는 분석 방법임
- Failure Mode and Effects Analysis의 약자로서 미항공우주국(NASA)이 1960년대 아폴로 프로젝트에서 고장으로 인한 사고를 줄이기 위해 개발함7
- 고장의 원인에서부터 상향식(Bottom-up) 혹은 귀납적 추론(Inductive Reasoning) 방법을 사용하여 고장 발생 확률을 줄이는 정성적 분석 기법임
- 현재는 우주항공 분야뿐만 아니라 원자력, 자동차 분야 등 다양한 산업 분야에서 활용 되고 있음
- (FTA) 예상할 수 있는 사고에 대하여 해당 사고의 원인이 되는 결함이나 오류를 연역적인 방법으로 검토하고 안전성을 평가하는 기법임
- Fault Tree Analysis의 약자로 미국 벨 연구소에서 군용 목적의 안전성 평가를 위해 1962년 처음 고안함
- 시스템에 문제를 일으키는 알려진 고장에 대해 예상 가능한 근본 원인을 알아내고 이에 대한 논리적 구조(나뭇가지 모양의 Fault Tree 구성)를 규명하는 정량적 분석 기법임
- 화재·폭발·누출 등의 사고를 예방하기 위해 화학플랜트, 핵발전소, 대기우주산업, 전자공업 등의 산업 분야에서 주로 활용됨
- (HAZOP) 시스템의 정상 동작으로부터 예측 가능한 이상 동작을‘안내 단어(Guide Words)’8를 활용하여 식별하는 분석 기법임
- HAZard and OPerability study의 약자로서 영국의 글로벌 화학기업인 ICI(Imperial Chemical Industries)에서 1963년 최초로 시작됨
- 각 분야의 전문가로 구성된 팀이 안내 단어(guide words)를 이용하여 원래 목적과 다른 일탈(deviation) 상황을 가정하여 브레인스토밍 등 자유로운 의견 개진을 통해 원인과 결과를 찾는 정성적 평가 방법임
- 신규 공정을 설계하거나 기존 공정, 원료 등에서 중요한 변경이 발생할 경우 주로 활용됨
- (STPA) 시스템의 개발과 운영에 관련된 요소들을 하나의 모델로 표현하여 위험을 분석하는 기법임
- System Theoretic Process Analysis의 약자로서 MIT의 낸시 레버슨(Nancy Leverson) 교수팀에서 개발함
- 시스템 이론에 따라 사고가 컴포넌트9 간의 상호작용에 의해 발생한다는 전제하에 컴포넌트 간 안전하지 못한 제어 액션(Unsafe Control Action)을 분석하여 위험원을 찾아냄
- SW, HW 이외에도 사람, 환경 등의 요소와 같이 시스템의 개발과 운영과 관련된 모든 요소를 모델로 표현하여 위험을 분석하는 점이 특징임
- 그림 4 HARA 수행을 위한 대표적인 정형화 기법들의 특성 정리
  ※ 출처 :“Delivering System Safety Through Design Tutorial”, Galen Ressler 외, ISSC2018, 재구성
시사점
- SW 안전 활동이 추가 혹은 불필요한 비용이라는 생각보다는 잠재적인 사고를 줄여 인적, 사회적, 경제적, 환경적 손실을 경감시킬 수 있다는 인식이 자리 잡혀야 함
- 개발 초기 단계에 수행되는 위험원 분석 및 위험 평가는 결과적으로 전체 프로젝트의 비용 및 기간을 절감하는 등 여러 장점이 있기 때문에 이러한 정형화 기법들에 대한 적극적인 교육과 홍보가 필요함
- 공공부문에서 안전한 SW 개발이 필요한 경우 SW 품질뿐만 아니라 SW 안전에 대한 명확한 요구사항을 계약에 포함하고 이에 합당한 대가를 산정하도록 관련 제도의 마련이 시급함
- 제4차 산업혁명의 도래로 위험분석가, 안전관리자, 안전검증전문가 등의 수요가 빠르게 증가할 것으로 전망되며, 이러한 SW 안전 전문가 육성을 위해 산·학·연의 긴밀한 협력이 요구됨
- 1 Navigant Research, 2013
- 2 Strategy Analytics
- 3 Atomic Energy of Canada Limited
- 4 SW 품질은 시스템의 효율적 운영을 위해 기능성, 사용성, 유지보수성, 호환성 등의 구현이 목적
- 5 정보보안은 SW가 올바르게 동작하도록 시스템 외부로부터의 침입을 방지하는 것이 목적
- 6 위험원 분석 및 위험 평가가 가능한‘위험분석가’, SW 안전 관점에서 개발프로젝트를 관리하는‘안전관리 자’, 정해진 안전기준에 맞게 개발되고 있는지 확인하는‘안전검증전문가’등
- 7 “Procedure for Failure Mode, Effects, and Criticality Analysis (FMECA), NASA, 1966”
- 8 없음(None), 과다(More), 과소(Less), 부분적(Part of), 대등한(as well as) 등
- 9 SW, HW뿐만 아니라 사람, 환경 등의 요소와 같이 시스템의 개발과 운영과 관련된 모든 요소