- 자동차의 듀얼 브레이크 컨트롤러
- 병원의 백업 인공호흡기
- 또는 항공우주 분야의 3중 이중화 비행 컴퓨터 등입니다.
이러한 것들은 눈에 보이기 때문에 당연한 것입니다. 그러나 종종 간과되는 것은 보이지 않는 계층인 소프트웨어 툴체인입니다.
컴파일러가 코드 한 줄을 잘못 컴파일하거나 빌드 플래그가 예상하지 못한 방식으로 최적화를 변경하면 시스템을 얼마나 많이 이중화했는지는 중요하지 않습니다.
컴파일러 때문에 시스템이 안전하지 않을 수 있습니다. 그리고 너무 늦을 때까지 이를 인지하지 못할 수도 있습니다.
그렇기 때문에 ISO 26262, IEC 62304, IEC 61508과 같은 표준에서는 툴에 대한 신뢰가 필요하다고 명시적으로 언급하고 있습니다. 그리고 임베디드 엔지니어인 우리에게는 툴체인 검증으로 귀결됩니다.
하지만 실제로 해보기 전까지는 툴체인의 유효성 검사가 간단해 보일 수 있습니다.
"컴파일러만 확인하면 되는" 것처럼 보이는 작업이 도구가 변경될 때마다 수개월의 노력과 문서화, 재검증 작업으로 바뀝니다.
수년 동안 저는 이 점을 과소평가하는 팀을 셀 수 없을 만큼 많이 보았습니다.
이 가이드의 목표는 이러한 함정으로부터 여러분을 구하는 것입니다.
팀이 저지르는 실수, DIY 검증의 현실, 그리고 많은 조직에서 사전 인증된 툴체인을 구매하는 것이 더 현명한 방법인 이유를 살펴보겠습니다.
기능 안전 인증의 현실
겉으로 보기에 툴체인 검증은 간단해 보입니다. 몇 가지 테스트를 실행하고 그 결과를 감사자에게 전달하고 다음 단계로 넘어가면 됩니다. 그렇죠?
그렇지 않습니다.
안전 표준은 소프트웨어 도구를 시스템 결함의 잠재적 원인으로 취급합니다.
하드웨어 결함은 무작위로 발생하므로 중복성을 통해 잡을 수 있습니다.
하지만 시스템적 결함이라면? 컴파일러가 중요한 안전 검사를 최적화하는 것처럼요?
이러한 결함은 수년 동안 발견되지 않고 조용히 안전 증명을 약화시킬 수 있습니다.
검증은 "지금 작동하느냐"가 아니라 "어떤 조건에서도 항상 안정적으로 작동한다는 것을 증명할 수 있느냐"에 더 중점을 둡니다. 즉
- 도구가 귀사와 같은 사용 사례에서 입증된 실적을 가지고 있음을 보여주세요.
- 확신을 줄 수 있을 만큼 광범위하고 관련성이 높은 테스트 사례를 실행합니다.
- 감사자가 요구 사항을 추적할 수 있는 문서를 작성합니다.
- 도구 체인이 변경될 때마다(패치 업데이트와 같은 '작은' 사항이라도) 전체 과정을 반복합니다.
무겁게 들릴 수 있습니다.
간단한 체크박스로 끝날 것으로 기대하는 팀은 보통 이 작업이 요구하는 구조, 리소스 및 규율의 양에 충격을 받습니다.
팀이 흔히 저지르는 실수
숙련된 임베디드 팀도 기능 안전이 도입되면 당황할 수 있습니다.
저는 자동차, 의료, 산업 자동화 등 산업 전반에 걸쳐 동일한 실수가 반복되는 것을 보았습니다.
실수 #1: 비용 및 범위 과소평가
전형적인 함정은 툴체인 검증을 부수적인 작업으로 취급하는 것입니다. 실제로는 그 자체로 하나의 전담 프로젝트로 취급해야 마땅합니다.
애플리케이션 엔지니어뿐만 아니라 컴파일러, 안전 표준, 테스트 설계를 이해하는 사람이 필요합니다.
테스트를 실행하고, 실패를 분석하고, 모든 것을 문서화하려면 몇 주(더 자주 몇 달)가 필요합니다. 저는 '몇 주'의 예산을 책정하고도 몇 달이 지난 후에도 여전히 허둥대는 팀을 보았습니다.
실수 #2: 인증을 한 번에 끝낼 수 있다고 가정하기
관리자들은 종종 한 번 인증을 받으면 영원히 재사용할 수 있다고 생각합니다. 안타깝게도 안전 표준은 그렇게 작동하지 않습니다.
컴파일러 버전을 변경한다고요? 최적화 플래그를 뒤집나요? 정적 분석기 버전을 변경하시나요? 이러한 각 변경 사항은 부분 또는 전체 재검증을 트리거할 수 있습니다.
도구 체인이 변경되는 순간, 원래의 증명은 더 이상 유효하지 않습니다.
저는 프로젝트 도중에 GCC를 업그레이드하는 것과 같은 사소한 일로 인해 프로젝트가 지연되는 것을 보았습니다.
"툴체인만 동결하면 괜찮아"라고 말할 수도 있습니다. 하지만 이 경우 컴파일러가 업데이트되는 데는 이유가 있기 때문에 버그와 보안 위험을 감수해야 합니다.
실수 #3: 유효성 검사를 "그냥 테스트 실행"으로 취급하기
거대한 테스트 스위트를 구입하거나 작성하는 것이 해결책처럼 들릴 수 있습니다. 하지만 안전 표준은 추적성, 위험 분석, 증거 등 훨씬 더 많은 것을 요구합니다.
단순히 "컴파일러가 테스트를 통과했는가"가 아니라 그 이상입니다:
- 해당 테스트에서 어떤 요구 사항을 충족했는가?
- 어떤 잔여 위험이 남아있나요?
- 어떻게 완화할 수 있을까요?
이것이 바로 감사자가 찾는 서류 작업의 종류입니다. 그리고 이를 건너뛰는 것은 나중에 위험 신호를 보내는 지름길입니다.
실수 #4: 리더십의 사각지대
겉으로 보기에 유효성 검사는 예산의 한 항목처럼 보입니다. 하지만 실제 비용은 비용이 아니라 엔지니어링 시간입니다.
최고의 엔지니어가 매주 검증을 실행하는 데 소비하는 시간은 제품 기능을 구축하거나 안정성을 개선하는 데 사용하지 않는 시간입니다.
눈에 보이는 금전적 비용보다 숨겨진 기회 비용이 더 큰 경우가 많습니다. 이를 무시하는 팀은 대개 너무 늦게 깨닫게 됩니다.
DIY 대 구매: 장단점
팀이 범위를 이해한 후에는 일반적으로 자체 검증 프로세스를 구축하거나 사전 인증된 툴체인을 구매하는 것으로 결정이 내려집니다.
두 경로 모두 효과가 있을 수 있지만 장단점은 매우 다릅니다.
DIY 경로
장점:
- 유효성 검사 범위와 방법을 완벽하게 제어할 수 있습니다.
- 사용자 환경에 정확히 맞출 수 있습니다.
- 공급업체에 대한 의존성이 없습니다.
단점:
- 심도 있고 전문적인 전문 지식이 필요합니다.
- 리소스를 많이 사용하며 엔지니어링 시간을 수개월씩 잡아먹기 쉽습니다.
- 주요 툴체인을 업데이트할 때마다 반복해야 합니다.
도구 체인이 특이하거나 제품 수명 주기가 수년에 걸쳐 최소한의 도구 변경으로 이루어지는 경우에는 DIY가 적합할 수 있습니다. 하지만 대부분의 팀에서는 반복적인 낭비가 됩니다.
구매 경로
장점:
- 공급업체에서 이미 검증을 수행합니다.
- 감사원이 인정하는 인증 키트, 테스트 증거 및 문서가 함께 제공됩니다.
- 엔지니어가 제품 작업에 집중할 수 있습니다.
단점:
- 선불 라이선스 비용.
- 공급업체의 업데이트 및 릴리스 주기에 의존해야 합니다.
바로 이 점에서IAR의 사전 인증된 도구 체인이 적합합니다 . 사내에서 컴파일러를 검증하는 데 6~12개월을 소비하는 대신 ISO 26262, IEC 61508 및 IEC 62304에 부합하는 테스트 결과, 프로세스 및 안전 문서가 이미 포함된 인증 키트를 받을 수 있습니다.
다시 말해, 서류 작업의 마라톤을 건너뛰고 엔지니어가 컴파일러 안전 케이스 대신 안전이 중요한 제품을 만드는 데 집중할 수 있습니다.
ROI 관점
라이선스는 서류상으로만 보면 비싸 보입니다. 하지만 숨겨진 비용을 생각하면 다릅니다:
- 선임 엔지니어 연봉의 반년치.
- 테스트 캠페인을 위한 QA 직원.
- 안전 사례를 준비하기 위한 외부 컨설턴트.
- 출시 지연과 수익 손실.
10번 중 9번은 구매가 더 빠를 뿐만 아니라 더 저렴하고 안전합니다.
전략적 결정
규정 준수는 필수입니다. 선택의 여지는 준수를 달성하는 방법에 있습니다.
DIY 또는 구매를 선택하는 것은 기술적인 결정이 아닙니다. 전략적 결정입니다.
결정하기 전에 몇 가지 질문을 해보세요:
- 향후 3~5년 동안 얼마나 많은 안전 프로젝트를 실행할 것인가?
- 최고의 (그리고 값비싼) 엔지니어가 기능을 작성하거나 검증 보고서를 작성하기를 원하는가?
- 툴체인 변경으로 인해 시장 출시가 분기별로 지연되면 어떻게 되나요?
규정 준수를 단순한 확인 사항이 아닌 전략적 결정으로 간주하는 팀은 결국 더 빨리 출시하고 속도와 안정성이 타협할 수 없는 시장에서 경쟁력을 유지하게 됩니다.
DIY로 진행할 때 피해야 할 함정
사내에서 직접 검증하기로 결정했다면 다음과 같은 함정을 피하세요:
- 초기 문서화 건너뛰기: 처음부터 요구 사항과 추적성을 파악하지 않으면 감사 압박으로 인해 서류 작업을 다시 작성하게 됩니다.
- 도구 체인 업데이트 무시: "사소한" 패치도 이전 유효성 검사를 무효화할 수 있습니다. 이를 무시하는 팀은 종종 감사에서 불이익을 받습니다.
- 공급망 요구 사항 무시: 감사는 테스트 로그 이상의 것을 요구할 것입니다. 감사는 수명 주기 프로세스, 위험 분석 및 모든 단계를 고려했다는 증거를 원할 것입니다.
DIY도 가능합니다. 하지만 적절한 리소스를 갖춘 장기 프로젝트로 진행할 때만 가능합니다.
결론
기능 안전은 선택 사항이 아닙니다. 하지만 툴체인 검증에 어떻게 접근하느냐에 따라 엔지니어링 시간의 블랙홀이 될지, 아니면 이미 해결한 문제가 될지가 결정됩니다.
직접 수행하면 제어할 수 있지만 시간과 리소스가 소모됩니다. IAR의 안전 인증 컴파일러와 같이 사전 인증된 툴체인을 구입하면 IAR 플랫폼에 포함된 Arm, RISC-V, STM8, Renesas RX, RL78, RH850 제품군을 모두 지원하므로 이러한 부담을 덜고 위험을 줄이면서 더 빠르게 진행할 수 있습니다.
성공하는 팀은 규정 준수를 세금처럼 여기는 팀이 아닙니다.
현명한 선택을 하고, 낭비되는 노력을 줄이며, 엔지니어들이 중요한 일, 즉 전 세계가 신뢰할 수 있는 시스템을 구축하는 데 집중할 수 있도록 하는 팀들이 성공합니다.
