수 년 혹은 몇 십년 간 축적된 C 코드베이스를 폐기하지 않고도 메모리 안전성과 성능을 동시에 확보할 수 있는 길이 열렸다. 세온이앤에스와 자비스(JARBIS)가 ARM Cortex-M4 베어메탈과 현대오토에버 mobilgene 플랫폼 위에서 검증한 Rust 적용 실증 결과를 소개한다.

글 | 신승환 상무, Seon ENS _ shshin@seonens.com






메모리 안전성 위기, 자동차 산업도 예외 아니다   

오늘날 자동차 한 대에 탑재되는 소프트웨어는 1억 라인을 넘본다. SDV 전환으로 ECU 통합이 가속화되면서 단일 제어기가 처리해야 할 기능은 기하급수적으로 늘고 있다. 자율주행, V2X, OTA가 더해질수록 결함 발생 확률 또한 함께 커진다.
Microsoft는 자사 CVE의 약 70%가 메모리 안전성 결함에서 비롯된다고 밝힌 바 있다. 버퍼 오버플로우, Use-after-free, 데이터 레이스는 IT 시스템에서는 패치로 대응하지만, 차량용 임베디드에서는 인명과 직결된다. Google Android 팀이 메모리 안전 언어 비중을 높여 메모리 안전 취약점 비율을 2019년 76%에서 2024년 24%로 끌어내린 사례는 시사하는 바가 크다.
C 언어는 임베디드의 표준이지만, 메모리 관리 책임을 전적으로 프로그래머에게 부여하는 설계 철학이 구조적 한계의 근원이다. MISRA C 같은 코딩 규칙은 정적 분석과 코드 리뷰에 의존하므로 복잡한 포인터 앨리어싱이나 멀티코어 데이터 레이스는 런타임까지 살아남는다. 결국 도구의 문제가 아니라 언어 자체의 문제다.



글로벌 동향 - 인증 컴파일러와 정부 권고

이러한 인식은 빠르게 확산되고 있다. 컴파일러 툴체인 인증 영역에서의 변화가 대표적이다. 독일 HighTec은 Infineon AURIX와 ARM 기반 Stellar 등 특정 MCU/툴체인 조합에 한해 ISO 26262 ASIL D 수준의 도구 인증(Tool Qualification)을 획득한 Rust 컴파일러를 공급하고 있다. 이는 Rust 언어 일반에 대한 안전 인증이 아니라, 해당 MCU와 툴체인 조합에서 안전 개발 경로가 마련됐음을 의미한다. 즉 모든 환경에서 Rust가 즉시 ASIL 개발에 사용가능해졌다는 뜻은 아니지만, 조건이 맞는 영역에서는 도입 장벽 중 하나가 낮아지고 있다고 볼 수 있다.
미국 백악관 ONCD는 2024년 2월 "Back to the Building Blocks" 보고서를 통해 메모리 안전 언어로의 전환을 국가 차원에서 권고했다. 안전이 최우선인 자동차 산업에 시사하는 바가 더욱 크다.



성능 검증 - Cortex-M4에서 C와 대등한 수준

세온이앤에스와 자비스는 STM32F446RE(ARM Cortex-M4) 보드에서 C와 Rust의 성능을 직접 비교했다. 핵심은 GCC와 LLVM이라는 컴파일러 백엔드 차이를 제거하기 위해 양측 모두 동일한 LLVM 20.1.7 백엔드(Clang/LLVM과 Rust 기본 LLVM)를 사용했다는 점이다. DWT 사이클 카운터로 CPU 사이클을 직접 측정하고, 어셈블리 수준에서 화이트박스 분석을 병행했다.
산술, 메모리 접근, 제어흐름, 알고리즘, 통신, 수학 연산 등 ECU 실연산을 포괄하는 6개 카테고리, 16개 벤치마크의 결과는 다음과 같다.

- Rust 우위 7개 / C 우위 8개 / 동등 1개 - 전반적으로 대등
- Rust 최대 우위: DMA 메모리 +68%, 행렬 연산 +57%, 배열 접근 +33%
- C 최대 우위: 함수 호출 +83%, 제어흐름 +36%

수치 해석에는 단서가 필요하다. 본 비교는 각 언어에서 실무적으로 사용되는 관용적 코드(idiomatic code) + 기본 컴파일 설정을 전제로 한 결과다. 예컨대 C에서도 restrict 키워드를 명시적으로 사용하거나 memcpy() 표준 라이브러리를 활용하면 Rust와 유사한 수준의 최적화 경로를 기대할 수 있으나, 실무에서 이를 일상적으로 사용하지 않는 관행을 반영하여 본 비교에서는 사용하지 않았다. 따라서 위 수치는 "Rust가 본질적으로 C보다 빠르다"는 일반적 결론으로 확장될 수 없으며, 관용적 작성 방식과 기본 설정의 차이까지 함께 반영된 실무적 경향으로 읽는 것이 적절하다.
이러한 단서를 전제로 본 결과를 보면, Rust 우위의 한 동인으로 소유권 기반 noalias 최적화가 관찰된다. Rust의 소유권 규칙은 "이 참조는 다른 참조와 메모리 영역이 겹치지 않는다"는 보증을 컴파일러에 제공하므로 LLVM이 더 공격적인 루프 언롤링과 중복 로드 제거를 안전하게 수행할 수 있는 조건이 형성된다. C에서는 프로그래머가 restrict를 명시해야 하는 정보가 Rust에서는 언어 규칙으로 표현된다는 차이다.
C 우위 항목 중 함수 호출 격차는 Rust 컴파일러가 기본적으로 프레임 포인터를 유지하는 설정에서 비롯되며, -C force-frame-pointers=no 옵션으로 조정 가능하다. 즉 언어의 본질적 한계라기보다는 기본 설정의 차이로 보는 편이 적절하다.
핵심 통찰은 보편적 우열의 선언이 아니다. 특정 조건에서 안전성 강화와 성능 유지·개선이 동시에 가능하다는 점, 즉 "안전성과 성능은 양자택일"이라는 기존 이분법이 항상 성립하지는 않을 수 있다는 점이다.



안전성 검증 - CAN 스택 결함 주입 실증 

성능이 동등하다면, 다음 질문은 "안전성은 실제로 작동하는가"다. 연구진은 AUTOSAR 계층 구조를 참조하여 CAN 통신 스택을 Rust로 구현하고(MCAL은 STM32F446RE bxCAN 레지스터 직접 제어, no_std staticlib 빌드), 의도적 결함을 주입했다.
컴파일 타임 결함 차단의 효과는 결정적이었다. [u8; 8]을 요구하는 함수에 [u8; 4]를 전달하는 코드는 C에서는 포인터 퇴화로 경고 없이 빌드되어 런타임에 버퍼 오버리드를 일으키지만, Rust에서는 빌드 자체가 불가능하다. 8바이트 버퍼의 인덱스 8 접근 또한 Rust에서는 컴파일 타임 또는 런타임 바운드 체크로 차단된다.
ISR-메인 루프 공유 자원 무결성 측정 결과도 인상적이다. Rust 임베디드 크레이트의 Mutex를 적용한 CAN 메시지 처리는 평균 31 사이클, 표준편차 0의 완벽한 결정론적 동작을 보였다. Mutex 미적용으로 ISR 간섭이 발생하면 평균 38 사이클이지만 표준편차가 26으로 흔들리고 30~116 사이클의 비결정적 지터가 관찰됐다. Mutex 추가로 인한 본질적 비용은 14 사이클 - 16MHz 기준 1마이크로초 미만이며, 이는 C에서 __disable_irq()/__enable_irq()를 직접 호출할 때도 동일하게 지불해야 하는 비용이다. 즉 Rust 추상화 계층 자체의 오버헤드는 사실상 없다.
Panic Handler Fail-safe는 ISO 26262 Fail-safe 설계 취지에 부합하는 메커니즘을 단 98바이트, 31 사이클(약 2마이크로초)로 구현 가능함을 보였다. 정의되지 않은 동작으로 잘못된 제어 명령이 계속 전달되는 것보다, 2마이크로초 안에 안전 상태로 전환되는 편이 기능안전 관점에서 압도적으로 유리하다.



FFI 통합 - 기존 C 코드베이스와의 점진적 공존

가장 현실적인 질문은 "수십 년 축적된 AUTOSAR C 코드베이스와 어떻게 통합할 것인가"다. 현실적인 한 가지 접근이 FFI(Foreign Function Interface)다. Rust FFI는 C ABI와 직접 호환되며, JNI나 ctypes와 달리 추가적인 런타임 계층이 없어 함수 호출 수준의 오버헤드는 매우 작다.
다만 FFI를 "비용이 거의 없는 통합 수단"으로만 보는 것은 적절하지 않다. 함수 호출 오버헤드와는 별개로, ABI 호환성 확보, C/Rust 간 데이터 레이아웃 설계, 두 빌드 시스템의 통합 등 시스템 수준의 엔지니어링 비용은 별도로 고려해야 한다. 즉 "FFI를 쓰면 자동으로 통합된다"가 아니라, "FFI는 통합의 출발점이며 그 위에 신중한 설계가 얹혀야 한다"는 관점이 필요하다.
통합 아키텍처 자체는 비교적 단순하다. Rust 소스를 Cargo로 크로스 컴파일하여 정적 라이브러리(.a)를 생성한 뒤(thumbv7em-none-eabihf, staticlib, panic = "abort", codegen-units = 1), AUTOSAR 빌드 시스템(SCons/CMake)이 이를 기존 C 소스, BSW, RTE와 함께 링킹한다. AUTOSAR 빌드 시스템 측에서는 일반적인 C 라이브러리 하나가 추가되는 형태이므로, 기존 빌드 시스템 자체에 대한 변경 부담은 크지 않다. 다만 실제 통합 단계에서는 SCons와 Cargo 빌드를 연결하기 위한 최소한의 설정 작업이 필요하며, "AUTOSAR 빌드 시스템을 전혀 손대지 않는다"는 의미는 아니다.
인터페이스 설계는 세 어트리뷰트의 조합으로 이뤄진다. #[no_mangle]은 이름 맹글링을 비활성화하고, extern "C"는 C 호출 규약을 적용하며, #[repr(C)]는 구조체 메모리 레이아웃을 C와 일치시킨다. C 측 AUTOSAR SWC에서는 일반적인 외부 함수 호출과 동일하게 Rust 함수를 사용한다.
Rust 코드가 삽입되는 지점은 SWC의 Runnable 내부다. MCAL, BSW, RTE는 기존 C가 그대로 동작하고, Runnable 내에서 C 래퍼를 통해 Rust FFI 함수가 호출된다. RTE 스케줄링과 BSW 스택은 변경이 없다. 무엇보다도 Runnable 단위 점진 전환이 가능하다는 점이 결정적이다. 하나의 SWC 안에서도 일부 Runnable만 Rust로 옮기고 나머지는 C로 유지할 수 있어, 리스크를 통제하면서 비중을 늘려갈 수 있다.



mobilgene 플랫폼 구동 결과

이론적 아키텍처를 넘어, 양산 플랫폼 계열 환경에서의 구동도 확인됐다. 현대오토에버의 mobilgene 플랫폼(AUTOSAR Classic 4.4, R44)과 NXP S32K312 EVB(ARM Cortex-M7, 120MHz, 2MB Flash, 256KB SRAM), Lauterbach TRACE32 디버거 조합으로 시험을 진행했다.
테스트는 7개 카테고리, 26개 FFI 함수로 설계됐다. 기본 연산, 메모리 접근, 제어흐름, 통신 프로토콜(CAN 프레임, CRC, 링버퍼), 실시간 태스크(스케줄링, 세마포어, 메시지 큐), 알고리즘(정렬, 검색, 필터, PID 제어), 하드웨어 인터페이스(GPIO, 레지스터, 인터럽트)까지 ECU 연산 패턴을 폭넓게 다뤘다. 각 함수별 1,000회 이상 반복 측정, 첫 100회는 워밍업으로 제외, 평균·표준편차·95% 신뢰구간·변동계수 산출, t-test/Mann-Whitney U(p<0.05) 검정으로 통계적 유의성을 확인했다.
결과는 26개 FFI 함수 전체가 mobilgene AUTOSAR Classic 4.4 플랫폼에서 정상 구동됐다. 의미는 세 가지다.

1. no_std와 staticlib 조합으로 AUTOSAR BSW 스택과 무결한 통합이 가능하다.
2. ECU의 주요 연산 패턴 전반을 Rust FFI로 구현·실행할 수 있다.
3. 기존 AUTOSAR 빌드 시스템(SCons)과 Cargo 빌드를 최소한의 수정으로 통합할 수 있다.

이는 Rust-AUTOSAR FFI 통합이 연구실 수준의 개념 증명이 아니라, 양산 플랫폼 계열 환경에서 구동이 확인된 실현 가능한 전략임을 보여준다.



3단계 점진적 도입 로드맵

전면 전환은 현실적이지도, 바람직하지도 않다. 연구진이 제안하는 도입 경로는 다음 3단계다.

1단계 - 유틸리티/알고리즘 모듈: CRC 계산, 룩업 테이블, 디지털 필터 등 BSW나 하드웨어 의존성이 없는 순수 연산 모듈에서 시작한다. 입출력이 명확하고 C 구현과의 동치성 검증이 쉬우며, 문제 발생 시 즉시 롤백할 수 있다. 이 단계의 진정한 목적은 팀 역량 확보, 빌드 파이프라인 구축, FFI 인터페이스 패턴 수립, 테스트 방법론 정립 등 이후 단계의 기반을 마련하는 데 있다.

2단계 - Safety-critical SWC 확장: ASIL 등급이 부여된 안전 관련 모듈(CAN/LIN 통신 처리, 센서 데이터 검증, 진단 모듈)에 적용한다. Rust의 컴파일 타임 안전성 보장은 ISO 26262가 요구하는 소프트웨어 안전성 확보에 유리한 특성을 제공한다. 다만 실제 ASIL 적용에는 별도의 안전 논증(Safety Case)과 ISO 26262 Part 8 기반의 도구 인증이 선행되어야 한다.

3단계 - Rust 네이티브 AUTOSAR 바인딩: 개별 함수 수준의 FFI를 넘어, AUTOSAR BSW API에 대한 체계적인 Rust 바인딩을 구축하여 SWC 전체를 Rust로 작성한다. bindgen 기반 자동 바인딩 생성과, Rust 타입 시스템을 활용한 안전한 래퍼 API 설계가 핵심 과제다. 이 단계에 이르면 Rust는 AUTOSAR 생태계의 일급 시민(first-class citizen)이 된다.

핵심은 "모든 것을 한 번에 바꾸겠다"가 아니라 "증명된 만큼만 확장하겠다"는 자세다.



맺음말 - "도입 타당성을 본격 검토할 시점"

본 실증은 세 가지 축을 정량적으로 검증했다. 첫째, ARM Cortex-M4 동일 LLVM 백엔드 비교에서 Rust는 C와 대등한 성능을 보였고, noalias 최적화로 특정 영역에서는 C를 상회했다. 둘째, 컴파일 타임 결함 차단, 14 사이클 Mutex 오버헤드, 31 사이클 Panic Handler 레이턴시는 Rust의 안전성 메커니즘이 실시간 ECU 환경에서 실용적임을 입증했다. 셋째, mobilgene 플랫폼 위 26개 FFI 함수의 정상 구동은 AUTOSAR Classic과의 실제적 통합 가능성을 확인시켰다.
기존 AUTOSAR 빌드 시스템에 최소한의 변경만으로 통합할 수 있고, BSW 스택에 영향을 주지 않으면서, Runnable 단위로 하나씩 전환해 나갈 수 있다는 사실은 실무적 도입 가능성이 충분함을 시사한다. 차량용 소프트웨어 복잡도 증가와 SDV 전환이 가속화되는 지금, Rust는 더 이상 "관심을 가져볼 만한 언어"가 아닌 "도입 타당성을 본격적으로 검토해야 할 기술"이다.
이 글은 세온이앤에스·자비스(JARBIS) 공동 백서 「차량용 임베디드 소프트웨어에서의 Rust 적용 전략 - FFI 기반 AUTOSAR 통합을 중심으로」(2026)를 바탕으로 작성되었다.

AEM(오토모티브일렉트로닉스매거진)