[Special Column] SW안전 엔지니어링 도입의 어려움과 해결방안
일반적으로 높은 수준의 안전무결성이 요구되는 SW 제품을 개발하기 위해서는 방대한 규모의 기술 적용 요구사항이 포함되는 공학 방법론을 적용한다. 이들은 시스템 공학, 시스템 안전공학 및 신뢰성 공학 등이 결합된 형태이다. 그러나 이들 공학분야들은 전체적으로는 서로가 매우 이질적인 분야들이다. 또한 이 중에서 시스템 공학은 전체 안전 공학의 주요 기반이 되는 방법론의 하나로서 대략 시스템 수준 기술 적용 사항, HW 수준 기술 적용 사항, SW수준 기술 적용 사항 등으로 구분될 수 있다. 그리고 이들 시스템 수준별 기술 적용 사항들 사이에도 이질성은 적지않다. 그런데 SW 안전 엔지니어링에서는 이렇게 이질적인 기술들이 SW 개발 수명주기 전체에 걸쳐서 한꺼번에 고려되어야 한다. 그렇다면 개발해야 할 안전 SW의 규모는 얼마나 큰 것일까? 놀랍게도 이렇게 방대한 방법론을 적용해서 개발된 소프트웨어의 크기는 고작 1~2만 라인에 불과한 경우가 허다하다(이 정도면 사실상 매우 간단한 휴대폰 게임 어플리케이션 정도의 규모이다). 하지만 그 1~2만 라인을 위해 십여명 이상의 인력이, 1~3년 혹은 그 이상의 시간을 투자해야 하는 업무가 바로 SW 안전 엔지니어링이다. 그리고 이러한 수준의 개발 요건을 충족하기 위해서는 SPICE나 CMMI 급 프로세스 품질이 요구되는 경우가 대부분이다.
이처럼 다양한 이질적인 기술들이 조합되다 보니 기술 자체의 난이도 이상으로 중요하게 고려되어야 하는 것이 기술간 접점 관리이다. 특히 개발조직의 기술적 역량이 충분히 성숙되지 않은 경우에는 기술간 접점 관리의 어려움은 더욱 커지게 된다. SW 안전 엔지니어링 사례에서 흔하게 보고되는 일정지연의 이유는 보통 SW 관련 문서의 방대한 분량, 커버리지 테스트 소요 기간, 요구사항의 누락이나 변경으로 인한 작업 재수행[1] 등을 원인으로 꼽는 경우가 많다. 하지만 이들 뒤에는 사실상 기술 자체의 난이도 문제 및 기술간 접점관리의 문제가 숨어있는 것이 대부분이다.
안전성이 요구되는 SW의 개발과 관련하여 감당해야 할 이슈들은 방대하기 때문에, 중소규모의 기업에서 이러한 모든 이슈에 대응할 수 있는 개발 조직을 한번에 갖추는 것은 쉽지 않다. 하지만 이 모든 필요성의 가장 밑바탕에는 ‘몇 가지 핵심적 기술’에 대한 지식이 존재[2]한다. 이러한 지식은 지난 수십년간 연구되어온 것으로서 몇 가지 이론서나 표준서에 나타나 있다.
이들 지식체계들은 SW입력부의 안전 설계, SW프로세스부의 안전 설계 및 SW출력부의 안전 설계에 대한 부분을
공통적으로 포함하고 있고, 이를 지원하기 위한 전체 SW아키텍쳐에 대한 논의도 병행하고 있다. 일반적으로 SW안전 공정에서는 SW설계활동이 전체 공정에서 1/3 ~ 1/2(혹은 그 이상)의 노력을 소모하는 경우도 많다는 사실은 SW설계와 관련된 ‘몇 가지 핵심적 기술’에 대하여 우리에게 시사하는 바가 크다. 또한 SW개발 프로세스의 경우 많은 문헌에서 SW안전 요구사항의 명세기법을 강조하고 다양한 정적/동적 테스트 방법론들을 제시하고 있다. 그리고 안전성이 요구되는 모든 SW의 개발에서 필수적으로 적용되어야 하는 SW위험원 분석이나 FMEA/FTA도 많은 지식체계에서 함께
포함하고 있다[3].
SW의 아키텍쳐 및 상세 설계에 대한 지식체계는 SW입력부, SW프로세스부, SW출력부 및 SW 전체 아키텍쳐의
안전 설계를 위하여 가능한 설계대안(design alternative)들을 모두 파악하고 그 중에서 최적의 대안을 선정하는
과정을 지원하는 것이 필수적이다.
정보통신산업진흥원에서는 “중소기업의 실무 역량 강화를 위한 SW안전기술 활용서”를 발간하여 이 부분을 가능한 한 다루기 쉬운 형태로써 SW안전기술 역량강화 프로그램 랜딩페이지를 통해 무료로 배포하고 있다. 또한 SW 안전을 위한 요구사항의 분석 및 다양한 정적, 동적 테스팅 방법은 SW 공학 문헌들에서 어렵지 않게 접할 수 있다. 정보통신
산업진흥원에서는 “SW안전기술 활용교육”을 통해 SW 안전 요구사항 명세에 특화된 요구사항 교육과정 및
SW FMEA, FTA 에 대한 교육 역시 제공중이다. 활용서와 교육을 통해 제공되는 SW 안전 요구사항 명세 기법, SW
안전 설계 기법, 그리고 SW 안전 분석 기법은 특히 중소규모의 개발조직에게 적지 않은 도움이 될 것으로 예상된다.
앞으로 중소규모의 많은 개발 조직이 ‘몇 가지 핵심적 기술’을 출발점으로 하여 SW 안전을 실현할 수 있기를
희망한다.
[1] SW 안전 공정에서는 요구사항이 누락되거나 변경되는 것은 그다지 이상한 일이 아니다. 그 이유는 SW 안전
프로세스 자체가 주요 수명주기 단계마다 위험원 분석을 반복적으로 수행하는 것을 포함하고 있기 때문이다. 이 과정에서 SW 안전성을 높이기 위한 새로운 요구사항이 도출되게 되면 이것은 요구사항이 누락된 것과 동일한 결과가 되고 요구사항이 변경되는 경우는 말할 것도 없다.
[2] 소위 ‘SIL 인증’이라는 것이 산업계에 소개되었던 초기 무렵에는 SIL 인증을 받은 제품과 (SIL 인증을 받지는 않았지만) 안전성을 나름대로 충분히 고려한 제품이 산업계에 혼재하던 기간이 있었다. 그 당시에는 시장에 나왔던 이들
두 가지 제품이 그 기능, 성능 등의 면에서 서로간에 크게 차이가 나지 않은 경우가 많았다. 이것은 필자가 주장하는
‘몇 가지 핵심적 기술’ 개념을 지지하는 또 다른 사례로 볼 수 있다.
[3] 이 외에도 ‘몇 가지 핵심적 기술’에 포함될 수 있는 항목들을 추가적으로 고려할 수 있겠으나 본 고에서는 이 정도의 소개만으로 한정하기로 한다.
본 내용은 칼럼 작성자 개인의 의견으로 정보통신산업진흥원의 공식적인 의견이 아니며
사용되는 용어는 산업분야별로 달리 사용될 수 있음을 알려드립니다.