535,496줄, 11일, 16만 5천 달러
숫자부터 보자. Bun 팀은 535,496줄의 Zig 코드를 64개 AI 에이전트를 병렬로 돌려 11일 만에 Rust로 옮겼다. 수작업이었다면 코드베이스를 완전히 이해하는 엔지니어 3명이 약 1년을 통째로 써야 했을 작업이다. 그동안 Node.js 호환성 개선도, 보안 버그 수정도, 신규 기능 개발도 멈춰야 했을 것이다. API 비용 16만 5천 달러는 미국 중간급 소프트웨어 엔지니어 연봉과 비슷한 수준이지만, 그 연봉의 엔지니어 한 명이 11일 안에 이 성과를 내는 건 불가능하다. ROI 계산은 단순하다.
하지만 이 숫자만 보고 "우리도 AI 에이전트 돌리면 되겠다"고 결론 내리면 곤란하다. Bun의 사례를 제대로 읽으려면 그들이 _속도를 낼 수 있었던 조건_을 먼저 봐야 한다. 실제로 Bun 팀 스스로 이 방식을 재현하려면 세 가지가 필요하다고 못 박았다. 코드베이스를 깊이 아는 엔지니어, 테스트 통과를 실제 동작의 근거로 신뢰할 수 있는 강력한 테스트 스위트, 그리고 성공 여부가 불확실해도 비용을 감수할 의지. 이 세 번째 조건은 솔직한 고백이다—처음부터 성공이 보장되지 않았다는 뜻이다.
속도는 설계에서 나왔다
Bun의 AI 마이그레이션이 단순한 "프롬프트 몇 개로 뚝딱" 작업이 아니었다는 점을 짚어야 한다. 출발점은 Claude와 3시간 동안 논의해 정리한 600줄짜리 PORTING.md였다. tokio, rayon, async fn 금지, Bun 고유의 이벤트 루프와 콜백 구조 보존, 빌림 검사기 우회를 위한 원시 포인터 사용 금지 등 구체적인 제약이 담겨 있었다. 이 문서가 없었다면 64개 에이전트가 병렬로 만들어낸 코드는 각자 다른 방향을 향했을 것이다.
그리고 각 커밋마다 두 차례의 "적대적 검토"가 있었다. 변환 작업과 분리된 세션에서 Claude가 결과물을 검토했다. 컴파일 오류가 약 16,000개 나왔을 때도 병렬화된 수정 루프가 돌았고, 에이전트들은 자정부터 오전 11시 30분까지 사람 개입 없이 오류를 수정했다. 최종적으로 모든 테스트를 통과하고 CI를 통과한 뒤에야 병합했다. 속도는 에이전트 숫자에서 나온 게 아니라, 이 검증 루프 설계에서 나왔다.
AI가 만든 코드, 무엇을 기준으로 신뢰하나
여기서 질문이 하나 생긴다. Bun의 테스트 스위트가 그만큼 신뢰할 수 있는 수준이었기 때문에 이 작업이 가능했다는 건데—그렇다면 테스트 자체는 어떻게 믿을 수 있나? AI 에이전트 테스팅에 관한 Focused Labs의 분석이 이 지점을 정확히 짚는다. 핵심 주장은 이렇다. 벤치마크 점수는 약한 오너십을 만들고, 실패 트레이스는 구체적인 오너십을 만든다.
에이전트가 벤치마크에서 좋은 점수를 받는 동안 실 트래픽에서 계속 실패하는 경우는 흔하다. "에이전트가 잘못된 툴을 골랐다", "리트리버가 오래된 정책 텍스트를 반환했다", "타임아웃 이후 쓰기 시도로 사이드 이펙트가 중복됐다"—이 실패들은 점수에 나타나지 않는다. 트레이스에 나타난다. 실제 트래픽에서 발생한 실패를 트레이스로 캡처하고, 그것을 재현 가능한 테스트 케이스로 만들어 릴리즈 게이트에 연결하는 것—이것이 AI 에이전트 품질 관리의 실질적인 방향이다. 대시보드를 "지켜보겠다"는 슬랙 스레드가 아니라.
테스트 케이스 자동 생성의 함정
AI로 테스트 케이스를 자동 생성하는 접근도 마찬가지다. 오후 한나절에 수천 개의 테스트를 생성하는 건 쉽다. 그게 실제로 버그를 잡는지는 다른 문제다. dev.to에 공유된 실전 경험은 솔직하다. CI는 계속 초록불이었지만 프로덕션은 계속 깨졌다. 들여다보니 생성된 테스트의 3분의 1이 틀렸거나, 거의 중복이거나, 실제 유저라면 절대 하지 않을 질문들이었다.
핵심 교훈은 세 가지로 압축된다. 첫째, 생성보다 필터가 중요하다. 필요한 것의 열 배를 생성하고, 그 중 10%만 살아남는 기준을 설계해야 한다. 텍스트가 아니라 의미 기준으로 중복을 걷어내고, 실제 유저가 이런 질문을 할까를 기준으로 심사해야 한다. 80%를 버리는 게 아깝게 느껴지겠지만, 그 80%가 테스트 세트를 오염시키면 초록불은 아무 의미가 없다. 둘째, 생성 모델과 심사 모델은 달라야 한다. 같은 모델이 쓰고 채점하면, 자기 자신의 나쁜 습관을 그대로 통과시킨다. 다른 모델 패밀리를 심사자로 쓰는 것만으로도 필터 신뢰도가 크게 올라간다. 셋째, 합성 테스트 세트를 실제 트래픽 데이터와 비교 검증해야 한다. 합성 데이터가 실제 트래픽과 동떨어진 공간에 있다면, 모델은 현실이 아닌 생성기가 발명한 세계에 최적화된다.
팀이 실제로 설계해야 할 것
세 사례를 종합하면 하나의 메시지로 수렴된다. AI 에이전트로 대규모 작업을 돌리는 것과, 그 결과물을 신뢰할 수 있는 것은 완전히 다른 문제다. Bun이 11일 안에 성공할 수 있었던 건 PORTING.md로 제약을 설계했고, 각 커밋마다 적대적 검토를 넣었으며, 최종 게이트로 강력한 테스트 스위트가 있었기 때문이다. 에이전트 숫자가 64개여서가 아니다.
팀이 AI 에이전트 기반 자동화를 도입할 때 먼저 설계해야 할 것은 세 가지다. 작업 제약 문서: 에이전트가 무엇을 하면 안 되는지를 코드베이스 맥락에 맞게 명문화한 가이드. 검증 루프: 생성 → 적대적 검토 → 컴파일/테스트 → 게이트 통과의 순서를 자동화한 파이프라인. 실패 기반 테스트 관리: 벤치마크 점수가 아니라 실 트래픽 실패 트레이스를 소유 가능한 테스트 케이스로 전환하는 프로세스.
이 방식이 모든 팀에 열려 있는가
솔직히 말하면, 아직은 아니다. Bun의 사례는 "잘 엔지니어링된 프로젝트"에서만 이런 속도가 가능하다고 스스로 인정한다. 월간 다운로드 2,200만 건의 프로덕션 런타임, 철저한 CI 인프라, 코드베이스 전체를 꿰는 엔지니어가 전제였다. 대부분의 팀에는 그 기반이 없다.
그러나 방향은 명확하다. AI 에이전트 기반 마이그레이션과 대규모 자동화는 점점 더 빨라질 것이고, 그 속도를 실제로 활용하려면 검증 설계가 먼저 완성되어 있어야 한다. 테스트 스위트가 강할수록, 실패 트레이스 기반 피드백 루프가 정교할수록, 더 많은 작업을 에이전트에게 안심하고 넘길 수 있다. 에이전트를 얼마나 많이 돌리느냐보다, 그 출력을 얼마나 신뢰할 수 있게 설계했느냐가 AI-First 팀의 실질적인 차별점이 된다.