(Essay #4) 국방SW 신뢰성 시험평가 기준과 발전 방향
이번 에세이는 지난 에세이에 잠깐 언급한 적이 있는 국방SW의 신뢰성 시험평가 기준에 대해서 그 내용을 좀 더 자세히 한 번 다뤄볼까 한다. 이 신뢰성 시험 평가와 관련하여 나는 지난 주에 구미에서 있었던 모 사업의 SW 기본설계 Design Review에 참석하여 소프트웨어 신뢰성 확보 방안에 대해 10분 정도 발표를 하였다. 이때 논란이 되었던 신뢰성 시험 평가 기준 중 하나인 코드 커버리지(Code Coverage) 목표치 설정과 관련하여 고객과 함께 서로 간의 이해가 필요할 것으로 생각이 되어 이 부분에 대해 정리를 해보고픈 생각이 들었다.
작년에 발표된 “무기체계 내장형 소프트웨어 획득 및 실무 지침서”에 부록 9를 보면 소프트웨어 신뢰성 시험평가 기준이 기술되어 있다. 여기에 기술된 정의에 따르면 소프트웨어 신뢰성 시험이란 소프트웨어가 동작할 수 있는 다양한 경우의 수에 대한 확인으로 소프트웨어가 일으킬 수 있는 잠재적인 결함을 식별하는 시험을 말하며 형태에 따라 정적 시험 및 동적 시험으로 구분할 수 있다고 정의되어 있다. 즉, ISO 9126에 정의된 소프트웨어 품질 특성인 신뢰성과는 그 의미에 차이가 조금 있다.
참고) ISO 9126의 소프트웨어 신뢰성 : 소프트웨어가 규정된 조건에서 사용될 때 규정된 성능수준을 유지하거나 사용자로 하여금 오류를 방지할 수 있도록 하는 소프트웨어 제품 능력으로 부 특성으로 성숙성, 결함허용성, 회복성, 유용성이 있음
먼저 소프트웨어 신뢰성 시험 중에 하나인 정적 시험에 대해 알아보자. 정적 시험은 소프트웨어를 실행하지 않은 상태에서 결함을 검출하는 1)코딩 규칙 검증과 2)실행시간오류(Runtime Error) 검출 시험으로 나뉜다. 코딩 규칙 검증은 지침에 있는 소프트웨어 코딩 규칙대로 코드가 작성되어 있는지를 확인하는 시험이다. 이 부분은 자동차 분야에서 사용되고 MISRA 룰을 토대로 만든 것이고, 국방SW의 개발 분야가 다양하기 때문에 MISRA 룰 중에 잠재적인 결함을 연결될 수 있는 필수적인 코딩 룰만을 선별하여 코딩 규칙으로 만든 것으로 생각된다.
또 하나의 정적 시험 종류인 실행시간오류(Runtime Error) 검출 시험은 의미 분석 기반의 정적 분석 도구에 의한 결함 검출을 말한다. 지침에서는 CWE-658/659의 결함 목록을 사업 별로 선별하여 사용하도록 권고하고 있으나 아마도 업체별로 보유하고 있는 정적 분석 도구의 결함을 기준으로 할 것으로 생각된다. 실제 의미 분석 기반의 정적 분석 도구의 동작 방식은 코딩 룰 기반의 도구와는 다르게 분석을 라인 단위로 순차적으로 하는 것이 아니라 프로그램의 수행 경로를 추적하면서 시스템에 존재하는 런타임 오류를 찾아낼 수 있기 때문에 아마도 용어 정의를 할 때 실행시간오류(Runtime Error)로 정의를 한 것으로 생각된다. 용어 정의 상 동적 시험과 약간 혼란이 생길 수 있을 거 같다. 실행시간오류니깐 동적 시험의 결함으로 생각하는 사람들이 있을 수 있을 테니 말이다.
다음으로 동적 시험의 시험평가 기준인 3)코드 실행률(Code Coverage)에 대해서 알아보자. 코드 실행률은 목표값 설정이 가장 중요한 부분인데 지침에서는 임무 중요도(Mission severity), 기능 안전성 및 통제 능력(Functional safety, Controllability), 사용 빈도(Exposure rate)를 고려하여 설정하라고 기술되어 있다. 사실 위에서 나온 용어들은 항공SW에서 주로 쓰는 고려 사항으로 항공SW를 개발할 때는 DO-178B라고 하는 규격에서 코드 실행률(Code Coverage)의 목표치를 등급을 나눠서 A등급의 경우 MC/DC Coverage 100%, B등급의 경우, Decision Coverage 100%, C등급의 경우 Statement Coverage 100%를 요구하고 있다. 하지만 현재 국방SW의 경우 지상용 장비이거나 임무를 직접 수행하지 않는 여러 지원 장비에 들어가는 SW를 개발하는 경우도 대다수 있기 때문에 SW 특성 상 코드 실행률를 항공SW와 동일하게 맞춰나가기 힘듦 여러 가지 상황이 많이 존재한다. 그리고 동적 시험의 특성 상 정적 시험과는 다르게 테스트 케이스를 설계 하는 과정이 비용과 시간이 많이 들어가는 점을 간과하지 말아야 하며, 획일화된 목표를 무조건적으로 설정하는 것은 바람직하지 않다는 생각이 든다. 지난 고객과 함께 하는 회의에서 SW의 특성이나 사업의 비용 및 기간을 고려하지 않고, MC/DC Coverage 100%를 요구하는 고객이 있어 잠깐 논쟁을 하였던 경험이 갑자기 생각난다.
지금까지 방위청 지침에 나온 3가지 소프트웨어 신뢰성 시험평가에 대해서 정리해보았다. 여기에 좀 더 보완하거나 강화해야 하는 부분으로 정적 시험 중에 Cyclomatic Complexity와 같은 정보들을 측정하여 기준치 이상이 되었을 때 동적 시험을 수행할 수 있도록 하는 방안이나 소프트웨어 요구사항 문서나 설계 문서가 테스트가 가능할 정도로 작성되어 있는 지 검토하는 등의 시험 용이성 측면의 동료 검토도 포함되면 보다 효과적인 시험이 이루어질 수 있지 않을까 하는 생각이 든다. 그리고 동적 시험에서는 단순히 자동화 도구를 통한 코드 실행률(Code Coverage)을 측정하는데 그치지 말고, 동적 시험을 위해 필요한 테스트 케이스를 설계하는 활동을 인정하고, 그에 따른 공수가 시험을 실제로 수행하는 데 들어가는 비용보다 많이 들어감을 고객 및 개발자가 함께 인식해야 할 것으로 생각이 든다. 테스트를 그냥 수행 측면에서 바라보는 것이 아니라 테스트도 개발과 마찬가지로 분석->설계 단계를 거쳐서 수행하는 것으로 인식하고 설계 단계에서 보다 효율적인 테스트 케이스를 만들기 위한 테스트 설계 기법 등도 연구를 해야 할 것으로 생각된다. 테스트 설계 기법에 대해서는 또 다음 에세이에서 한번 다뤄볼까 한다.
