MISRA Compliance 2020: 어떻게 MISRA를 준수할 수 있을까? (MISRA 준수 방법)

목차

1. MISRA 준수를 위한 소프트웨어 개발 프로세스: 핵심 요소와 도구 관리

MISRA 규칙 준수는 안전하고 신뢰성 있는 소프트웨어를 개발하는 데 중요한 기준입니다. 소프트웨어 개발 과정에서 MISRA 규칙을 올바르게 적용하기 위해서는 체계적인 개발 계약, 프레임워크 설정, 교육, 스타일 가이드, 메트릭스, 도구 관리 등 다양한 요소들이 필요합니다. 이번 글에서는 MISRA Compliance 2020의 섹션 2에서 다루는 소프트웨어 개발 프로세스의 각 주요 요소를 설명하고, 도구 관리에 대해서는 하위 항목별로 구체적으로 살펴보겠습니다.

 

1.1. 개발 계약 (Development Contract)

개발 계약(The Development Contract)은 프로젝트가 시작될 때, MISRA 규칙 준수를 명확히 하기 위한 법적 또는 비공식적 합의를 의미합니다. 이 계약은 고객과 개발자가 프로젝트의 MISRA 준수 목표를 정의하고, 규칙 준수를 위한 구체적인 절차를 합의하는 문서입니다. 개발 계약은 명확하고 상세하게 작성되어야 하며, 초기 단계에서 고객과 합의함으로써 나중에 발생할 수 있는 충돌을 방지할 수 있습니다. 프로젝트의 복잡도에 따라 계약 내용을 구체적으로 정의하는 것이 좋습니다. 개발 계약은 다음과 같은 항목을 포함합니다:

• MISRA 준수의 범위: 규칙의 적용 범위와 어느 부분에서 예외가 있을지 결정.
• Deviation 관리 절차: 규칙 위반이 불가피한 경우, Deviation을 어떻게 처리할지에 대한 계획.
• 품질 보증: 개발 과정에서 사용할 도구, 테스트 방법, 검토 절차 등을 정의하여 소프트웨어의 품질을 보장하는 조항.

1.2. 프레임워크 (Framework)

프레임워크(The Framework)는 소프트웨어 개발 프로세스에서 모든 절차가 일관되게 관리될 수 있도록 돕는 체계적인 구조입니다. 프레임워크는 MISRA 규칙 준수를 위한 주요 단계를 정의하고, 각 단계에서 필요한 활동과 도구를 명확히 설명합니다. 프레임워크는 조직 내에서 반복적으로 사용할 수 있는 구조를 마련해 주며, 이를 통해 규칙 준수가 자동화될 수 있습니다. 특히, 프로젝트가 커질수록 일관된 프로세스는 필수적입니다. 프레임워크는 다음과 같은 기능을 제공합니다:

• 일관된 프로세스 정의: 프로젝트 전반에 걸쳐 동일한 규칙과 절차가 적용되도록 관리.
• 책임 분담: 각 개발자와 팀의 역할을 명확히 나누어 규칙 준수가 일관되게 진행되도록 지원.
• 프로세스 검토: 각 단계에서 규칙 준수가 올바르게 이루어지고 있는지 검토할 수 있는 절차 제공.

1.3. 교육 (Training)

교육(Training)은 개발자가 MISRA 규칙을 이해하고, 이를 올바르게 적용할 수 있는 능력을 갖추는 데 필요한 과정입니다. MISRA 규칙은 단순히 암기할 대상이 아니라, 그 의도를 이해하고 소프트웨어의 안전성과 신뢰성을 보장하기 위한 방법을 배우는 것이 중요합니다. 교육은 단발성으로 끝나서는 안 되며, 지속적인 학습과 실습을 통해 개발자가 실제 프로젝트에서 문제를 해결할 수 있는 능력을 기르는 것이 중요합니다.

• 규칙 이해: 개발자는 각 규칙의 목적과 중요성을 이해하고, 이를 실제로 어떻게 적용할지 배워야 합니다.
• 도구 교육: 정적 분석 도구나 컴파일러와 같은 도구를 사용하는 방법을 충분히 학습해야 합니다.
• 지속적인 학습: MISRA 규칙은 시간이 지남에 따라 변화할 수 있으므로, 개발자들은 꾸준히 최신 정보를 학습해야 합니다.

1.4. 스타일 가이드 (Style Guide)

스타일 가이드(The Style Guide)는 팀 내에서 코드의 일관성을 유지하기 위한 규칙을 정의한 문서입니다. MISRA 규칙 자체는 스타일을 강제하지 않지만, 코드의 가독성과 유지보수성을 높이기 위해 스타일 가이드를 따르는 것이 매우 중요합니다. 스타일 가이드는 조직 내에서 표준화되어야 하며, 개발자가 이를 잘 따르고 있는지 주기적으로 코드 리뷰를 통해 확인하는 것이 좋습니다. 또한, 프로젝트마다 약간씩 가이드를 조정할 수 있는 유연성도 필요합니다.

• 코드 일관성: 모든 개발자가 동일한 방식으로 코드를 작성하도록 함으로써 코드 리뷰와 유지보수가 더 쉽고 효율적으로 이루어집니다.
• 가독성 향상: 잘 정리된 코드는 오류를 사전에 방지할 수 있으며, 팀 간 협업에서도 중요한 역할을 합니다.

1.5. 메트릭스 (Metrics)

메트릭스(Metrics)는 소프트웨어의 품질을 평가하고 관리하는 데 사용되는 기준입니다. 이는 코드 복잡성, 함수 길이, 코드 중복도 등을 측정하여 소프트웨어의 안정성과 유지보수성을 높이는 데 도움을 줍니다. 메트릭스는 단순히 숫자로만 평가할 것이 아니라, 이를 바탕으로 실제 코드의 개선 방향을 설정하는 데 활용해야 합니다. 특히, 특정 메트릭스 임계점을 넘으면 즉각적인 조치를 취할 수 있는 자동화된 시스템을 구축하는 것이 좋습니다.

• 복잡성 분석: 복잡한 코드는 버그 발생 가능성이 높으므로, 복잡도를 줄이는 방향으로 코드 개선이 필요합니다.
• 품질 관리: 코드 메트릭스를 활용하여 품질 목표를 설정하고, 이를 지속적으로 측정함으로써 소프트웨어의 성능과 안전성을 보장할 수 있습니다.

1.6. 도구 관리 (Tool Management)

도구 관리(Tool Management)는 MISRA 규칙을 준수하기 위해 사용하는 컴파일러, 정적 분석 도구, 테스트 도구 등 각종 도구들을 효과적으로 선택하고, 적절하게 설정하는 과정입니다. 도구 관리는 여러 하위 요소로 구성되며, 각각의 요소를 제대로 관리해야 전체 프로젝트의 성공적인 MISRA 준수를 이끌어낼 수 있습니다. 

먼저 컴파일러 관리는 MISRA 규칙에 맞춰 소프트웨어를 컴파일할 때, 사용하는 컴파일러가 올바르게 설정되었는지 확인하는 것을 의미합니다. 프로젝트에서 사용하는 C 또는 C++ 버전에 맞는 컴파일러 버전을 선택해야 하며, 올바른 설정이 이루어져야 합니다(버전 관리). 또한 컴파일러가 충분한 경고 메시지나 오류 메시지를 생성하도록 설정하여, 코드의 문제를 미리 감지할 수 있게 해야 합니다(진단 정보 생성). 

다음으로 MISRA-C를 준수함에 있어 정적 분석 도구가 사용되는데, 이는 코드를 실행하지 않고도 소스 코드의 구조적 문제나 규칙 위반을 자동으로 탐지하는 도구로, 정적 분석을 위한 각 프로젝트의 요구사항에 맞게 정적 분석 도구를 설정하고, 언어 확장을 사용한 경우에도 이를 처리할 수 있도록 도구를 맞춤화해야 합니다(설정 및 맞춤화). 그런 다음 분석 도구에서 제공하는 경고나 오류를 검토하고, 불필요한 경고는 무시하거나 실제 오류를 해결하는 과정이 필요합니다(결과 검토).

마지막으로 이러한 도구들이 올바르게 검증에 활용되는지를 확인할 필요가 있습니다. 즉, 도구 검증은 사용 중인 도구가 신뢰할 수 있는 결과를 제공하는지 검증하는 단계이므로, 도구 관리에서 중요한 것은 각 도구가 프로젝트 요구사항에 맞게 제대로 설정되고, 도구 간 상호작용에서 발생하는 문제를 미리 방지해야 합니다. 따라서 사용중인 컴파일러와 분석 도구가 MISRA 규칙을 제대로 지원하고 있는지 검증하고, 이를 위한 테스트 계획을 수립해야 합니다. 그리고 여러 도구를 함께 사용할 때, 도구 간 결과가 일치하지 않는 경우가 발생할 수 있으므로, 이를 해결할 수 있는 절차를 마련하는 것이 중요합니다(도구 검증 계획). 도구가 정확하게 동작하는지 지속적으로 모니터링하고, 오류나 잘못된 분석 결과가 발견될 경우 즉각적인 조치를 취해야 합니다(결과 검증).

MISRA 준수를 위한 프로세스 및 도구 체크리스트

---

2. MISRA 준수의 기본 요소: 필수 절차와 고려 사항

MISRA 준수를 위해서는 소프트웨어 개발 과정에서 규칙을 체계적으로 적용하고 관리하는 것이 필수적입니다. 이번 장에서는 지침 분류, 분석 범위, 지침 집행 계획, 메시지 분석, 결정 가능성에 대해 설명하고, 이를 실무에 적용할 때 고려해야 할 사항들을 함께 살펴보겠습니다.

 

2.1. 지침 분류 (Guideline Classification)

MISRA 규칙은 크게 필수(Mandatory), 요구(Required), 그리고 권고(Advisory)로 분류됩니다. 이 분류는 각 규칙의 중요성을 나타내며, 준수 여부에 따라 어떻게 대응해야 하는지를 정의합니다. 이때 각 프로젝트의 특성에 맞춰 규칙을 분류하는 것이 중요합니다. 안전이 가장 중요한 프로젝트라면 권고 규칙도 더 엄격하게 적용할 수 있습니다. 반대로, 성능이나 시간 제약이 우선시되는 경우 권고 규칙을 완화할 수 있습니다. 프로젝트 특성에 맞게 규칙을 유연하게 적용하되, deviation이 발생할 때는 반드시 이를 정당화하는 절차를 마련해야 합니다.

• 필수(Mandatory): 반드시 지켜야 하는 규칙입니다. 이 규칙을 위반하면 심각한 안전성 문제나 시스템 오류가 발생할 수 있습니다.
• 요구(Required): 가능하면 지켜야 하는 규칙입니다. 위반 시에는 반드시 deviation을 기록하고 이를 정당화해야 합니다.
• 권고(Advisory): 가능한 한 따르는 것이 좋지만, 상황에 따라 위반이 허용될 수 있습니다.

2.2. 분석 범위 (Analysis Scope)

MISRA 규칙의 준수 여부를 확인하기 위해서는 분석 범위를 명확히 설정해야 합니다. 분석 범위는 규칙이 적용될 단일 번역 단위와 시스템 범위로 나뉩니다. 시스템 범위의 분석은 파일 간의 상호작용을 분석해야 하므로 복잡성이 더 큽니다. 이를 효과적으로 수행하려면 시스템 전반을 분석할 수 있는 도구나 체계적인 검토 절차가 필요합니다. 단일 번역 단위의 규칙은 도구를 사용해 자동화할 수 있지만, 시스템 범위 분석은 더 세심한 주의와 수동 검토가 요구될 수 있습니다.

• 단일 번역 단위(Single Translation Unit): 개별 소스 파일에 대해 적용되는 규칙입니다. 이러한 규칙은 파일 내부에서 위반 여부를 쉽게 확인할 수 있습니다.
• 시스템 범위(System Scope): 여러 파일 간의 상호작용을 고려해야 하는 규칙으로, 소프트웨어 전체를 분석해야 위반 여부를 파악할 수 있습니다.

2.3. 지침 집행 계획 (Guideline Enforcement Plan)

지침 집행 계획(Guideline Enforcement Plan, GEP)은 프로젝트에서 MISRA 규칙을 어떻게 준수할 것인지에 대한 상세한 계획을 세우는 문서입니다. 이 문서에는 각 규칙이 어떻게 준수되는지, deviation이 발생했을 때 어떤 절차를 따를 것인지가 포함됩니다. 지침 집행 계획은 프로젝트의 시작 단계에서 명확히 수립되어야 합니다. 이를 통해 개발자는 각 규칙을 어떻게 준수할지 명확히 이해하고, deviation이 필요한 경우 미리 대비할 수 있습니다. 특히, 정적 분석 도구가 자동으로 규칙을 검사할 수 있는지, 그렇지 않으면 수동 검토가 필요한지 명확히 구분하는 것이 중요합니다. 계획이 너무 복잡하거나 비효율적이면 실무에서 제대로 실행되지 않을 수 있으므로, 현실적이고 실현 가능한 계획을 수립하는 것이 좋습니다.

• 지침 준수 도구: 어떤 도구를 사용해 규칙 준수를 확인할지, 그리고 각 도구가 어떤 규칙을 검사할 수 있는지 명시해야 합니다.
• Deviation 처리 절차: 규칙을 지키지 못하는 상황에서 deviation을 어떻게 기록하고 승인할 것인지 구체적으로 계획해야 합니다.

2.4. 메시지 분석 (Investigating Messages)

개발 과정에서 정적 분석 도구나 컴파일러는 규칙 위반을 감지하고 다양한 메시지를 생성합니다. 이 메시지를 분석하여 규칙 위반 여부를 파악하고, 필요한 경우 조치를 취하는 것이 중요합니다. 정적 분석 도구는 때때로 false positive를 생성할 수 있습니다. 이를 무조건 수용하지 않고, 개발자가 각 메시지를 분석하여 실제 위반인지 판단하는 것이 중요합니다. 잘못된 경고를 무시하는 절차를 마련하는 것도 필요하지만, 이런 절차가 너무 관대하게 운영되면 실제 규칙 위반이 놓치게 될 위험이 있습니다. 적절한 균형을 유지하는 것이 핵심입니다.

• 위반 메시지 분석: 정적 분석 도구가 제공하는 메시지가 실제로 규칙을 위반한 것인지, 아니면 잘못된 경고인지를 분석해야 합니다.
• 오류 수정: 규칙을 위반한 경우, 이를 수정하거나 deviation으로 처리해야 합니다.

2.5. 결정 가능성 (Decidability)

MISRA 규칙 중 일부는 자동화된 도구로 완벽하게 결정할 수 있는 결정 가능한 규칙이고, 일부는 도구로 확인할 수 없는 결정 불가능한 규칙입니다. 결정 불가능한 규칙에 대해서는 수동 검토가 필수적입니다. 이때는 개발자들의 경험과 판단이 중요하며, 규칙 위반 가능성을 최소화할 수 있도록 충분한 검토 절차를 마련해야 합니다. 도구를 사용하여 결정할 수 있는 규칙은 가능한 한 자동화해 개발 시간을 절약할 수 있지만, 그 외의 규칙들은 철저한 수동 검토와 기록이 필요합니다.

• 결정 가능한 규칙(Decidable Rules): 정적 분석 도구를 사용해 명확히 준수 여부를 확인할 수 있는 규칙들입니다. 대부분의 MISRA 규칙은 결정 가능한 범주에 속합니다.
• 결정 불가능한 규칙(Undecidable Rules): 도구만으로는 준수 여부를 확인할 수 없는 규칙들로, 수동 검토나 추가 분석이 필요합니다.

 

MISRA 준수를 위한 프로세스 및 도구 체크리스트

---

3. MISRA 준수에서의 Deviation 처리: 필요한 이유와 절차

소프트웨어 개발 과정에서 모든 MISRA 규칙을 100% 준수하는 것은 어려울 때가 있습니다. 이러한 상황에서는 Deviation을 허용하여 규칙을 위반하는 것이 가능하며, 이때는 deviation을 기록하고 이를 정당화하는 절차가 필요합니다.

 

3.1. Deviation의 역할 (Role of Deviations)

MISRA 규칙은 소프트웨어 안전성을 보장하기 위한 엄격한 기준을 제시하지만, 모든 규칙이 모든 상황에 적용될 수 있는 것은 아닙니다. Deviation의 역할은 MISRA 규칙을 준수하지 않아도 되는 상황에서 예외적인 처리를 허용하는 메커니즘입니다. 이는 규칙을 지키지 않음으로써 더 나은 성능을 얻거나 시스템 제약을 해결할 수 있는 경우에 사용됩니다. 그러나 Deviation은 남용될 수 있는 요소이기 때문에, 규칙을 무시하기 위한 수단으로 사용해서는 안 됩니다. 가능한 모든 경우 규칙을 준수하려고 노력해야 하며, deviation은 필요한 경우에만 신중하게 사용되어야 합니다.

• 특정 상황에서 규칙 적용이 불필요하거나 불가능할 때 적용됩니다.
• Deviation이 발생하면 반드시 그 이유를 명확히 기록하고, 이를 정당화해야 합니다.
• Deviation이 안전성에 미치는 영향을 평가하고, 안전을 저해하지 않도록 대처 방안을 마련해야 합니다.

3.2. Deviation 기록 (Deviation Records)

Deviation 기록(Deviation Records)은 Deviation이 발생했을 때 이를 문서화하여, 왜 규칙을 준수하지 않았는지 설명하는 기록입니다. 모든 Deviation은 명확한 이유와 함께 기록되어야 하며, 규칙을 위반한 이유와 이에 대한 대처 방안이 포함됩니다. Deviation 기록은 모든 Deviation이 발생할 때마다 상세히 작성되어야 하며, 프로젝트 관리자가 이를 검토하고 승인하는 절차가 필요합니다. 이를 통해 Deviation이 소프트웨어의 안전성을 해치지 않도록 관리할 수 있습니다. 이때 규칙 위반에 따른 위험을 최소화하기 위한 대처 방안도 기록에 포함해야 합니다.

Deviation 기록은 다음과 같은 정보를 포함해야 합니다:

• 위반한 규칙의 번호 및 설명: 어떤 규칙이 위반되었는지 명시해야 합니다.
• Deviation의 이유: Deviation이 필요한 이유를 구체적으로 설명해야 합니다. 성능 개선, 하드웨어 제약, 코드 통합 등 다양한 이유가 있을 수 있습니다.
• Deviation이 소프트웨어에 미치는 영향: Deviation으로 인해 소프트웨어의 안전성, 성능, 품질에 미치는 영향을 평가해야 합니다.

3.3. Deviation 허가서 (Deviation Permits)

Deviation 허가서는 (Deviation Permits)는 반복적으로 발생하는 특정 규칙 위반 상황을 사전에 승인해 두는 문서입니다. Deviation 기록을 매번 작성하는 대신, 미리 허가된 Deviation 상황에 대해서는 "Deviation Permits"를 작성하여 보다 효율적으로 deviation을 관리할 수 있습니다. Deviation Permits는 규칙 준수의 유연성을 제공하지만, 남용되지 않도록 신중하게 사용해야 합니다. 또한, 허가서가 발행된 이후에도 상황에 맞게 재검토하고, 필요할 경우 새로운 Deviation Permits를 발행해야 합니다.

Deviation Permits는 다음과 같은 경우에 유용합니다:

• 반복적으로 발생하는 규칙 위반: 특정 하드웨어 제약이나 성능 요구 사항으로 인해 반복적으로 규칙을 위반해야 하는 경우.
• 제외 가능한 규칙: 프로젝트의 특성상 미리 규칙을 제외해도 되는 경우에 대해 허가서를 미리 발행하여, 이후 발생할 수 있는 Deviation을 일관되게 관리할 수 있습니다.

3.4. Deviation 정당화 (Justifying a Deviation)

Deviation이 발생할 경우, 이를 정당화하는 과정이 필수적입니다. Deviation 정당화(Justifying a Deviation)는 왜 특정 규칙을 준수하지 못했는지에 대한 합리적인 이유를 제공하며, 이로 인해 발생할 수 있는 문제를 해결하기 위한 대책을 제시합니다. Deviation을 정당화할 때는 deviation이 소프트웨어의 안정성과 품질에 미치는 영향을 신중히 평가해야 하며, 가능한 경우 대체 방안을 마련하는 것이 중요합니다. Deviation이 소프트웨어에 미치는 영향을 최소화하는 것이 최우선 목표입니다.

MISRA에서는 deviation을 정당화할 수 있는 4가지 주요 이유를 제시합니다:

• 성능 향상 (Performance Improvement)
  규칙을 준수하면 시스템 성능이 저하되거나, 자원 사용이 비효율적으로 이루어질 수 있습니다. 성능 향상을 위해 규칙을 위반하는 경우, 성능 최적화가 중요한 요구사항일 때 deviation이 정당화될 수 있습니다. 
  예시: 시스템이 실시간 응답을 요구하는 경우, 성능 최적화를 위해 일부 규칙을 무시해야 할 수 있습니다. 이때는 규칙 위반으로 얻는 성능 개선이 소프트웨어의 전반적인 목표를 달성하는 데 더 중요한 역할을 할 수 있습니다.
• 하드웨어 접근 (Access to Hardware)
  임베디드 시스템에서는 하드웨어에 직접 접근해야 하는 경우가 많습니다. 이때 표준 C/C++ 규칙을 따르는 것이 불가능할 수 있으며, 하드웨어 접근을 위해 규칙을 위반하는 것이 필요할 수 있습니다.
  예시: 특정 하드웨어 레지스터에 접근하기 위해서는 표준적인 메모리 접근 방식이 아닌 방법을 사용해야 할 수 있으며, 이는 규칙 위반을 유발할 수 있습니다.
• 코드 통합 (Adopted Code Integration)
  채택된 코드(Adopted Code)나 외부 라이브러리를 통합할 때, 해당 코드가 MISRA 규칙을 준수하지 않을 수 있습니다. 이 경우, 외부 코드를 수정하기 어렵다면, 이를 그대로 사용하는 것이 정당화될 수 있습니다.
  예시: 외부에서 제공받은 드라이버나 라이브러리가 MISRA 규칙을 따르지 않지만, 이를 수정하는 데 시간이 많이 걸리거나 기술적으로 불가능한 경우 그대로 사용할 수 있습니다.
• 기존 레거시 코드 (Legacy Code)
  레거시 코드(Legacy Code)는 기존 시스템에서 사용되던 오래된 코드로, 새 프로젝트에서 재사용할 경우 규칙 위반이 발생할 수 있습니다. 그러나 레거시 코드를 수정하는 데 드는 비용이나 위험성이 크다면, 이를 그대로 유지할 수 있습니다.
  예시: 레거시 시스템에서 성공적으로 운영 중인 코드가 있고, 이를 변경하면 전체 시스템의 안전성에 영향을 미칠 수 있는 경우, 해당 코드를 수정하지 않고 사용할 수 있습니다.

참고로 코드의 품질을 결정함에 있어 ISO/IEC 25010 Product Quality Model을 참고하여 성능 이외에 다른 특성을 만족시킬 수 있는 속성들을 결정할 수 있어야 합니다.

 

MISRA 준수를 위한 프로세스 및 도구 체크리스트

---

4. MISRA 준수에서의 카테고리 재분류: 프로젝트 특성에 맞춘 규칙 적용

MISRA 규칙은 소프트웨어의 안전성과 신뢰성을 보장하기 위해 다양한 산업에서 폭넓게 적용됩니다. 그러나 모든 프로젝트가 동일한 규칙을 동일한 방식으로 적용할 필요는 없습니다.

4.1. 재분류의 필요성 (5.1 Re-categorization)

MISRA 규칙은 기본적으로 Mandatory(필수), Required(요구), 그리고 Advisory(권고)의 세 가지 카테고리로 나뉩니다. 이 분류는 규칙의 중요성에 따라 정의되며, 각 카테고리는 프로젝트에서 얼마나 엄격하게 준수되어야 하는지 결정합니다. 그러나 모든 프로젝트가 동일한 기준을 적용할 수는 없으므로, 프로젝트 특성에 맞춰 규칙의 카테고리를 재분류할 수 있습니다.

• Mandatory(필수): 반드시 준수해야 하는 규칙. 위반 시 프로젝트의 안전성과 신뢰성에 심각한 영향을 미칠 수 있습니다.
• Required(요구): 대부분의 상황에서 준수해야 하지만, 특정 상황에서 예외가 있을 수 있습니다.
• Advisory(권고): 가능한 준수하는 것이 좋지만, 프로젝트 상황에 따라 준수하지 않아도 되는 규칙입니다.

재분류는 특정 프로젝트에서 규칙의 우선순위를 조정하여, 안전성과 성능을 동시에 고려하는 데 유용합니다. 예를 들어, 안전성이 특히 중요한 프로젝트에서는 권고 규칙을 필수 규칙으로 승격시킬 수 있으며, 반대로 시간이나 성능이 더 중요한 프로젝트에서는 권고 규칙을 적용하지 않을 수 있습니다.

4.2. 카테고리 조정 테이블 (Category Adjustment Table)

MISRA 규칙의 카테고리를 재분류할 때, 카테고리 조정 테이블(Category Adjustment Table)을 사용하여 규칙이 어떻게 재분류될 것인지를 명확히 정의합니다. 이 테이블은 각 규칙이 기본적으로 분류된 카테고리와, 해당 프로젝트에서 적용되는 새로운 카테고리를 비교하여 나타냅니다. 카테고리 조정 테이블의 기본 구조는 다음과 같습니다:

Rule	MISRA Category (Original)	Revised Category (Adjusted)	Reason for Adjustment
5.1	Mandatory	Mandatory	Core safety requirements
6.3	Required	Mandatory	Critical for system integrity
7.4	Advisory	Required	Performance Improvement

 

• Rule 5.1 (필수 규칙): 이 규칙은 원래 "필수(Mandatory)"로 지정되어 있으며, 프로젝트에서 그대로 필수로 유지됩니다. 이 규칙은 프로젝트의 핵심적인 안전 요건이므로, 위반 시 심각한 안전 문제를 초래할 수 있습니다. 따라서 카테고리가 변경되지 않고 그대로 유지됩니다.
• Rule 6.3 (요구 규칙): 이 규칙은 원래 "요구(Required)"로 분류되어 있지만, 해당 프로젝트에서는 "필수(Mandatory)"로 승격되었습니다. 이는 시스템의 무결성을 보장하는 데 중요한 역할을 하기 때문에, 보다 엄격한 준수가 필요하다고 판단한 경우입니다. 이 규칙의 위반은 시스템의 안전성이나 데이터 무결성에 영향을 미칠 수 있으므로, 프로젝트 안전성 요구 사항에 따라 더 높은 카테고리로 조정되었습니다.
• Rule 7.4 (권고 규칙): 이 규칙은 기본적으로 "권고(Advisory)" 규칙으로 분류되어 있지만, 프로젝트에서 성능 향상이 중요한 경우 "요구(Required)"로 승격되었습니다. 성능을 개선하기 위해 이 규칙의 준수를 요구하는 것이 바람직한 상황입니다. 규칙을 준수함으로써 시스템의 성능에 중요한 영향을 미칠 수 있어, 권고에서 요구로 상향 조정된 것입니다.

4.3. 카테고리 재분류 적용 시 고려 사항

카테고리 재분류는 프로젝트 요구 사항을 반영하여 규칙을 유연하게 적용할 수 있는 강력한 도구입니다. 그러나 이를 사용할 때는 다음과 같은 사항을 신중히 고려해야 합니다.

• 안전성 평가: 재분류된 규칙이 프로젝트의 안전성에 미치는 영향을 철저히 평가해야 합니다. 특히 권고 규칙을 필수 규칙으로 승격하는 경우, 시스템 안전성을 극대화하는 데 도움이 될 수 있습니다.
• 성능 요구 사항: 성능이 중요한 프로젝트에서는 일부 규칙을 완화하거나 적용하지 않을 수 있습니다. 이 경우, 성능 개선과 시스템 안정성 간의 균형을 유지하는 것이 중요합니다.
• 규칙 위반 관리: 규칙이 재분류되면, 그에 따라 위반 상황도 달라집니다. 예를 들어, 권고 규칙이 필수로 승격된 경우, 위반 시 편차 기록과 같은 추가적인 절차가 필요합니다.
• 도구 지원: 재분류된 규칙을 준수하기 위해 사용하는 도구가 이를 지원하는지 확인해야 합니다. 일부 정적 분석 도구는 특정 규칙만 검사할 수 있으므로, 프로젝트에 맞는 도구 설정이 필요합니다.

 

MISRA 준수를 위한 프로세스 및 도구 체크리스트

---

5. MISRA 준수에서의 채택된 코드: 외부 코드 통합 시 고려 사항

Adopted Code는 외부에서 가져온 코드나, 이전 프로젝트에서 재사용된 코드, 또는 서드파티 라이브러리 등을 의미합니다. 이러한 코드가 반드시 MISRA 규칙을 준수하지는 않기 때문에, 이를 프로젝트에 통합할 때는 MISRA 준수와 위험 관리에 대한 철저한 계획이 필요합니다. 

5.1. 채택된 코드의 특성 (The Nature of Adopted Code)

"채택된 코드(Adopted Code)"는 프로젝트에서 직접 작성한 코드가 아닌, 외부 소스에서 가져와 사용하는 코드입니다. 이러한 채택된 코드는 MISRA 규칙을 준수하지 않을 수 있으며, 이를 통합할 때는 특별한 관리 절차가 필요합니다. 이는 다음과 같은 형태로 존재할 수 있습니다:

• 서드파티 라이브러리: 외부에서 제공받은 라이브러리.
• 레거시 코드: 이전 프로젝트에서 재사용되는 코드.
• 자동 생성 코드: 모델링 도구나 코드 생성기로부터 자동으로 생성된 코드.
• 표준 라이브러리: 프로그래밍 언어에서 제공하는 표준 라이브러리.

5.2. 시스템 전반의 분석 범위 (System Wide Analysis Scope)

"시스템 전반의 분석 범위(System Wide Analysis Scope)"는 채택된 코드가 전체 시스템에 미치는 영향을 평가하기 위한 분석 방법입니다. 채택된 코드가 여러 파일 간에 상호작용할 수 있기 때문에, "단일 번역 단위(Single Translation Unit)"로만 분석할 수 없습니다. 전체 시스템을 분석하는 것이 필수적입니다.

• 종속성 분석: 채택된 코드가 시스템의 다른 부분과 어떻게 상호작용하는지 분석합니다.
• 통합 테스트: 채택된 코드와 기존 시스템 간의 오류 발생 가능성을 줄이기 위해 통합 테스트가 필수적입니다.

5.3. 채택된 바이너리 코드 (Adopted Binary Code)

"채택된 바이너리 코드(Adopted Binary Code)"는 소스 코드가 아닌 이진 파일 형태로 제공되는 코드입니다. 이 경우, 개발자는 코드 내부를 직접 분석할 수 없기 때문에 MISRA 규칙 준수를 확인하기가 어렵습니다. 그러나 다음과 같은 방법을 통해 바이너리 코드의 안전성을 보장할 수 있습니다.

• 공급업체의 준수 문서: 바이너리 코드가 MISRA 규칙을 준수했음을 증명하는 문서를 공급업체로부터 받을 수 있습니다.
• 정적 및 동적 분석 도구 사용: 바이너리 코드에 대한 정적 분석 도구를 사용해 코드의 안전성을 분석하거나, 실행 중 동적 분석을 통해 오류 가능성을 평가할 수 있습니다.

5.4. 채택된 소스 코드 (Adopted Source Code)

"채택된 소스 코드(Adopted Source Code)"는 소스 코드 형태로 제공된 외부 코드입니다. 이 경우, 개발자는 소스 코드를 직접 분석하여 MISRA 규칙 준수 여부를 확인할 수 있습니다.

• 정적 분석: 채택된 소스 코드를 프로젝트에 통합하기 전에, 정적 분석 도구를 사용해 코드 내 규칙 위반을 사전에 탐지하고 해결할 수 있습니다.
• Deviation 처리: 만약 채택된 소스 코드가 MISRA 규칙을 준수하지 않는다면, 해당 규칙에 대한 deviation을 기록하고 이를 정당화해야 합니다.

5.5. 채택된 헤더 파일 (Adopted Header Files)

"채택된 헤더 파일(Adopted Header Files)"은 외부 라이브러리나 코드와 함께 제공되는 헤더 파일로, 다른 코드와 연결하는 인터페이스 역할을 합니다. 헤더 파일 역시 MISRA 규칙을 위반할 수 있으며, 이를 관리하는 것이 중요합니다.

• 규칙 위반 확인: 헤더 파일이 MISRA 규칙을 준수하는지 확인하고, 위반 시 해당 부분을 수정하거나 편차를 기록해야 합니다.
• 호환성 문제 해결: 헤더 파일이 시스템의 다른 부분과 충돌하지 않도록 호환성 문제를 해결해야 합니다.

5.6. 표준 라이브러리 (The Standard Library)

"표준 라이브러리(The Standard Library)"는 C/C++ 표준 라이브러리와 같이 프로그래밍 언어에서 기본적으로 제공하는 라이브러리입니다. 이러한 라이브러리는 성능 최적화를 위해 MISRA 규칙을 따르지 않는 경우가 많습니다. 그러나 MISRA는 표준 라이브러리를 채택된 코드로 간주하며, 이를 반드시 준수하지 않아도 된다고 명시합니다.

• 표준 라이브러리 사용: MISRA 규칙을 위반하더라도, 표준 라이브러리는 성능과 효율성을 고려하여 사용할 수 있습니다.
• 상호작용 규칙 준수: 표준 라이브러리와 상호작용하는 코드가 MISRA 규칙을 준수해야 하며, 이를 통해 전반적인 시스템 안전성을 보장할 수 있습니다.

 

MISRA 준수를 위한 프로세스 및 도구 체크리스트

---

6. MISRA 준수 선언: 필수 요소와 고려 사항

MISRA 규칙 준수를 선언하려면 소프트웨어 개발 과정에서 규칙 준수가 일관되게 관리되고 기록되어야 합니다. 이번 장에서는 MISRA 준수 선언의 핵심 요소들을 설명하고, 이를 적용할 때 주의해야 할 사항을 함께 살펴보겠습니다.

6.1. 인력의 역량 (Staff Competence)

인력의 역량은 프로젝트가 MISRA 규칙을 성공적으로 준수하는 데 매우 중요한 요소입니다. 참여하는 개발자와 관련 인력은 MISRA 규칙에 대한 이해와 정적 분석 도구 사용법 등 필요한 기술적 역량을 갖춰야 합니다.

• 필요한 교육: 개발자는 MISRA 규칙의 목적과 적용 방법을 이해하고, C/C++ 프로그래밍 언어와 관련 도구를 숙련되게 사용할 수 있어야 합니다.
• 지속적인 학습: MISRA 규칙은 변화할 수 있기 때문에, 최신 규칙과 기술에 대한 지속적인 교육이 필요합니다.

6.2. 관리 프로세스 (Management Process)

관리 프로세스는 MISRA 규칙 준수 상태를 지속적으로 추적하고 관리하는 시스템을 의미합니다. 프로젝트가 진행되는 동안 규칙 준수를 일관되게 유지하고, 발생하는 편차를 관리하는 프로세스가 필요합니다.

• 계획 및 실행: 각 규칙이 어떻게 준수될 것인지 계획을 세우고, 개발 단계마다 이를 실행합니다.
• 편차 처리: 규칙을 준수하지 못하는 경우 발생할 수 있는 편차에 대한 관리와 기록 절차가 포함되어야 합니다.

6.3. 지침 준수 요약 (Guideline Compliance Summary)

"지침 준수 요약(Guideline Compliance Summary, GCS)"은 프로젝트 완료 후, MISRA 규칙 준수 여부를 기록한 공식 문서입니다. 이 문서는 프로젝트가 규칙을 얼마나 준수했는지, 발생한 편차는 무엇인지, 어떤 규칙이 적용되지 않았는지를 상세히 기록합니다.

• 포함 내용: 각 규칙의 준수 여부, 편차 기록, 편차 승인 내용, 미적용 규칙 등이 포함됩니다.
• 투명성: GCS는 프로젝트가 규칙을 준수했는지를 명확히 보여주며, 최종적으로 MISRA 준수를 선언할 때의 중요한 근거 자료로 사용됩니다.

6.4. 프로젝트 배포/납품 (Project Delivery)

"프로젝트 배포/납품(Project Delivery)은 프로젝트가 완료된 후, 최종 산출물과 문서를 고객에게 제공하는 과정입니다. 이때 MISRA 준수와 관련된 모든 기록과 문서를 함께 제공하여, 프로젝트가 규칙을 준수했음을 명확히 해야 합니다.

• 제공 문서: GCS, 편차 기록, 사용된 도구와 분석 결과 등 규칙 준수와 관련된 모든 문서가 포함됩니다.
• 추적 가능성: 프로젝트 이후에도 규칙 준수가 유지될 수 있도록, 모든 문서가 투명하고 쉽게 추적 가능하게 전달되어야 합니다.

 

MISRA 준수를 위한 프로세스 및 도구 체크리스트

---

마치며...

MISRA 준수를 성공적으로 선언하려면 교육과 도구 관리, 편차 기록, 지침 재분류, 채택된 코드 관리, 그리고 지침 준수 요약 작성까지 모든 단계에서 철저한 관리가 필요합니다. 각 섹션에서 제시하는 절차와 고려 사항들을 바탕으로, 개발자는 안전하고 신뢰성 있는 소프트웨어를 개발하고, 이를 바탕으로 MISRA 규칙 준수를 공식적으로 선언할 수 있습니다.

프로젝트의 특성에 맞는 유연한 규칙 적용과 철저한 검토를 통해, MISRA 준수는 실현 가능한 목표가 될 수 있으며, 이를 통해 더 높은 품질의 소프트웨어를 개발할 수 있습니다.

 

이 글은 https://misra.org.uk/app/uploads/2021/06/MISRA-Compliance-2020.pdf을 기반으로 작성되었습니다.

 

 

MISRA-C:2023 개요 (소프트웨어 코딩룰 준수)

 

 

MISRA 준수를 위한 프로세스 및 도구 체크리스트