# Claude Code, Rust로 재작성된 Bun 사용 > Clean Markdown view of GeekNews topic #31603. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31603](https://news.hada.io/topic?id=31603) - GeekNews Markdown: [https://news.hada.io/topic/31603.md](https://news.hada.io/topic/31603.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-20T10:01:57+09:00 - Updated: 2026-07-20T10:01:57+09:00 - Original source: [simonwillison.net](https://simonwillison.net/2026/Jul/19/claude-code-in-bun-in-rust/) - Points: 2 - Comments: 1 ## Topic Body - Claude Code **v2.1.181**부터 Rust로 포팅된 Bun을 내장해 Linux 시작 속도가 10% 빨라졌지만, 대부분의 사용자는 변화를 거의 알아차리지 못함 - 실행 파일의 문자열을 조사하면 정식 태그가 아직 없는 **Bun v1.4.0**과 Rust 소스 파일 경로를 확인할 수 있음 - `~/.local/bin/claude`에서 `src/runtime/bake/dev_server/mod.rs` 등을 포함한 **563개 `.rs` 파일명**이 발견됨 - `BUN_OPTIONS`로 TypeScript 파일을 미리 불러와 `Bun.version`을 출력하는 방식으로도 내장 버전이 **1.4.0**임을 검증할 수 있음 - Rust 버전은 Bun canary로 배포됐으며, Claude Code를 통해 이미 **수백만 대의 기기**에서 프로덕션 실행 중임 --- ### Claude Code에 내장된 Rust 기반 Bun - [Rewriting Bun in Rust](https://bun.com/blog/bun-in-rust)에 따르면 6월 17일 출시된 Claude Code v2.1.181부터 **Rust 포트**를 사용함 - Linux 시작 속도가 10% 향상됨 - 그 밖의 차이는 사용자가 거의 알아차리지 못했으며, Jarred Sumner는 이를 “Boring is good”이라고 평가함 - Claude Code를 통해 이미 수백만 대의 기기에서 프로덕션 실행 중임 - Claude 실행 파일의 문자열에서 **내장 Bun 버전**을 찾을 수 있음 ```bash strings ~/.local/bin/claude | grep -m1 'Bun v1' ``` - macOS arm64 환경에서는 `Bun v1.4.0 (macOS arm64)`이 출력됨 - 당시 GitHub의 최신 정식 릴리스는 5월 12일의 [Bun v1.3.14](https://github.com/oven-sh/bun/releases/tag/bun-v1.3.14)였으므로, Claude Code에는 아직 정식 출시되지 않은 **v1.4.0 프리뷰**가 포함된 셈임 - Rust 버전은 [Bun canary](https://bun.com/docs/installation#canary-builds)로 공개됐으며, `bun upgrade --canary`로 설치할 수 있음 ### Rust 소스와 버전 검증 - 실행 파일에서 Rust 소스 경로를 추출하면 [563개 파일명](https://gist.github.com/simonw/c92fb0f67b114ac26e3b95a09ddccfdc)을 확인할 수 있음 ```bash strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs' ``` - 목록에는 다음 경로가 포함됨 ```text src/runtime/bake/dev_server/mod.rs src/runtime/bake/production.rs src/bundler/bundle_v2.rs ``` - Ajan Raj가 공유한 방법은 `BUN_OPTIONS`로 TypeScript 파일을 미리 불러와 Claude Code에 내장된 **`Bun.version`** 을 직접 출력함 ```bash cat > /tmp/bun-version.ts <<'EOF' console.log("embedded bun:", Bun.version); process.exit(0); EOF BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version ``` - 이 명령에서도 `1.4.0`이 출력됨 - [5월 17일 커밋](https://github.com/oven-sh/bun/commit/b18bf6d1d0a92238f240bfd125f0e3b3461b9243#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519)에서 `package.json` 버전이 1.4.0으로 변경된 뒤 그대로 유지됐으며, 아직 `canary` 외의 태그 릴리스에는 포함되지 않음 ## Comments ### Comment 62066 - Author: neo - Created: 2026-07-20T10:01:58+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48966569) - TUI가 왜 JavaScript를 거쳐 터미널용 React에서 실행돼야 하는지 이해하기 어려움. Anthropic이 TUI 개선을 위해 런타임까지 인수했다는 사실은 **엔지니어링 품질**을 더 의심하게 만듦. 재작성이 그렇게 쉽다면 Claude Code를 네이티브 언어로 옮기는 편이 훨씬 저렴했을 것임 - 이미 잘 작동하며 막대한 매출을 내는 사업이므로, “왜 이 기술인가?”는 기술보다 **사업적 선택**에 가까움. 초기에 선택한 기술이 제 역할을 하고 있으니 완벽한 아키텍처가 아니어도 바꿀 이유가 적음 재작성은 Bun조차 쉽지 않으며, API 계약과 테스트가 명확한 비UI 개발 도구가 기능이 모호하고 테스트가 부족한 UI 도구보다 재작성 후 신뢰하기 쉬움 - Claude, OpenCode, Ghostty를 함께 쓰면 대화형 터미널 프로그램이 **CPU와 배터리**를 심하게 소모하고, 밤새 절전 상태였던 노트북마저 뜨거워짐. curses/ncurses, Emacs, Vim, MS-DOS까지 40년 넘는 선례가 있는데도 웹 기술을 억지로 끼워 넣은 이유가 궁금함 - 유명한 Haskell 회사가 LLM을 활용한 반복 개발 속도 때문에 Python으로 전환했다는 글을 봤음. React 학습 데이터는 매우 많고 TypeScript 컴파일 시간도 Rust 등에 비해 짧음 사용자 대면 코드와 빠르게 변하는 UX 계층은 **빠른 반복 개발**이 가능한 동적 시스템으로, 인프라 계층은 Rust 같은 안전한 시스템 환경으로 이동할 가능성이 큼. Java/C#은 중간 지대지만, 앞으로 UX에는 TypeScript/Python이면 충분하고 시스템 작업에는 Rust가 더 적합해 입지가 줄어들 듯함 [https://avi.press/posts/2026-07-10-after-7-years-in-producti...]() - Anthropic이 AI로 Claude Code를 작성한다고 보면 JavaScript도 나쁘지 않은 선택임. 학습 데이터가 풍부하고, 다른 고성능 언어에서 AI를 혼란스럽게 할 수 있는 **다중 스레딩과 메모리 관리** 문제도 피할 수 있어 AI로 빠르게 소프트웨어를 만들기 좋음 - OpenAI는 약 1년 전 Codex를 **Rust로 재작성**하기로 결정했음. 재작성이 정말 쉽다면 Bun이 왜 필요하며, 모든 JavaScript 코드를 Rust로 옮기지 않는지도 물어야 함 [https://github.com/openai/codex/discussions/1174]() - Jarred의 원문을 보면 Zig에서는 수작업이던 부분이 Rust에서는 자동화되는 게 전환 이유로 분명해 보임. 인간과 에이전트 모두 비결정적이어서 Zig의 메모리 수명과 명시적 해제를 수동으로 추적하면 누락 버그가 길게 쌓이지만, Rust는 이 오류 부류를 제거해 엔지니어링 관리 측면에서 좋은 절충안이 됨 특히 **컴파일러 오류**는 코딩 에이전트에 필요한 결정적 안전장치이며, Claude에게 정확성을 시험할 방법과 “컴파일되게 만들라”는 목표를 주면 잘 작동함. 결정적 테스트로 확률적 출력을 확실한 보장으로 바꾸는 일반화된 접근은 [https://michael.roth.rocks/blog/verification-surface/]()에 정리했음 - Zig와 C는 수명이 서로 무관한 작은 할당을 많이 만들 때 적합하지 않음. 견고하게 쓰려면 아레나에 할당을 묶거나 고정 버퍼를 두는 식으로 **수명을 직접 관리**해야 함 그렇게 하면 Zig도 Rust 못지않게 견고할 수 있지만, LLM이 선호하는 관리형 언어식 할당 패턴을 원한다면 Zig는 맞지 않음 - 자동으로 처리하는 건 가비지 컬렉션 언어임. Rust에서도 메모리 수명을 생각하고 추적해야 하지만 **빌림 검사기**가 잘못된 처리를 막고 즉시 수정 피드백을 주므로 LLM이 쓰기 좋음. 기본 불변 참조 매개변수도 큰 성능 문제를 예방해 줌 - 현재 Bun에 `unsafe` Rust가 매우 많은데도 오류 부류를 자동으로 제거한다고 할 수 있는지 의문임: [https://news.ycombinator.com/item?id=48967630]() - 내 경험상 LLM은 메모리 버그를 꽤 쉽게 잡아냄. 이번 일은 Anthropic의 성공적인 **마케팅 행사**에 불과해 보임 - 이번 Rust 재작성은 전부 `unsafe`였던 것으로 기억하므로, 해당 문제를 자동으로 제거하지 못할 가능성이 큼 - Jarred나 Simon Willison의 평가와 무관하게 이번 일은 상당히 부정적으로 봄. Anthropic의 Bun 인수나 AI 재작성보다 더 큰 문제는 “내 브랜치일 뿐이고 과민반응한다”는 태도에서 시작해 **100만 줄 이상의 PR**을 한 달도 안 돼 병합한 미성숙한 진행 방식임 소통을 매우 잘못해 신뢰를 훼손하고 분열을 키웠으며, TypeScript 팀이 7.0에서 취한 접근을 따르는 게 그렇게 어려웠는지 의문임 - 결국 Claude Code 사용자 대부분은 알아차리지 못했거나 신경 쓰지 않고, 문제 삼는 쪽은 극소수라 실질적으로 중요하지 않을 수 있음 - TS7 역시 아키텍처를 진지하게 검토하기보다 다른 언어로 **한 줄씩 이식**한 대표적인 사례임 - Claude에 포함된 Bun v1.4.0은 아직 공개되지 않은 미리보기 버전으로 보임. 그렇다면 FOSS 프로젝트 **Bun이 조용히 다른 존재로 바뀐 것** 같아 조사만 TODO에 남겨두고 도입하지 않은 게 다행임 Bun의 거버넌스 문서를 찾을 수 없는데, 이제 사실상 Anthropic이 작업과 병합 여부를 모두 결정하는 구조인지 궁금함 - Rust로 바꾼다고 프로젝트가 죽는다는 결론은 이해하기 어려움 - PR은 공개돼 있어 누구나 빌드해 사용할 수 있으며, Anthropic 팀이 먼저 사용하기로 했을 뿐임 - 사실상 Jarred가 그 주에 받아들일 의향이 있느냐에 달린 구조로 알고 있음. Claude Code 변경 기록에는 거의 한 달 전부터 Bun 1.4.0 버전 변경이 적혀 있었지만, AI가 작성한 기록이라 대부분 읽지 않았어도 이상하지 않음 - 나도 Bun 도입을 조사했다가 **불안정성** 때문에 쓰지 않기로 했으며, 이번 일을 보면 올바른 판단이었던 듯함 - 왜 이렇게 Bun을 둘러 복잡하게 처리했는지 모르겠음. 에이전트가 Zig를 Rust로 옮길 수 있다면 Claude Code도 JavaScript에서 **Rust로 직접 재작성**해 런타임 의존성을 없애고 성능을 높일 수 있었을 것임 - Bun의 Rust 재작성은 Anthropic의 제품 전략과 사실상 아무 관련이 없다고 보면 혼란스러울 이유가 없음 - Claude Code만 놓고 보면 Rust 직접 재작성이 나았겠지만, 그러면 **Bun/oven.sh 인수 가치**가 크게 줄어듦 Bun은 Claude Code 외에도 외부와 Anthropic 내부 사용자가 있을 것이며, 코딩 모델이 선호할 수 있는 JavaScript 런타임과 도구 생태계를 확보하게 해줌. 향후 Anthropic이 이런 앱의 실행·관리에 특화된 클라우드까지 제공할 수 있고, 개발자 커뮤니티만 확보해도 Claude Code 하나를 Rust로 옮기는 것보다 훨씬 큰 영향력을 얻음 - Claude Code가 실제로 성능에 병목되는지도 의문임. JavaScript 런타임은 도구 생태계가 크고 **플러그인 개발**이 쉬워 충분히 적절함 - 추측과 감정을 빼고 보면 실제 실행 품질이 궁금함. 시작 속도뿐 아니라 RAM·CPU 사용량, 무한 루프나 교착 상태가 어떤지 확인해야 하며, 이전과 같거나 더 좋다면 상당히 인상적임 개발자로서 AI가 일자리를 가져갈 가능성은 싫지만, 누구나 간단한 요구만으로 원하는 소프트웨어를 만들 수 있다면 세상을 개선할 수 있음. Microsoft의 데이터 수집이 싫으면 운영체제를, Google의 도청이 싫으면 휴대전화를 AI에게 만들게 하는 **기술적 자급자족**이 가능해질 수 있으며, 그 앞에서는 개인의 고용 안정성이 사소해짐 그래서 기술을 오픈소스로 유지하는 것이 더욱 중요하며, 그렇지 않으면 기존 독점 구조를 반복하면서 일자리까지 잃게 됨 - 소프트웨어 개발에서 가장 어려운 부분은 **명확한 요구사항**을 얻는 일임. 완벽한 AGI가 있어도 사람들이 원하는 바를 명확히 표현하지 못하므로 모두가 정확히 원하는 소프트웨어를 만드는 세상은 오지 않을 것임 - 좋은 도구도 숙련된 장인이 써야 뛰어난 결과를 냄. 좋은 개발자는 적절한 질문을 하고, **안전장치**를 세우며, 필요한 곳에서 결과물을 직접 조정할 수 있음 - 현재 보조금을 받는 유료 장벽 뒤의 폐쇄형 모델을 두고 **기술 민주화**라 부르는 건 지나치게 순진함. Bun의 Rust 이식을 주로 마케팅 목적으로 활용한 전략이 제대로 먹힌 듯함 - 최근 Kitty 탭 안에서 Claude Code를 쓰다가 **세그멘테이션 오류**를 겪었고, 이후 탭 전체가 입력에 반응하지 않게 됨. 신고 링크가 나타나지만 클릭할 수 없고 인코딩돼 있어 어떤 정보를 보내는지도 확인할 수 없음 - Bun은 아이디어와 기능 면에서 다른 JavaScript 런타임보다 압도적으로 좋지만, 안정성은 형편없고 Node보다 세그멘테이션 오류가 **약 20배** 많았음. 이 수치는 New Relic 원격 측정 자료에 근거함 - 셸에 `Segmentation fault`가 출력되지 않았다면 세그멘테이션 오류가 아니라 멈춤일 가능성이 큼. 실제 오류라면 셸로 돌아온 뒤 화면에 보이지 않더라도 `reset`을 입력해 탭을 복구할 수 있음 - 업무용 MacBook에서 Ghostty와 Claude Code를 쓰지만 이 문제는 아직 겪지 않았음. 예전에는 폭주하는 메모리 누수로 시스템이 멈춰 재부팅해야 했는데 최근 몇 주 동안 사라졌으며, 단정하긴 이르지만 **Rust 이식이 메모리 누수**를 줄였을 가능성이 있음 - Ghostty에서 Claude의 대화형 질문 인터페이스를 쓸 때 비슷하게 멈추며, 스크롤 외에는 선택이나 취소를 포함한 어떤 입력도 받지 않음. 다만 Bun과 관련 있다고 보지는 않음 - Zig 버전에도 세그멘테이션 오류가 있었고, 이를 `unsafe` Rust로 한 줄씩 옮겼다면 원인이 된 코드 역시 그대로 남음. 관용적이고 **메모리 안전한 Rust**로 리팩터링하기 전에는 해결되지 않을 것임 - 이들은 문제를 잘 기술하고 토큰 예산이 무제한인, 크게 성공했지만 형편없는 엔지니어들처럼 보임. 토큰 비용을 직접 부담했다면 소프트웨어 효율을 높일 재정적 동기가 생겼을 것임 AI 데이터센터의 숨겨진 현실은 GPU 클러스터 효율이 **40~60%** 에 불과해도 자금으로 장비를 더 사서 메운다는 것임. 중국 경쟁사를 두려워하는 이유도 그들처럼 낭비할 여유가 없기 때문일 수 있음 - 이번 작업은 **트랜스파일**이며 품질도 좋지 않음. 생성된 코드는 관용적인 Rust와 거리가 멀어 흉물스럽다고 볼 만함 - 그래도 제대로 작동하는 듯함. 이번에는 기본적으로 한 줄씩 기계적으로 옮긴 초기 단계이며, 다음 단계에서 관용적인 Rust로 다듬을 예정이므로 이 재작성에 계속 반대 베팅하는 건 좋지 않아 보임 - 안정성·효율·비용을 생각하면 원래 구조를 최대한 보존하는 **소스 간 변환기**를 사용하거나 작성하는 편이 훨씬 합리적이었음 보통 재작성에서는 기존 코드베이스에서 얻은 교훈을 반영하지만, 에이전트로 파일마다 이식하면 그런 이점이 없음. 어느 쪽이든 비관용적인 번역이 되지만 LLM을 쓰면 비결정성과 막대한 비용까지 추가됨 - 흉물스럽다는 Rust 코드의 구체적인 예시가 필요함 - 차라리 LLVM IR로 직접 트랜스파일하지 않은 이유가 궁금함 - 프로젝트가 **메모리 안전성 목표**를 달성한다면 관용적인 코드인지가 꼭 중요한지는 의문임 - 최근 Claude Code가 예전보다 훨씬 불안정하며, **TUI 렌더링 오류**로 대화 기록이 깨지는 일이 자주 생김 - 2월부터 마지못해 Claude를 쓰고 있는데 처음부터 렌더링 결함, 키보드 입력 오류 등 지금껏 써본 TUI 중 최악이었음. 그런데도 최근 일주일 사이 더 나빠져 입력한 문자 일부가 보이지 않는 등 터미널 세션까지 망가뜨리기 시작함 백그라운드로 보낸 뒤 `reset`을 실행하고 다시 포그라운드로 가져오면 고쳐짐. Claude에게 진단을 요청하니 자신에게는 그런 버그가 없고 다른 프로그램 탓이라고 했지만 tmux와 Claude만 실행 중이었음. 최근 Rust 버전을 적용했다면 품질 저하 시점과 대략 맞아떨어짐 - Windows에서 창 크기를 바꿀 때마다 출력이 완전히 깨져 방금 한 답변을 다시 요청해야 함. 새 문제는 아니지만 최근 더 악화된 느낌 - AI 자체에 반대하지 않지만 Anthropic은 지나치게 나아가 **AI가 만든 저품질 코드**를 내놓고 있음. 실제 엔지니어가 계속 개입해 도구를 이끌어야 하는데, Anthropic은 코드의 100%를 AI에 맡기려는 듯함