2013년 07월호 지면기사
/ 글│윤 범 진 기자 <bjyun@autoelectronics.co.kr>
MISRA C는 ISO/IEC C 표준 9899:1990/1999를 기반으로 한다. 이 코딩 가이드라인의 목적은 명확하게 임베디드 장치에서 안전하고, 이식성이 좋고, 신뢰성 높은 코드를 만드는 것이다. 새로운 버전이 릴리스된 MISRA C에 대해 PRQA의 프랭크 반 덴 부켄(Frank Van Den Beuken) 컨설턴트와 이야기를 나눴다.
 |
| PRQA 프랭크 반 덴 부켄 선임 컨설턴트 |
Q. 자동차 산업에서 탄생한 MISRA C의 역사는.
A. MISRA C의 첫 버전은 1998년에 처음 나왔습니다. MISRA C는 포드와 로버가 협력해 탄생시켰습니다. 이들은 소프트웨어의 공통 규칙을 준수하고 코드를 공유하는 것을 목표로 코딩 표준을 만들었습니다. MISRA C의 최초 개정은 2004년에 있었습니다. 이때 표준이 확장됐고 Exemplar suite가 추가됐습니다. 이 Exemplar suite이 소스 코드 파일로 많은 사례가 들어갔습니다. 규칙준수(compliance)와 비규칙준수 코드 사례들이 실제로 들어가면서 툴 벤더나 고객들이 서로를 더 잘 이해할 수 있게 됐습니다. 가장 최근에 나온 버전은 MISRA C:2012로 올 3월 배포됐습니다. 10명으로 구성된 위원회를 통해 4년 만에 나왔습니다. MISRA C의 버전 업은 대략 7년 주기입니다. 그러나 사실 MISRA 2008 버전도 있습니다. 2008의 경우엔 C++에 대한 룰입니다.
Q. ISO 26262와 MISRA C는 어떤 관계인가.
A. C 언어는 불안정한 언어이지만 자동차 산업에서 널리 사용되고 있습니다. 차량용 소프트웨어에 대한 안전도가 갈수록 중요해지면서 자동차를 비롯해 우주항공, 철도, 국방 부분에서 사용하는 소프트웨어의 결함을 줄이고자 영국 자동차 산업 신뢰성 협회(Motor Industry Software Reliability Association, MISRA)가 처음으로 C 프로그래밍 언어에 대한 코딩 가이드라인을 발표했습니다. MISRA C는 ISO/IEC C 표준 9899:1990 /1999를 기반으로 합니다. 이 코딩 가이드라인의 목적은 명확하게 임베디드 장치에서 안전하고, 이식성이 좋고, 신뢰성 높은 코드를 만드는 것입니다. ISO 26262가 추구하는 방향은 MISRA C와 비슷합니다. 때문에 MISRA C는 강제사항이 아니라 옵션이지만 유럽 OEM은 이를 하나의 룰로 채택했고 ISO 26262에서도 이를 권장하고 있습니다.
Q. MISRA C는 얼마나 보편화됐나.
A. VDC 리서치는 2년 전 코딩 표준 채택과 관련된 백서를 하나 냈습니다. 임베디드, 엔터프라이즈 IT 회사에서 근무하는 600여명의 개발자를 대상으로 조사한 것인데, 대부분 응답자가 인하우스 표준을 사용하는 것으로 나타났습니다. 즉, 기업 내 랭기지 전문가가 있어 이들이 코딩 가이드라인을 만들고 이를 채택해 사용하고 있는 것입니다. 그러나 업계의 표준 중에는 MISRA C가 가장 많이 사용되는 것으로 나타났습니다. 물론, MISRA C가 자동차에서 시작됐지만 자동차에서만 사용되는 것은 아닙니다. 우주항공, 국방, 의료, 원자력, 철도 등 안전에 민감한 산업, 그리고 소비가전 등에서 사용되고 있습니다. 소비가전의 경우엔 기기의 품질과 관련한 기업의 이미지, 사후관리 비용 측면에서 수요가 높습니다. 한마디로 MISRA C는 모든 산업 분야에서 사용되고 있는 것입니다.
Q. PRQA의 국내외 위상은.
A. 1985년에 설립된 PRQA는 정적분석(static analysis) 산업의 개척자로 결함 검출과 코딩 표준 자동검사 툴의 글로벌 리더입니다. 우리의 QA C, QA C++, QA VERIFY 툴은 C와 C++에서 최선의 툴입니다. PRQA의 MISRA C 컴플라이언스 모듈, 툴은 시장의 사실상 표준입니다.
PRQA는 자동차 산업은 물론 우주항공, 국방, 교통, 소비가전 등 거의 모든 산업에서 4,400여개 기업을 고객으로 두고 있습니다. 이중 절반은 자동차 산업 기업들입니다. PRQA는 MISRA C 코딩 룰 부문 마켓셰어 1위 업체이고 한국의 자동차 산업 내에서도 독보적인 지위에 있습니다. 2006년 MDS테크놀로지가 총판을 하면서 현대·기아자동차의 코딩 룰에 채택됐고 이후 사업을 크게 확장하고 있습니다. 글로벌 2위 경쟁업체는 한국 자동차 산업 부문에서 활동을 하지 않습니다.
사실 2000년대 중반까지 한국의 자동차 산업은 MISRA C를 왜 적용해야하는지 몰랐습니다. 이전까지 내부 관리용으로 사용된 정도입니다. 그러나 최근에 ISO 26262 표준을 비롯해 해외 업체가 코딩 룰 리포트를 요구하면서 적용이 확대되고 있습니다. 한국의 메이저 회사들이나 Tier 1은 100% 적용하고 있고 Tier 2도 거의 다 사용하고 있는 상황입니다.
Q. MISRA C:2012와 이전 버전 간 차이점은.
A. MISRA C:2012는 2004보다 커졌습니다. 규칙이 142개에서 159개로 늘었고 내용도 더 좋아졌습니다. 문구가 바뀌고 설명이 더 들어갔으며 룰 넘버링도 바뀌었습니다. 그러나 가이드라인은 거의 바뀌지 않았습니다. MISRA 웹 사이트에 가보면 2004와 2012 버전 간 규칙을 서로 매핑해주는 문서가 있습니다. 혹시 MISRA C:2004를 사용하고 있고 2012로 업그레이드를 고려하고 있다면 이 문서를 찾아보기 바랍니다.
레거시 코드는 호환되지 않습니다. 예를 들어 소프트웨어가 10만 개의 라인을 갖고 있으면 1만 여개의 MISRA 바이얼레이션이 있을 것입니다. 즉, 1만 개의 메시지를 고친다면 어딘 가에서 실수가 있을 것입니다. MISRA 위원회는 이 표준을 기존의 코드에 적용하려하지 않고 새로 작성한 코드에만 적용하는 것을 목표로 했습니다. 다만 2012 표준에는 그래도 레거시 코드에 대한 언급이 있습니다. 새로운 요구사항은 많지 않고 일부 제약사항이 제거됐습니다. PRQA의 제품 중에는 레거시 코드와 관련 도움을 줄 수 있는 제품이 있습니다. 코드가 과거부터 있었던 것인지, 새로운 코드인지를 판단하는 제품입니다.
Q. ISO C와 MISRA의 관계는.
A. MISRA C는 다양한 ISO C 언어를 지원합니다. ISO C의 첫 번째 표준 버전은 1990년도에 릴리스됐습니다. ISO:C90은 컴파일러나 툴에 의해 잘 지원받고 있습니다. 그러나 모든 컴파일러들이 C 표준을 체크하지는 않습니다. 완벽히 지원하는 것이 아닙니다. 거의 모든 경우에서 일부 옵션을 인에이블링 시켜서 체크하게 만들어야합니다. ISO:C90은 언어가 가지고 있는 위험들을 충분히 이해하고 있습니다. 제약 요소가 있다면 불리언(Boolean) 타입이 없다는 점입니다. C90은 파이프 시스템 자체에 문제가 있지만 이런 문제는 충분히 이해되고 있고 이를 해결할 솔루션도 있습니다. 그중 하나가 바로 MISRA C 표준입니다.
ISO:C99는 불리언 타입이 포함됐고 인라인 펑션도 허용됩니다. 이러한 특징은 C++ 랭기지와 GCC와 같이 많이 사용되는 컴파일러에서 비롯됩니다. 그런데 랭기지 자체는 C90에 비해 정립되지 않은 behaviour가 많아 위험한 부분이 많습니다. 코드의 의미가 무엇인지를 알려주지 않는 undefined behavior는 큰 문제입니다. 이는 코드에서 절대 있어서는 안 되는 것입니다. ISO:C11은 새로운 언어이고 아직 툴 지원도 제한적입니다. 따라서 사용을 권하지 않습니다. MISRA C:1998, MISRA C:2004, MISRA C:2012 모두는 ISO:C90 사용을 허용합니다. MISRA C:2012는 ISO:C99 사용까지 허용합니다.
Q. 좀 더 자세하게 MISRA C:2012의 특징을 설명하면.
A. MISRA C:2012는 이전 버전과 비교해 용어상 변화가 있습니다. 과거에는 용어들의 의미가 애매모호했습니다. C 언어의 타입은 다양한 의미를 내포하고 있고 이는 문제가 될 수 있습니다. 때문에 MISRA C:2004에는 underlying과 complex expression이란 타입 개념이 도입됐습니다. 하지만 이 용어들의 정의가 모호하고, 개념은 signed, unsigned 정수까지만 의미했습니다. 또 underlying type 용어는 C++에서 다른 의미로 사용됐고 complex는 일반적으로 C99에서 지원되는 대수인 complex arithmetic을 의미하는 데 사용됐습니다. 결국 MISRA C:2012에서 underlying 타입은 essential 타입으로 부르기로 했습니다. complex expression은 composite expression으로 대체됐습니다. essential 타입은 코딩 규칙의 정의에서 산술 표현의 타입을 설명할 때 더욱 직관적입니다. 불리안 쪽에서는 같은 이유에서 effectively 불리안이 아닌 essentially 불리안으로 바뀌었습니다. ISO에서 사용되는 용어들과 확연히 구분되게 됐습니다.
가이드라인은 Directive와 Rule 두 종류가 있습니다. 카테고리는 Advisory, Required, Mandatory 세 가지이고, 언어는 C90, C99, C90·C99이 있습니다. 결정가능성은 두 가지, 분석 범위는 Single Translation Unit과 System이 있습니다. 룰은 요구사항이 명확하게 정의됐고, Directive는 프로세스나 문서 관련 요구사항을 다룹니다.
그런데 Directive는 룰만큼 정의가 명확하지 않습니다. 때문에 다양한 방식으로 해석됩니다. Directive는 프로세스나 문서 관련 요구사항을 다룰 수도 있습니다. 코드와 관련된 것이 아니라 코드를 쓰기 위해 사용한 프로세스나 무엇인가를 입증하기 위해 작성한 문서와 관련된 것일 수 있습니다. 대표적 룰로 8.5나 11.3 등이 있습니다. 8.5는 “external object 또는 function은 단 한 번, 단 하나의 파일에서만 공표되면 된다”고 매우 명확히 돼 있습니다. 반면에 Directive는 3.1, 4.3이 좋은 예인데, 3.1은 “모든 코드는 문서화된 요구사항에 추적 가능해야한다”고 명시합니다.
중요한 가이드라인 카테고리를 보면, 첫째 Advisory guideline이 있는데 이는 권고사항에 가깝습니다. 사용자가 비규칙 준수를 선택할 수 있습니다. 다만 규칙을 따르지 않았다는 내용을 문서화해야합니다. 따르지 않은 이유를 합리화할 필요는 없습니다. Required guideline은 규칙을 따르지 않기로 했다면 어떤 공식적인 문서를 만들어야만 합니다. Mandatory guideline은 반드시 준수해야하고 규칙준수는 항상 이뤄져야합니다. deviation이 허용되지 않습니다. MISRA C:2004에서는 모든 가이드라인에서 deviation이 허용됐었습니다.
룰 12.4와 13.5는 결정가능(decidable)하든지, 그렇지 않든지 둘 중 하나에 대한 것입니다. 결정 가능하다는 것은 어떤 프로그램에서든지 툴이 규칙을 준수하는 지, 안하는 지를 항상 결정할 수 있다는 것이다. 그렇지 않다면 전부 결정 가능하지 않다는 것입니다. 결정 가능하다는 것은 소스 코드를 보며 자동으로 체크가 가능하다는 뜻입니다.
Analysis scope는 두 가지 타입이 있습니다. Single Translation Unit 룰은 소스 파일을 보며 결정을 할 수 있습니다. 파일에서 괜찮은지 않은지를 판단할 수 있습니다. System 룰은 모든 소스 파일을 함께 봐야하고 규칙준수 여부를 알 수 있습니다. Single Translation Unit이 있다면 봐야하는 파일이 많지 않아 체크가 쉽습니다.
Q. MISRA C에 대한 다양한 툴이 있을텐데.
A. 테라랩스(TERA-Labs)는 9개의 상용 정적분석 툴을 비교했는데 문헌상으로는 툴들이 포괄적인 MISRA C 규칙준수를 체크한다고 나와 있지만 현실은 그렇지 않다고 보고했습니다. 여기서 툴별 점수를 밝혔습니다. 11개 룰을 선택하고 규칙 별로 툴이 메시지를 체크하고 바이얼레이션을 체크했습니다. 테라랩스는 9개의 툴이 발견한 바이얼레이션 메시지, 트루 메시지를 봤습니다. 메시지의 25%만이 트루 메시지였는데 이것이 정적분석의 문제입니다. 개발자들은 이런 상태에선 툴을 신뢰할 수 없습니다. 9개 툴 중에서 가장 신뢰할 수 있는 툴은 PRQA의 QA C였습니다.
PRQA의 QA C의 가장 큰 장점은 코드에 대한 오검출률이 낮다는 것입니다. 다른 툴은 오류가 아닌데도 검출하는 오검출이 많습니다. 또 일부 오류를 검출하지 못합니다. QA C는 가장 많은 오류를 정확하게 검출할 수 있습니다. 우리는 코드 표준을 준수하기 위해 많은 노력을 기울이고 있습니다. ISO 기준을 맞춰 가는데 엄격하게 임하고 있습니다.
결정적으로 경쟁사 대비 MISRA 오검출이 적은 이유는 MISRA가 PRQA가 개발한 코딩룰을 그대로 가져가 사용하기 때문입니다. 우리는 여전히 MISRA 위원회의 중요 일원으로 활동하고 있습니다.
Q. QA VERIFY는 어떤 툴인가.
A. Deviation은 MISRA C의 중요한 부분이며 종종 필요합니다. 왜냐면 속성들이 서로 컴플리팅하는 경우가 있기 때문입니다. 퍼포먼스 목표를 달성해야하는데 리더빌리티, 유지보수성 등 다른 품질 속성과 상충되는 경우가 있어 이런 경우 deviation을 활용해서 실행 조치를 합리화할 필요가 있습니다. MISRA에는 승인된 deviation 규칙준수 절차가 있고 감사관에게 입증해야합니다. PRQA의 QA VERIFY는 deviation을 지원해줍니다. 모든 메시지별로 서프레스 옵션이 있어서 어떤 메시지를 suppression하거나 deviation을 생성하거나 재사용할 수 있습니다. 코드와 함께 사용하기 때문에 suppression과 deviation 하기 쉽고 리포트를 모두 볼 수 있습니다. 코드 내에 코멘트를 달 수도 있습니다.
우리는 QA C 등 툴 개발에서 표준, 컴파일러, 툴 변화를 관심 있게 보고 있고, 실제 개발자들의 요구사항을 분석해 다음 버전을 릴리즈 할 때 적합성을 판단 개선하는데 심혈을 기울이고 있습니다. ISO C 표준을 따르려하고 있고 고객들의 반응을 수렴하려하고 있습니다. AE
<저작권자 © AEM. 무단전재 및 재배포, AI학습 이용 금지>
