클로드 코드가 Node.js를 버렸습니다 — AI 코딩 도구 성능 경쟁이 '런타임'까지 내려간 이유

터미널에서 AI 코딩 도구를 켤 때 걸리는 1초. 예전엔 아무도 신경 쓰지 않던 시간이었습니다. 그런데 하루에 그 도구를 200번 호출한다면 이야기가 달라지는데요. 클로드 코드가 Node.js를 떠나 Bun 위에서 돌기 시작했다는 소식이, 단순한 기술 스택 교체 이상으로 읽히는 이유가 여기 있습니다.

먼저 솔직하게 말씀드리면, 이번 주제는 커뮤니티 데이터가 거의 없습니다. 최근 30일간 레딧에서 이 주제를 직접 다룬 스레드를 찾지 못했습니다. 그래서 이 글은 커뮤니티 반응 정리가 아니라, 이 변화가 무엇을 의미하는지에 대한 해석 중심으로 가겠습니다. 확인되지 않은 부분은 그렇다고 명시하겠습니다.

Bun이 뭔가요, 그리고 왜 “Rust로 다시 썼다"는 말이 틀렸나

먼저 흔한 오해부터 정리하겠습니다. Bun은 Zig로 작성된 JavaScript 런타임입니다. Rust가 아닙니다. 이 부분이 온라인에서 자주 잘못 알려져 있는데요.

혼동이 생기는 이유는 있습니다. 최근 JavaScript 생태계의 도구들이 대거 네이티브 언어로 다시 쓰이고 있기 때문입니다. Rust로 쓰인 것들이 실제로 많습니다. 번들러 Turbopack, 린터 Oxc, 그리고 TypeScript 컴파일러 자체를 Go로 다시 쓴 프로젝트까지. 이 흐름 속에서 Bun도 “그 Rust 도구들 중 하나"로 뭉뚱그려지곤 합니다.

정확히는 이렇습니다. Bun은 Zig 기반이고, JavaScript 엔진으로 V8이 아닌 JavaScriptCore를 씁니다. Safari가 쓰는 그 엔진입니다. Node.js가 쓰는 V8은 장시간 실행되는 서버에 최적화돼 있는 반면, JavaScriptCore는 상대적으로 시작이 빠릅니다. CLI 도구에는 이 차이가 결정적입니다.

즉 언어는 Zig, 엔진은 JavaScriptCore, 목표는 시작 속도. 이 세 가지가 핵심입니다.

CLI 도구에서 “시작 시간"이 왜 그렇게 중요한가

서버는 한 번 켜면 몇 주씩 돕니다. 부팅에 3초 걸려도 아무도 모릅니다. 그래서 Node.js는 오랫동안 시작 속도를 크게 신경 쓰지 않았습니다. 합리적인 선택이었습니다.

CLI는 정반대입니다. 명령어 하나 칠 때마다 프로세스가 새로 뜹니다. 켜지고, 일하고, 죽습니다. 그리고 AI 코딩 에이전트는 이 패턴을 극단으로 밀어붙입니다. 파일을 읽고, 명령을 실행하고, 서브 프로세스를 띄우고, 결과를 받아 다시 판단합니다. 한 번의 작업 요청이 수십 번의 프로세스 생성으로 번역됩니다.

여기서 100ms의 차이는 100ms로 끝나지 않습니다. 100번 곱해지면 10초입니다. 사용자 입장에서는 “왜 이렇게 굼뜨지"라는 인상으로 축적됩니다. 모델이 아무리 똑똑해도, 도구가 느리면 똑똑해 보이지 않습니다.

배포 문제: Node.js를 깔라고 요구하는 게 부담인 시대

성능만 이유는 아닙니다. 배포가 더 현실적인 문제일 수 있습니다.

Node.js 기반 CLI를 배포하려면 사용자에게 Node를 설치하라고 요구해야 합니다. 그것도 특정 버전 이상으로. npm 설치 과정에서 권한 문제, 버전 충돌, 전역 패키지 경로 문제가 줄줄이 따라옵니다. 개발자에게도 귀찮은 일인데, 클로드 코드처럼 개발자가 아닌 사용자까지 유입되는 도구라면 진입 장벽이 됩니다.

Bun은 단일 실행 파일로 컴파일할 수 있습니다. 런타임이 바이너리 안에 통째로 들어갑니다. 사용자는 아무것도 미리 설치할 필요가 없습니다. 다운로드하고 실행하면 끝입니다.

Go나 Rust로 만든 CLI 도구들이 오래 누려온 장점입니다. JavaScript 생태계는 이걸 갖지 못했었는데요. Bun이 그 격차를 메웁니다. 이미 방대한 TypeScript 코드베이스를 버리지 않으면서도 단일 바이너리 배포를 얻는 것. 이게 아마 가장 실용적인 동기일 겁니다.

AI 코딩 도구 경쟁이 런타임까지 내려온 이유

몇 년 전만 해도 AI 코딩 도구의 경쟁 축은 단순했습니다. 어느 모델이 더 정확한 코드를 쓰는가. 그게 전부였습니다.

지금은 다릅니다. 모델 성능이 상향 평준화되면서, 차이는 다른 데서 납니다. 컨텍스트를 얼마나 잘 관리하는가. 도구 호출이 얼마나 빠른가. 에이전트 루프가 얼마나 매끄럽게 도는가. 사용자가 체감하는 건 모델의 벤치마크 점수가 아니라 응답까지 걸린 시간입니다.

에이전트가 자율적으로 도는 시대라 더 그렇습니다. 사람이 한 줄 치고 결과를 기다리던 시절엔 오버헤드가 사람의 사고 시간에 묻혔습니다. 지금은 에이전트가 사람을 기다리지 않고 수십 스텝을 연달아 돕니다. 묻힐 곳이 없습니다. 스텝마다 붙는 지연이 그대로 누적돼 드러납니다.

그래서 최적화 대상이 아래로 내려갑니다. 프롬프트 최적화에서 시작해, 도구 설계로, 그리고 이제 실행 환경 자체로. 런타임 교체는 이 흐름의 자연스러운 종착점입니다. 더 내려갈 곳이 별로 없다는 뜻이기도 합니다.

그럼 Node.js는 끝났나요

아닙니다. 이건 CLI라는 특정 사용 사례의 이야기입니다.

Node.js는 여전히 압도적인 생태계를 가지고 있습니다. 검증된 프로덕션 사례, 방대한 패키지 호환성, 기업 환경에서의 신뢰. 서버 사이드에서 Node를 걷어낼 이유는 거의 없습니다. 그리고 Node 진영도 가만있지 않았습니다. 최근 버전들은 시작 속도 개선과 단일 실행 파일 지원을 계속 밀고 있습니다.

Bun의 약점도 분명합니다. 생태계가 젊습니다. Node의 모든 API를 완벽히 흉내 내지는 못합니다. 특정 네이티브 모듈에서 호환성 문제를 만날 수 있습니다. 프로덕션 안정성 트랙 레코드도 Node에 비할 바가 아닙니다.

그래서 클로드 코드의 선택은 “Bun이 Node보다 낫다"가 아니라 “이 특정 워크로드에는 Bun이 맞는다"에 가깝습니다. 잦은 프로세스 생성, 단일 바이너리 배포, 통제된 실행 환경. 조건이 딱 맞아떨어지는 케이스입니다.

마무리

런타임 교체는 사용자가 눈치채기 어려운 변화입니다. 화면에 새 기능이 뜨지 않습니다. 그저 조금 빨라질 뿐입니다. 하지만 회사가 이런 수준의 작업에 리소스를 쓴다는 건, 눈에 보이는 기능이 아니라 체감 속도에서 승부가 갈린다고 판단했다는 뜻입니다.

여러분이 쓰는 AI 코딩 도구에서 가장 불만스러운 부분은 무엇인가요. 모델이 틀린 코드를 쓰는 것인가요, 아니면 맞는 코드를 너무 느리게 쓰는 것인가요. 요즘 도구 회사들은 점점 두 번째 질문에 답하려는 것처럼 보입니다.