소프트웨어 재사용과 DO-178C

“저희는 이 소프트웨어를 ISO 26262나 ISO 61508 등의 표준을 준수하여 개발했어요. 그런데 굳이 처음부터 다시 개발해야 할까요?”

항공우주 프로그램에 참여하는 조직이 늘면서 이런 질문도 점점 더 자주 제기됩니다. 다행히도 답은 “아니오”​입니다. DO-178C는 처음부터 항공기용으로 개발되지 않았다는 이유만으로 이미 검증된 소프트웨어를 폐기하도록 요구하지 않습니다. 그렇다고 특정 환경에서 문제없이 작동한 소프트웨어가 다른 환경에서도 자동으로 적용될 수 있다고 보는 것도 아닙니다. 중요한 것은 기존 소프트웨어를 재사용할 수 있는지를 판단하는 것이 아니라, 해당 소프트웨어를 새로운 배포 환경(deployment context)에 도입할 때 무엇이 달라지는지를 이해하는 것입니다.

오늘날 소프트웨어 개발은 재사용을 전제로 한다

오늘날 대부분의 임베디드 소프트웨어 프로젝트는 빈 소스트리(empty source tree)에서 시작하지 않습니다. 애플리케이션 자체를 새로운 제품에 맞춰 처음부터 개발하는 경우에도 일반적으로 이미 존재하는 소프트웨어에 의존합니다. 운영체제(OS), 보드 지원 패키지(BSP), 통신 스택, 미들웨어, 암호화 라이브러리, 컴파일러 런타임 라이브러리, 생성 코드, 자체 개발한 프레임워크 등이 최종 실행 이미지 구성에 모두 활용됩니다.

이것은 결코 잘못된 소프트웨어 개발 방식이 아닙니다. 오히려 오늘날 임베디드 시스템이 개발되는 일반적인 방식입니다. 이미 검증된 소프트웨어를 재사용하면 비용을 절감하고 개발 시간을 단축할 수 있으며, 엔지니어링 조직은 수년간 축적한 경험을 바탕으로 새로운 시스템을 개발할 수 있습니다.

항공우주 분야로 진출한다고 해서 이러한 현실이 달라지는 것은 아닙니다. 다만 기존 소프트웨어가 인증된 항공 시스템의 일부로 사용되기 위해서는 그 전에 새롭게 답해야 할 몇 가지 질문이 있습니다. 

새로운 배포 환경에 따라 달라지는 인증 논거

DO-178C는 애플리케이션 소프트웨어가 독립적으로 존재하는 것이 아니라는 점을 전제로 합니다. 소프트웨어는 특정 프로세서에서 실행되며, 특정 개발·컴파일·테스트 툴체인을 사용하여 개발됩니다. 또한 특정 하드웨어와 연동되고 다른 소프트웨어 구성 요소와 통신하며, 부여된 소프트웨어 레벨에 따라 정의된 기능을 수행하는 시스템의 일부로 동작합니다. 

이러한 요소 가운데 어느 하나라도 달라지면 소프트웨어의 배포 환경(deployment context)도 달라지며, 바로 이것이 DO-178C가 중요하게 보는 부분입니다. 실제 운용 환경에서 성공적으로 작동했다는 사실은 분명 중요한 근거가 될 수 있습니다. 하지만 새로운 항공기용 애플리케이션에 필요한 입증 자료를 대신할 수는 없습니다. 기존 환경에서의 성공적인 운용은 소프트웨어에 대한 신뢰도를 높여주지만, DO-178C 적합성을 입증하는 것은 아닙니다. 

입증 자료의 격차 해소
IEC 61508이나 이를 기반으로 한 표준인 ISO 26262, IEC 62304, EN 50716 등을 경험했다면 DO-178C에서 요구하는 많은 엔지니어링 절차가 이미 익숙할 것입니다. 요구사항 관리, 양방향 추적성, 검토, 정적 분석, 테스트, 형상 관리 등은 모두 기능 안전성 분야와 밀접한 관계가 있습니다.

차이는 안전보증 논거(assurance argument)​에 있습니다. 기능 안전성은 요구되는 무결성 수준을 달성하기 위해 충분한 조치가 적용됐는지를 확인합니다. 반면, DO-178C는 적용 가능한 모든 라이프사이클 목표(lifecycle objective)를 충족했는지, 그리고 이를 객관적이고 검토 가능한 입증 자료를 통해 증명할 수 있는지를 확인합니다.

이러한 차이는 기존 소프트웨어를 재사용하는 데 필요한 노력에도 영향을 미칩니다. 공인된 기능 안전성 프로세스에 따라 개발된 소프트웨어라면 요구사항, 설계 문서, 검토 결과, 테스트 및 추적성 자료 등이 이미 갖춰져 있을 수 있습니다. 반면, 보다 비공식적인 방식으로 개발해 온 소프트웨어는 정상적으로 작동하는 소스 코드만 남아 있을 수도 있습니다. 둘 중 어느 쪽도 그 자체로 적합하거나 부적합하다고 볼 수는 없습니다. 결국 차이는 새로운 환경에 적용하기 위해 보완해야 할 입증 자료의 격차(evidence gap)가 얼마나 큰가에 있습니다. 

‘안전 설계’가 기존 소프트웨어의 재사용을 막는 것은 아니다

항공우주 분야에서는 ‘안전 설계(safety by design)’를 강조하지만, 그렇다고 소프트웨어가 반드시 현재의 DO-178C 라이프사이클에 따라 개발됐어야 한다는 의미는 아닙니다.

DO-178C는 과거의 개발 과정을 재현하거나 기존 소프트웨어가 마치 최근에 개발된 것처럼 다루도록 요구하지 않습니다. 대신 새로운 배포 환경에서 해당 소프트웨어가 의도된 용도를 충족할 수 있음을 입증할 수 있는 충분한 근거를 요구합니다. 

이를 위해서는 소프트웨어가 어떤 기능을 수행하도록 설계됐는지, 어떤 가정을 전제로 하는지, 어떤 인터페이스에 의존하는지, 어떤 환경에서 동작하게 되는지를 이해해야 합니다. 이러한 정보가 이미 확보돼 있다면 상당 부분 재사용할 수 있습니다. 반면, 필요한 정보가 없다면 소프트웨어가 DO-178C 라이프사이클에 본격적으로 포함되기 전에 해당 정보를 복원하고 문서화한 뒤 검증해야 할 수 있습니다.

결국 목표는 정상적으로 작동하는 소프트웨어를 다시 개발하는 것이 아닙니다. 새로운 역할에 해당 소프트웨어를 적용하는 것이 적절하다는 사실을 입증하는 것입니다.

문서의 모음이 아닌 하나의 입증 체인 구축

항공우주 분야에 진출하는 조직이 가장 먼저 이해해야 할 중요한 개념적 변화는 인증을 위한 입증 자료가 서로 별개의 보고서를 모아 놓은 형태로 구성되는 것이 아니라는 점입니다. 

요구사항, 아키텍처, 소스 코드, 검토 결과, 검증 결과, 구조적 커버리지, 타깃 측정 결과, 규정 준수 보고서 등은 모두 하나의 입증 체인(evidence chain)​을 구성합니다. 소프트웨어가 발전하면 이 입증 체인도 함께 발전합니다. SOI(Stage of Involvement) 검토에서 인증 기관이 확인하는 것은 개별 산출물뿐만 아니라, 각 산출물을 연결하는 일관성과 추적성입니다. 

프로젝트 규모가 커지고 복잡해질수록 이러한 관계를 수작업으로 관리하기는 점점 더 어려워집니다. 이 지점에서 검증되고 신뢰할 수 있는 개발 및 검증 툴체인이 중요한 역할을 합니다.
 
LDRA 툴 제품군은 요구사항 추적성, 정적·동적 분석, 테스트, 구조적 커버리지, 규정 준수 보고 기능을 지원합니다. TASKING BlueBox와 winIDEA는 실제 타깃 환경에서 실행 과정, 타이밍 및 트레이스 동작을 확인할 수 있도록 지원합니다. 이들 툴을 함께 사용하면 반복적인 엔지니어링 작업을 줄이면서 입증 체인의 무결성을 유지할 수 있습니다.

기존 소프트웨어에는 수년간 축적된 엔지니어링 투자가 녹아 있습니다. 여기에는 축적된 경험과 도메인 지식은 물론, 실제 환경에서 검증된 동작 특성이 반영된 경우도 많습니다. DO-178C는 이러한 투자를 포기하도록 요구하지 않습니다.

다만 새로운 배포 환경이라는 관점에서 기존 소프트웨어를 검토하고, 새로운 배포 환경에 맞춰 소프트웨어와 이를 뒷받침하는 입증 자료를 함께 조정할 것을 요구합니다.

 

---

DO-178C는 항공기 탑재 시스템 및 장비에 사용되는 소프트웨어의 개발과 인증을 위한 국제적 지침이다. 소프트웨어의 계획, 개발, 검증 및 인증 과정에서 충족해야 할 목표와 활동을 제시하며, 시스템 고장이 항공기 안전에 미치는 영향에 따라 DAL A부터 E까지 안전성 등급을 구분해 요구되는 입증 수준을 차등 적용한다. 이를 통해 항공 소프트웨어가 의도된 기능을 안전하게 수행한다는 것을 객관적인 자료로 입증하도록 하고 있다.

AEM(오토모티브일렉트로닉스매거진)

---