바로가기 메뉴
본문 바로가기
주메뉴 바로가기
연구자료
소프트웨어 안전, 미리 대비하라!
  • 송지환SW기반정책·인재연구실 책임연구원
날짜2018.04.27
조회수12118
    • Software safety, prepare it ahead!
    • 2011년 발사된 중국 우주정거장‘ 톈궁(天宮) 1호’는 2016년 3월에 통신이 끊긴 지 거의 2년만인 2018년 4월 2일 아침 남태평양 바다에 추락하고 말았다. 세계 각국은 톈궁 추락으로부터 자국의 피해를 최소화하기 위해 모든 기술 역량을 동원하여 추락 궤도를 예측하고 충돌에 대비했다. 다행히도 톈궁은 사람이 살지 않는 바다 한가운데에 추락했고 누구도 다치지 않았다. 그런데 우주에서 추락하는 우주선의 위험은 어느 정도일까? 경찰청에서 발표한 교통사고통계에 의하면 2016년 국내 교통사고 사망자 수가 4,292명으로 하루 평균 11.7명이 교통사고로 사망했다. 그렇다면 톈궁의 추락보다 자동차 운행이 더 위험한 게 아닐까?
    • <그림 1> 톈궁 1호 추락 지점 예측
    • 먼저 안전(Safety)의 정의부터 살펴보자. 국제안전규격인 ISO/IEC GUIDE51을 살펴보면 “ 안전은 수용할 수 없는 위험에서 벗어난 것(Safety: freedom from unacceptable risk)”으로 정의되어 있다1. 전기/전자/프로그램이 가능한 전자기기의 기능 안전(Functional Safety) 표준인 IEC 61508 역시 ISO/IEC GUIDE51의 정의를 그대로 차용하고 있다2. 소프트웨어 안전계획을 위한 표준인 IEEE Std 1228-1994에서는“ 소프트웨어 안전(Software Safety)은 소프트웨어가 위해(危害)로부터 자유로운 상태를 의미한다.”로 정의한다3.
    • 안전의 반대 개념인 위험(Risk)은 어떻게 정의될까? 우리는 위험을‘ 위험원(Hazard)’, ‘ 유해(有害, Harm)’등 의 의미로 혼용하기도 한다. 그러나 이들 용어는 표준이나 학계에서는 각각 구별하여 쓰고 있다. 우선 위험원은‘ 잠재적인 위험을 갖는 것’이라 생각하면 된다. 예를 들어, 일상생활에서 흔히 볼 수 있는‘ 뜨거운 물’이나 청소용품인‘ 락스’가 위험원의 예가 될 수 있다. 뜨거운 물이나 락스가 엎질러지면‘ 화상’이라는 결과를 가져오기 때문이다. 하지만 화장지 한 조각은 어떻게 해도 사람을 다치게 하기 어려우므로 이를 위험원으로 보기 어렵다. ‘ 미끄러운 눈길’‘, 건물 외벽의 간판’도 같은 맥락에서 위험원이라고 할 수 있다. 유해는 화상, 골절, 뇌진탕, 사망 등 위험원으로부터 발생한 사고의 결과로 보면 된다.
    • <그림 3> 위험 정도 비교 예시
    • 위험은 위험원으로부터 이어지는 유해의‘ 심각성(Severity)’과 유해로 이어질‘ 가능성(Probability)’의 조합이다. 예를 들어, 50℃ 물 보다 100℃ 물이 더 큰 화상을 유발할 수 있으므로 유해의 심각성이 높다. 바꾸어 말해 100℃ 물이 50℃ 물보다 위험하다고 말할 수 있다. 또한, 위험은 위험원이 유해를 일으킬 가능성이 크거나 발생 빈도가 잦을수록 커진다. 엎질러지더라도 주변에 사람이 없어 유해를 일으킬 가능성이 작다면 위험은 작아진다. 뜨거운 물은 엎질러지면 화상을 일으킬 수 있지만 뜨거운 물이 엎질러질 가능성이 매우 낮다면 역시 위험은 작아진다. 정리하면, 위험은 유해의 정도가 심각할수록 그리고 해로운 상황이 발생할 가능성이 클수록 커진다.
    • 다시 톈궁의 추락사건으로 돌아가 보자. 톈궁은 우리 머리 위를 빙글빙글 돌고 있었고 추락하면 사람이 다치거나 죽을 수 있으므로 위험원임에는 틀림없다. 톈궁이 머리 위로 떨어져 사람이 사망할 가능성은 얼마나 될까? 미국 항공우주국 NASA의 계산에 의하면 벼락에 맞을 확률보다 천만 배 더 작다고 한다4. 이는 톈궁의 추락이 유해 심각성은 높지만, 유해로 이어질 확률이 매우 낮으므로 위험은 그리 크지 않았다. 2016년 우리나라의 인구가 대략 5,100만 명이고 당시 한해 4,292명이 교통사고로 사망했기 때문에 국민 한 명당 0.008%의 사망 가능성이 있었다. 결국, 톈궁 추락에 의한 사망 위험보다 교통사고에 의한 사망 위험이 훨씬 높음을 알 수 있다.
    • 이제 소프트웨어 안전을 이야기해 보자. 왜 예전보다 소프트웨어 안전이 중요해진 걸까? 지금까지 설명한 위험의 정의로 설명이 가능하다. 과거에는 워드프로세서와 같은 사무용 소프트웨어가 우리가 접할 수 있는 소프트웨어의 대부분이었다. 그러나, 제4차 산업혁명은 거의 모든 기기에 소프트웨어를‘ 심어’놓 는다. 철도 분야의 열차제어시스템, 항공우주 분야의 항공관제시스템과 인공위성 제어시스템뿐만 아니라, 스마트 빌딩, 드론, 로봇 그리고 자율주행차 등 새로운 영역에서도 소프트웨어는 핵심이 되어 가고 있다. 그만큼 일상생활에서 더 많은 기기가 소프트웨어로 제어되고 있다. 결국, 예전보다 위험원이 훨씬 많아지고 있으므로 필연적으로 소프트웨어로 인한 위험은 커질 수밖에 없다. 시대의 흐름으로 인해 소프트웨어에 대한 위험원이 증가함에 따라, 이에 대한 사고 발생 가능성이나 빈도를 낮추는 데 집중하고 있다.
    • 최근 테슬라의 운전자 사망사고와 우버의 보행자 사망사고 모두 운전자의 개입 없이 자율주행 중에 발생했다. 2016년 발생한 테슬라 모델S의 운전자 사망사고는 맞은편에서 좌회전하던 트레일러 옆면의 흰색 부분이 하늘과 구분이 되지 않아 발생했고, 2018년 3월 테슬라 모델X 사고 역시 도로 분리대를 인지하지 못한 결과이다. 2018년 3월에 발생한 우버 자율주행차 보행자 사망사고는 자전거를 끌고 가던 보행자를 미처 인식하지 못해 발생했다. 이렇듯 소프트웨어의 인식오류나 오동작은 인명피해로 이어질 수 있다. 항공이나 철도 분야에서 소프트웨어 오류는 더 큰 인명 피해를 일으킬 수 있음은 너무나도 자명하다.
    • <그림 4> 우버의 자율주행차 보행자 사망사고
    • 해외 안전 선진국들은 안전에 대해 민간 주도로 표준을 만들고 있으며, 최근에는 소프트웨어의 안전을 위한 내용이 표준에서 점점 중요한 부분을 차지하고 있다. 전자기기의 기능 안전 표준인 IEC 61508은 Part 1에서 일반 요구사항을 기술하고, Part 2에서는 하드웨어에 대해, Part 3에서는 소프트웨어에 대해 각각 안전 요구사항을 기술하고 있다. 그만큼 하드웨어와 소프트웨어 모두의 안전이 확보되어야 전체 시스템의 안전을 담보할 수 있음을 의미한다. 철도, 항공, 의료와 같은 분야의 안전 국제표준 역시 IEC 61508과 유사하게 안전 확보를 위해 시스템 전반의 안전 활동에 관해 기술하고, 소프트웨어 안전에 대해서도 비중 있게 다루고 있다.
    • <표 1> 분야별 안전 관련 국제 표준
    • 이제는 디자인과 기능뿐만 아니라 안전이 제품 경쟁력의 중요한 요소로 자리 잡고 있다. 국내 기업이 세계 시장에 진출하기 위해서는 안전은 선택이 아니라 필수이다. 미국 및 유럽 등 해외 선진국에서는 안전 산업에서 장기간 축적한 기술력을 바탕으로 안전 국제표준을 주도하고 있으며, 산업에서도 우위를 선점하고 있다. 안전 표준을 지키지 않으면 시장 진입 자체가 불가능할 수도 있다는 말이다. 그런데도 대다수 우리 기업들은 안전 국제표준에 대한 인지도가 아직 낮은 편이다. 그나마 국제표준을 준수해도 표준화 작업에 적극적으로 참여하지 않고 제정된 표준을 따라가기에 급급하다.
    • 국민의 안전을 지키고 더불어 글로벌 경쟁력 확보를 위해서는 소프트웨어 안전에 대해 정부와 기업이 더 많은 관심을 가져야 한다. 제4차 산업혁명의 도래로 소프트웨어의 쓰임이 더욱 확대됨에 따라 소프트웨어의 오작동을 최소화하고 안전성을 확보하는‘ 소프트웨어 안전사회’를 만들기 위해 국가 차원의 노력이 필요하다. 인명 사고는 후회해도 되돌릴 수 없다는 것을 우리는 다시 한번 명심해야 한다.
    • 1 ISO/IEC Guide 51:1999, definition 3.1
    • 2 IEC 61508 Part 4 Definitions and abbreviations definition 3.1.11 freedom from unacceptable risk [ISO/IEC Guide 51:1999, definition 3.1]
    • 3 IEEE Std 1228-1994 - IEEE Standard for Software Safety Plans
    • 4 http://blogs.esa.int/rocketscience/2018/03/26/tiangong-1-frequently-asked-questions-2/