17. DO-178과 소프트웨어 라이프 사이클 데이터 (Section 11.0)

앞서 아래와 같은 목록을 본 적이 있을 것이다.

 

이제부터는 본격적으로 DO-178 인증을 통해서 만들어지는 위의 목록에 있는 문서 혹은 데이터에 대해서 알아보자. 참고로 이 모든 것들은 앞서 설명되었던 여러 프로세스들을 거치면서 만들어 지는 것들이다.

 

참고) 위의 설명에서 ‘문서 혹은 데이터’라고 말한 부분의 의미를 정확하게 정리할 필요가 있을 것 같다. 의미로 보자면 문서도 데이터의 종류이다. 따라서 두 단어를 혼용해서 쓸 필요없이 모두 데이터로 통일하면 가장 깔끔하다. 하지만 우리가 만들어내는 데이터의 상당 부분이 문서이고 아무래도 우리에게는 문서와 데이터의 뉘앙스 차이가 있기 때문에 이해의 편의를 위해서 필자의 설명에서는 필요에 따라서 구분해서 사용을 하고 있다.   참고로 DO-178 가이드라인에서는 ‘document’라는 용어대신 ‘data’로 통일해서 사용하고 있다. 이는 산출물의 형태가 문서이든 혹은 다른 형식이든 제한을 두지 않는다는 의미를 담고 있다. 결국 내용이 중요한 것이고 그래서 모든 것을 ‘data’로 칭하고 있는 것이다. 착오 없으시기 바란다.

 

DO-178 가이드라인에서는 이러한 문서 혹은 데이터의 생성에 대해서 다음과 같은 네 가지 관점으로 가이드하고 있다.

 

-       소프트웨어 라이프 사이클 데이터가 가져야 할 특징(Characteristics)

-       소프트웨어 라이프 사이클 데이터가 갖춰야 할 형식(Form)

-       소프트웨어 라이프 사이클 데이터에 대한 형상 관리 컨트롤(Configuration Management Controls)

-       소프트웨어 라이프 사이클 데이터의 내용(Content)

 

결국은 DO-178 가이드라인에서 제시하는 위의 네 가지 관점에 맞게 소프트웨어 라이프 사이클 데이터가 만들어 지는 것이 중요하다. 그리고 직접 만들어야 하는 우리로서는 위의 네 가지 관점에 대해서 명확하게 이해하고 실제 데이터를 만들 때 반영해야 한다. 하나씩 살펴보자.

 

(1)    소프트웨어 라이프 사이클 데이터가 가져야 할 특징(Characteristics)

 

소프트웨어 라이프 사이클 데이터는 다음과 같은 특징을 가지게 된다. 일단 여기서는 문서라고 생각하고 보면 조금 더 이해가 쉬울 것이다.

 

내용이 많기는 하지만 해석을 해 보면 다음과 같다.

 

a. 특징: 소프트웨어 라이프 사이클 데이터는 다음과 같아야 한다:   1.      모호하지 않은: 만약 하나의 해석만 허용되는, 필요하다면 정의에 의해서 도움을 받는 용어들로 작성된다면 정보는 모호하지 않다 2.      완전한: 필요하고 관련된 요구사항 그리고/혹은 설명적인 요소들을 포함할 때; 유효한 입력 데이터의 범위에 대해서 응답이 정의될 때; 사용된 형상이 라벨링될 때; 그리고 측정 용어와 단위들이 정의될 때 정보는 완전하다 3.      검증가능한: 사람 혹은 툴에 의해서 정확성에 대해 체크될 수 있다면 정보는 검증가능하다 4.      일관된: 내부적으로 충돌이 없다면 정보는 일관성을 가진다 5.      수정가능한: 구조적이고 그 구조를 유지하는 동안 변경이 완전하게, 시종일관해서, 그리고  정확하게 이루어질 수 있는 그런 스타일을 가진다면 정보는 수정가능하다 6.      추적가능한: 해당 컴포넌트의 기원이 결정될 수 있다면 정보는 추적가능하다

 

우리가 어떤 것에 대해서 ‘특징’을 이야기하는 경우 사실 특징이라는 것은 자칫 모호한 개념으로 받아들여질 가능성이 높다. 필자가 처음 DO-178 가이드라인에서 설명하는 소프트웨어 라이프 사이클 데이터의 특징이라고 하는 것을 보았을 때는 그렇게 받아들이고 크게 신경 쓰지 않고 지나쳤었다. 실제로 위의 내용들을 읽어보면 당연히 이렇게 작성해야 하는게 아닌가 싶고 그렇게 어려운 내용은 없어 보인다.

 

하지만 실전에서 DER이 바로 위의 문구들을 가지고 산출물 하나하나를 리뷰하면서 지적하는 것을 보면서 그런 판단이 잘못되었다는 것을 깨닫게 되었다. 이 글을 처음 보는 분들에게는 어쩌면 그런 느낌에 제대로 전달되지 않을 수도 있을 것 같은데 일단 위의 내용에 대해서 추가 설명을 보면서 그런 부분을 정리해 보자.

 

①     모호하지 않은(Unambiguous)

 

‘모호하지 않다’는 것을 이해하는 가장 빠른 방법은 ‘모호한’것이 무엇인지를 보는 것이다. ‘모호하다’라는 단어를 아무리 설명해 봐야 실제 그 느낌을 말로는 이해하기가 힘들다. 예시를 보면서 직관적으로 느껴지는 것이 가장 빠르고 어쩌면 가장 정확한 이해가 아닐까 싶다.

 

소프트웨어 라이프 사이클 데이터 중에서 대표적인 항목이라고 할 수 있는 요구사항을 예를 들어 보자. 아래는 DO-178 인증을 받기 위한 소프트웨어의 요구사항으로 작성된 문장이다.

 

위의 문장을 볼 때 어떤 느낌이 드는가? 모호하다? 잘 작성된 것 같다? 아마 다양한 의견이 있을 것이다. 솔직히 필자는 지금도 저 정도면 아주 깔끔하게 작성한 게 아닌가 싶은 생각이 들기도 한다. 더구나 모국어도 아닌 영어를 저렇게 간결하게 작성할 수 있다는 것 만으로도 대단하다는 생각이 드는 게 사실이다.

 

하지만 DO-178 인증의 관점에서 보기 시작하면 앞서 우리가 말한 ‘모호함’이 문장에 포함되어 있다는 것을 알게 된다. 일단 그 부분을 지적한 아래 내용을 보자.

 

‘충분한’이나 ‘지원한다’라는 말이 당연하게 들릴 수 있지만 조금만 더 생각해 보면 얼마가 되어야 충분한 건지, 지원을 한다는 게 도대체 무엇을 지원한다는 것인지가 명확하지 않다는 점을 알게 된다. ‘모호하지 않다’라는 것은 바로 이런 모호한 단어, 용어를 사용하지 않아야 한다는 것을 말한다.

 

참고로 위의 문장을 ‘모호하지 않게’하자면 아래와 같이 수정할 수 있다.

 

위의 샘플을 통해서 DO-178 가이드라인에서 설명하는 모호함을 해소하기 위해 정확도의 범위를 정의한 내용이 추가됨으로써 모호하지 않은 정의를 하고 있다는 것을 확인할 수 있다.

 

위의 예를 보고 혹시라도 요구사항에 대해서만 이런 점을 신경 쓰면 되는구나라고 생각할 지도 모르겠다. 오해 없기를 바란다. 지금 우리가 이야기하는 내용은 요구사항을 포함해서 소프트웨어 라이프 사이클 데이터 전체에 공통으로 해당하는 것이다. 데이터의 특성에 따라서 더 강조되는 부분이 다를 수 있겠지만 결국 소프트웨어 라이프 사이클 데이터가 무엇이든 여기서 이야기하는 특성을 모두 가지고 있어야 한다.

 

②     완전한(Complete)

 

사실 ‘완전한’이라는 단어 자체가 모호한 단어이다. 도대체 완전하다는 기준이 무엇인가? 그런 의미에서 DO-178 가이드라인에서는 다음과 같이 몇 가지 예를 들어서 추가 설명을 하고 있다.

 

-       필요한, 관련된 요구사항이나 설명이 될 수 있는 항목을 포함하는 경우

-       유효한 입력 데이터 범위를 지정하는 경우

-       라벨링을 통해서 형상을 명확하게 하는 경우

-       정확한 용어와 단위를 사용하는 경우

 

위의 내용은 결국 ‘불완전한’ 내용이 있을 경우 그 부분을 채워주는 것들이라고 볼 수 있다. 이런 식으로 ‘완전한’ 상태를 만들기 위해서 필요한 부분이 추가되어야 한다는 의미이다.

 

③     검증가능한(Verifiable)

 

앞서 예를 든 요구사항을 보게 되면 ‘검증가능한’의 의미가 쉽게 이해가 될 것이다. 처음 작성된 요구사항으로는 어떤 식으로 검증해야 할 지 아무도 정확하게 말할 수 없다. ‘모호한’ 부분이 포함되어 있기 때문이다. 하지만 그런 ‘모호함’이 해소된 수정된 샘플을 보면 정확도의 범위가 정의됨으로써 무엇을 어떻게 검증해야 할 지 알 수 있다.

 

여기서의 검증은 시험만을 의미하는 것은 아니다. 단순히 산출된 상태로 저장하는 데이터라고 해도 ‘검증가능한’ 특성을 가져야 한다. 이 경우에는 저장된 상태를 ‘확인’할 수 있는 특성을 가지는 것이라고 할 수 있다.

 

④     일관된(Consistent)

 

여기서 말하는 ‘일관성’은 데이터 자체의 충돌이 없는 것을 말한다. 요구사항으로 보자면 작성된 내용의 단어나 의미가 서로 상충되는 경우가 해당될 것이다. 단순 데이터의 경우라면 패키지 내부에 동일한 아이디의 데이터가 여러 개 저장되어 있는 경우를 예로 들 수 있을 것이다. 이런 식으로 일관성을 잃게 되면 그 데이터는 DO-178 뿐만 아니라 그 자체로 어디에서도 공식적인 의미를 가질 수 없을 것이다.

 

⑤     수정가능한(Modifiable)

 

‘수정가능한’ 특성은 말그대로 수정가능해야 한다는 뜻이다. 그것만 보면 별다를 게 없어 보이지만 수정가능하기 위해서는 기본적으로 앞서 언급된 것들이 갖춰진 데이터가 되어야 한다는 것이 중요하다. 이런 데이터의 경우에는 수정을 하더라도 그 전에 가지고 있던 특성을 그대로 유지할 가능성이 높다. 반대로 앞서 설명한 특성들을 제대로 가지고 있지 않은 경우라면 수정이 불가능할 가능성이 상당히 높아진다.

 

⑥     추적가능한(Traceable)

 

이 특성도 요구사항을 생각하면 이해가 쉬워진다. 즉, 소스코드가 있다면 설계문서에 정의된 하위레벨 요구사항으로 추적이 가능해야 하며 하위레벨 요구사항은 연결된 상위레벨 요구사항으로 추적이 가능해야 한다. 더 나아가서 상위레벨 요구사항은 그것과 연결된 시스템 요구사항으로 추적가능해야 한다. 이 과정에서 추적성을 찾을 수 없는 데이터가 있다면 DO-178 기준으로는 그 데이터는 의미 없는 데이터가 되는 것이다.

 

지금까지 소프트웨어 라이프 사이클 데이터가 갖추어야 할 특성들에 대해서 알아보았다. 다시 한 번 말하지만 당연할 수도 있는 내용을 가지고 이렇게 길게 설명하는 것은 실전에서 이런 부분이 소홀히 다루어 지는 경우가 많고 그로 인해서 실제 진행 과정에서 예상치 못했던 어려움을 겪는 것을 자주 목격했기 때문이다. 물론 필자도 과거에 그런 경험을 여러 번 겪었으며 아무리 이렇게 강조하더라도 처음 접하는 분들이라면 마찬가지의 시행착오를 거칠 수 밖에 없겠지만 적어도 나중에 이런 부분을 떠올릴 수 있다면 그것만으로도 의미가 있을 것이라고 생각된다.

 

(2)    소프트웨어 라이프 사이클 데이터가 갖춰야 할 형식(Forms)

 

앞에서 설명한 특성(Characteristics)에 이어서 나오는 부분은 데이터의 형식이다. 데이터의 형식과 관련해서 DO-178 관점에서는 아래 내용을 이해하는 것으로 충분하다.

 

-       데이터의 형태는 전자파일이 될 수도 있고 인쇄된 문서의 형태가 될 수도 있음

 

서두에 문서와 데이터에 대해서 이야기 한 것처럼 앞서 설명된 특성을 만족한다면 어떤 형식의 자료든 인정받을 수 있다는 것을 기억하자.

 

(3)    소프트웨어 라이프 사이클 데이터에 대한 형상 관리 컨트롤(Configuration Management Control)

 

이 부분은 앞서 살펴보았던 DO-178의 형상관리에 대한 부분 중 데이터 관리 범주(Data Control Category)인 CC1, CC2의 구분을 말한다. 소프트웨어 라이프 사이클 데이터가 만들어지게 되면 최소한 CC2에 해당하는 관리가 되어야 한다는 점을 기억하자. 참고로 그 부분에 대한 설명 중에 가능하다면 아예 가장 엄격한 기준인 CC1으로 통일하는 것이 오히려 더 효율적이라고 이야기한 부분도 참고하자.

 

(4)    소프트웨어 라이프 사이클 데이터의 내용(Contents)

 

여기서 설명하고자 하는 특성은 DO-178 인증을 위한 소프트웨어 라이프 사이클 데이터를 어떻게 작성하느냐에 관한 내용이다. 기본적으로 DO-178 가이드라인에서는 소프트웨어 라이프 사이클 데이터 각각에 대한 설명과 어떤 내용이 포함되어야 하는지를 자세히 설명하고 있기 때문에 어떻게 보면 가이드라인에서 설명하는 대로 작성하면 되지 않나라고 생각할 수 있다. 하지만 결론적으로 가이드라인은 그렇게 설명은 하고 있으면서도 그대로 작성하면 된다고 장담하고 있지는 않다. 솔직히 필자가 처음 그런 내용을 접했을 때는 마치 책임을 회피(?)하는 듯한 느낌이 들어서 좀 황당하다는 생각도 들었지만 이제는 가이드라인이 어떤 역할을 하는지를 이해하기 때문에 왜 그렇게 이야기하는 지를 충분히 이해하고 있다.

 

어쨌든 DO-178 가이드라인에서 제시하는 최선의 방법은 가이드라인에서 설명하는 소프트웨어 라이프 사이클 데이터의 각각에 대한 설명과 함께 그와 연관된 프로세스에 대한 설명도 함께 고려해서 작성을 하라는 것이다. 예를 들면 PSAC에 대해서 설명하고 있는 가이드라인 Section 11.1을 참고해서 PSAC을 작성하면서 아울러 그와 관련된 소프트웨어 라이프 사이클 프로세스 전체와 소프트웨어 인증 교섭 프로세스를 설명하고 있는 가이드라인의 내용을 참고하라는 것이다.

 

우리는 지금까지 DO-178 가이드라인에서 설명하고 있는 소프트웨어 라이프 사이클 프로세스 전반에 대한 부분을 살펴보았다. 이제 그것을 백그라운드로 해서 소프트웨어 라이프 사이클 데이터 자체에 대한 DO-178 가이드라인의 설명을 확인해 보자.