Anthropic이 Claude Code로 대규모 코드 마이그레이션을 실행하는 법

1. 두 개의 마이그레이션

접근 방식은 달랐지만, 둘 다 "멀티 에이전트 루프 + 기계적 검증" 이라는 같은 뼈대를 공유했습니다.

2. 왜, 그리고 언제 언어를 바꾸는가

마이그레이션은 초기 설계와 현재 상황 사이의 간극에서 시작됩니다. 알려진 트레이드오프가 발목을 잡거나, 더 나은 방법이 등장했거나, 원래 생태계가 쪼그라들 때입니다. Jarred가 Zig를 고른 건 2026년 이전, LLM도 없던 시절 "오클랜드의 비좁은 아파트에서 1년 만에 Bun을 쓰기" 위한 선택이었죠. 이제 Bun CLI는 월 1,000만 회 이상 다운로드되고 Claude Code 내부에서도 쓰입니다.

3. 왜 AI가 마이그레이션의 셈법을 바꾸는가

Fable 5와 Opus 4.8은 서브에이전트로 병렬 워크스트림을 위임·지휘·검증하고, 목표를 향한 여러 경로를 찾는 데 특히 강합니다. 대규모 코드 마이그레이션이 이 모델들에 효과적인 이유는 다음과 같습니다.

4. 언어의 간극(Gap)이란 무엇인가

새 언어는 옛 언어와 다른 요구사항을 강제합니다. 이 암묵적 지식을 명시적으로 기록한 것이 "갭 인벤토리"입니다. 두 사례의 핵심 간극을 코드로 비교합니다.

fn readConfig(allocator: Allocator) ![]u8 {
  const buf = try allocator.alloc(u8, 1024);
  // ...fill buf...
  return buf; // 주석만이 "호출자가 free 해야 함"을 말한다
}
// defer allocator.free(buf)를 잊어도 컴파일은 된다.
// 누수는 런타임에서야 드러난다.

fn read_config() -> Vec<u8> {
  let buf = vec![0u8; 1024];
  // ...fill buf...
  buf // 소유권이 호출자로 이동, 메모리는 자동 해제
}
// 이동 후 사용? 이중 해제? 둘 다 컴파일 불가.
// free 호출 자체가 없으니 잊을 것도 없다.

def register(handler):
    handler.setup()
    return handler.run({"retries": 3})
# .setup()과 .run()을 가진 어떤 객체든 동작한다.
# 실제로 뭐가 넘어오는지? 코드베이스 전체를 읽어야 안다.

interface RunResult { ok: boolean }
interface Handler {
  setup(): void;
  run(opts: { retries: number }): Promise<RunResult>;
}
function register(handler: Handler): Promise<RunResult> {
  handler.setup();
  return handler.run({ retries: 3 });
}
// 컴파일되려면 계약을 먼저 적어야 한다.

5. 대규모 마이그레이션의 6단계

각 단계는 리뷰와 게이트로 연결됩니다. Jarred는 이 흐름을 그대로 따랐고, Mike는 유사한 구조로 전체를 처음부터 끝까지 돌린 뒤 규칙과 워크플로우를 수정해 다시 실행하는 방식을 세 번째 시도까지 반복(매번 결과물은 폐기)했습니다.

6. 코드 마이그레이션 베스트 프랙티스

모든 실행이 이전에는 몰랐던 것을 가르쳐 줬지만, 프로젝트를 관통해 유효했던 몇 가지 원칙입니다.

7. 결과 — 측정 가능하게 더 나은 코드

Jarred의 Bun 마이그레이션은 프로덕션에 올라가 있습니다. 모든 마이그레이션에 트레이드오프는 있습니다 — Rust 코드의 약 4%는 C/C++ 경계의 단일 라인 포인터 연산이 대부분인 unsafe 블록 안에 있습니다. 하지만 새 코드베이스는 명백히 더 낫습니다.

오래 미뤄둔 마이그레이션의 셈법을 다시 계산할 때가 됐는지 자문해 볼 만합니다. 그동안 참고 써온 코드베이스를 하나 골라, Claude에게 그 마이그레이션 프로세스가 어떤 모습일지 물어보는 것부터 시작해 보세요.