6. 비용 vs 이득

 

DO-178B가 정말로 비쌀까? 그것이 비용을 증가시킬까? 그것이 안전성과 신뢰성을 높일 수 있을까? 이득에 대응하는 실제 비용은 무엇일까? 이러한 중요한 질문들은 명확하고 솔직하게 답변될 가치가 있다.

 

우리는 DO-178B와 DO-254가 비용의 20 ~ 40% 이상을 추가하면 안 된다고 말했다. 몇 년간의 경험에 따르면 산업계에서는 약 75 ~ 150%의 비용 증가하는 것을 보여준다. 200%에 이르는 경우도 본 적이 있다. 왜 그런 차이가 발생하는 것일까?

 

몇 가지 이유가 있다. 아마도 개발 과정이 잘 정립되어 있지 않아서 혹은 반복 작업에 너무 많은 시간을 소비해서 혹은 같이 프로젝트를 진행하는 DER이 “이것을 반드시 해야 합니다”라고 해서 그럴지 모른다. 몇몇 DER은 “오로지 내가 말하는 대로만 하세요.”라고 말했을지도 모르겠다. 그대로 따르지 않으면 결국은 상당히 많은 추가 작업을 하게 된다.

역주) DO-178 인증을 받으려면 비용이 든다. 다른 것들은 다 무시한다고 해도 최소한 DER을 고용(?)해야 하므로 그 비용만큼은 분명히 필요하다. 생각해 보자. 미국의 DER이라는 항공분야 최고 전문가가 우리나라에 와서 한 번에 3 ~ 4일씩 약 4회에 걸쳐서 와야 한다면 그 사람에게 도대체 얼마를 줘야 할까? 짐작만으로도 절대 적은 액수가 아닐 것이다. 그 와중에 그동안에는 진행하지 않았던 시험을 수행해야 할 수도 있다. 마침 자체적으로 그걸 할 수 없는 상황이라면? 다른 업체에 의뢰를 할 수 밖에 없을 텐데 항공업계에서 사용되는 툴은 보통 억 단위의 비용을 요구하는 경우가 다반사이다. 단순히 두 가지의 변수만 가정해도 처음에 고려하지 않았던 많은 비용이 추가되는데 여기에 또 다른 변수들이 더해진다면 추가되는 비용은 그야말로 상상을 초월하게 된다.

 

어떤 DER들은 요구사항이 없음에도 불구하고 여전히 단위시험이 필요하다고 믿고 있다. 그것은 DO-178A와 DO-178B의 차이점이다. 단위시험은 버전이 갱신되면서 중요도가 낮아졌다. 어떤 사람들은 여전히 자체 프로세스 정의에 단위시험을 정의하고 있고 그것은 확실히 비용을 높이게 된다. 프로세스 내에 단위시험을 정의한 경우에만 그것을 수행할 필요가 있다. 하지만 DO-178B는 그것을 요구하지 않는다. 기억하라. DO-178B는 “시스템”에 관한 것이고 검증은 해당 시스템 상에서 혹은 적어도 과거에 운영되었던 통합된 소프트웨어 상에서 수행되는 것이 최선이다. 단위시험은 매우 주관적인데, DO-178B는 주관성이 아닌 결정론을 강조한다.

역주) DO-178은 의외로 단위시험을 강조하지 않는다. 완벽한 소프트웨어, 안전한 소프트웨어를 위해서 함수단위로 꼼꼼하게 시험하는 단위시험이 반드시 필요할 것 같은데 아예 시험할 필요가 없다고 하는 것이다. 이 부분을 이해하기 위해서는 DO-178의 철학을 이해해야 한다. DO-178의 철학에서는 애매한 것을 용납하지 않는다. 모든 것이 명확해야 하고 근거가 있어야 하며 제 3자가 보더라도 충분히 납득할 수 있어야 한다. 여기에 비교해 본다면 단위시험은 사실 시험하는 사람이 누구냐에 따라서 같은 함수를 시험한다고 하더라도 여러 가지 형태로 수행될 수 있다. 함수 자체로만 생각을 해서 함수 자체의 기준으로 모든 경우의 수를 다 시험할 수도 있고 혹은 외부의 입출력 조건을 고려하면서 일부만 시험할 수도 있다. 어떤 식으로 하든 시험을 통과하게 되면 단위시험은 성공한 것으로 판정 받게 된다. DO-178의 철학에서는 허용할 수 없는 모호함이 존재하는 것이다. 단위시험 자체에 대해서는 다른 단락에서 상세하게 설명한다.

 

일반적으로 유닛은 응집력을 가진 조각과 같은 하나의 진입/하나의 진출을 가진 2167 유형의 정의이다. 어떤 사람들은 “아니요. 우리는 큰 컴포넌트, 클래스, 더 큰 클래스, 클래스들의 조합, 프로그램을 유닛이라고 부를 겁니다.”라고 말한다. 그렇다면 그것은 당신이 가지고 있는 표준에 정의되어야 한다. 만약 단위시험이 수행된다면 유닛을 정의해야 한다. 언제나 유닛을 함수 및 소프트웨어 요구사항과 연결하라.

역주) 유닛을 어떻게 정의할 지에 대해서 말하고 있다. 저자가 말한 2167 유형의 정의는 DOD-STD-2167에 있는 아래의 정의를 말하는 것으로 보인다.

 

C-17 항공기의 새로운 기상레이더에 대해서 작업한 적이 있다. 2년동안 구조적 커버리지 분석만 진행했었다. 우리가 했던 것들은 올바른 동작을 하는지 확인하는 검증 작업이 전부였다. 단위시험의 한 부분만을 한 것이 아니었다. 우리가 모든 작업을 완료했을 때 얼마나 많은 코드가 있었는지 당신이 보았어야 한다. 14개의 DSP가 연결되었고 2개의 powerPC가 함께 동작했다. 방대한 양의 코드였고 수많은 유닛이 정의되어 있었다. 우리는 단위시험에 다시 2년을 소비해야 했고 그것은 수동으로 철저하게 진행했기 때문에 비용이 많이 들었다. 이런 상황조차도 만약 당신의 프로세스에 정의되어 있다면 당신은 그것을 따라야 한다.

위험 레벨 – 비용

위험 레벨 당 DO-178B의 비용 차이

 

비용 vs. 위험도

레벨 E(가장 덜 위험한)부터 차례대로 서로 다른 위험 레벨에 따른 비용 충격을 생각해 보자. 레벨이 높아짐에 따라 문서, 설계, 리뷰, 구현 그리고 검증과 관련된 엄격함의 정도가 더 높아진다. 위의 그림과 아래의 테이블은 각 위험 레벨과 관련된 실질적인 비용차이를 보여준다.

 

시간 축을 따라서 이어지는 일정과 레벨 A, B 그리고 C, D의 비용을 보면 큰 변화가 일어나는 곳은 레벨 C와 D 사이이다. 위험도가 높아짐에 따라 그에 해당하는 비용은 실제로는 줄어든다. A와 B 사이에는 거의 변화가 없다. A와 B 사이의 차이를 내는 유일한 큰 항목은 MCDC이다.

레벨 E 비용	레벨 D 비용	레벨 C 비용	레벨 B 비용	레벨 A 비용
기준선	E + 5%	D + 30%	C + 15%	B + 5%

 

역주) 위험 레벨과 비용과의 상관관계는 사실 실제 진행되는 현장에 따라서 변수가 많기 때문에 이렇게 일괄적으로 이야기하는 것이 이론적인 이야기로만 들릴 수 있다. 그래도 결국은 레벨이 높아지면 질수록 실제 수행해야 할 활동들(최소한 시험이든 리뷰든 하나라도 더 늘어날 것이므로)이 많아지게 되고 그로 인해서 비용이 높아지는 결과가 나오게 된다. 아마 위의 그래프와 똑같지는 않더라도 비슷한 추세를 보이게 될 것이다.

 

다음으로 DO-178B가 비싸다는 미신이다. 레벨 D로 인증된 소프트웨어는 완전한 계획, 구현, 리뷰, 그리고 기본적인 시험을 가진다. 형상관리, 품질보증 그리고 DER 교섭이 레벨 D에 적용된다. 하지만 비용은 비 인증 소프트웨어 프로세스보다 그렇게 많지 않다. 위의 그래프에서도 다른 레벨에 비해서 상대적으로 낮은 비용을 가리킨다. 이것은 레벨 D가 일반적인, “좋은” 소프트웨어 엔지니어링 원칙으로 대부분 구성되어 있기 때문이다.

역주) 저자가 왜 유독 레벨 D를 들어서 DO-178이 비싸지 않다고 설명을 하는 건지 좀 이해가 안된다. 실제로 레벨이 더 높은 경우라면 비용이 더 많이 들 것이기 때문에(사실 다음 절에서 그런 부분이 설명되고 있다) 이걸 가지고 DO-178B가 비싸다는 미신이 잘못되었다고 말하는 것은 뭔가 억지스런(?) 느낌이 아닌가 싶다. 굳이 이해하자면 DO-178 인증을 받는 것 자체가 목표라면 가장 낮은 레벨인 레벨 D 수준에서 비싼 비용을 들이지 않고도 가능하다는 것을 말하는 것이 아닌가 싶기도 하다.

 

또 다른 미신은 가장 중요한 비용 상승은 레벨 B에서 레벨 A로 갈 때 일어난다는 것이다. 이것은 사실이 아니다. DO-178B의 비용 충격은 레벨 D와 레벨 C 사이에서 가장 급격하게 나타난다. 왜 그럴까? 레벨 C는 레벨 D가 하지 않는 다음과 같은 것들이 필요하기 때문이다. 결과적으로 레벨 C에서는 30% 이상의 비용과 일정이 더 필요하게 된다.

 

l  하위레벨 소프트웨어 요구사항 시험

l  모든 소스코드의 Statements에 대해서 100% 커버리지를 보장

l  리뷰에 대한 상당한 엄격함

l  많은 경우에 있어서 더 엄격한 형상관리

 

레벨 B는 추가적인 구조적 커버리지(Decision-condition, 즉 소스코드에서의 모든 branch), 리뷰에 있어서 추가적인 독립성 그리고 좀 더 타이트한 형상관리가 필요하다.

 

언뜻 보면 레벨 B가 레벨 C에 비해서, 예를 들면 50 ~ 70% 눈에 띄게 더 비싸 보인다. 이론적으로는 말이 되는 것처럼 보인다. 하지만 삶에 있어서 상식은 이론을 이기는 경우가 많다. 레벨 B(그리고 C)에는 상세한 하위레벨 요구사항이 있고 그것들은 완전하게 시험되어야 한다. 그런 요구사항 기반의 시험 과정에서 소스코드 내의 branch 중 상당 부분(70 ~ 90%)이 미리 수행되고 만약 시험 과정을 캡쳐하는 툴과 커버리지툴이 적절하게 사용된다면 추가적인 구조적 커버리지 시험이 필요 없게 된다! 그래서 레벨 C 대비 레벨 B와 관련해서 상당한 비용 증가로 보이는 것은 이미 요구사항 기반의 시험에 의해서 완화된다. 그리고 추가된 구조적 커버리지 요구사항은 VectorCAST와 같은 이미 인증을 받은 툴을 사용해서 상당부분 자동화가 되며 그것은 효율성을 상당히 개선한다. 품질을 갖춘 소프트웨어 엔지니어링 조직은 이미 독립된 리뷰와 엄격한 형상관리를 포함하는 반 자동화되고 합리화된 프로세스를 결합하고 있다. 그래서 레벨 B에 대한 이러한 특징의 추가되는 비용은 감소된다. 이 책을 읽는 독자는 이러한 비용 감소 기술을 활용하기 위해 DO-178B 교육과 함께 DO-178B 프로세스 개선을 진행할 수 있도록 좋은 충고를 받게 된다.

역주) 복잡하게 설명하고 있는데 핵심은 요구사항 기반 시험을 제대로만 진행하면 커버리지 시험까지도 한꺼번에 결과를 얻을 수 있다는 것이다. 물론 툴은 사용해야 되고 시험을 잘 준비하고 진행해야 하는 전제는 있지만 실제로 제대로만 진행된다면 비용과 시간을 상당부분 줄여줄 수 있는 아주 유용한 부분이다. 사실 이 부분만 제대로 된다고 해도 이미 그 조직은 DO-178을 제대로 진행할 수 있는 충분한 자격과 능력을 갖추고 있다고 할 수 있다.

 

레벨 A는 가장 위험한 소프트웨어 레벨이고 가장 비싸다. 하지만 레벨 A에 대해서 또 다른 미신이 존재하는데 바로 “레벨 A는 달성하기 매우 어렵고 레벨 B보다 최소한 30 ~ 50% 더 비용이 든다’”라는 것이다. 그 가정은 틀렸다. 레벨 A가 한층 더 엄격한 구조적 커버리지 요구사항(MCDC 시험), 강건성 및 관련성에 대한 요구사항, 조금 더 엄격한 리뷰를 강요하는 것은 사실이다. 그리고 레벨 B 이상에서의 가장 중요한 비용 요인은 MCDC 시험 요구사항이다. 그러나 최신의 구조적 커버리지 툴의 적절한 적용, 인력에 대한 훈련 그리고 철저한 요구사항 기반의 시험에 레벨 A에 대한 추가된 비용의 상당부분이 포함될 수 있다.

역주) 저자의 말처럼 가정이 틀렸다고 말하기에는 현실적으로 레벨 A에서 요구하는 시험 수준이 레벨 B에 비해서 너무 높다. 원칙적으로만 보자면 실제로 레벨 A에 소요되는 비용이 레벨 B에 비해서 30 ~ 50%, 아니 그 보다 더 많은 비용이 들 수도 있다. 여기서 저자가 설명하는 부분은 MCDC에 국한해서 보는 것이 좋을 것 같다.

 

DO-178B는 무료가 아니지만 제대로 구현되었을 때는 비용 대비 효율을 높을 수 있다. 그렇다면 그렇게 많은 업체들이 DO-178B를 채택하는 이유는 무엇일까? 다음의 내용들이 실질적인 경험을 기반으로 DO-178B의 가치에 대해서 우리가 내린 결론이다.

 

상당히 빠른 시점에 선행해서 요구사항을 명확하게 하는 것. DO-178B는 완전하고 상세한 소프트웨어 요구사항을 강요한다. 그것을 만족하기 위해서는 요구사항의 작성을 미루어서는 안되며 오히려 선행해서 나가야 한다. 가정은 철저하게 최소화된다. 요구사항의 일관성과 시험가능성이 보장된다. 검증된 요구사항 추적성을 사용해서 잘못된 요구사항과 누락된 요구사항으로 인한 반복과 재작업이 상당부분 감소된다.

 

더 적은 코딩 작업의 반복. 코딩 작업의 반복이나 코드 전체를 뒤집는 것은 소프트웨어 엔지니어링의 골치거리이다. 많은 경우에 있어서 새로운 제품을 만드는 데에는 10, 20, 심지어는 30개의 버전으로 갱신된 소스 코드가 존재한다. 코드는 처음 작성되는 단계에서 상당 부분이 정확해야 하고 수정을 위해서 많은 업데이트가 필요하지 않아야 되기 때문에 이것은 말도 안된다. 정적 코드 분석기의 사용은 코드 반복을 줄이는 데 조금 더 도움이 될 것이다.

 

단위시험 동안의 더 적은 버그. DO-178B는 철저하게 시험 가능한 요구사항과 코드 리뷰를 강요하기 때문에 단위시험동안 훨씬 더 적은 버그가 발견된다. 그리고 독립적인 코드리뷰는 그것을 좀 더 강화한다.

 

소프트웨어 내부의 더 강력한 일관성. 소프트웨어는 체인과 같다. 가장 약한 연결 부위만큼만 강하다. 99%가 정확하고 1%가 부정확하다면 그 소프트웨어는 안전하지 않다는 의미가 된다. 가장 약한 소프트웨어 모듈 혹은 소프트웨어 엔지니어는 소프트웨어 안전의 임계 경로에 있는 것이다. 모든 소프트웨어는 위험 레벨에 따라서 일관성이 있어야 하며 DO-178B는 이것을 강요한다. DO-178B와 DO-254는 “결정론”에 관한 것이다.

역주) ‘결정론’이라는 어려운 단어를 써서 그렇지 결국 여기서 말하는 것은 요구사항이 모호하지 않고 명확해야 한다는 것이다. 100명이 같은 요구사항을 보고 각자 해석하더라도 누구에게나 동일한 해석이 되어야 한다. 이러한 면에서의 ‘일관성’, ‘결정론’을 말하고 있다.

 

통합 단계에서의 더 적은 문제점. 통합은 설계 변경이 필요한 주요 문제점들이 드러나고 수정되는 길고 반복적인 프로세스가 될 수 있다. DO-178B를 거치지 않는, 비 DO-178B 환경보다 일반적으로 50 ~ 75% 더 빠른 통합이 가능하다.

 

개선된 형상관리. 프로젝트의 한 부분이 관리되고 재생산될 수 있도록 하는 것은 형상관리에 의해서 커버된다. 또한 형상관리는 안전, 백업, 완전한 리뷰, 문제점 리포트 그리고 버전 관리를 보장한다. 많은 형상관리 태스크를 자동화하는 현대의 도구들과 함께하는 DO-178B의 강력한 형상관리 요구사항은 현재 그리고 미래 모두의 더 높은 소프트웨어 품질을 보장한다.

 

더 철저한 시험.

 

더 쉬운 회귀시험. 보통 성공적이고 긴 수명을 가질 것이라고 가정하면서 소프트웨어를 만든다. 그리고 소프트웨어가 새로운 적용, 설치 그리고 버전을 통해서 진화할 것이라는 것을 알고 있다. 만약 광범위하게 혹은 수동으로 회귀시험을 하려면 비용이 많이 들 수 있다. DO-178B는 추적성을 통해서 어떤 모듈이 변경되어야 할지, 분석되어야 하고 회귀시험되어야 할지에 대한 정보를 제공한다.

역주) 마지막 문장의 의미는 소프트웨어의 어떤 변경이 필요한 상황이 되면 개발자가 요구사항 추적성을 확인해서 변경되는 부분이 어디이고(요구사항인지, 소스인지, 시험절차인지 등) 그걸 수정하면 혹시 다른 부분을 또 수정해야 하는 것은 아닌지 검토해 볼 수 있다는 것이다. DO-178에서는 추적성이 이런 용도 이외에도 생각보다 다양한 곳에서 사용되고 있는데 어쨌든 상상하는 이상으로 상당히 중요한 항목이라는 것을 기억하자.

 

개선된 하드웨어 통합. 소프트웨어를 타겟으로 통합하는 것은 일반적으로 임베디드 시스템에서는 도전이라고 할 수 있다. 개발 환경이 타겟 환경과 전혀 다르고 타겟 구현은 다른 개발팀을 통해서 이루어 지기 때문이다. DO-178B에서는 하드웨어에 영향을 받을 수 있는 소프트웨어 컴포넌트는 하드웨어상에서 시험할 것을 강요한다. 예를 들면 하드웨어/소프트웨어 인터페이스, 인터럽트, 타이밍, 보드레벨 컴포넌트, BSP/RTOS 등이 있다. 그리고 DO-178B를 통한 이러한 모든 컴포넌트들의 개선된 결정성과 품질은 개선된 하드웨어 통합에 의지한다.

 

더 적은 현장 오류. 현장의 오류와 고객의 반품 및 ‘리콜’은 단기간이든 장기간이든 극단적으로 비용이 많이 든다. DO-178B 기반으로 개발된 제품들은 80 ~ 90% 더 적은 반품율을 보여주고 있다.

역주) 이 부분은 정확한 데이터를 제시하고 있지 않기 때문에 누군가는 그냥 주장일 뿐이지 않냐고 할 지도 모르겠다. 그럴 수도 있다. 하지만 DO-178이 왜 필요하고 그것이 어떻게 진행되는지를 이해하고 나면 저자의 이런 주장(?)이 상당히 신뢰성이 있다는 것을 이해하게 될 것이다. DO-178에 대해서 설명하는 책이어서 의례적으로 하는 이야기가 아니라 정말로 그만한 가치가 있고 효과가 있다는 것은 역자도 전적으로 동의하는 바이다.   다만 현실에서는 우선, 우리에게 익숙하지 않다는 게 크고, DO-178과 같은 것을 받아들일 수 있는 철학이나 의지가 거의 없는 상황이다 보니 이런 이야기가 의례적인 것으로 들릴 수 밖에 없는 것이다. 또한 그런 식으로 흘러온 기간이 너무 길다 보니 특별한 계기가 없이는 받아들이기가 쉽지 않다. 물론 그에 따른 비용에 대한 부분도 당연히 집행해야 하는 투자로 생각하지 않는 것도 받아들이지 못하는 큰 요인 중 하나다.

 

개선된 재사용성. DO-178B에 의해서 요구되는 철저하고 일관된 문서화, 모듈화, 문서화된 현대적인 엔지니어링 원리의 적용 그리고 이상의 모든 것들을 보장하기 위한 리뷰가 소프트웨어 재사용성을 상당히 개선시킨다. (그리고 소프트웨어에서 재사용성은 성배라고 할 수 있다) 하지만 현실에서는 소프트웨어 컴포넌트가 적어도 80%의 재사용성을 가지고 있지 않은 경우에는 차라리 처음부터 시작하는 게 더 빠르고 위험성을 줄일 수 있다. 그리고 대부분의 소프트웨어는 50% 이하의 재사용성을 가진다. DO-178B 그리고 독립된 리뷰 및 추적성과 함께하는 설계/코딩 표준의 적용을 통해서 대부분의 모듈이 적어도 90% 이상의 재사용성이 되어야 한다.

역주) 소프트웨어를 재사용하는 것은 사실 개발자들에게는 이상적인 부분이다. 그런 의도를 가지고 개발을 시작하더라도 막상 최종 결과물이 나오면 이미 재사용성은 딴나라 이야기가 되어 버린다. DO-178은 기본적으로 ‘일관성’과 ‘명확함’을 추구한다. 바로 이런 면이 기존 개발 방식의 모호한 부분을 최소화하기 때문에 그 만큼 재사용성의 가능성이 높아진다고 할 수 있다.

 

개선된 고객 만족. 믿을 수 있는 소프트웨어는 고객의 신뢰를 얻게 된다.

 

한 사람에게 의존하게 되는 문제점 감소. 소프트웨어는 일종의 기술적인 예술활동이고 예술가들은 자신들의 작업을 문서화하는 것이라든지 공통의 개발 표준과 동료 검토로 지배하는 것에 저항한다. 표준, 훈련 그리고 현대적인 소프트웨어 엔지니어링 원리, 소프트웨어 팀이 없이는 느슨하게 조직된 불량 예술가들이 되어버린다. 그들은 매우 귀중하고 창의적이며 재능이 많지만 만약 그런 예술가를 잃게 되거나 어떤 부분이 부족하게 되는 경우에는 팀에는 재앙이 된다. 모든 작업은 반드시 문서화되고 이해되며 일관되게 적용되어야 한다. DO-178B는 한사람에게 의존하면서 발생하게 되는 그런 문제점들을 줄여준다.

 

실제 일정 상태를 알게 되는 관리의 개선. 소프트웨어 프로젝트는 어떻게 매주 “99% 완료”가 보고되는 걸까? 소프트웨어 진도는 어떻게 측정되는 것일까? 관리하는 곳에서는 소프트웨어 완료 상태를 어떻게 정확하게 정의할 수 있을까? 그 답은 DO-178B를 통해서 구축된 현대적이고 정확하게 상세화 된 관리 테크닉이다. 그것은 설계, 개발, 시험, 통합 그리고 리뷰에 대한 통찰력, 추적성, 정확한 상태에 대한 규정을 가지고 있다.

 

위의 사항들로 인해서 개선된 완료 일정. “측정되는 것이 실행되는 것이다.” DO-178B는 지속적인 프로젝트 완료와 품질 상태를 제공한다.

 

시장 확대. DO-178B는 신뢰성에 대한 잘 알려진, 그리고 채택되고 있는 증거를 제공한다. 항공우주, 의료, 교통, 에너지 그리고 심지어는 엔터테인먼트(놀이공원같은) 분야에 이르기까지 안전에 민감한 적용이 많다. 이들 영역은 생명을 다루고 있기 때문에 안전과 신뢰성을 높일 필요가 있다.

 

경쟁자들에 비해 개선된 차이점. 현재의 경제 시스템은 경쟁을 보장한다. 이 말은 누군가가 당신 제품의 장점을 채택해서 당신과의 차이점을 무력화할 수 있다는 것을 의미한다. 그럼 어떻게 해야 할까? 제품을 개선하고 스스로 차별화시키는 것이다. 기업과 제품은 살아남기 위해서 끊임없이 성장해야 한다. 신뢰성을 증명하고 품질을 증명하며 가치가 더해진 제안을 증명하라. 똑같은 것을 찍어내는 것이 아니라 DO-178B는 당신이 그런 증거를 보여줄 수 있도록 만들어 준다.

DO-178B의 장점 상당히 빨리 선행된 요구사항이 시험을 명확하게 함     더 적은 현장에서의 문제점 더 적은 코딩의 반복     개선된 고객 만족 단위시험 동안의 더 적은 버그     개선된 재사용성 소프트웨어 내부의 더 뛰어난 일관성   한사람에 의존하면서 발생하는 문제점 감소   개선된 형상관리     실제 일정 상태의 이해에 대한 개선된 관리 더 쉬운 회귀시험     이러한 것들을 통해서 개선된 완료 일정 더 철저한 시험     시장 확대 개선된 하드웨어 통합   경쟁자에 비해서 개선된 차이점   군은 DO-178B를 받아들여왔다. 왜냐하면: 공급자에 대한 일관성 & 가시성의 개선   개선된 시스템 신뢰성 개선된 소프트웨어 품질   라이프사이클 비용의 감소 더 나은 재사용성

 

역주) DO-178의 많은 장점들이 소개되고 있다. 내용만 보면 더할 나위 없이 좋은 것들만 보인다. 문제는 돈과 인력이다. 개발에만 매달리기에도 부족한데 DO-178까지 챙길 여유가 없는 것이다. 좋은 건 알고 있지만. 어차피 단기간에 할 수 있는 게 아니다. 장기적인 시선과 의지를 가지고 꾸준히 해 나가야 그나마 비슷한 효과를, 그것도 아주 서서히 경험할 수 있을 것이다. 따라서 그것을 선택하기 위한 정확한 이해와 경영진의 철학이 선행되어야 할 부분이라고 생각된다.