8. DO-178과 시스템의 관계 (Section 2.0)

예전에 필자가 포스팅한 내용 중에 아래와 같은 그림을 사용한 적이 있다. 소프트웨어에 대한 DO-178 인증과 체계에 대한 인증이 어떤 관계를 가지고 있는지를 설명하기 위한 그림이었는데 어쩌면 이 그림이 바로 이 절에서 설명하고자 하는 것을 그대로 보여주는 것이 아닐까 싶다.

 

그림 15 체계인증과 DO-178/DO-254 인증의 구분

 

위의 그림에서 보듯이 항공기는 여러 개의 시스템으로 구성된다. 그리고 그 시스템은 다시 하드웨어와 소프트웨어의 조합으로 구성된다. 그리고 이러한 구분을 기준으로 소프트웨어에 대해서는 DO-178 인증을, 하드웨어에 대해서는 DO-254 인증을 받게 된다. 항공기 자체는 이러한 인증이 모여서 최종적인 체계 인증을 받게 된다.

 

여기에서 시스템이 하드웨어와 소프트웨어로 구성되어 있다는 것이 중요하다. 즉 어떤 시스템이 만들어지느냐에 따라서 그 속에 포함되는 하드웨어와 소프트웨어의 구성이 완전히 달라지게 되는데 결국 이것은 항공기에 탑재되는 하드웨어와 소프트웨어가 시스템의 영향을 받는다는 것을 말해 주는 것이다.

 

DO-178 가이드라인에서는 그와 관련된 설명을 위해서 시스템에 대한 설명을 가이드라인의 가장 첫 부분이라고 할 수 있는 Section 2에서부터 설명하고 있다. 중요성을 짐작할 수 있는 부분이다. 물론 그렇다고 해서 DO-178 가이드라인에서 시스템에 대한 모든 것을 설명하지는 않는다. 결과적으로 소프트웨어에 대한 DO-178 인증에 대한 설명을 위해서 필요한 부분만을 설명하게 되는데 각각의 내용은 아래와 같다.

 

해석을 보자.

 

l  소프트웨어로의 시스템 요구사항 할당 (2.1을 보라) l  시스템과 소프트웨어 라이프 사이클 프로세스간 그리고 소프트웨어와 하드웨어 라이프 사이클 프로세스간의 정보 흐름 (2.2를 보라) l  시스템 안전성 평가 프로세스, 실패 조건, 소프트웨어 레벨 정의 그리고 소프트웨어 레벨 결정 (2.3을 보라) l  아키텍처 고려사항 (2.4를 보라) l  시스템 라이프 사이클 프로세스에서 소프트웨어 고려사항 (2.5를 보라) l  소프트웨어 라이프 사이클 프로세스에서 시스템 고려사항 (2.6을 보라)

 

여기에서 DO-178 인증을 받기 위해서는 소프트웨어에 대한 내용 뿐만 아니라 관련된 시스템에 대해서도 알아야 하는 부분이 있다는 것을 확인할 수 있다. 사실 현장에서는 바로 이런 부분에 대해서 제대로 파악하지 못하고 진행하는 경우가 상당히 많으며 (솔직히 필자는 국내에서 진행하는 DO-178 인증의 대부분이 이런 문제를 안고 있다고 생각한다) 그로 인해서 진행에 문제가 생기거나 어려움이 발생하는 경우가 많다. 어쩌면 DO-178이 소프트웨어에 대한 인증이라는 것에만 매몰되어 그 외의 것들은 전혀 고려하지 않는 잘못된 인식에 기인한 것인지도 모르겠다.

 

이제 위의 항목들을 하나하나 살펴보면서 그러한 잘못된 인식을 바로잡아 보자.

 

(1)    소프트웨어로의 시스템 요구사항 할당 (Section 2.1)

 

서두에 보았던 그림에서처럼 시스템은 하드웨어와 소프트웨어로 구성된다. 이는 결국 시스템의 기능 즉, 시스템에 대한 요구사항이 하드웨어와 소프트웨어로 할당된다는 것을 의미한다. 물론 두 개가 서로 조합되어 하나의 기능을 수행하게 되겠지만 결국 그 하나의 기능을 수행하기 위해서 하드웨어와 소프트웨어가 각각 어떤 기능을 해야 할지를 지정해 주어야 한다. 그것이 바로 여기에서 말하는 시스템 요구사항 할당이라고 할 수 있다. 그런데 항공기에 대한 인증의 관점에서는, 그리고 DO-178 인증의 관점에서는 이러한 할당이 단순히 기능과 관련된 요구사항으로 한정되는 것은 아니다. 그 외에도 고려되는 부분이 여러 가지가 있는데 DO-178 가이드라인에서는 아래와 같은 것들이 포함된다고 말하고 있다.

 

해석을 보자.

 

a.     기능 및 운영 요구사항 b.     인터페이스 요구사항 c.     성능 요구사항 d.     파티션, 비유사성, 다중화 혹은 안전 모니터링과 같은 안전 전략, 설계 제약 그리고 설계 방법을 포함하는 안전성 관련 요구사항. 또한 시스템이 다른 시스템의 컴포넌트인 경우에는 다른 시스템에 대한 요구사항과 실패 조건이 소프트웨어에 할당된 시스템 요구사항의 일부를 구성할 수 있다. e.     안전 요구사항 f.      유지보수 요구사항 g.     적용가능한 인증당국 규정, 이슈페이퍼, 등을 포함하는 인증 요구사항 h.     시스템 라이프 사이클 프로세스를 지원하기 위해 필요한 추가적인 요구사항

 

위의 목록에서 특히 주목해야 할 부분은 바로 d의 안전성 관련 요구사항이다. 사실 개발자의 관점에서는 안전성이라는 것은 쉽게 와 닿지 않는 부분이다. 일반적으로 소프트웨어 개발 자체에서는 대부분 안전성이라는 것에 대해서는 크게 신경쓰기 않기 때문이다. 하지만 항공기에 탑재되는 순간부터 안전성은 그 무엇보다도 중요한 부분이 된다. 소프트웨어의 잘못된 동작이 자칫 항공기를 추락하게 만들 수도 있기 때문이다. 이런 이유로 위와 같이 시스템으로부터 할당되는 요구사항에는 안전성에 관련된 요구사항 또한 아주 중요한 항목 중 하나이다.

 

(2)    시스템과 소프트웨어 라이프 사이클 프로세스간 그리고 소프트웨어와 하드웨어 라이프 사이클 프로세스간의 정보 흐름 (Section 2.2)

 

DO-178 가이드라인에는 시스템 개발 프로세스와 소프트웨어 개발 프로세스 그리고 하드웨어 개발 프로세스간의 정보 흐름을 설명하는 아래와 같은 그림이 있다. 복잡하게 보이지만 기본적인 구성은 앞서 설명했던 시스템과 하드웨어, 소프트웨어의 관계를 그대로 보여주고 있다.

 

 

위의 그림을 간단하게 요약하면 아래와 같이 표현할 수 있다.

 

그림 16 시스템과 소프트웨어 라이프 사이클 프로세스간의 정보 흐름 간략화

 

여전히 복잡하긴 하지만 전체적인 구조 자체는 조금 더 단순해 졌다. 그 사이에 주고받는 부분도 큰 개념으로 보자면 위와 같이 요약할 수 있다. 여기에서 세부적인 내용을 모두 설명하지는 않겠다. 기본적으로 앞에서 소프트웨어로 할당되는 항목들을 정리했었는데 그것을 포함해서 전체적인 관점으로 보면 위의 그림과 같이 요약할 수 있다는 점을 이해하면 된다.

 

다만 한 가지 추가적인 설명이 필요한 부분은 바로 위의 붉은색 점선으로 표시된 부분이다. “파생된 요구사항, 문제점 혹은 수정사항”이라고 되어 있고 소프트웨어 라이프 사이클 프로세스에서 시스템 라이프 사이클 프로세스로 화살표가 향하고 있다. DO-178 인증 관점에서는 이 흐름에 담긴 의미가 상당히 많다. 이해를 위해서 이와 관련된 시나리오를 예로 들어 보자. 먼저 ‘파생된 요구사항’에 대한 시나리오이다.

 

①    소프트웨어에서 시스템과 관계없는 독자적인 요구사항을 하나 선정한다. 이를 파생 요구사항(Derived Requirement)라고 부른다.

②    선정된 파생 요구사항을 시스템 라이프 사이클 프로세스로 전달해서 시스템 관점에서 안전성을 포함한 시스템 전체에 영향을 미치지 않을 것인지를 확인한다.

③    소프트웨어로부터 받은 파생 요구사항에 대해서 시스템 라이프 사이클 프로세스를 거치면서 문제가 없음이 확인되면 소프트웨어 라이프 사이클 프로세스에서는 해당하는 파생 요구사항을 구현하게 된다.

④    만약 시스템 라이프 사이클 프로세스를 거치는 과정에서 문제가 확인되면 그것을 고려한 새로운 요구사항(혹은 검토 지시)이 소프트웨어로 전달된다.

 

그림에서는 간단한 한 줄에 지나지 않지만 그 내부에 담긴 세부적인 절차가 상당히 복잡하다는 것을 확인할 수 있다. 사실 개발 현장에서 이런 식의 진행이 실제로 이루어 지기는 상당히 어렵다. 소프트웨어 개발을 하다 보면 수 많은 기능들이 정의되며 그것들을 구현하기에도 정신 없이 바쁘다. 이런 식으로 시스템과의 연관성까지는 아예 생각조차 하지 못하는 경우가 많다. 그러다 보니 실제로 위와 같은 케이스가 발생하더라도 단순히 기능 하나가 추가된 것으로 생각하고 소프트웨어 라이프 사이클 프로세스 자체적으로만 소화(?)하고 넘어가는 경우가 많다. 하지만 DO-178 관점에서는 절대 이를 용납하지 않는다. 만약 위와 같은 절차를 제대로 수행하지 않는 경우에는 DO-178 가이드라인에서 제시한 기준을 따르지 않은 것이 되므로 결과적으로 그것 하나 때문에 DO-178 인증을 받지 못할 수 있다.

 

다음은 ‘문제점 혹은 수정사항’에 대한 시나리오이다.

 

①    소프트웨어를 구현하다 보니 시스템에서 할당된 요구사항이 일부 잘못된 부분이 발견되었다. 그래서 수정을 해야 한다. 이를 문제점 혹은 수정사항이라고 부른다.

②    문제점 혹은 수정사항을 시스템 라이프 사이클 프로세스로 전달해서 시스템 관점에서 안전성을 포함한 시스템 전체에 영향을 미치지 않을 것인지를 확인한다.

③    소프트웨어로부터 받은 문제점 혹은 수정사항에 대해서 시스템 라이프 사이클 프로세스를 거치면서 문제가 없음이 확인되면 소프트웨어 라이프 사이클 프로세스에서는 해당하는 문제점 혹은 수정사항을 처리하게 된다.

④    만약 시스템 라이프 사이클 프로세스를 거치는 과정에서 문제가 확인되면 그것을 고려한 재검토 혹은 새로운 수정사항이 소프트웨어로 전달된다.

 

누구나 아는 것처럼 소프트웨어 개발이 한 번에 완벽하게 이루어지는 법은 없다. 시스템으로부터 할당된 요구사항이라고 하더라도 소프트웨어 개발 과정에서 일부 혹은 전체적으로 잘못된 부분이 발견될 수 있다. 이런 경우 소프트웨어 차원에서 알아서 수정하는 것이 아니라 앞서 설명한 것과 동일한 방식으로 문제점에 대해서 시스템 차원의 검토를 거치게 되는 것이다. DO-178 기준에서는 소프트웨어와 관련된 수정사항은 반드시 시스템 레벨의 검토와 확인을 거쳐야 한다는 점을 반드시 기억하자.

 

(3)    시스템 안전성 평가 프로세스, 실패 조건, 소프트웨어 레벨 정의 그리고 소프트웨어 레벨 결정 (Section 2.3)

 

필자가 번역한 DO-178 인증지침서에 보면 아래와 같은 소프트웨어 레벨을 설명하는 그림이 있다.

 

그림 17 소프트웨어 위험레벨의 구분

※ 출처: Avionics Certification: A Complete Guide to DO-178 (software), DO-254 (hardware) / Vance Hilderman, Tony Baghi

 

한 마디로 소프트웨어가 고장났을 때 항공기가 어느 정도의 위험에 빠질 수 있느냐를 레벨로 구분한 것이다. DO-178에서는 소프트웨어에 대한 인증을 할 때 위의 레벨 중 하나를 정해서 진행하게 된다. 바로 그 지정을 하는 것이 시스템 레벨에서 수행하는 일이다.

 

구체적으로 소프트웨어 레벨 선정은 시스템 안전성 평가(System Safety Assessment)를 통해서 결정된다. DO-178 가이드라인에서 시스템 안전성 평가를 구체적으로 설명하고 있지는 않다. 다만 아래와 같이 시스템 라이프 사이클 프로세스를 통해서 소프트웨어 레벨이 선정되어야 한다는 것을 설명한 부분을 확인할 수 있다.

 

해석을 보자.

 

시스템 안전성 평가 프로세스와 소프트웨어 레벨   이 섹션은 소프트웨어 컴포넌트에 대한 소프트웨어 레벨이 어떻게 결정되고 아키텍처 고려사항이 소프트웨어 레벨 할당에 어떻게 영향을 미치는지에 대한 간략한 소개를 제공한다. 그러한 활동들이 어떻게 수행되는지를 설명하는 것은 이 문서의 의도가 아니다. 이것은 시스템 라이프 사이클 프로세스의 일부로써 수립되고 수행되어야 한다.

 

필자 역시 시스템 안전성 평가의 구체적인 내용에 대해서는 설명하지는 않는다. 그 자체만으로도 별도의 책으로 정리해야 할 만큼 방대한 분량이기 때문이다. 그런데 이런 어려움 때문인지는 모르겠지만 현장에서 DO-178 인증을 받으려고 하는 케이스들을 보면 시스템 안전성 평가를 수행하는 업체를 거의 찾아볼 수 없다. (물론 필자의 한정된 경험일 수도 있다) 더구나 그것이 필요하다는 인식조차 하지 못하는 경우가 많아서 특히 인증을 시작하는 초기 단계에서 이 부분을 어떻게 처리해야 하는지에 대해서 혼선이 발생하는 경우가 많다. 기본적으로는 시스템 안전성 평가를 공식적으로 진행하고 시스템으로부터 소프트웨어 레벨을 할당 받는 것이 원칙이지만 만약 그것이 불가능한 상황이라면 그것을 어떻게 처리해야 할 지를 명확하게 정리해야 한다. 그래야 이후 진행이 가능하다. 참고로 그런 경우에 선택할 수 있는 한 가지 방법은 DO-178 인증을 감사하게 되는 DER과 직접 상의하는 것이다.

 

이 부분을 마무리하기 전에 DO-178에서 말하는 소프트웨어 레벨이 무엇인지에 대해서만 정리를 해 보자. 관련해서 실패 조건(Failure Condition)과 같이 추가로 이해해야 할 부분이 있지만 필자의 판단으로는 지금 시점에서는 굳이 그런 내용까지 이해할 필요없이 지금까지 설명한 내용만 이해하더라도 충분하다는 생각이다.

 

DO-178 가이드라인에서 구분하는 소프트웨어 레벨은 그림 17에서 보듯이 아래와 같은 5가지이다.

 

각각에 대한 설명을 간략하게 줄이면 다음과 같이 정리할 수 있다.

 

a.     Level A: 항공기에 치명적인 실패(Catastrophic Failure)를 가져오는 문제점을 만들 수 있는 소프트웨어

b.     Level B: 항공기에 위험한 실패(Hazardous Failure)를 가져오는 문제점을 만들 수 있는 소프트웨어

c.     Level C: 항공기에 주요한 실패(Major Failure)를 가져오는 문제점을 만들 수 있는 소프트웨어

d.     Level D: 항공기에 사소한 실패(Minor Failure)를 가져오는 문제점을 만들 수 있는 소프트웨어

e.     Level E: 문제점이 발생해도 항공기에 별다른 영향을 미치지 않는 소프트웨어

 

여기서 치명적인(Catastrophic), 위험한(Hazardous), 주요한(Major), 사소한(Minor)에 대한 용어가 구체적으로 무엇을 의미하는지에 대해서도 DO-178 가이드라인에서는 다음과 같이 설명하고 있다. 위험 정도를 정량적으로 구분하는 것은 불가능하다. 대신 시스템 안전성 평가 프로세스를 통해서 위험성을 아래와 같은 카테고리를 기준으로 구분함으로써 소프트웨어 레벨을 결정하게 된다. 해석은 생략한다.

 

 

(4)    아키텍처 고려사항 (Section 2.4)

 

아키텍처 고려사항에 대해서 설명하는 DO-178 가이드라인에는 아래와 같은 내용이 나온다.

 

해석을 보자.

 

시리얼 구현(Serial Implementation)은 하나의 시스템 기능에 여러 소프트웨어 컴포넌트들이 사용되는 것으로 어떤 컴포넌트의 비정상적인 동작이 실패 조건을 만들어 낼 수 있다. 이러한 구현에서는 소프트웨어 컴포넌트가 시스템 기능의 가장 심각한 실패 조건 분류와 관련된 소프트웨어 레벨을 가질 것이다.

 

위의 설명에서는 ‘시리얼 구현(Serial Implementation)’이라는 용어가 키워드인데 간단하게 말하자면 하나의 실행파일로 구성된 소프트웨어를 말한다. 일명 ‘통으로’ 되어 있기 때문에 소프트웨어 전체를 구성하는 각각의 컴포넌트들이 아무리 많더라도 그 중 하나만 잘못 동작해도 전체 동작에 영향을 미칠 수 있는 그런 구조를 말한다. 이런 경우에는 무조건 그 소프트웨어가 가질 수 있는 가장 높은 위험성이 그 소프트웨어 레벨이 된다.

 

이에 반해서 만약 파티션으로 구성된 소프트웨어 즉, 실행파일이 여러 개로 구분되고 운영체제와 같은 상위레벨에서 파티션으로 완벽하게 구분되어 동작하는 소프트웨어라면 하나의 소프트웨어가 잘못 동작하더라도 다른 소프트웨어에 영향을 미치지 않을 가능성이 높아진다. 이런 경우에는 각각의 파티션마다 서로 다른 위험성을 고려해서 서로 다른 소프트웨어 레벨을 가질 수도 있다.

 

아키텍처 고려사항이라는 것은 결국 이러한 구분이 있느냐 없느냐를 말하는 것이다. 그리고 이는 앞에서 여러 번 언급했던 시스템 안전성 평가와 관련된다. DO-178 가이드라인에서 아키텍처 고려사항에 대해서 다음과 같이 세 가지를 들고 있다.

 

파티션(Partitioning), 다중 버전 비유사성 소프트웨어(Multiple-Version Dissimilar Software), 안전 모니터링(Safety Monitoring)이 제시되어 있는데 이들은 모두 안전성을 구현하는 구체적인 기법들이라는 공통점을 가지고 있다. 참고로 여기에 나온 아키텍처 고려사항은 단순한 예시일 뿐으로 DO-178 인증에서 반드시 적용되어야 하는 것은 아니다. 상대적으로 많이 사용되는 기법이라는 정도로만 이해하자.

 

DO-178 가이드라인에는 각각에 대한 비교적 자세한 설명이 나와 있지만 여기서 그 부분을 언급하는 것은 생략하기로 한다. 추후 각각에 대해서 별도로 설명할 기회가 있을 것이다. 여기서는 소프트웨어 레벨을 결정하는 데 있어서 안전성을 위해 이러한 기법들이 고려될 수 있고 이에 대한 적용은 시스템 안전성 평가 프로세스를 통해서 결정될 수 있다는 점을 이해하는 것이 중요하다. DO-178 가이드라인에서는 이에 대해서 아래와 같이 설명하고 있다.

 

해석을 보자.

 

시스템 안전성 평가 프로세스는 기능(즉, 상위레벨 요구사항)과 설계(예를 들면 공통 설계 요소, 언어, 그리고 툴) 모두에 대해서 소프트웨어 컴포넌트간에 충분한 독립성이 존재한다는 것을 만들어낼 필요가 있다.   만약 소프트웨어 컴포넌트간에 파티션과 독립성을 증명할 수 없다면 소프트웨어 컴포넌트들은 소프트웨어 레벨을 할당할 때 하나의 소프트웨어 컴포넌트로써 보아야 한다. (즉, 모든 컴포넌트들이 소프트웨어가 부여할 수 있는 가장 엄격한 실패 조건과 관련된 소프트웨어 레벨로 할당된다.)

 

시스템 안전성 평가 프로세스를 통해서 파티션과 독립성이 확인되며 만약 그것이 제대로 확인되지 않을 경우에는 결과적으로 앞서 설명했던 ‘시리얼 구현’처럼 그 소프트웨어가 가질 수 있는 가장 높은 위험성을 기준으로 소프트웨어 레벨이 결정되는 것이다. 참고로 소프트웨어 레벨이 높다는 것은 간단하게 말하면 그 만큼 인증을 받기 위한 과정이 복잡하고 어렵다는 의미이다. 이처럼 소프트웨어 레벨의 결정에 시스템 차원에서의 아키텍처 고려사항이 중요하다는 점을 다시 한 번 기억하자.

 

(5)    시스템 라이프 사이클 프로세스에서 소프트웨어 고려사항 (Section 2.5)

 

일반적으로 시스템 라이프 사이클 프로세스와 소프트웨어 라이프 사이클 프로세스는 서로 구분되는 개념이지만 경우에 따라서 시스템 라이프 사이클 프로세스내에도 소프트웨어에 대한 고려사항이 존재할 수 있다. DO-178 가이드라인에서는 아래와 같은 항목들을 들고 있다.

 

사실 위에 나열된 것들 중 일부 용어는 한국어로 일반화된 단어는 없는 것으로 알고 있다. 사용되는 곳에 따라서 각자의 해석대로 사용하는 식이다. 원문 영어조차도 일부 단어가 다른 경우가 있는데 일단 필자는 대체로 아래와 같이 번역해서 사용하고 있다.

 

a.     파라미터 데이터 아이템 파일(참고: 일반적으로 파일형태로 사용되는 설정파일을 말한다) b.     사용자 수정가능 소프트웨어 c.     상용(COTS) 소프트웨어 d.     옵션 선택가능 소프트웨어 e.     현장 적재가능 소프트웨어 f.      시스템 검증에서의 소프트웨어 고려사항

 

참고) 국토교통부에서 발행한 항공용 소프트웨어 승인 지침서(Software Approval Guidelines)에 보면 아래와 같이 “사용자 수정가능 소프트웨어”, “현장 적재(로딩)가능 소프트웨어”에 대한 정의가 나온다. DO-178을 기반으로 만들어진 문서이므로 직접적인 참고가 될 것이다.

※ 출처: 항공용 소프트웨어 승인 지침서 / 국토교통부

 

시스템과 관련된 대부분이 그런 것처럼 위에서 제시된 항목들 역시 DO-178 인증에서 미리 고려하지 못하고 그대로 진행되는 경우가 많은 항목들이다. 더구나 생소한 용어만큼이나 부족한 정보로 인해서 막상 무엇을 준비해야 하는지 파악조차 하지 못하는 경우가 많다.

 

일단 기본적으로는 DO-178 가이드라인에서 설명하는 것을 기준으로 삼아야 한다. 그 외에 구글링이나 다른 참고 자료를 활용할 수도 있을 것이다. 위의 항목 전부를 여기에서 설명하기에는 내용이 너무 방대해 지므로 각각의 세부 설명과 고려사항에 대해서는 가이드라인을 참고하고 여기서는 “c. 상용(COTS) 소프트웨어”에 대해서만 조금 더 살펴보자.

 

사실 다른 항목들은 일반적인 소프트웨어의 경우라면 해당하는 경우가 그렇게 많지 않다. 하지만 COTS라고 하는 상용 소프트웨어는 대부분의 경우에 사용되기 때문에 반드시 고려해야 할 항목이다. 특히 사용되는 소프트웨어의 종류와 유형이 제각각 이라서 이를 DO-178 인증에서 요구하는 기준으로 정리하는 것이 결코 쉽지 않다. COTS 자체에 대한 부분은 다른 절에서 살펴보기로 하고 여기서 꼭 기억하고 넘어갈 부분은 바로 COTS가 사용되는 경우 자신이 개발하고 있는 소프트웨어와 거의 동일한 수준의 증빙이 마련되어야 한다는 점이다. 극단적으로 보자면 실제 코딩을 하느냐 하지 않느냐의 차이만 있을 뿐 나머지는 모두 동일한 수준과 분량으로 준비해야 한다. 다만 여기에는 한 가지 옵션이 있을 수 있다. 바로 그러한 증빙을 COTS를 만든 업체로부터 구매하는 것이다. 한마디로 돈으로 해결하는 것이다. (물론 구매하더라도 별도의 추가 작업이 있기 때문에 돈으로 완벽하게 해결할 수 있는 부분도 아닌 셈이다.)

 

처음 듣는 분들이라면 생소하게 들리겠지만 이는 사실이다. 특히 COTS는 인증에 필요한 증빙을 구매해서 적절하게 가공한 후 제출하는 것이 일반적인데 개념적으로 어려운 것뿐만 아니라 비용적인 문제가 크게 다가올 수 있는 부분이라고 할 수 있다.

 

참고로 마지막에 제시된 “f. 시스템 검증에서의 소프트웨어 고려사항”은 소프트웨어가 아닌 시스템 검증에 대한 내용이어서 DO-178 가이드라인을 벗어나는 주제로 볼 수도 있는데 이것은 만약 시스템 레벨의 검증에서 확인할 수 없는 부분이 있을 경우 다른 방법을 고려해야 하는데 그 중 한 가지 방법으로써 소프트웨어 레벨에서 확인할 수 있는지를 검토해볼 수도 있다는 것을 말하는 내용이다.

 

(6)    소프트웨어 라이프 사이클 프로세스에서 시스템 고려사항 (Section 2.6)

 

앞서 잠시 언급되었던 “f. 시스템 검증에서의 소프트웨어 고려사항”과 반대의 경우라고 할 수 있다. 즉, 소프트웨어 라이프 사이클 프로세스 내에서 만족할 수 없는 것이 있을 경우 시스템 라이프 사이클 프로세스에서 확인 가능한 부분이 있을 수 있다는 뜻이다. 이런 경우에는 비록 소프트웨어를 위한 증빙을 위한 것이라고 하더라도 시스템 차원에서 증빙을 확보해서 제출할 수 있어야 한다.