Bun 75만 LoC를 11일에 Rust로 옮긴 워크플로 — '병렬 sub-agent + 파일당 reviewer 2명'의 정체

핵심 요약 (TL;DR)

Bun 창업자 Jarred Sumner가 Claude Code의 Dynamic Workflows로 Zig 코드 약 75만 줄을 11일 만에 Rust로 옮겼고, 기존 테스트 스위트의 99.8%를 통과시켰습니다. Anthropic은 이걸 "production-ready"가 아니라 "신뢰할 만한 개념 증명" 수준으로 명시했고, 그게 핵심입니다. 진짜 무기는 모델이 아니라 600줄 spec 문서와 파일마다 reviewer를 둘 붙인 워크플로 구조였습니다.

그래서 무슨 일이 있었던 거죠?

2026-05-28 Anthropic이 자사 블로그에 Dynamic Workflows 리서치 프리뷰를 공개하면서 첫 번째 사례로 Bun 포팅을 올렸습니다. Bun은 76,000개가 넘는 GitHub 스타를 가진 JavaScript 런타임으로, 원래는 Zig라는 비교적 마이너한 시스템 언어로 작성돼 있죠. 이걸 Rust로 통째로 옮기는 작업을 Bun 본인이 직접, Claude Code 위에서 11일 만에 끝낸 겁니다.

수치만 보면 어지럽습니다. 약 75만 줄, 11일, 테스트 99.8% 통과. 듣는 순간 "내 사이드 프로젝트도 그러면 며칠이면 끝나는 거 아닌가" 싶어지는 숫자죠. 그런데 Anthropic이 공식 표현으로 못 박은 단어가 "credible proof of concept"입니다. 신뢰할 만한 개념 증명. 프로덕션 배포까지 간 게 아니라, 정상 작동하는 사본을 만들어냈다는 뜻이에요.

진짜 비밀은 모델이 아니라 워크플로

Anthropic의 공개 자료와 HN 토론을 같이 읽어 보면 그림이 명확해집니다. Sumner가 워크플로에 박아 둔 룰은 세 가지였습니다.

첫째, 600줄짜리 spec 문서. Zig idiom 하나하나를 Rust 대응으로 미리 매핑해 둔, 사람이 직접 쓴 문서입니다. 모델한테 "Rust로 옮겨"라고 시킨 게 아니라 "이 매핑표대로 옮겨"라고 시킨 거죠. 자연어 지시가 아니라 결정 트리에 가까운 형태로 컨텍스트를 미리 굳혀 둔 구조입니다.

둘째, 파일마다 reviewer 두 명. Dynamic Workflows가 수백 개의 sub-agent를 병렬로 띄울 수 있게 되자, Sumner는 파일 한 개당 작성 에이전트 한 명에 검토 에이전트 두 명을 따로 붙였습니다. 두 명이 다 통과시킨 코드만 머지 후보로 올라가는 구조죠. 사람 코드 리뷰의 관행을 그대로 에이전트 레이어로 끌어내린 패턴이에요.

셋째, Tokio와 Rayon 같은 Rust async 런타임은 일부러 회피. pure callbacks + state machines 조합으로 갔다고 합니다. 모델이 더 잘 만지는 패턴이 따로 있다는 걸 인정한 선택이죠. 일반적인 Rust 코드 스타일과는 거리가 있지만, 에이전트 입장에선 추론할 표면적이 좁아지는 효과가 있습니다.

그런데 HN은 박수 안 쳤습니다

HN 토론은 활발했고 톤은 양분돼 있었습니다. 한쪽은 "역사적인 데모"라는 반응, 다른 쪽은 거의 적대적이었어요. 가장 많이 인용된 비판 한 줄을 옮기면 이런 톤입니다 — "이건 토큰을 가장 빠른 속도로 태우는 새로운 방법일 뿐". 그리고 더 본질적인 지적 "속도가 아니라 correctness가 늘 진짜 병목이다"가 따라붙었죠.

생성된 Rust 코드 안에 수많은 unsafe 호출이 들어가 있다는 비판도 나왔습니다. unsafe는 Rust 컴파일러의 안전 보증을 끄는 키워드인데, 그게 많다는 건 곧 "Rust로 옮겼다고는 하는데 Rust가 약속하는 안전성은 별로 못 받는다"는 뜻이에요. 11일·99.8% 같은 숫자만큼이나 이 부분이 중요한 두 번째 진실입니다.

바이브코더가 가져갈 진짜 메시지

Max 플랜이나 Team 플랜을 끊을지 망설이는 인디 개발자 입장에서, 이 사례는 두 가지를 동시에 보여줍니다. 한쪽으론 "75만 줄짜리 OSS 통째 포팅이 한 사람의 11일에 들어간다"는, 거의 SF 같은 데이터 포인트가 있고요. 다른 쪽으론 "그렇게 만든 코드는 아직 프로덕션엔 못 올린다, 검증과 정리는 사람이 한다"는 단서가 같이 박혀 있습니다.

그러니까 vibe-port와 vibe-ship은 다른 일이라는 거예요. 비유하자면 11일 만에 신축 건물 골조를 다 올린 거지, 사람이 들어가서 사는 단계가 아닌 거죠. 골조부터 빠르게 올릴 가치가 있는 작업이라면 이 워크플로는 정말 강력한 무기입니다. 다만 마감재·인테리어·안전점검은 여전히 사람이 한다는 걸 잊지 말아야 합니다.

자주 묻는 질문

Q. 75만 줄이라는 게 정확히 어떤 기준인가요?
Anthropic이 "approximately 750,000 lines of Rust"로 표현했습니다. 빈 줄과 주석 포함 여부, 자동 생성 코드 비중 등 세부 측정 기준은 공개되지 않았고요. 같은 기준으로 원본 Zig 라인 수를 비교한 수치도 공개되지 않았으니 "포팅 비율"이 아니라 "에이전트가 출력한 총량"으로 읽는 게 안전합니다.

Q. 그럼 우리 회사 레거시 코드도 11일에 옮길 수 있나요?
아닙니다. Bun은 이미 잘 짜인 OSS이고, 메인테이너 본인이 도메인을 완벽히 알고 있는 상태에서 600줄짜리 매핑 문서를 직접 썼다는 전제가 있습니다. 도메인 지식과 spec을 사람이 미리 굳혀 두는 시간이 빠진 "11일"이 아닙니다. 그리고 결과물은 프로덕션 배포가 아직이라는 점도 같이 봐야 합니다.

Q. Dynamic Workflows는 누가 쓸 수 있나요?
2026-05-28에 리서치 프리뷰로 공개됐고, Anthropic 발표 기준 Enterprise·Team·Max 플랜 대상입니다. 일반 Pro 플랜에선 아직 접근할 수 없는 단계라는 점만 인지하고 계시면 됩니다.

11일 만에 75만 줄을 옮긴 워크플로의 진짜 정체는, 결국 "사람이 spec을 굳히고 에이전트를 위계적으로 배치한다"는 오래된 엔지니어링 룰을 에이전트 시대로 끌어온 것에 가깝습니다. 모델은 점점 비슷해지지만 워크플로 설계는 한 사람의 머리에서 나옵니다 — 이 비대칭이 한동안 바이브코더의 진짜 경쟁력이 될 거예요.