개발이야기

코드를 고치지 말고, 코드를 만든 시스템을 고쳐야 합니다

Claude Code를 이용해 대규모 코드베이스를 다른 언어로 마이그레이션한 사례

2026.08.05 | 조회 29 |
0
|

Anthropic에서 흥미로운 글을 하나 공개했습니다.

Claude Code를 이용해 대규모 코드베이스를 다른 언어로 마이그레이션한 사례인데요.

Bun은 Zig에서 Rust로 옮기는 과정에서 2주도 안 되는 기간에 약 100만 줄의 코드를 만들었고, Anthropic 내부에서는 Python 프로젝트를 주말 동안 16만5천 줄의 TypeScript로 전환한 사례도 소개합니다.

그런데 저는 이 글에서“AI가 이제 100만 줄도 코딩할 수 있다”는 사실보다 다른 문장이 더 눈에 들어왔습니다.

코드를 고치지 말고, 그 코드를 만들어낸 프로세스를 고쳐라.

이 한 문장이 앞으로 AI와 일하는 방식을 꽤 잘 설명한다고 생각합니다.


AI에게 일을 많이 시키는 것이 핵심은 아닙니다

대규모 마이그레이션에서 가장 먼저 한 일은 코드를 작성하는 것이 아니었습니다.

먼저 Judge, 즉 결과가 맞는지를 판단할 수 있는 기준부터 만들었습니다.

기존 코드와 새 코드를 같은 조건에서 실행하고,

테스트를 통과하는지,동일한 입력에 같은 결과를 내는지,컴파일되는지,실제 사용 시나리오에서 동일하게 동작하는지를 자동으로 확인할 수 있게 만든 겁니다.

그다음에야 Rulebook을 만들고, 의존성을 분석하고, 여러 에이전트에게 작업을 나눴습니다. Anthropic은 강한 Judge가 없으면 프로젝트의 종료 조건도, 성공 여부를 판단할 방법도 없다고 설명합니다.

AI를 잘 쓰는 조직과 그렇지 않은 조직의 차이는 여기서 벌어질 것 같습니다.

많은 조직이 AI를 도입하면서 가장 먼저 묻습니다.

“어떤 모델을 써야 하지?”

하지만 실제로 더 어려운 질문은 이것입니다.

“AI가 만든 결과가 맞다는 것을 어떻게 판단할 것인가?”


같은 오류를 100번 고치는 대신 규칙 하나를 고칩니다

Anthropic의 방식에서 특히 인상적인 부분이 있습니다.

여러 에이전트가 마이그레이션을 진행하다 같은 오류가 반복해서 발견되면 해당 파일들을 하나씩 수정하지 않습니다.

대신 Rulebook을 수정합니다.

그리고 영향을 받은 코드를 다시 생성합니다.

즉,

문제 발생→ 코드 수정→ 또 다른 곳에서 같은 문제 발생

이 구조가 아니라,

문제 패턴 발견→ 규칙 수정→ 다시 생성→ 자동 검증

이라는 루프를 만드는 겁니다.

실제로 Anthropic은 구현, 리뷰, 수정의 멀티에이전트 구조를 사용하고, 반복되는 오류가 발견되면 개별 코드를 손대는 대신 Rulebook을 업데이트해 영향을 받은 작업을 다시 생성하는 방식을 사용했습니다.

저는 이 부분이 단순한 코딩 기법이라기보다 AI 시대의 업무 자동화 원칙에 가깝다고 봅니다.

AI가 수백 개의 작업을 동시에 처리할 수 있게 되면 사람이 결과 하나하나를 검수하는 방식은 금방 한계에 도달합니다.

그래서 중요한 것은AI에게 일을 시키는 능력이 아니라,

반복되는 오류를 발견하고, 그것을 다시 시스템의 규칙으로 올려보내는 구조를 만드는 능력입니다.


사람의 역할도 달라지고 있습니다

예전 개발자는 직접 코드를 많이 작성하는 사람이었습니다.

AI Coding Agent가 등장한 뒤에는 조금 달라졌습니다.

프롬프트를 잘 작성하고,Agent에게 작업을 나누고,결과를 리뷰하는 능력이 중요해졌습니다.

그런데 이 글을 보면 한 단계 더 이동하고 있습니다.

앞으로 중요한 사람은 AI에게 직접 모든 일을 지시하는 사람도 아닐 수 있습니다.

무엇이 좋은 결과인지 정의하고,어떤 규칙으로 일해야 하는지 만들고,실패했을 때 시스템이 스스로 다음 작업을 만들어내도록 설계하는 사람.

쉽게 말하면 작업자가 아니라 작업 시스템을 설계하는 사람입니다.

Compiler가 오류를 만들면 그것이 다음 Agent의 작업이 되고,

Smoke Test에서 Crash가 발생하면 원인별 작업 큐가 만들어지고,

같은 실패가 반복되면 Rulebook이 수정됩니다.

Anthropic의 표현대로라면 작업 큐가 스스로 만들어지는 구조입니다.

사람은 그 위에서

규칙을 만들고,평가 기준을 설계하고,예외를 정의하고,시스템 전체가 올바른 방향으로 움직이는지를 봅니다.


AI Agent의 경쟁력은 모델보다 시스템에서 나옵니다

좋은 모델을 쓰는 것은 분명 중요합니다.

하지만 모델만 바꾼다고 안정적인 Agent 시스템이 만들어지는 것은 아닙니다.

오히려 앞으로 중요한 것은 이런 구조일 겁니다.

Rulebook → Agent → Review → Test → Failure → Rulebook

그리고 이 루프가 사람의 개입 없이 얼마나 많이 돌 수 있는가.

Anthropic도 모든 작업에 가장 큰 모델을 사용하지 않았습니다.

구현처럼 병렬화하기 쉬운 작업은 상대적으로 작은 모델에 맡기고, 중요한 판단이나 리뷰에는 더 강한 모델을 배치했습니다.

결국 Agent 시스템의 성능은 단순히

“어떤 AI 모델을 쓰는가”

보다

어떤 일을 맡기고,무엇으로 검증하고,실패를 어떻게 다시 시스템에 학습시키는가

에서 결정됩니다.


제가 이 글에서 가장 중요하게 본 것은 100만 줄의 코드가 아닙니다.

AI가 일을 하는 시대에는 사람이 결과를 만드는 것보다, 좋은 결과가 반복해서 나오는 구조를 만드는 능력이 더 중요해지고 있다는 점입니다.

개발뿐 아니라 운영, 데이터 분석, 고객지원, 리서치도 비슷해질 겁니다.

AI에게 일을 하나씩 시키는 단계에서 벗어나,

판단 기준을 만들고,실패를 자동으로 수집하고,규칙을 업데이트하고,다시 실행하는 구조를 만드는 것.

앞으로 AI를 잘 활용하는 팀의 경쟁력은프롬프트의 개수가 아니라 이 루프를 얼마나 잘 설계했는가에서 드러날 것 같습니다.

[원문] https://claude.com/blog/ai-code-migration

 

다가올 뉴스레터가 궁금하신가요?

지금 구독해서 새로운 레터를 받아보세요

✉️

이번 뉴스레터 어떠셨나요?

Tomorrow Tech 님에게 ☕️ 커피와 ✉️ 쪽지를 보내보세요!

댓글

의견을 남겨주세요

확인
의견이 있으신가요? 제일 먼저 댓글을 달아보세요 !

다른 뉴스레터

© 2026 Tomorrow Tech

통찰력 있는 최신 기술 트렌드와 깊이 있는 분석.

메일리 로고

도움말 오류 및 기능 관련 제보

서비스 이용 문의admin@team.maily.so 채팅으로 문의하기

메일리 사업자 정보

메일리 (대표자: 이한결) | 사업자번호: 717-47-00705 | 서울특별시 송파구 위례광장로 199, 5층 501-2-31호

이용약관 | 개인정보처리방침 | 정기결제 이용약관 | 라이선스