Microsoft가 Rust를 tier-1로 올렸다 — 선언이 아니라 백엔드의 문제
Microsoft가 Rust를 tier-1로 올렸다 — 선언이 아니라 백엔드의 문제
플랫폼 벤더가 새 언어를 「1급」으로 받아들인다는 것은 호감의 표시인가, 아니면 수십 년 치 툴체인 투자를 복제하지 않겠다는 결정인가?
도입
2026년 9월 10일, Rust Foundation 블로그에 「Rust는 Microsoft에서 Tier-1 언어다」라는 게스트 글이 올라왔다. 필자는 Victor Ciura, Microsoft DevDiv/CoreAI의 Rust 툴링 팀 수석 엔지니어다. 해커뉴스에서 701점, 댓글 459건을 기록했다.
첫 문단은 이 발표가 방향 전환이 아님을 분명히 한다. Rust가 Microsoft에 전략적으로 중요하다는 것은 이제 놀랄 일이 아니라는 것이다. Azure CTO Mark Russinovich가 네이티브 코드 전략을 밝힌 시점부터, Rust 프로젝트 지원에 수백만 달러가 투입된 이후의 몇 년까지 이어진 흐름이다.
새로운 것은 지위의 정의다. 글은 이렇게 적는다. 오늘날 Rust는 C++, C#, TypeScript와 나란히 Microsoft 사내 개발에서 가장 잘 지원되는 언어 중 하나다. 이 「Tier-1 언어」라는 엔지니어링 지위가 뜻하는 바는, 사내 팀들에게 로컬 개발에서 프로덕션까지 포장된 길을 제공한다는 것이다. 안전한 툴체인 빌드, 생산적인 개발자 도구, 품질 워크플로, 깊은 플랫폼 통합, 그리고 Microsoft 소프트웨어가 충족해야 하는 SDL 요구사항 준수가 그 내용이다.
해커뉴스의 한 이용자가 이 목록을 그대로 인용하며 요점을 짚었고(@gshubert17), 다른 이용자는 기존 Tier 1 언어 목록이 C++·C#·TypeScript였다는 점을 명시했다(@swiftcoder). 즉 이것은 새 언어를 하나 추가한 사건이 아니라, 세 개뿐이던 목록을 네 개로 만든 사건이다.
rustc_codegen_utc — 발표의 실제 내용
이 글이 단순한 홍보문과 다른 지점은 중간부터다. 발표의 실체는 지위 선언이 아니라 컴파일러 백엔드다.
글은 문제 설정부터 제시한다. Windows 플랫폼과 MSVC는 수십 년간 함께 진화해 왔고, C와 C++가 개발 플랫폼의 구성 요소였다. MSVC와 Windows가 혁신을 내놓을 때, 그 기능들이 C++와 Rust 양쪽에서 모두 사용 가능해야 하고 둘 사이의 상호운용이 매끄러워야 한다는 것이다. 하이브리드 Rust/C++ 프로젝트에서 이것은 대단히 중요하다.
그 목표를 향한 가장 중요한 투자로 제시된 것이 rustc_codegen_utc다. 이것은 rustc를 위한 대안 코드 생성 백엔드이며, rustc_codegen_llvm, rustc_codegen_gcc, rustc_codegen_cranelift와 같은 아키텍처 계열에 속한다. 동일한 백엔드 인터페이스에 꽂히고, rustc의 공유 컴파일러 기구를 MSVC 백엔드(UTC라 불린다)에 연결한다.
무엇을 얻으려는 것인가. 글이 나열한 목록은 구체적이다. Windows 툴링 생태계 및 ABI와의 높은 호환성, 바이너리 하드닝과 코드 보안 기능, Hotpatch를 포함한 링크 후 준수·분석·서비싱, 하이브리드 프로젝트를 위한 매끄러운 Rust/C++ 상호운용, 언어를 가로지르는 인라이닝·최적화·SPGO(표본 프로파일 기반 최적화), 디버깅과 크래시 덤프 분석, 프로파일링·진단·커버리지다.
핵심 논리는 그다음 문장에 있다. 이 역량과 워크플로들은 MSVC 기술 스택 위에서 여러 해에 걸쳐 만들어졌다. rustc를 그 백엔드에 연결하면, Windows 고유의 모든 역량을 병렬로 다시 구현하지 않고도 Rust가 같은 플랫폼 투자 위에 올라탈 수 있다. 결과는 Windows에서 Rust와 C++를 위한 통합 코드 생성 플랫폼이다.
배포 현황도 숫자로 제시된다. rustc_codegen_utc는 Microsoft DevDiv의 전담 팀이 투입된 주요 투자이며, 2026년 초부터 프로덕션 준비 상태였다. Rust 1.90부터 셀프 호스팅되고 있고, 오늘 기준 100개가 넘는 Microsoft 프로젝트 저장소가 이것으로 빌드한다. 이 롤아웃은 매주 더 많은 저장소가 채택하며 계속되고 있다.
왜 LLVM으로 충분하지 않았는가
여기서 자연스러운 질문이 나온다. Rust는 이미 LLVM 백엔드로 Windows 바이너리를 잘 만든다. 왜 백엔드를 하나 더 만드는가.
답은 코드 생성 품질이 아니라 그 주변의 생태계에 있다. 글이 든 대조가 이 점을 명확히 한다. 다른 플랫폼에서는 하이브리드 Rust/C++ 프로젝트가 C++ 코드를 Clang으로 빌드하면 두 언어가 이미 같은 LLVM 코드 생성 플랫폼에 도달할 수 있다. rustc_codegen_utc는 MSVC가 네이티브 플랫폼 컴파일러인 Windows 네이티브 C++ 프로젝트에 대해 같은 공유 백엔드 기회를 만든다는 것이다.
즉 이것은 Rust를 위한 기능이 아니라 경계면을 위한 기능이다. 한 저장소 안에 Rust와 C++가 함께 있고, 둘 다 같은 보안 검토와 서명, 핫패치, 크래시 덤프 분석 파이프라인을 통과해야 할 때, 두 언어가 서로 다른 백엔드에서 나오면 그 파이프라인은 두 벌이 된다. Hotpatch가 목록에 포함된 것이 특히 시사적이다. 재부팅 없이 실행 중인 시스템을 패치하는 기능은 링크 후 도구 체인과 심볼 정보에 강하게 의존하며, 이런 능력은 언어 런타임이 아니라 플랫폼 툴체인에 붙어 있다.
글 자체도 이것이 절반의 문제임을 인정한다. 코드 생성, 플랫폼 특유의 문제들, ABI, 예외 처리, 링크 후 도구는 상호운용 과제의 절반일 뿐이라는 것이다. 고충실도 언어 수준 상호운용, FFI 계약, 바인딩, 언어 의미론의 차이, 그리고 빌드 시스템이 사내와 업계 전반에서 작업 중인 문제들의 일부로 남아 있다고 밝힌다.
해커뉴스에서 나온 반응 중 이 발표의 성격을 가장 잘 짚은 것은 다음이다. 한 이용자는 이것이 매우 큰 소식이며, C와 C++ 언어 툴링에서 역할을 하는 모든 주요 OS 벤더가 이제 그린필드 개발을 위한 시스템 프로그래밍 언어 선택지를 다변화했다고 정리했다. 그리고 MSVC 통합에 관한 소문에 대해 드디어 공개적인 소식이 나왔다고 덧붙였다(@pjmlp). 「소문」이라는 단어가 중요하다. 이 작업은 2026년 초부터 프로덕션 준비 상태였다. 발표는 작업의 시작이 아니라 이미 100개 저장소에 배포된 뒤의 공개다.
상호운용에 대한 회의적 질문도 나왔지만, 같은 이용자가 Windows의 기존 답을 상기시켰다. COM과 WinRT가 VB 5가 VBX를 OCX로 대체한 이래 Windows에서 언어 간 상호운용을 하는 방식이었고, .NET Framework 설계의 핵심 기능이었으며, Windows 8에서 WinRT가 도입되며 개편되었다는 것이다. windows-rs 크레이트를 보라는 말도 덧붙였다(@pjmlp). 즉 Rust는 Windows에서 상호운용을 위해 새 메커니즘을 발명한 것이 아니라 기존 메커니즘에 편입되고 있다.
tier-1이 실무에서 뜻하는 것
이 발표를 어떻게 읽어야 할까. 두 가지 과대 해석을 먼저 걷어내는 편이 좋다.
첫째, 이것은 C++의 종료 선언이 아니다. 글 자체가 명시한다. Rust는 Microsoft에서 Tier-1 언어가 되었지만, 수십 년의 개발을 거친 C++가 여전히 지배적이라는 것이다. 통합 코드 생성 플랫폼을 쓰는 이유도 양쪽의 유지보수와 진화 비용을 최소화하기 위해서라고 밝힌다. 하이브리드 시스템이 앞으로 여러 해 동안 두 언어를 함께 쓸 것이라는 전제가 문서 전체에 깔려 있다.
둘째, 이것은 개발자 경험 전반의 완성이 아니다. 해커뉴스에서 Visual Studio 지원 이야기가 나오자, 한 이용자는 자신이 VS로 Rust 바이너리를 디버깅하고 프로파일링해 왔다고 밝히면서도 주요 고충을 구체적으로 짚었다. 표준 컨테이너와 열거형에 대한 디버거 시각화 지원이 빈약했다는 것이다. 그는 표준 컨테이너용 natvis 파일을 직접 작성해 일부를 고쳤고, 그 파일들이 몇 번 깨지기도 했으며, 자동으로 pdb에 포함되지 않아 별도 크레이트까지 만들었다고 적었다. 이후 Rust 자체에 #[debugger_visualizer] 속성이 안정화되어 같은 일을 할 수 있게 되었다는 경과도 덧붙였다(@MaulingMonkey). 다른 이용자는 레거시 C/C++ 코드베이스와 공유해야 하는 경우가 아니라면 VS가 Rust에 최적의 환경은 아닐 것이라고 봤다(@jeroenhd).
이 두 관점을 합치면 tier-1의 실제 의미가 드러난다. 그것은 「이 언어가 좋다」가 아니라 「이 언어로 쓴 코드가 우리 조직의 준수·보안·서비싱 절차를 통과할 수 있다」는 뜻이다. 사내 팀에게 중요한 것은 표현력이 아니라 포장된 길이다. 안전한 툴체인 빌드가 있고, 크래시 덤프를 분석할 수 있고, SDL 검토를 통과하고, 핫패치를 발행할 수 있는가. 이 질문들에 전부 예라고 답할 수 있을 때 비로소 대규모 조직에서 언어 선택지가 된다.
실무자에게 남는 시사점도 여기서 나온다. 조직에 새 언어를 도입할 때 논쟁은 대개 언어의 장점을 둘러싸고 벌어지지만, 실제로 도입을 막는 것은 거의 언제나 주변 도구다. 빌드 재현성, 의존성 공급망 검증, 디버그 심볼, 프로파일러 연동, 보안 스캐너 지원, 사고 대응 시의 덤프 분석 같은 것들이다. Microsoft가 백엔드를 하나 더 만들어서까지 해결하려 한 것이 정확히 이 목록이다. 수십 년 치 툴체인 투자를 두 벌로 유지하는 대신, 새 언어를 기존 투자 위로 끌어올리는 쪽을 택한 것이다.
또 하나 눈여겨볼 것은 이 발표가 어디에 실렸는가이다. Microsoft의 사내 블로그가 아니라 Rust Foundation의 게스트 포스트였고, 글은 마지막에 Rust 프로젝트 Zulip의 전용 토론 주제로 독자를 안내한다. 상호운용의 남은 절반에 대해서도 재단의 Interoperability Initiative를 가리킨다. 사내 백엔드를 만든 회사가 그 성과를 재단 채널로 발표하고 업스트림 토론으로 연결하는 구성은, 포크가 아니라 편입을 지향한다는 신호로 읽는 편이 자연스럽다. 물론 신호는 약속이 아니다. rustc_codegen_utc가 언제 어떤 형태로 업스트림 rustc에서 쓸 수 있게 되는지는 이 글에 적혀 있지 않다.
전망은 세 갈래다. 낙관적으로 보면, rustc_codegen_utc의 존재는 Windows에서 Rust를 채택하려는 다른 조직에도 같은 경로를 연다. 이미 100개가 넘는 사내 저장소가 쓰고 있고 매주 늘고 있다면, 외부 공개와 안정화는 시간 문제일 수 있다. 비관적으로 보면, 백엔드가 하나 더 생기는 것은 유지 부담이 하나 더 생기는 것이다. LLVM 백엔드에서만 재현되는 버그와 UTC 백엔드에서만 재현되는 버그가 갈라지면, 크레이트 생태계는 그 차이를 감당해야 한다. 현실적으로는 한동안 Microsoft 내부 사용 사례에 최적화된 상태가 이어지고, 외부 채택은 Windows 네이티브 통합이 절실한 영역부터 선택적으로 일어날 것이다.
결론
이 발표에서 인용할 만한 문장은 지위 선언이 아니라 근거다. 글은 rustc_codegen_utc의 차별점이 단순하다고 말한다. rustc를 Microsoft가 Windows를 중심으로 수십 년간 구축해 온 네이티브 백엔드와 플랫폼 생태계에 연결한다는 것이다.
「Rust가 tier-1이 되었다」는 헤드라인은 감정적으로 읽히기 쉽다. 그러나 이 글이 실제로 보여 준 것은 승리 선언이 아니라 비용 계산이다. Windows의 보안 기능, 서비싱 도구, 진단 인프라를 Rust용으로 다시 만들 것인가, 아니면 Rust를 그 인프라에 꽂을 것인가. Microsoft는 후자를 택했고, 그 선택이 「tier-1」이라는 단어의 내용을 이룬다.
당신의 조직이 다음 언어를 도입할 때 논쟁은 무엇을 두고 벌어지는가. 그 언어의 문법인가, 아니면 그 언어로 만든 바이너리가 사고 발생 시 분석 가능한지 여부인가. 두 번째 질문에 답할 수 없다면, 도입은 아직 시작되지 않은 것이다.
출처: