블로그2분 읽기

클로드 코드 시작이 20% 빨라진 건 앤트로픽 덕이 아닙니다

클로드 코드 입력창이 397밀리초에서 318밀리초로 줄었는데, 예고한 사람은 앤트로픽이 아니라 Bun 창시자 재러드 섬너입니다. bun build --compile을 쓰는 앱 전부가 이득을 봅니다.

클로드 코드 시작이 20% 빨라진 건 앤트로픽 덕이 아닙니다 대표 이미지

클로드 코드의 다음 버전은 입력창이 뜨기까지 397밀리초 걸리던 것을 318밀리초로 줄였습니다. 그런데 이 예고를 올린 사람이 앤트로픽 직원이 아니에요. Bun 런타임을 만든 재러드 섬너입니다. 트윗은 조회 9만을 넘겼어요.

남의 제품 속도 개선을 런타임 제작자가 발표하는 장면. 저는 이 장면이 지금 하네스 생태계의 층 구조를 정확히 보여준다고 봅니다.

왜 Bun 창시자가 클로드 코드 속도를 발표하나요?

클로드 코드가 Bun으로 빌드되기 때문입니다.

이번 가속은 클로드 코드 팀이 자기 코드를 고친 게 아니라, Bun과 그 아래 자바스크립트코어 엔진 전반의 최적화 작업에서 나왔어요. 본인 스레드에 못을 박았습니다. bun build --compile을 쓰는 모든 앱이 이득을 본다고요.

수치도 실측 방식까지 공개됐습니다. 리눅스 x64, 조용한 환경, 25회 교차 실행의 중앙값. 397에서 318로, 79밀리초입니다.

80밀리초에 9만 명이 반응한 이유는 뭔가요?

에이전트 도구는 하루에도 수십 번 켭니다.

브라우저는 아침에 한 번 켜지만, 터미널 도구는 세션마다 새로 시작해요. 그때마다 기다리는 0.4초는 한 번이면 아무것도 아니지만, 하루 서른 번이면 리듬이고, 리듬이 나쁘면 도구를 바꿉니다.

같은 주에 클로드 코드 공식 계정도 같은 병목을 팠습니다. 리눅스 다운로드를 4.5배 줄여 75MB로, 세션당 메모리를 40~70MB씩 줄이고, 샌드박스 준비를 기다리지 않고 바로 타이핑되게 했어요. 런타임 쪽과 앱 쪽이 동시에 시작 속도를 파는 중입니다.

런타임 한 층을 고치면 무슨 일이 생기나요?

지렛대가 생각보다 깁니다.

Bun 위에는 클로드 코드만 있는 게 아니에요. bun build --compile로 배포되는 CLI 도구 전부가 이번 최적화를 공짜로 받습니다. 한 층 아래를 고치면 그 위의 생태계 전체가 함께 빨라지는 구조예요.

이건 하네스 미니멀리즘 흐름과도 이어집니다. 바이너리를 88kb까지 줄이는 진영이 있고, 람다처럼 밑단 런타임의 밀리초를 깎는 진영이 있어요. 방향은 하나입니다. 지능은 API 건너편에 있으니, 내 컴퓨터에서 도는 부분은 가볍고 빨라야 한다는 것.

남는 생각

저는 이 예고를 하네스 전쟁의 최전선 이동으로 읽습니다.

모델 성능 경쟁은 위에서 벌어지지만, 체감 경쟁은 밑에서 벌어져요. 켜지는 속도, 뜨는 속도, 키 입력에 반응하는 속도. 벤치마크는 도구를 고를 때 한 번 보지만, 시작 속도는 매일 겪습니다.

그리고 이번 사례가 보여주는 건 그 경쟁의 주체가 하네스 회사만이 아니라는 점이에요. 런타임, 엔진, 빌드 도구까지 한 층씩 내려가며 밀리초를 캐는 사람들이 있고, 그들의 성과가 위층 제품의 발표문에 올라옵니다.

밀리초를 파는 사람들이 결국 이깁니다. 그 사람들이 어느 회사 소속인지는 점점 덜 중요해지고 있어요.


원문·소스

FAQ

자주 묻는 질문

왜 Bun 창시자가 클로드 코드 속도를 발표하나요?
클로드 코드가 Bun으로 빌드되기 때문입니다. 가속은 클로드 코드 팀이 자기 코드를 고친 게 아니라 Bun과 자바스크립트코어 엔진 전반의 최적화에서 나왔어요.
수치는 어떻게 쟀나요?
리눅스 x64, 조용한 환경, 25회 교차 실행의 중앙값입니다. 397에서 318로, 79밀리초예요.
런타임 한 층을 고치면 무슨 일이 생기나요?
bun build --compile로 배포되는 CLI 전부가 이번 최적화를 공짜로 받습니다. 지능은 API 건너편에 있으니 내 컴퓨터에서 도는 부분은 가볍고 빨라야 한다는 흐름과 이어져요.