2. DO-178의 현실

 

컨설턴트로 일하면서 다음과 같은 이야기를 놀라울 정도로 자주 듣게 된다.

 

“우리가 현재 DO-178B 프로젝트를 진행하고 있는데요. 도움이 필요합니다.”

“좋습니다. DO-178B에 대해서는 얼마나 알고 계신가요?”

“아무것도 모릅니다.”

“현재 프로젝트가 어느 정도 진행되었나요?”

“최근에 제안서를 제출했습니다.”

“알겠습니다. 현재 제안서가 제출된 상태이고 DO-178B에 대해서는 전혀 모르시는 상태구요. 혹시 과제 비용이 고정되어 있나요, 아니면 비용이 발생할 때 마다 청구할 수 있는 건가요?”

“글쎄요, 고정되어 있는 것 같습니다만….”

 

이 친숙한 대화는 아주 현실적이다. 그래서 이 책을 쓰게 된 이유이기도 하다.

역주) 항공산업의 선진국이자 DO-178의 본고장인 미국에서의 대화 내용이다. 어떻게 보면 현재 우리나라의 현실과 별로 다를 바가 없어 보인다. 실제로 이 책의 내용은 이런 현실적인 부분이 곳곳에서 나오게 된다.

 

DO-178B 인증은 때때로 프로젝트 비용의 20 ~ 40%를 증가하게 만든다. 그러나 진행 과정에서의 함정들로 인해서 70에서 200%까지도 급속한 비용 증가를 가져올 수 있다. 다행히, 그 함정들은 DO-178이 현실에서 어떻게 수행되는 지를 살펴보는 것으로 회피할 수 있다. 단지 시간, 돈 그리고 생산성의 낭비를 피하는 것뿐만 아니라 소프트웨어 유지보수성, 재사용성 그리고 가성비를 유지할 수 있도록 해준다.

 

DO-178을 자세히 알아보기 위해 이제는 주요 상업용 항공기와 군용 항공기에 탑재되어 운영 중인 프로그램을 포함해서 지난 7년 동안 완료된 300개 이상의 인증으로부터 얻어진 경험을 그려볼 것이다.

 

DO-178에 대해서 아래와 같은 여러 이야기들이 있어 왔다. 이들을 살펴보고 미신처럼 전해지는 부분들을 명확하게 해보자.

 

“DO-178B는 요구사항이 아닌 “고려사항”을 포함하고 있다.”

“DO-178B는 위원회에 의해서 만들어졌고 그래서 그것은 모든 사람들을 위한 모든 것이라고 할 수 있다.”

“DO-178B는 거대한 시스템이든 아주 작은 시스템이든 유사하게 적용된다.”

“DO-178B는 가장 위험한 레벨 A 시스템에도 적용되고 가장 덜 위험한 레벨 D 시스템에도 적용된다.”

“DO-178B는 모호하고 너무 비싸다.”

 

DO-178이 요구사항이 아니라 “고려사항”을 포함하고 있다는 첫 번째 포인트를 고려해 보자. 사실 DO-178 어디에도 “요구사항”을 말하는 곳은 없다. “이것을 할지어다.” 라는 식으로 절대 말하지 않는다.

 

DO-178B는 위원회를 통해서 만들어 졌다. 위원회는 큰 시스템이든 작은 시스템이든 동일하게 적용하면서 모든 사람들에게 적용할 수 있는 공통의 요소들을 문서로 만들어 내야 한다. 만약 예를 들어 항공기 화장실에 있는 조명을 켜기 위한 간단한 드라이버를 구현하는데 50라인의 소스코드가 작성된다면 이들 소스코드는 1,200만 라인의 소스코드를 가진 항공정보시스템에 대해서 그런 것처럼 DO-178B를 따라야 한다.

 

다음으로 DO-178B가 모호하다는 불평이 있다. 그리고 그것은 사실이다! 개선되기는 했지만 여전히 이 문서는 모호하고 그렇게 분명한 편이 아니며 쉽게 따라갈 수가 없다. DO-178B는 겨우 100페이지(그것도 10페이지는 문서를 만든 사람들의 이름이 적혀있다) 분량의 문서이다. 하지만 그럼에도 이 문서를 요구사항으로 해석하는 문제로 소송을 한 경우가 한 번도 없다는 사실이 이 문서가 부족한 점이 없다는 것을 보여주는 증거가 되고 있다. 어떤 할머니가 뜨거운 커피를 무릎에 쏟는 일, 밤새도록 개가 짖는 소리 혹은 남의 집 뜰로 넘어온 나뭇가지 등으로 인해서 소송을 하고 관련된 헤드라인을 만들어 내는 사건들을 들어봤을 것이다. DO-178B에는 한 번도 이런 경우가 없었다. 이 문서대로 만들게 되면 그 자체로 소송에 대해서 걱정하지 않아도 되는 것이다. 그리고 그 이유는 아무것도 “요구”하지 않기 때문이다. 만약 거기에 아무런 요구사항이 없다면 그럼 왜 귀중한 시간을 낭비하면서 이 책을 읽는 것일까? 이유는 간단하다. DO-178B를 따르지 않고서는 인증을 받을 수 없기 때문이다.

 

만약 FAA(혹은 다른 감항당국)가 그것을 “요구사항”으로 만들었다면 다음과 같은 상황을 가정할 수 있다. 한 회사가 어떤 구동 시스템을 만들었는데 그것을 시계가 제로인 상황의 날씨에서도 비행기가 자동으로 착륙할 수 있도록 하는 소프트웨어로 인증을 받았다고 하자. 그런데 어느 날 그 비행기가 추락하고 말았다. 그러면 그 회사는 “우린 아무 잘못이 없어요. 우리는 “요구사항 기준”에 따라서 만들었을 뿐입니다.”라고 말할 것이다. 이 경우 누구의 잘못일까? 변호사는 그 “기준”이 잘못되었다고 주장할 것이다. 왜냐하면 이번 사고와 같은 위험한 이슈를 커버하지 않았고 그래서 사고가 났으니까. 이대로라면 그들의 말이 절대적으로 옳다. 하지만 그 문서는 단지 제안이자 가이드라인일 뿐이다. 그럼에도 인증을 받아야 한다.

역주) 미국은 소송이 일상화되어 있는 나라다. 담배와 관련된 소송은 익히 들어왔을 것이고 뜨거운 커피 한 잔을 가지고도 수천만 달러의 소송을 하는 경우가 있다. 저자의 말대로 DO-178 인증이 뭔가 부족하다거나 잘못된 부분이 있다면 지금까지 인증을 받은 수 천, 수 만개의 소프트웨어와 그걸 만든 회사들이 문제가 발생하는 경우 DO-178을 만든 곳 혹은 그걸 인증해준 FAA에 소송을 하지 않았겠느냐는 말이다. 하지만 지금까지 그런 소송이 단 한 번도 없었다는 사실이 간접적으로 DO-178 인증의 완전성을 보여주는 것이라는 말이다. (참고 포스팅: 6. DO-178 가이드라인)

 

DO-178B 문서의 목적   현실 세계에서 DO-178B를 이해하기 시간과 비용의 낭비를 피하기 DO-178B를 적용하면서도 생산성을 최대화 하기 300여개의 항공전자장비 인증을 통해서 얻게 된 경험을 활용하기 업계 최고의 기술, 도구 그리고 제품의 적용

 

하드웨어에 대한 DO-254

20년 이상의 기간동안 DO-178은 항공기에서 소프트웨어 개발을 가이드해왔다. 시스템이 발전하면서 하드웨어에 대한 필요성도 점차 증가되었다. 그 결과로 자매 문서와도 같은 DO-254가 복합전자하드웨어의 인증을 가이드하기 위해 나타났다. 두 문서는 동일한 그룹에 의해서 작성되었기 때문에 많은 면에서 유사함을 가지고 있다. DO-254는 PLD, FPGA, ATCL, BACL과 같은 하드웨어 장비 내의 소프트웨어적인 특성과 프로세스 중심의 임베디드 코드를 다루고 있다. (이 책 전반의 약어는 후반부의 부록에 정의되어 있다.)

역주) DO-178이 소프트웨어 인증, DO-254가 하드웨어 인증이라고 흔히들 이야기하지만 사실 DO-254에서 말하는 하드웨어는 일반적인 의미의 하드웨어와는 그 의미가 많이 다르다. 기본적으로 소프트웨어 특성을 가진 하드웨어의 일부로써 일명 ‘프로그래밍 할 수 있는 하드웨어’라고 할 수 있다. 나중에 다시 설명이 있겠지만 궁금하신 분은 ‘FPGA’를 구글링해서 확인해 보자.

 

하드웨어에 대한 인증의 필요성에 직면했을 때 FAA는 담당자들이 하드웨어 관련 인증을 해본 적이 없었기 때문에 관련된 엔지니어들을 확보하고 있지 못한 상태였다. 이 부족한 점을 채우기 위해 하드웨어 문서를 작성하기 위한 RTCA 소프트웨어 위원회가 소집되었고 그 결과로 나온 것이 DO-254였다. 그 문서는 주로 DO-178B에서 가져온 부분이 많았으며 그래서 두 문서는 80 ~ 85% 정도의 유사성을 가지고 있다. 하나의 시스템이 예를 들어 ASIC 혹은 FPGA와 같은 로직장비를 가지고 있으면 그 장비들은 DO-254의 영향을 받게 된다. 실리콘 혹은 소프트웨어를 통한 자체 로직을 포함하는 아이템은 반드시 동일한 엄격함으로 인증받아야 한다.

Hardware Accomplishment Summary   시스템 개요 인증 고려사항 하드웨어 라이프사이클 데이터 추가 고려사항 하드웨어 개요 하드웨어 설계 라이프사이클 설명 이전에 개발된 하드웨어 대체 방법   이 문서는 또한 승인받은 PHAC과의 차이점이 구분되어야 하고 하드웨어에 대한 식별정보를 포함해야 하며 변경 히스토리와 하드웨어의 상태, 마지막으로 커버리지에 대한 구문 준수를 포함해야 한다.

 

역주) 저자가 이 시점에서 갑자기 HAS를 언급한 이유가 뭔지 잘 모르겠다. 어쨌든 HAS에 대해서는 이 책의 후반부에 DO-254에 대한 설명이 나오는데 자세한 내용은 거기에서 확인할 수 있다. 참고로 처음 번역본에서는 DO-254가 포함되지 않았었다. 하지만 이번 재번역에서는 그때 제외했었던 DO-254에 대한 부분까지 모두 포함하였다.

 

시험

특별히 레벨 A, B 그리고 C에 대해서는 소프트웨어 개발보다는 시험에 더 많은 비용을 사용하게 될 것이다. 시험에는 네 가지 종류가 있다. 기능(Functional), 정상범위(Normal range), 강건성(Robustness), 그리고 구조적 커버리지(Structural coverage)가 그것이다. 여기서 잠깐, 현장에서 많이 사용되고 있는 운영체제를 생산하는 어떤 회사가 “부분적인” DO-178 준수를 주장한 흥미로운 사례를 살펴보자. 그 소프트웨어는 대략 3천만라인의 소스코드를 가지고 있었고 그 중 반 이상이 시험되었다. 하지만 그 소스코드 중 얼마만큼이 구조적으로 커버되었고 정확하다는 게 증명되었을까? 결과물을 보면 약 백만라인 이상 되는 것으로 보인다. 그러나 나머지 2천 9백만라인은? 명확하게 그 운영체제는 DO-178을 준수하고 있지 않다. 우리가 여기서 커버하는 시험의 종류는 군사용이나 의료분야 혹은 SEI에서 진행되는 것과는 다르다.

역주) 소프트웨어의 일부만 DO-178 인증 받는 것은 불가능하다. 하지만 막상 현실에서는 그걸 요구하는 경우를 종종 마주치게 된다. 불가능한 수많은 이유 중에 하나를 여기서 이야기하고 있다.

 

설계 데이터 및 컨트롤 플로우(Data and Control Flow)

우리는 설계에서의 데이터 및 컨트롤 플로우에 대해서도 논의할 것이다. 이들은 한 때 신형 VLJ(Very Light Jet)에서 사용되는 잘 알려진 운영시스템을 레벨 C로 인증하는 것에 대한 요구를 거절한 이유가 되기도 했던 항목들이다. 그 소프트웨어는 조종실의 전자 디스플레이를 구동하기 위한 용도였다. 우리는 제작자에게 “미안합니다, 당신들은 잘못된 길로 가고 있네요.”라고 말해야 했다. 중복성을 위해서 두 개의 디스플레이를 가지긴 했지만 동일한 소프트웨어를 가졌던 시스템에 대해서 지적했다. 만약에 하나의 디스플레이가 비정상적으로 동작하지 않게 되면 다른 디스플레이에서는 어떤 일이 발생할까? 동일한 문제가 발생한다. 그들은 우리의 이런 충고를 받아들이지 않았고 우리는 더 이상의 진행을 하지 않았다. 하지만 그 이듬해 FAA가 전체 항공전자 조종석 구조를 재작업하도록 만듦으로써 우리의 판단이 증명되었다. 그 항공기는 3,000만불 이상의 개발 비용 증가와 함께 2년이 지연되었다. 여전히 훌륭하고 새로운 비행기이지만 지름길을 선택하지 않고 전문가의 충고를 받아들였다면 그런 시행착오를 피할 수 있었을 것이다. DO-178B는 “결정론”이자 상식에 관한 것으로 둘 다 노력이 필요한 부분이다.

역주) DO-178에서 요구하는 데이터 플로우(Data Flow), 컨트롤 플로우(Control Flow)가 구체적으로 무엇인지는 이를 추출하는 도구에 따라서 다소 차이가 있다. 여의치 않으면 결과를 얻기 위해서 직접 수동으로 작업해야 할 수도 있다. 단순화하자면 데이터의 흐름과 함수 호출을 중심으로 한 다이어그램이라고 말할 수 있다. 이에 대해서는 나중에 자세히 설명하게 된다. (참고 포스팅: 7. DO-178과 커버리지 분석 – Data / Control Coupling (1))

 

툴

툴인증(Tool qualification) 은 DO-178B의 핵심 특성이다. DO-178B는 하나의 체인과 같아서 항공전자 시스템은 아무리 튼튼하게 만들었다고 하더라도 그 중에 가장 약한 연결고리가 존재한다면 결국은 그저 그 약한 연결고리만큼만 강할 뿐이다. 만약 체인이 끊어진다면 체인의 어디가 끊어지게 될까? 가장 약한 연결부분이다. 하지만 DO-178B(그리고 DO-254)는 각각의 체인에서 다섯 개의 서로 다른 내구성을 허용하는, 세상에서 흔치 않는 표준 중 하나이다. 이 다섯 가지 위험 레벨은 이 책 전반에 걸쳐서 설명될 것이다. 분명한 것은, 당신은 모든 항공전자시스템을 가장 강력한 표준인 레벨 A를 따르게 만들 수 있고 그래서 가장 강력한 제품이 될 수 있다. 하지만 그것은 항공기, 유지보수, 업그레이드 그리고 여분에 대한 비용이 엄청나게 증가하게 만들 것이다. 이것이 항공산업에 있어서 가장 관심을 가지는 부분일까? 항공사가 항공기를 만들 여유가 없고 승객들이 항공기 티켓을 살 수가 없다면 어찌될까? 그래서 DO-178B는 전체 체인(항공기)의 안전에 대해서 연결(시스템)의 비중에 따라서 서로 다른 위험레벨을 가진다.

역주) 솔직히 저자가 ‘툴’이라는 타이틀을 달고서 왜 여기에다가 위험레벨을 설명하고 있는지 잘 모르겠다. 이번 재번역에서 의역을 많이 넣기는 했지만 이런 식의 종잡을 수 없는 저자의 설명까지는 손을 대지 않을 예정이어서 일단 원문의 내용을 그대로 따르기로 했다. 툴과 관계없이 중요한 내용이므로 내용 자체로 이해하고 넘어가자.

 

툴에 관해서 인증 전문가의 한 사람으로서 누군가가 말한 게 있다. “툴을 가진 바보는 단지 좀 더 강력한 바보일 뿐이다.” 사람들이 주로 하게 되는 주된 실수들 중에 불필요하게 툴인증을 수행하는 경우가 있다. 예를 들면 컴파일러는 인증을 받을 필요가 없다. 하지만 소스 코드를 시험하고 수행경로를 분석하기 위한 구조적 커버리지툴은 어떨까? 별것 없어 보이지만 만약 당신이 소스코드의 모든 조건절을 일일이 수작업으로 재확인하는 엄청난 리소스가 필요한 작업을 하지 않는다면 그것은 인증이 필요하다. 소수의 툴에 대해서는 인증이 필요하지만 그 외 대부분의 툴에 대해서는 인증이 필요하지 않다. 그것을 어떻게 빨리 결정할 지를 이 책에서 보여줄 것이다.

 

두 가지 종류의 툴이 있다. 개발툴과 검증툴이다. 그 중에 어려운 것은 개발툴이다. 검증툴은 인증하기가 쉽고 만약 이전에 인증을 받은 적이 있다면 단지 몇 주의 시간만 투자하면 인증을 다시 받을 수 있다.

역주) DO-178 최신 버전에서 툴인증의 개념이 일부 변경되었다. 그래서 지금의 설명과 다소 차이가 있긴 하지만 기본적인 개념으로는 이 정도만 이해하고 넘어가도 충분하다. (참고 포스팅: 33. 툴인증(Tool Qualification) (Section 12.2))

 

“유죄 추정의 원칙” (Guilty until proven innocent)

미국과 유럽의 법에는 무죄 추정의 원칙이 있다. DO-178B에서는 그 반대이다. 무죄를 증명하기 전까지 당신은 유죄이다! 문서의 의도를 따르고 양호한 기록을 유지하며 조심스럽게 계획을 따름으로써 당신은 프로젝트의 마지막 단계에서 인증을 받게 될 것이다. 이런 이유로 DO-178을 “책으로” 배우는 것은 불가능하다. 왜냐하면 책 내용이 너무 모호하기 때문에. 오랜 시간을 거치면서 우리는 소프트웨어 엔지니어들을 바로 FAA가 생각하는 것처럼 가르치는 것이 가장 좋은 방법이라는 것을 배웠다.

역주) FAA는 미국 민간항공 분야의 감항당국이다. FAA처럼 ‘생각’한다는 것은 감항당국 즉, FAA의 ‘의도를 이해한다’는 것을 말한다. 정해진 규정이라고 하지 않고 ‘생각’, ‘의도’라고 말하는 부분을 유의하자. DO-178이 어려운 것은 이런 식의 ‘철학적’인 이해가 필요해서라고 할 수 있다.

 

“요구사항”이 아닌 “고려사항”

DO-178 문서의 공식 타이틀을 자세히 살펴보자.

RTCA DO-178B Software Considerations In Airborne Systems and Equipment Certification

 

“Requirement”라는 단어가 없다는 것에 주목하자. 대신 “Considerations”라는 단어를 사용함으로써 이 문서는 모호하다고 할 정도로 느슨해진다. 그럼에도 이 문서는 항공산업 업체들의 목표에 의해서 수행되어 왔기 때문에 지금도 제 역할을 잘하고 있다. 이 문서를 만드는데 참여한 사람들 중 75%가 항공우주분야 종사자들이어서 이 문서는 다른 표준들보다 더 잘 동작한다. 스케쥴, 비용 그리고 리스크를 고려하는 업계의 입장에서는 완벽하지는 않더라도 현실적이라고 할 수 있다.

 

다른 표준들을 보면 서로 얽혀있고 어려워서 사람들이 잘 따르지 않는 것을 볼 수 있다. 그래서 합리적인 룰을 만드는 것이 최초의 생각이었고 항공업계가 DO-178B를 작성하는 것을 도와주었기 때문에 합리적으로 작성될 수 있었다.

 

DO-178 문서에는 많은 타협이 담겨 있는데 바로 그 점 때문에 레시피북이 아니라 가이드라인이라고 하는 것이다. DO-178B 어디에도 “어떻게 하는지”를 말하는 것이 아니라 무엇이 수행되어야 하는지 그 “필요성”을 말한다. AMC라고 알려진 Alternative Means of Compliance(역주, ‘인증 준수 대체 방법’ 정도로 해석하자.)라는 뭔가 다른 방법이 있을 수도 있다. 이론적으로든 실전적으로든 그것이 충분하거나 더 좋다는 것을 보여줄 수 있다면 그 방법을 사용할 수 있다.

 

그런 과정으로 들어서기 전에 당신은 아마도 전문가, 즉 DER과 논의하기를 원할지 모른다. 예를 들면 캐나다의 한 회사는 로딩을 위한 용도로 8개의 트랜스퓨터를 사용하면서 대체 방법을 통해서 레벨 B로 인증을 받았다. 따라서 그것은 가능한 것이다. DO-178B를 엄격한 규정이 아니라 협의가 가능한 것이라고 생각하자. 실제로 그것이 황금률이다.

역주) DO-178이 타협이 가능하다는 말이 어떻게 들릴 지 모르겠다. 그것이 가능하다고 하더라도 실제로 타협을 할 정도가 되려면 그 만큼 제대로 알고 있어야 응용이 가능한 것이다. 무턱대고 타협하고 싶다고 타협할 수 있는 것이 아니고 그 나름의 근거가 반드시 있어야 한다. 이렇게 보면 명확하게 하나로 규정하지 않고 타협할 수 있다는 모호함이 오히려 준비하는 입장에서는 더 어려운 일일 수도 있다. (참고 포스팅: 6. DO-178 가이드라인)