AI 코딩 도구는 왜 Rust로 갈까: 코덱스와 클로드 코드의 선택

요즘 AI 코딩 도구에서 같은 이름이 자주 나옵니다. 오픈AI는 터미널용 코딩 에이전트 코덱스(Codex) CLI를 TypeScript에서 Rust로 다시 썼습니다. 깃허브는 2026년 9월 코파일럿 에이전트 런타임 83만 줄을 TypeScript에서 Rust로 옮겼다고 밝혔습니다. 앤트로픽의 클로드 코드(Claude Code)를 실행하는 런타임 Bun도 2026년 여름 Rust판으로 바뀌었습니다.

Rust는 2015년에 1.0이 나온 프로그래밍 언어입니다. C나 C++처럼 빠르게 돌면서도 메모리를 잘못 다뤄 생기는 오류를 컴파일 단계에서 막도록 설계됐습니다.

이 글은 2026년 10월 30일까지 나온 공식 발표와 연구 자료를 바탕으로 다섯 가지를 정리합니다. 날짜는 모두 한국 시간 기준입니다. AI 코딩 도구가 왜 Rust를 고르는지, Rust면 보안 취약점에서 자유로운지, LLM 서빙과 바이브 코딩에 Rust가 유리한지, Rust는 무엇을 바탕으로 만들어져 어디에 쓰였는지, 그리고 개발자와 주요 인물들은 어떻게 반응하는지입니다.

먼저 바로잡을 전제: 클로드 코드 본체는 아직 TypeScript

"코덱스와 클로드 코드가 Rust로 바뀌었다"는 말은 절반만 맞습니다. 두 도구가 Rust와 맺는 관계가 다릅니다.

코덱스와 클로드 코드의 Rust 관계

항목	코덱스 CLI오픈AI	클로드 코드앤트로픽
본체 코드	Rust로 다시 씀 저장소의 97.3%가 Rust	TypeScript와 React(Ink)
Rust가 들어간 곳	에이전트 전체	코드를 실행하는 런타임 Bun
전환 시점	2025년 5월 발표 8월 TypeScript 코드 삭제	2026년 6월 17일 배포된 v2.1.181부터 Rust판 Bun

클로드 코드를 만든 보리스 체르니(Boris Cherny)는 2025년 9월 개발 뉴스레터 The Pragmatic Engineer 기사에서 TypeScript와 React를 고른 이유를 "클로드 코드가 스스로를 만들 수 있는, 가르치지 않아도 되는 기술 스택을 원했다"고 설명했습니다. 모델이 이미 잘 다루는 언어를 골랐다는 뜻입니다.

대신 클로드 코드는 Bun이라는 자바스크립트 런타임 위에서 돌아갑니다. 런타임은 TypeScript로 쓴 코드를 실제로 실행해 주는 프로그램입니다. 앤트로픽은 2025년 12월 Bun을 인수했고, Bun 창업자 재러드 섬너(Jarred Sumner)는 2026년 5월 Zig로 쓰인 Bun을 Rust로 다시 썼습니다.

AI 코딩 도구가 Rust를 고르는 이유

코덱스: 설치, 샌드박스, 메모리, 확장성

오픈AI는 2025년 5월 31일 코덱스 깃허브 공지 "Codex CLI is Going Native"에서 Rust 재작성을 발표했습니다.

그림 1. 코덱스의 Rust 재작성 발표 공지입니다. 출처는 깃허브 openai/codex 토론 #1174(2025년 5월 31일)입니다.

공지는 코덱스의 핵심을 "모델을 반복해서 호출하는 에이전트 하네스"라고 설명하고, 이 하네스를 가장 효율적으로 만들려고 Rust를 골랐다고 밝혔습니다. 네 가지 이유를 풀면 다음과 같습니다.

1. 의존성 없는 설치: 당시 코덱스를 쓰려면 Node.js 22 이상을 먼저 깔아야 했습니다. Rust로 만들면 실행 파일 하나만 받으면 됩니다.
2. 보안 기능 연결: AI가 명령을 실행할 때 파일과 네트워크 접근을 막는 샌드박스는 운영체제 기능을 직접 불러야 합니다. 코덱스는 macOS에서는 Seatbelt, 리눅스에서는 Landlock을 씁니다. 리눅스 샌드박스는 Rust 연결 라이브러리가 이미 있어 처음부터 Rust로 만들어 배포하고 있었습니다.
3. 메모리: Rust에는 가비지 컬렉터가 없어 메모리를 덜 씁니다. 가비지 컬렉터는 프로그램이 쓰고 버린 메모리를 런타임이 주기적으로 찾아 치우는 장치입니다.
4. 확장 프로토콜: 다른 언어로 코덱스 기능을 넓힐 수 있게 통신 규약을 만들려 했습니다.

이후 2025년 8월 저장소에서 TypeScript 코드를 지웠고, 2026년 10월 30일 깃허브 언어 통계로 Rust 비중은 97.3%입니다.

그림 2. 코덱스 저장소의 언어 비중입니다. 출처는 깃허브 openai/codex(2026년 10월 30일 조회)입니다.

Bun: 메모리 버그를 컴파일 오류로 바꾸려고

재러드 섬너는 2026년 7월 8일 블로그 글 "Rewriting Bun in Rust"에 이유와 과정을 적었습니다.

그림 3. Bun의 Rust 재작성 글 첫 화면입니다. 출처는 Bun 블로그(2026년 7월 8일)입니다.

섬너는 Bun 버그의 큰 비중이 해제한 메모리를 다시 쓰는 오류(use-after-free), 두 번 해제하는 오류, 오류 처리 경로에서 해제를 잊는 오류였다고 썼습니다. 그리고 "안전한 Rust에서는 이런 실수가 컴파일 오류로 잡힌다"고 설명했습니다. 실행하다 터지던 버그를 코드를 만드는 단계에서 막겠다는 선택입니다.

옮긴 방식도 화제가 됐습니다. 섬너는 주석을 뺀 Zig 코드 535,496줄을 클로드 코드에서 동적 작업 흐름 약 50개를 11일 동안 계속 돌려 Rust로 옮겼다고 밝혔습니다. 결과로 기존 버전(v1.3.14)에서 재현되던 버그 128건이 고쳐졌고 성능은 2~5% 빨라졌습니다. 클로드 코드에는 6월 17일 배포한 v2.1.181부터 Rust판 Bun이 들어갔는데, 섬너는 "리눅스에서 시작이 10% 빨라졌고, 그 밖에는 거의 아무도 눈치채지 못했다. 지루한 게 좋은 것"이라고 적었습니다.

깃허브 코파일럿: 83만 줄을 에이전트로 옮기다

깃허브는 2026년 9월 16일 코파일럿 에이전트 런타임을 TypeScript에서 Rust로 옮긴 과정을 공개했습니다. 결과물은 제품 코드 832,378줄(테스트 코드 제외)이고, 14.5주 동안 PR 128개로 나눠 에이전트가 대부분을 작성했습니다. 다만 깃허브는 같은 글에서 "모든 큰 TypeScript 프로그램이 Rust가 돼야 한다는 주장이 결코 아니다"라고 선을 그었습니다.

반대로 Rust를 고르지 않은 경우

모두가 Rust로 가지는 않습니다. 마이크로소프트는 2025년 3월 TypeScript 컴파일러를 Go로 옮기기로 하면서 이유를 밝혔습니다. 새로 짓는 것이 아니라 기존 코드를 그대로 옮기는 작업이라, 기존 코드 구조와 비슷하게 쓸 수 있는 Go가 맞았다는 설명입니다. 가비지 컬렉터의 단점도 자기들 코드에서는 크게 문제 되지 않는다고 했습니다. 구글의 제미나이 CLI도 2026년 10월 기준 저장소의 97.2%가 TypeScript입니다.

정리하면 AI 코딩 도구가 Rust를 고르는 이유는 네 가지로 모입니다. 사용자 컴퓨터에서 몇 시간씩 도는 프로그램이라 메모리와 안정성이 중요하고, 실행 파일 하나로 배포할 수 있고, 샌드박스 같은 운영체제 기능을 직접 다룰 수 있으며, AI가 대량으로 코드를 쓸 때 컴파일러가 실수를 잡아 줍니다.

Rust면 보안 취약점에서 자유로울까요?

메모리 오류는 크게 줄어든다

큰 소프트웨어의 보안 취약점 중 상당수는 메모리를 잘못 다뤄서 생깁니다. 마이크로소프트는 2019년 해마다 CVE를 붙이는 자사 취약점의 약 70%가 메모리 안전성 문제라고 밝혔고, 크로미움 프로젝트도 심각도 높은 보안 버그의 약 70%가 메모리 문제라고 집계했습니다. CVE는 공개된 보안 취약점마다 붙는 고유 번호입니다.

구글 안드로이드는 2019년 무렵부터 새 코드를 Rust 같은 메모리 안전 언어로 쓰기 시작했습니다. 그 뒤 전체 취약점 중 메모리 안전성 취약점의 비중이 꾸준히 내려갔습니다.

그림 4. 안드로이드의 새 메모리 비안전 코드 비율과 메모리 안전성 취약점 비율입니다. 출처는 구글 보안 블로그(2024년 9월 25일)입니다.

안드로이드가 공개한 Rust 도입 효과

• 76→24%메모리 안전성 취약점 비중2019년에서 2024년, 전체 취약점 중
• 20% 미만2025년 같은 비중처음으로 20% 아래
• 1,000배메모리 취약점 밀도 차이100만 줄당 Rust 0.2건, C와 C++ 약 1,000건

구글은 2025년 11월 글에서 중간 이상 규모의 Rust 변경은 되돌리는 비율이 C++의 4분의 1 수준이고 코드 리뷰 시간도 25% 적게 든다고 밝혔습니다. 안전해지는 대신 개발이 느려진다는 통념과 반대 결과입니다. 미국 백악관 국가사이버국장실(ONCD)도 2024년 2월 보고서에서 메모리 안전 언어로 옮기라고 권고했습니다.

그래도 취약점이 사라지지는 않는다

Rust가 막는 것은 메모리 오류이고, 보안 문제 전체가 아닙니다. 최근 2년 사이에도 Rust 쪽에서 나온 사례가 여럿입니다.

Rust와 보안을 둘러싼 오해

• Rust로 쓰면 메모리 버그가 절대 생기지 않는다

  Rust도 unsafe 블록 안에서는 컴파일러 검사를 일부 끕니다. 2025년 12월 리눅스 커널 Rust 코드의 첫 CVE(CVE-2025-68260)가 안드로이드 바인더 드라이버의 unsafe 블록에서 나와 시스템이 멈출 수 있었습니다.

• 표준 라이브러리는 믿어도 된다

  2024년 4월 Rust 표준 라이브러리에서 윈도우 배치 파일을 실행할 때 임의 명령이 실행될 수 있는 치명적 취약점(CVE-2024-24576)이 나와 1.77.2에서 고쳤습니다.

• 컴파일만 통과하면 안전한 프로그램이다

  2025년 11월 18일 클라우드플레어 장애는 설정 파일 크기가 한도를 넘자 Rust 코드의 unwrap() 호출이 프로그램을 멈추면서 커졌습니다. 입력 검증과 오류 처리는 언어가 대신해 주지 않습니다.

• Rust 생태계의 패키지는 안전하다

  2025년 9월 Rust 패키지 저장소 crates.io에서 이름을 흉내 낸 악성 패키지 두 개가 발견돼 삭제됐습니다. 로그 파일에서 이더리움과 솔라나 개인키를 찾아 외부 서버로 보내는 코드였습니다.

그래서 "Rust면 보안 취약점에서 자유롭다"가 아니라 "가장 흔한 취약점 범주를 컴파일 단계에서 크게 줄인다"가 정확한 표현입니다. AI가 쓴 Rust 코드도 마찬가지입니다. Bun 블로그도 Rust판에 unsafe 키워드가 약 1만 3,000곳 들어 있다고 밝혔고, 해커 뉴스 토론에서도 이 점이 지적됐습니다. unsafe가 많으면 Rust의 안전 보장이 그만큼 줄어듭니다.

AGI는 Python으로 만들어질까요, Rust로 만들어질까요?

2023년 4월, 보얀 퉁구즈(Bojan Tunguz)가 X에 "AGI는 Python으로 만들어질 것이다"라고 썼습니다. AGI는 사람 수준의 범용 인공지능을 말합니다. 일론 머스크는 이 글에 한 단어로 답했습니다.

그림 5. "AGI는 Python으로 만들어진다"는 글에 머스크가 "Rust"라고 답했습니다. 출처는 X @elonmusk(2023년 4월 22일)입니다.

같은 스레드에서 AGI 연구자 벤 괴르첼(Ben Goertzel)은 머스크 편을 들었습니다. 자신이 이끄는 AGI 프레임워크 OpenCog Hyperon의 핵심이 Rust로 작성됐고, Python은 군데군데 연결용으로만 쓴다는 내용입니다.

그림 6. 벤 괴르첼의 답글입니다. 출처는 X @bengoertzel(2023년 4월 24일)입니다.

머스크의 한 단어 뒤에는 실제 선택이 있었습니다. xAI는 2023년 11월 첫 모델 Grok을 공개하면서 "Kubernetes, Rust, JAX로 자체 학습과 추론 스택을 만들었다"고 밝혔습니다. 수만 개 GPU를 몇 달씩 묶어 돌리면 GPU 고장이 일상이 되는데, 이를 바로 감지하고 자동 처리하는 자체 분산 시스템을 만들었고, 이런 인프라를 만드는 데 Rust가 이상적이었다는 설명입니다.

그림 7. xAI가 Grok 기술 스택을 설명한 부분입니다. 출처는 xAI 공식 사이트의 Announcing Grok(2023년 11월)입니다.

xAI는 같은 글에서 "Rust는 분산 시스템에서 흔히 나오는 버그 대부분을 막아 준다"며, 팀이 작은 만큼 인프라가 안정적이어야 한다고 썼습니다. 머스크는 2026년 2월 X 답글에서 한 걸음 더 나아갔습니다.

그림 8. 머스크는 "Rust는 꽤 훌륭하다. xAI 코드는 대부분 Rust이고, X는 옛 트위터의 스칼라 코드를 빠르게 Rust로 바꾸고 있다"고 썼습니다. 출처는 X @elonmusk(2026년 2월 20일)입니다.

다만 이 논쟁에는 단서가 붙습니다. 모델을 학습시키는 코드는 지금도 대부분 Python입니다. xAI가 꼽은 JAX도 Python에서 쓰는 머신러닝 라이브러리입니다. 실제 계산은 GPU용 CUDA와 C++가 맡고, Python은 그 계산을 지휘합니다. Rust가 자리 잡은 곳은 그 주변입니다. 수만 개 GPU를 관리하는 인프라, 데이터 파이프라인, 그리고 이제는 AI 에이전트 프로그램 자체입니다.

AI 연구자 안드레이 카파시는 2026년 2월 다른 방향에서 이 질문을 다뤘습니다.

그림 9. 카파시는 LLM이 특히 번역에 강해 C를 Rust로 옮기는 흐름이 커진다고 보면서도, Rust조차 LLM에게 최적인 언어와는 거리가 멀다고 했습니다. 출처는 X @karpathy(2026년 2월 17일)입니다.

카파시의 말을 따르면 지금의 Rust 전환은 "AI가 쓰기에 가장 좋은 언어를 찾았다"기보다 "AI 덕분에 옮기는 비용이 크게 떨어졌다"에 가깝습니다. 앤트로픽도 2026년 9월 Opus 5.5를 발표하면서, 웹 트래픽을 여러 서버에 나누는 로드 밸런서 HAProxy를 C에서 Rust로 옮기는 내부 시험을 9.5시간 만에 마쳤다고 소개했습니다.

LLM 서빙에 Rust를 쓰면 유리할까요?

LLM 서빙은 학습을 마친 모델을 서버에 올려 사용자 요청에 답하게 하는 일입니다. 여기서 Rust가 맡는 부분과 맡지 않는 부분이 뚜렷이 나뉩니다.

토크나이저는 문장을 모델이 읽는 토큰 단위로 자르는 프로그램입니다. 오픈AI의 tiktoken은 핵심부가 Rust로 작성됐고, 비슷한 오픈소스 토크나이저보다 3~6배 빠르다고 밝힙니다. 카파시도 2025년 10월 교육용 프로젝트 nanochat을 만들면서 Python 토크나이저가 너무 느리다며 Rust로 rustbpe를 새로 만들었습니다.

반면 Rust 라우터와 Python 모델 서버로 이뤄진 허깅페이스 TGI는 2025년 12월 유지보수 모드로 들어갔고(저장소는 2026년 3월 보관 처리), 허깅페이스는 앞으로 vLLM과 SGLang을 쓰라고 권했습니다. 그런데 그 vLLM과 SGLang이 요청을 나누는 앞단 라우터는 Rust로 새로 만들었습니다.

결론은 이렇습니다. 모델 계산은 GPU가 하므로 서버를 Rust로 쓴다고 답이 빨라지지는 않습니다. Rust가 효과를 내는 곳은 GPU 밖에서 CPU가 하는 일입니다. 동시에 들어오는 요청이 많을 때 토큰화, 요청 분배, 도구 호출 결과 해석이 늦으면 GPU가 놀게 되는데, 이런 CPU 작업을 Rust로 옮기면 GPU를 더 꽉 채워 쓸 수 있습니다. 개인이나 작은 팀이 모델 하나를 올려 쓰는 정도라면 서빙 코드를 새로 짤 필요 없이 Ollama나 vLLM 같은 기존 엔진을 그대로 쓰는 편이 맞습니다.

바이브 코딩에 Rust를 쓰면 유리할까요?

바이브 코딩은 코드를 직접 쓰지 않고 AI에게 말로 시켜 프로그램을 만드는 방식입니다. Rust 쪽 주장의 핵심은 "컴파일러가 AI의 검수자가 된다"는 것입니다. Bun 재작성 글에도 "컴파일러 오류는 스타일 가이드보다 나은 피드백 순환"이라는 문장이 있습니다.

연구 결과도 이 주장을 일부 뒷받침합니다. C 코드를 Rust로 옮기는 2025년 연구 SafeTrans에서는 컴파일 오류를 모델에게 되돌려 주며 반복하자 GPT-4o의 번역 성공률이 54%에서 80%로 올랐습니다. 마이크로소프트 연구진의 RustAssistant는 실제 저장소의 Rust 컴파일 오류를 LLM과 컴파일러를 번갈아 돌려 최대 약 74% 고쳤습니다.

하지만 첫 시도의 성공률은 Python이 훨씬 높습니다. 2025년 다국어 코딩 에이전트 벤치마크 Multi-SWE-bench 논문에서 같은 모델(Claude 3.7 Sonnet)과 같은 에이전트로 실제 깃허브 이슈를 풀게 하자, 비교용으로 함께 실린 Python 문항은 52.2%, Rust는 15.9%였습니다. Rust는 Go와 TypeScript보다는 높았지만 자바(21.9%)보다 낮았고, Python과는 차이가 컸습니다. 또 RustEvo² 연구에서는 모델 학습 이후에 바뀐 Rust API를 다루면 성공률이 56.1%에서 32.5%로 떨어졌습니다.

반대 의견도 뚜렷합니다. Flask를 만든 아르민 로나허(Armin Ronacher)는 2025년 6월 에이전트 코딩 경험을 정리하며 새 백엔드 프로젝트에는 Go를 강하게 권한다고 썼습니다. Rust에서는 에이전트가 cargo test 명령 형식을 헷갈려 실패하기도 한다는 점도 이유로 들었습니다. Rust 컴파일러 성능 설문(2025년)에서는 Rust를 더 쓰지 않는다고 답한 사람의 약 45%가 긴 컴파일 시간을 이유 중 하나로 꼽았습니다. 에이전트는 고치고 컴파일하기를 수십 번 반복하므로 이 대기 시간이 그대로 쌓입니다.

코드량도 다릅니다. 루비 온 레일스를 만든 DHH는 2026년 10월 같은 채팅 앱을 에이전트로 여러 언어로 만들어 비교했습니다.

그림 10. DHH는 Rust판 코드가 레일스판의 10배가 넘지만 AI가 코드를 쓰는 지금은 계산이 달라졌다고 했습니다. 인용된 성능 비교에는 언어별 구현 조건이 다르다는 X 커뮤니티 노트가 붙어 있습니다. 출처는 X @dhh(2026년 10월 5일)입니다.

DHH의 말은 Rust의 단점이던 긴 코드와 학습 부담을 AI가 덜어 준다는 뜻입니다. 다만 사람이 그 코드를 읽고 책임져야 한다면 10배 긴 코드는 여전히 부담입니다. 상황별로 정리하면 다음과 같습니다.

바이브 코딩에서 Rust를 고를 때와 피할 때

상황	Rust가 유리	다른 언어가 유리
만드는 것	CLI 도구, 에이전트, 프록시, 오래 도는 서버	웹 화면, 사내 도구, 데이터 분석 스크립트
수명	몇 년 유지할 핵심 부품	몇 주 쓰고 바꿀 시제품
검증 장치	테스트가 탄탄해 컴파일러와 함께 검수 가능	테스트가 거의 없음
팀 역량	Rust 코드를 읽고 고칠 사람이 있음	AI가 쓴 코드를 아무도 못 읽음

Rust는 무엇을 바탕으로 만들어졌나

Rust는 2006년 모질라 개발자 그레이던 호어(Graydon Hoare)의 개인 프로젝트로 시작했습니다. MIT 테크놀로지 리뷰에 따르면, 호어는 밴쿠버 아파트의 엘리베이터 소프트웨어가 또 멈춰 21층까지 계단을 오르다 "컴퓨터를 다룬다는 사람들이 멈추지 않는 엘리베이터 하나 못 만든다니 말이 안 된다"며 새 언어를 구상했습니다. 이름은 생존에 맞게 지나칠 만큼 튼튼하게 진화한 녹병균에서 따왔다고 합니다.

첫 컴파일러는 함수형 언어 OCaml로 작성됐고, 2011년 Rust로 다시 쓴 컴파일러가 처음으로 자기 자신을 컴파일했습니다. 모질라가 2009년부터 공식 후원했고, 1.0은 2015년 5월 15일 나왔습니다. 2021년 2월에는 AWS, 화웨이, 구글, 마이크로소프트, 모질라가 창립 회원으로 참여한 Rust 재단이 생겼습니다.

Rust 공식 레퍼런스는 영향받은 언어 목록을 "Rust는 그리 독창적인 언어가 아니다"라는 문장으로 시작합니다. 여러 언어에서 검증된 아이디어를 모았다는 뜻입니다.

여기서 Rust가 새로 만든 핵심이 소유권(ownership)과 빌림 검사기(borrow checker)입니다. 값마다 주인이 하나 있고, 주인이 사라지면 메모리가 자동으로 해제됩니다. 다른 코드는 값을 빌려 쓰는데, 읽기만 하는 참조 여러 개나 수정할 수 있는 참조 하나만 동시에 허용됩니다. 컴파일러가 이 규칙을 검사해, 가비지 컬렉터 없이도 해제한 메모리를 쓰거나 두 스레드가 같은 값을 동시에 고치는 오류를 막습니다.

Rust는 어디에 쓰였나

Rust는 AI 도구보다 훨씬 앞서 인프라 곳곳에 들어갔습니다.

마이크로소프트의 갈렌 헌트(Galen Hunt)는 2025년 12월 채용 공고에 "2030년까지 마이크로소프트에서 C와 C++ 코드를 한 줄도 남기지 않는 것이 목표"라고 썼다가 화제가 됐습니다. 이후 그는 윈도우를 AI로 Rust로 다시 쓰는 것이 아니며 자기 팀의 연구 프로젝트라고 덧붙였습니다. 회사 전체 전략이 아니라 한 연구 조직의 목표라는 점을 함께 알아야 합니다.

개발자와 주요 인물의 반응

개발자들의 평가는 높습니다. 스택 오버플로 2025년 개발자 설문에서 Rust는 72%로 "가장 높이 평가받는 언어(Most Admired)" 1위였습니다. Rust로 만든 파이썬 패키지 관리자 uv도 설문에 새로 들어간 기술 부문에서 74%로 가장 높이 평가받았습니다.

코덱스 Rust 전환에는 반응이 나뉘었습니다. 2025년 6월 해커 뉴스 토론에서 보안 연구자 토머스 프태첵(tptacek)은 "Node.js를 깔기 번거로운 곳에도 CLI를 설치하려는 것"이라고 이유를 짚었습니다. 반면 "근거가 너무 빈약하다, 그냥 Rust로 다시 쓰고 싶어서 쓰는 것"이라는 냉소와 "누가 10만 줄 넘는 Rust 코드를 넘겨줄 때까지 기다려 보라"는 댓글도 올라왔습니다. 같은 토론에는 "이제 클로드 코드가 Rust로 다시 쓰이길 기다린다"는 댓글이 있었는데, 1년 뒤 클로드 코드를 돌리는 Bun이 Rust로 바뀌었습니다.

Bun의 AI 재작성에는 기대와 우려가 함께 나왔습니다. 2026년 7월 해커 뉴스 토론에서는 "탄탄한 테스트가 있으면 LLM이 이런 대규모 이전을 해낸다"는 평가와 함께, 생성된 코드가 읽기 어렵다는 비판, unsafe가 1만 3,000곳이라는 지적이 함께 나왔습니다.

업계 인사들의 발언도 이어졌습니다.

• 리누스 토발즈(리눅스 창시자), 2025년 2월: 커널 메일링 리스트에서 Rust 도입에 반대하는 관리자에게 "Rust를 좋아할 필요는 없다"면서도, 자기 코드를 누가 쓸지 관리자가 통제할 수 있다고 생각한다면 틀렸다고 못 박았습니다.
• 그렉 크로하트먼(리눅스 안정 버전 관리자), 2025년 2월: "우리가 겪는 버그 대부분(심각도가 아니라 개수로)은 Rust에서는 아예 사라지는 C의 사소한 경계 사례 때문"이라고 썼습니다.
• 비야네 스트롭스트룹(C++ 창시자), 2025년 2월: C++ 표준 위원회에 보낸 메모(3월 P3651R0 문서로 공개)에서 C++를 겨냥한 공격이 전례 없다며 긴급 대응을 촉구하고, 언어를 바꾸는 대신 C++ 안에서 안전 규칙을 강제하는 프로파일(Profiles)을 대안으로 내놓았습니다.
• 브렛 테일러(오픈AI 이사회 의장), 2025년 2월: 팟캐스트 Latent Space에서 "이 Rust 프로그램이 메모리 안전하냐고 물으면 읽을 필요 없이 컴파일만 해 보면 된다"고 말했습니다. AI가 쓴 코드를 사람이 다 읽을 수 없을 때 컴파일러가 증명해 주는 부분이 있다는 뜻입니다.

정리: Rust를 골라야 하는 경우

AI 코딩 도구들이 Rust로 가는 이유는 유행보다 조건에 가깝습니다. 사용자 컴퓨터에서 몇 시간씩 도는 에이전트는 메모리와 안정성이 중요하고, 실행 파일 하나로 배포해야 하며, 샌드박스 같은 운영체제 기능을 직접 다뤄야 합니다. 여기에 AI가 코드를 대량으로 옮겨 쓰는 비용이 크게 떨어지면서, Rust의 약점이던 학습 부담과 긴 코드가 덜 문제가 됐습니다.

그렇다고 모든 프로젝트를 Rust로 시작할 필요는 없습니다. 판단할 때는 세 가지를 확인합니다.

1. 오래 유지할 핵심 부품인지: CLI 도구, 에이전트, 프록시, 오래 도는 서버라면 Rust의 장점이 크고, 몇 주 쓰고 바꿀 화면이나 스크립트라면 반복이 빠른 언어가 낫습니다.
2. 테스트가 있는지: Bun과 코파일럿 모두 탄탄한 테스트 위에서 옮겼습니다. 컴파일러는 메모리 오류를 잡지만 기능이 맞는지는 테스트가 확인합니다.
3. 누가 읽고 책임지는지: AI가 쓴 Rust 코드를 읽고 고칠 사람이 없다면, 컴파일이 통과해도 논리 오류와 unsafe 블록의 위험은 그대로 남습니다.

LLM 서빙이라면 모델 계산은 GPU의 몫이니 서버 전체를 Rust로 쓰기보다, 이미 Rust 부품을 쓰는 vLLM이나 SGLang 같은 엔진을 고르고 요청이 많아질 때 앞단 병목을 보는 순서가 맞습니다.

참고 자료

• Codex CLI is Going Native(오픈AI 깃허브 토론 #1174)
• Rewriting Bun in Rust(Bun 블로그)
• Migrating the GitHub Copilot runtime to Rust using Copilot(깃허브 블로그)
• Why Go?(TypeScript 컴파일러 Go 이전 설명)
• Announcing Grok(xAI)
• Eliminating Memory Safety Vulnerabilities at the Source(구글 보안 블로그)
• Rust in Android: move fast and fix things(구글)
• Chromium Memory Safety
• Back to the Building Blocks(백악관 ONCD 보고서)
• CVE-2024-24576 보안 공지(Rust 블로그)
• crates.io 악성 패키지 공지(Rust 블로그)
• 18 November 2025 outage(클라우드플레어)
• Rust 실험 종료 패치(리눅스 커널)
• Multi-SWE-bench 논문
• SafeTrans 논문
• RustEvo² 논문
• Agentic Coding Recommendations(아르민 로나허)
• Rust 컴파일러 성능 설문 2025 결과
• Rust의 영향을 준 언어(Rust 레퍼런스)
• Rust 1.0 발표
• How Rust went from a side project to the world's most-loved programming language(MIT 테크놀로지 리뷰)
• 스택 오버플로 2025 개발자 설문 기술 부문
• SGLang 모델 게이트웨이
• vLLM Router 발표
• 허깅페이스 TGI 저장소