13. DO-178과 소프트웨어 형상관리 프로세스 (Section 7.0)

소프트웨어 개발에서 형상관리(Configuration Management)는 앞서 나왔던 여러 프로세스들에 비해서 상대적으로 사람들의 관심이 떨어지는 게 사실이다. 실제로 현장에서 보면 형상관리 자체가 제대로 이루어 지지 않는 경우가 많다. 하지만 DO-178에서는 이런 식의 기존 방식으로는 절대로 인증을 받을 수 없다. 어떻게 보면 DO-178 인증을 위해서는 다른 무엇보다도 형상관리 프로세스가 기본이라고 할 수 있다. 왜냐하면 DO-178 인증을 받기 위해서 FAA 혹은 DER에게 제출하는 산출물은 모두 형상관리를 통해서 보관되고 관리되고 최종적으로 제출되기 때문이다.

 

이번 절에서는 DO-178 가이드라인에서 설명하는 형상관리 프로세스에 대해서 자세히 알아본다. 시작에 앞서 소프트웨어 형상관리 프로세스 역시 소프트웨어 계획 프로세스(Software Planning Process)를 통해서 소프트웨어 형상관리 계획(Software Configuration Management Plan) 문서로 작성된다는 점을 기억하자. 당연히 계획 문서에 작성된 대로 진행되어야 한다.

 

(1)    소프트웨어 형상관리 프로세스의 역할

 

DO-178 가이드라인에서는 형상관리 프로세스를 통해서 다음과 같은 역할을 수행할 것이라고 기대하고 있다.

 

a.     소프트웨어 라이프 사이클 전반에 걸쳐서 소프트웨어에 대해 정의되고 컨트롤된 형상을 제공

b.     실행가능 오브젝트 코드와 파라미터 데이터 아이템 파일을 반복적으로 복제할 수 있게 해 줌

c.     소프트웨어 라이프 사이클 동안의 프로세스 입력과 출력의 컨트롤

d.     리뷰, 상태 평가, 변경 컨트롤을 위한 알려진 지점과 베이스라인 생성을 제공

e.     문제점과 그에 대한 변경을 기록, 승인, 구현하는 것을 보장하는 컨트롤 제공

f.      소프트웨어 라이프 사이클의 산출물 컨트롤에 의해서 소프트웨어 승인에 대한 증거를 제공

g.     소프트웨어 제품이 요구사항을 준수한다는 것을 평가

h.     형상항목들의 안전한 보관, 복구, 컨트롤을 보장

 

다양하면서도 많은 역할이 제시되고 있다. 그리고 결론적으로는 위에서 언급된 역할 하나하나를 정확하게 수행해야 한다. 그렇게 하기 위해서는 DO-178 가이드라인에서 제시하는 지침 전체를 제대로 이해하고 그에 맞는 활동을 수행하는 것이 중요하다. 무엇보다도 소프트웨어 형상관리 프로세스는 결과적으로 가이드라인에서 제시하는 모든 내용을 실제 결과물로 보여주게 되는데 제대로 수행하지 못한 부분은 있는 그대로 명확하게 드러나게 되므로 소위 ‘어설프게’ 혹은 ‘어중간하게’ 할 수 있는 여지가 거의 없는 부분이라고 할 수 있다.

 

(2)    소프트웨어 형상관리 프로세스의 목표(Objectives) (Section 7.1)

 

DO-178 가이드라인에서는 소프트웨어 형상관리 프로세스의 목표(Objective), 활동(Activity), 결과(Output)를 부속물(Annex) A의 Table A-8에서 확인할 수 있다.

 

 

위의 표에서 Objective에 있는 Ref에 DO-178 가이드라인의 관련 절이 표기되어 있다. 해당하는 절에는 위의 Objective에 대한 이해를 돕기 위한 내용들이 정리되어 있다. 결국 우리는 그런 것들을 참고해서 위의 Objective를 정확하게 이해하는 것이 중요하다.

 

위의 표를 기준으로 정리해 보면 다음과 같다.

 

1.     형상 항목이 구분되어야 함

2.     베이스라인과 추적성이 만들어져야 함

3.     문제점 리포트, 변경 컨트롤, 변경 리뷰, 그리고 형상 상태 확인이 이루어져야 함

4.     소프트웨어 로딩에 대한 컨트롤이 되어야 함

5.     소프트웨어 라이프 사이클 환경 컨트롤이 되어야 함

 

기본적으로 위의 내용들을 만족할 수 있고 그 증빙을 보일 수 있다면 DO-178 인증을 위한 소프트웨어 형상관리 프로세스를 완벽하게 수행하는 것이라고 볼 수 있다.

 

(3)    소프트웨어 형상관리 프로세스의 활동(Activities) (Section 7.2)

 

DO-178 가이드라인에서 제시하는 주된 활동으로는 다음과 같은 것들이 있다.

 

-       형상 구분

-       변경 컨트롤

-       베이스라인 생성

-       보관

 

기본적으로 형상관리 활동의 대상은 관련되는 소프트웨어 라이프 사이클 데이터를 포함한 소프트웨어 제품 전체이다. 그리고 형상관리 활동은 DO-178 인증을 받는 것으로 종료되는 것이 아니다. DO-178 가이드라인에서는 이에 대해서 아래와 같이 설명하고 있다.

 

해석을 보자.

 

소프트웨어 형상관리(SCM) 프로세스는 소프트웨어 제품이 인증당국에 의해서 승인받을 때 멈추는 것이 아니라 시스템 혹은 장비의 서비스 라이프 내내 계속된다.

 

DO-178 가이드라인 자체에서도 DO-178 인증을 받고 나면 소프트웨어 형상관리 프로세스가 종료되는 것이 아니라는 점을 분명하게 하고 있다는 것을 확인할 수 있다.

 

앞서 정리한 주요 활동들은 일반적인 형상관리 활동들과 동일한 것들이다. 하지만 그 안에는 DO-178 관점으로 이해해야 할 부분들이 포함되어 있다. 그런 부분들을 살펴보자.

 

①     형상 구분 (Section 7.2.1)

 

먼저 형상 구분(Configuration Identification)이라는 용어를 DO-178 가이드라인에서는 어떻게 정의하고 있는지 한 번 보자. 형상 항목(Configuration Item)에 대해서도 함께 알아보자.

 

해석을 보자.

 

형상 구분 – (1) 하나의 시스템에서 형상 항목을 지정하고 그들의 특성을 기록하는 프로세스. (2) 형상 항목을 정의하는 승인된 문서화   형상 항목 – (1) 형상 관리 목적을 위해 하나의 유닛(Unit)으로 다루어 지는 하나 혹은 그 이상의 하드웨어 혹은 소프트웨어 컴포넌트. (2) 형상 관리 목적을 위해 하나의 유닛(Unit)으로 다루어 지는 소프트웨어 라이프 사이클 데이터.

 

간단하게 말하면 형상 항목은 소프트웨어 개발 과정에서 우리가 다루게 되는 문서, 소스 등과 같은 것을 말하며 형상 구분은 그런 것들을 형상 관리용 서버에 등록하는 것을 말한다. 용어가 좀 낯설 수는 있어도 우리가 일반적으로 생각하는 개념과 별반 다르지 않다.

 

DO-178 가이드라인에서는 이러한 형상 항목에 대한 형상 구분의 시점을 다음과 같이 가이드하고 있다.

 

해석을 보자.

 

d. 형상 항목은 그 항목이 다른 소프트웨어 라이프 사이클 프로세스에 의해 사용되기 전, 다른 소프트웨어 라이프 사이클 데이터에 의해서 참조되기 전, 혹은 소프트웨어 생산 혹은 소프트웨어 로딩을 위해 사용되기 전에 구분되어야 한다.

 

위의 설명은 간단하게 말하면 형상 항목이 참조되기 시작하면 그 형상 항목은 형상구분을 하라는 것이다. 다른 프로세스나 형상 항목에서 참조를 한다는 것은 그 이후에도 다시 참조가 될 수 있다는 뜻이 된다. 그렇다면 다음에 참조하는 경우에 그것이 현재 참조한 것과 동일한 것인지, 아니면 오히려 그 이전의 것인지 어떻게 확인할 수 있을까? 바로 형상관리를 통해서 이런 부분을 커버하는 것이다. 따라서 참조가 되는 순간부터는 반드시 공식적인 형상관리가 수행되어야 한다.

 

여담이지만 필자는 이 부분에 대해서 더 엄격한 의견을 가지고 있다. 예를 들면 일단 문서 하나를 생성하게 되면 무조건 형상 등록부터 하라고 제안한다. 즉 형상 구분부터 시작하라는 것이다. 물론 시작부터 형상 등록을 하게 되면 그 만큼 번거로운 일이 많아지는 것이 사실이다. 하지만 그런 번거로움 보다는 제대로 관리됨으로써 전반적으로 얻게 되는 이득이 훨씬 더 크다고 믿고 있다. 한편으로는 그런 면을 고려해서 초기의 관리는 상대적으로 느슨하게 하는 것도 방법이 될 수 있다. 어쨌든 소스와 같은 초기 변동성이 급격한 항목을 제외하고는 가능하면 모든 형상 항목은 반드시 시작 시점에서부터 형상 등록을 한 후에 제대로 관리하는 것을 추천한다.

 

②     베이스라인과 추적성 (Section 7.2.2)

 

베이스라인이라는 것은 결국 버전관리를 말한다. 그리고 추적성은 그렇게 관리되는 버전과 그 내부에 포함되는 항목들이 모두 명확하게 구분되고 확인될 수 있어야 한다는 말이다. DO-178 관점에서 이와 관련해서 기억해야 할 부분은 아래와 같은 내용이다.

 

해석을 보자.

 

b. 소프트웨어 제품 베이스라인은 소프트웨어 제품에 대해서 생성되어야 하며 소프트웨어 형상 인덱스(Software Configuration Index)에 정의되어야 한다.

 

이것은 소프트웨어 개발이 완료되어 제품화되는 시점에서의 베이스라인 설정을 말하는 것으로 그 자체는 특별한 게 없지만 그 다음에 나오는 ‘소프트웨어 형상 인덱스(Software Configuration Index)’를 작성하는 것에 대해서는 반드시 기억하고 있어야 한다. DO-178 인증을 받기 위한 필수 문서라고 할 수 있으며 자세한 내용은 DO-178 가이드라인 Section 11.16에서 확인할 수 있다. 별도의 절로 다시 설명할 예정이다.

 

③     변경 리뷰 (Section 7.2.5)

 

변경 리뷰(Change Review) 자체는 일반적으로 생각하는 리뷰의 개념과 다르지 않다. 다만 이 리뷰를 어느 정도로 진행하느냐는 DO-178 기준으로 이해할 필요가 있다. 아래는 DO-178 가이드라인에서 제시하는 변경사항에 대한 리뷰 활동 중 하나이다.

 

해석을 보자.

 

a. 시스템 요구사항에서의 문제점 혹은 제안된 변경의 충격을 평가. 피드백이 시스템 안전성 평가 프로세스를 포함해서 시스템 프로세스로 제공되어야 하며 시스템 프로세스로부터의 어떤 응답도 평가되어야 한다.

 

DO-178 관점에서는 리뷰가 단순히 해당 항목에 대한 리뷰 자체로 끝나는 것이 아니라 반드시 시스템 안전성 평가를 거쳐야 한다. 물론 변경사항이 시스템에 영향을 주는지에 따라서 실제로 문제점 혹은 변경사항에 대한 시스템 안전성 평가가 이루어 질지 그렇지 않을지가 결정되겠지만 최소한 그것에 대한 판단을 할 수 있어야 한다는 것이다. 안전성을 중요시 하기 때문에 사소한 변경사항 하나도 꼼꼼하게 체크하는 것이라고 볼 수 있다.

 

④     형상 상태 감사 (Section 7.2.6)

 

‘accounting’이라는 단어를 ‘감사’로 번역해서 약간 어색하게 보이겠지만 이것은 간단하게 말하면 현재 형상 구분 상태를 전체적으로 파악하고 리포트하는 것이다. DO-178 가이드라인에서는 아래와 같은 활동으로 설명하고 있다.

 

해석을 해보면 다음과 같다.

 

a. 형상 항목 구분, 베이스라인 구분, 문제점 리포트 상태, 변경 히스토리 그리고 릴리즈 상태에 대한 리포팅 b. 유지되어야 할 데이터와 이 데이터의 상태를 기록하고 리포트하는 방법의 정의

 

(4)    데이터 관리 범주(Data Control Category) – CC1과 CC2 (Section 7.3)

 

DO-178에서는 형상관리와 관련해서 데이터 관리 범주(Data Control Category)라는 용어를 사용하고 있다. 가이드라인에는 아래와 같이 정의되어 있다.

 

해석을 보자.

 

관리 범주 – 소프트웨어 라이프 사이클 데이터에 주어지는 형상 관리 컨트롤. 두 가지 범주인 CC1과 CC2는 소프트웨어 라이프 사이클 데이터를 컨트롤하기 위해 적용되는 소프트웨어 형상 관리 프로세스와 활동을 정의한다.

 

설명이 복잡한데 간단하게 말하면 형상관리를 더 엄격하게 하느냐 덜 엄격하게 하느냐의 구분이다. 이에 대한 이해를 위해서는 필자가 번역했던 인증 지침서의 아래 그림이 도움이 될 수 있다.

 

그림 25 CC1과 CC2에 대한 포함관계

 

CC2가 CC1 내부에 포함되어 있는데 이는 CC2가 CC1에 비해서 고려해야 할 부분이 더 적다는 것을 표시하는 것이다. DO-178 가이드라인에서는 엄격함의 구분을 아래와 같이 나누고 있다.

 

 

위의 표에서 엄격함의 구분은 우측의 CC1, CC2에 점으로 표시된 활동이 있는지가 기준이다. 예를 들면 CC1은 모든 활동에 대해서 점이 표시되어 있는데 이것은 CC1으로 구분되는 데이터에 대해서는 왼쪽의 모든 형상관리 프로세스의 활동을 수행해야 한다는 뜻이다. 즉, 첫 번째 줄의 형상구분(Configuration Identification)에서부터 마지막 줄의 데이터 보존(Data Retention)에 이르기까지 모든 활동을 수행해야 한다. 이에 반해서 CC2의 경우는 베이스라인이나 변경 컨트롤, 리뷰 등의 일부 활동이 표시되어 있지 않다. CC2로 구분되는 데이터는 그런 활동들을 수행하지 않아도 되는 것이다. 그 만큼 덜 엄격하다는 의미이다.

 

그리고 이는 앞서 여러 번 본 적이 있는 아래와 같은 각 프로세스별 목표, 활동, 출력에 대한 표에서 사용되고 있다. 아래 표의 붉은색으로 표시된 부분에 대해서 위의 해석을 적용할 수 있다.

 

사실 필자가 번역한 적이 있는 DO-178 인증 지침서에서는 CC1과 CC2에 대해서 아래와 같이 설명하는 부분이 있다.

 

해석을 보자.

 

하지만 레벨과 데이터 아이템을 구분하려고 노력해서 그것이 레벨 CC1인지 CC2인지를 알아내는 것에 시간을 낭비하지는 말아라. 모든 것을 엄격한 형상 컨트롤하에 유지하는 것이 더 쉽다. 그렇게 함으로써 프로세스를 반복하지 않고 단지 모든 것을 CC1으로 수행함으로써 어떤 레벨로 적용할 지 결정하는 데 더 많은 시간을 소모하지 않게 된다.

 

위의 설명에서 말하고자 하는 점은 모든 형상항목을 CC1, CC2와 같이 무엇이 더 엄격해야 하고 덜 엄격해도 되는지 구분하고 신경쓰다보면 오히려 그 부분에 더 부하가 걸릴 가능성이 높으므로 그럴 바에는 차라리 전체를 엄격한 레벨로 통일해서 형상관리를 하는 것이 하나하나 구분하는 것에 비해서 전체적으로 보면 오히려 부하를 감소시킬 수 있다는 말이다. 물론 이는 선택의 문제이므로 굳이 구분해서 한다고 해서 문제가 될 부분은 전혀 없다.

 

(5)    그 외의 주요내용

 

소프트웨어 형상관리 프로세스에 대한 내용 중 일반적으로는 잘 알려지지 않았지만 DO-178 인증을 위해서 반드시 챙겨야 하는 항목들이 있다. 바로 아래 항목들이다.

 

-       소프트웨어 로딩과 관련된 컨트롤

-       소프트웨어 라이프 사이클 환경에 대한 컨트롤

 

사실 위의 것들은 제대로 형상관리가 이루어지지 않으면 소프트웨어의 안전성에 반드시 문제를 일으키게 된다. 예를 들면 소프트웨어 로딩과 관련된 컨트롤에 대한 형상관리가 제대로 이루어 지지 않으면서 잘못된 소프트웨어가 시스템에 로딩되는 문제가 있을 수 있다. 혹은 소프트웨어 라이프 사이클 환경의 일부라고 할 수 있는 개발 도구가 임의로 사용되면서 자칫 최종 산출물이 툴의 버전에 따라서 일부 달라질 수도 있다. DO-178 가이드라인에서는 이러한 문제들을 방지하기 위해서 각각에 대한 지침을 제시하고 있다.

 

①     소프트웨어 로드 컨트롤(Software Load Control) (Section 7.4)

 

소프트웨어를 시스템에 적재할 때는 승인된 소프트웨어를 승인된 방법으로 로드해야 한다. DO-178에서는 그것을 위해서 다음과 같은 활동을 수행하도록 하고 있다.

 

a.      적재될 소프트웨어라는 것을 증명할 수 있게 소프트웨어 형상을 구분하도록 일련 번호를 매기거나 미디어 구분을 하는 절차가 있어야 함

b.     적재될 소프트웨어가 시스템 혹은 장비와 호환성을 가지는지를 확인할 수 있는 기록이 있어야 함

 

참고로 DO-178 가이드라인에서는 이에 대한 예시를 다음과 같이 들고 있다.

 

해석을 해 보면 다음과 같다.

 

소프트웨어 로드 컨트롤은 프로그램된 명령어와 데이터가 마스터 메모리 디바이스로부터 시스템 혹은 장비로 전송되는 프로세스를 참조한다. 예를 들면, 방법에는 (인증 당국의 승인을 조건으로) 공장 사전 프로그램된 메모리 디바이스의 설치 혹은 현장 로딩 디바이스를 사용한 시스템 혹은 장비의 “현장” 재 프로그래밍을 포함할 수 있다.

 

예시가 좀 어렵기는 하지만 요지는 특정한 상황에서 소프트웨어를 다시 로딩하는 경우에 소프트웨어 로드 컨트롤이 참조된다는 것을 설명하고 있다.

 

②     소프트웨어 라이프 사이클 환경 컨트롤(Software Life Cycle Environment Control) (Section 7.5)

 

제목이 뭔가 엄청난 것을 말하는 것 같지만 결국 이것은 소프트웨어를 개발하면서 사용되는 도구, 즉 개발환경에 대한 형상관리를 말하고 있다. DO-178에서는 소프트웨어 자체에 대한 형상관리 뿐만 아니라 그 소프트웨어를 만드는 과정에서 사용되는 개발환경에 대해서도 고려를 하는 것이다. 다음과 같은 활동을 수행하도록 가이드하고 있다.

 

a.      도구의 실행가능 오브젝트 코드에 대한 형상 구분이 되어야 함. 이때 도구의 대상은 개발, 컨트롤, 빌드, 검증, 그리고 로드에 이르기까지 소프트웨어 라이프 사이클 전반에 걸쳐서 사용되는 도구를 말함

b.     인증된 도구를 컨트롤하기 위한 형상관리 프로세스는 소프트웨어와 마찬가지로 앞서 설명한 CC1 혹은 CC2 데이터의 기준을 따라야 함

c.      위의 b가 적용되지 않는 경우에는 최소한 CC2의 기준을 따라야 함