Bun이 LLM을 사용하여 9일 만에 Zig에서 Rust로 스스로를 재작성했습니다. 이는 당신을 두렵게 만들어야 합니다.

주요 런타임(runtime)이 완전히 다른 언어로 기계 번역되어 2주도 채 되지 않아 병합되었습니다. 다시 한번 천천히 말씀드리겠습니다.

커뮤니티에서 진지한 관계로 고려하고 있는 JavaScript 런타임인 Bun이 Zig에서 Rust로의 자체 재작성을 완료했습니다. 이 재작성은 대부분 LLM 모델에 의해 구성되었습니다. 이 과정은 약 9일 동안 지속되었습니다. 해당 풀 리퀘스트(Pull Request)에는 100만 라인(LoC) 이상의 Rust 코드가 포함되어 있었습니다.

이것이 얼마나 놀라운 일인지 모든 사람이 깨닫고 있다고 생각하지 않습니다.

이것은 재작성이 아닙니다. 번역입니다.

소프트웨어를 재작성(Rewriting)하는 것과 번역(Translating)하는 것은 완전히 다른 영역입니다. 전자는 인간이 아키텍처(architecture)를 다시 생각하고, 오래된 실수를 수정하며, 필연적으로 새로운 언어에서 새롭고 다른 실수를 저지르는 과정을 포함합니다. 번역은 코드를 기계에 밀어 넣고 결과물이 동등하기를 바라는 것을 의미합니다.

유지 관리자(maintainers) 본인들 외에 누가 이 새로운 코드베이스의 대부분을 이해할 가능성이 있을까요? 그들이 직접 손으로 작성하지 않았다는 점을 고려하면 말입니다. 이것은 수사적인 질문이 아닙니다. 이것이 유일하게 중요한 질문입니다.

아무도 작성하지 않은 백만 줄의 코드

LLM이 생성한 백만 줄의 Rust 코드를 코드 리뷰(code review)하는 시나리오를 상상해 보십시오. 당신은 누군가가 추론을 통해 도출한 로직을 검토하는 것이 아닙니다. 당신은 그저 '합리적으로 보이는' 결과물을 검토하고 있는 것입니다. 이것이 바로 LLM이 악명 높은 정확한 실패 모드(failure mode)입니다.

이 상황에서 저를 가장 걱정하게 만드는 점은 다음과 같습니다:

→ LLM은 추론 엔진(reasoning engines)이 아니라 자신감 넘치는 패턴 매처(pattern matchers)입니다. 이들은 Zig의 관용구(idioms)를 Rust로 번역할 것이며, 이는 컴파일은 되지만 압박 상황에서만 드러나는 방식으로 Rust의 소유권 모델(ownership model)을 미묘하게 위반할 수 있습니다.

→ 번역이 깨지는 지점은 엣지 케이스(Edge cases)입니다. 해피 패스(happy path)는 잘 번역됩니다. 하지만 Zig에서 찾는 데 6개월이 걸렸던 기묘한 동시성 버그(concurrency bug)는요? LLM은 그것이 존재하는지조차 모릅니다.

→ 약 9일이라는 시간은 약 9일간의 테스트를 의미합니다. 당신의 프로덕션(production) JavaScript를 실행하고자 하는 런타임에 있어서 말이죠. 😬

기술 부채 세탁 (Tech Debt Laundering)

제가 계속해서 되새기게 되는 문구는 이것입니다: 기술 부채 세탁 (tech debt laundering).

기존에는 알려진 특이점(quirks), 알려진 부채, 그리고 기여자들 사이의 명확한 소유권이 있는 Zig 코드베이스를 가지고 있었습니다. 하지만 이제는 알려지지 않은 특이점, 숨겨진 부채, 그리고 조직적 지식(institutional knowledge)이 거의 제로에 가까운 Rust 코드베이스를 갖게 되었습니다. 부채는 사라지지 않았습니다. 그저 새로운 언어와 깨끗한 git 히스토리로 옷을 갈아입었을 뿐입니다.

기존 코드베이스는 실전에서 검증(battle-tested)되었습니다. 새로운 코드베이스는 실전에서 번역(battle-translated)되었습니다. 이 둘은 결코 같은 것이 아닙니다.

이것이 생태계 전체를 걱정시켜야 하는 이유

Bun은 단순히 누군가가 우연히 사용하는 또 하나의 재미있는 프로젝트가 아닙니다. 어떤 이들은 실제로 비즈니스를 위해 Bun에 의존하고 있습니다. 어떤 기업들은 자신들의 전체 기술 인프라를 Bun에 걸었습니다. 그리고 해당 인프라의 핵심은 이제 공학적으로 설계(engineered)되었다기보다, 거의 생성(generated)된 것에 가까운 코드 더미가 되었습니다.

저는 코드베이스에 AI를 사용하는 것을 반대하지 않습니다. 저도 매일 LLM을 사용합니다. 하지만 제가 세심하게 검토할 유틸리티 함수(utility function)를 생성하기 위해 LLM을 사용하는 것과, 수천 명의 개발자에게 배포할 완전한 런타임(runtime)을 번역하기 위해 LLM을 사용하는 것 사이에는 분명한 차이가 있습니다.

진짜 문제는 속도입니다. 9일이라는 시간은 백만 줄 규모의 시스템 코드베이스에 필요한 철저하고 적대적인 검토(adversarial reviews)를 수행하기에는 턱없이 부족합니다. 그 시간은