AI 코드 마이그레이션 특집: 다년짜리 이식을 2주로 — 컴파일러의 꿈부터 100만 줄 Rust 재작성까지

들어가며: 100만 줄을 11일 만에

2026년 5월, 개발자 커뮤니티에 믿기 힘든 소식 하나가 올라왔다.

자바스크립트 런타임 Bun이 언어를 통째로 갈아탔다. Zig로 짜여 있던 약 60만 줄의 코드베이스를, Rust로 100만 줄 넘게 다시 썼다. 문제는 방법이었다. 사람이 한 줄 한 줄 옮긴 게 아니었다. 64개의 Claude 에이전트가 4개의 워크트리에서 병렬로 돌며, 11일 동안 6,502번을 커밋했다. 최고 출력 속도는 분당 약 1,300줄. API 요금으로 환산하면 약 $165,000(약 2억 3천만 원)이 들었다.

숫자 하나만 더 얹어 보자. 이 정도 규모 — 50만 줄짜리 완전 재작성 — 을 사람 개발팀이 한다면 보통 1년이 걸린다. 그것도 성공했을 때 이야기다.

크게 보기

이게 바로 이 글의 주제, AI 코드 마이그레이션(AI code migration) 이다. Anthropic의 정의를 그대로 옮기면 이렇다.

"AI 코드 마이그레이션은 AI 에이전트를 사용해 프로덕션 코드베이스를 새로운 언어나 프레임워크로 이식하는 것이다. 파일을 손으로 번역하는 대신, 엔지니어는 마이그레이션 규칙과 검증 루프를 작성한다. 그러면 에이전트들이 번역하고, 컴파일하고, 테스트하며, 새 코드의 동작이 원본과 일치할 때까지 반복한다 — 다년짜리 프로젝트를 몇 주로 압축하면서."

핵심 단어 두 개를 기억하자. 규칙(rules) 과 루프(loop). 이 글 전체가 결국 이 두 단어의 이야기다.

TL;DR — 5초 요약

1. 코드 마이그레이션은 원래 '실패율 70%의 지옥'이었다. 다년·수백만 달러·중도 폐기가 기본값이었다.
2. 번역을 자동화하려는 꿈은 오래됐다. f2c 트랜스파일러(1980s) → 규칙 기반 → 신경망 번역 TransCoder(2020) → LLM 에이전트(2026).
3. 2026년에 갑자기 가능해진 이유는 마이그레이션이 AI에 유독 잘 맞는 4가지 구조를 갖고 있기 때문이다: 병렬화 가능, 명세가 이미 존재(레거시 코드), 검증이 자동(기존 테스트), 작업 큐가 스스로 채워짐(에러가 곧 할 일).
4. 방법론의 핵심은 "코드를 고치지 말고, 코드를 만든 루프를 고쳐라" 다. 개별 파일이 아니라 규칙집을 고치고 배치를 재생성한다.
5. 하지만 논쟁도 뜨겁다. "리뷰 안 된 100만 줄이 정말 괜찮은가?"라는 Zig 창시자의 비판을 이 글은 회피하지 않는다.

제1장: 왜 코드 마이그레이션은 늘 '지옥'이었나

AI 이야기를 하기 전에, 왜 이게 어려운 문제였는지부터 알아야 한다. 그래야 무엇이 바뀌었는지 실감할 수 있다.

줄당 가격표가 붙은 작업

레거시 시스템을 새 언어로 옮기는 일에는 업계 표준 견적이 있다. 코드 한 줄당 $1.50 ~ 4.00.</strong> 50만 줄이면 그것만으로 최소 75만 달러에서 200만 달러다. 여기에 요구사항 분석, 병렬 운영, 회귀 테스트, 인력의 기회비용까지 더하면 <strong>\3~4M(수십억 원) 짜리 프로젝트가 된다.

그런데 돈보다 무서운 건 실패율이다.

Gartner의 2024년 조사에 따르면 레거시 재작성 프로젝트의 약 70%가 실패하거나 원래 일정을 크게 초과한다. 데이터 마이그레이션으로 좁히면 실패·예산초과 비율이 83% 까지 올라간다.

크게 보기

실제로 무너진 프로젝트들

숫자는 추상적이니, 실제 사례를 보자.

이것이 마이그레이션의 근본 딜레마였다. "바꾸고 싶다" 와 "바꾸다 죽는다" 사이의 협곡. 그래서 대부분의 조직은 세 번째 선택지를 골랐다 — 그냥 안 바꾼다. 20년 된 COBOL이 여전히 전 세계 금융 거래의 상당수를 처리하는 이유, 아무도 못 건드리는 '레거시 괴물'이 회사마다 하나씩 있는 이유가 바로 이것이다.

핵심: 마이그레이션의 진짜 비용은 '번역'이 아니라 '검증' 이었다. 옮기는 건 지루할 뿐이지만, 옮긴 게 원본과 똑같이 동작하는지 확인하는 일 은 사람의 시간을 무한히 잡아먹는다. 이 점을 기억해 두자 — 뒤에서 AI가 정확히 이 지점을 공략한다.

제2장: 코드를 번역하려는 오래된 꿈

"프로그램을 자동으로 다른 언어로 번역한다"는 발상은 LLM이 등장하기 수십 년 전부터 있었다. 그 역사를 알면, 2026년의 도약이 왜 진짜 도약인지 보인다.

크게 보기

1세대: 트랜스파일러 — 문법을 갈아 끼우다

가장 오래된 접근은 소스 대 소스 컴파일러(source-to-source compiler), 흔히 트랜스파일러(transpiler) 다. 대표적으로 1980년대의 f2c(Fortran을 C로 변환), 그리고 훗날의 2to3(Python 2→3), Babel(최신 JS→구형 JS), TypeScript 컴파일러가 여기 속한다.

원리는 명확하다. 문법 트리(AST)를 파싱해서, 규칙에 따라 다른 언어의 문법 트리로 다시 조립한다. 결정론적이고 정확하다. 하지만 결정적 한계가 있었다.

• 관용구(idiom)를 못 옮긴다. 문법은 바뀌지만 "그 언어답게" 는 안 된다. f2c가 뱉은 C 코드는 "Fortran을 C 문법으로 쓴 것"이지 사람이 쓸 법한 C가 아니었다.
• 패러다임 차이 앞에서 무너진다. 명령형→함수형, 수동 메모리→GC처럼 사고방식 자체가 다르면 규칙으로 다 담을 수 없다.
• 규칙을 사람이 다 짜야 한다. 언어 쌍마다 방대한 변환 규칙을 손으로 유지보수해야 했다.

2세대: 신경망이 코드를 '번역'하다 — TransCoder (2020)

2020년, Facebook AI Research(FAIR)가 NeurIPS에서 발표한 논문 《Unsupervised Translation of Programming Languages》 가 판을 흔들었다. 이 모델이 바로 TransCoder 다.

발상이 대담했다. "프로그래밍 언어 번역을, 자연어 번역처럼 다루면 어떨까?" 영어를 프랑스어로 옮기듯, C++를 Java로, Java를 Python으로 옮기는 것이다. 그것도 병렬 코퍼스(짝지어진 번역 예시) 없이 비지도(unsupervised)로.

TransCoder는 GitHub의 280만 개 오픈소스 프로젝트로 학습됐고, C++·Java·Python 사이를 오가며 당시의 규칙 기반 상용 변환기를 앞질렀다. 연구팀은 852개의 병렬 함수와 단위 테스트로 구성된 검증 세트까지 공개했다.

의의: TransCoder는 "코드 번역은 통계적으로 학습 가능한 문제"임을 증명했다. 하지만 여전히 함수 단위의 번역이었고, 컴파일되는지, 실제로 돌아가는지 를 스스로 책임지지는 못했다. 번역가는 있었지만, 자기 번역을 컴파일하고 테스트하고 고치는 '엔지니어' 는 아직 없었다.

2.5세대: 산업이 뛰어들다 — IBM의 COBOL 현대화

2023년, IBM은 watsonx Code Assistant for Z 를 내놓으며 가장 값비싼 레거시 문제, COBOL→Java 를 정면으로 겨눴다. 생성형 AI로 COBOL을 객체지향 Java로 옮기되 의미적 등가(semantic equivalence) 를 유지하고, 자동 검증으로 변환 결과가 동일한 값을 내는지 확인하는 접근이었다.

효과는 실측으로도 나왔다. 한 조직은 복잡한 애플리케이션을 이해하는 데 걸리는 시간을 24시간에서 약 5시간으로(79% 단축) 줄였고, 한 글로벌 물류 기업은 COBOL→Java 전환에서 생산성 60% 향상 을 보고했다. IBM은 이 도구를 "메인프레임의 로제타석"이라 불렀다.

여기까지가 LLM 에이전트 직전 의 풍경이다. 번역 품질은 좋아졌고, 검증도 붙기 시작했다. 하지만 오케스트레이션 — 수천 개 파일을 병렬로 번역하고, 컴파일 에러를 스스로 작업 목록으로 삼아, 실패가 사라질 때까지 도는 자율 루프 — 은 아직 없었다. 그게 3세대의 이야기다.

제3장: 무엇이 바뀌었나 — "파일을 고치지 말고, 루프를 고쳐라"

2026년의 도약을 한 문장으로 요약하면 이렇다.

"Don't fix the code. Fix the process (loop) that produced the code." 코드를 고치지 마라. 그 코드를 만들어 낸 과정(루프)을 고쳐라.

크게 보기

이게 왜 혁명적인가? 전통적 마이그레이션에서 개발자는 파일 하나를 옮기고, 안 되면 그 파일을 고치고, 또 안 되면 또 고쳤다. 5만 개 파일이면 5만 번의 개별 씨름이다. 에이전트 마이그레이션은 다르게 본다. 같은 유형의 에러가 200개 파일에서 반복되면, 200개를 각각 고치는 게 아니라 '규칙집'의 규칙 하나를 고치고 그 200개를 통째로 재생성 한다. 개별 증상이 아니라 원인(규칙) 을 친다.

AI가 마이그레이션에 유독 강한 4가지 구조

마이그레이션은 사실 AI 에이전트를 위해 설계된 것처럼 생긴 문제다. Anthropic이 짚은 네 가지 구조적 이유:

일반적인 코딩은 이 넷 중 어느 것도 공짜로 주어지지 않는다. "무엇을 만들지" 부터 애매하고, "제대로 됐는지" 판단도 주관적이다. 하지만 마이그레이션에서는 정답지(원본)와 채점기(테스트)가 처음부터 손에 있다. 그래서 마이그레이션은 "AI가 처음으로 사람보다 확실히 잘하는, 규모 있는 실전 소프트웨어 작업"이 됐다.

비유: 백지에 소설을 쓰는 건 어렵다(일반 코딩). 하지만 이미 완성된 한국어 소설을 영어로 옮기는 건, 원문이라는 정답과 "뜻이 같은가"라는 채점 기준이 있다(마이그레이션). AI는 후자에서 압도적으로 강하다.

제4장: 6단계 마이그레이션 루프 (인터랙티브)

이제 방법론의 심장으로 들어가자. Anthropic이 실제 프로젝트에서 정리한 절차는 판사를 세우는 전제 단계 + 6개의 단계 로 이뤄진다. 앞부분(0~2)은 사람의 머리 를 갈아 넣는 준비 단계이고, 뒷부분(4~6)은 거의 동일한 구조의 자율 루프 다.

아래 인터랙티브로 각 단계에서 누가, 무엇을 입력받아, 무엇을 내놓는지 를 직접 눌러 가며 확인해 보자.

루프의 진짜 모양: '증상'이 아니라 '원인'을 친다

4~6단계가 왜 전부 '루프'인지가 이 방법론의 핵심이다. 세 단계는 똑같은 골격 을 공유한다. 다만 사람의 판단이 개입하는 정도만 줄어든다.

이 구조 덕분에 마이그레이션은 재개 가능(resumable) 해진다. 작업 큐를 매번 디스크에서 다시 만들기 때문에(예: "이 출력 파일이 아직 없네? 그럼 할 일") 중간에 멈춰도 이어서 돌릴 수 있다. 사람이 상태를 들고 있을 필요가 없다.

적대적 리뷰(adversarial review): 뒷단계에서 실패 묶음을 검토할 때, 여러 리뷰어 에이전트가 독립적으로 판단하고, 이견이 갈리면 제3의 에이전트가 판정 한다. 리뷰어 한 명의 편향에 끌려가지 않게 만드는 장치다. Mike Krieger의 Python→TS 이식에는 이런 적대적 리뷰가 3라운드 들어갔다.

제5장: 사례 A — Bun, Zig에서 Rust로 (패러다임 전환의 끝판왕)

이제 실제 사례다. 첫 번째는 이 글을 연 그 프로젝트, Bun의 Zig→Rust 이식 이다. Bun의 공동창업자이자 현 Anthropic 소속인 Jarred Sumner 가 이끌었다.

크게 보기

규모와 결과

토큰을 뜯어보면 규모가 실감 난다. 입력 약 59억 토큰 + 출력 약 6.9억 토큰 = 총 65.9억 토큰. Jarred는 약 50개의 동적 워크플로우를 짜서 돌렸고, 결국 64개 에이전트가 병렬로 작동했다.

왜 Zig→Rust가 '어려움'의 대명사인가

이 이식이 특별히 어려웠던 건 메모리 모델의 패러다임이 완전히 다르기 때문 이다.

Zig가 관대하게 넘어가던 순환 임포트를 Rust의 규칙에 맞추자, 수천 개의 모듈 에러가 한꺼번에 쏟아졌다. 이걸 파일마다 손으로 고쳤다면 프로젝트는 거기서 끝났을 것이다. 대신 규칙집을 고치고 배치를 재생성하는 루프로 흡수했다.

성과: 느려지지 않았다, 오히려

가장 중요한 질문 — "AI가 옮긴 코드, 실제로 좋은가?" 벤치마크 결과:

• 머지 전, Bun의 기존 전체 테스트 스위트(100만 개 이상의 테스트)를 통과 했다.
• 머지 후 발견된 회귀는 19건 — 모두 이후 수정됐다.
• 메모리는 벤치마크에서 6,745MB → 609MB로 약 91% 감소, 바이너리는 19% 작아졌고, 성능은 2~5% 개선됐다.

이 프로젝트가 성립한 진짜 이유는 "Zig가 나빠서"가 아니다. 만성적인 메모리 버그라는 명확한 병목 이 있었고, 그걸 Rust의 소유권 모델로 없앨 수 있다는 뚜렷한 보상 이 있었기 때문이다. (이 판단 기준은 제9장에서 다시 다룬다.)

제6장: 사례 B — Anthropic 내부, Python에서 TypeScript로 (주말 하나)

두 번째 사례는 결이 다르다. Anthropic Labs의 공동 리드 Mike Krieger(인스타그램 공동창업자이기도 하다)가 내부 도구 하나를 Python에서 TypeScript로 옮긴 이야기다.

크게 보기

규모와 결과

수백 개의 에이전트, 8개의 단계 관문(phase gate), 3라운드의 적대적 리뷰. 메인 이식 작업은 약 2,700만 토큰 을 썼다. 결과적으로 별도의 배포 파이프라인이 통째로 사라졌고, 빌드는 30분에서 2초로 줄었다.

Bun과 Anthropic 사례의 대비가 알려주는 것

두 사례를 나란히 놓으면, 이 방법론이 하나의 정답이 아니라 상황에 맞춰 변형되는 틀 임이 보인다.

Python의 동적 타이핑과 TypeScript의 필수 타입 계약은 근본적으로 다르다. 에이전트들은 이 간극을 명시적 인터페이스 정의를 만들어 메웠다 — 정확히 제4장 1단계의 '갭 목록'이 하는 일이다.

제7장: 그래서 얼마나 싸지고 빨라지나 (인터랙티브 계산기)

지금까지의 수치를 직접 만져 보자. 아래 계산기에서 코드 규모와 난이도 를 조절하면, 전통적 수작업 이식과 AI 에이전트 이식의 비용·기간·토큰 추정치를 비교할 수 있다. (Bun과 업계 공개 수치를 기반으로 한 선형 근사이며, 실제는 코드베이스마다 크게 다르다.)

이 계산기가 보여 주는 진짜 메시지는 "AI가 싸다"가 아니다. 경제성의 손익분기점이 이동했다 는 것이다. 예전에는 $3~4M·다년이라는 비용 때문에 "병목이 아무리 아파도 참는 게 남는 장사" 였다. 이제는 명확한 병목 하나만 있으면 마이그레이션이 '수지 맞는 투자' 가 된다. Bun의 메모리 버그, Anthropic의 30분 빌드가 바로 그 병목이었다.

제8장: 반론 — "리뷰 안 된 100만 줄, 정말 괜찮은가?"

여기까지만 쓰면 홍보 글이다. 하지만 이 기술에는 뜨거운 논쟁 이 따라붙었고, 그 논쟁을 빼면 정직하지 않다.

크게 보기

Bun의 Rust 재작성이 화제가 되자, Zig 언어의 창시자 Andrew Kelley 가 공개적으로 날을 세웠다. 그는 이 재작성을 두고 "리뷰되지 않은 slop(엉성한 결과물)" 이라 표현했고, 이렇게 물었다.

"100만 줄의 리뷰되지 않은 코드에서 버그를 잡아내는 게 정말 충분한가?"

Kelley의 비판은 몇 갈래로 나뉜다.

이 논쟁의 본질은 "기계적 검증(테스트·컴파일러)이 사람의 코드 리뷰를 어디까지 대체할 수 있는가" 다. 방법론 자체가 이미 답의 일부를 담고 있다 — 그래서 제4장의 판사(Judge) 와 적대적 리뷰 가 핵심 장치인 것이다. 검증을 기계적으로 만들수록(컴파일·diff·테스트를 심판으로) 이 비판의 사정거리는 줄어든다. 하지만 테스트가 없는 영역 은 여전히 사각지대로 남는다.

균형 잡힌 결론: AI 마이그레이션은 "테스트가 촘촘한 코드베이스" 에서 가장 강하다. 테스트 커버리지가 곧 이 방법론의 신뢰도 상한선이다. 판사가 부실하면, 아무리 많은 에이전트를 돌려도 "그럴듯하지만 틀린" 코드를 양산할 뿐이다. 이 방법을 쓰기 전에 물어야 할 첫 질문은 "우리 테스트는 심판 역할을 할 만큼 튼튼한가?" 이다.

제9장: 2026년, 이 기술의 자리 — 언제 하고, 언제 하지 말아야 하나

기술이 가능해졌다고 아무 때나 해야 하는 건 아니다. 판단 이 남는다.

크게 보기

실무 체크리스트 — 가이드를 맹종하지 말 것

Anthropic이 스스로 강조하는 원칙들을, 시작하기 전 점검표로 옮기면:

더 큰 그림: '마이그레이션'을 넘어서

이 방법론이 흥미로운 진짜 이유는, 마이그레이션이 "AI가 대규모 소프트웨어를 자율적으로 다루는 법"의 리허설 이기 때문이다. 정답지(원본)와 채점기(테스트)가 명확한 이 문제에서 확립된 패턴 — 병렬 에이전트 + 기계적 검증 루프 + 규칙집 기반 상류 수정 — 은 대규모 리팩터링, 프레임워크 업그레이드, 심지어 대규모 버그 수정으로 번져 가고 있다. 2026년의 진짜 뉴스는 "Bun이 Rust가 됐다"가 아니라, "이제 사람이 코드를 고치는 대신, 코드를 만드는 루프를 설계한다" 는 역할의 전환이다.

마무리: 번역가에서 루프 설계자로

코드 번역의 꿈은 40년 묵었다. f2c는 문법을 갈아 끼웠고, TransCoder는 '그 언어답게' 번역하는 법을 배웠고, watsonx는 검증을 붙였다. 그리고 2026년, 마지막 조각이 맞춰졌다 — 번역하고, 컴파일하고, 테스트하고, 실패가 사라질 때까지 스스로 도는 오케스트레이션.

기억할 것은 결국 세 가지다.

1. 마이그레이션의 진짜 비용은 번역이 아니라 검증이었고, AI는 정확히 그 검증 루프를 자동화했다.
2. "코드를 고치지 말고, 코드를 만든 루프를 고쳐라." 개별 증상이 아니라 규칙집(원인)을 친다.
3. 판사가 전부다. 테스트가 튼튼한 만큼만 이 방법을 믿을 수 있다. Kelley의 비판이 겨눈 곳도 바로 여기다.

그래서 엔지니어의 일이 사라지는 게 아니다. 바뀐다. 파일을 한 줄씩 옮기는 번역가에서, 규칙을 쓰고 판사를 세우고 루프를 설계하는 오케스트레이터로. 값을 매길 수 없던 재작성이 수지 맞는 투자가 되는 순간, 그동안 아무도 못 건드리던 '레거시 괴물'들의 목록이 다시 열린다.

코어닷투데이의 관점

우리는 기업의 레거시 시스템 현대화와 AI 자동화 파이프라인 설계를 함께 고민합니다. 이 글에서 반복된 메시지 — "먼저 판사(테스트·검증)를 세우고, 사람의 노력을 규칙과 루프 설계에 몰아넣어라" — 는 마이그레이션뿐 아니라 모든 AI 도입의 출발점입니다. "우리 코드베이스도 이렇게 옮길 수 있을까?", "어디가 진짜 병목이고, 테스트는 심판이 될 만큼 튼튼한가?" 를 진단하는 일부터, 코어닷투데이(core.today)가 함께합니다.

📩 레거시 현대화·AI 파이프라인 상담: core.today

참고 자료

• Anthropic, How Anthropic runs large-scale code migrations with Claude Code (claude.com/blog/ai-code-migration)
• Lachaux et al., Unsupervised Translation of Programming Languages (TransCoder), NeurIPS 2020
• IBM Research, watsonx Code Assistant for Z: the Rosetta Stone for mainframes
• The Register, Anthropic's Bun Rust rewrite merged at speed of AI (2026)
• Andrew Kelley, My Thoughts on the Bun Rust Rewrite (andrewkelley.me)
• Gartner (2024) · Standish Chaos Report (2025) — 레거시 재작성/데이터 마이그레이션 실패율