비전 문서(Vision Doc) 작업을 통해 안전 필수 소프트웨어 분야에서 Rust를 실제로 출시·운용하는 데 필요한 조건과 남은 과제들을 정리한다.
2026년 1월 14일 · Vision Doc 그룹을 대표하여 Pete LeVasseur
이 글은 Vision Doc 프로세스를 통해 우리가 배운 내용을 다루는 연재의 또 다른 글입니다. 첫 번째 글에서는 전체적인 접근 방식과 사용자 조사(user research)를 하며 배운 점을 설명했습니다. 두 번째 글에서는 사람들이 Rust를 좋아하는 이유를 살펴봤습니다. 이번 글은 한 도메인—안전 필수 소프트웨어—를 깊게 파고듭니다.
Vision Doc 작업을 시작했을 때, 우리가 깊이 탐구하고 싶었던 분야 중 하나는 안전 필수 시스템(safety-critical systems)이었습니다. 이는 소프트웨어의 오작동이 부상, 사망, 또는 환경 피해로 이어질 수 있는 영역입니다. 차량, 항공기, 의료기기, 산업 자동화를 떠올리면 됩니다. 우리는 자동차(대부분), 산업, 항공우주, 의료 분야 전반에서 OEM, 시스템 통합업체(integrator), 공급업체(supplier)의 엔지니어들과 대화했습니다.
우리가 발견한 점은 어느 정도 놀라웠습니다. 대화는 계속해서 하나의 긴장 관계로 되돌아갔습니다. Rust 컴파일러가 강제하는 보장(guarantees)은 이 영역의 기능 안전 엔지니어(Functional Safety Engineers)와 소프트웨어 엔지니어들이 시간을 들여 예방해 온 많은 문제를 직접적으로 지원합니다. 하지만 프로토타이핑 단계를 넘어 시스템의 더 높은 중요도(criticality) 영역으로 들어가면, 생태계 지원이 빠르게 얇아집니다. MATLAB/Simulink 같은 Rust 코드 생성이 없습니다. OSEK 또는 AUTOSAR Classic 호환 RTOS가 Rust로 작성되어 있거나 Rust를 1급으로 지원하는 형태도 없습니다. 자격 검증(qualification)과 인증(certification)을 위한 도구(tooling)는 여전히 성숙해 가는 중입니다.
이 분야에서 일해본 적이 없다면, 요점을 짧게 정리하면 이렇습니다. 각 안전 필수 도메인에는 무결성(integrity) 수준의 단계(사다리)를 정의하는 표준이 있습니다. 자동차는 ISO 26262, 산업은 IEC 61508, 의료기기는 IEC 62304, 항공우주는 DO-178C입니다. 세부사항은 다르지만 형태는 비슷합니다. 더 높은 중요도 방향으로 사다리를 올라갈수록 개발 프로세스, 검증(verification), 그리고 증거(evidence)에 대한 요구가 증가하고, 비용도 커집니다.1
이 때문에 분해(decomposition) 에 대한 강한 유인이 생깁니다. 가장 높은 중요도의 로직을 가능한 한 작은 표면적(surface area)으로 격리하고, 나머지는 비용이 더 관리하기 쉬운 낮은 수준에 유지하여 더 빠르게 움직이는 것입니다.
이 글에서는 인터뷰가 가장 많이 나온 자동차 용어(QM에서 ASIL D까지)를 사용하겠습니다. 다만 패턴은 다른 도메인에도 일반화됩니다. 이 용어들은 안전 중요도가 증가하는 단계를 나타내며, QM이 가장 낮고 ASIL D가 가장 높습니다. 도메인과 무관하게 낮은 중요도에서의 이야기는 높은 중요도에서의 이야기와 매우 다릅니다.
과제를 살펴보기 전에, Rust가 이 영역에서 단지 “평가 중”이 아니라는 점을 언급할 가치가 있습니다. Rust는 실제로 배포되어 프로덕션에서 실행 중입니다.
우리는 IEC 61508 SIL 2 인증을 받은 모바일 로보틱스 시스템을 담당하는 한 수석 펌웨어 엔지니어(principal firmware engineer)와 이야기를 나눴습니다.
“안전 시스템이 포함된 새 프로젝트가 예정되어 있었어요. 과거에는 이런 프로젝트를 늘 C로 했고, 제3자 스택 분석(stack analysis) 및 단위 테스트 도구를 썼는데 대체로 별로 좋지 않았죠. 하지만 안전 등급 표준 때문에 해야만 했습니다. Rust는 스택 분석 도구가 검사해야 했던 것의 90%를 컴파일러가 그냥 처리해 준다는 점에서 기회였어요. 거기에 더해 이제 안전 자격을 갖춘(qualified) 컴파일러가 있다는 점을 제시할 수 있게 되면서, 일종의 돌파구가 됐죠.” — 수석 펌웨어 엔지니어(모바일 로보틱스)
또한 ICU(중환자실)에 IEC 62304 Class B 소프트웨어를 배포하는 의료기기 회사의 엔지니어와도 이야기했습니다.
“최종 사용자와 고객에게 배포하는 제품 코드 전체가 현재 Rust로 되어 있습니다. 우리는 소프트웨어로 EEG 분석을 하고 있고, 그게 ICU(중환자실)와 환자 모니터에 배포되고 있습니다.” — 의료기기 회사의 Rust 개발자
“이 Python 컴포넌트를 Rust 컴포넌트로 바꿨는데, 속도가 100배 증가한 것 같습니다.” — 의료기기 회사의 Rust 개발자
이들은 개념 증명(proof of concept)이 아닙니다. 규제 환경(regulated environment)에서 실제로 출하(shipping)되는 시스템이며, 감사(audit)와 인증 절차를 거치고 있습니다. 길은 이미 존재합니다. 질문은 다음 팀들이 그 길을 지나갈 때 더 쉽게 만들려면 어떻게 해야 하느냐입니다.
낮은 중요도에서 팀들은 실용적인 접근을 설명했습니다. Rust와 crates 생태계를 이용해 빠르게 움직인 다음, 출하하는 것을 강화(harden)하는 방식입니다. 한 자동차 OEM의 아키텍트는 이렇게 말했습니다.
“우리는 [crates.io의] 어떤 크레이트든 사용할 수 있습니다 [..] 다만 프로덕션 사용을 위해 소프트웨어 컴포넌트를 준비하는 일은 우리가 주의해서 해야 합니다.” — 자동차 OEM 아키텍트
하지만 더 높은 수준에서는 제3자 의존성을 정당화하기가 어려워집니다. 팀들은 재작성(rewrite)하거나, 내부화(internalize)하거나, 사용하는 범위를 엄격히 제한합니다. 한 임베디드 시스템 엔지니어는 직설적으로 말했습니다.
“우리는 제3자 의존성이나 nursery 크레이트를 쓰지 않는 편입니다 [..] 스택 아래로 내려갈수록 솔루션은 점점 더 임기응변(kludgy)적이 됩니다.” — 펌웨어 엔지니어
어떤 팀들은 “탈출구(escape hatch)”를 만들기도 했습니다. 미래에 교체할 수 있도록 설계한 추상화 계층(abstraction layer)입니다.
“나중에 교체를 쉽게 하기 위해, 궁극적으로 갖고 싶어 하는 인터페이스를 만들어 둡니다 [..] 때로는 재작성하고, 기존 크레이트를 재사용하더라도 API를 바꾸거나 테스트를 더 많이 작성하곤 합니다.” — 자동차 공급업체 팀 리드(목표 ASIL D)
또 crates.io의 크레이트를 사용하는 팀들조차도, 그것을 초기 가속기 정도로 취급한다고 했습니다. 주의 깊게 추적하고, 출하 전에는 크리티컬 경로에서 제거하려는 대상으로요.
“초기에는 빠르게 셋업해야 하는 것들—개념 증명 같은 것—에 주로 크레이트를 쓰지만, 그런 의존성은 아주 명시적으로 추적하고, 소프트웨어의 크리티컬한 부분에서는 장기적으로 제거하려고 합니다.” — Rust로 미들웨어를 개발하는 자동차 소프트웨어 회사의 팀 리드
항공우주에서는 “스택 전체를 통제(control the whole stack)해야 한다”는 본능이 더 강합니다.
“항공우주에서는 우리가 모든 코드를 직접 소유해야 한다는 개념이 있습니다. 코드 한 줄 한 줄까지 통제해야 합니다.” — 항공우주 분야 엔지니어링 리드
여기서 첫 번째 핵심 결론이 나옵니다. 안전 필수에서의 Rust는 단지 Rust가 특정 타깃에서 컴파일되느냐의 문제가 아닙니다. 팀이 ‘증거 친화적(evidence-friendly)’인 소프트웨어 스택을 구성할 수 있는지, 그리고 긴 제품 수명 동안 그것을 안정적으로 유지할 수 있는지가 핵심입니다.
많은 인터뷰 대상자들은 Rust의 가치를, 컴파일러가 더 앞단으로 일을 이동시키고 반복 가능하게 만든다는 관점에서 설명했습니다. 이는 단지 “좋다” 수준이 아니라, 현실적으로 감당할 수 있는 수동 리뷰(manual review)의 양을 바꿔 놓습니다. MISRA C와 CERT C 같은 코딩 표준을 통해 역사적으로 프로세스 기반으로 강제하던 많은 것들이 Rust에서는 언어 수준의 관심사가 되고, 외부 정적 분석 도구나 수동 리뷰가 아니라 컴파일러에 의해 검사됩니다.
“예전에 외부 도구로 검사하던 것의 대략 90%가 Rust 컴파일러에 내장되어 있습니다.” — 수석 펌웨어 엔지니어(모바일 로보틱스)
대규모 코드베이스와 다양한 숙련도 수준을 다루는 팀들로부터도 비슷한 이야기를 들었습니다.
“우리는 개발자들의 역량을 처음부터 끝까지 통제할 수 없습니다. 코드 품질을 점검해야 하죠. Rust는 컴파일 타임 체크나 Clippy 도구를 통해 우리 도메인에 매우 유용합니다.” — 대형 자동차 회사 엔지니어
작은 팀에서도 리뷰 부담은 중요합니다.
“저는 보통 5~8명 팀에서 일합니다. 그래도 코드가 너무 많아요. 더 빠르게 움직일 수 있다는 자신감이 생깁니다. 어떤 종류의 결함은 더 이상 걱정하지 않게 되니까요.” — 임베디드 시스템 엔지니어(모바일 로보틱스)
밀접하게 연결된 또 다른 점으로, 사람들은 Rust 생태계 전반의 오류 처리(error handling) 일관성을 반복해서 강조했습니다.
“생태계 전반에서 쓰이는 단 하나의, 받아들여진 오류 처리 방식이 있다는 점은 Rust가 정말 제대로 한 것입니다.” — 자동차 분야 테크니컬 리드
수명이 15~20년에 달하고 “팀의 집합(teams of teams)” 형태로 개발되는 제품에서, 컴파일러가 강제하는 불변조건(invariants)은 “그냥 더 열심히 리뷰하자”보다 더 잘 확장됩니다.
안전 필수 환경에서는 보수적인 툴체인 선택이 흔합니다. 하지만 엔지니어들은 긴장 관계를 지적했습니다. 오래된 툴체인에는 그 자체로 결함 이력(defect history)이 있기 때문입니다.
“[..] 전통적인 통념은 무언가가 오래 존재했고 여러 절차/테스트를 거치면 더 안정적이고 안전하다고 보는 겁니다 [..] 하지만 오래된 컴파일러는 버그가 더 많고, 그 선택을 정당화하기가 어려워집니다.” — 자동차 공급업체 소프트웨어 엔지니어
Rust의 에디션(edition) 시스템은 여기서 실제 장점으로 언급됐는데, 특히 자동차 프로그램에서 흔한 점진적 마이그레이션(incremental migration) 전략에 유리하다고 했습니다.
“[에디션 시스템은] 점진적 마이그레이션이 필수인 자동차 분야에 ‘황금’ 같습니다.” — 대형 자동차 회사 소프트웨어 엔지니어
실무에서 “안정성”은 플랫폼이 지원하는 것과 생태계가 기대하는 것 사이의 불일치를 관리하는 문제이기도 합니다. 팀들은 Rust 버전을 고정(pin)한 다음, 의존성 드리프트(dependency drift)와 싸운다고 설명했습니다.
“우리는 Rust 툴체인을 고정할 수 있지만, 거의 모든 크레이트가 최신 버전에 맞춰 구현되어 있어서 다운그레이드를 해야 합니다. 시간이 아주 많이 듭니다.” — 대형 자동차 회사 엔지니어
안전 필수 도입에서 “안정성”은 운영상의 문제입니다. 팀들은 이런 질문들에 답해야 합니다. Rust 업그레이드는 무엇을 바꾸고, 무엇을 바꾸지 않는가? 마이그레이션 작업의 범위는 어디까지인가? 업그레이드 위험을 관리했다는 것을 어떻게 입증하는가?
안전 필수 소프트웨어는 종종 수명이 긴 플랫폼과 RTOS 위에서 동작합니다. “지원이 존재한다”고 해도 주의사항이 있을 수 있습니다. 예컨대 QNX 같은 타깃에서는 업스트림 Rust 지원이 존재하지만 제한이 있습니다(예: 현재 QNX 8.0 지원은 no_std 전용).2
이는 Rust의 타깃 티어(target tier) 정책과도 연결됩니다. 정책 자체는 명확하지만, 규제 환경의 팀들은 “티어”를 “이 플랫폼과 제품 수명에 대해 책임 있게 어떤 수준까지 베팅할 수 있는가”로 매핑해야 합니다.
“갑자기 컴파일러와 툴체인을 업그레이드했더니 우리가 쓰는 Tier 3 타깃에서 의존성이 더 이상 동작하지 않는 경험이 있었습니다. 그건 절대 용납될 수 없습니다. 어떤 기술에 투자하려면 일정 수준의 신뢰성이 필요합니다.” — 대형 자동차 회사 시니어 소프트웨어 엔지니어
core는 등뼈(spine)이며, 기대치를 설정한다no_std 환경에서 core는 Rust의 등뼈가 됩니다. 팀들은 core가 실제 제품을 만들기에는 충분히 풍부하면서도, 감사(audit)하기에는 충분히 작다고 설명했습니다.
Rust의 안전성 레버리지(leverage) 상당 부분이 여기에 있습니다. Option과 Result, 슬라이스(slices), 이터레이터(iterators), Cell과 RefCell, 아토믹(atomics), MaybeUninit, Pin. 하지만 우리는 빈틈(gaps)의 전형적인 형태도 들었습니다. 많은 임베디드 및 안전 필수 프로젝트는 no_std 친화적인 빌딩 블록(고정 크기 컬렉션, 큐)과 예측 가능한 수학 기본 요소(math primitives)를 원하지만, 더 높은 무결성 수준에서는 “아무” 제3자 크레이트에 의존하고 싶지 않아 합니다.
“수학 라이브러리 대부분은 core에 없고 std에 있습니다. 사인, 코사인… 지금은 libm 크레이트로 우회하고 있는데, core에 있으면 좋겠어요.” — 수석 펌웨어 엔지니어(모바일 로보틱스)
안전 필수에 인접한(safety-critical-adjacent) 일부 시스템은 이미 강하게 비동기적(asynchronous)입니다. 데몬(daemons), 미들웨어 프레임워크, 이벤트 기반 아키텍처가 그렇습니다. 그래서 Rust의 async 스토리는 흥미롭습니다.
하지만 사람들은 생태계 종속(lock-in)과, 더 높은 중요도의 컴포넌트에서 async를 사용하려면 무엇이 필요할지에 대한 불확실성도 표현했습니다. 미들웨어를 개발하는 한 팀 리드는 이렇게 말했습니다.
“안전 필수에서 Rust의 async가 장기적으로 어떻게 될지 확신이 없습니다. [..] 우리 소프트웨어의 상당 부분이 고도로 비동기적이고, AUTOSAR Adaptive Platform 세계의 많은 데몬은 기본적으로 리액터(reactor) 패턴을 따릅니다. [..] [C++14]는 이런 개념을 제대로 지원하지 않기 때문에, 이런 부분은 익숙하지 않아서 생기는 문제도 있습니다.” — Rust로 미들웨어를 개발하는 자동차 소프트웨어 회사의 팀 리드
또 팀들이 ISO 26262 관점에서 async를 보면, 런타임(runtime) 문제가 즉시 등장합니다.
“async Rust를 활용하려면, 물론 런타임이 필요하고 ISO 26262를 위한 모든 품질 아티팩트(quality artifacts)와 프로세스 아티팩트(process artifacts)를 제공해야 합니다.” — Rust로 미들웨어를 개발하는 자동차 소프트웨어 회사의 팀 리드
안전 필수 맥락에서 async는 “그냥 언어 기능”이 아닙니다. 이는 런타임 선택, 스케줄링 가정(scheduling assumptions), 그리고 더 높은 무결성 수준에서는 스택의 관련 부분을 인증하거나 자격 검증하는 것이 무엇을 의미하는지라는 질문을 끌어옵니다.
안전 필수 커뮤니티가 스스로의 필요를 지원할 수 있도록 돕는 방법을 찾자. 오픈 소스는 스스로 돕는 사람을 돕습니다. Ferrocene 언어 명세(Ferrocene Language Specification, FLS)는 이것이 잘 작동하는 사례입니다. FLS는 Rust 컴파일러의 안전 자격 검증에 적합한 명세를 만들기 위한 업계 노력으로 시작되었고, 기업들이 작업에 투자했으며, 이제 Rust 프로젝트 산하에 지속 가능한 보금자리를 갖고 이를 적극적으로 유지보수하는 팀이 있습니다.3
이를 rustc의 MC/DC 커버리지 지원과 대비해 보십시오. 초기 노력은 안전 필수 기업들의 지속적인 참여 부족으로 정체되었습니다.4 기술적 작업은 있었지만, 요구 사항을 정의하고 구현을 검증하며 유지보수를 약속할 업계 참여가 없어서 추진력이 떨어졌습니다. 큰 우려는 MC/DC 코드가 명확한 소유자 없이 다른 커버리지 인프라 전체에 유지보수 부담을 더한다는 점이었습니다. 2026년 현재, 이를 올바르게 진행하려는 새로운 관심이 생겼습니다. 기업들은 Safety-Critical Rust Consortium을 통해 2026년에 Rust 프로젝트 목표(Rust Project Goal)를 만들어 Rust 프로젝트와 MC/DC 지원을 협업하려 하고 있습니다. 모델은 요구 사항을 공동 소유(shared ownership)하고, 안전 필수에 이해관계가 있는 기업들이 주된 구현과 유지보수를 담당하되, 나머지 커버리지 코드의 유지보수를 방해하지 않는 방식으로 진행하는 것입니다.
나머지 권고 사항들도 이 패턴을 따릅니다. Safety-Critical Rust Consortium이 커뮤니티가 요구 사항을 정리하고 작업을 추진하도록 돕고, Rust 프로젝트는 성공적인 협업에 필요한 Rust 프로젝트 산출물(artifacts)에 대한 깊은 기술 지식을 제공합니다. 양쪽 모두가 참여할 때 이 길은 작동합니다.
생태계 전반의 MSRV 관례를 확립하자. 의존성 드리프트 문제는 실제입니다. 팀들은 안정성을 위해 Rust 툴체인을 고정하지만, 최신 컴파일러를 겨냥한 크레이트들 때문에 이를 지속하기가 어렵습니다. LTS 릴리스 스킴과, 라이브러리들이 LTS 릴리스에 대한 MSRV 호환성을 유지하도록 장려하는 방식이 결합되면 마찰을 줄일 수 있습니다. 이를 위해 Rust 프로젝트(잠재적으로 릴리스 팀)와 더 넓은 생태계 사이의 조정이 필요하며, Safety-Critical Rust Consortium이 요구 사항과 도입 패턴을 명확히 하는 데 도움을 줄 수 있습니다.
“타깃 티어 정책”을 안전 필수 온램프(onramp)로 바꾸자. 우리가 들은 마찰은 정책이 불명확해서가 아니라, “티어”를 실무 의사결정으로 번역하기 어렵다는 데 있습니다. 짧고 타깃 중심의 준비도 체크리스트(readiness checklist)가 도움이 될 것입니다. 어떤 타깃이 존재하는가? 어떤 타깃이 no_std 전용인가? 마지막으로 테스트된 OS 버전은 무엇인가? 가장 큰 블로커(blockers)는 무엇인가? 원재료는 rustc 문서, 릴리스 노트, 이슈 트래커에 있지만, 이를 한 곳에 모아두면 진입 장벽이 낮아집니다. 더 명확하고 통합된 정보는 특정 타깃에 의존하는 팀들이 그 타깃을 유지하는 데 기여하기도 쉽게 만듭니다. Safety-Critical Rust Consortium이 이 노력을 주도하고, 컴파일러 팀 구성원 및 플랫폼 메인테이너들과 협력해 정보를 정확하게 유지할 수 있습니다.
팀들이 이미 사용 중인 “의존성 라이프사이클” 패턴을 문서화하자. QM 단계의 이야기는 흔히 이렇습니다. 초기에 크레이트를 사용하고, 주의 깊게 추적하며, 더 높은 중요도의 부분을 위해 의존성을 줄여나간다. ASIL B+ 단계의 이야기는 흔히 이렇습니다. 제3자 크레이트를 아예 피하거나, 추상화 계층을 사용하고 나중에 교체할 계획을 세운다. 이런 패턴을 재사용 가능한 플레이북(playbook)으로 만들면, 새 팀들이 시행착오를 줄이고 같은 움직임을 할 수 있습니다. 이는 Safety-Critical Rust Consortium의 연락(liaison) 업무에 자연스럽게 맞는 주제처럼 보입니다.
안전 케이스(safety-case) 친화적인 async 런타임에 대한 요구 사항을 정의하자. 안전 필수 맥락에서 async를 도입하는 팀들은 ISO 26262 같은 표준에 맞는 적절한 품질/프로세스 아티팩트를 갖춘 런타임을 필요로 합니다. 이 분야에서는 이미 작업이 진행 중입니다.5 Safety-Critical Rust Consortium이 “안전 케이스 친화적”이란 무엇인지 구체적인 용어로 정의하는 노력을 주도하고, async 워킹 그룹 및 라이브러리 팀(libs team)과 함께 기술적 실현 가능성과 설계를 논의할 수 있습니다.
상호운용성(interop)을 안전 이야기의 일부로 다루자. 많은 팀들은 세상을 전부 Rust로 다시 쓰지 않을 것입니다. 기존 C 및 C++ 시스템에 Rust를 통합하고, 그 경계를 수년간 유지할 것입니다. 인터페이스가 올바르고, 감사 가능하며, 동기화된 상태로 유지되도록 돕는 가이드와 도구는 큰 도움이 됩니다. 컴파일러 팀과 언어 팀(lang team)은 Safety-Critical Rust Consortium을 통해 수집된 요구 사항을 바탕으로, FFI 경계가 어떻게 드러나고 검사되는지에 대해 고려할 수 있습니다.
“우리는 C, C++, Rust 사이의 FFI 호환성에 매우 크게 의존합니다. 안전 필수 영역에서는 결국 그 부분이 어려움이 됩니다. 바인딩을 생성하고, 문제가 무엇이었는지 찾아내는 것 말이죠.” — 임베디드 시스템 엔지니어(모바일 로보틱스)
이 글의 핵심을 요약하면 다음과 같습니다.
우리는 여섯 가지 권고 사항을 제시했습니다. 안전 필수 커뮤니티가 스스로의 필요를 지원하도록 돕는 방법을 찾기, 생태계 전반의 MSRV 관례 확립, 타깃 중심의 준비도 체크리스트 만들기, 의존성 라이프사이클 패턴 문서화, 안전 케이스 친화적인 async 런타임 요구 사항 정의, C/C++ 상호운용성을 안전 이야기의 일부로 다루기입니다.
안전 필수 Rust를 다루고 있거나, 더 쉽게 만들고 싶다면 Rust Foundation의 Safety-Critical Rust Consortium과 진행 중인 Safety-Critical Rust 코딩 가이드라인을 확인해 보세요.
구체적인 제약 조건, 심사자(assessor) 피드백의 예, 그리고 실제로 “증거(evidence)”가 실무에서 어떤 모습인지 듣는 것은 엄청나게 도움이 됩니다. 목표는, 정확성과 안전이 선택 사항이 아닌 환경에서 Rust의 강점을 더 쉽게 활용할 수 있도록 만드는 것입니다.
ISO 26262에서 엄격함(rigor)이 비용과 함께 어떻게 확장되는지 궁금하다면, Feabhas 가이드가 고수준 개요를 잘 제공합니다. ↩
FLS 팀은 2025년에 Rust 프로젝트 산하에 생성되었습니다. 현재 팀은 명세를 적극적으로 유지보수하며, 변경을 리뷰하고 언어의 진화와 FLS를 동기화하고 있습니다. ↩
맥락은 MC/DC 트래킹 이슈를 참고하세요. 초기 구현은 유지보수 우려로 인해 제거되었습니다. ↩
Eclipse SDV의 Eclipse S-CORE 프로젝트에는 안전 필수 자동차 소프트웨어를 목표로, async 런타임을 위한 Rust 작성 오케스트레이터(Orchestrator)가 포함되어 있습니다. ↩
Rust 팀이 유지보수합니다. 오타를 발견했나요? 여기서 수정 제안을 보내세요!