소프트웨어 결함이 어떻게 시스템 고장으로 전파되는지, 그리고 그 전파 사슬을 어디서 끊을 것인지에 대한 4가지 안전 확보 컨셉.
결함 전파 (Fault Propagation)
System Hierarchy를 따라 결함이 사고·피해로 확장되는 7단계 체인:
| 용어 | 설명 | 예시 |
|---|---|---|
| Mistake (실수) | 사람이 실수로 결함을 주입하는 행위 | 반복문 종료 조건 잘못 명시 |
| Fault (결함) | 오류를 일으킬 수 있는 비정상적인 상태/조건 | 무한루프 발생 상태 (while(1)) |
| Error (오류) | 명세된 결과와 처리 결과의 불일치 | 명세는 10회 반복인데 실제는 무한루프 |
| Failure (고장) | 상위 시스템에서 요구된 기능을 수행하지 못함 | 제어기에서 SW가 요구된 기능을 수행하지 못함 |
| Hazard (위험원) | 시스템 고장이 만들어 내는 잠재적 위험 상태 | 브레이크 제어기 미응답으로 제동 불가 |
| Accident (사고) | Hazard가 외부 요인과 결합해 실제 발생한 사건 | 추돌 사고 발생 |
| Harm (피해) | 사고가 사람·재산에 끼친 최종 손해 | 인명 사상, 차량 파손 |
→ 어느 단계에서 사슬을 끊을 것인지에 따라 안전 확보 방법이 달라진다. 사슬을 빨리 끊을수록 비용이 작다.
대표 사례: 소프트웨어 결함 사고 사례 (Therac-25, Ariane 5, Boeing 737 MAX, Toyota 급발진, Tesla, Uber 등).
자동차 SW 규모와 결함 잠재량
| 시스템 | 규모 |
|---|---|
| F22 Raptor | 1.7 MLOC |
| F-35 Joint Strike Fighter | 5.7 MLOC |
| Boeing 787 Dreamliner | 6.5 MLOC |
| Modern Premium Car | 100 MLOC, 70-100 ECUs |
- Best US Software Companies 결함 밀도: 8-12 Defects / 1K SLOC (Code Complete, Steve McConnell 2004)
- → 자동차에 100M LOC × 10 defects/KLOC = 약 100만 결함 잠재
눈덩이 효과
개발 단계별 결함 수정 비용은 후반 단계로 갈수록 기하급수적으로 증가.
| 단계 | 비용 배수 |
|---|---|
| 요구분석 | 1배 |
| 설계 | 2-6배 |
| 구현 | 10배 |
| 통합 테스트 | 15-40배 |
| 시스템 테스트 | 30-70배 |
| 현장운영 | 40-1000배 |
출시 이후 결함 수정은 개발 초기 단계 수정 대비 40-1000배 비용 소요.
Shift Left
결함 발견·수정을 V-Model 좌측(개발 초기 단계)으로 당기는 원칙. 정적 V&V·코딩 표준·인스펙션·CI에서의 정적 분석 등을 통해 비용 누적을 차단.
소프트웨어 안전 확보 컨셉 4가지
| 구분 | 설명 | 예시 |
|---|---|---|
| Fault Prevention (결함 예방) | 사람이 실수하지 않도록 방지 | 코딩 표준 준수, Strongly Typed 언어 사용, 정적/동적 테스팅, 코드 리뷰 |
| Fault Detection (결함 검출) | 결함을 검출하기 위한 방법 | 디버깅 |
| Fault Removal (결함 제거) | 검출된 결함을 제거하기 위한 방법 | 디버깅 |
| Fault Tolerance (결함 허용) | 런타임에 결함이 발생해도 오류·고장으로 이어지지 않도록 함 | Redundancy Design, Diversity Design |
Redundancy와 Diversity
| 구분 | 의미 | 예시 |
|---|---|---|
| Redundancy | 특정 기능을 수행하기 위해 동일한 방식으로 설계 | 동일 Failure Rate의 CPU 2개. 동일 입력에 동일 알고리즘을 여러 번 적용해 결과 비교 |
| Diversity | 특정 기능을 수행하기 위해 다양한 방식으로 설계 | 다른 Failure Rate의 CPU 2개. 동일 입력에 다른 알고리즘 적용해 결과 비교 |
사례: Airbus Flight Control System
주 시스템과 보조 시스템에 서로 다른 채널·필터·출력 구조를 적용 → Diversity 구현.
사례: Ariane 5호 폭발 (1996)
Redundancy는 만족하지만 Diversity는 불만족.
The fault was caused by a software systems failure. There was a backup system but it was not diverse, and so the software in the backup computer failed in exactly the same way. The rocket and its satellite payload were destroyed.
→ 발사 37초 만에 폭발. 동일한 SW로 백업하면 동일한 방식으로 함께 실패한다는 교훈. 다른 사례는 소프트웨어 결함 사고 사례 참조.
SW Diversity 구현 방법
N-version 프로그래밍을 통해 구현 가능. 다양성을 만드는 방법:
- 다양한 알고리즘 사용 (예: Quick Sort vs Bubble Sort)
- 다양한 팀/개발자에 의한 개발
- 다양한 프로그래밍 언어 사용
- 다양한 설계 기법 사용
- 다양한 개발 도구 사용
→ 결과 비교 및 채택.
결함 검출 기법 예시 (ISO 26262 Part 6 적용)
센서 유효 영역 검사
- 센서 입력 값 중 유효 범위 밖의 값을 검출
- 유효 영역 검사기 → 임계값보다 크거나 작으면 오류로 판단 → 고장 처리기로 전달
메시지 타임아웃 모니터링
- 통신 버스로부터 입력되는 메시지의 타임아웃으로 지연·누락 오류 검출
- 예: 타임아웃 500ms인 메시지를 10ms 주기로 모니터링
Fault Injection Testing
시스템이 정상 동작하는 상황에서 비정상 조건을 강제로 주입하여 예외 상황에 대한 시스템의 반응을 테스팅하는 방법
// [기존 코드]
while(i <= 10) { ... }
// [변경된 코드 - 연산자 변경]
while(i > 10) { ... } // 결함을 주입해 시스템 반응 확인