2주, 25,000줄, 회귀 0건—숫자가 말하는 것
브라우저 엔진을 밑바닥부터 새로 만드는 오픈소스 프로젝트 Ladybird가 JavaScript 엔진 LibJS를 C++에서 Rust로 포팅했습니다. 기간은 약 2주, 결과물은 25,000줄의 Rust 코드, 그리고 회귀 테스트 0건. 수개월이 걸릴 작업을 Claude Code와 OpenAI Codex를 활용해 극적으로 단축한 사례입니다(출처: geeknews). 저는 이 숫자보다 그 숫자를 만들어 낸 팀 운영법이 훨씬 중요하다고 봅니다.
'자동 생성'이 아니라 '인간 지휘형 번역'이었다
흥미로운 건, Ladybird 팀이 AI에게 "알아서 포팅해 줘"라고 던진 게 아니라는 점입니다. 핵심 팀이 포팅 순서와 코드 구조를 직접 결정하고, 수백 개의 작은 프롬프트로 세밀하게 지시하는 방식을 택했습니다. 생성 후에는 다양한 모델을 교차 투입해 코드 검증과 오류 탐지까지 수행했고요.
Claude Code한테 물어보니까 한 번에 완벽한 Rust가 나오는 게 아닙니다. AI가 생성해 준 걸 기반으로 우리가 다듬는 거죠. 이 사례가 보여주는 건 AI는 '자율 코더'가 아니라 '증폭기(Amplifier)'로 쓸 때 가장 강력하다는 점입니다.
성공의 열쇠: 바이트 단위 동일성이라는 검증 기준
Hacker News 댓글에서도 가장 많이 칭찬받은 부분은 포팅 전략 자체였습니다. Ladybird 팀은 "C++ 파이프라인과 Rust 파이프라인의 출력이 바이트 단위로 동일해야 한다"는 제약을 처음부터 걸었습니다. AST, 바이트코드, 심지어 레지스터 할당 패턴까지 그대로 모방한 뒤, 두 파이프라인을 동시에 돌리는 lockstep 테스트로 웹 브라우징 중 결과 일치를 실시간 검증했습니다.
이게 왜 중요하냐면, 많은 리라이트가 실패하는 이유가 포팅 중에 '이왕 하는 김에 개선하자'는 유혹에 빠지기 때문입니다. Ladybird는 기능 변경 제로, 동작 동일성 100%라는 원칙을 세워 유령 버그를 원천 차단했습니다. AI로 리뷰 받아보니까 이런 게 나오더라고요—가 아니라, 테스트 스위트가 모든 걸 잡아주는 구조를 먼저 깔아놓은 겁니다.
AI-First 팀이 이 사례에서 가져가야 할 세 가지
기획 단계부터 AI를 끼면 훨씬 효율적이라는 건 맞지만, Ladybird 사례는 '어떻게 끼느냐'에 대한 구체적 답을 줍니다.
첫째, 검증 기준을 먼저 세워라. AI가 생성한 코드의 품질은 결국 테스트가 보증합니다. Ladybird의 test262 기반 커버리지와 lockstep 비교처럼, AI 코드 대량 투입 전에 '무엇이 맞는 결과인지'를 정의하는 게 팀 리드의 첫 번째 일입니다.
둘째, 프롬프트 설계를 아키텍처 설계처럼 다뤄라. 수백 개의 프롬프트를 체계적으로 작성하고 순서를 관리하는 건, 사실상 포팅 아키텍처를 짜는 것과 같습니다. Kiro 같은 도구가 Spec(요구사항)→Design(설계)→Tasks(작업)로 이어지는 연결 구조를 제공하는 이유도 여기에 있습니다(출처: dev.to). 프롬프트도 '명세'입니다.
셋째, '나중에 정리'를 일정에 넣어라. Ladybird 팀도 인정했듯, 현재 Rust 코드는 C++을 그대로 번역한 비정형(unidiomatic) 상태입니다. C++ 파이프라인을 퇴역시킬 시점에 Rust답게 정리하겠다는 계획이 명시되어 있죠. AI가 생성한 코드의 기술 부채를 '의도적으로 수용'하되, 정리 시점을 로드맵에 박아두는 것—이게 현실적인 AI-First 전략입니다.
코드가 범용재라면, 팀의 가치는 어디에?
브라질 개발자 Ricardo Mello가 dev.to에 쓴 글의 제목이 인상적입니다. "코드는 AI 이후에 범용재(commodity)가 된 게 아니다. 원래 그랬다." 소금이 싸졌다고 요리가 범용재가 되지 않듯, 코드 생성 비용이 0에 수렴해도 무엇을 만들지, 왜 만드는지, 프로덕션에서 어떻게 살아남게 할지를 결정하는 역량은 오히려 더 비싸집니다.
Ladybird 사례가 정확히 이걸 보여줍니다. AI가 25,000줄을 찍어냈지만, 포팅 대상 선정(lexer→parser→AST 순서), 검증 전략 설계(바이트 단위 동일성), 병행 운영 계획(C++/Rust 공존 경계 관리)은 전부 사람의 판단이었습니다.
이거 자동화하면 우리가 더 중요한 일에 집중할 수 있어요
팀원들에게 AI-First 마인드를 심어줘야 한다고 늘 말하지만, Ladybird 사례를 보면서 한 가지를 더 확신하게 됐습니다. AI-First는 'AI가 다 해주는 것'이 아니라 'AI가 코드 생산을 맡는 동안, 팀은 검증 기준 설계·아키텍처 판단·기술 부채 관리에 집중하는 것'입니다.
2주 만에 25,000줄을 포팅한 건 AI의 성과입니다. 하지만 회귀 0건을 달성한 건 팀의 성과입니다. AI 시대에 개발자의 진짜 가치는 코드를 짜는 손이 아니라, 코드가 맞는지 판단하는 눈에 있습니다. 그 눈을 팀 전체에 장착시키는 게, 지금 우리가 해야 할 리빌딩입니다.