Proven by Intelligence
보이지 않는 안전을 인텔리전스로 증명하다.
기술 인사이트를 만나보세요.
MISRA는 “규칙 집합”이 아니라 “선택 가능한 프레임워크”입니다.
MISRA는 임베디드 C/C++ 개발에서 가장 널리 사용되는 코딩 표준입니다.
하지만 많은 개발자들이 오해하는 부분이 하나 있습니다.
MISRA는 모든 규칙을 반드시 지켜야 하는 절대 규칙이 아닙니다."
실제로 대부분의 개발 조직은 전체 규칙을 그대로 적용하지 않고, 프로젝트 특성이나 고객 요구사항에 맞게 필요한 규칙만 선택하여 사용합니다.
즉, MISRA의 핵심은 “완전 준수”가 아니라 “선택적 적용”입니다.
"
왜 MISRA는 호불호가 갈릴까?
MISRA가 “좋기도 하고, 불편하기도 한” 이유는 크게 두 가지입니다.
1. 일부 규칙은 시대에 뒤떨어져 있습니다.
초기 MISRA (예: 2004)는 지금과 비교하면 소프트웨어 규모와 복잡도가 매우 낮던 시기에 만들어졌습니다.
현재의 멀티 플랫폼 (Arm, RISC-V), 멀티 OS (VxWorks, QNX, Zephyr), 대규모 코드베이스와 같은 환경에서는 일부 규칙이 과도하게 제한적으로 느껴질 수 있습니다.
2. 모든 규칙이 동일하게 중요한 것은 아닙니다
MISRA의 규칙을 자세히 보면, 중요도가 서로 완전히 다르다는 것을 알 수 있습니다.
MISRA 규칙은 3가지로 나눠서 봐야 한다
01. 코드 품질 & 가독성 (Bucket 1)
사용하지 않는 매크로 금지 (MISRA C:2025, Rule 2.5)
코드 정리 측면에서는 좋지만 실제 버그와는 직접적인 관련이 없는 경우가 많습니다.
02. 실제 버그 & 정의되지 않은 동작 (Bucket 2)
예:
✔️ Null pointer dereference
✔️ Buffer overflow
✔️ Undefined behavior
이 영역은 절대 타협하면 안 됩니다.
반드시 수정해야 하는 “핵심 영역”입니다.
03. 잠재적 런타임 오류 (Bucket 3)
예:
✔️ 타입 축소 (narrowing conversion)
항상 문제는 아니지만, 위험 가능성이 존재합니다.
설계에 따라 문제 없을 수도 있습니다.
멀티 플랫폼 프로젝트로 예를 들면, 특정 환경에서는 일부 매크로가 사용되지 않을 수 있습니다. (MISRA Rule 2.5 위반)
하지만 실제로는 의도된 설계이거나, 유지보수가 필요한 케이스일 수 있습니다.
이런 경우까지 무조건 제거하는 것은 오히려 비효율적일 수 있습니다.
그럼 어떻게 적용하는 게 현실적일까요?
"
바로, 프로젝트 성격에 따라 접근이 달라져야 합니다.
"
📌 안전 필수 시스템 (자동차, 항공)
✔️ MISRA 전체 적용 (Bucket 1~3)
✔️ 예외 최소화
✅ 안전이 최우선
📌 일반 임베디드 / 산업용 시스템
✔️ Bucket 2 + 3 중심 적용
✔️ Bucket 1은 선택
✅ 효율성과 안전의 균형
그렇다면, 정적 분석 도구는 어떻게 활용해야 할까요?
정적 분석 도구는 설정에 따라 완전히 다른 결과를 낼 수 있습니다.
🛠️ 엄격 모드 (자동차, 항공 등)
✔️ 모든 MISRA 규칙 검사
✔️ 경고 다수 발생
🛠️ 실용 모드 (일반 임베디드/산업용 시스템)
✔️ 실제 런타임 오류 가능성 중심
✔️ False Positive 감소
핵심 기술: “경로 기반 분석”
현대 정적 분석 도구는 단순 규칙 체크를 넘어서 다음과 같은 분석을 수행합니다.
🔍 데이터 흐름 분석
🔍 제어 흐름 분석
🔍 추상 해석 (Abstract Interpretation)
이러한 심층적인 흐름 기반 정적 분석 기법을 통해 “실제로 문제가 발생할 수 있는 코드 경로”를 식별할 수 있습니다.
이 과정에서는 변수 값과 해당 값이 실행 경로 및 잠재적인 문제에 미치는 영향을 함께 고려하게 되며, 특히 추상 해석(Abstract Interpretation) 기법은 Buffer Overrun, Underrun과 같은 정의되지 않은 동작을 탐지하는 데 매우 효과적입니다.
MDS인텔리전스는 이러한 분석 기법을 기반으로, C/C++ 코드에서 반드시 수정이 필요한 메모리 및 타입 관련 문제를 식별할 수 있도록 지원합니다.
또한 프로젝트의 목적과 요구사항에 따라 분석 수준을 조정하여, 단순 규칙 위반이 아닌 실제 런타임 오류 가능성에 초점을 맞춘 분석 환경을 구성할 수 있도록 제공합니다.
MISRA 전체를 적용하지 않더라도 Bucket 2 + 3 중심으로 적용하면 “더 안전한 C/C++”를 만들 수 있습니다.
결론: MISRA는 “유연하게” 써야 한다
MISRA는 규칙을 강요하는 표준이 아니라 리스크를 관리하기 위한 도구입니다.
✅ MISRA는 전부 적용할 필요 없다
✅ 규칙은 중요도에 따라 구분해야 한다
✅ 가장 중요한 것은 Bucket 2 (실제 버그)
✅ Bucket 3는 상황에 따라 판단
✅ Bucket 1은 선택 적용 가능
"
결국 중요한 것은 “표준 준수”가 아니라 “실제 위험 제거”입니다.
"
출처 : https://www.adacore.com/blog/misra-for-memory-safety
MDS 인텔리전스는 이러한 차이를 고려하여 산업군별, 프로젝트별 맞춤형 MISRA 적용 전략과 정적 분석 환경 커스터마이징을 제공합니다.
단순히 도구를 도입하는 것을 넘어, 고객 환경에 맞는 규칙 선정과 분석 설정을 통해 불필요한 경고를 줄이고 실제 리스크에 집중할 수 있도록 지원합니다.
결론적으로 중요한 것은 모든 규칙을 지키는 것이 아니라, 실제로 문제가 될 수 있는 위험을 정확하게 식별하고 제거하는 것입니다. MISRA는 이를 위한 도구이며, 상황에 맞게 유연하게 활용하는 것이 가장 효과적인 접근입니다.
📧 codesonar@mdsit.co.kr ✍️ 문의남기기
