기술자료

자동차, 항공 전자, 의료 및 산업용 제어와 같은 많은 산업에서 애플리케이션 기능 안전 인증을 받는 것은 당연한 일입니다. 기능 안전 체크리스트를 완료하는 데 필요한 모든 프로세스와 테스트를 거치는 것은 전통적으로 매우 어려운 프로세스였지만 인증을 빠르게 추적할 수 있는 방법이 있습니다.

인증 속도를 높이기 위해 개발 프로세스를 조정할 수 있는 방법이 많지만 모든 것은 코드 품질에서 시작됩니다. 하지만 어떻게 코드 품질을 보장할 수 있을까요? 

코드 품질을 최대한 간단하게 업그레이드하여 기능 안전 인증을 빠르게 획득하는 방법을 소개합니다.

표준에서 도움 받기

C99의 코드 사양에 약 190개의 모호성이 있다는 것을 알고 계셨나요? 즉, C99에는 C 언어 사양에 명시되지 않은 190개의 구문적으로 합법적인 C 구성 요소가 있다는 것입니다. 실제로 C18로 이동하면 상황이 약간 더 나빠지고 다중 상속 및 가상 상속 개념을 도입하기 시작하는 C++에서는 더욱 그렇습니다. 물론 컴파일러는 소스를 구체적인 코드로 변환해야 하므로 코드의 의미에 대한 해석을 선택하여 실행해야 합니다.

실제적으로 이는 소스 코드를 다르게 해석하는 다양한 컴파일러를 얻을 수 있다는 것을 의미합니다. 고신뢰성 시스템에서 이는 악몽 같은 시나리오입니다. 특히 기능 안전 인증을 추구하는 많은 회사가 테스트의 용이성을 위해 여러 플랫폼에서 코드를 교차 컴파일하기 때문입니다. 상상할 수 있듯이 이는 코드의 반복성과 신뢰성을 증명하기 위해 이러한 모든 상황을 테스트해야 하기 때문에 인증을 받는 데 걸리는 시간에 정말 나쁜 영향을 미칠 수 있습니다. 이를 어떻게 극복할 수 있을까요? 간단히 말해서 코드에서 이러한 모호성을 피하는 것입니다. 하지만 어떻게 해야 할까요? MISRA와 같은 코딩 표준을 사용하면 코드에서 이러한 유형의 일반적인 함정을 피하도록 설계되었기 때문에 문제를 빠르게 해결할 수 있습니다. 또한 코드의 결함 수를 줄이기 위해 안전하고 신뢰할 수 있는 코딩 관행을 촉진합니다. 하지만 이러한 표준을 어떻게 따를 수 있을까요? 다행히도 기능 안전 표준은 이를 수행할 수 있는 방법을 제공합니다.

표준에는 코드 분석이 필요합니다.

거의 모든 기능 안전 표준은 코드에 대한 정적 분석을 요구하며, 코드에 대한 런타임(또는 동적) 분석을 강력히 권장합니다. 이러한 표준 중 가장 광범위한 표준은 일반적으로 안전 관련 시스템을 다루는 IEC 61508입니다. 해당 표준의 섹션 C.4.2에서 모호하고 위험한 동작을 제거하는 코딩 표준 없이 C를 사용하는 것은 안전 무결성 수준(SIL) 1 이상에서는 권장되지 않습니다. 즉, 제품에 대한 SIL 2-4 인증을 받으려면 정적 분석을 사용하여 코드를 더욱 견고하게 만들어야 합니다. 그 이유는 무엇일까요? 이러한 정적 분석 도구는 개발자가 MISRA와 같은 코딩 표준을 구현하도록 강제할 수 있습니다. 게다가 정적 및 런타임 분석은 특히 앞서 언급한 코딩 표준 모호성으로 인해 위험한 코딩 동작에 빠지고 있는 경우를 빠르게 지적하여 코드 품질을 높이는 데 도움이 됩니다.

그러나 이러한 유형의 자동화 도구를 사용하면 인증 일정에 큰 영향을 미칠 수도 있습니다. 많은 조직에서 구성하기 어렵고 사용하기 어려운 코드 분석 도구를 사용하는데, 이는 매일 밤 빌드의 일부로 빌드 서버에서 실행되도록 합니다. 이는 개별 개발자가 방금 작성한 코드에 문제가 있는 부분에 대한 즉각적인 피드백을 받지 못하기 때문에 실제로는 큰 도움이 되지 않습니다. 게다가 이러한 도구에서 나오는 경고 메시지는 이해하기 어렵고 개발자가 경고가 무슨 뜻인지, 경고를 없애기 위해 코드를 어떻게 수정할 수 있는지 알아내려고 시간을 낭비합니다. 개발 중에 코드 분석을 실행할 수 있고 공식 빌드에 체크인하기 전에 코드 분석을 실행할 수 있다면 결함이 전혀 발생하지 않은 것과 마찬가지입니다. 인증 기관에서 선호하는 낮은 결함 주입률을 얻을 수 있는데, 이는 매우 성숙한 개발 조직을 가지고 있다는 것을 의미하기 때문입니다.

코드 분석을 일상 워크플로의 일부로 만들기

저희는 다양한 산업 분야의 여러 회사를 만났고, 코드 분석 도구를 구성하고 사용하기 쉽게 만들수록 개발자가 도구를 사용할 가능성이 높아지고 따라서 더 빨리 이점을 얻을 수 있다는 것을 알게 되었습니다. 개발자 도구 상자의 일부로 이러한 자동화된 도구를 사용하면 애플리케이션을 작성하는 동안 코드 품질을 확인하고 개선할 수 있으며, 해당 코드 섹션이 무엇을 하는지, 시스템의 다른 모듈과 어떻게 상호 작용하는지 이해하는 "영역"에 있을 수 있습니다. 이를 효과적으로 수행하려면 도구를 일상 워크플로에 통합해야 합니다.

통합 코드 분석과 관련하여 다른 사람들이 말하는 내용을 살펴보니 Google에서 ACM 간행물에 코드 분석의 장점을 살펴보는 기사를 게재했습니다. 이 기사는 C, C++, Java를 포함한 전체 코드베이스에 대한 전체적인 관점을 취하지만 결과는 매우 명확합니다.

"컴파일러 오류는 개발 프로세스 초기에 표시되고 개발자 워크플로에 통합됩니다. Google에서 컴파일러 검사 세트를 확장하는 것이 코드 품질을 개선하는 데 효과적이라는 것을 발견했습니다.”

저자는 정적 분석 검사를 컴파일러 워크플로로 옮기고 오류로 표시하면 도구의 결과에 대한 주의가 크게 향상되고 궁극적으로 코드의 품질이 훨씬 높아졌다고 말했습니다. 이어서 그들은 최근에 컴파일러 오류를 겪은 개발자와 동일한 문제에 대한 수정 사항이 포함된 패치를 받은 개발자에게 보낸 설문 조사에 대해 이야기합니다.

"Google 개발자들은 체크인 코드에 대한 패치가 아닌 컴파일 시간에 플래그가 지정된 문제가 더 중요한 버그를 잡는다고 생각합니다. 예를 들어, 설문 조사 참여자들은 체크인 코드에서 발견된 21%에 비해 컴파일 시간에 플래그가 지정된 문제의 74%를 "실제 문제"로 간주했습니다."

이 기사는 또한 정적 분석 도구를 통해 커밋을 자동으로 실행하고 엔지니어에게 분석 대시보드를 보도록 요청했을 때 매우 소수의 엔지니어만이 이를 따랐다고 말하면서 코드 분석을 워크플로의 일부로 포함하는 것의 중요성에 대해 설명합니다. 컴파일 프로세스에서 즉각적인 피드백을 받으면 정적 분석을 사용하기가 더 쉬워지고 무시하기 어려워졌습니다. 따라서 그들은 모든 사람의 워크플로에 기본적으로 정적 분석을 통합하기로 했습니다. 그들은 코드 분석 도구가 성공하려면 개발자가 도구를 사용하는 데 이점이 있다고 느끼고 도구를 사용하는 것을 즐겨야 한다고 믿습니다.

하지만 워크플로에 코드 분석을 추가하면 어떤 종류의 결과를 기대할 수 있을까요? 기대할 수 있는 한 가지는 이 기사에서 설명한 대로 높은 코드 품질을 통해 버퍼 오버플로, 불법 포인터 등과 같은 악용을 배제할 수 있으므로 애플리케이션의 전반적인 보안이 향상된다는 것입니다. 이것 자체가 코드 분석을 사용하는 좋은 이유이지만,  "예방 1온스가 치료제 1파운드의 가치가 있다"는 격언을 사람들에게 설득하기 어려울 때가 있으며, 개발자와 관리자 모두에게 코드 분석의 장점을 설득하려면 더 중요한 결과가 필요합니다.

Stefan Wagner 등이 작성한 논문은 경험적 데이터를 사용하여 다양한 코드 기반에서 코드 분석 도구의 이점과 기존 테스트의 이점을 계산했습니다. 그들의 결과는 매우 의미심장합니다. 식별된 769개의 결함 중 76%는 코드 분석 도구로 발견되었고, 전통적인 테스트로는 4%에 불과했습니다(나머지 20%는 코드 검토로 발견). 테스트를 시작하기도 전에 버그의 75%를 제거할 수 있다면 소프트웨어에서 평균 장애 시간(MTTF) 목표를 얼마나 빨리 달성할 수 있을까요? 답은 "엄청나게 빠릅니다"입니다. 테스트에 드는 시간과 비용 절감만으로도 코드 분석 도구에 투자할 가치가 있으며, 출시 시간 절감은 말할 것도 없습니다. 이러한 유형의 프로세스는 기능 안전 인증 기관에서 선호하는데, 최종 제품에서 결함이 발생할 위험을 대폭 줄여주기 때문입니다.

고품질 코드로 기능 안전으로 가는 길을 가속화

기능 안전 인증으로 가는 길을 빠르게 하는 열쇠는 코드 품질을 개선하는 것입니다. 코드 품질을 개선하면 결함 주입률이 낮아져 소프트웨어 릴리스 기준에 더 빨리 도달할 수 있으며, 이를 통해 개발 조직이 기능 안전 인증 기관에 매우 성숙해 보일 수 있습니다. 애플리케이션에 얼마나 많은 결함이 남아 있는지 정확히 알 수는 없지만 코드 분석 도구를 조기에 자주 사용하면 그 수를 최소화할 수 있습니다.

작성자 :  Shawn Prestridge / FAE / IAR SYSTEMS US