MISRA C 완전 가이드 — 자동차 소프트웨어 코딩 표준의 모든 것

MISRA C, 왜 자동차 개발자라면 피할 수 없는가

자동차 소프트웨어 개발을 하다 보면 MISRA C라는 이름을 안 들어볼 수가 없습니다. 코드 리뷰에서, 정적 분석 도구 설정에서, OEM 납품 요구사항에서 — 어디서든 등장합니다. 솔직히 말해서, 처음 접하면 "규칙이 왜 이렇게 많아?"라는 생각부터 듭니다. 225개 가이드라인이라니, 부담스러운 게 당연합니다.

MISRA C는 Motor Industry Software Reliability Association에서 만든 C 언어 코딩 가이드라인입니다. 1998년에 처음 나왔고, 원래 목적은 명확합니다. C 언어가 가진 모호한 동작(undefined behavior), 구현 의존적 동작(implementation-defined behavior)을 피해서 안전하고 이식성 높은 코드를 작성하자는 것입니다.

C 언어는 프로그래머에게 엄청난 자유도를 줍니다. 하지만 그 자유도가 곧 위험입니다. 평가 순서가 정의되지 않은 표현식, 경계 검사 없는 포인터 연산, 데이터를 조용히 잘라버리는 암묵적 형변환 — 일반 애플리케이션에서는 그냥 넘어갈 수 있는 문제들이 자동차에서는 치명적입니다.

자동차 ECU에 들어가는 소프트웨어는 사람의 생명과 직결됩니다. 브레이크 제어, 에어백 전개, 조향 보조 — 이런 기능의 소프트웨어에서 undefined behavior가 발생하면 어떻게 될까요? 브레이킹 알고리즘의 미묘한 정수 오버플로우, 에어백 제어기의 초기화되지 않은 변수 — 이런 것들이 실제 사고로 이어질 수 있습니다. 그래서 MISRA C는 자동차 업계에서 사실상 필수 코딩 표준이 되었고, 항공, 의료기기, 철도 분야까지 확산되었습니다.

MISRA C의 역사: 1998부터 2025까지

MISRA C의 발전 과정을 알면 현재 버전을 이해하는 데 도움이 됩니다.

MISRA-C:1998 — 시작

최초 버전입니다. C90(ANSI C)을 기반으로 127개의 규칙을 정의했습니다. 자동차 업계에서 C 언어 코딩 표준의 필요성을 공식화한 첫 번째 시도였습니다.

MISRA-C:2004 — 체계화

142개 규칙으로 확장되면서 규칙 분류 체계가 정리되었습니다. Required(필수)와 Advisory(권고)로 나뉘었고, 자동차 업계를 넘어 항공, 의료, 철도 등 안전 관련 산업으로 확산되기 시작했습니다.

MISRA C:2012 — 현대화

143개 규칙과 16개 디렉티브(Directive)로 구성되었습니다. C99 지원이 추가되었고, 규칙 분류가 Mandatory(절대 필수), Required(필수), Advisory(권고) 3단계로 세분화되었습니다. 규칙과 디렉티브를 분리한 것이 큰 변화입니다. 디렉티브는 정적 분석 도구만으로는 자동 검증이 어려운, 개발 프로세스 차원의 가이드라인입니다.

MISRA C:2023 — C11/C18 통합

MISRA C:2012의 세 번째 에디션(second revision)으로, 이전에 나온 모든 Amendment와 Technical Corrigendum을 하나로 통합한 롤업 버전입니다. 약 200개의 규칙과 21개의 디렉티브, 총 221개의 가이드라인을 포함합니다. C90, C99에 더해 C11/C18까지 지원 범위를 넓혔습니다.

특히 Amendment 4(AMD4)에서 추가된 멀티스레딩 관련 규칙(Rules 22.11~22.20)과 atomic 연산 규칙이 중요합니다. 멀티코어 프로세서가 보편화된 자동차 ECU 환경에서, 동시성 관련 코딩 표준이 드디어 공식화된 것입니다.

MISRA C:2025 — 최신 버전

2025년에 출시된 최신 버전입니다. 4개의 새로운 규칙이 추가되고 2개가 제거되어, 총 약 225개의 활성 가이드라인을 포함합니다.

실무적으로 가장 주목할 변화가 두 가지 있습니다. 첫째, 오랫동안 논란이 있었던 "single point of exit" 규칙이 disapplied(비적용) 처리되었습니다. 함수에서 return을 하나만 써야 한다는 규칙인데, 현실적으로 코드 가독성을 떨어뜨리는 경우가 많아서 실무자들의 반발이 컸습니다. 둘째, AI가 생성한 코드도 사람이 작성한 코드와 동일한 기준으로 취급한다는 방침이 명시되었습니다. AI 코딩 도구 사용이 늘어나는 상황을 반영한 것입니다.

규칙 분류: Mandatory, Required, Advisory

MISRA C의 규칙은 세 가지 등급으로 나뉩니다. 이 분류를 이해하는 것이 실무 적용의 첫걸음입니다.

Mandatory (절대 필수)

어떤 상황에서도 반드시 준수해야 합니다. 편차(deviation)도 허용되지 않습니다. undefined behavior를 직접적으로 유발하는 코드 패턴을 금지하는 규칙들이 여기에 해당합니다. 수는 적지만 절대로 위반해서는 안 됩니다.

Required (필수)

원칙적으로 준수해야 하지만, 정당한 사유가 있으면 편차를 문서화하여 예외 처리할 수 있습니다. 대부분의 규칙이 이 등급입니다. 핵심은 "편차를 인정하되 반드시 기록하라"는 것입니다. 왜 이 규칙을 위반했는지, 위반으로 인한 리스크는 무엇인지, 어떤 대안 조치를 했는지를 문서로 남겨야 합니다.

Advisory (권고)

좋은 코딩 관행으로 권장되지만, 준수가 강제되지는 않습니다. 다만 프로젝트 방침에 따라 Advisory를 Required로 격상시키는 경우도 있으니, 프로젝트별 MISRA 준수 정책을 확인해야 합니다.

실무에서 겪는 문제는 따로 있다

MISRA C의 개념을 이해하는 것과 실제 프로젝트에 적용하는 것은 완전히 다른 얘기입니다. 현실적으로 겪는 문제들을 짚어보겠습니다.

레거시 코드와의 충돌

신규 프로젝트에서는 처음부터 MISRA C를 적용할 수 있지만, 문제는 기존 코드입니다. 수만 줄, 수십만 줄의 레거시 코드에 MISRA C를 소급 적용하면 위반 사항이 수천 건씩 쏟아집니다. 전부 수정하는 것은 일정상 불가능하고, 어디서부터 손을 대야 할지 우선순위를 정하는 것 자체가 큰 일입니다. 현실적으로는 리스크 기반 접근이 필요합니다. Mandatory 위반부터 잡고, 안전 관련 모듈의 Required 위반을 그다음 우선순위로 놓는 식입니다.

정적 분석 도구 간 차이

같은 MISRA C 규칙이라도 정적 분석 도구마다 검출 결과가 다릅니다. A 도구에서는 위반으로 잡히는 패턴이 B 도구에서는 통과되기도 합니다. 도구마다 규칙 해석 범위와 검출 방식이 다르기 때문입니다. OEM이 특정 도구를 지정하는 경우도 있어서, 도구 선정과 설정이 중요합니다. 프로젝트 초반에 도구 기준선을 명확히 잡아두지 않으면, 최종 납품 직전 컴플라이언스 감사에서 예상치 못한 문제가 터집니다.

디렉티브의 모호함

규칙(Rule)은 비교적 명확합니다. "이런 코드를 쓰지 마라"고 구체적으로 정의되어 있으니까요. 반면 디렉티브(Directive)는 "동적 메모리 할당을 사용하지 마라", "어셈블리 코드를 캡슐화하라" 같이 프로세스 차원의 가이드라인이라 해석의 여지가 있습니다. 팀 내에서 디렉티브 해석을 통일하는 작업이 필요합니다.

편차 관리의 부담

Required 규칙을 위반할 때마다 편차 기록(Deviation Record)을 작성해야 합니다. 규모가 큰 프로젝트에서는 수백 건의 편차를 관리해야 하는데, 이 자체가 상당한 공수입니다.

MISRA C++:2023 — C++ 개발자도 알아야 할 것

C++로 자동차 소프트웨어를 개발하는 경우도 점점 늘고 있습니다. 2023년 10월, MISRA C++:2023이 출시되었습니다. 기존 MISRA C++ 2008과 AUTOSAR C++14 가이드라인을 통합하여, C++17을 타겟으로 179개의 규칙을 정의합니다.

이전에는 MISRA C++ 2008과 AUTOSAR C++14가 별도로 존재해서 어떤 것을 따라야 할지 혼란이 있었는데, MISRA C++:2023이 이를 하나로 정리했습니다. C++17의 주요 기능(structured bindings, std::optional, if constexpr 등)에 대한 가이드라인이 포함되어 있어, 최신 C++ 문법을 활용하면서도 안전한 코드를 작성할 수 있습니다.

ISO 26262와 MISRA C의 관계

ISO 26262(기능안전 국제 표준)는 코딩 단계에서 적절한 코딩 가이드라인의 사용을 요구합니다. ISO 26262 Part 6, Table 1에서는 ASIL(Automotive Safety Integrity Level)에 따라 코딩 표준 적용을 권장하는데, MISRA C가 사실상 이 요구사항을 충족하는 대표적인 코딩 표준입니다.

즉, ISO 26262 인증을 받으려면 MISRA C(또는 동등 수준의 코딩 표준)를 적용했음을 증명해야 합니다. ASPICE CL2 이상을 요구하는 OEM은 거의 예외 없이 MISRA C 준수도 함께 요구합니다. 두 표준은 상호 보완적입니다. ASPICE가 개발 프로세스의 품질을 보장한다면, MISRA C는 코드 수준의 안전 규율을 보장합니다. 둘 다 갖추어야 OEM 납품 요건을 충족할 수 있습니다.

AI 시대의 MISRA C 적용

2025~2026년 현재, 자동차 소프트웨어 개발에 AI 도구의 활용이 빠르게 확산되고 있습니다. 코드 생성, 코드 리팩토링, 정적 분석 결과 자동 수정 등에 AI가 적용되고 있는데, 여기서 중요한 질문이 나옵니다. AI가 생성한 코드도 MISRA C를 준수해야 하는가?

MISRA C:2025에서 명확하게 답을 내렸습니다. AI가 생성한 코드든 사람이 작성한 코드든, 동일한 규칙을 적용합니다. 코드의 출처가 아니라 코드 자체의 품질이 중요하다는 것입니다.

이 방침은 실무적으로 두 가지를 의미합니다. 첫째, AI 코딩 도구를 사용하더라도 MISRA C 검증 프로세스는 그대로 유지해야 합니다. 둘째, AI 도구가 처음부터 MISRA C를 준수하는 코드를 생성할 수 있다면 검증 부담이 크게 줄어듭니다.

PARVIS-Coder: AI로 MISRA C 자동 적용

PopcornSAR의 PARVIS-Coder는 바로 이 문제를 해결합니다. AI 기반 코드 리팩토링을 통해 MISRA C 규칙을 자동으로 적용하는 도구입니다.

실제 프로젝트에서 MISRA C 준수율을 40%에서 94%로 끌어올린 사례가 있습니다. 기존 레거시 코드에 MISRA C를 소급 적용할 때, 수동으로 하면 수주에서 수개월이 걸리는 작업을 AI가 자동으로 처리합니다. 물론 자동 수정 결과는 엔지니어가 리뷰해야 하지만, 초기 수정 작업의 공수가 대폭 줄어듭니다.

PARVIS-Verify는 MISRA C 준수를 고려한 테스트 코드를 자동 생성하고, PACON IDE는 개발 환경에서 코딩 규칙 검사를 통합 제공합니다. 설계 단계부터 검증까지 MISRA C 준수를 일관되게 유지할 수 있는 환경입니다.

MISRA C 적용이나 자동화 도구에 대해 더 알고 싶으시다면, PARVIS 제품 페이지에서 자세한 내용을 확인하시거나 문의하기를 통해 편하게 상담해 주세요.