코드 100만 줄을 옮긴 Claude Code, 성공 기준은 생성 루프였어요

코드 100만 줄을 옮긴 Claude Code, 성공 기준은 생성 루프였어요

AI 뉴스 썸네일

Claude Code가 대규모 언어 이전에도 쓰이기 시작했어요. Anthropic 개발자들은 최근 한 달 동안 수만~수십만 줄 규모의 패키지 10개를 옮겼고, Bun의 Zig 코드를 Rust로 바꾸는 작업에서는 2주가 되기 전에 코드 100만 줄을 생성했어요. 1

성과만 보면 빠른 코드 생성 이야기처럼 들려요. 실제 작업에서 더 많은 시간을 쓴 곳은 번역 규칙, 테스트, 컴파일 오류, 원본과의 동작 비교였어요. 사람이 파일을 하나씩 고치는 대신 반복해서 틀리는 원인을 규칙에 반영하고 해당 묶음을 다시 생성했어요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
Bun 이전	Zig에서 Rust로 옮기며 2주 미만에 코드 100만 줄을 생성했어요	병합 전 기존 테스트를 모두 통과했지만, 병합 뒤 회귀 19건도 발견됐어요
Python 이전	주말 동안 TypeScript 코드 16만 5,000줄을 만들었어요	수백 개 AI 작업과 8개 단계 관문, 3차례 적대적 검토를 거쳤어요
작업 방식	개별 오류보다 오류를 만든 규칙과 반복 과정을 고쳤어요	같은 실수가 여러 파일에 퍼지는 일을 줄이고 중단한 작업도 다시 이어갈 수 있어요
비용과 결과	Bun 이전 비용은 API 가격 기준 약 16만 5,000달러였어요	바이너리는 19% 작아졌고 일부 실제 작업 성능은 2~5% 빨라졌어요

1. 대규모 코드 이전에서 Claude Code가 맡은 일

기존 코드가 명세와 정답을 함께 제공했어요

언어를 바꾸는 작업은 새 기능 개발보다 성공 조건을 만들기 쉬운 편이에요. 이전 코드의 입력과 출력이 비교 기준이 되고, 기존 테스트가 새 코드의 동작을 확인해 줘요. 컴파일 오류와 테스트 실패도 다음 수정 목록으로 바로 바꿀 수 있어요.

728x90

Bun 이전에서는 TypeScript로 작성된 기존 테스트가 Zig와 Rust 구현을 같은 기준으로 검사했어요. 병합 전 CI에서 기존 테스트를 모두 통과했지만, 운영에 들어간 뒤 회귀 19건이 나왔고 모두 수정됐어요. 테스트 통과가 강한 기준이기는 해도 실제 운영 검증을 완전히 대신하지는 못한다는 점도 함께 보여 줘요. 2

Python에서 TypeScript로 옮긴 사례는 실제 사용 시나리오 7개를 양쪽 코드에 실행한 뒤 명령 출력의 차이를 비교했어요. 기존 테스트가 부족하면 원본 프로그램을 기준 삼아 별도 동등성 검사 도구를 만들 수 있다는 접근이에요.

파일보다 규칙을 먼저 고쳤어요

작업은 규칙집, 파일 의존성 지도, 언어 차이 목록을 만드는 단계에서 시작했어요. Zig의 수동 메모리 관리와 Rust의 소유권처럼 언어마다 같은 개념을 다루는 방식이 달라요. Python의 느슨한 객체 계약을 TypeScript 인터페이스로 옮길 때도 먼저 기준을 정해야 해요.

전체 코드를 옮기기 전에는 소규모 시험 이전으로 규칙을 흔들어 봤어요. Bun 사례에서는 파일 3개를 규칙집대로 번역한 결과와 숙련된 Rust 개발자 관점의 결과를 비교했어요. 이 과정에서 전체 1,448개 파일에 퍼질 수 있었던 중대한 문제 2개를 미리 찾았어요. 시험에서 나온 코드는 버리고, 규칙만 다듬은 뒤 본 작업을 시작했어요.

같은 오류가 여러 파일에서 반복되면 각 파일을 직접 고치지 않았어요. 규칙집에 새 기준을 추가하고 영향을 받은 묶음을 다시 생성했어요. 코드 생성량보다 생성 과정을 안정시키는 데 초점을 둔 이유예요.

병렬 작업과 비싼 검증을 분리했어요

파일과 패키지는 여러 묶음으로 나눠 동시에 옮겼어요. 대량 번역은 작은 모델이 맡고, 큰 모델은 규칙 작성과 검토에 집중하는 방식도 썼어요. 완료 여부는 출력 파일이 디스크에 있는지처럼 기계적으로 판단했고, 실행할 때마다 남은 목록을 다시 만들었어요. 작업이 중단돼도 끝난 묶음을 처음부터 다시 처리하지 않아도 돼요.

컴파일 위치는 프로젝트마다 달랐어요. TypeScript는 단위별 컴파일이 수초 안에 끝나서 번역 과정마다 실행했어요. Rust의 `cargo`는 수 분이 걸려 전체 번역 뒤에 따로 실행했어요. 여러 수정 작업이 동시에 비싼 빌드를 요청하지 않도록 빌드 권한을 한 프로세스에 모은 점도 눈여겨볼 만해요.

검토자는 별도 맥락에서 결과를 공격적으로 확인했어요. 두 검토 결과가 다르면 세 번째 검토가 판단했어요. 마지막에는 원본과 새 프로그램에 같은 테스트를 실행하고, 실패한 항목과 관련 코드만 다시 살폈어요.

속도만큼 비용과 회귀 위험도 컸어요

Bun 이전에는 캐시되지 않은 입력 토큰 59억 개와 출력 토큰 6억 9,000만 개가 쓰였어요. Anthropic은 API 가격으로 약 16만 5,000달러에 해당한다고 밝혔어요. 대규모 이전 비용이 줄었어도 작은 팀이 가볍게 실험할 수준은 아니에요. 2

결과는 수치로 확인됐어요. Linux와 Windows 바이너리 크기가 19% 줄었고, HTTP 서비스와 `next build`, `tsc` 같은 실제 작업은 2~5% 빨라졌어요. 빌드 2,000회를 반복한 측정에서는 메모리 사용량이 6,745MB에서 609MB로 줄었어요. 반면 Rust 코드 약 4%는 `unsafe` 블록 안에 남았어요. 언어 이전이 모든 기술 부채를 자동으로 없앤 것은 아니에요.

왜 중요한가요

대규모 코드 이전의 병목이 타이핑에서 검증 설계로 옮겨가고 있어요. 컴파일러, 테스트, 출력 비교처럼 맞고 틀림을 기계적으로 판정할 수 있는 작업은 여러 AI 작업을 병렬로 붙이기 좋아요. 반대로 동작 기준이 모호하거나 기존 코드 자체가 불안정하면 빠르게 생성된 코드도 신뢰하기 어려워요. 2

실무에서는 모델 선택보다 먼저 종료 조건을 정해야 해요. 원본과 새 구현을 같은 입력으로 비교할 수 있는지, 일부러 망가뜨린 코드에서 테스트가 실패하는지, 반복 오류를 규칙으로 되돌릴 수 있는지를 확인해야 해요. 이 세 가지가 없으면 코드 생성 속도가 빨라도 검토 비용이 계속 늘어요.

모든 프로젝트를 다른 언어로 옮길 이유도 없어요. Anthropic 사례에는 대규모 토큰 비용과 병합 뒤 회귀가 함께 있었어요. 장기간 반복되는 메모리 문제, 느린 빌드, 줄어드는 생태계처럼 비용을 설명할 수 있는 제약이 있을 때 검토할 만해요. 작은 코드베이스라면 전체 이전보다 프레임워크 업그레이드나 문제 구간의 단계적 교체가 더 안전할 수 있어요.

참고 자료

1. Claude Code로 대규모 코드 마이그레이션을 수행한 방법 — GeekNews
2. How Anthropic runs large-scale code migrations with Claude Code — Anthropic