facts

최근 한 달간 앤스로픽 개발팀은 Claude Fable 5와 Claude Opus 4.8, 그리고 동적 워크플로를 결합해 수만에서 수십만 줄 규모의 패키지 10개를 다른 언어로 이전했다. 가장 큰 규모의 작업이었던 Bun의 Zig-Rust 이전에서는 2주 미만의 기간 동안 100만 줄의 코드를 생성했으며, Python-TypeScript 이전 프로젝트에서는 주말 동안 16만 5,000줄을 옮겼다.

자원 투입 규모는 상당하다. Bun 이전 작업에는 캐시되지 않은 입력 토큰 59억 개와 출력 토큰 6억 9,000만 개가 소비되었으며, API 가격 기준 약 16만 5,000달러의 비용이 발생했다. 반면 Python-TypeScript 이전의 핵심 구간에서는 2,700만 토큰이 사용되었다. 이 과정에서 수백 개의 에이전트와 8단계의 관문, 3회의 적대적 검토 프로세스가 동원되었다.

how-it-works

핵심 작동 원리는 개별 코드를 수동으로 수정하는 것이 아니라, 코드를 생성하는 '루프' 자체를 개선하는 방식에 있다. 전체 파이프라인은 판정 기준 준비, 규칙집·의존성 지도·차이 목록 작성, 규칙 스트레스 테스트, 전체 번역, 컴파일, 실행, 동작 비교의 단계로 구성된다. 특히 번역 전 단계에서 작성하는 규칙집은 단순한 대응표를 넘어 설계 문서의 역할을 하며, 의존성 지도는 병렬 처리를 위해 파일 간 관계를 지도화하는 데 사용된다.

구현과 검토 단계에서는 모델의 등급을 나누어 토큰 사용량을 최적화하는 자문 패턴을 적용했다. 대량의 코드 구현은 Claude Sonnet과 같은 상대적으로 작은 모델의 하위 에이전트(Bun 사례의 경우 12개)가 병렬로 처리하고, 결과 검토와 상위 규칙 작성은 Fable 5나 Opus 4.8 같은 대형 모델이 담당한다. 검토 과정에서는 독립된 컨텍스트를 가진 적대적 검토자 2개가 결과를 평가하며, 의견이 갈릴 경우 세 번째 에이전트가 최종 판정한다.

검증 루프는 기계적 정답을 기반으로 작동한다. 컴파일 오류나 테스트 실패가 발생하면 이를 개별 파일의 버그로 보지 않고, 상위 규칙의 결함으로 간주해 규칙집을 수정하고 해당 배치를 전체 재생성한다. 이를 위해 원본과 포트의 동작이 일치하는지 확인하는 '동등성 하네스'가 필수적이다. Bun의 경우 TypeScript로 작성된 대규모 테스트 스위트를 활용해 병합 전 기존 테스트를 100% 통과시켰으며, Python 이전 사례에서는 7개의 실제 사용 시나리오를 통해 동작 변화를 추적했다.

implementation-impact

자동화 루프를 통한 이전은 실제 인프라 지표의 개선으로 이어졌다. Bun의 Rust 포트는 2,000회 반복 벤치마크 결과 메모리 사용량이 6,745MB에서 609MB로 급감했으며, 바이너리 크기는 19% 축소되었다. 실제 워크로드 성능은 2~5% 향상되었으나, Rust 코드의 약 4%가 C/C++ 경계의 포인터 연산을 위해 `unsafe` 블록으로 구현되었다는 제약이 확인되었다. Python-TypeScript 이전의 경우, 플랫폼별 바이너리 생성 시간이 8분에서 2초로 단축되었고 바이너리 시작 속도는 6배 빨라졌다.

실무자가 이 방식을 도입할 때 주의할 점은 '판정자'의 설계다. 원본 언어의 내부 함수에 의존하는 테스트는 포트 후 실행되지 않으므로, 이를 외부 호출 기반의 단언(Assertion)으로 재작성해야 한다. 또한, 전체 이전에 앞서 소규모 파일로 규칙을 흔들어 보는 스트레스 테스트를 통해 중대한 설계 오류를 먼저 제거하는 과정이 필수적이다.

결과적으로 개발자는 이제 코드 한 줄의 수정보다 규칙집의 문장 하나를 고치는 것에 집중해야 하며, 1년 내내 반복되는 메모리 버그나 만성적인 빌드 병목이 확인된다면 수십만 달러의 API 비용을 감수하더라도 전체 언어 이전을 검토할 수 있는 기술적 근거가 마련되었다.