ISO 26262란 무엇인가? 자동차 기능 안전 완전 정리

자동차는 이제 단순한 기계가 아니다. 과거에는 엔진, 브레이크, 조향장치처럼 기계적인 부품이 중심이었다면, 현재의 차량은 수십 개 이상의 ECU와 수백만 줄 이상의 소프트웨어 코드로 동작하는 복합 전자 시스템이 되었다. 운전자가 버튼 하나를 누르는 동작 뒤에도 수많은 센서 데이터 처리, 통신 네트워크 메시지, 제어 알고리즘, 진단 로직이 동시에 작동한다.

 

이처럼 자동차 내부의 전자 제어 시스템이 복잡해질수록, 소프트웨어 오류나 하드웨어 결함이 단순 불편을 넘어서 실제 사고로 이어질 가능성도 함께 커졌다. 예를 들어 브레이크 제어 로직이 오동작하거나, 전동 파워 스티어링 시스템이 잘못된 신호를 받아 조향이 불가능해지거나, 주행 중 계기판이 잘못된 속도를 표시한다면 운전자와 탑승자의 생명에 직접적인 영향을 줄 수 있다.

 

이러한 이유로 자동차 산업에서는 “제품이 정상 동작하는가?”만 확인하는 수준을 넘어, 고장이 발생하더라도 위험한 상태로 이어지지 않도록 설계해야 한다는 개념이 매우 중요해졌다. 그리고 이 개념을 체계적으로 정의한 국제 표준이 바로 ISO 26262이다.

 

ISO 26262의 정의

 

ISO 26262는 자동차 전기·전자(E/E, Electrical/Electronic) 시스템의 기능 안전(Functional Safety) 을 위한 국제 표준이다. 쉽게 말하면, 차량 내부 전장 시스템에서 오류가 발생하더라도 사람에게 위험을 주지 않도록 개발하고 검증하는 방법을 정리한 규칙이라고 이해하면 된다.

 

여기서 중요한 단어는 “기능 안전”이다. 기능 안전은 제품이 절대 고장 나지 않도록 만드는 개념이 아니다. 현실적으로 모든 시스템은 언젠가 오류가 발생할 수 있다. 따라서 기능 안전은 오류 자체를 완전히 제거하는 것보다, 오류가 발생했을 때 위험한 결과로 이어지지 않게 만드는 것에 초점을 둔다.

 

즉, ISO 26262는 다음과 같은 질문에 답하기 위해 존재한다.

 

- 센서 값이 잘못 들어오면 차량은 어떻게 반응해야 하는가?
- ECU 내부 메모리가 깨졌다면 어떤 보호 로직이 동작해야 하는가?
- 브레이크 신호가 비정상이라면 시스템은 어떤 안전 상태로 전환해야 하는가?
- 소프트웨어 버그가 있어도 운전자에게 치명적 위험이 발생하지 않게 하려면 어떻게 설계해야 하는가?

 

이러한 모든 내용을 개발 프로세스, 시스템 설계, 소프트웨어 구현, 테스트, 검증 관점에서 체계화한 것이 ISO 26262이다.

 

왜 ISO 26262가 중요한가?

 

자동차는 일반 소비자 제품과 다르다. 스마트폰 앱이 잠시 멈추는 문제는 불편함으로 끝날 수 있지만, 자동차 제어 시스템 오류는 사고와 인명 피해로 이어질 수 있다. 특히 최근 차량은 아래와 같은 기능들이 대부분 전자 제어 기반으로 동작한다.

 

- 전자식 브레이크 제어
- 전동식 조향 제어
- 에어백 전개 제어
- ADAS(첨단 운전자 보조 시스템)
- 차선 유지 보조
- 자동 주차 시스템
- 배터리 관리 시스템(BMS)
- 전동 파워트레인 제어

 

이러한 기능들은 단순 편의 기능이 아니라 주행 안전과 직접 연결된다. 따라서 제조사와 부품사는 시스템 개발 단계부터 안전 요구사항을 반영해야 하며, 단순 테스트 몇 번으로 끝나는 것이 아니라 처음 기획부터 양산까지 안전 활동을 수행해야 한다. ISO 26262는 바로 그 기준이 된다.

 

실제 글로벌 OEM과 Tier1 업체에서는 신규 ECU 개발 시 ISO 26262 대응 여부가 필수 요구사항인 경우가 많다. 즉, 이 표준은 이론 지식이 아니라 실제 프로젝트에서 사용하는 실무 기준이다.

 

기능 안전(Functional Safety)이란 무엇인가?

 

기능 안전은 시스템 내부에 결함이 발생했을 때도 허용 가능한 수준의 안전을 유지하는 능력을 의미한다.

 

예를 들어 차량 속도 센서가 갑자기 0km/h를 출력했다고 가정해보자. 실제 차량은 고속 주행 중인데 시스템이 이를 정지 상태로 오인한다면 여러 제어 로직이 잘못 동작할 수 있다. 이때 안전하게 설계된 시스템은 센서 값을 무조건 신뢰하지 않는다. 다른 센서와 비교하거나, 값의 변화율을 검사하거나, 이상 상태를 감지해 보호 모드로 전환한다.

 

즉, 기능 안전은 아래와 같은 구조를 가진다.

 

- 위험 상황을 예측한다.

- 어떤 고장이 위험으로 이어지는지 분석한다.

- 고장을 감지하는 방법을 만든다.

- 고장 시 안전하게 동작하도록 설계한다.

- 실제로 그렇게 동작하는지 검증한다.

 

이 과정을 문서화하고 체계적으로 수행하도록 요구하는 표준이 ISO 26262이다.

 

ISO 26262에서 가장 중요한 개념: ASIL

 

ISO 26262를 공부하면 반드시 등장하는 핵심 개념이 ASIL(Automotive Safety Integrity Level) 이다. 이는 위험도의 수준을 분류하는 등급 체계다. 시스템 오류가 얼마나 심각한 사고로 이어질 수 있는지에 따라 안전 수준 요구사항이 달라진다.

 

등급은 일반적으로 아래와 같이 나뉜다.

QM : 일반 품질 관리 수준 (기능 안전 대상 아님)
ASIL A : 낮은 위험도
ASIL B : 중간 위험도
ASIL C : 높은 위험도
ASIL D : 가장 높은 위험도

 

예를 들어 실내 무드등 오동작은 안전에 큰 영향이 없을 수 있으므로 QM 수준일 수 있다. 반면 고속 주행 중 브레이크 제어 실패는 치명적인 결과를 만들 수 있으므로 ASIL D 수준으로 평가될 수 있다.

 

ASIL이 높아질수록 요구되는 개발 절차, 검증 강도, 테스트 범위, 아키텍처 이중화, 진단 커버리지 등도 훨씬 엄격해진다.

 

ISO 26262 전체 구조 (V-model)

 

ISO 26262는 크게 아래 영역으로 나뉜다.

출처: https://velog.io/@hyeon-ii/ISO-26262

1. 공통 용어 정의
2. 기능 안전 관리
3. 개념 단계(위험 분석)
4. 시스템 개발
5. 하드웨어 개발
6. 소프트웨어 개발
7. 생산 및 운영
8. 지원 프로세스
9. 안전 분석 기법
10. 가이드라인

 

즉, 자동차 ECU 하나를 개발하더라도 코딩만 잘한다고 끝나는 것이 아니라,

요구사항·검증·문서·변경관리·양산 대응까지 모두 포함된다.

 

1. Vocabulary (Part 1)

가장 첫 번째 파트는 용어 정의다.

 

기능 안전 분야에서는 단어 하나의 의미가 매우 중요하다. 예를 들어 Fault, Failure, Hazard, Risk는 비슷해 보이지만 완전히 다른 의미다. 프로젝트마다 해석이 다르면 요구사항도 달라지기 때문에 공통 언어를 맞추는 역할을 한다.

 

실무 예시

Fault = 내부 결함
Failure = 기능 실패 결과
Hazard = 위험 상황

 

2. Management of Functional Safety (Part 2)

기능 안전을 조직적으로 관리하는 파트다.

 

누가 책임자인지, 안전 계획은 어떻게 세우는지, 리뷰는 누가 하는지, 독립성은 어떻게 확보하는지 등을 정의한다. 즉, 엔지니어 개인 역량만이 아니라 회사의 개발 체계까지 포함한다.

 

실무 예시

Safety Manager 지정
Safety Plan 작성
Audit 일정 운영
역할/책임(R&R) 정의

 

3. Concept Phase (Part 3)

이 단계는 기능 안전의 출발점이다. 차량 기능이 어떤 위험을 만들 수 있는지 분석한다.

 

4. Product Development at the System Level (Part 4)

시스템 레벨 설계 단계다. FSC를 실제 ECU 구조로 내리는 과정이다.

 

주요 내용:

Technical Safety Requirements
System Design
Item Integration & Testing
Safety Validation
Release for Production

 

즉, “안전 아이디어”를 실제 시스템 요구사항으로 바꾸는 단계다.

 

5. Product Development at the Hardware Level (Part 5)

하드웨어 개발 단계다.

(대상: MCU, 전원 회로, 드라이버 IC, 센서 회로)

 

주요 활동:

HW Safety Requirements
HW Design
Failure Metrics 분석
HW Integration Test

 

예를 들어 MCU 오동작 시 Watchdog, 전원 이상 시 Reset 회로 등을 설계한다.

 

6. Product Development at the Software Level (Part 6)

자동차 소프트웨어 개발자가 가장 많이 보는 파트다.

 

주요 흐름:

Software Safety Requirements
Software Architecture Design
Unit Design & Implementation
Unit Test
Integration Test
Verification

 

7. Production and Operation (Part 7)

개발 완료 후 양산과 운영 단계다.

 

포함 내용:

생산 공정 관리
서비스센터 정비 절차
현장 이슈 피드백
폐기(Decommissioning)

 

즉, 출시 후에도 안전 활동은 계속된다.

 

8. Supporting Processes (Part 8)

실무에서 매우 중요한 공통 지원 영역이다.

 

포함 내용:

Requirement Management
Configuration Management
Change Management
Documentation
Tool Qualification
Verification Process

 

왜 중요할까?

코드는 맞아도 버전 관리가 틀리면 양산 사고가 날 수 있다.

그래서 형상관리와 변경관리가 기능 안전에서 매우 중요하다.

 

9. ASIL-oriented and Safety-oriented Analyses (Part 9)

안전 분석 기법을 다룬다.

 

예:

ASIL Decomposition
Dependent Failure Analysis
Safety Analysis

 

복잡한 시스템에서 단일 고장뿐 아니라 연쇄 고장까지 검토한다.

 

10. Guideline on ISO 26262 (Part 10)

표준 적용을 돕는 해설서 역할이다.

필수 요구사항이라기보다 이해를 돕는 참고 문서에 가깝다.

 

AUTOSAR와 ISO 26262는 어떤 관계가 있을까?

 

자동차 소프트웨어 개발자라면 ISO 26262와 함께 AUTOSAR를 자주 접하게 된다. 두 개념은 서로 다른 표준이지만 실무에서는 매우 밀접하게 연결된다.

 

ISO 26262는 “무엇을 안전하게 해야 하는가”를 정의한다.

AUTOSAR는 “소프트웨어를 어떻게 구조적으로 구현할 것인가”를 지원한다.

 

예를 들어 안전 관련 입력 신호를 처리하는 SWC를 만들고, Watchdog을 설정하고, DEM으로 Fault를 기록하고, DCM으로 진단 응답을 제공하는 구조는 AUTOSAR 환경에서 자주 구현된다.

 

즉, ISO 26262가 요구하는 안전 목표를 AUTOSAR 아키텍처 위에서 구현하는 형태가 많다.

 

실무에서 자주 보는 기능 안전 예시

 

1. 센서 이중화

: 중요 센서는 하나만 사용하지 않고 두 개 이상의 값을 비교한다. 값 차이가 크면 Fault로 판단한다.

 

2. Watchdog

: 소프트웨어가 멈추거나 무한 루프에 빠졌을 때 MCU를 리셋하거나 안전 모드로 전환한다.

 

3. Range Check

: 입력 값이 물리적으로 불가능한 범위이면 오류로 처리한다.

 

4. Timeout Check

: CAN 메시지가 일정 시간 이상 수신되지 않으면 통신 이상으로 판단한다.

 

5. Safe State

: 이상 발생 시 모터 정지, 출력 차단, 제한 모드 진입 등 안전한 상태로 이동한다.

 

이러한 기능들은 모두 ISO 26262 철학과 연결된다.

 

개발자가 ISO 26262를 꼭 알아야 할까?

 

반드시 심사원 수준으로 깊게 알 필요는 없지만, 자동차 소프트웨어 개발자라면 기본 개념은 이해하는 것이 매우 중요하다. 이유는 명확하다.

 

- 요구사항 문서에 ASIL 용어가 자주 등장한다.

- 테스트 케이스 작성 시 안전 관점 검증이 필요하다.

- 코드 리뷰에서 방어 로직이 요구된다.

- 고객사 대응 문서에 기능 안전 항목이 포함된다.

- AUTOSAR 프로젝트에서도 Safety 설계가 빈번하다.

 

즉, ISO 26262를 모르면 코드는 작성할 수 있어도 프로젝트 전체 맥락을 이해하기 어렵다.

 

처음 공부할 때 무엇부터 보면 좋을까?

 

처음부터 표준 원문 전체를 보는 것은 부담이 크다. 아래 순서로 접근하는 것이 효율적이다.

 

1. 기능 안전 개념 이해
2. Hazard와 Risk 개념 이해
3. ASIL 등급 이해
4. 안전 요구사항 흐름 이해
5. 실제 ECU 사례 분석
6. AUTOSAR Safety 기능 연결 학습

 

이렇게 공부하면 실무 적용 감각까지 빠르게 익힐 수 있다.

 

정리

 

ISO 26262는 자동차 전기·전자 시스템의 기능 안전을 위한 국제 표준이며, 차량 내 소프트웨어와 하드웨어 오류가 사람에게 위험을 주지 않도록 개발하는 방법을 정의한다. 핵심은 오류를 완전히 없애는 것이 아니라, 오류가 발생해도 위험한 결과로 이어지지 않게 만드는 것이다.

 

현재 자동차 산업에서 ECU, ADAS, 브레이크, 조향, 배터리 시스템 등 대부분의 핵심 기능은 전자 제어 기반으로 동작하기 때문에 ISO 26262의 중요성은 계속 커지고 있다. 특히 AUTOSAR 기반 개발 환경에서도 기능 안전 개념은 매우 자주 등장한다.

 

자동차 소프트웨어 개발자로 성장하고 싶다면 ISO 26262는 선택이 아니라 필수 기초 지식이라고 볼 수 있다.