1. Intro
Software Engineering 수업에서 소프트웨어의 기능과 확실성(Dependability)에 대해서 배웠다.
또한 특별히 소프트웨어 테스팅에 대해서도 중점적으로 학습하였다.
테스팅에 대해서 배울 때 테스팅이 왜 중요할까? 테스팅을 제대로 수행하지 않고 소프트웨어를 출시했을때 어떤 문제가 발생할 수 있을까?에 대한 의문점이 들었다.
그래서 소프트웨어 오류에 관한 책을 찾아보던 중 “역사 속의 소프트웨어 오류”라는 책을 발견하게 되었고, 다양한 소프트웨어 오류 사례에 대해 나와있기에 소개하고자 한다.
2. 사례
| 사례 | 내용 |
| 미 공군 패트리어트 미사일의 오류 | 비트 이하 0.000000095 버림 누적으로 인한 표적 miss |
| 화성 탐사선의 소프트웨어 오류 | 탐사선 MCO의 단위 표기(뉴턴, 파운드) 불일치로 인한 탐사선 파괴 탐사선 MPL의 착륙 완료 오인(한쪽 다리에서 발생한 진동을 착륙 완료로 오인)으로 인한 파괴 |
| AT&T 장거리 전화 불통 사건 | 업데이트 된 코드 한 줄의 오류로 인한 9시간의 전화 불통 |
| 2003년 미국 북동부 대정전 사건 | race condition으로 인한 연이은 trip |
| 모리스 웜 | 1/7 확률로 프로그램을 복제하도록 한 코드 때문에 걷잡을 수 없이 퍼진 모리스 웜 |
| 스웨덴 JAS 39 그리펜 전투기 추락사고 | Fly-by-Wire FCS(Flight Control System, 비행 조종 시스템) 소프트웨어 오류 |
| ESA(유럽우주국) 아리안5 501편 사고 | SRI(Intertial Reference System, 로켓의 현재 고도와 속도 측정)의 이중화 But, 아리안4에서 사용했던 SRI를 그대로 사용하면서 요구사항 정의와 테스트 부족으로 비행 도중 폭발 |
| 미국 빈센트호 사건 | UI의 잘못된 설계(속도, 거리, 고도 미표시 – 수기 계산), 시나리오 비행(어떤 일이 발생할 것이라고 믿으면 실제 결과가 그렇지 않더라도 그 일이 발생했다고 믿게 되는 것) 등으로 인한 민간 항공기 격추 |
| 윤년 버그 | 마이크로소프트의 준(Zune)이라는 MP3 플레이어의 윤년 버그(2008년 12월 31일) PS3 윤년 버그(2010년 3월 1일 -> 2000년 1월 1일로 변경) 펜실베니아주의 Shared Medical Systems사 16비트 자료구조로 인한 범위 초과로 인해 시스템 장애 TOMTOM 내비게이션의 GPS 수신기 소프트웨어 윤년 버그 (2012년 3월 31일) |
| 게임 버그 | FIFA 온라인 다리 꺾임 아이슬란드 CCP가 제작, 운영하는 Eve Online의 업데이트로 boot.ini 파일 삭제로 인해 시스템 부팅 불가 World of Warcrafe의 Corrupted Blood 사건 – 죽지 않는 NPC 감염, 전염되고 다른 도시로 이동한 플레이어 등에 의해 실제와 흡사한 전염병 확산 |
| 테락 25 사건 | 엑스선 모드, 전자선 모드 2가지 모드가 있는데 소프트웨어 오류로 모드를 변경해도 정상 모드 미작동, 산란박 미위치 불편한 UI – 2번의 작업(치료실, 제어실) 필요, 일반인이 이해하기 힘든 오류 메시지 오류 메시지에 대한 설명이 문서에 미기재 소프트웨어에 대한 AECL(제작사)의 무지 – 소프트웨어에 대한 과신 |
| 화성 탐사선의 소프트웨어 오류 | Mars Global Surveyor : 비상 상황에서 안테나의 위치를 잡아주는 소프트웨어의 업데이트 오류 – 잘못된 메모리 주소에 저장 Mars Pathfinder : 플래시 메모리 용량 부족으로 인한 무한 재부팅 (3일간 60번 재부팅) |
| 금융 소프트웨어 버그 | 벤쿠버 증권거래소의 새로운 주가지수(1982.01)의 소수점 넷째자리 버림으로 인한 오류 호주 EFTPOS(Electronic Funds Transfer at Point of Sale, 은행 직불카드)의 16진수-2진수 혼동으로 인한 날짜 변경(2010년 1월 1일 -> 2016년 1월 1일) 미국 대형 증권 중개업체인 Knight Capital Amercas의 서버 8대 중 1대의 신규 소프트웨어 미설치로 인해 대량 거래 발생 – Power Peg라는 거래 중개 기능의 Flag 변수와 신규 소프트웨어의 변수명 동일 |
| 대한항공 801편, 아메리칸항공 965편 추락 사고 | 대한항공 801편 : 괌 국제공항의 MSAW(Minimum Safe Altitude Warning, 최저 안전고도 경고 시스템)의 문제 – 레이더의 탐지 지역(100~101.8km) 제한 아메리칸항공 965편 : 약자 혼용으로 인한 실수, 기장과 관제사의 의사소통 문제 등 |
| 대한민국 디지털예산회계시스템 문제 | 한국정보사회진흥원의 ‘시스템 통합 분야’ 부정적 의견에도 불구하고 시스템 가동 감행 2007년 1월 2일 시스템 운영 시작 이후 9,437건의 프로그램 변경 응용 프로그램 오류로 인한 프로그램 변경/개발 2,415건 시스템 성능 저하/장애 처리 240건 프로그램 기능 추가 및 개선 6,785건 동일한 프로그램을 2회 이상 반복 변경 1,299건(전체 오류의 53.8%) 지출업무 관련 프로그램 변경 43회 |
| 도요타 급발진 사고 | Bar Group의 보고서 – ECU 소프트웨어의 급발진 발생 가능성 제시 1. 급가속의 원인 중 하나가 소프트웨어 결함이라는 사실을 처음으로 입증 2. 과학, 기술 논문처럼 실제로 테스트를 통해 소프트웨어 결함으로 급가속이 일어날 수 있다는 사실을 증명한 첫 사례 복잡한 소스코드 – 버그 투성이, 순환복잡도 50이상의 함수 67개, 스로틀 각도 조절 함수의 순환복잡도 100이상 |
3. 책을 읽으면서 든 생각
수업을 통해 이론을 배웠다면 이 책을 통해 실제 사례를 배울 수 있었다.
이 책을 읽으면서 든 생각은 소프트웨어 테스팅을 통해 모든 오류를 잡을 수는 없지만, 오류의 최소화는 확보할 수 있다는 것이다.
2018년 현재 거의 모든 분야에 소프트웨어가 작동하고 있지만 어떤 소프트웨어도 완벽하다는 것을 보장할 수는 없다.
테스팅을 통해 발견된 오류를 수정하고, 오류를 최소화할뿐 오류 없음을 보장할 수는 없다.
그러나 막을 수 있는 사고는 최대한 막고, 지속적인 관심을 통해 소프트웨어를 Care한다면 100년, 200년 사용할 수 있는 훌륭한 소프트웨어를 만들 수 있지 않을까 싶다.
내가 생각하는 100년, 200년동안 사용할 수 있는 소프트웨어란 2000년에 C언어로 만든 소프트웨어를 Language의 변화와 트랜드, 속도, 보안 등 주변 환경과 여건에 알맞게 2010년에는 JAVA로 2020년에는 또다른 언어로 2100년에는 또다른 언어로 지속적으로 renewal하면서 언어의 생애주기에 관계없이 지속적으로 유지보수 가능하도록 만드는 것이다.
프로그래밍 언어의 변경은 소프트웨어를 새로 만드는 것과 다를 바 없을 수도 있다.
이를 위해서는 명확한 요구사항 명세와 변경에 대한 지속적인 이력 관리가 필수적이며, 주먹구구식 개발이 아닌 체계적인 개발 등 여러가지가 뒷받침되어야 할 것이다.
쉽지 않은 일이다. 그러나 소프트웨어 하나를 만들더라도 하나의 작품을 만들듯이 정말 열정과 애정을 가지고 만든다면 그 소프트웨어도 제작자의 마음을 알아주지 않을까?!
그리고 그동안에는 표준, 규약에 대해 불필요하다, 번거롭다라고 생각했었는데 이 또한 소프트웨어와 시스템, 사용자, 사람, 그룹의 안전을 위해 준수해야겠다는 생각을 했다.
귀찮다고 번거롭다고 등한시하지 말고, 좀 더 관심을 가지고 안전한 소프트웨어를 만들어야겠다는 생각을 했다.
4. Reference
김종하, “역사 속의 소프트웨어 오류”, 에이콘