10. DO-178과 소프트웨어 계획 프로세스 (Section 4.0)

앞서 소프트웨어 라이프 사이클 프로세스에 대해서 알아보았다. 이제부터는 각각의 프로세스에 대해서 좀 더 상세한 내용이 나오게 된다. 첫 번째로 소프트웨어 계획 프로세스(Software Planning Process)이다.

 

DO-178 가이드라인에서는 소프트웨어 계획 프로세스에 대해서 알아야 할 부분을 크게 다음과 같이 구분하고 있다.

 

-       소프트웨어 계획 프로세스의 목표(Objectives)

-       소프트웨어 계획 프로세스의 활동(Activities)

-       소프트웨어 계획 프로세스의 출력(Outputs)

 

먼저 위의 구분은 DO-178 가이드라인의 부속물(Annex) A에 있는 아래의 표와도 연계되어 있다는 점을 기억하자. 빨간색 점선으로 표시된 부분을 보면 위에서 제시한 목표/활동/출력이 모두 포함된 것을 볼 수 있다.

 

사실 위의 표는 가이드라인의 내용을 기반으로 종합적으로 정리한 형태라고 할 수 있는데 실제 현장에서는 위의 표를 기준으로 인증활동이 많이 이루어지기 때문에 표가 의미하는 것이 무엇이고 어떻게 활용하는지를 반드시 이해하고 있어야 한다.

 

참고로 DO-178 가이드라인의 용어사전에는 활동(Activity)와 목표(Objective)에 대해서 다음과 같이 정의되어 있다.

 

해석을 보자.

 

활동(Activity) – 목표(Objective)를 만족하는 방법을 제공하는 태스크 목표(Objective) – 이 문서(참고: DO-178 가이드라인)가 규정을 준수하는 방법으로써 인정될 때 그 목표(Objective)를 준수한다는 것을 보여주기 위해 만족해야 하는 요구사항이 된다.

 

용어 자체는 어렵지 않을 텐데 여기서 중요한 점은 활동과 목표의 관계이다. 즉, 활동(Activity)은 반드시 특정한 목표(Objective)를 가지고 수행되어야 한다는 점이다. 두 가지가 서로 분리된 것이 아니라 밀접하게 연관되어 있는 개념이다. 정리하자면 결국 활동을 위한 목표가 설정되고 활동을 통해서 그 목표가 달성되어야 한다. 참고로 정의는 안되어 있지만 출력(Output)은 그러한 활동(Activity)을 통해서 목표(Objective)를 달성했음을 보여 주는 결과물(Results) 혹은 산출물(Artifacts)이라고 이해하면 된다.

 

(1)    소프트웨어 계획 프로세스의 목표(Objectives) (Section 4.1)

 

앞서 설명한 것처럼 소프트웨어 계획 프로세스의 목표는 이후 진행되는 개발 프로세스 전반에 걸친 활동의 근간이 된다. 따라서 이 계획이 어떻게 세워지고 얼마나 잘 정의되느냐는 소프트웨어 개발이 제대로 된 방향으로 진행될 수 있는지를 결정하는 중요한 부분이라고 할 수 있다. DO-178 가이드라인에서는 이를 위해서 아래와 같이 총 7가지의 목표(Objective)를 제시하고 있다.

 

a.     시스템 요구사항과 소프트웨어 레벨을 설명하는 소프트웨어 라이프 사이클의 소프트웨어 개발 및 전체 프로세스 활동들(Activities)을 정의

b.     프로세스간의 상호 관계, 순서, 피드백 메커니즘, 전이 기준을 포함하는 소프트웨어 라이프 사이클을 정의

c.     소프트웨어 라이프 사이클 활동들에 사용되는 방법과 툴을 포함한 소프트웨어 라이프 사이클 환경을 정의

d.     DO-178 가이드라인 Section 12에서 설명하는 추가적인 고려사항을 정의

e.     시스템 안전성 목표와 일치하는 소프트웨어 개발 표준(Standards)을 정의

f.      DO-178 가이드라인 Section 4.3 및 11과 일치하는 소프트웨어 계획을 생성

g.     소프트웨어 계획의 개발과 수정을 조율

 

참고로 이는 앞서 보았던 부속물(Annex) A의 표에서도 아래와 같이 확인할 수 있다. (1 ~ 7)

 

 

참고) 필자는 현장에서 DO-178 인증과 관련된 일을 할 때 위의 표를 상당히 자주 활용한다. 지금까지 설명한 것처럼 계획 프로세스에서 강조하는 핵심사항이 모두 포함되어 있기 때문이다. 표 자체만 보자면 마치 체크리스트처럼 보이기도 한다. 그리고 실제로도 대부분의 DO-178 인증에서는 위의 표를 체크리스트로 사용한다고 해서 크게 문제될 것은 없다.   하지만 분명히 알아야 할 점은 이것이 체크리스트가 아니라는 것이다. “체크리스트처럼” 사용할 수 있다는 것이지 체크리스트로 바로 사용할 수는 없다. DO-178 인증의 관점에서 보면 위의 표를 체크리스트로 사용하기 위해서는 각각의 항목들이 인증을 받고자 하는 소프트웨어에 적용 가능한 목표(Objective)들인지가 미리 확인되어야 한다. 무조건적으로 사용할 수는 없다는 뜻이다. 혹시라도 오해가 없기를 바란다.

 

(2)    소프트웨어 계획 프로세스의 활동(Activities) (Section 4.2)

 

DO-178 가이드라인에서 제시하는 소프트웨어 계획 프로세스에서의 주요 활동은 아래와 같다.

 

a.      가장 먼저 직원들이 제대로 된 방향으로 진행할 수 있는 가이드를 제시할 수 있는 계획을 작성

b.     계획과 함께 소프트웨어 개발에 대한 표준(Standard)을 정의

c.      에러를 방지하고 결점을 찾아내기 위한 방법과 툴을 정의

d.     계획의 일관성을 달성하기 위해 개발과 전체 프로세스를 조율

e.      계획을 작성하는 것 뿐만 아니라 수정하는 것에 대해서도 같은 수준의 방법을 결정

f.       다중 버전 비유사성 소프트웨어(Multiple-version Dissimilar Software)에 대해서 시스템 안전성을 고려

g.     계획과 표준이 형상관리되고 완전하게 리뷰

h.     비활성화된 코드(Deactivated Code) 사용에 대한 계획이 있을 경우 시스템 안전성에 대한 충분한 검토 방안을 작성

i.       사용자 수정가능 소프트웨어(User-modifiable Software) 사용에 대한 계획이 있을 경우 관련된 프로세스, 툴, 환경, 그리고 설계를 대신하는 데이터 아이템을 소프트웨어 계획과 표준에 구체화

j.       파라미터 데이터 아이템 사용에 대한 계획이 있을 경우 다음을 설명

1.      파라미터 데이터 아이템이 사용되는 방법

2.      파라미터 데이터 아이템의 소프트웨어 레벨

3.      파라미터 데이터 아이템의 개발, 검증 그리고 수정 프로세스와 관련된 툴인증

4.      소프트웨어 로딩 컨트롤 및 호환성

 

k.      추가 고려사항이 있을 경우 그에 대해서도 설명

l.       공급자가 있을 경우 공급자의 감독에 대해서 설명

 

위에서 보는 것처럼 소프트웨어 계획 프로세스에서 수행해야 할 활동들이 상당히 많다. 그리고 다중 버전 비유사성 소프트웨어, 비활성화된 코드, 사용자 수정가능 소프트웨어, 파라미터 데이터 아이템 등과 같은 특이한 용어들이 있어서 이해하기가 쉽지 않다.

 

일단 여기서 위의 내용을 모두 이해하고 가야 한다는 생각은 하지 말자. 필자의 의견으로는 위의 내용들은 DO-178 가이드라인을 전체적으로 이해할 수 있어야 파악할 수 있는 것들이다. 이런 활동들이 있구나 정도로 넘어가고 추후 정리하는 관점에서 다시 한 번 살펴보기를 추천한다.

 

(3)    소프트웨어 계획 문서 (Section 4.3)

 

DO-178 가이드라인에서는 소프트웨어 계획 프로세스의 목표(Objective)를 만족하기 위한 방법을 계획으로 정의하도록 가이드하고 있다. 쉽게 말해서 소프트웨어 계획 문서를 작성하는 것이다. 기본적으로 다음 문서들이 작성되어야 한다.

 

-       Plan for Software Aspects of Certification (Section 11.1): 인증을 받는 방법에 대한 계획

-       Software Development Plan (Section 11.2): 개발에 대한 계획

-       Software Verification Plan (Section 11.3): 검증에 대한 계획

-       Software Configuration Management Plan (Section 11.4): 형상관리에 대한 계획

-       Software Quality Assurance Plan (Section 11.5): 품질보증에 대한 계획

 

PSAC, SDP, SVP, SCMP, SQAP라는 약어로 부르기도 하는 위의 계획 문서들은 DO-178 인증 과정에서 가장 먼저 작성되는 필수 문서들이다.

 

소프트웨어 계획문서의 핵심은 바로 소프트웨어 라이프 사이클 프로세스 전반에 걸쳐서 진행되는 활동들(Activities)이 반드시 이 계획 문서와 일치해야 한다는 점이다. 만약 일치하지 않는 경우가 일부 존재하는 경우 그로 인해서 DO-178 인증을 받지 못할 수도 있다.

 

하지만 현실적으로 계획을 아무리 꼼꼼하게 세운다고 하더라도 실제 진행과정에서 변경사항이 생기기 마련이다. DO-178 인증에서는 이를 당연하게 받아들인다. 그래서 당연히 계획 문서를 수정할 수 있다. 그런데 무작정 수정하는 것이 아니라 바로 그 수정 절차 마저도 계획에 작성된 대로 진행한다. 만약 그렇게 계획에 작성된 대로 수정 절차가 이루어지지 않으면 DO-178 인증에서는 원칙적으로 그런 부분에 대해서는 인정하지 않는다. 이러한 수정 방법에 대한 작성을 포함해서 실제로 어떤 내용이 계획에 포함되는지는 각각의 해당하는 절에서 상세하게 설명하고 있다. 해당 절에서 추가 설명을 하겠다.

 

(4)    소프트웨어 계획 프로세스에서 추가로 고려해야 할 부분

 

DO-178 인증을 위한 소프트웨어 계획에는 앞서 언급한 것들 이외에도 다양한 내용들이 포함되어야 한다. 예를 들어 보자. 개발이나 검증에 사용되는 도구를 무엇으로 선택하느냐에 따라서 개발과정 전체에 영향을 줄 수 있다. 개발 비용에 막대한 영향을 미치는 경우도 있다. 사실 이 부분은 DO-178 인증 기준에서는 조금 관점이 다른 부분이 있다. 무슨 말인가 하면 DO-178 인증에서는 개발 비용이 문제가 아니라 툴로 인해서 소프트웨어에 문제가 발생할 수도 있다고 보는 것이다. 자세한 내용은 추후 툴인증과 관련된 부분에서 좀 더 자세하게 설명되겠지만 어쨌든 이런 식으로 추가로 고려해야 할 부분이 있다는 점을 기억하자.

 

DO-178 인증을 수행하는 현장에서는 때때로 이런 것들을 계획에 상세하게 정의해야 한다는 것을 전혀 인식하지 못하는 경우가 많다. 작성해야 한다는 것을 알고 있는 경우에도 DO-178에서 요구하는 수준으로 작성하지 않고 형식적으로 작성하기도 한다.

 

이런 식으로 추가로 고려되어야 할 부분에는 아래와 같은 항목들이 있다.

 

-       소프트웨어 개발 환경

-       소프트웨어 개발 언어 및 컴파일러

-       소프트웨어 시험 환경

-       소프트웨어 개발 표준

-       소프트웨어 계획 프로세스의 리뷰

 

①     소프트웨어 개발 환경

 

소프트웨어 개발 환경이라는 것은 결국 개발에 사용되는 툴이다. 그리고 소프트웨어 개발 환경이 미칠 수 있는 영향에 대한 설명을 위해서 DO-178 가이드라인에서는 아래와 같은 예시를 들고 있다.

 

해석을 보자.

 

예를 들면, 컴파일러가 에러를 주입해서 손상된 출력(output)을 생산할 수도 있고 링커가 메모리 할당 에러를 찾아내지 못해서 그 문제가 그대로 남아 있을 수 있다.

 

컴파일러와 링커는 소프트웨어 개발 환경, 즉 개발툴의 대표적인 사례라고 할 수 있다. 그런데 그런 컴파일러 혹은 링커가 잘못된 코드 결과물을 만들어 낼 수 있다고 설명하고 있다. 사실 개발자들에게 컴파일러가 오류가 있다는 것은 상상할 수 없는 부분이다. 그런 여지가 있는 컴파일러라면 애초에 사용되지 않을 것이기 때문이다. 하지만 DO-178에서는 이 세상의 어떤 컴파일러도 믿지 않는다. 즉, 세상의 모든 컴파일러는 잘못된 코드를 만들어 낼 수 있다고 가정하는 것이다. 따라서 우리가 사용하는 컴파일러가 완벽하다는 것을 공식적으로 증명해야 한다. 증빙을 제출해야 하는 것이다.

 

결론적으로 DO-178에서는 이에 대해서 툴인증(Tool Qualification)을 요구한다. 즉, 컴파일러에 대한 툴인증을 요구하는 것이다. 컴파일러에 대해서 요구한다는 것은 다른 개발툴에도 동일하게 요구한다는 것을 의미한다. 그리고 이는 검증툴에 대해서도 마찬가지다. 처음 이런 내용을 접하는 분들에게는 그야말로 어처구니 없는 요구사항이다. 도대체 무슨 수로 그것을 공식적으로 증명할 수 있다는 말인가?

 

사실 미리 조금 언급을 하자면 이에 대한 해결책은 의외로 간단하다. 그것도 2가지 방법이 있을 수 있다. 먼저 돈으로 해결하는 것이다. 툴을 판매한 업체에게 비용을 주고(엄청난 액수를 지불해야 겠지만) DO-178에서 요구하는 것을 만족시켜 달라고 하는 것이다. 우리나라의 현실을 본다면 이는 가능성이 거의 없는 방법이다.

 

다른 한 가지는 툴에서 나온 결과물을 하나하나 검증하는 것이다. 이것은 툴을 통해서 나온 결과물이 아무런 문제가 없다는 것을 직접적으로 확인시켜주는 것이다. 뭔가 이것도 말이 안될 것 같지만 실제로 현장에서는 이 방법을 주로 사용한다. 예를 들어 컴파일러에서 나온 바이너리에 대해서 모든 적용가능한 시험을 수행해서 요구사항을 완벽하게 만족하고 다른 문제를 일으키지 않는다는 것을 직접 확인하는 것이다. 하지만 이 방법은 결국 시험을 어떻게 하느냐가 관건이겠지만 현실적으로 가능할지 의구심이 들 수 밖에 없는 것이 사실이다.

 

앞서 첫 번째 방법은 우리나라에서는 가능성이 거의 없다고 설명했지만 실제로 DO-178 인증을 수행하는 미국과 같은 항공 선진국에서는 오히려 이것이 더 많이 채택되고 있다. 즉, 막대한 비용을 들여서 툴을 판매한 업체를 통해서 증빙을 구매하는 것이다. 하지만 이는 어디까지나 외국의 사례이며 우리나라에서는 불가능한 일이라고 봐야 한다. 이와 관련된 내용은 추후 별도의 절에서 자세한 설명이 있을 것이다.

 

어쨌든 이런 식으로, 사용되는 툴에 대한 내용, 그리고 그 툴을 통해서 나오는 결과를 어떤 식으로 보장할 지에 대한 내용 등을 소프트웨어 계획으로 정의해야 한다.

 

②     소프트웨어 개발 언어 및 컴파일러

 

앞서 프로그래밍 언어와 밀접한 관련이 있는 컴파일러에 대해서 예를 들어서 설명하기는 했지만 프로그래밍 언어와 관련해서는 추가로 고려해야 할 부분이 있다. 바로 컴파일러를 통해서 나온 바이너리가 소스코드와 1:1로 매칭되지 않는 부분이다. DO-178 가이드라인에서는 그 예를 아래와 같이 들고 있다.

 

해석을 보자.

 

b. 어떤 특성을 구현하기 위해서 일부 언어를 위한 컴파일러는 소스 코드와 직접적으로 추적 가능하지 않는, 예를 들면 초기화, 내장 에러 탐지, 혹은 예외 처리(6.6.6.2.b를 보라)와 같은 오브젝트 코드를 생성할 수 있다. 소프트웨어 계획 프로세스는 이러한 오브젝트 코드를 탐지하고 검증 커버리지를 보장하기 위한 방법을 제공해야 하며 적절한 계획에 그 방법을 정의해야 한다.

 

컴파일러가 일부 코드에 대해서 자동으로 코드를 추가하거나 최적화를 위해서 코드를 변경하는 부분에 대해서는 많이들 알고 있는 사실이다. 하지만 DO-178에서는 기본적으로 그것을 인정하지 않는다. 정확하게는 그렇게 하려면 그 변경이 아무런 문제를 일으키지 않는다는 것을 증명할 수 있어야 한다. 그리고 그 방법으로써 ‘커버리지 보장’이라는 말을 하고 있다. 커버리지에 대한 부분은 별도의 절에서 상세하게 설명이 될 것이다.

 

아무런 의심없이 당연하게 컴파일러를 사용해왔던 개발자들에게는 어찌 보면 황당한 이야기일 수 있지만 바로 이런 점이 항공기에 탑재되는 소프트웨어 개발에서 어려운 점이라고 할 수 있다. 참고로 이런 문제를 포함해서 여러 가지 고려사항이 있을 수 있기 때문에 항공기에 탑재되는 소프트웨어를 개발하는 언어는 마음대로 선택할 수 없고 일단 선택된 언어에 대해서는 많은 검토와 완벽한 보장이 있어야 한다. 그리고 그러한 내용이 소프트웨어 계획 프로세스에 정의되어야 한다.

 

참고로 DO-178 인증의 관점에서 또 하나 유의해야 할 부분이 있다. 아래의 설명이 그것이다.

 

해석을 보자.

 

유의사항: 비록 컴파일러가 일단 모든 검증 목표를 만족하는 것으로 여겨지더라도 그 컴파일러는 그 제품에 대해서만 받아들여지는 것이고 반드시 다른 제품에도 그대로 받아들여지는 것은 아니다.

 

위의 설명은 어떤 소프트웨어에 대한 DO-178 인증을 통해서 컴파일러가 아무런 문제가 없다는 것이 확인되더라도 그것은 단지 그 소프트웨어에 대해서만 인정되는 것이며 만약 다른 소프트웨어에 사용되는 경우에는 다시 똑 같은 과정으로 확인받아야 한다는 뜻이다. 어떻게 보면 이미 검증된 컴파일러를 쓸데 없이 또 한 번 확인작업을 하는 것으로 비쳐질 수 있는 부분이지만 그만큼 DO-178 인증은 엄격한 잣대를 가지고 있다는 것을 반증하는 부분이기도 하다.

 

③     소프트웨어 시험 환경

 

DO-178에서는 소프트웨어에 대한 시험에 대해서 기본적으로는 실제 운영되는 타겟에서의 시험을 요구한다. 즉, 모든 시험은 타겟에서 수행되어야 하고 타겟상에서의 결과가 확인되어야 하는 것이다. 하지만 현실에서는 불가능한 이야기이다. 실제로 DO-178에서는 그 부분을 인정하고 있으며 대신 타겟과 다른 환경, 예를 들면 호스트에서의 시험이나 에뮬레이터 혹은 시뮬레이터에서 시험하는 경우에는 그것이 타겟과는 어떤 점에서 다르고 거기에서 나오는 결과가 타겟과 비교해서 어느 정도 받아들일 수 있는지를 설명할 수 있어야 한다. 한마디로 결과를 믿을 수 있다는 데이터를 제공해야 한다는 말이다. 이러한 내용 역시 소프트웨어 계획 프로세스에서 정의할 수 있어야 한다.

 

④     소프트웨어 개발 표준

 

DO-178에서의 또 하나의 특징 중 하나는 아래와 같은 표준(Standard) 문서를 요구한다는 점이다.

 

-       Software Requirements Standards (Section 11.6): 요구사항 표준

-       Software Design Standards (Section 11.7): 설계 표준

-       Software Code Standards (Section 11.8): 코드 표준

 

이 문서들의 특징은 한 마디로 개발자들이 개발을 하면서 요구사항, 설계, 코딩의 통일성을 갖추기 위한 기준이 된다는 점이다. 만약 이러한 기준이 없으면 개발자들마다 혹은 문서 작성자들마다 서로 다른 방식으로 결과물을 만들어 내게 되어 그 만큼 소프트웨어의 안전성이 떨어질 가능성이 높아진다고 보는 것이다. 그런 면에서 DO-178에서는 소프트웨어 라이프 사이클 전반에 걸쳐서 적용할 수 있는 이러한 기준을 가질 것을 요구한다. 각각의 자세한 설명은 해당 절에서 다시 설명하게 된다.

 

참고로 위의 표준 문서들은 앞서 보았던 5가지 계획 문서들과 달리 반드시 작성해야 하는 것은 아니다. 하지만 FAA 혹은 DER은 이러한 기준이 있는지, 그리고 그 기준에 따라서 개발하고 있는지를 확인하기 때문에 계획 문서와 같은 필수 문서로 보아도 무방하다.

 

⑤     소프트웨어 계획 프로세스의 리뷰

 

지금까지 설명한 소프트웨어 계획 프로세스에 대한 내용은 결국 소프트웨어 라이프 사이클 전반에 걸쳐서 지속적으로 확인된다. 그리고 그 과정에서 발생하는 여러가지 문제점과 변경사항 역시 소프트웨어 계획 프로세스에서 정의된 계획을 기준으로 처리되는지 확인하게 된다. 이것이 실질적인 소프트웨어 계획 프로세스의 리뷰라고 할 수 있다. 이처럼 소프트웨어 계획 프로세스는 단순히 계획이 수립되는 한 번으로 끝이 아니라 소프트웨어가 완성되고 최종 인증되는 시점까지 지속적으로 영향을 받는다는 것을 기억하자.