(A-SPICE 2회차) ISO 26262와 A-SPICE는 무슨 사이? – 안전과 프로세스의 케미 이야기

🧯 2회차: ISO 26262와 A-SPICE는 무슨 사이? – 안전과 프로세스의 케미 이야기

"ISO 26262는 Safety, A-SPICE는 Process. 그럼 둘이 같이 놀 수 있어요?"

🎬 오프닝: 이 둘은 친구일까, 상사와 부하일까?

자동차 소프트웨어 업계에선 늘 이런 말이 오갑니다.

"우리는 ISO 26262 인증도 따야 하고, A-SPICE도 올라가야 하고…
이거 그냥 시험 치라고 만든 거 아냐?"

🤯 헷갈릴 수 있어요.
하지만 이 둘의 관계를 이해하면,
“아~ 이래서 둘 다 필요한 거구나” 하고 무릎을 치게 됩니다.

---

⚙️ ISO 26262: 기능 안전을 위한 법칙서 📜

먼저, ISO 26262는 자동차 기능 안전(Functional Safety)을 다루는 국제표준이에요.

• 자동차 전자시스템이 오작동하면 생명을 위협할 수 있으니,
• “고장나도 안전한 시스템을 어떻게 만들까?”를 고민하는 철학이죠.

즉, ISO 26262는 “안전 중심”입니다.

예:

• 위험 분석 (HARA)
• 안전 목표 도출
• ASIL 결정
• 시스템 설계/SW설계/HW설계에 안전 기법 적용 등등…

---

🧭 A-SPICE: 프로세스를 만드는 메뉴판 📋

반면에 A-SPICE는 “어떻게 일할 건데?”를 정리해주는 프로세스 관리 표준이에요.

예:

• 요구사항은 어디에 정리해?
• 코드 리뷰는 누가, 언제 하지?
• 테스트 케이스는 어떻게 만들고 관리하지?

즉, A-SPICE는 “절차 중심”입니다.
좋은 품질을 일관되게 내기 위한 회사의 운영 철학이라고 할 수 있어요.

---

🔗 그럼 둘은 어떻게 연결돼?

🎯 요약하자면:

• ISO 26262는 “무엇을 해야 안전한가”를 말하고,
• A-SPICE는 “그걸 어떻게 일관되게 실현할 것인가”를 말합니다.

둘은 목적이 같아요.
“신뢰할 수 있는 자동차 시스템을 만든다”
그 목적을 안전 중심 vs 절차 중심으로 접근하는 것뿐!

---

🧩 예제로 보는 두 표준의 콜라보

단계	ISO 26262에서 요구하는 것	A-SPICE에서 뒷받침하는 프로세스
시스템 위험 분석	HARA 분석 및 ASIL 지정	SYS.1 요구사항 분석 프로세스
기술 안전 요구사항 작성	TSC 문서화	SYS.2 시스템 요구사항 할당
SW 아키텍처 설계	안전기능 분리 구조 설계	SWE.2 소프트웨어 아키텍처
테스트 및 검증	안전 목표 기반 검증 수행	SWE.4, SWE.5, SWE.6의 테스트 프로세스
형상관리	안전 관련 변경 사항 관리	SUP.8 형상 관리 프로세스

요컨대, ISO는 "안전하게 만들어!"
A-SPICE는 "그걸 매번, 빠짐없이, 체계적으로 해!"

---

☕ 커피 타임 – 둘 다 필요한 이유

만약 ISO 26262만 지킨다면?

• "우리는 안전 분석은 잘했어!"
• 그런데 테스트 케이스가 문서화 안 되어 있고,
• 요구사항이 버전에 따라 다르고,
• 아키텍처 변경 로그가 없어요…

💥 이러면 결국 인증 못 받습니다.

반대로 A-SPICE만 잘하면?

• 프로세스는 완벽!
• 근데 정작 “안전은 고려 안 했어요”…? 🤔

💥 이것도 문제입니다.

---

🎯 오늘의 핵심 요약

ISO 26262는 '왜', A-SPICE는 '어떻게'

둘은 경쟁자가 아니라 짝꿍입니다.
진짜 좋은 개발자는 이 두 시스템을 같이 다룰 줄 아는 사람이죠!

---

📌 다음 회차 예고

3회차에선
“A-SPICE 심사, 도대체 어떻게 진행되는 걸까?”를 다룹니다.

• CL이 뭔데?
• 평가 기준은 어떻게 나눠져 있어?
• 실무자들은 뭘 준비해야 하지?

👉 이거 알아야 회의 때 눈치 안 보입니다 😉
그럼 다음 회차에서 만나요!