어제 Claude Code의 업데이트 이후 평소처럼 스모크 테스트 (Smoke Test)를 실행하던 중, 기동 시의 동작이 조금 변했다는 느낌을 받았다. 의존성을 늘린 기억이 없는데 실행 기반까지 교체되었다면, 살펴봐야 할 곳이 달라진다.

먼저 결론부터 쓰자면, 현재의 Claude Code는 실행 시 사용하는 Bun의 버전을 바이너리로부터 확인할 수 있다. Rust 유래의 경로 문자열(Path string)도 함께 수집해 두면, 적어도 "Node를 호출하고 있을 뿐"이라는 전제로 조사를 시작하지 않아도 된다.

2026년 7월의 Bun 발표에서는 Claude Code v2.1.181 이후가 Rust 버전의 Bun을 사용하여 Linux의 기동이 10% 빨라졌다고 설명되어 있다. 전면 이식은 11일간, 약 50개의 dynamic workflow를 통해 진행되었으며, 기존의 TypeScript 테스트군을 그대로 실행했다고 한다. 화면에는 잘 드러나지 않는 변경이라도 기동, 자식 프로세스 (Child process), 모듈 해결 (Module resolution)에서 차이가 발생했을 때의 분류 정보가 된다.

로그를 수집하기 시작하기 전에, 우선 동봉된 바이너리를 읽기로 했다. 조사의 입구로서 비용이 저렴하다.

다음 스크립트는 claude가 PATH에 있다는 것을 전제로, 내장된 Bun의 버전과 Rust 소스 경로 문자열의 건수를 출력한다. macOS에서 Claude Code 2.1.215를 대상으로 실행했다.

#!/usr/bin/env bash
set -euo pipefail
claude_bin="$(command -v claude || true)"
...

실행 결과는 다음과 같았다.

Claude binary: /opt/homebrew/bin/claude
Embedded runtime: Bun v1.4.0 (macOS arm64)
Rust source paths: 563

strings의 결과는 바이너리에 포함된 문자열일 뿐, Rust 코드 전체를 복원하는 것은 아니다. 따라서 이것을 엄격한 이력 증명으로 사용할 수는 없다. 그럼에도 버전과 .rs 경로를 동일한 실행 파일에서 얻을 수 있으므로, 조사 대상의 실체를 혼동하지 않기 위해서는 충분히 유용하다.

563은 유니크한 파일 수가 아니다. 링크 시에 남은 중복을 포함하여 매칭된 경로 문자열의 건수다. 유니크한 수가 필요하다면 파이프의 끝을 sort -u | wc -l로 바꾼다. 내 환경에서는 223건이었다.

여기서 수를 늘리는 것 자체에는 의미가 없다. 업데이트 전후로 동일한 검사를 남겨두고, Bun의 버전만 바뀌었는지 아니면 동봉물의 구성까지 움직였는지를 비교한다. CI의 상시 체크보다는 업데이트 직후의 수동 스모크 테스트에 추가하는 정도가 다루기 쉽다고 생각한다.

다른 이야기지만, 런타임 (Runtime) 이식 이야기를 들으면 성능만을 쫓기 쉽다. Bun의 설명을 읽어보면, 이식의 동기는 use-after-free나 double-free를 컴파일러의 검사로 넘기는 데 있었다. 체감되는 속도보다 장애 조사에서 재현하기 어려운 크래시 (Crash)의 모수가 줄어드는 것이 팀에는 더 효과적인 경우가 많다.

우선 버그 보고 시에 claude --version뿐만 아니라 위의 2줄을 덧붙인다. 그다음, 업데이트 직후에만 실패했다면 동일한 프롬프트를 다른 머신과 비교하기 전에 동봉된 Bun의 버전 차이를 확인한다. 자식 프로세스나 파일 감시 (File watching)가 얽혀 있다면 특히 빠르다.

Claude Code의 업데이트는 CLI의 기능 차이만 보고 있으면 충분한 시기가 아니게 되었다. 실행 런타임도 릴리스 경계로 취급한다. 작은 검사이지만, 원인 조사에서의 첫 30분을 낭비하지 않기 위한 기록이 된다.

참고: Bun 공식: Rewriting Bun in Rust, Claude Code uses Bun written in Rust now