11. DO-178과 커버리지 분석 – Structural Coverage of Object Code

cast-17.pdf

앞서 우리는 ①소스코드를 이용한 커버리지 분석과 ②소스코드와 오브젝트 코드를 연계한 커버리지 분석에 대해서 알아보았다. 이번 절에서는 ③오브젝트 코드를 이용한 커버리지 분석에 대한 내용이다. 이에 대해서 FAA에서 발행한 문서로 CAST-17이 있다.

 

그림 16 CAST-17

 

앞서 구조적 커버리지 분석은 소스 코드, 오브젝트 코드 혹은 실행가능한 오브젝트 코드상에서 수행될 수 있다고 설명한 바가 있다. CAST-17은 그 중 오브젝트 코드를 이용한 구조적 커버리지 분석에 대한 내용을 담고 있다. 혹시 착각하시는 분이 있을지 몰라서 다시 한 번 강조하자면 소스 코드가 아닌 오브젝트 코드이다.

 

사실 지금까지 살펴본 것처럼 기본적으로 구조적 커버리지 분석을 수행하는 것은 결코 쉽지 않은 일이다. 그나마 소스 코드를 기반으로 한 구조적 커버리지 분석은 지금까지 꾸준하게 시도되어 왔고 그것을 지원하는 툴도 제법 다양하게 존재하기 때문에 적어도 시도해 볼 여지는 있다고 할 수 있다.

 

그런데 여기서 설명하는 것은 오브젝트 코드를 기반으로 한 구조적 커버리지 분석에 대한 것이다. 사실 필자는 이것을 지원하는 툴이 있다는 이야기를 아직까지는 들어본 바가 없다. 또한 실제로 어떻게 수행하는지 전혀 알지 못한다. 실제 진행하는 것을 경험한 적도 없고 지금 설명하는 CAST-17이외에는 관련된 자료를 본 적도 없다.

 

그래서 이것을 여기에서 소개하는 것이 실효성이 있을까 싶은 생각이 들었지만 일단 CAST-17 자체가 구체적인 방법론을 설명하는 것이 아니고 오브젝트 코드를 기반으로 한 구조적 커버리지를 인증 당국의 관점에서 어떻게 바라보고 있는지를 주로 설명하고 있기 때문에 그런 부분을 통해서 구조적 커버리지 분석에 대한 이해를 높이는 데 도움이 될 수 있지 않을까 싶은 생각에 추가하게 되었다.

 

(1)   CAST-17 문서의 성격

 

CAST-17이라는 문서는 오브젝트 코드를 기반으로 한 구조적 커버리지 분석을 대상으로 작성된 것이긴 하지만 실제 수행 방법이나 과정에 대해서 설명하는 것은 아니다. 대신 인증 당국의 입장에서 그것을 어떻게 보아야 하는지, 무엇에 관심을 가져야 하는지를 주로 설명하고 있다. 아래는 문서의 서두에서 언급하고 있는 이 문서의 목적에 대한 설명이다.

 

해석을 보자.

 

이 페이퍼의 목적은 특별히 레벨 A 소프트웨어에 대해 소스 코드 레벨에서 보다는 오브젝트 코드 레벨에서 구조적 커버리지 분석에 관한 인증당국의 우려와 위치에 대해서 나타내는 것이다.

 

인증당국의 ‘우려’와 ‘위치’라는 단어가 현재로서는 와닿지 않는 부분이겠지만 이어지는 설명을 통해서 어느 정도는 확인할 수 있을 것이다. 앞서도 잠시 언급했지만 이것을 이해하는 것이 지금 당장은 우리에게 쓸모가 있는 부분이 아닐 지 모르겠지만 기존에 가지고 있던 구조적 커버리지 분석에 대한 이해를 좀 더 높일 수 있고 실제 진행 과정에서 또 다른 선택지가 될 수 있는 부분이어서 그런 면에서는 충분한 가치를 가지고 있는 문서로 이해하고 이어지는 내용들을 살펴보자.

 

(2)   오브젝트 코드 기반의 구조적 커버리지 분석과 관련된 배경 설명

 

CAST-17 문서를 전체적으로 보면 기본적으로 FAA에서는 구조적 커버리지 분석을 소스 코드를 기반으로 수행하는 것에 기준을 두고 있다는 느낌을 받게 된다. 그래서 오브젝트 코드를 기반으로 한 구조적 커버리지 분석을 소스 코드를 기반으로 한 구조적 커버리지 분석과 비교하는 부분이 많다. 아래의 설명을 보면 인증당국이 왜 소스 코드를 기반으로 한 구조적 커버리지 분석과 함께 오브젝트 코드를 기반으로 한 구조적 커버리지 분석에 관심을 가지게 되었는지를 알 수 있다.

 

해석을 보자.

 

최근에, 여러 지원자들이 전통적인 소스 코드 레벨 대신에 오브젝트 코드 레벨 (혹은 가능하다면 어셈블리 언어 코드 레벨)에서 구조적 커버리지 분석을 수행함으로써 DO-178B/ED-12B [2] Table A-7 (MC/DC)의 목표 #5를 만족하는 것을 제안해왔다. 다른 사람들은 오브젝트 코드 레벨 구조적 커버리지 분석이 또한 레벨 B와 레벨 C에도 적용 가능하다고 제안해 왔다.

 

소스 코드 기반의 구조적 커버리지 분석이 ‘전통적인’ 방법이라고 언급하면서 최근 들어서 (문서작성 시점 기준 2003년) 그것을 대신하는 방법으로 오브젝트 코드 레벨 구조적 커버리지 분석이 새로운 방법으로 제시되고 있다는 점을 설명하고 있다.

 

소스 코드 기반의 구조적 커버리지 분석에서는 컴파일러를 통해서 추가될 수 있는 소스 코드에 대한 추가적인 분석이 필요할 수 있다고 설명한 바가 있다. 바로 ‘Source Code to Object Code Traceability’이다. 오브젝트 코드 기반의 구조적 커버리지 분석 역시 컴파일러의 영향을 받을 수 있다. 즉, 코드 최적화나 컴파일러 옵션 혹은 컴파일러 자체의 특성에 따라서 소스 코드가 추가되면서 그 상태로 오브젝트 코드가 생성됨으로써 영향을 주게 되는 것이다. 결국 컴파일러가 오브젝트 코드 기반의 커버리지 분석에서도 영향을 준다는 점은 이해하고 있어야 한다.

 

오브젝트 코드 기반의 구조적 커버리지 분석에 있어서 또 하나 고려할 수 있는 부분이 바로 컴파일러를 검증도구로 사용할 수 있다는 부분이다. 필자가 처음 이 부분을 접했을 때는 잘못 본 게 아닌가 싶은 생각이 들 정도로 생소한 개념이었다. 개발도구의 핵심이라고 할 수 있는 컴파일러를 검증도구로 사용한다? 이에 대한 설명을 위해서 CAST-17에서는 다음과 같은 예를 들고 있다.

 

해석을 보자.

 

l  코드 리뷰 체크리스트로부터 해당하는 항목들을 배제하기 위해서 통과되는 모든 파라미터들이 올바른 타입인지, 모든 배열 인덱스가 범위 안에 있는지 등을 컴파일러가 체크하는지를 보증 l  소스코드와 오브젝트 코드의 추적성 분석 활동을 수행하는 것을 피하기 위해 컴파일러가 추적이 불가능한 오브젝트 코드를 추가하지 않는다는 것을 보증

 

사실 컴파일러를 이용해서 위와 같은 결과를 보여줄 수 있다면 비록 개발도구인 컴파일러라고 하더라도 검증도구로 활용되는 것으로 볼 수 있다. 다만 문제는 실제로 컴파일러를 그러한 목적에 맞게 툴인증(Tool Qualification)을 받을 수 있느냐이다.

 

CAST-17이 구체적인 방법을 제시하는 것이 아니라 일종의 개념적인 설명을 제시하는 문서이기 때문에 이에 대해서는 이런 개념이 있다는 정도로만 이해하고 넘어가자.

 

(3)   오브젝트 코드 기반의 구조적 커버리지 분석이 인정받은 이유

 

비록 오브젝트 코드 기반의 구조적 커버리지 분석이 전통적인 방식의 소스 코드 기반 구조적 커버리지 분석과는 많은 차이점을 가진 새로운 방식이지만 CAST-17에서는 다음과 같은 여러가지 이유로 활용 가능성을 인정하고 있다.

 

-       그 동안 구조적 커버리지 분석 툴이 발전해 왔고 이런 접근을 지원할 수 있다.

-       요구사항 기반 시험을 자동화하고 오브젝트 코드상에서 시험이 수행되는 동안 구조적 커버리지 정보를 모으는 데에 발전이 있어왔다.

-       오브젝트 코드에 대한 소스 코드 추적성이 어렵고 일치되지 않을 수 있다.

-       적절하게 수행된다면 오브젝트/어셈블리/기계어 코드 레벨에서 전체 코드 커버리지를 증명할 수 있다.

-       소스 코드보다 설치되어야 하는 최종 항공 소프트웨어에 더 가까운 코드의 “추상화”에 기반해서 시험과 커버리지 분석이 수행됨으로써 더 “유효한” 커버리지를 지원할 수 있다.

-       소스 코드 프로그래밍 언어 독립적으로 실행될 수 있다.

-       시간이 걸리는 수동 분석을 줄여줄 수 있다.

-       Instrumentation이 필요하지 않을 수 있다.

 

이상의 내용만 보자면 소스 코드 기반의 구조적 커버리지 분석에 비해서 상당한 장점을 가지고 있는 것으로 보인다. 하지만 결국 문제는 실제로 수행할 수 있느냐가 관건이다. 계속 이야기하는 부분이지만 여기서는 그 부분까지는 설명하지 않는다.

 

(4)   오브젝트 코드 기반의 구조적 커버리지 분석에 대해서 인증당국이 우려하는 부분

 

이처럼 장점이 많은 방법이지만 한편으로는 상대적으로 새로운 방법이다 보니 불확실한 부분도 많은 것이 사실이다. 여기서는 인증당국의 관점에서 걱정되는 부분을 살펴보자. 우선 현재까지 지원자들이 오브젝트 코드 기반의 커버리지 분석의 적절성을 증명하기 위해 제시한 방법들이 몇 가지가 있다.

 

-       엄격한 설계와 코딩룰의 적용

-       컴파일러의 일부를 인증

-       설계와 코딩룰을 제대로 따랐음을 증명할 추가적인 오브젝트 코드 리뷰 혹은 분석 수행

-       이러한 방법들을 조합

 

부가 설명이 있긴 하지만 핵심만 정리하자면 위와 같다. 그런데 각각의 방법에는 저마다의 부족한 점을 가지고 있는 것도 사실이다. CAST-17에서는 그 중에서도 크게 다음과 같은 2가지를 들고 있다.

 

①     컴파일러 동작(Operation)에 대한 가정이 있음

 

다들 아는 것처럼 컴파일러는 상당히 복잡한 소프트웨어이다. 컴파일러의 입력으로 소스 코드가 들어가면 출력으로 오브젝트 코드가 나오게 되는데 입력과 출력의 상이함만 보더라도 그 사이에 우리가 상상할 수 없는 많은 부분이 변경된다는 것을 짐작할 수 있다. 그렇다면 그 사이의 변경에 오류가 없다는 것을 어떻게 보장할 수 있을까?

 

앞서 잠시 언급된 바가 있지만 엄격한 코딩룰을 적용해서 코딩을 하게 되면 출력에 대해서 일관성을 보장할 수 있지 않을까라고 생각할 수 있다. 하지만 현실적으로 그것은 희망사항일 뿐이다. 아무리 코딩룰을 완벽하게 만든다고 하더라도 하나의 시스템 전체가 일률적인 코딩룰에만 한정해서 소스 코드를 작성하는 것은 애초에 불가능하다. 이처럼 컴파일러를 통해서 진행되는 변경과정에 대한 무결성을 증명하는 것은 현재로서는 불가능하다고 할 수 있다. 컴파일러 동작에 대한 가정이 있다는 것은 바로 이것을 말하는 것이다.

 

②     컴파일러가 만들어내는 출력(Output)에 대한 검증이 이루어 지지 않음

 

앞서 설명한 것처럼 컴파일러 동작에 대한 가정이 있다는 것은 결국 그 출력에 그 가정이 포함되어 있다는 의미이다. 그렇다면 이러한 가정에 대해서 체크를 해야 한다. 그런데 실제 현장에서는 그런 활동이 이루어지지 않는 경우가 많다. CAST-17에서는 다음과 같이 설명하고 있다.

 

해석을 보자.

 

기본적으로, 컴파일러의 출력에 대한 가정이 만들어지고 있다. 그러나 일반적으로 개발자는 오브젝트 코드에 대한 소스 코드 추적성을 수행하지 않거나 컴파일러가 가정한 대로 동작한다는 것을 결정할 (혹은 그러한 컴파일러 기능을 증명하는) 컴파일러 기능의 설계 리뷰를 수행하지 않는다.

 

원칙적으로는 오브젝트 코드 기반의 추적성 커버리지 분석을 수행하는 경우에도 위에서 설명하는 추적성 분석이 완전하게 수행되어야 한다. 혹은 컴파일러 기능에 대한 설계 리뷰를 수행함으로써 부족한 부분을 커버할 수도 있다. 하지만 현실에서는 그런 활동이 거의 이루어지지 않는다는 것을 FAA에서도 충분히 인지하고 있다는 것을 알 수 있다.

 

이상의 2가지 이외에도 인증당국의 관점에서 보게 되는 여러가지 문제점이 있을 수 있다. CAST-17의 목적은 어쩌면 바로 그런 부분을 제시하고 무엇을 체크해야 하는 지를 설명하는 문서라고도 할 수 있다. 다음 단락에서 그런 부분들을 전체적으로 정리해 본다.

 

(5)   오브젝트 코드 기반의 구조적 커버리지 분석에 대한 주요 이슈

 

지금까지 많은 설명이 있었지만 결국 오브젝트 코드 기반의 구조적 커버리지 분석이 인정을 받기 위해서는 전통적인 방법이라고 할 수 있는 소스 코드 기반의 구조적 커버리지 분석과 동등한 결과를 보여주면 된다. 그것은 결국 DO-178 인증을 위한 구조적 커버리지의 목표를 준수하는 것이다. 이를 위해서 다음과 같은 이슈들이 체크되고 설명될 수 있어야 한다.

 

-       소스 코드 기반에서 필요로 하는 것과 동일한 최소한의 시험 케이스를 생성해야 함

-       커버리지 분석을 위해 사용되는 시험 케이스는 요구사항으로부터 만들어 져야 함 (모듈 기반의 “구조적 시험”은 사용되어서는 안됨)

-       소스 코드 기반과 동등한 수준을 강요하는 설계와 코딩룰이 설계 및 코딩 표준, 검증 체크리스트 등에 사용되어야 하며 엄격하게 따라야 함

-       컴파일러 동작의 가정을 모두 입증할 수 있도록 데이터가 제공되어야 함

-       오브젝트 코드의 분석 혹은 툴에 대한 인증(Qualification)이 필요할 수 있음

-       오브젝트 코드, 소스 코드, 설계, 그리고 요구사항에 대한 추적성이 존재해야 함

-       아키텍처와 복잡도 제약이 문서화되고 따라야 함

-       오브젝트 코드 기반이든 그렇지 않든 커버리지 분석이 수행되는 경우에는 Data Coupling과 Control Coupling 분석이 수행되어야 함

-       커버되지 않는 오브젝트 코드가 있는 경우 그것을 입증할 데이터가 있어야 함

-       오브젝트 커버리지 접근에서 문제를 일으킬 수 있는 알려진 영역에 대한 질문이 있어야 함 (세부 질문 항목은 여기서 생략한다. 궁금한 분은 CAST-17 원문을 참조하자)

 

막상 CAST-17의 내용을 모두 작성하고나서 보니 필자가 보기에도 불가능한 이야기를 의미없이 나열해 놓은 게 아닌가 싶은 생각이 든다. 하지만 다시 한 번 말하자면 CAST-17이라는 문서는 개념적인 이해를 돕기 위한 의미가 더 크기 때문에 비록 지금은 이해가 안되더라도 추후 구조적 커버리지 분석에 대해서 어느 정도 이해가 된 상태라면 그 이해도를 더욱 더 넓힐 수 있는 참고자료로써는 충분히 역할을 할 것으로 믿는다.