서론

제품의 안전성은 새로운 의료 장비 개발의 모든 단계에 영향을 미치며, 소프트웨어의 개발 및 인증은 전체 프로세스에 있어서 중요한 부분이다. ‘C’ 컴파일러와 같이 표준을 준수하는 기성 제품 소프트웨어의 사용은 종종 해당 프로젝트가 직면하게 되는 전반적인 위험을 줄이는 방법으로 여겨진다.  본문에서는 현 시점에서의 컴파일러 설계 및 인증 기술 수준을 살펴보고, 독립적인 협력 개발 업체를 통한 컴파일러 기능 안전성 표준의 준수 여부 평가에 따른 이점을 고려해 보고자 한다. 소프트웨어 툴이라는 맥락에서 표준을 준수한다는 것이 무엇을 의미하는지, 그리고 표준을 준수하는 컴파일러로부터 소프트웨어 개발자가 기대할 수 있는 것은 무엇인지를 설명하는 데 역점을 둘 것이다.

기능 안전성 표준의 기원은 대개 IEC 61508 (1998년에 최초 간행)로 거슬러 올라갈 수 있으며, 소프트웨어가 의미하는 바는 대개 초기의 RTCA DO-178B까지 거슬러 올라갈 수 있다. 본문의 많은 정의와 예제들은 ISO 26262에서 온 것이지만, 이들은 IEC 61508에도 똑같이 적용되며 그 내용을 계승하므로 일반적인 기능 안전성에도 적용할 수 있다. 안전을 매우 중시하는 자동차 산업에서조차도 국제 표준 포럼에서 기능 안전성에 대해 공식적인 관심을 보이게 된 것은 비교적 최근의 일이다. ISO 26262가 처음 간행된 것은 불과 2011년 11월의 일이었다.  이 같은 새로운 표준에 의해 야기된 모호성으로 인해, 해당 권위를 가진 컨설턴트와 등록기관들이 실제 세계에서의 구현이 아닌 학술적인 세부사항들을 놓고 격론을 벌이고 있다. ISO 26262 준수에 필요한 내용과 불필요한 내용을 결론짓기란 매우 어려울 수 있으며, 이는 규제가 그다지 심하지 않은 소프트웨어 툴의 영역에서도 마찬가지다. IEC 61508 등의 보다 확립된 일부 기능 안전성 표준들은 지난 수년 간, 심지어 수십 년에 걸쳐 관련 세부사항과 영향을 정립하였으나, ISO 26262의 경우 아직 그와 같지 않으므로 이를 위한 노력이 진행 중이다. 본문에서는 ISO 26262에 관한 일년간의 집중적인 연구 및 토의 결과들과, 이를 통해 소프트웨어 툴을 포함한 임베디드 마이크로컨트롤러용 컴파일러의 기능 안전성과 명시적으로 관련된 시스템 개발 국면에 미치는 영향에 대해 설명할 것이다.

기능 안전성의 개요

모든 노력에는 항상 위험이 내재할 수 밖에 없다. 기능 안전성이란 위험을 아예 제거한다는 비현실적이며 도달 불가능한 목표에서 출발하는 것이 아니라, 전기 및 전자 시스템(하드웨어와 소프트웨어)이 초래할 수 있는 위험을 최소화 하기 위한 합리적인 예방조치를 취하고 실제로 위험이 현실화될 경우 야기되는 피해를 완화시키고자 한다.  “기능 안전성”이라는 용어에 대한 공통된 이해에 도달하기 위해, ISO 26262는 다소 혼란스러울 수 있는 일련의 용어들의 정의을 쏟아내고 있는데, 그 최종적인 목표는 (자동차) 안전 무결성 수준(SIL: Safety Integrity Levels)을 이해하는 것이다.  이 수준은 개발 팀이 표준 준수를 위해 어느 정도의 노력을 쏟아야 하는지에 대한 설명으로 이루어진다. 이것은 시스템의 상식적인 “안전”은 물론, 개발 노력에 관한 결정적인 요인이므로 (A)SIL은 표준을 효과적으로 따르기 위해 반드시 이해해야 할 초석이 되는 개념이다. 따라서 이후 내용에서는 ISO 26262의 정의를 따라 이 초석이 되는 개념을 명확히 하되 좀더 현실적인 설명을 덧붙이고자 한다. 본문에 자세히 명시되지 않은 정의들에 대해서는 지금으로서는 일단 넘어가는 것이 적절할 것이다.

ISO 26262는 기능 안전성(1.51)을 “E/E 시스템(1.31) 의 오작동(1.73)이 야기한 위험(1.57)으로 인한 불합리한 위험(1.136) 의 부재”로, 그리고 불합리한 위험 (1.136)을 “타당한 사회도덕적 개념에 따라 특정 맥락에서 허용할 수 없는 것으로 판단되는 위험(1.99)”으로 정의하고 있다.

ISO 26262는 또한 안전 조치(1.110)의 개념을 “시스템 수준의 고장(1.130)을 피하거나 통제하고, 무작위적인 하드웨어 고장(1.92)을 감지 또는 통제하거나 그 폐해를 완화시키기 위한 활동 또는 기술적 솔루션”으로 제시하고 있다. 또한 잔여 위험(1.97)은 “안전 조치(1.110)를 취한 후에도 남아 있는 위험 (1.99)”으로 정의하고 있다.

이러한 정의를 고려할 때 자동차 안전 무결성 수준(1.6)은 “불합리한 잔여 위험(1.97)을 피하기 위해 ISO 26262에 부합하는 항목(1.69)이나 요소(1.32)에 필요한 요건 및 안전 조치(1.110)를 명시하기 위한 네 가지 수준 중 하나로서, D는 가장 엄격한 수준을, A는 가장 느슨한 수준을 나타낸다.”

비교적 덜 까다로우면서 이해하기 쉬운 용어로 설명하자면, 안전 무결성 수준은 시스템에 요구되는 동작 특성을 개인에게 해를 끼칠 수 있는 위험이라는 맥락에서 네 가지 범주로 구분하고 있다. 이때 재산의 손해 문제는 고려하지 않는다. (A)SIL D의 요건들은 (A)SIL A의 요건들보다 훨씬 더 밀접하다. 그 밖의 ISO 26262 표준에서는 필요한 동작 특성들의 개요를 밝히고 있다.

안전 무결성 수준

ISO 26262를 준수하고자 할 경우, 이 표준의 실제 본문을 따르는 것이 가장 좋다.  본문에서는 독자로 하여금 이 표준에 대한 감을 잡고 그것이 소프트웨어 툴에 미치는 영향을 이해할 수 있도록 해당 표준의 내용 중 아주 작은 일부만을 다루고 있다. 안전 무결성 수준에 대해서는 이 표준의 파트 9에 분명한 통계적 관점에서 상세하게 설명되어 있으므로 이를 참고할 것을 진심으로 권고하는 바이다.

   ▪ 툴 안전성의 의미
소프트웨어 툴 역시 이들이 사용되는 시스템과 동일한 안전 무결성 수준을 통과하여야 한다. 이 표준의 파트 8 중 상당 부분은 소프트웨어 툴을 특정 안전 무결성 수준으로 검증하기 위한 요건에 적용된다.

검증 툴

ISO 26262는 검증 툴과 관련한 네 가지 방법을 제공하고 이를 폭넓게 정의하며, 각각의 안전 무결성 수준에 어떤 방법들이 적용 가능한지(혹은 필요한지)에 대한 매핑을 제공한다. 이 네 가지 방법은 다음과 같다:

    • 사용에 대한 신뢰도 증대
    • 툴 개발 과정에 대한 평가
    • 소프트웨어 툴 검증
    • 안전성 표준에 따른 개발
적용 가능한 방법에 관한 평가를 내리기 위해서는, 툴이 기능 안전성에 미치는 영향과 에러 예방 및 검출 능력을 평가해야 한다. 일단 이러한 평가가 완료되면 네 가지 방법을 어떻게 적절히 적용할 수 있을 지 결정할 수 있다.

  ▪ 적절한 검증 방법의 결정
적절한 검증 방법을 결정하기 위한 첫 번째 요소는 툴이 미치는 영향이다.  선택 옵션은 두 가지인데, 툴이 에러를 초래/검출 실패하거나 그렇지 못하거나 둘 중 하나이다. 컴파일러는 시스템에 에러를 초래할 수 있으며 자신이 초래한 에러를 검출하지 못할 수도 있으므로 컴파일러의 툴 영향(TI: tool impact) 등급 값은 2가 된다. 툴 영향 등급이 1(에러를 초래할 수 없거나 모든 에러를 검출함)인 툴은 검증을 필요로 하지 않는다.

두 번째 결정 요소는 툴 에러 검출이다. 고장의 검출 또는 예방에 대한 신뢰도를 등급화하는 데는 높음, 중간 및 그 밖의 모든 경우라는 세 가지 선택옵션이 있다. 이 표준의 미흡한 점 중 하나는 높음과 중간이라는 용어에 대한 정의가 확립되지 않았다는 것이다! 이 신뢰도 등급은 툴 신뢰도(TCL: tool confidence level)를 결정하며, 어떤 검증 방법 표가 적합할 지 가려내 준다. 신뢰도가 높은 툴은 검증이 필요하지 않다. 컴파일러는 상당한 수준의 에러 검출 능력을 가지므로 툴 신뢰도 등급을 2로 매길 수 있다. 검증을 필요로 하는 두 신뢰도는 다음의 두 표를 따라야 한다:

표 1: TCL2에 적합한 툴 검증 방법

표 2: TCL3에 적합한 툴 검증 방법

‘++’ 표시는 이 검증 방법들이 해당 안전 무결성 수준에 매우 권장됨을 나타낸다.  ‘+’ 표시는 두 가지 의미를 함축하고 있다. 즉, 이 방법이 지나치거나(예를 들어, ASIL A의 경우 1d) 혹은 적절하지 못하다(예를 들어, ASIL D의 경우 1a)는 것이다.

  ▪ 사용에 대한 신뢰도 증대
표준에 따르면 소프트웨어 툴의 사용에 대한 신뢰도 증대는 특정 버전에 관련된 것이라고 한다. 툴 업데이트의 경우 추가 기능이나 버그 수정의 형태로도 적용되지 않는다는 점에서 이는 실제로 극히 제한적이다. 사용에 대한 신뢰도 향상은 근거를 대야 하는 부담도 크다. 즉 비교 가능한 이용 사례가 있어야만 하는데, 이 경우 사양 변경이 없어야 하며 툴의 고장 이력 전체를 체계적으로 축적해 놓아야 한다. 또한 툴의 정확한 식별, 툴 사용 기간, 발생한 고장 내역 및 이에 대처하기 위해 채택한 안전장치나 조치 또는 차선책에 대한 데이터도 제공되어야 한다. 이와 비슷하게 채택되었던 이전 버전의 툴에 대해서도 동일한 정보를 제공해야만 한다.

기능 안전성에 대한 인식을 갖고 있는 소프트웨어 툴 사용자들은 이로 인해 곤란에 처할 수 밖에 없다. 오래되고 기능이 미흡하거나 버그가 더 많지만 독립적인 협력 기관의 감사관에 의해 표준을 “준수”하는 것으로 평가된 툴을 사용할 것인가, 아니면 보다 새롭고 기능이 뛰어나며 버그도 적은데다가 동일한 벤더가 동일한 소스 코드를 기반으로 제공하지만 평가가 아직 이루어지지 않은 툴을 사용할 것인가?  자기평가에 대한 ISO 26262의 규정은 이러한 선택에 어떠한 영향을 미칠까? 이러한 난제를 효과적으로 해결하기 위해 마이크로칩에서는 “사용에 대한 신뢰도 증대”를 참조하는 대신 준수 여부를 독립적으로 평가하기로 했다. 이런 방식을 통해 여러 버전과 소스 기반의 변경 전반에 걸쳐 “툴 프로세스의 평가”와 “소프트웨어 툴의 인증”을 기반으로 준수성의 근거를 주장할 수 있다. 저자는 “사용에 대한 신뢰도 증대”의 경우 준수성에 대한 논거가 되기에는 약한 것이라고 보고 있다.

  ▪ 툴 개발 프로세스
툴 개발 프로세스에 대한 검증은 이 표준에서 아마도 가장 짧은 조항일 것이다. 이 조항에서는 단지 툴 개발 프로세스가 적절한 표준(예를 들어 Automotive SPICE, CMMI 또는 ISO 15504)을 준수해야 한다고만 서술하고 있으나, 이는 이 표준 전체의 무게를 짊어지고 있는 셈이다!

“사용에 대한 신뢰도 증대”가 갖는 산더미 같은 증거 및 비결정론과는 매우 대조적으로, 소프트웨어 툴의 개발에 사용되는 프로세스를 평가하여 검증하는 방법은 소프트웨어 엔지니어링 커뮤니티에서 지속적인 성공을 거둬왔다.  ISO 26262에 열거된 표준을 준수하는 소프트웨어 개발 프로세스 이용 시에도 표준 이하의 불안전한 소프트웨어를 작성할 가능성은 있으나, 그 확률은 훨씬 낮아진다. 클린(clean)하고 엄격한 개발 프로세스의 투자수익은 매우 높다. 표준을 준수하는 프로세스를 토대로 하는 검증 소프트웨어 툴은 이러한 투자에 부가적으로 따라오는 이득이나 마찬가지이다.

  ▪ 소프트웨어 툴 인증
인증 또한 요건 면에서는 간단하지만 그 실현에 따르는 부담은 크다. 인증은 전통적으로 컴파일러 개발의 강점이며 이에 대해서는 본고 후반에서 다룰 예정이다. 툴 인증을 검증하기 위해서는 그 툴이 요건을 충족한다는 것을 입증하여야 한다. ‘C’ 컴파일러의 경우 ANSI 표준이 이러한 요건을 제공한다. 인증 시에는 모든 에러나 고장들을 함께 분석하여, 그에 따른 결과 및 문서화된 에러나 고장을 검출할 수 있거나 예방 가능한 방법들을 평가해야 한다. 이 프로세스 역시 컴파일러 개발의 전통적인 강점이다. 또한 다음의 간단한 이용 사례 두 가지를 통해 컴파일러 인증은 다소 용이해진다: 하나는 소스 언어의 의미론에 따라 소스 코드로부터 그 의미에 충실한 기계어를 작성하는 것이고, 다른 하나는 동일한 소스로부터 최적화된 기계어를 작성하는 것이다. 컴파일러 개발자에게 있어서 이들은 독립된 두 개의 이용사례라기보다는 동일한 이용 사례의 두 측면일 뿐이지만, 인증에서는 그 점이 별로 문제되지 않는다.

  ▪ 안전성 표준에 따른 개발
ISO 26262는 “어떠한 안전성 표준도 소프트웨어 툴의 개발에 완전히 적용할 수 없다”고 명시적으로 밝히고 있다. 아마도 장래에는 관련 표준에서 소프트웨어 툴들을 망라하거나 혹은 표준을 준수함으로써 툴이 개발된 것으로 간주되는 요건을 체계화하게 될 것이다. 그 때까지 소프트웨어 툴은 사용을 통한 신뢰도 증대, 적절하고 시연 가능한 툴 개발 프로세스 또는 적절한 인증에 의존하여야 할 것이다.

컴파일러 인증

컴파일러 인증은 그 자체가 NP-완전(NPC) 연산 문제이다. 이 때문에 컴파일러 인증 프로세스가 다소 복잡해진다. 컴파일러가 임의의 입력 소스 코드 세트의 의미(소스 언어의 의미론에 따른) 실현을 보장할 수 없다면, 그로부터 생성된 출력의 기능적 안전성 또한 보장할 수 없다. 이런 면에서 컴파일러의 인증은 기능 안전성의 경우와 매우 유사하다. 한 개인에게 해가 미칠 위험을 모두 제거할 수 있다면 좋겠지만, 보다 현실적인 목표는 고장 가능성을 제한하고 가능한 한도까지 모든 고장의 영향을 완화시키는 것이다. 마찬가지로, 가능한 모든 입력 소스를 컴파일러가 기계어로 완벽하게 구현할 수 있다면 좋겠지만 이는 현실적으로 불가능하다.

실제로는 현재 표준 언어와 라이브러리 기능성 모두에 대해 업계 표준 테스트를 채택하여 인증에 대해 통계적으로 접근하고 있으며, 여기에는 긍정적 사례와 부정적 사례가 모두 포함된다. 임베디드 컴파일러는 인증 엔지니어에게 추가적인 과제를 제시한다. 즉, 감소된 메모리 크기(와 여기에 수반되는 코드 크기 최적화)와 임베디드 설계에 특정된 문제들을 해결하기 위해 목적에 맞게 구축된 프로세서 아키텍처(예: 추가적인 범용 및 DSP 코어, 온-칩 주변장치, 추가 메모리 공간)가 그것이다. 이를 적절하게 해결하기 위해 아키텍처 특정 화이트 박스(내부 구현 및 아키텍처 선택을 인식하는) 관련 테스트, 회귀(이전에 발생했던 에러의 재발)를 검출하기 위한 누적 테스트 및 컴파일러의 실제 사용자들로부터 축적된 광대한 양의 실제 코드 예제들이 사용되고 있다.

이러한 일련의 테스트의 크기는 그야말로 엄청날 수 있다. 어떤 경우에는 이러한 테스트가 무려 개별 테스트 50만 회에 육박하여, 정교한 자동 테스트 시스템을 컴퓨터로 수 주에 걸쳐 실행하여야 한다. 이렇게 극단적인 수준의 테스트를 통해서도 컴파일러 출력 내용을 완전히 인증할 수는 없으나, 안정적이고 신뢰성 있는 애플리케이션 구축을 위한 플랫폼을 제공할 수 있다. 컴파일러의 기능 안전성 매뉴얼은 애플리케이션의 안전 가능성을 기존에 컴파일러에 의한  것 이상으로 향상시키기 위한 추가 권장사항을 제공할 것이다.

컴파일러의 기능 안전성 매뉴얼

기능 안전성 매뉴얼은 벤더의 컴파일러 제공항목 가운데 두 번째로 중요한 부분이다. 기능 안전성 매뉴얼은 해당 제품이 사용자의 기대에 부응하는 지 확인하기 위한 완전한 제품 개요에서부터 시작해야 한다. 이 매뉴얼은 어떤 기능들을 자유롭게 사용할 수 있으며, 사용 전에 어떤 기능들을 철저히 이해해야 하는지 혹은 아예 피해야 할지 구체적으로 서술하여야 한다.  전자의 한 예가 포인터나 어레이를 통한 단일 인디렉션(indirection)이다. 후자의 예는 보다 높은 수준의 인디렉션이나 보다 적극적인 최적화 설정이다.  안전성 매뉴얼은 추가적인 프로세스 단계들을 시사하거나, 추가 툴들(예: MISRA 체커)을 권장하거나 혹은 개발 노력을 도와줄 다른 안전성 조치들(예: 모든 인터럽트와 트랩들이 처리되도록 하기 위한 ASSERT ())을 제안할 수도 있다.

컴파일러의 안전한 사용

엄격한 개발 프로세스와 안전에 대한 높은 집중도 및 뛰어난 인증 절차를 거치더라도, 컴파일러는 여전히 컴파일러일 뿐이다. 툴에 대하여 표준 준수와 관련한 별도의 간소화된 요건들이 주어지는 이유는 이 때문이다. 소스 코드의 한 조각이 안전성 의도를 나타내는 지(예를 들어, if(abs(velocity) > 200_KPH) LockAllWheels(); 는 구문론상으로 유효한 ANSI ‘C’이지만 의미론적으로는 끔찍한 코드이다) 이해할 수 있는 맥락적, 의미론적 민감성을 지닌 범용 툴은 존재하지 않는다. ISO 26262가 주로 관여하고 있는 것은 위에서 언급했듯이, 기능적으로 안전한 동작특성을 필요로 하는 제품을 위해 개발 또는 구입되는 코드에서 요구하는 동작특성이다. 컴파일러를 안전하게 사용하기 위한 최상의 지침은 컴파일러의 기능 안전성 매뉴얼을 철저하게 이해하고 이를 충실하게 따르라는 것이다. 이것이 안전성을 보장해 주지는 못하지만, 적어도 툴을 안전하게 사용하기 위한 가장 개연성 높은 경로임은 틀림 없다.