사용 사례

서로 보완적인 두 가지 접근 방식이 있습니다.

첫째, 하드웨어 추상화 계층(HAL)을 갖춘 펌웨어를 설계하여 Unity나 CppUTest와 같은 표준 C 테스트 프레임워크를 사용해 호스트 머신에서 비즈니스 로직을 테스트할 수 있도록 합니다. 이렇게 하면 로직 테스트에 크로스 컴파일러나 보드가 필요하지 않습니다.

둘째, 실제 CPU 동작이 필요한 테스트의 경우 IAR C-SPY와 같은 명령어 세트 시뮬레이터를 사용합니다. 사이클 정확도 시뮬레이터를 사용하면 물리적 보드 없이도 CI 러너에서 크로스 컴파일된 펌웨어를 실행하여 실시간 오류 및 메모리 오류를 포착할 수 있습니다.

잘 구축된 CI 파이프라인은 이 두 가지를 결합합니다. 즉, 모든 커밋에 대해 신속한 피드백을 제공하는 호스트 네이티브 단위 테스트와, 보다 심층적인 검증을 위한 시뮬레이터 기반 통합 테스트를 모두 포함합니다.
실제 보드가 필요한 하드웨어-인-더-루프(Hardware-in-the-loop) 테스트는 하드웨어 액세스 일정에 따라 매일 밤 또는 릴리스 브랜치에서 실행됩니다.

임베디드 프로젝트에서 컴파일 시간이 길어지는 원인은 모놀리식 빌드 구성, 사소한 변경에도 발생하는 중복된 전체 재빌드, 그리고 멀티코어 시스템의 비효율적인 사용에서 비롯됩니다.

가장 빠르게 개선할 수 있는 방법은 다음과 같습니다.

병렬 컴파일을 활용하고(IAR을 비롯한 일부 컴파일러가 이를 지원), 펌웨어를 독립적으로 빌드 가능한 모듈로 분할하여 변경된 구성 요소만 재컴파일되도록 하며, 툴체인을 컨테이너화하여 CI 실행 시 매번 도구를 재설치하지 않도록 하는 것입니다.

컴파일러의 품질도 중요합니다. 더 작은 크기의 코드를 생성하는 최적화 컴파일러를 사용하면 링크 시간도 단축되는 경우가 많습니다.

리눅스에서 CI 통합 툴체인을 사용하는 팀들은 윈도우 전용 수동 빌드에 비해 빌드 시간이 최대 50% 단축되었다고 보고합니다. 이는 주로 리눅스 네이티브 툴체인과 컨테이너화된 러너가 오브젝트 파일을 더 효율적으로 처리하기 때문입니다.

이 방법이 귀사의 워크플로우에 어떻게 적용될지 확인해 보시겠습니까? IAR 전문가와 상담하여 맞춤형 평가를 받아보세요.

이는 임베디드 CI에서 가장 흔히 발생하는 오류로, 거의 항상 빌드가 CI 환경에 없는 로컬에 설치된 요소(특정 컴파일러 버전, 벤더 SDK 경로, 호스트 OS 라이브러리, 또는 시스템 PATH에 포함된 암시적 도구 등)에 의존하고 있음을 의미합니다.

영구적인 해결책은 ‘밀폐형 빌드’입니다. 컴파일러, 링커, 어셈블러, SDK 등 모든 도구를 버전이 고정되고 버전 관리 시스템에 체크인된 Docker 컨테이너 이미지로 패키징하는 것입니다.

모든 개발자와 모든 CI 실행기는 정확히 동일한 이미지를 사용합니다. 헤드리스(headless) 방식으로 작동하는 벤더 제공 리눅스 툴체인 설치 프로그램을 사용하면 이를 간편하게 컨테이너화할 수 있습니다. 이미지가 유일한 기준이 되면, 'works on my machine'는 식의 오류는 더 이상 발생하지 않습니다. 왜냐하면 사실상 하나의 컴퓨터만 존재하게 되기 때문입니다.

핵심은 MISRA 분석을 처음에는 비차단형 품질 게이트로 CI 파이프라인에 직접 통합한 다음, 점차 규칙을 강화해 나가는 것입니다.

정적 분석을 설정하여 모든 풀 리퀘스트(pull request) 또는 병합 요청(merge request) 시 실행되도록 하고, 위반 사항을 diff와 함께 인라인 CI 어노테이션으로 보고하도록 하면, 개발자는 워크플로우를 벗어나지 않고도 어떤 줄에서 어떤 규칙을 위반했는지 정확히 확인할 수 있습니다.

노이즈를 줄이기 위해 MISRA-C:2012의 필수 규칙만 포함된 프로필로 시작하세요. 새로운 위반 사항은 빌드 실패로 처리하고, 기존 위반 사항은 점진적으로 수정할 추적 대상 백로그로 취급하세요. 이 접근 방식은 별도의 검토 단계 없이도 코딩 표준을 지속적으로 적용합니다.

IDE와 CI 모두에서 동일한 분석기 바이너리를 실행하는 툴체인을 사용하면, 개발자의 게이트에 대한 신뢰를 저해하는 ‘로컬에서는 통과, CI에서는 실패’라는 문제를 해소할 수 있습니다.

실질적인 해결책은 IAR 플랫폼과 같이, 단일 라이선스와 단일 빌드 도구 인터페이스 하에서 두 아키텍처를 모두 지원하는 통합 개발 플랫폼입니다. Arm 및 RISC-V 프로젝트가 동일한 컴파일러 공급업체와 IDE를 사용할 경우, CI 파이프라인 스크립트는 거의 동일하며, 타겟 플래그만 변경됩니다.

즉, Arm 및 RISC-V용 툴체인이 포함된 동일한 Docker 이미지, 동일한 정적 분석 규칙 세트, 그리고 동일한 디버깅 워크플로우를 사용할 수 있습니다. 비용 및 벤더 독립성을 이유로 산업 및 IoT 애플리케이션에서 RISC-V의 채택이 가속화됨에 따라, 다중 아키텍처 지원은 더 이상 ‘있으면 좋은 기능’이 아니라 필수 요건이 되어가고 있습니다.

일찍이 단일 아키텍처 도구에 얽매였던 팀들은 이제 마이그레이션 비용을 치르고 있는 반면, 다중 아키텍처 플랫폼을 사용하는 팀들은 단순히 타겟 구성을 추가하기만 하면 됩니다.

임베디드 디버깅에서 가장 많은 시간을 잡아먹는 요인은 다음과 같습니다. 한 가지 변경 사항을 테스트하기 위해 전체 빌드-플래시-부팅 주기가 완료될 때까지 기다려야 하는 것, 오류 발생 시 근본 원인의 맥락을 파악하지 못하는 것, 그리고 며칠 전에 발생한 버그를 뒤늦게 발견하는 것입니다.

이 문제들을 각각 따로 해결하십시오.

• 플래싱 전에 호스트나 시뮬레이터에서 로직 테스트를 실행하여 반복 루프를 줄이십시오.

• 단순히 오류 주소를 보고하는 데 그치지 않고, 호출 스택, 레지스터 상태, 크래시 지점의 메모리 를 캡처하는 디버거를 사용하여 오류 컨텍스트를 개선하십시오.

• 수동 세션 중에만 수행하는 것이 아니라 CI의 일환으로 런타임 분석(스택 오버플로우 감지, 메모리 액세스 검사)을 실행하여 버그 발견 시점을 앞당깁니다.

시뮬레이터 기반 CI 테스트와 IAR C-SPY와 같은 고급 온타겟 디버깅을 결합한 팀들은 사후 대응형 수동 워크플로우에 비해 디버깅 시간이 최대 80%까지 단축되었다고 보고합니다.

상용 툴체인의 투자 수익률(ROI)은 오픈소스 툴이 다루지 못하는 네 가지 요소에 기반을 두고 있습니다.

첫째, 안전 표준(IEC 61508, ISO 26262)에 대한 오픈소스 툴체인의 사내 검증에는 최대 12개월의 엔지니어링 시간이 소요될 수 있으며, 주요 버전 업데이트 시마다 이 과정을 반복해야 합니다. 이러한 비용은 툴 예산 비교 시 거의 반영되지 않는 경우가 많습니다.

둘째, 컴파일러 최적화 품질입니다. 상용 컴파일러는 일반적으로 코드 크기를 20~28% 줄여주며, 이는 더 작은 플래시 메모리나 더 저렴한 실리콘을 사용할 수 있게 함으로써 BOM 비용을 직접적으로 절감합니다.

셋째, 지원 응답 시간입니다. 툴체인 버그로 인해 막힌 개발 팀의 작업을 재개하는 데는 매일 정량화할 수 있는 비용이 발생합니다.

넷째, 구독형 라이선스는 막대한 자본 지출을 예측 가능한 운영 비용으로 전환하여, 승인 절차가 더 수월하고 규모 조정도 용이합니다. 라이선스 비용 대 무료라는 식이 아니라, 12개월간의 총 엔지니어링 비용으로 비교를 제시하십시오.

자세한 내용은 다음 전자책에서 확인하세요:

TCO 백서

임베디드 소프트웨어 개발의 12가지 기본 원칙

임베디드 프로젝트에서 인증 기한을 놓치는 경우는 거의 항상 다음 세 가지 원인으로 귀결됩니다.

1. 준수 증거를 지속적으로 수집하지 않고 사후에 뒤늦게 수집한 경우,

2. 툴 검증을 프로젝트 막바지에 미루는 경우, 그리고

3. 시스템 통합 단계에서 품질 문제가 발견되는 경우입니다.

각 원인마다 프로세스 차원의 해결책이 있습니다.

사후 증거 수집을 지속적인 생성으로 대체하십시오: CI를 구성하여 매 빌드 시 MISRA 위반 보고서, 정적 분석 요약, 빌드 추적 정보를 자동으로 생성하도록 하십시오.

사전 인증된 툴체인을 사용하여 사내 툴 검증을 완전히 제거하십시오 — 이것만으로도 6~12개월의 시간을 절약할 수 있습니다.

커밋 시점에 품질 게이트를 실행하여 통합 단계로 유입되는 결함 밀도를 낮춥니다.

이 세 가지 지표(증거의 완전성, 도구 검증 상태, 누락된 결함 비율)를 측정하는 프로젝트 관리자는 감사 시점에야 인증 위험을 발견하는 대신, 조기에 경고를 받을 수 있습니다.

다음 네 단계부터 시작하세요:

1. 빌드 — 리눅스에서 헤드리스 모드로 실행되는 컨테이너화된 툴체인을 사용하여 크로스 컴파일하기

2. 정적 분석 — MISRA 또는 CERT-C 검사를 실행하고, 새로운 위반 사항이 발견되면 빌드를 실패 처리

3. 단위 테스트 — 논리 검증을 위한 호스트 네이티브 테스트와 하드웨어 의존 코드에 대한 시뮬레이터 기반 테스트를 실행

4. 아티팩트 패키징 — 서명된 펌웨어 바이너리와 함께 빌드 매니페스트를 생성합니다. GitHub Actions 또는 GitLab CI를 사용하여 푸시할 때마다 이 프로세스를 트리거합니다.

핵심 요소는 GUI 라이선스 없이 작동하는 명령줄 빌드 도구입니다. 현재 상용 툴체인은 클라우드 또는 컨테이너 라이선싱을 지원하는 리눅스 네이티브 CLI 빌드를 제공하므로, 각 러너에 라이선스 서버를 설치할 필요가 없습니다.

간단하게 시작하고, 기본 파이프라인의 신뢰성이 확보되면 하드웨어-인-더-루프(HIL) 및 OTA 스테이징 게이트를 추가하십시오. https://github.com/iarsystems의 튜토리얼에서는 시작하는 방법에 대한 지침을 제공합니다.

정적 분석은 소스 코드를 실행하지 않고 검사하는 방식으로, 바이너리가 실행되기 전인 빌드 단계에서 정의되지 않은 동작, MISRA 위반, null 포인터 참조 오류, 데이터 흐름 오류를 탐지합니다.

하드웨어가 필요하지 않기 때문에 CI 환경에서 확장성이 뛰어납니다. 런타임 분석(동적 분석)은 실행 중인 펌웨어에 계측기를 삽입하거나 모니터링하여 런타임에만 나타나는 오류, 즉 스택 오버플로우, 힙 손상, 타이밍 위반, RTOS의 경합 조건 등을 탐지합니다.

두 분석 방식은 서로 다른 유형의 결함을 탐지하므로 모두 필요합니다. 정적 분석은 첫 번째 방어선이며, 모든 커밋 시 실행됩니다. 런타임 분석은 시뮬레이터나 하드웨어-인-더-루프(HIL) 장비에서 실행되어 실제 실행 조건에서만 나타나는 결함을 탐지합니다.

IEC 61508 또는 ISO 26262를 준수하는 안전 중요 프로젝트의 경우, 각 개발 단계에서 두 가지 분석 기법 모두 필수적으로 적용되어야 합니다.

IAR 정적 분석 및 기능 안전에 대해 자세히 알아보기

전환 전에 다음 네 가지 기준 지표를 측정하십시오:

• 코드 커밋부터 결함 발견까지의 평균 소요 시간,

• 스프린트당 통합 실패 횟수,

• 릴리스당 규정 준수 증빙 자료 수집에 소요된 시간, 그리고

• 신입 엔지니어 온보딩 소요 시간.

CI/CD는 일반적으로 결함 발견 시점을 통합 단계(비용이 많이 드는)에서 커밋 시점(비용이 적게 드는)으로 앞당겨, 재작업 비용을 40~50% 절감합니다.

규정 준수 증거의 자동화는 인증 프로젝트에서 릴리스당 일반적으로 2~5일이 소요되는 수동 문서화 주기를 제거합니다.

빌드 자동화는 수동적인 ‘빌드-플래시-테스트’ 루프를 제거하여, 팀들은 빌드-테스트 주기가 50% 빨라졌다고 보고합니다.

툴체인이 컨테이너화되면 온보딩 시간이 단축됩니다. 엔지니어들은 로컬 환경 설정 문제를 해결하는 데 시간을 낭비하지 않고 첫날부터 바로 코드 작성을 시작할 수 있습니다.

이러한 지표는 엔지니어 작업 시간 절감으로 직접 연결되며, 이는 일정 단축이나 인력 효율성 향상으로 이어집니다.

이 TCO 백서에서 자세한 내용을 확인하세요.