2019년 2학기 고려대학교 차성덕 교수님 소프트웨어 공학
소프트웨어의 위기
많은 소프트웨어 프로젝트들이 품질, 비용, 기간 등의 목표를 도달하지 못하는 것을 바로 Software Crisis, 즉 소프트웨어의 위기라고 한다.
프로젝트의 성공과 실패의 기준이 명확하지는 않지만 일반적으로 처음 계획 및 예측이 합리적이라고 가정하고 그 기간, 품질 등에 어느정도 도달했을때 성공했다고 판단한다. 이러한 상황 아래 소프트웨어 프로젝트의 성공률은 50%가 넘지 않고, 기간을 초과하는 경우가 많다.
요구사항 정의 및 선행 프로젝트에서 배우기
사실 초기의 비용 산출 및 시간 설정은 굉장히 어려운 문제이다. 특히 SW 개발 초반에는 매니저 입장에서 진도 확인 또한 쉽지 않은데 이럴때는 문서와 도식화를 통해 요구사항들을 정의하고 관련된 인물들을 모아 리뷰를 함으로써 진행상황을 어느 정도 확인 할 수 있다. 또한 이전의 비슷한 프로젝트가 있다면 프로젝트 기간 설정 등을 참고할 수 있다.
책에서 배우기
참고로 SE의 클래식이라고 불리는 The Mythical Man-Month 라는 책에서는 “늦은 프로젝트에 사람을 추가하면 그 프로젝트는 더 늦어진다”라는 유명한 말이 나온다. 반드시 늦어진다고 할 수는 없으나 대체로 그렇다는게 정설이다. 이러한 책을 통해서도 프로젝트의 진행이 늦춰질때 어떻게 대처해야할지 힌트를 얻을 수 있다.
소프트웨어 에러 사례에서 배우기
소프트웨어의 품질 보증에 많은 영향을 미치는 것 중 하나가 바로 에러이다.
77.1*850의 결과값으로 100,000이 나왔던 엑셀 버그나, 작동 환경의 차이가 있음에도 불구하고 같은 SW를 사용해서 폭발해버린 Ariane 5 Failure 등과 같은 유명한 에러 사례들이 있다.
이러한 에러 처리는 엄격히 다루어져야 하는데 소프트웨어에서의 사소한 오류가 현실 세계에서는 큰 사고로 이어질 수 있기 때문이다.
간단한 문제에 필요 이상의 복잡한 솔루션을 적용해 에러가 생기는 경우도 있다. Therac-25와 같은 경우가 그러한데, 복잡한 솔루션으로 인해 race condition이 생겼고 이로 인해 암 세포 치료를 위한 엑스선 양의 치사량이 넘는 경우가 최소 6번이나 있었고 사망자는 최소 5명이 나왔다. SW를 고칠때마다 소프트웨어를 작동하는 환경도 달라지기에 그 부분에 대해 테스팅을 해야하는데 그마저도 하지 않았다고 한다.
An Investigation of the Therac-25 Accidents 라는 논문에서는 아래와 같이 해당 프로젝트에서 배울 수 있는 교훈이 나온다.
기본적인 소프트웨어 엔지니어링 원칙이 Therac-25에서는 지켜지지 않았다.
- 문서화는 나중에 덧붙인 것이 되어서는 안된다.
- 소프트웨어 품질 보증 수행과 기준이 확립되어 있어야 한다.
- 디자인은 심플하게 유지되어야 한다.
- software audit trails와 같이 에러를 알아낼수 있는 방법이 초기부터 소프트웨어에 디자인 되어야 한다.
- 소프트웨어는 모듈과 소프트웨어 레벨에서 광범위한 테스팅과 형식적인 분석을 거쳐야한다. 독립적인 시스템 테스팅은 부적절하다.
안전에 민감한 소프트웨어는 특별한 안전 분석과 디자인 절차가 프로젝트에 포함되어야한다. 안전은 소프트웨어에도 설계되어 있어야하고 이에 더해 소프트웨어 에러에도 문제 없는 안전 보증이 시스템 레벨에서 보장되어야 한다. Therac-20도 Tyler의 죽음으로 내몰았던 같은 에러를 갖고 있었지만 기계가 그 결과를 약화시키는 하드웨어 interlock을 포함하고 있었다. 소프트웨어 에러에 대한 보호가 소프트웨어 자체에 구현되어 있어야한다.
뿐만 아니라 더 중요한 교훈은 소프트웨어를 재사용할때 그것은 이미 널리 사용되어져 왔기 때문에 나이브한 가정이 만들어진다는 것이다. 소프트웨어 모듈을 재사용하는 것은 새로운 시스템에서 안전을 보장하지 않는다. 안전은 소프트웨어가 사용되는 시스템에서의 품질이지 소프트웨어 자체에 대한 품질이 아니다. 그냥 전체 소프트웨어를 처음부터 다시 쓰고 심플한 디자인으로 가는게 많은 경우에서 더 안전할 수도 있다.
이러한 실패 경험들을 잘 살펴보고 각각에서 얻을 수 있는 교훈을 통해 소프트웨어의 위기를 줄여나갈 수 있다.
소프트웨어 실패 원인에서 배우기
요구사항 이해 부족, 부적절한 계획과 예측, 새로운 기술, 시니어 개발자 부족 등과 같은 소프트웨어 실패 원인을 체크하고 이를 반면교사로 삼아 보완할 수도 있다.
USAF C-17과 같은 경우에는 부적절한 계획과 예측으로 인한 실패 사례이다. 41억 달러 예산에서 15억을 초과했고, 15만 줄이 예상된 프로젝트의 규모도 백만줄을 넘겼으며 C-17에서 소프트웨어가 차지하는 비중은 적다고 생각했기 때문에 프로젝트와 관리와 추적 또한 전혀 되어있지 않았다. 이를 두고 감사원에서는 국방부와 같은 프로젝트에 들어가는 SW 에서 일어나서는 안 될 나쁜 선례를 보여주는 좋은 예라고 했다.
이를 해결하기 위해서 데드라인 연장, 더 나은 프로젝트 관리 절차, 많은 인원과 자금 등등 당연한 것들이 있다.
사실 애초에 요구 사항이 바뀌는 것을 조금이라도 줄이기 위해 중간 중간 꾸준히 리뷰를 받는 것이 좋다. 또한 프로젝트 일정을 늘리거나 개발 범위를 축소하는 등의 요구를 할 때는 근거가 필요한데 이러한 스킬이 개발을 잘하는 것만큼이나 중요하다.
생각해볼점
- 내가 개발자라면/PM이라면 Therac-25와 같은 상황을 막기 위해 어떻게 했을까
- 비현실적인 프로젝트 목표, 필요한 리소스에 대한 부정확한 예측, 잘정의되지않은 시스템 요구사항, 프로젝트 상태에 대한 poor 리포팅, 관리되지 않은 위험들, 고객 개발자 사용자 간의 소통 부재, 미성숙한 테크놀로지 사용 등 많은 소프트웨어 실패 요인 가운데 가장 중요하다고 생각하는 세가지를 뽑는다면?
- 프로젝트 결정할 수 있는 영향력 가진 사람이라면 위의 문제점 개선 위해 무엇을 할까. 실천 방안
참고
http://www.cse.msu.edu/~cse470/Public/Handouts/Therac/Therac_5.html
