자동차 소프트웨어 개발의 필수, ISO 26262와 ASIL 등급을 완벽하게 이해해 보자. 기능 안전의 개념부터 ASIL 등급 산정 방법까지, 초보 개발자의 시선에서 쉽게 풀어보자.
리스트
1. 자동차가 달리는 컴퓨터가 된 이유 (ISO 26262의 등장)
자동차 업계에 발을 들이거나 임베디드 소프트웨어를 공부하다 보면, 반드시 마주치는 거대한 장벽이 있다. 바로 ISO 26262라는 표준이다. 처음 이 단어를 접했을 때, 단순히 코드를 잘 짜는 것 외에 무엇이 더 필요한지 의문이 들수 있다. 하지만 이유는 명확하다.
과거의 자동차는 기계 장치의 집합이었지만, 지금의 자동차는 ‘바퀴 달린 컴퓨터’나 다름없기 때문이다. 엑셀을 밟았을 때 속도가 올라가는 것, 브레이크를 밟았을 때 차가 멈추는 것, 심지어 핸들을 돌리는 것까지 모든 것이 전자 제어 장치(ECU)와 소프트웨어에 의해 통제된다. 만약 우리가 사용하는 스마트폰이 멈추면 재부팅하면 그만 이지만, 고속도로를 달리는 자동차의 제어 소프트웨어가 버그로 인해 멈춘다면 그것은 곧장 인명 사고로 이어진다.
ISO26262
이러한 배경에서 탄생한 것이 ISO 26262, 즉 ‘자동차 기능 안전(Functional Safety)’ 국제 표준이다.
이 표준을 깊이 파고들며 알게 된 핵심은 ‘고장 나지 않는 것’을 넘어, ‘고장이 나더라도 안전하게 대처하는 것’에 초점이 맞춰져 있다는 점이다.
개발 과정에서 발생할 수 있는 모든 위험을 미리 분석하고, 그 위험을 허용 가능한 수준으로 낮추는 체계적인 프로세스가 필요해진 것이다. 단순히 코딩을 잘하는 것을 넘어, 설계 단계부터 검증 단계까지 모든 과정이 문서화 되고 추적 가능해야 한다는 것이 이 표준의 골자다.
결국 ISO 26262는 개발자에게 귀찮은 숙제가 아니라, 사람의 목숨을 지키기 위한 최소한의 안전장치이자 엔지니어로서 가져야 할 윤리적 책임의 가이드라인이라고 이해하는 것이 옳다.
2. ASIL: 위험을 측정하는 척도
ISO 26262를 공부하다 보면 항상 함께 나오는 것이 ASIL(Automotive Safety Integrity Level)이다.
모든 부품이나 소프트웨어 기능이 똑같이 위험한 것은 아니다. 예를 들어, 에어컨이 고장 나는 것과 브레이크가 고장 나는 것은 차원이 다른 문제다. 그렇다면 이 위험도를 어떻게 객관적인 수치로 표현할 수 있을까? 여기서 엔지니어들의 논리적인 사고방식이 빛을 발한다.
ASIL은 단순히 감으로 정하는 것이 아니라, 세 가지 명확한 변수의 조합으로 결정된다그 세 가지는 바로 심각도(Severity), 노출 빈도(Exposure), 그리고 제어 가능성(Controllability) 이다.
가. 심각도 (Severity, S)
“사고가 났을 때, 탑승자나 보행자가 얼마나 다치는가?”를 판단한다. 단순히 ‘아프다’가 아니라 부상의 정도와 생명 위협 여부가 기준이다.
나. 노출 빈도 (Exposure, E)
“위험한 상황에 얼마나 자주 놓이는가?”를 판단한다. 운전 시간 중 해당 상황이 차지하는 비율이나 빈도를 따진다.
다. 제어 가능성 (Controllability, C)
“위험 상황이 닥쳤을 때, 운전자가 사고를 피할 수 있는가?”를 판단한다. 이 부분이 가장 주관적일 수 있어 ISO 26262에서는 ‘운전자의 몇 퍼센트가 피할 수 있는가’를 기준으로 제시한다.
이 세 가지를 매트릭스 형태로 조합하면, QM(Quality Management)부터 ASIL A, B, C, D까지의 등급이 나온다.
ASIL D가 가장 높은 위험 등급이며, 이는 곧 개발 과정에서 가장 엄격한 안전 요구사항을 준수해야 함을 의미한다.
3. ASIL 산정 매트릭스 (ASIL Determination Matrix)
이제 위에서 정의한 세 가지 변수를 조합해 보자. 제어 가능성(C)을 C1, C2, C3로 명확히 나누어, 같은 심각도와 노출 빈도에서도 운전자의 제어 능력에 따라 등급이 어떻게 달라지는지 한눈에 볼 수 있도록 구성하였다.
- 왼쪽에서 해당 기능의 고장 시 심각도(S)를 찾는다.
- 그다음 해당 상황의 노출 빈도(E)를 찾는다.
- 마지막으로 오른쪽의 제어 가능성(C) 열과 만나는 지점의 등급을 확인한다.
| Severity (심각도) | Exposure (노출 빈도) | C1 (단순 제어) 99% 회피 가능 | C2 (보통 제어) 90% 회피 가능 | C3 (제어 어려움) 90% 미만 회피 |
| S1 (경미) | E1 | QM | QM | QM |
| E2 | QM | QM | QM | |
| E3 | QM | QM | ASIL A | |
| E4 | QM | ASIL A | ASIL B | |
| S2 (중상) | E1 | QM | QM | QM |
| E2 | QM | QM | ASIL A | |
| E3 | QM | ASIL A | ASIL B | |
| E4 | ASIL A | ASIL B | ASIL C | |
| S3 (치명적) | E1 | QM | QM | ASIL A |
| E2 | QM | ASIL A | ASIL B | |
| E3 | ASIL A | ASIL B | ASIL C | |
| E4 | ASIL B | ASIL C | ASIL D |
위 표를 보면 알 수 있듯, S3(치명적) + E4(자주 발생) + C3(피하기 어려움)의 조합이 되었을 때 비로소 최고 등급인 ASIL D가 부여된다.
예를 들어 고속 주행 중 전자식 스티어링 휠이 멋대로 잠겨버리는 상황은 사망 사고로 이어질 수 있고(S3), 고속 주행은 빈번하며(E4), 운전자가 힘으로 핸들을 돌리기 매우 어렵기(C3) 때문에 전형적인 ASIL D 등급의 기능이라 할 수 있다.
4. ASIL D를 대하는 자세
막상 내가 개발해야 할 모듈이 ASIL D 등급을 받았다고 가정해 보자. 처음에는 막막함이 앞설 것이다. ASIL D는 하드웨어적으로는 단일 고장이 발생해도 기능이 유지되어야 하는 이중화(Redundancy) 설계를 요구하고, 소프트웨어적으로는 매우 높은 수준의 무결성을 요구하기 때문이다. 코드를 짤 때 단순히 “동작하네?”에서 끝나는 것이 아니라, “이 변수가 메모리 오류로 비트가 뒤집혀도 안전한가?”까지 고민해야 한다는 뜻이다.
여기서 몇 가지 실무적인 접근 방법을 고민해 볼 수 있다.
첫째, ASIL 분해(Decomposition) 기법 활용
하나의 시스템에 과도하게 높은 ASIL 등급이 부여되면 비용과 개발 난이도가 급상승한다. 이때 서로 독립적인 두 개의 채널로 시스템을 구성하여 요구되는 안전 등급을 낮추는 방법이다.
예를 들어, ASIL D 요구사항을 충족하기 위해 ASIL B 등급의 모듈 두 개가 서로를 감시하도록 설계하는 방식이다. 이는 마치 비행기의 엔진이 하나 꺼져도 다른 하나로 비행할 수 있게 만드는 원리와 유사하다.
둘째, 코딩 룰과 검증 도구의 적극적인 활용
MISRA C와 같은 자동차 코딩 표준을 준수하는 것은 기본 중의 기본이다. 하지만 사람의 눈으로 모든 오류를 잡을 수는 없다.
따라서 정적 분석 도구(Static Analysis Tool)를 사용하여 런타임 에러 가능성을 사전에 차단하고, 동적 분석을 통해 코드 커버리지(Code Coverage)를 측정해야 한다.
특히 ASIL D 등급에서는 MC/DC (Modified Condition/Decision Coverage)라는 매우 까다로운 커버리지를 만족해야 한다. 이는 복잡한 조건문 내의 각 조건이 결과에 독립적으로 영향을 미치는지를 검증하는 것으로, 테스트 케이스 설계부터 치밀해야만 달성할 수 있다.
셋째, 추적성(Traceability)의 확보
요구사항(Requirements)부터 설계(Design), 구현(Code), 테스트(Test)까지 모든 단계가 서로 1:1로 매핑되어야 한다.
코드 한 줄을 수정하더라도 이 코드가 어떤 요구사항에서 비롯되었는지, 그리고 어떤 테스트 케이스로 검증되었는지 즉시 파악할 수 있어야 한다. 이를 위해 엑셀로 관리하기보다는 전문적인 ALM(Application Lifecycle Management) 도구를 사용하는 것이 정신 건강과 프로젝트 성공에 훨씬 이롭다는 것을 경험적으로 느꼈다.
안전! 안전! 안전! ISO 26262
지금까지 ISO 26262의 개념과 ASIL 등급이 갖는 의미, 그리고 이를 실무에서 어떻게 받아들여야 할지 살펴보았다. 처음에는 ASIL D라는 등급이 단순히 개발자를 괴롭히는 높은 벽처럼 느껴질 수 있다. 하지만 관점을 조금만 바꾸어 보자. 우리의 가족, 친구, 그리고 나 자신이 타는 자동차의 안전을 책임진다는 사명감으로 접근한다면, 까다로운 표준들이 오히려 든든한 가이드라인이 되어줄 것이다.
기술은 계속 발전하고, 자동차는 더욱 복잡해질 것이다. 그 속에서 ‘안전’이라는 가치를 지키기 위해 고군분투하는 모든 개발자에게, 이 글이 작게나마 도움이 되었기를 바란다. 기능 안전은 단순한 규제가 아니라, 기술에 대한 신뢰를 완성하는 마지막 퍼즐 조각임을 잊지 말자.