01. MISRA-C란 무엇인가?
MISRA-C = Motor Industry Software Reliability Association – C
*자동차 산업 소프트웨어 신뢰성 협회: 자동차용 임베디드 소프트웨어의 안정성을 높이기 위한 산업 협의체
MISRA-C는 자동차 산업 소프트웨어 신뢰성 협회에서 만든 C 언어 코딩 표준으로,
임베디드 시스템에서 C언어의 안전성 신뢰성 이식성을 확보하기 위해 만들어진 규칙 모음이다.
02. MISRA-C가 등장한 이유
자동차는 사람 생명과 바로 연결되기 때문에 “개발자가 잘하면 된다”가 아니라
애초에 위험한 코드 자체를 못 쓰게 제한해야 한다는 발상이 필요했다.
→ 사전에 사고 가능성을 제거해야 하는 시스템
위험 요인
- 자동차 시스템의 복잡성 증가
- 차량 내부에는 여러 ECU(Electronic Control Unit, 전자 제어 장치)가 있고, 각각이 센서와 연결되어 차량 동작을 제어
- 이 ECU들은 소프트웨어로 동작하며, 소프트웨어 오류가 직접적인 사고 위험으로 연결될 수 있다.
- C 언어의 특성
- C는 하드웨어 제어에 유리하지만 포인터, 동적 메모리, 배열 범위 초과 등으로 인해 메모리 오류, 버퍼 오버플로우, 정의되지 않은 동작이 쉽게 발생한다.
- 자동차 같은 시스템에서는 이런 오류를 막기 위해 안전한 코딩 가이드라인이 필요했다.
- 정의되지 않은 동작(Undefined Behavior, UB) 방지
- UB는 컴파일러마다 동작이 달라질 수 있어 예측 불가능
- MISRA‑C 규칙은 UB를 일으킬 수 있는 코딩 패턴을 제한하여, 안전한 소프트웨어를 만들도록 한다.
- 기능 안전(Functional Safety) 표준화
- ISO 26262 같은 자동차 기능 안전 표준에서는 소프트웨어 설계, 개발, 검증 과정에서 위험 관리가 요구된다.
- MISRA‑C는 이를 충족시키는 실질적인 코딩 규칙을 제공함으로써, 표준 준수와 안전성 확보를 도움
임베디드 특징
- 실시간 처리
- 하드웨어 직접 연결
- 한 번 오류가 발생하면 사람의 생명이나 장비가 위험
따라서 위험한 코드 형태를 만들지 못하게 하는 규율이 MISRA가 말하는 코드 안전성이다.
실수 자체를 못 하게 만든다 → 모든 코드가 분석 가능한 상태로 유지된다 → 결과적으로 안전하고 예측 가능한 시스템이 된다.
03. MISRA-C는 어떻게 안전성을 확보하는가?
MISRA-C 안전성 확보 원리
- 위험한 C 기능 제한
- C 언어는 메모리 접근과 포인터 연산을 자유롭게 할 수 있어서 오류가 생기면 하드웨어 오동작으로 이어진다.
- 포인터 연산 제한, 암묵적 타입 변환 금지, 매크로 남용 제한
- 재귀 호출 대부분 금지 → 실행 결과 예측 가능
- 정적 분석 가능 구조
- MISRA-C 규칙 대부분은 정적 분석 도구가 코드를 자동으로 검사할 수 있도록 설계되어 있다.
- 복잡한 제어문 제한, 전역 상태 최소화, break/continue 남용 금지
- 단순화된 구조 → 전체 실행 경로 분석 가능
- 일관된 코딩 스타일 강제
- 코딩 스타일이 제각각이지만, MISRA는 스타일을 강제한다.
- 조건문 괄호, 변수 초기화, 파라미터 형식 통일
- 사람이나 도구가 오류 쉽게 발견 가능
- Deviation(예외) 문서화
- 특정 규칙을 어겨야만 하는 경우가 존재하기 때문에 MISRA는 예외를 허용하되 문서화를 의무화한다.
- 규칙 위반 필요 시: 이유, 안전성 검증 문서 작성 → 심사, 승인 후 허용
04. 코드 작성 가이드라인 규칙(Rule) & 지침(Directives)
Rule: 코드 작성 시 준수해야 하는 기술적 규칙, 정적 분석 도구로 검증 가능
Directive: 코드 자체가 아닌 안전성, 문서, 프로세스 규정, 안전 요구사항 추적성 확보, Deviation 문서 필수
MISRA-C 규칙 영역별 분류(Rule Categories)
| 영역 번호 | 영역 내용 | 주요 규칙 | 준수 수준 |
|---|---|---|---|
| Directive | Directive (지침) | 문서화, 안전 요구사항, Deviation | Required / 일부 Mandatory |
| 2.x | Comments (주석) | 중첩 주석 금지, 잘못된 주석 금지 | Required |
| 3.x | Character Sets (문자 집합) | 허용 문자 집합만, 제어 문자 금지 | Required / 일부 Advisory |
| 4.x | Lexical Conventions (어휘 규칙) | 토큰/문자 모호성 금지, 인코딩 준수 | Required |
| 5.x | Identifiers (식별자) | 식별자 충돌 금지, 유사 이름 제한 | Required |
| 6.x | Types (타입) | 타입 일관성, typedef 기준, 부호 관리 | Required |
| 7.x | Literals & Basic Types (기본 타입/리터럴) | 정수 크기/부호 모호성 제거 | Required |
| 8.x | Declarations & Definitions (선언/정의) | 초기화 없는 변수 금지 등 | Required |
| 9.x | Initialization (초기화) | 모든 객체 명확 초기화 | Required |
| 10.x | Implicit Conversions (암묵적 변환) | 암묵적 변환 금지 | Required |
| 11.x | Pointer Conversions (포인터 변환) | 위험 포인터 변환 제한 | Required |
| 12.x | Expressions (표현식) | 연산자 우선순위 의존 금지 | Required |
| 13.x | Evaluation Order & Side Effects (평가 순서/부수효과) | 평가 순서/부수효과 | Required |
| 14.x | Control Flow (제어 흐름) | 깊은 중첩/불명확 흐름 금지 | Required |
| 15.x | Switch Statements (switch 문) | Fall‑through 금지, default 필수 | Required |
| 16.x | Functions (함수) | 반환값 무시 금지 등 | Required |
| 17.x | Memory Access (메모리 접근) | 배열 범위, 임의 메모리 접근 금지 | Required |
| 18.x | Unused / Unreachable Code (미사용/도달불가 코드) | 미사용/도달불가 코드 금지 | Required / 일부 Advisory |
| 19.x | Preprocessor (전처리기) | 매크로 남용 금지 등 | Required |
| 20.x | Standard Library (표준 라이브러리) | 위험 함수/동적 메모리 제한 | Required / 일부 Mandatory |
| 21.x | Runtime Failures (런타임 실패 방지) | 0 나누기, 오버플로우 방지 | Mandatory / Required |
준수 수준(Compliance Level)
MISRA-C 규칙은 안전성과 예측 가능성을 위해 만들어졌지만, 모든 상황에 100% 적용 가능한 규칙은 존재하지 않는다.
준수 강제 정도에 따라 세 가지 수준(Level)으로 분류된다.
| Rule 유형 | 설명 | Deviation 허용 여부 |
|---|---|---|
| Mandatory | 절대적으로 지켜야 하는 규칙, 위반 시 MISRA 준수 불가 | 불가능 |
| Required | 반드시 따라야 하는 규칙, 정당한 근거 문서화시 예외 가능 | 가능, 문서화 필요 |
| Advisory | 권장 사항 | 정책에 따라 선택적 적용 |
*Deviation(예외 처리): 특정 규칙 위반이 불가피할 경우, 그 이유와 안전성을 증명하는 문서를 작성해야 하는 규정이 있다.
05. MISRA-C 규칙을 어떻게 검증하나?
정적 분석 도구 (Static Analysis Tools)
단순히 “사람이 규칙을 잘 지켜라”가 아니라, 모든 코드가 기계적으로 분석 가능해야 한다는 전제를 가진다.
정적 분석 도구를 쓰면 MISRA 규칙 준수 정도를 공통된 기준으로 확인할 수 있기 때문에, 사람 실수를 보완해 품질을 일정 수준 이상으로 강제하는 역할을 한다.
정적 분석이란?
프로그램을 실행하지 않고 소스 코드 자체를 분석해서 오류 가능성을 찾는 기법으로
코드를 실행하기 전에 MISRA 규칙 위반, 정의되지 않은 동작 가능성, 논리적 결함을 사전에 제거하여 ‘사고가 날 수 없는 코드만 남기는 과정’이다.
자동차 기능 안전(ISO 26262)을 충족하기 위한 결함 예방 수단!
왜 실행 하지 않고 검사하는가?
Why? 테스트(run-time)만으로는 부족하고, 굳이 실행 전에(static) 검사를 해야 할까?
→ 동적 분석만으로는 안전성을 보장할 수 없다!
실행 기반 테스트(동적 분석)
- 실제 발생한 오류만 검출할 수 있고, 모든 실행 경로를 검증하는 것은 현실적으로 불가능하다.
- 자동차 SW는 오류 발생 자체가 위험하다.
따라서 MISRA-C는 실행 결과에 의존하는 동적 분석이 아니라, 코드 구조 자체를 검사하는 정적 분석 도구로 검증 가능하도록 설계되었다.
정적 분석 도구 종류
| 도구 | 특징 | MISRA 지원 여부 | 사용 분야 | 라이선스 / 가격 |
|---|---|---|---|---|
| Cppcheck | 무료, 오픈소스, 코드 품질 및 안전 분석 | △ (일부) | 일반 임베디드, 학습용, 오픈소스 프로젝트 | 무료 (오픈소스, GPL) |
| Polyspace | 업계 표준, 품질 우수, 정적/동적 분석 | ◎ | 자동차 ECU, 항공, 산업용 임베디드 | 상용 (유료, MathWorks) |
| PC‑Lint / FlexeLint | MISRA 검사 강력, 코드 품질 분석 | ◎ | 자동차 ECU, 일반 임베디드 | 상용 (유료) |
| Coverity Scan | 보안 취약점 탐지 + MISRA 지원 | ◎ | 대형 SW 프로젝트, 자동차, 보안 분석 | 상용(유료), 오픈소스 프로젝트 무료 옵션 |
| Klocwork | 빠르고 안정적, CI/CD 통합 용이 | ◎ | 자동차, 산업용 임베디드, 대형 IT 프로젝트 | 상용 (유료) |
| QAC | 유럽 OEM/티어1 표준 준수, MISRA 전용 | ◎ | 자동차, 항공, 산업용 안전 시스템 | 상용 (유료) |
MISRA-C는 개발자에 맡겨 지키는 규칙이 아니라, 정적 분석 도구를 통해 객관적이고 반복 가능한 검증이 이루어지도록 설계된 규칙이다.
