8. 시작하기

 

DO-178과 DO-254를 받아들이는 데에는 기본적으로 2가지 방법이 있다. 빅뱅이론 혹은 진화가 그것이다. 당신이 처음 시작하는 사람이라면 우리는 빅뱅을 추천한다. 레벨 1, 2, 3 그리고 4를 거쳐가는 SEI 프로세스를 피하라. 왜냐하면 점진적인 진화를 통해서 가까이 가기에는 그 갭이 너무 크기 때문이다. 대신 비공식적인 개발 프로세스들을 모두 버리는 것과 같이 나쁜 습관을 끊어버릴 필요가 있다. 힘에 겨워도 DO-178B 전체를 잡아서 당신의 프로그램에 결합하는 것이다. 부분적으로 접근하지 마라. DO-178B는 단편적인 것이 아니어서 그런 방식으로는 작동하지 않는다. 사실상 DO-178B의 합이 전체가 된다. 그리고 당신이 DO-178B를 준수하기 위해서 부족한 프로세스들을 개선해 나가는 형태로 진행한다면 개발자들을 혼란스럽게 만들지 않을 것이다. 만약 당신이 거대한 갭을 단편적으로 채우려고 하면 문제는 당신이 사람들을 한 부분을 수행하도록 훈련시킨다는 것이고 그것은 그들이 할 수 있는 유일한 부분이 된다. 일 년 후에 당신은 DO-178B 라이프사이클 프로세스의 또 다른 일부를 더하게 되고 그것은 또 다른 부분이 된다. 이제 너무 많은 각각의 프로세스들 때문에 혼란이 생긴다.

역주) 저자가 여기에서 말하고자 하는 것은 조직의 혼선을 최소화하기 위해서 DO-178을 부분적으로 도입하는 것이 예상과는 달리 혼란을 해소할 수 없을 것이라는 이야기다. 우주에서의 빅뱅처럼, 한 번에 모든 것이 파괴되듯이, 기존의 방식을 고려하지 않고 DO-178이 조직 내에 빅뱅처럼 도입되어야 한다는 것이다. 어차피 어떤 형태로든 혼란은 피할 수 없다. 하지만 그 혼란을 거치고 나왔을 때 결과적으로 조직에 도움이 되었다는 것을 확인할 수 있는 방법으로 ‘빅뱅’ 방식을 제안하고 있는 것이다. 실제 현장에서의 경험을 돌이켜 본다면 역자 역시 이에 대해서 동의하는 바이다.

 

다섯 개의 서로 다른 소프트웨어 라이프사이클 계획 프로세스에 대해서 단지 하나의 프로세스를 작성하고 그것을 적절한 장소에 두어라. 사람들이 DO-178B를 통해서 전체 시스템을 개발하도록 훈련하라. 조직에 대한 갭분석을 수행한 후 다섯 개의 핵심 프로세스를 마무리하고 써드파티가 제공하는 툴 셋을 식별하라. 툴인증을 계획하고 FAA 인증 담당자와 조율하라. 모든 프로세스를 한번에 계획하는 것보다는 더 쉬운 방식이다. 기억하자. DO-178B는 고품질의 빌딩을 짓는 것과 비슷하다. 당신은 기초에 대한 계획없이 “14층”을 계획하지는 않을 것이다. 이는 DO-178B 구현을 계획하는 데에도 동일하게 적용된다.

역주) 이 부분은 광범위한 내용을 너무 간단하게 정리한 느낌이 든다. 이후 나오는 내용들이 이 내용들을 하나하나 풀어서 설명하고 있으므로 일단 가볍게 넘어가자.

 

이전에 사용된 적이 한 번도 없는 새로운 운영체제에 대해서는 어떨까? 그것에 대한 대단히 좋은점들에 대해서 들어왔을 것이고 영업사원은 그것이 인증 가능하다고 말할 지도 모른다. 그럼에도 불구하고 이력이 없는, 즉, 이전에 히스토리를 가지고 있지 않는 운영체제와 같은 기술은 피하는 것이 제일 좋다. 당신은 “연구 프로젝트”를 진행하고 싶지는 않을 것이다. Integrity-178B와 같은 DO-178B 인증을 받은 유명한 운영체제 중 하나를 선정하고 그런 다음 그것을 지원하는 다른 툴을 찾아라. 운영체제는 당신의 “브레인”이다. 따라서 그 브레인이 수행할 것이 무엇인지를 고려해서 선택하라.

 

디지털 신호처리기(DSP)는 어떨까? DSP는 빠르기 때문에 흔히 사용된다. 하지만 생산된 지 얼마 되지 않은 DSP는 사용하지 마라. 많은 COTS가 좋긴 하지만 사용된 히스토리가 있어야만 한다. 설계 정보가 없다면 그것은 연구 프로젝트로 끝날 것이다. DSP는 항공전자 분야에서는 새로운 제품이다. 그래서 DO-178B를 준수하는 툴 지원은 이 글을 쓰고 있는 현 시점까지도 제대로 이루어지지 않고 있다. 다음 몇 년 후에는 바뀌리라고 기대하지만 아직은 아니다.

역주) OS는 아주 복잡하고 중요한 소프트웨어이다. 항공기에서 윈도우의 블루스크린을 본다면 당신은 어떨 것 같은가? 아마도 그것을 보는 순간 ‘죽음’이 떠오르게 될 것이다. 그래서 저자는 이미 검증된 OS를 사용하라고 말하고 있다. DSP도 마찬가지다. 다만 검증된 DSP가 우리 주변에 거의 없다는 것이 문제이지만. 어쨌든 이처럼 항공산업은 모든 것에 대해서 상당히 보수적인 자세를 가지고 있다. 그래서 모든 것을 하나하나 검증하고, 검증되지 않은 것은 그것이 아무리 ‘슈퍼 울트라’ 최첨단 기술이라고 하더라도 절대 사용하지 않는다.

 

새로운 대형 항공기에 대해서 일하고 있을 때 한 거대 항공회사가 자신들이 만든 Ada 컴파일러를 사용하기로 결정했다. 동시에 자신들이 만든 운영체제를 사용하기로 결정했다. 개발 과정에서 다른 사람들이 어플리케이션 코드를 개발하는 동안 그 컴파일러는 계속 변경되었다. 하지만 왜 굳이 자신들이 개발한 컴파일러와 운영체제를 사용하려고 하는 걸까? 그것은 흥미로운 작업인 것은 분명하지만 항공전자 시스템은 제시간에 그리고 이윤이 남을 수 있도록 개발되어야 하는 것도 분명하다. 다른 누군가가 이미 개발한 컴파일러를 사용하라. RTOS와 툴을 직접 개발하는 것도 마찬가지다. 시장에서 검증된 툴만 사용해라. 툴은 당신 제품들 중에서 가장 높은 설계 보증 레벨이 되어야 한다. 그래서 제품이 레벨 A라면 툴도 레벨 A를 따라야 한다.

역주) 앞에서 이야기한 부분의 연장선이다. 다른 항공기에 사용된 이력이 있고 안전성이 이미 검증된 제품을 사용하라는 것이다. 그런데도 굳이 자신들의 기술력을 뽐내기 위해서(?) 자신들이 개발한 컴파일러나 OS를 사용한다면 그것은 그 자체로 당신에게는 이미 재앙이다. 장담하건데 그 프로젝트는 무조건, 100% 실패하게 되어 있다. 비록 자존심도 상하고(?) 많은 구매 비용이 들겠지만 다른 사람이 만든 검증된 컴파일러와 OS를 사용하는 것이 가장 현명한 일이다.

 

감항당국은 툴과 항공전자 컴포넌트에 대해서 이전에 사용된 적이 있다는 주장을 좀 더 유연하게 받아들이긴 하지만 툴회사에서 제공하는 데이터를 사용해서 그것을 증명해야 한다. 써드파티 툴로부터 자신의 데이터를 개발하는 비용과 시간은 상당하다. DO-178B 이력을 가지고 있고 판매자로부터 산출물들(문서들)을 받을 수 있는 게 확실한 툴과 제품 컴포넌트를 선택하라.

 

이것은 DO-254에서의 합성과 시뮬레이션 툴에 대해서도 마찬가지로 이들은 잘 받아들여지고 있다. 이들은 오랜 기간 사용되어 왔고 당신은 툴을 만든 회사로부터 품질과 형상에 대한 증거를 받을 수 있다. 당신은 이전의 공식 툴인증(판매자에 의해서 제공된)이 여전히 충분하다는 것을 보장하기 위해 재인증과 관련된 약간의 활동을 더 해야 할 지도 모른다. 하지만 그것은 툴을 재인증하는 방대한 작업은 아니다. 그것이 우리가 그러한 프로세스를 모두 거친 검증된 툴을 사용하라고 하는 이유이다.

역주) DO-178/DO-254에서 어려운 부분 중 하나는 툴에 대한 인증이다. 시장에서 지금 현재 잘 사용되고 있는 툴을 사용하는데 그 툴이 완벽하다는 증거를 대라고 하기 때문이다. 실제 이런 상황이 왔을 때 어떤 식으로 대응해야 하는지를 여기서 말하고 있다. 결국은 OS나 컴파일러에서 설명한 것처럼 이미 증명된 툴을 사용해야 한다. 그리고 툴을 만든 회사로부터 증빙을 구할 수 있어야 한다. 당연히 툴 구매비용 이외에 추가 비용이 소요되며 액수도 엄청나게 크다. 이래저래 DO-178/DO-254는 비싸고 어렵다. (참고 포스팅: 33. 툴인증(Tool Qualification) (Section 12.2))

 

사람들은 때때로 계획을 세우지만 그것을 따르지는 않는다. 우리는 이런 오류를 항상 보아왔다. 우선, 그 계획은 때로는 너무 상위레벨로 작성해서 실제로는 아무것도 정의하지 않거나 혹은 너무 하위레벨로 작성해서 모든 것이 정의된다. 그리고 프로젝트는 그 계획을 전혀 따르지 않는다. (우리는 이것을 “사실상 완벽한” – 사실상 완벽하고, 완벽하게 사용되지 않는 – 계획이라고 부른다. 이것이 인증에 실패하는 비결이다.) DER은 계획에 만족하는 준수결과를 찾아볼 것이다. 따라서 무언가를 작성하고 그것을 따르지 않는다면 그것은 쓸모 없는 짓이다. 사람들은 때때로 그들이 절대 수행하지 않을 아름다운 프로세스들로 완벽한 계획을 작성한다. 당신이 실제로 할 것을 작성하고 그것을 분명하게, 하지만 간결하게 만들며 제대로 수행해서 DER이 받아들이도록 만들어라.

역주) 다른 인증과 마찬가지로 DO-178도 여러가지 문서를 작성할 것을 요구한다. 그런데 그 계획에는 개발 과정 전체의 내용이 작성되어야 한다. 게다가 그 내용은 실제 개발 과정에서 그대로 진행되고 있는지 DER에 의해서 하나하나 감사를 받도록 하고 있다. 그냥 문서작업만 잘해서는 DO-178 인증을 받을 수 없다.

 

적절하지 않은 수준의 상세화와 요구사항. 소스코드는 하나의 요구사항에 대해서 15 ~ 25줄의 수준으로 작성되어야 한다. 그것은 경험에 근거한 좋은 법칙이며 일반적으로 말하자면 그 이상(더 상세한 요구사항)이 더 좋다. 다른 말로 하자면, 하나의 요구사항을 설계 혹은 코딩하는 사람이 가정을 할 여지가 없을 때까지 분해하는 것이다. DER 혹은 FAA가 하위레벨 요구사항을 요구할 때 당신의 추적성 매트릭스를 따라서 한 그룹의 하위레벨 요구사항을 가리키고 이게 나의 하위레벨 요구사항이라고 말하라. 당신이 코드를 작성할 수 있을 만큼 충분히 분해했다는 것, 그것이 그가 찾는 모든 것이다. 이제 요구사항이 잘 작성되고 그 회사가 DO-178B와 개발 지식을 많이 보유하고 있다면 그 하위레벨 요구사항은 상위레벨 요구사항으로 이어진다.

역주) DO-178은 기본적으로 요구사항이 가장 중요하다. 요구사항으로 시작해서 요구사항으로 끝난다고 해도 과언이 아니다. 당연히 모든 소스코드도 요구사항에서 나온다. 이 말은 개발자가 소스코드를 작성할 때 요구사항(하위레벨 요구사항)을 보고 그 요구사항에 대한 코드를 작성한다는 말이다. 그런데 요구사항 하나를 소스코드로 작성한다면 몇 줄이 적당할까? 100줄? 1000줄? 저자는 15 ~ 25줄을 제안하고 있다. 그러자면 요구사항을 작성할 때 개발자가 15 ~ 20줄로 소스코드를 작성할 수 있을 정도의 내용으로 작성해야 한다는 말이다. 이런 내용을 제대로 이해하기 위해서는 앞으로 나올 상위레벨 요구사항, 하위레벨 요구사항, 그리고 요구사항에 대한 추적성 등에 대해서 정확하게 이해하는 것부터 시작해야 한다.

 

많은 회사들이 중요한 아키텍처 정보 즉, 하위레벨 요구사항을 당신이 상위레벨 요구사항이라고 부르는 SRS 문서, 즉 Software Requirement Specification에서 보고 있다. 모든 세부사항이 그 안에 포함되어 있다. 이것은 잘못된 것이다. 그 다음 무슨 일이 일어날까? 당신은 하위레벨 요구사항이 필요하게 된다.

 

다음으로 엔지니어는 PDL, 즉 Program Description Language를 작성하고 그 코드를 그들의 하위레벨 요구사항이라고 부르게 된다. 그것은 하위레벨 요구사항이 되고 당신은 각각에 대한 시험을 작성해야 한다. 당신은 요구사항을 분해하는 프로세스를 거침으로써 가지게 되는 소프트웨어 라이프사이클의 장점을 잃어버린다. 그것은 아주 비효율적이고 실수하기 쉬운 방식이다. 따라서 조심하라. 하위레벨 요구사항은 충분히 하위단계여야 하지만 (20년 동안의 철학적 담론과 거래와 같이) 너무 내려가서는 안된다.

역주) 상위레벨 요구사항과 하위레벨 요구사항에 대해서 최대한 줄여서 정리해 보자면 상위레벨 요구사항은 고객이 말하는 요구사항이고 하위레벨 요구사항은 개발팀이 작성하는 설계문서라고 생각하자. 저자가 여기서 이야기하는 것은 하위레벨 요구사항을 너무 상세하게 작성하지 말라는 것이다. 만약 소스코드 라인 한 줄 당 요구사항이 하나씩 대응된다고 가정해보자. 그럼 수만, 수십만 혹은 수백만까지 나올 수 있는 소스코드 라인 수만큼의 요구사항이 작성된다는 것이고 또 그런 수준의 시험절차서, 시험결과서가 나온다는 말이 된다. 현실적으로 말이 안되는 상황이다. 이런 관점으로 상위레벨 요구사항과 하위레벨 요구사항을 작성하라고 말하고 있다. (참고 포스팅: 1. DO-178과 소프트웨어 요구사항(Software Requirements))

 

불충분하고 자동화되지 않은 추적성. 당신은 산출물로써 추적성 매트릭스가 필요한가? 그렇지 않다. DO-178B는 요구사항이 소스코드로 연결될 수 있어야 하고 코드에서 요구사항으로 연결되는 증거를 보여줄 수 있어야 한다고 말한다. 이것을 어떻게 하느냐는 당신에게 달려있다. 우리는 그것이 추적성 매트릭스와 같은 것이 없이도 가능한지에 대해서는 알지 못한다. 이를테면, 당신은 엑셀파일을 관리도구로 사용할 수도 있다. 하지만 5만라인에 가까운 소스코드와 5,000개에 가까운 요구사항으로는 당신은 그것을 시도할 수 없을 것이다. 일치하는지에 대한 감사를 하는데 상당히 오랜 시간이 걸릴 것이다. 또한 DO-178B 전이기준의 달성을 증명하는 훌륭한 방법이 추적성 매트릭스이다. 요구사항으로부터 코드로, 시험으로의 당신의 진행을 보여주기 위해 그것을 사용하라.

 

그런데 추적성 매트릭스를 가지고 있다는 것으로 당신이 확인과정을 거쳤다고 말할 수 있을까? 추적성 매트릭스는 요구사항으로부터 코드로의 추적성, 그리고 코드로부터 역으로 요구사항으로의 추적성을 확인하는 과정에서의 하나의 방법론적인 툴이다. 그 툴을 가지고 있다는 것만으로 보증과정을 담보하는 것이 아니다. 이것은 자동화되어야 한다. 한 두 사람만으로 모든 요구사항을 추적하기는 어렵다. 툴을 가져라. 특정 프로그램 용도로만 사용할 수도 있겠지만 회사 전체와 모든 사람들이 하나의 프로세스를 배우도록 하나의 툴을 사용할 것을 추천한다.

역주) 추적성 매트릭스 역시 DO-178에서 아주 중요한 부분이다. 항상 요구사항과 함께 하면서 요구사항과 연결된 모든 것(설계, 소스코드, 시험 등)을 보여준다. 그리고 만약 요구사항이든, 소스든, 시험이든, 추적성 매트릭스에서 연결된 부분이 확인이 안되는 경우에는 그 항목은 뭔가 잘못된 것이라고 봐야 한다. 물론 추적성 매트릭스가 잘못 만들어 졌을지도 모를 상황까지 포함해서. 이런 중요한 것을 엑셀파일로 만들어서 수작업으로 하나하나 업데이트 한다는 것은 상당히 답답하고 어려운 일이다. 절대 추천하는 방법이 아니다. 실제로 대부분 적절한 툴을 선정해서 사용하게 된다. (참고 포스팅: 3. DO-178과 추적성 매트릭스(Traceability Matrix))

 

부족한 리뷰와 툴로 인한 너무 많은 코드 반복. 어떤 사람들은 체크리스트를 만들지 않은 채 코드를 작성하고 바로 연구실로 들어가서는 디버깅을 시작한다. 그런 다음 그들은 말한다. “아, 이것은 잘 못 되었네요.” 그래서 그들은 수정된 코드를 작성하고 다시 연구실로 들어가기를 반복한다. 세상의 상용 소프트웨어 중 많은 수가 이런 식으로 만들어 진다. 당신으로서는 바로 바로 결과를 얻기 때문에 그것이 빠른 것처럼 보인다. 때때로 관리자들도 같은 이유로 그런 방식을 좋아한다. 코드가 동작하는 것을 빨리 볼 수 있는 것이다. 그러나 우리가 읽어본 모든 연구와 우리 자신의 모든 경험은 확실히 그런 일시적인 만족은 정의하기 어렵고 궁극적으로는 충분하지 않다는 것을 보여준다. 요구사항과 설계단계를 지나치는 것은 요구사항이 올바르고 누군가가 그것을 리뷰했다는 것을 보장해야 하기 때문에 오히려 시간을 낭비하게 된다. 제품에 대한 세계적인 수준의 반복은 일반적으로 두 번의 단계를 거치는 것이다. 어떤 관리자는 한 번으로 충분하기도 하지만 엔지니어링 세계에서는 일반적으로 최소 두 번의 단계가 있다. 만약 세 번 이상의 단계를 거친다면 당신은 무언가 잘 못 하고 있는 것이다. 반복 작업에 너무 많은 시간을 소모하는 것일지 모른다. 그런 반복을 줄일 방법을 찾아라. 훌륭한 소프트웨어 라이프사이클 개발 방법론을 따르는 것 만으로도 최선이다. DO-178B는 서로 다른 방법론을 허용하는 유연성을 가지고 있다. 사실상 현대의 어떤 방법론이든 충분할 것이다. 하나를 고르고 당신의 소프트웨어 개발 계획에 그것을 기술하고 그것을 따르라.

역주) 역자가 지금까지 경험한 소프트웨어 개발에서의 요구사항과 관련된 개발 방법은 대부분두 단계를 거치는 것이었다. 혹시 이 글을 보시는 분들 중에는 그 보다 더 많은 단계, 혹은 아예 한 번의 단계만 거치면서 소프트웨어를 개발한 분들이 있을지 모르겠다. 여기서 저자가 강조하는 부분은 한 번이든, 열 번이든 DO-178에서는 문제삼지 않는다는 것이다. 문제는 한 단계라도 더 거치게 되면 결국 그 만큼 더 해야 할 일이 생긴다는 것이고 그와 관련된 추적성 연결이라든지 시험과 같은 추가적인 활동들까지 고려한다면 너무 많은 시간과 비용을 추가로 소모하게 되는 문제점에 대해서 말하고 있다. 여러분들이 동의하실 지는 모르겠지만 DO-178은 가장 적정한 비용을 들여서 가장 안전한 소프트웨어를 개발하는 것을 목표로 하고 있다.

 

기능 시험 동안에 충분한 커버리지를 확보하지 못함. 당신도 알다시피 레벨 C와 그 이상에 대해서는 statement와 path에 대한 커버리지 시험을 수행해야 한다. 하지만 이것이 기능 요구사항 기반의 시험과 독립적으로 수행되어서는 안된다.

 

요구사항 기반의 (기능) 시험을 진행하는 동안에 구조적 커버리지 분석을 함으로써 60 ~ 70%의 커버리지를 얻을 것이다. “좋았어, 이제 나는 구조적 코드 커버리지 분석에 들어간다.”라고 말하기 전에 당신은 이미 거기에 있을 것이다. 한 가지 찜찜한 것은 “공식이냐 비공식이냐”에 관한 것이다. DO-178B에는 “비공식”과 같은 것은 없다. 모든 것은 공식적인 프로세스이다. 요구사항을 작성할 때 동시에 기능 시험 케이스에 대해서도 작성해야 한다. 마찬가지로 코드를 가지고 있고 해당하는 코드의 기능 요구사항을 시험할 때 구조적 커버리지 분석을 수행하고 동시에 그 구조적 커버리지를 얻어라.

 

자동화된 시험의 부재. 모든 것이 작성되고 시험 장비를 갖춘 후 다음 단계는 시험 장비에서 수행할 시험 케이스를 개발하는 것이다. 수동으로 시험하는 것은 쉽다. 그냥 장비로 가서 소프트웨어를 올리고 다양한 출력들을 읽으면서 일련의 버튼들을 누른다. 하지만 당신이 원하는 것은 자동화이다. 우리가 자동화를 하지 않는 유일한 이유는 대부분의 시험이 구축하기에 너무 많은 투자가 선행된다는 점이다. 자동화 프로세스를 위해서는 또 다른 개발자들이 필요하기 때문에 관리자들은 쉽게 받아들이지 않는다. 많은 프로그램에서 일어나는 일은 소프트웨어를 변경하고 나면 모든 시험을 계속해서 돌리는 것이다. 그것은 매우 리소스가 많이 드는 일이다. 시간이 지나면 당신은 자동화된 시험 환경을 개발하는데 투자함으로써 비용을 줄일 것이 거의 확실하다. 가능하다면 자동화에 먼저 투자하라. 왜냐하면 그 결과로 비용을 줄일 것이기 때문이다. 그 충고는 소프트웨어 세계에서 40년 이상을 회자되어 왔고 우리는 여전히 충분하게 따르지 않고 있다.

역주) DO-178에서는 모든 행위와 결과에 대해서 증거를 확보하고 언제든 보여줄 수 있어야 하는데 이를 원활하게 하기 위해서는 개발과 시험을 지원할 툴을 사용하는 것이 중요하다. 특히 시험에 툴을 사용한다면 그것을 자동화하는 것에 대해서 어느 시점부터는 심각하게 고민을 해야 한다. 그렇지 않으면 엄청나게 많은 일을 사람이 붙어서 일일이 손으로 밤새도록 해야 하는 상황이 올 수 있다. 저자가 여기서 말하고자 하는 요지는 결국 그런 판단을 관리자 차원에서 할 수 있어야 하고 그에 따른 비용을 투자해야 한다는 것이다.

 

DO-178B & DO-254: 원칙 피라미드

 

결정론(Determinism). 보통은 어떤 프로세스나 시험 시나리오를 들어갔다가 나오게 되면 당신은 항상 동일한 답을 얻는다. 만약 당신의 프로세스가 주관적이라면 어떤 문제가 있지 않을까 라는 우려가 있게 된다. 우리는 DO-178B 혹은 DO-254에서 “D”가 “determinism”을 의미한다고 말하고 싶지만 현실에서는 동일한 자극과 반응 하에서는 같은 응답을 원한다. 당신의 전체 소프트웨어 프로세스는 가정을 제거하는 데 초점이 맞추어 져야 한다. 그렇게 함으로써 “결정론”을 증가시킬 수 있다.

역주) ‘결정론’이라는 어색한 번역을 하고 있지만 결국은 명확해야 한다는 말이다. 모호함이 없이 백이면 백 모두 똑같아야 한다. 서로 다를 수 있는 여지가 있다면 DO-178은 원칙적으로 그런 상황을 받아들이지 않는다. 요구사항 정의, 소스코드 작성, 시험 케이스 선정, 시험 결과 작성 등 개발 과정 전체의 모든 것이 ‘결정론’의 대상이다.

 

문서화. 시험과 검증에 관한한 같은 질문을 하는 경우 언제나 같은 결과를 얻어야 한다. 시스템의 비결정적인 동작에 유의하라. 레벨 A, B 그리고 C에 대해서 그것은 필수항목이다. 레벨 D에 있어서는 많은 융통성이 있지만 레벨 A, B 그리고 C는 결정론적이어야 한다. 비록 우리가 데이터에 대해서 말하지만 문서화는 실질적으로 데이터 아이템을 강화한다.

역주) ‘문서화’라는 타이틀을 달고 실제 설명은 ‘결정론’에 대한 부분이 대부분이라는 게 함정인데 어쨌든 DO-178에서는 산출물로써의 데이터를 문서의 확장되는 개념으로 사용한다는 것을 이해하자.

 

유죄 추정의 원칙. 이것은 일반적인 법정에서의 법률과는 반대되는 것이다. 여기서는 당신이 무죄라는 것 그리고 요청받은 것만 했다는 것을 증명해야 한다.

역주) 요청받은 것만 했다는 것은 다른 말로 하면 불필요한 것을 하지 않았다는 말이다. 예를 들면 고객으로부터 요구사항이 주어졌다면 주어진 요구사항을 모두 다 구현했다는 것과 함께 요구되지 않은 불필요한 기능, 불필요한 코드가 단 한 줄도 포함되지 않았다는 것을 의미한다. 무심코 넘어갈 수 있는 문장이지만 상당히 중요한 의미를 담고 있다.

 

리뷰의 결과로써 생성된 리뷰결과물과 산출물. 상업용 임베디드 제품을 생산하는 약 20여개 회사를 방문하면서 그들 대부분이 DO-178B와 항공전자분야로 들어섬으로써 시장을 확대하기를 원한다는 것을 알았다. 이들 회사들은 “우리는 훌륭한 프로세스를 가지고 있습니다.”라고 말했다. 그리고 우리가 처음 물어본 것은 이것이었다. “코드 리뷰를 수행하나요?” 사람들은 많은 횟수의 리뷰를 수행한 이후에도 때때로 자신들의 오류를 보지 못하기 때문에 이것은 DO-178B 준수를 위해서는 상당히 중요하다. 우리는 언제나 그 데이터를 조사하는 사람에게 물어본다.

 

그러면 대부분의 회사는 “우리가 개발하는 코드는 제품으로 나가기 전에 100% 리뷰됩니다.”라고 말한다. 그러면 다음으로 나오는 말은 이것이다. “훌륭합니다! DO-178 준수를 위한 많은 시간과 노력을 줄이셨네요. 이제 그 중 하나의 리뷰를 보고 작업된 결과를 평가해 봅시다.” 우리가 보게 되는 반응은 무표정한 얼굴이거나 “Joe가 6개월전에 했습니다만 그는 현재 회사에 없습니다.” 따라서 “Joe가 코드리뷰를 수행했다”는 것 이상의 다른 산출물은 없다. 우리는 여전히 무엇을 리뷰했고 리뷰의 기준이 무엇이었으며 어떻게 진행되었고 문제점은 무엇인지 그것이 어떻게 적용되었는지 알지 못한다. 그것은 어중간한 논의였다. 그것이 우리가 그 프로세스를 따랐는지를 하나의 산출물인 체크리스트로 확인하는 이유이다.

 

DO-178을 준수하는 것을 증명. 이것은 테이블과 매트릭스를 만들고 “여기에 objective에 대한 결과가 있습니다.”라고 말함으로써 달성된다. 레벨 A에 대해서 66개의 objective가 있고 레벨 B에 대해서 63개의 objective가 있는데 이것은 레벨 A와 B 사이에 단지 세 개의 차이만 있다는 의미이다. 따라서 FAA가 “오, 당신은 현재 레벨 B이군요. 우리는 당신이 레벨 A에 있기를 원합니다.”라고 말할 때 놀랄 이유가 없다. 그것은 단지 하나의 objective가 더해지는 것이고 많은 분량의 부가적인 작업이 아니다. 당신은 할 수 있다. 하지만 그 objective들을 제시하고 그들을 어떻게 만족했는지 그리고 검증했는지를 기술하게 된다. 그것은 어려운 일이 아니다.

역주) 먼저 objective에 대해서 설명을 하고 가야 할 것 같다. 단어 자체만으로는 ‘목적, 목표’ 정도로 해석할 수 있는데 아무래도 뉘앙스 전달이 안되는 것 같아서 그냥 영문 그대로 사용했다. DO-178에서는 많은 objective를 제시하고 있으며 그것을 충실하게 따르도록 요구한다는 정도로 이해하고 넘어가자.   참고로 DO-178C로 버전업이 되면서 레벨 A에 대한 objective 개수가 71개로 늘었다. 레벨 B 역시 69개로 늘었다. 그리고 사실 레벨 A를 수행하기 위해서는 상당히 어렵고 시간이 많이 걸리는 작업을 추가로 진행해야 한다. 그런 점에서는 저자가 너무 쉽게 말하는 느낌이 들지만 맥락으로는 충분히 이해가 되는 부분이다. 어려운 점은 오히려 DO-178을 제대로 수행하고자 하는 의지를 자질 수 있느냐 이다. (참고 포스팅: 37. 부속물 - 소프트웨어 레벨에 따른 프로세스 목표와 출력 (ANNEX A))

 

추적성. DER이 감사에서 처음으로 하는 것은 일반적으로 추적성 문서를 보는 것이다. 이것은 데이터이고 당신이 현재 라이프사이클 내에서 어디인지를 결정하는 엑셀문서 혹은 DOORS 데이터베이스이다. 소프트웨어에 할당된 시스템의 모든 부분들이 구현되었는가? 모든 요구사항이 코드에 있다는 것을 확인할 수 있는 추적성이 없다면 그것을 증명할 수 없다. 추적성은 작업이 얼마나 잘 이루어졌는지를 보여주는 스코어카드이자 점수이다.

 

그것은 또한 모든 기능이 구현되었다는 것을 상위로부터 하위로 내려가면서 말해준다. 하위로부터 상위로 올라가게 되면 오직 요구된 것만 구현되었다는 것을 보여준다. 추적할 수 없는 코드는 존재해서는 안된다. 이것은 또한 역방향 추적성의 가치를 보여준다. 모든 블록의 코드는 요구사항을 가져야 하며 그렇지 않으면 그것이 왜 존재하며 왜 제거되지 않아야 하는지를 스스로에게 물어보아야 한다.

 

만약 시작 단계에서부터 프로그램과 프로세스를 구축한다면 사용할 수 있는 무료 도구들이 있다. DOORS는 일종의 Hummer와 같아서 거대하고 강력한 도구이다. 대형 통합 시스템과 거대한 볼륨의 제품에게는 아주 좋다. 하지만 식료품점에 갈 때마다 Hummer를 타고 갈 필요는 없다. 더 작은 프로젝트를 위한 다루기 쉬운 툴들이 있다. 하지만 거대한 프로그램 혹은 여러 개의 개발 팀, 그리고 여러 개의 제품 버전을 가지고 있다면 아마도 DOORS를 사용하기 원할지 모른다.

역주) Hummer는 아래와 같은 외형을 가진 미국의 유명한 자동차 브랜드 중 하나이다. 딱 보기에도 강력해 보인다. 저자가 이야기하고 싶은 말은 DOORS라는 도구가 이런 멋지고 강력한 자동차 같은 규모의 도구인데 매번 장보러 갈 때마다 이런 멋지고 강력한 차를 타고 가는 것은 좀 오버스럽지 않냐는 말이다. 물론 갈 수는 있지만 거친 광야를 달려야 할 포스의 자동차를 그저 쇼핑가는 데에만 사용한다면 굳이 비싼 돈을 주고 이런 강력한 자동차를 살 필요가 있을까?   자신이 개발하는 소프트웨어의 규모나 회사의 규모를 고려해서 적당한 수준의 툴을 적당한 비용을 투자해서 사용하라는 조언이다.

 

만약 프로그램이 작다면 프로세스를 자동화하고 낭비를 줄이는 더 간단한 툴들이 있다. 코드의 라인을 기준으로 크기를 정하자. 0 ~ 5,000라인은 작은 크기의 프로그램이다. 5,000 ~ 20,000라인은 중간 크기의 항공전자 소프트웨어 패키지이다. 20,000라인 이상은 큰 프로그램으로 간주된다.

 

다음으로, 시스템뿐만 아니라 소프트웨어의 복잡도를 살펴보자. 소프트웨어가 얼마나 복잡한가? 복잡한 알고리즘을 가지고 있는가? 많은 조건절을 가지고 있는가? McCabe 복잡도 숫자는 무엇인가? McCabe는 “if”절이 얼마나 많이 중첩되어 있는가와 같은 코드의 복잡도를 평가하는 방법이다. 다른 조건들에 선행하는 많은 조건들은 소프트웨어의 복잡도를 증가시키고 복잡한 소프트웨어는 리뷰하고 유지하기가 더 어렵다. 그래서 복잡도는 두 번째 측정방법이다.

역주) McCabe는 우리말로는 ‘메카비 복잡도 지수’라고 부르기도 하고 ‘순환복잡도’라고도 하는데 소프트웨어 개발자들에게는 그나마 친숙한 용어일 것이다. DO-178에서 이것을 엄격하게 규정하지는 않지만 결국 소스코드가 복잡해지면 그 만큼 인증을 받기가 어려워 지기 때문에 자연스럽게 복잡도가 낮아지도록 소스를 작성할 수 밖에 없게 된다.

 

작고 매우 오래된 ‘Mythical Man-Month(역주. 우리나라에서 ‘맨먼스 미신’으로 출간되기도 함)’라는 소프트웨어에 대해 이야기하는 책이 있다. 거기에서 “소프트웨어 팀의 이상적인 크기는 얼마인가?”라고 묻고 있다. 정답은 “한 명”이다. 왜냐하면 소프트웨어 에러의 주된 원인은 가정이기 때문이다. 많은 경우에 있어서 소프트웨어 및 시스템 개발자들이 소통하는데 익숙하지 않은 점은 여러 개발팀들이 가정에 근거해서 작업하게 만드는 경우가 많다.(당장 그들의 와이프나 구 여친에게 물어보면 바로 알 수 있다) 여기에서 다시 한번 문서와 추적성은 가정을 피하기 위한 핵심 항목임이 드러난다.

역주) 여기서 가정을 한다는 것은 정확한 내용을 확인하지 않고 개발자가 임의로 판단해서 일을 진행하는 것을 말한다. ‘이렇게 하는 게 맞겠지’라고 생각하고 그냥 진행해 버리는 것이다. 팀원들끼리 서로 소통이 잘 안되는 혹은 하지 않는 경우 쉽게 일어날 수 있는 상황이다. 그런데 팀원이 단지 한 명이라면 그럴 여지가 아예 없어지므로 그런 면에서는 차라리 한 명이 이상적인 팀의 크기가 아니냐는 말을 하고 있는 것이다. 그 만큼 소통의 중요성을 강조하는 이야기이다.

 

미래 DO-178C (2009년?) COTS 제품의 증가 DO-178B/DO-254의 범위 확대 (지상, 해상, 상업용, 산업계) 강화된 FAA의 엄격함 C++, 객체지향, 하드웨어 툴 Formal Modeling/Methods의 사용 스케쥴/비용에 대한 개선된 방안들 FAA로부터의 설명 산업계의 워킹 그룹 활동들

 

앞으로의 전망

우리는, 특히 DO-254 영역에서 많은 COTS 제품들이 승인을 획득하게 될 것으로 기대하고 있으며 그것이 요구되어 온 지난 몇 년 동안에 빠르게 성숙되어 왔다. FAA는 더 많은 툴셋, 카드, CPU 그리고 완전하게 통합된 버스들을 인지하고 있다. COTS 제품의 서비스 히스토리에 대한 채택이 증가하고 있고 자체 개발한 항공전자제품이 더 좋다는 생각은 점점 줄어들고 있다. COTS 제품을 가지고 시스템에 설치하는 것이 더 점점 더 늘어나고 있다. COTS를 더 많이 인증받을 수 있다면 더 많은 시간을 절감할 수 있다. 하지만 그 COTS 제품을 사용 이력과 DO-178B/DO-254 프로세스의 적용으로 인정받을 수 있어야 한다.

 

DO-178B의 범위 확대. DO-178B는 앞으로 지상, 해상, 상업용, 산업계 그리고 다른 분야로 좀 더 확대될 것이다. DO-178B가 더 많은 분야에서 받아들여지게 되면 그것은 항공우주와 그 외의 모든 분야에서 사실상 전세계의 표준이 될 수 있다. 육군, 해군 그리고 공군은 DO-178을 주시하고 있거나 혹은 이미 그것을 사용하고 있다. 저자는 군의 모든 조직내에서 DO-178B 프로세스를 가르치고 감독해 왔으며 각각의 성장은 흥미롭게 받아들여지고 있다. 지상 기반, 해상 그리고 자국 보안 시스템들 또한 이미 사용하고 있거나 가까운 시기에 DO-178B 그리고 DO-254의 사용을 고려하고 있다.

역주) 저자가 이 글을 쓴 시기가 DO-178C가 나오기 전인데 2018년을 기준으로 보면 6년이 지난 상황에서 위의 내용을 다시 보자면 아직은 갈 길이 멀다는 느낌이 든다. 예상보다는 적용 속도가 느린 게 아닌가 싶다.

 

강화된 FAA의 엄격함. 예산이 점점 타이트해지면서 “펜으로 장난치는 것”(기록을 위조하는 것)에 대한 우려가 있다. FAA는 이제 좀 더 조심스럽게 바라보고 있다. DER은 더 이상 단순히 “좋아 보입니다. 제가 서명을 하겠습니다.”라고 말할 수 없다. 오늘날 DER은 준수한다는 것을 입증하기 위해 무엇을 했는지를 보여주여야 한다. 현재 DER에 의해서 사용되는 프로세스는 SOI(Stage of Involvement) 감사이다. 거기에는 계획, 설계, 검증 그리고 인증의 네 가지 감사가 있다. 그리고 각각의 프로세스가 잘 진행되고 있는지를 확인하기 위한 훌륭한 체크리스트가 있다. QA를 담당하는 사람들 또한 감사를 위해서 그것들을 사용할 수 있다. DER은 이제 체크리스트를 작성하고 준수 사항에 대해서 확인한 것들과 함께 제시하도록 요청받게 된다. FAA 또한 이전에는 관계없는 것으로 여겨졌던 무인 항공 장비와 지상 시스템과 같은 영역으로 그들의 감독을 확장하고 있다. 이전에는 오로지 상용 항공전자 장비에 집중했던 FAA의 오클라호마 사무소에서 만들어진 새로운 FAA 태스크 포스를 포함해서 여러 새로운 FAA 팀들이 군 감독 이슈를 관여하고 있다.

역주) 미국의 감항당국인 FAA는 미국 전역의 민간항공기에 대한 인증을 담당하고 있다. 생각해 보자. 거대한 미국 전역을 날아다니는 항공기의 숫자가 얼마나 많겠는가? 거기에 항공기를 새로 만들기도 하고 수리를 하기도 하고 항공기 내부에 사용될 수 많은 제품들도 미국 전역에 걸쳐서 생산되고 있다. FAA가 이 모든 것들을 심사할 수 없기 때문에 자신들을 대신해서 심사해 줄 사람을 정하게 되었다. 그것이 DER이다. (위임제도라고 해서 그 외에도 몇 가지가 더 있다.) 따라서 원칙적으로 DER은 인증을 받으려고 하는 업체에게 FAA가 요구하는 것과 똑같은 수준을 요구하게 된다. 그리고 그것을 하나하나 확인하는 과정이 SOI(Stage of Involvement)이다. (참고 포스팅: 16. DO-178 소프트웨어 리뷰와 SOI(States of Involvement) – Order 8110.49)

 

C++, 객체지향, 하드웨어 툴. DO-178C가 이러한 이슈들에 대해서 언급하고 있다. 비록 우리는 C가 적합하다고 느끼지만 C++이 점차 많이 사용되고 있다. 세상은 C++로 이동하고 있고 오늘날 젊은 프로그래머들은 미래의 관리자가 될 것이다. 그들은 C++을 더 선호할 것이고 툴개발자들은 그것에 초점을 맞출 것이다. DO-178B의 다음 버전인 DO-178C가 C++에서 모두 통용되는 모델링과 객제지향기술에 대해서 기술하고 있고 그것을 명확하게 할 것이라는 것은 더 이상 비밀이 아니다. 그 같은 경우가 DO-254와 VHDL에도 해당한다. 인증에 대한 준수를 보장하기 위한 새로운 툴에 대한 영역이 빠르게 성장하고 있다. 항공전자 툴판매의 선두기업들이 FAA 워킹그룹에 참여하고 있고 그들의 제품이 인증을 준수한다는 것을 보장하기 위해 그들의 제품을 변경하고 있다. 거기에는 Green Hills, Vector Software, Polyspace, HighRely, TNI, MentorGraphics 그리고 Engenuity등이 포함된다.

역주) 2018년 현재 미국에서는 실제로 C++로 개발한 소프트웨어를 탑재한 항공기가 FAA의 승인을 받은 사례도 있다. 이미 객체지향언어로 개발된 소프트웨어의 DO-178 인증이 현실이 된 것이다. 여전히 우리나라에서는 갈 길이 먼 게 사실이지만 DO-178 인증에 대해서 관심이 있는 분들이라면 이런 트렌드가 있다는 사실을 기억하도록 하자.

 

스케쥴과 비용에 대한 개선된 방안들. 하나의 산업이 돈을 벌기를 원하는 경우 좀 더 유의해야 할 부분이 있다. 더 빠른 시장 진입, 더 나은 제품 스케쥴이 그것이다. DO-178B는 비용에 관해서 신경쓰지 않는다. 즉 DO-178B에서는 당신이 “무한대”를 포함해서 어떠한 액수로 예산을 초과하더라도 허용된다. 하지만 시장 적기 출시를 위한 시간은 감소하고 있고 항공전자 사업은 비용 경쟁이 치열하다.

역주) 위에서 저자는 DO-178이 비용에 대해서 신경쓰지 않는다고 했지만 사실은 그렇지 않다. DO-178 자체가 비용을 고려해서 나온 가이드이기 때문이다. 항공기의 특성상 무조건 안전이 우선이지만 다른 한편으로는 회사의 이익이 있어야 그런 안전한 항공기도 만들 수 있다는 현실을 인식한다면 저자의 설명은 결국 적절한 비용을 사용해서 안전한 항공기를 적기에 출시하는 것이 DO-178의 목표라는 점을 강조하는 것이라고 할 수 있다.

 

FAA로부터의 설명. FAA와, 방법론을 개발하는 워킹그룹으로부터의 새로운 설명이 언제나 존재한다. DO-248에는 DO-178B 내부의 프로세스에 대한 해석을 통해서 그 의미를 설명하는 훌륭한 보기들이 있다. 정기적인 문서들이 릴리즈되고 있고 항공전자 개발자들은 빠르게 발전하고 있는 시장에서 다채로운 변화들을 따라갈 수 있도록 정기적으로 “항공전자, DO-178B와 DO-254 백서”를 구글링해야 한다.

역주) 여기서 말하는 부분은 간단하게 정리하면 DO-178 인증에 대해서 FAA가 다양한 참고 자료들을 배포하고 있으므로 그것을 잘 챙겨보라는 이야기이다. 구체적으로 어떤 문서들이고 어디서 봐야 하는지는 이 책을 포함해서 다양한 자료들을 보면서 DO-178에 대한 내공을 쌓아가다 보면 점차 파악하게 될 것이다. 지금 단계가 처음인 분들은 그 정도로만 이해하고 앞으로 나올 내용들을 꾸준히 파악해서 DO-178에 대한 내공을 하나하나 쌓아 가시기를 기원한다. (본 블로그의 'DO-178 응용'에 몇 가지 사례가 포스팅되어 있음)