설계서 취약점 없앤다: Rust 실증 근거와 차량 SW 도입

메모리 안전성 취약점은 여전히 주요 보안 위협으로 남아 있다. 패치·완화·탐지 중심의 전통적 대응은 반복적이고 비용이 많이 든다. 이런 한계를 극복하기 위해 최근에는 개발 단계에서 보안을 설계에 내재화하는 접근(Secure by Design)이 주목받고 있다. 그중에서도 Rust는 대표적인 ‘메모리 안전 언어’로 평가받으며, 구글의 Android 사례를 통해 실증적 효과가 확인되었다. 이 글에서는 구글의 연구 결과를 중심으로, Rust 도입이 어떻게 보안 문제를 구조적으로 완화할 수 있는지 살펴보고, 자동차 분야에서 이 전략을 적용할 때 고려해야 할 점을 함께 말한다.

세온이앤에스(Seon ENS, Inc.)는 자동차 전장 분야를 중심으로 한 임베디드 소프트웨어 개발, 기능안전성 및 보안 컨설팅, 국제 인증 대응에 특화된 엔지니어링 전문 기업이다. 





 
구글은 Android의 보안 통계를 통해 다음과 같은 흥미로운 사실을 확인했다(참고 1). 
2019년 Android의 보안 취약점 중 약 76%가 메모리 안전성과 관련된 문제였지만, 2024년에는 그 비율이 24%로 급감했다. 이 변화는 특정 보안 도구나 탐지 기법의 개선 때문이 아니라, 새로 작성되는 코드를 메모리 안전 언어(Rust, Kotlin 등)로 전환한 결과였다. 즉, 취약점의 상당수가 ‘새 코드’에서 비롯된다는 점을 역이용한 것이다.
Rust로 작성된 코드는 컴파일 시점에서 메모리 접근 오류를 원천 차단하므로, 개발자가 런타임에서 문제를 발견하거나 패치로 보완할 필요가 크게 줄어든다. 이를 통해 Android 전체 코드베이스의 보안 수준이 꾸준히 향상됐다.
구글은 ‘기존 코드를 모두 Rust로 교체해야 한다’는 극단적 방식을 택하지 않았다. 대신 신규 코드는 Rust로 작성하고 기존 코드는 그대로 유지하는 ‘이중 전략(dual strategy)’을 선택했다. 이 접근은 문화적·기술적 저항을 줄이면서도, 새로운 코드에서 발생하는 취약점을 근본적으로 줄이는 효과를 냈다.
또한 기존 C/C++ 코드와의 상호운용성을 위해 Crubit, autocxx 등 다양한 도구를 개발해 두 언어 간 안전한 연결을 가능하게 했다. Rust로 작성된 모듈은 기존 시스템과 통합되더라도 런타임 오류나 메모리 해제 문제로 인한 시스템 크래시 가능성이 훨씬 낮았다. 이는 개발자들의 학습 곡선과 컴파일러의 엄격한 검증 때문이라 초기 도입에 시간이 오래 걸린다는 의견도 있지만, 이러한 초기 비용에도 불구하고 런타임 크래시 발생률은 C++보다 현저히 낮아 장기적으로 시스템 안정성에 긍정적 영향을 미친다.
이 결과는 “모든 코드를 바꿀 필요는 없으며, 새 코드부터 안전하게 설계하면 전체 보안성이 향상된다”는 점을 실증적으로 보여준다.


 
구글은 ‘취약점의 감쇠 모델(exponential decay model)’을 제시했다.
이는 시간이 지날수록 코드 내 취약점 밀도가 자연스럽게 감소한다는 가정에 기반한다.

 


그림 1은 취약점 수명의 분포를 수학적으로 모델링한 것이다. 이 함수는 지수분포를 기반으로 모델링했고, 생애주기 동안의 평균 취약점 수가 주어지면 그 분포가 정해진다. 이 수학적 모델과 실제 사례를 비교한 것이 그림 2다. 수학적 모델과 관측치가 잘 일치하는 것을 확인할 수 있다.
위 결과를 해석하면, 새 코드일수록 취약점이 많고 오래된 코드일수록 이미 수정과 검증을 거쳤기 때문에 취약점 발생 확률이 낮아진다. 즉, 직관적으로 보면 오래된 코드는 시간이 흐르며 취약점이 고쳐져 안정화되지만, 새롭게 배포된 코드에는 아직 드러나지 않은 취약점이 많아 배포 시점에 가장 취약하다는 결론에 도달한다.
결국 신규 코드에서 메모리 비안전 코드를 줄이는 것이 전체 보안 위험을 빠르게 낮추는 핵심 전략이다. 이 모델은 Android의 실제 취약점 데이터와 시뮬레이션 결과가 거의 일치한다는 점에서 신뢰성을 얻는다.
기존의 보안 접근은 대부분 사후 대응 중심이었다. 취약점을 찾고 패치하고 완화책을 추가하는 방식은 반복적이고 비용이 많이 든다. Rust의 도입은 이런 대응 중심 접근을 설계 중심(Secure-by-Design)으로 바꾸는 실질적 도구가 된다. Rust는 언어 차원에서 메모리 접근 오류를 차단하므로 보안의 상당 부분을 언어 설계 자체에 내장할 수 있다. 이것이 바로 ‘보안을 설계 단계에서 해결한다’는 개념의 실증적 예시다.


 
볼보는 2019년 Rust 적용 프로젝트를 시작해 2024년 최초 양산을 했다(참고 2). 
양산 이력이 없었기 때문에 처음부터 안전에 직결된 제어기에 적용하지는 못하고, 저전력 프로세서(Low Power Processor, LPP)에 적용했다. 개발은 4명 규모의 소규모 팀으로 시작해 최대 10명 정도의 시니어 엔지니어가 참여했다. 볼보 발표에 따르면 LPP 프로젝트에서는 3년 반 동안 단 18건의 결함 보고서(fault report)만 발생했다. 이는 유사한 규모의 다른 프로젝트보다 약 100배 적은 버그율로 평가된다.
물론 하나의 사례만으로 Rust의 자동차 도메인 전반 안전성을 단정할 수는 없다. 다만 볼보 사례는 Rust 도입이 불가능하지 않다는 실증적 증거로 볼 수 있다. 즉, 성능·가격·개발 비용 측면에서 기존 C 기반 제어기와 동등 수준이라면, 기능안전성(Functional Safety)과 사이버보안 측면에서 Rust 도입을 진지하게 고려할 만하다고 판단된다.
차량 소프트웨어 복잡성이 급증하고 전장 시스템이 점점 더 연결되는 상황에서 메모리 안전성은 단순 품질 이슈를 넘어 안전 및 보안의 핵심 요소가 된다. 다만 자동차 분야에 Rust를 도입할 때는 다음과 같은 사항을 신중히 고려해야 한다.


 
Rust는 ISO 26262와 AUTOSAR Classic 분야에서 완전한 인증 체계가 구축된 것은 아니지만, 일부 툴 체인이 ASIL-D 등급 자격을 획득하는 등 생태계가 빠르게 성숙하고 있다. 따라서 초기 도입 단계에서는 안전 필수 제어기보다는 진단 또는 보조 프로세서 등 리스크가 낮은 영역부터 적용하는 것이 현실적이다. Rust는 메모리 안전성을 강화하지만, 기능안전성은 별도의 검증·증빙 절차를 통해 입증해야 한다. 즉, 메모리 안전성이 곧 기능안전성을 의미하지는 않는다.


 
자동차 제어 시스템은 Android와 달리 하드 리얼타임 요구사항을 가진다. Rust의 소유권 검사나 Drop 트레이트가 실행 시간에 영향을 줄 수 있으므로, WCET(Worst-Case Execution Time) 분석을 포함한 실시간성 검증이 필요하다. 특히 RTOS 환경에서의 no_std 제약과 결정론적 실행 시간 보장이 추가 과제가 될 수 있다.


 
기존 C/C++ 개발 중심 조직에서는 Rust의 소유권 모델과 빌림(borrow) 개념이 낯설 수 있다. 학습 곡선과 코드 리뷰 문화의 변화까지 고려해 점진적 도입 로드맵을 설계하는 것이 바람직하다.


 
Rust와 C/C++의 FFI(외부 함수 인터페이스) 통합, 빌드 시스템 병합, 테스트 자동화 등 기술적 통합 지점에서의 관리가 중요하다. 이러한 과정은 보안뿐 아니라 안정성 검증의 품질에도 직접적으로 영향을 준다.


 
Rust가 코드 품질을 높이더라도 검증 절차(Verification & Validation)는 여전히 필수적이다. Rust의 안전성을 ISO 26262나 ASPICE 같은 품질 기준에 맞추어 체계적으로 입증할 수 있는 내부 절차와 문서화가 필요하다.
결국 자동차 소프트웨어에 Rust를 도입하는 것은 단순한 언어 교체가 아니라 조직 문화, 인증 체계, 개발 프로세스 전체를 함께 성숙시키는 과정이다. 이 점을 인식하고 단계적으로 추진한다면 Rust는 차량 소프트웨어의 보안성과 신뢰성을 동시에 높이는 유력한 수단이 될 것이다.
Rust는 보안을 사후적으로 ‘패치’하는 언어가 아니라, 문제를 설계 단계에서 예방하는 언어다. 구글의 Android 사례는 “새 코드부터 안전하게 작성하는 것만으로도 전체 시스템의 취약점을 줄일 수 있다”는 사실을 보여준다. 자동차 산업에서도 이런 원리를 적용해, 새롭게 개발되는 모듈부터 Rust를 도입하고 기존 시스템과 안전하게 연동하는 전략을 취한다면 장기적으로 더 안전하고 신뢰성 높은 차량 소프트웨어 생태계를 구축할 수 있다.


 

---

참고문헌
1. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?utm_source=chatgpt.com
2. https://www.youtube.com/watch?v=2JIFUk4f0iE

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

---