프로젝트를 위한 신속한 기능 안전 인증

개발 프로세스를 수정하여 인증 시간을 단축할 수 있는 방법은 많지만, 모든 작업은 코드 품질에서 시작됩니다. 하지만 코드 품질을 어떻게 보장할 수 있습니까? 다행히도, 코드 품질 게임을 최대한 적은 고통으로 거의 즉각적으로 업그레이드할 수 있는 몇 가지 쉬운 방법이 있습니다.

표준을 참고하기

C99에는 코드 사양에 190가지 정도의 모호성이 있다는 것을 알고 있습니까? 우리가 의미하는 것은 C99에는 C 언어 규격에 명시되지 않은 190개의 구문상 합법적인 C 구문이 있다는 것입니다. C++에서는 다중 및 가상 상속 개념을 도입하기 시작할 때 C18로 이동하면 상황이 더 악화됩니다. 물론 컴파일러는 소스를 구체적인 코드로 변환해야 하므로 코드의 의미에 대한 해석을 선택하여 실행해야 합니다.

즉, 소스 코드를 다르게 해석하는 컴파일러를 여러 개 얻을 수 있습니다. 신뢰성이 높은 시스템에서는 특히 기능 안전 인증을 추구하는 많은 기업들이 테스트의 용이성을 위해 여러 플랫폼에서 코드를 크로스 컴파일하고 있기 때문에 이는 악몽 같은 시나리오입니다. 보시다시피, 코드 반복성과 신뢰성을 입증하기 위해 이러한 모든 상황을 테스트해야 하기 때문에 인증 획득에 걸리는 시간에 매우 나쁜 영향을 미칠 수 있습니다. 어떻게 극복해야 할까요? 간단한 대답은 코드의 이러한 모호함을 피하는 것입니다. 하지만 그걸 어떻게 하죠? MISRA와 같은 코딩 표준을 사용하는 것은 코드 내의 일반적인 함정으로부터 사용자를 보호하도록 설계되었기 때문에 문제를 신속하게 해결할 수 있는 방법입니다. 또한 코드의 결점 수를 줄이기 위해 안전하고 신뢰할 수 있는 코딩 관행을 장려합니다. 하지만 어떻게 우리가 그 기준을 따르는지 확인할 수 있을까요? 다행히 기능 안전 표준이 우리에게 이것을 할 수 있는 방법을 알려드립니다.

표준은 코드 분석을 필요로 합니다

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

그러나 이러한 유형의 자동화된 도구를 사용할 경우 인증 시간에도 큰 영향을 미칠 수 있습니다. 많은 조직에서는 야간 빌드의 일부로 빌드 서버에서 실행하도록 밀려난 구성 및 사용이 어려운 코드 분석 도구를 사용합니다. 개인 개발자가 방금 작성한 코드의 문제점에 대해 즉각적인 피드백을 받지 못하기 때문에 이 방법은 그다지 도움이 되지 않습니다. 게다가, 때때로 이러한 도구에서 나오는 경고 메시지는 이해하기 어렵고 개발자의 시간을 낭비하여 어떤 의미인지, 어떻게 코드를 수정하여 경고가 사라지게 할 수 있는지 알아냅니다. 개발 중에, 그리고 정식 빌드에 체크인하기 전에 코드 분석을 실행할 수 있다면, 이는 마치 결함이 전혀 발생하지 않은 것과 마찬가지입니다. 귀사는 매우 성숙한 개발 조직을 보유하고 있기 때문에 인증 기관에서 자주 볼 수 있는 프로젝트에 대한 결점 주입률이 낮아집니다.

일별 워크플로우의 일부로 코드 분석 하기

동료들과 저는 여러 업종에서 많은 다양한 기업을 만났는데, 코드 분석 도구를 쉽게 구성하고 사용할수록 개발자가 이를 사용할 가능성이 높아져 더 빨리 혜택을 볼 수 있다는 점에 주목했습니다. 이러한 자동화된 도구를 개발자의 도구 상자의 일부로 사용하면 프로그램 작성 시 코드 품질을 확인하고 개선할 수 있으며, 코드의 해당 섹션이 무엇을 의미하는지, 시스템의 다른 모듈과 어떻게 상호 작용하는지를 이해하는 "영역"에 있을 수 있습니다. 이를 효과적으로 수행하려면 도구를 일별 워크플로우에 통합해야 합니다.

통합코드 분석과 관련하여 다른 사람들이 말하는 내용을 살펴보니 구글이 ACM 출판물에 코드 분석의 장점을 살펴보는 기사를 실었다는 것을 알게 되었습니다. 이 문서는 C, C++, Java를 포함한 전체 코드베이스를 전체적으로 살펴보지만, 그 결과는 매우 명확합니다:

"컴파일러 오류는 개발 프로세스 초기에 표시되고 개발자 워크플로우에 통합됩니다. 컴파일러 검사 세트를 확장하는 것이 Google의 코드 품질 향상에 효과적이라는 것을 알게 되었습니다."

저자들은 정적 분석 검사를 컴파일러 워크플로우로 옮기고 이를 오류로 보이게 함으로써 도구의 발견에 대한 주의를 크게 개선했으며 이는 궁극적으로 코드가 훨씬 더 높은 품질의 것을 의미한다고 말했습니다. 또한 최근에 컴파일러 오류가 발생한 개발자와 동일한 문제에 대한 수정 패치가 적용된 개발자에게 보낸 설문 조사에 대해 설명합니다:

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

이 기사에서는 정적 분석 툴을 통해 자동으로 커밋을 실행하고 엔지니어를 초대하여 분석 대시보드를 살펴보도록 함으로써 코드 분석 워크플로우의 일부를 갖는 것의 중요성에 대해서도 설명합니다. 컴파일 프로세스에서 즉각적인 피드백을 제공하므로 정적 분석을 더 쉽게 사용할 수 있고 무시하기가 더 어려웠습니다. 따라서 모든 사용자의 워크플로우에서 기본적으로 정적 분석을 통합하도록 선택했습니다. 이들은 코드 분석 툴이 성공하려면 개발자가 자신이 사용하는 이점을 누리고 도구를 사용하는 것을 즐긴다고 생각합니다.

하지만 워크플로우에 코드 분석을 추가하면 어떤 결과를 얻을 수 있을까요? 이 기사에서 설명한 것처럼 높은 코드 품질을 가지면 버퍼 오버플로, 불법 포인터 등과 같은 공격이 제거될 수 있으므로 애플리케이션의 전반적인 보안 향상을 기대할 수 있습니다. 이 자체가 코드 분석을 사용해야 하는 훌륭한 이유이기도 하지만, "예방 1온스가 치료제 1파운드의 가치가 있다"는 격언을 사람들에게 납득시키기 어려울 때가 있으며, 개발자와 경영진 모두에게 코드 분석의 장점을 납득시키려면 더 중요한 결과가 필요합니다.

Stefan Wagner 및 기타 연구진이 작성한 논문은 경험적 데이터를 사용하여 다양한 코드 기반에서 코드 분석 도구와 기존 테스트의 이점을 계산했습니다. 확인된 결함 769개 중 76%가 코드 분석 도구에 의해 잡히고 4%만이 기존 테스트에 의해 발견되었습니다(나머지 20%는 코드 검토에 의해 발견됨). 테스트를 시작하기 전에 75%의 버그를 제거할 수 있다면 소프트웨어에서 MTTF(평균 장애 시간) 목표를 얼마나 빨리 달성할 수 있습니까? 대답은 "엄청나게 빠르다"입니다. 테스트에 드는 시간과 비용 절감만으로도 코드 분석 툴에 투자할 가치가 있으며, 출시 기간 단축 효과도 기대할 수 있습니다. 이러한 프로세스는 기능 안전 인증 기관에서 최종 제품에 결함이 발생할 위험을 대폭 줄여주기 때문에 즐겨 볼 수 있는 프로세스입니다.

고 품질 코드를 통해 기능 안전으로 전환 속도 높이기

기능 안전 인증으로의 전환을 가속화하는 비결은 코드 품질을 향상시키는 것입니다. 코드 품질을 개선하면 결함 주입률이 낮아져 소프트웨어 릴리스 기준에 더 빨리 도달하고 개발 조직이 기능적 안전 인증 기관에 비해 매우 성숙해 보입니다. 응용 프로그램에 남아 있는 결점 수를 정확히 알 수는 없지만 코드 분석 도구를 초기에 자주 사용하여 그 수를 최소화할 수 있습니다.

IAR Systems US FAEs의 산업 프로필 및 수석 현장 프로그램 엔지니어/팀 리더 Shawn Prestridge에 의해 작성됨.