Claude Code가 Bun과 Rust를 통해 보여주는 행보는 특정 런타임(Runtime)이 보편적으로 더 우수하다는 것을 증명하기 때문에 흥미로운 것이 아닙니다. 이것이 흥미로운 이유는, 에이전트형 개발 도구(Agentic developer tools)가 단순한 CLI(Command Line Interface)를 넘어 로컬 운영자(Local operators)처럼 동작하기 시작할 때, 실제로 무엇을 최적화하는지를 드러내기 때문입니다.

코딩 에이전트(Coding agent)는 기묘한 제품입니다. 대화하는 느낌을 줄 수 있을 만큼 충분히 빠르게 부팅되어야 하고, 멈춤 없이 출력을 스트리밍(Stream)해야 하며, 실제 개발 도구들을 생성(Spawn)하고, 망가진 로컬 환경에서도 생존해야 하며, 플랫폼 간에 깔끔하게 패키징되어야 하고, 사용자가 "파일 3개를 편집하고 테스트를 실행한 뒤에 멈췄어요"라고 말할 때 디버깅(Debug)이 가능해야 합니다. 이는 웹 API를 구축하는 것과는 매우 다른 런타임 문제입니다.

따라서 올바른 교훈은 "모두가 자신의 도구를 Bun으로 다시 작성해야 한다"가 아닙니다. 올바른 교훈은 에이전트 런타임은 단순한 벤치마크 처리량(Benchmark throughput)보다는 마찰(Friction), 제어(Control), 그리고 실패 동작(Failure behavior)에 의해 선택된다는 것입니다. Claude Code의 방향성은 이러한 현실을 더 쉽게 볼 수 있게 해줄 뿐입니다.

Anthropic의 공개 자료는 이제 그 연결 고리를 상당히 명시적으로 보여주고 있습니다. Bun은 2025년 12월, Anthropic이 Claude Code 및 향후 AI 코딩 도구의 인프라로서 Bun에 베팅하고 있다고 발표했으며, Anthropic은 별도로 Claude Code의 샌드박싱(Sandboxing) 모델과 에이전트 SDK 방향성에 대해 기술했습니다. 이것들은 고립된 제품 노트가 아닙니다. 이들은 함께 더 넓은 아키텍처 편향(Architecture bias)을 가리킵니다. 즉, 에이전트 도구는 느슨한 런타임 표면이 아닌, 더 긴밀한(Tighter) 런타임 표면을 원한다는 것입니다. Anthropic의 인수 노트, Bun의 발표, 그리고 Anthropic의 샌드박싱 기술 문서를 참조하십시오.

에이전트 도구는 잘못된 런타임을 빠르게 처벌한다

개발자들은 여전히 주요 질문이 요청 처리량(Request throughput)이나 생태계 규모인 것처럼 런타임을 이야기합니다. 코딩 에이전트에게 이러한 요소들은 부차적입니다. 런타임은 훨씬 더 가혹한 제품 제약 조건에 의해 평가받습니다.

코딩 에이전트는 모델과 운영 체제 (OS) 사이에 위치합니다. 에이전트는 파일을 읽고, 패치 (patch)를 작성하며, 서브프로세스 (subprocess)를 생성하고, 로그를 파싱하며, 테스트 출력을 감시하고, 권한을 관리하며, 때로는 IDE와 통신하고, 종종 부분적인 실패로부터 복구하려고 시도합니다. 이는 런타임이 단순한 실행 엔진이 아님을 의미합니다. 런타임은 제품의 표면 (product surface)의 일부가 됩니다.

만약 이 표면의 시작이 느리다면, 사용자는 첫 번째 유용한 토큰이 나오기도 전에 지연 (lag)을 느낍니다. 서브프로세스 처리가 불안정하다면, 테스트 실행이 멈춰버립니다. 패키징이 엉망이라면, 실제 노트북에서 설치 스크립트가 실패합니다. 스택 트레이스 (stack trace)가 너무 소란스럽거나 상태 (state)가 너무 많은 계층에 분산되어 있다면, 장애 진단은 비참해집니다.

이것이 바로 에이전트 도구가 일반적인 앱보다 잘못된 런타임에 대해 더 빠르게 대가를 치르는 이유입니다. 표준적인 백엔드는 컨테이너 (container), CI, 그리고 안정적인 배포 환경 뒤에 많은 런타임의 어색함을 숨길 수 있습니다. 하지만 로컬 코딩 에이전트는 그럴 수 없습니다. 에이전트는 사용자의 환경에서 실행되며, 사용자의 실제 리포지토리 (repo)를 건드리고, 사용자의 실제 툴체인 (toolchain)으로 셸 명령을 실행합니다. 모든 취약한 가장자리가 이제는 제품의 버그가 됩니다.

에이전트 런타임을 위한 실질적인 체크리스트는 다음과 같습니다:

• 콜드 스타트 (cold start) 및 대화형 지연 시간 (interactive latency)
• 설치 및 업그레이드 마찰 (friction)
• 서브프로세스 (subprocess), 파이프 (pipe), TTY 동작
• 크로스 플랫폼 파일 시스템 정확성
• 패키징 및 바이너리 배포
• 샌드박스 (sandbox) 호환성 및 권한 제어
• 장시간 실행되는 세션 동안의 관찰 가능성 (observability)

이 목록은 왜 런타임에 대한 논의가 변화했는지를 말해줍니다. 이것은 단순히 JavaScript 대 Rust의 문제가 아닙니다. 어떤 스택이 제품 팀에게 복잡하고 로컬 중심적이며 툴 집약적인 워크플로우에 대해 가장 신뢰할 수 있는 제어권을 제공하느냐에 관한 것입니다.

Bun이 에이전트 형태에 적합한 이유는 툴링 계층을 축소하기 때문입니다

이 분야에서 Bun의 매력은 단순히 속도만이 아닙니다. 속도도 중요하지만, 더 큰 핵심은 **표면적 축소 (surface area reduction)**입니다.

전통적인 JavaScript CLI 배포는 종종 Node, npm, 글로벌 설치 경로, lockfile 가정, 버전 관리자의 특이점, 패키지 해석(package resolution) 동작, 그리고 때로는 네이티브 모듈(native module)의 돌발 변수들을 하나로 엮어내는 과정을 의미합니다. 이러한 스택도 잘 작동할 수 있지만, 코딩 에이전트가 유용한 작업을 수행하기도 전에 실패할 수 있는 수많은 지점을 만들어내기도 합니다.

Bun은 런타임(runtime), 패키지 매니저(package manager), 번들링(bundling) 가정, 그리고 CLI 인체공학(ergonomics)을 더 긴밀한 경험으로 통합함으로써 문제의 형태를 변화시킵니다. 소비자용 웹 앱의 경우 이것이 생산성 향상에 도움이 될 수 있겠지만, 로컬 에이전트에게는 그 이상의 의미를 갖습니다. 이는 설정 엔트로피(setup entropy)에 대한 공격입니다.

설치 마찰은 제품 지표입니다

대부분의 개발자는 에이전트 채택이 설치 품질에 의해 얼마나 크게 좌우되는지 과소평가합니다. 코딩 도구는 열 번째 세션이 지난 후에야 평가받는 것이 아닙니다. 처음 3분 동안 평가받습니다.

만약 설치 경로가 다음과 같다면, 그 도구는 이미 취약하게 느껴집니다:

1. 특정 Node 버전 설치.
2. npm 업그레이드.
3. 셸 프로필(shell profile)이 올바른 글로벌 bin 경로를 노출하기를 희망.
4. 하나의 전이적 의존성(transitive dependency) 문제 해결.
5. macOS와 Linux에서 postinstall 단계가 다르게 동작하여 재실행.

이것은 단순한 기술적 번거로움이 아닙니다. 이것은 사용자 이탈(user churn)입니다.

다운로드와 첫 번째 프롬프트 사이의 가정(assumptions)의 수를 줄여주는 런타임은 불균형할 정도로 큰 제품 가치를 창출합니다. Bun이 매력적인 이유는 그 경로의 길이를 줄이는 데 도움을 주기 때문입니다.

콜드 스타트(Cold Start)는 벤치마크의 세부 사항이 아닙니다

대화형 에이전트는 웹 서비스가 아니라 에디터처럼 평가받습니다. 1초의 시작 페널티는 눈에 띕니다. 모든 호출, 컨텍스트 복구(context restore), 또는 도구의 서브프로세스(subprocess) 경계에서 이 페널티가 반복되면, 이는 제품의 인지된 지능(perceived intelligence)의 일부가 됩니다.

사용자들은 좀처럼 "이 런타임은 시작 특성이 좋지 않다"라고 말하지 않습니다. 대신 "도구가 무겁게 느껴진다"라거나 "작은 작업에는 더 이상 사용하지 않게 되었다"라고 말합니다. 이는 결국 같은 불만입니다.

런타임이 부팅 비용(boot cost)과 CLI 오버헤드(overhead)를 줄이면, 에이전트에게 위임할 가치가 있다고 느껴지는 작업의 종류가 달라집니다. 이는 단순한 미세 최적화(micro-optimization)가 아니라 제품의 레버리지 포인트(leverage point)입니다.

더 긴밀한 소유권의 중요성

여기에는 조직적인 관점도 존재합니다. 만약 벤더(vendor)가 런타임 표면(runtime surface)의 더 많은 부분을 소유하거나 강력하게 영향을 미칠 수 있다면, 버그를 해결하기 위해 끝없이 우회하는 대신 레이어 전반에 걸쳐 버그를 직접 해결할 수 있습니다.

이는 에이전트 제품에 있어 매우 중요한데, 많은 실패 사례가 앱 코드 내부에 깔끔하게 머물지 않기 때문입니다. 실패는 프로세스 실행(process execution), 스트리밍(streaming), 패키지 해석(package resolution), 권한(permissions), 그리고 로컬 OS 동작 사이의 경계(seams)에서 발생합니다. 더 긴밀한 런타임 스택(runtime stack)은 제품 팀이 사용자에게 고통을 주는 바로 그 지점들에 대해 더 큰 영향력을 행사할 수 있게 해줍니다.

Rust 레이어가 마케팅에서 암시하는 것보다 더 중요한 이유

"Rust로 작성됨"이라는 문구는 마케팅에서 남용되곤 하지만, 이 문맥에서는 실질적인 무언가를 가리킵니다. 에이전트 도구(agentic tools)에는 많은 시스템 수준(systems-level)의 실패 모드(failure modes)가 존재합니다.

이러한 도구들은 다음 사항들을 관리해야 합니다:

• 서브프로세스(subprocess) 수명 및 취소
• 데드락(deadlock) 없는 stdout 및 stderr 스트리밍
• 대규모 파일 시스템 탐색(filesystem walks)
• 저지연(low-latency) 파싱 및 변환
• 격리 경계(isolation boundaries)
• 긴 세션 동안의 메모리 동작
• 까다로운 에지 케이스(edge cases)에서의 충돌 저항성

이것들은 화려한 제품 기능은 아니지만, 사용자 경험의 핵심입니다. 런타임 기반의 일부가 시스템 언어의 제약 조건에 더 가깝게 이동한다는 것은, 보통 팀이 정확성(correctness)과 운영 동작(operational behavior)을 더 긴밀하게 제어하려고 시도하고 있음을 의미합니다.

그렇다고 해서 Rust가 에이전트의 문제를 자동으로 해결한다는 뜻은 아닙니다. 다만 제품 팀이 런타임 기질(substrate)에서 발생하는 모호하고, 동적이며, 계층적인 실패 모드를 수용하려는 의지가 더 낮아졌음을 의미합니다.

코딩 에이전트에게 이는 합리적인 선택입니다. 이 도구는 이미 개발자의 머신에서 의미 있는 동작을 수행하고 있습니다. 파일을 편집하고, 명령어를 실행하며, 저장소를 조사하고, 잠재적으로 제한된 샌드박스(sandboxes) 내부에서 실행되어야 한다면, 기반이 되는 실행 모델은 가능한 한 가장 좋은 의미로 '지루해야(boring)' 합니다.

Rust 관점에서 생각할 수 있는 유용한 방법은 다음과 같습니다: 제품이 운영 체제(operating system)를 오케스트레이션(orchestrating)하는 것에 가까워질수록, 런타임 구현 세부 사항은 점점 더 제품의 기능(feature)처럼 작동하기 시작합니다. 안전성(Safety), 예측 가능한 동시성(concurrency), 그리고 리소스 제어(resource control)는 더 이상 내부적인 엔지니어링 선호 사항이 아닙니다. 그것들은 사용자의 신뢰 요소가 됩니다.

서브프로세스 경계에서 실체화되는 런타임 결정

에이전트 런타임을 정직하게 평가하고 싶다면, HTTP 벤치마크를 보는 것을 멈추고 서브프로세스(subprocess) 동작을 살펴보기 시작해야 합니다.

코딩 에이전트는 사실 모델이 부착된 서브프로세스 오케스트레이션 엔진입니다. 이들은 git, rg, npm, pnpm, bun, cargo, pytest, php artisan, composer, docker, 그리고 커스텀 리포지토리 스크립트를 실행하는 데 엄청난 양의 시간을 소비합니다. 에이전트의 신뢰성은 실제 환경의 노이즈 속에서 이러한 도구들을 관리하는 능력에 달려 있습니다.

우수한 서브프로세스 지원이 처리해야 할 사항들

프로덕션급(production-grade) 에이전트 런타임은 다음과 같은 사항들에 대해 예측 가능한 동작을 제공해야 합니다:

• 버퍼링 재앙 없이 대량의 출력을 스트리밍(streaming)하는 것
• 취소 시 자식 프로세스(child processes)를 깔끔하게 종료하는 것
• 정상 종료, 타임아웃(timeout), 그리고 시그널 종료(signal termination)를 구분하는 것
• 대화형 프로그램과 의사 터미널(pseudo-terminals)을 처리하는 것
• 환경 변수(environment variables)를 의도적으로 보존하는 것
• stdout이 소란스럽거나 stderr가 폭발적으로 발생할 때 멈춤(hangs) 현상을 방지하는 것

이것들은 예외적인 케이스(edge cases)가 아닙니다. 코딩 도구들에게는 일상적인 경로입니다.

언어와 관계없이 에이전트가 결국 필요하게 되는 실행 래퍼(execution wrapper)의 형태는 다음과 같습니다:

type CommandResult = {
  exitCode: number | null;
  stdout: string;
...

이 예시는 의도적으로 단순하게 작성되었습니다. 실제 에이전트는 스트리밍 콜백(streaming callbacks), 허용 목록(allowlists), 구조화된 이벤트(structured events), 출력 절단(output truncation), 재시도 로직(retry logic), 그리고 환경 범위 지정(environment scoping) 등을 추가합니다. 핵심은 구문(syntax)이 아닙니다. 핵심은 런타임이 이 계층을 충분히 예측 가능하게 만들어 제품 팀이 그 위에 정책을 구축할 수 있도록 해야 한다는 점입니다.

실패 동작은 성공 속도보다 더 중요하다

빠른 해피 패스(happy path)는 보기 좋습니다. 하지만 더 중요한 것은 저장소(repo)가 특이한 상황일 때 도구가 깔끔하게 실패하느냐 하는 점입니다.

일반적인 실제 실패 사례는 다음과 같습니다:

• 대화형 입력을 기다리는 테스트 명령
• 취소(cancellation) 후에도 살아남는 손자 프로세스를 생성하는 자식 프로세스
• 셸 시작 모드 간의 환경 드리프트 (environment drift)
• 기가바이트 단위의 로그를 출력하는 저장소 스크립트
• TTY가 존재하지 않을 때 다르게 동작하는 도구들
• Windows, WSL, macOS 간의 경로(path) 차이

만약 런타임(runtime)이 이러한 실패를 관찰하거나 복구하기 어렵게 만든다면, 에이전트의 벤치마크 수치가 아무리 빨라 보여도 신뢰할 수 없게 느껴질 것입니다.

그렇기 때문에 Bun의 이야기는 단순히 "더 빠른 JavaScript"로서가 아니라, "CLI 및 시스템 인체공학(ergonomics)에 깊은 관심을 기울이는 런타임 스택"으로서 더 중요합니다. 그것이 실제 제품의 요구사항입니다.

샌드박싱(Sandboxing)은 런타임 논의를 완전히 바꿉니다

에이전트가 명령을 실행하고 파일을 편집할 수 있게 되면, 샌드박싱은 단순한 기능 체크리스트가 아니게 됩니다. 그것은 1차적인 아키텍처 제약 사항(architectural constraint)이 됩니다.

Claude Code에 대한 Anthropic의 샌드박싱 기술 문서는 실제 위협 모델을 보여준다는 점에서 유용합니다: 프롬프트 인젝션 (prompt injection), 과도하게 넓은 명령 액세스 권한, 의도치 않은 데이터 노출, 그리고 로컬 환경에서의 위험한 도구 실행 등이 그것입니다. 격리 제어(isolation controls)와 깔끔하게 협력할 수 없는 에이전트 런타임은 취약한 기반이 됩니다.

샌드박싱에는 런타임의 협력이 필요합니다

런타임이 스스로 전체 샌드박스를 제공할 필요는 없지만, 주변 계층들과 잘 맞물려 돌아가야 합니다:

• 운영 체제 샌드박스 기본 요소 (operating system sandbox primitives)
• 컨테이너화된 실행 (containerized execution)
• 명령 허용 목록 (command allowlists)
• 임시 디렉토리 격리 (temp directory isolation)
• 파일 권한 경계 (file permission boundaries)
• 위험한 동작 전의 정책 확인 (policy checks)

코딩 에이전트는 종종 다음과 같은 실행 깔때기(execution funnel)를 필요로 합니다:

사용자 요청
  -> 플래너 (planner)
  -> 정책 확인 (policy check)
...

만약 런타임이 하위 프로세스 제어, 환경 형성(environment shaping), 또는 임시 파일 시스템 격리를 까다롭게 만든다면, 제품 팀은 안전 정책을 구현하는 대신 플랫폼과 싸우게 될 것입니다.

네이티브 확장(Native Extensions) 및 시스템 인터페이스의 중요성

이 지점이 바로 런타임 선택이 까다로워지는 부분입니다. 순수한 개발자 경험(Developer Experience)만으로는 충분하지 않습니다. 에이전트 도구는 라이브러리, 플랫폼 API, 또는 보안 래퍼(Security Wrappers)를 통해 간접적으로 네이티브 기능이나 저수준 OS 인터페이스(Low-level OS interfaces)를 건드리게 되는 경우가 많습니다.

이는 호환성이 여전히 중요하다는 것을 의미합니다. Node는 생태계의 관성(Ecosystem inertia) 덕분에 이 분야에서 여전히 강력합니다. 단순히 더 많은 라이브러리, 더 많은 에지 케이스(Edge-case) 통합, 그리고 더 많은 엔터프라이즈 검증 패턴이 존재하기 때문입니다.

Bun이 여전히 올바른 선택이 될 수 있지만, 그 부담의 성격이 달라집니다. 만약 에이전트가 좁고 예측 가능하며 엄격하게 제어되는 스택을 필요로 한다면, Bun의 트레이드오프(Tradeoffs)는 매우 훌륭할 수 있습니다. 하지만 도구가 롱테일 패키지(Long-tail packages), 오래된 빌드 가정(Build assumptions), 또는 깊게 자리 잡은 엔터프라이즈 환경에 의존한다면, Node의 생태계 중력(Ecosystem gravity)은 여전히 매우 실질적인 요소입니다.

그렇기에 이것은 종교 전쟁이 아닙니다. 이것은 제품 토폴로지(Product topology)에 관한 문제입니다.

패키징, 업데이트, 그리고 운영 디버깅이 승자를 결정한다