# Ladybird가 Rust를 채택, AI의 도움으로 전환 가속 > Clean Markdown view of GeekNews topic #26941. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26941](https://news.hada.io/topic?id=26941) - GeekNews Markdown: [https://news.hada.io/topic/26941.md](https://news.hada.io/topic/26941.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-24T09:45:32+09:00 - Updated: 2026-02-24T09:45:32+09:00 - Original source: [ladybird.org](https://ladybird.org/posts/adopting-rust/) - Points: 5 - Comments: 1 ## Topic Body - Ladybird 브라우저 프로젝트가 **C++을 대체할 메모리 안전 언어로 Rust를 채택**하고, 전환 과정에 **AI 도구를 활용**함 - 기존에 Swift를 검토했으나 **C++ 상호운용성과 플랫폼 제약**으로 한계를 느껴 Rust로 방향을 전환함 - 첫 번째 포팅 대상은 **JavaScript 엔진 LibJS**로, **Claude Code**와 **Codex**를 이용해 수백 개의 프롬프트로 수동 지휘된 번역을 수행함 - 약 **2주 만에 2만5천 줄의 Rust 코드**를 완성했으며, **출력·성능 모두 C++ 버전과 완전히 동일**함을 검증함 - 프로젝트는 당분간 **C++과 Rust 병행 개발 체제**를 유지하며, 장기적으로 안전성과 유지보수성을 강화할 계획임 --- ### Rust 채택 배경 - Ladybird는 **C++을 대체할 메모리 안전 언어**를 찾기 위해 여러 언어를 검토함 - Swift는 C++과의 상호운용성 부족 및 Apple 생태계 외 플랫폼 지원 한계로 제외됨 - Rust는 **시스템 프로그래밍 생태계가 성숙**하고, **기여자 다수가 이미 익숙한 언어**로 평가됨 - 2024년에는 Rust의 **C++식 OOP 부적합성**으로 채택을 보류했으나, 이후 **안전성과 생태계 성숙도**를 이유로 재도입 결정 - Firefox와 Chromium이 이미 Rust를 도입한 사례를 참고해 **Ladybird에도 적합하다고 판단**함 ### LibJS 포팅 과정 - 첫 번째 전환 대상은 **Ladybird의 JavaScript 엔진 LibJS** - **lexer, parser, AST, bytecode generator** 등 독립적 구성요소와 **test262 기반 테스트 커버리지**로 시작점으로 적합함 - 포팅에는 **Claude Code**와 **OpenAI Codex**를 사용 - 자동 생성이 아닌 **인간 주도형 번역**으로, 포팅 순서와 코드 구조를 직접 결정 - 수백 개의 프롬프트로 세밀히 지시하며, 이후 **다양한 모델을 통한 코드 검증 및 오류 탐지** 수행 ### 결과 및 검증 - 목표는 **C++과 Rust 파이프라인의 출력이 바이트 단위로 동일**한 결과를 내는 것 - 약 **25,000줄의 Rust 코드**를 2주 만에 완성, 수개월 걸릴 작업을 단축함 - **AST와 바이트코드가 완전히 동일**하며, **테스트 및 JS 벤치마크에서 성능 저하 없음** - **C++과 Rust 파이프라인을 동시에 실행하는 lockstep 테스트**로 웹 탐색 중 결과 일치 여부를 검증함 - 현재 코드는 **C++에서 번역된 형태를 유지**하며, **레지스터 할당 패턴까지 동일하게 모방** - 이는 **C++ 파이프라인과의 호환성 확보**가 최우선이기 때문 - 향후 C++ 파이프라인을 폐기할 시점에 **Rust 코드의 단순화 및 정리** 예정 ### 향후 계획 - Rust 전환은 **프로젝트의 주력 개발 방향이 아닌 병행 작업**으로 진행 - **C++과 Rust 코드가 공존**하며, 명확한 상호운용 경계를 유지함 - 포팅 순서와 범위는 **핵심 팀이 관리**, 외부 기여자는 사전 조율 필요 - 장기적으로 **안전성과 유지보수성 향상**을 목표로 점진적 전환 추진 - 결정이 논란이 될 수 있음을 인정하면서도, **Ladybird의 미래를 위한 올바른 선택**으로 평가함 ## Comments ### Comment 51749 - Author: neo - Created: 2026-02-24T09:45:32+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47120899) - 이 프로젝트에서 **바이트 단위로 동일한 출력**을 요구한 점이 가장 똑똑한 부분임 덕분에 기존 파이프라인과 새 파이프라인을 나란히 돌려서 diff를 비교할 수 있고, 번역 중 생긴 버그를 즉시 잡을 수 있음 많은 리라이트가 실패하는 이유는 사람들이 포팅 중에 “개선”을 시도하다가 구버전, 신버전, 혹은 단순한 동작 차이에서 생긴 **유령 버그**를 쫓기 때문임 Rust로의 C++ 번역 버전이 처음엔 어색해 보여도 괜찮음. 나중에 C++ 쪽을 완전히 퇴역시키면 점진적으로 더 **idiomatic**하게 바꿀 수 있음 - 포팅은 많은 걸 개선할 좋은 시점이지만, 새로운 기능을 추가할 시점은 아님 출력이 동일하게 유지되는 한에서 **리팩터링, 효율화, 문서화**를 할 수 있음 코드를 읽으며 문서화하는 게 가장 좋은 타이밍이라고 생각함. Ladybird 같은 인기 프로젝트는 문서화가 곧 개발 속도를 높이는 방법임 - 이런 방식의 순수 포팅이 더 많아지길 바람 예전에는 마이그레이션 비용이 너무 커서 “이왕 하는 김에 개선하자”는 식으로 정당화했지만, 결국 **유령 버그**를 더 많이 쫓게 됐음 - 이 접근법이 정말 마음에 듦. 며칠 전 [테스트와 검증 관점에서 쓴 글](https://balanarayan.com/2026/02/20/gen-ai-time-to-focus-on-logic-quality-and-not-code-quality/)이 있는데, 이렇게 복잡한 프로젝트에 적용된 걸 보니 놀라움 - 나도 웹 프레임워크를 이런 식으로 여러 번 변환했음. HTTP 출력 문자열이 완전히 일치하도록 새 코드에서 맞춘 뒤, 구버전을 **완전 삭제**했음 - 좋은 **테스트 스위트**가 있다면 이런 접근은 훨씬 더 잘 작동함. Ladybird도 그럴 것이라 생각함 - Claude Code와 Codex를 이용해 C++ 코드를 Rust로 번역했음 완전 자동이 아니라 사람이 직접 방향을 잡고 수백 개의 작은 프롬프트로 조정했음 두 파이프라인의 출력이 **바이트 단위로 동일**해야 한다는 요구를 처음부터 걸었고, 결과적으로 2주 만에 25,000줄의 Rust 코드 완성 AST와 바이트코드가 모두 일치했고 **회귀 0건**을 달성했음 이런 방식이야말로 언어 간 포팅에 AI를 쓰는 올바른 방법이라 생각함 - 나도 예전에 망가진 Perl 스크립트를 Claude로 Rust로 옮겨봤음 80분 만에 Drupal 구조를 분석하고, 원래 설계와 모듈 구조를 그대로 복원하면서 **커스텀 플러그인**까지 구현했음 지금은 그 사이트가 WordPress, ProcessWire, Node.js, 그리고 이제는 Next.js로까지 옮겨졌다는 소문이 있음 - AI 회사들이 이런 **협업형 사용 방식**에 집중하지 않는 게 아쉬움 나는 “한 번의 프롬프트로 완성된 코드”가 아니라, AI와 함께 오랜 세션을 주고받으며 **인간 지능을 증폭(IA)** 시키는 도구를 원함 하지만 이런 툴은 개발 지식이 있는 사람만 쓸 수 있어서 시장이 작을 것 같음 - 나도 Rust를 배우며 Claude에게 “teach”라는 스킬을 만들어서 쓰고 있음 Claude는 코드를 직접 쓰지 않고 **힌트만 주고 리뷰만 함** Rust는 언어 특성상 즉흥적으로 짜기 어려운데, 이런 방식이 매우 만족스러움 - 나도 Claude를 이런 식으로 씀. “AI가 다 해줘”가 아니라 **설계, 리뷰, 테스트**를 함께 하는 파트너로 씀 - 예전에 만든 복잡한 bash 스크립트를 Claude로 **golang**으로 옮겼는데, 속도와 안정성이 엄청나게 개선됨 이제는 브라우저에서도 돌아가는 wasm 버전까지 있음 암호 관련 부분은 직접 구현하지 않았으니 걱정 안 해도 됨 - Rust로의 전환 소식이 흥미롭지만, Ladybird 팀이 예전엔 **“anti-Rust hype”** 성향이 강했기에 놀라움 그래도 Rust로 옮기면 내가 기여하기는 훨씬 쉬워질 듯함 - 나도 Rust를 좋아하지만, 언어에 대한 **과도한 열광**이 때로는 피로하게 느껴짐 언어는 도구일 뿐이고, 특정 언어에 정체성을 걸 필요는 없다고 생각함 - Rust를 좋아하지 않지만, **실용적으로는 최선의 선택**일 때가 있음 - Ladybird가 이제는 C++/Swift 중심이 아니라는 [링크](https://news.ycombinator.com/item?id=47067678)가 있음 - 언어 방향이 자주 바뀌는 게 조금 불안함. 프로젝트의 **연속성**이 흔들릴 수 있음 - Andreas는 뛰어난 엔지니어이자 **기업가적 감각**이 있는 사람임 취미 프로젝트를 산업적 프로젝트로 발전시킨 게 인상적임 다만 이런 빠른 언어 전환이 살짝 불안하게 느껴짐 - Andreas는 단순한 사업가가 아니라, **Serenity OS**를 혼자서 수년간 만든 엔지니어임 프로젝트가 자연스럽게 성장한 결과라고 봄 - Swift 결정도 여러 언어를 직접 실험해보고 내린 **합리적 판단**이었다고 함 - 참고로 그는 예전에 **Apple Safari 엔진** 팀에서 일했음 - 그래도 이게 진짜 새로운 브라우저로 이어질지는 아직 의문임 - “불안하다”고 했는데, 구체적으로 어떤 점이 불안한지 궁금함 - “비정상적인 Rust 코드지만 나중에 정리할 것”이라는 말이 **또 다른 리라이트**를 암시하는 것 같아 걱정됨 스타트업이 언어를 바꾸는 건 종종 **위험 신호**로 보임 - 그래도 C++과 Rust는 모두 **멀티 패러다임 언어**라서 구조를 비슷하게 옮길 수 있음 - Joel on Software가 말한 “리라이트의 함정”이 떠오름 새 버전 개발과 기존 기능 개발이 병행되면 **속도 경쟁**이 생기고, 새 버전이 따라잡지 못할 수 있음 - 하지만 Ladybird는 스타트업이 아니라 오픈 프로젝트라서 비교가 다름 Linux나 PHP, musl libc도 여러 번 **전체 리라이트**를 거쳤음 - 나도 이런 상황이면 그냥 Firefox를 계속 쓸 듯함 - LLM으로 몇 주간 포팅하는 건 다소 **이상한 선택**처럼 보임 - AI가 보편화된 지금은 “새 언어로 전체 리라이트”의 계산법이 완전히 달라졌음 특히 **테스트 스위트**가 있다면 리스크가 훨씬 줄어듦 테스트의 중요성이 **10배는 커진 시대**임 - 나도 개인 프로젝트에서 AI로 Python CLI 라이브러리를 만들었음 Streamlit, Shiny, Dash 등 다양한 UI를 빠르게 시도할 수 있어서 **프로토타이핑**이 즐거움 - 장기적으로는 AI가 발전하면서 **프로그래밍 언어 자체의 의미**가 줄어들 것 같음 이미 일부 프로젝트에서는 **low-code + agent** 조합으로 충분히 돌아감 - “AI에게 코드 리뷰를 맡겼다”는 부분이 불안하게 들림 모델이 **논리적 오류**를 잡는 데는 한계가 있음 - 그래도 결과적으로 6만5천 개 테스트에서 **0회귀 + 동일 출력**을 달성했다면, 완전히 무시할 수는 없음 다만 나중에 “정리(cleanup)”가 실제로 이루어질지가 관건임 - 인간 리뷰어도 완벽하지 않음. 여러 관점에서 리뷰하면 AI든 사람이든 **서로 다른 오류**를 잡을 수 있음 - 이런 부분은 **테스트 스위트**가 검증해야 할 영역임 - 하지만 AI가 만든 **비정형 Rust 코드**를 다루고 싶지 않다는 사람도 있음 AI 코드에 의존하면 점점 **AI 종속성**이 커지는 악순환이 생김 - 프로젝트가 C++과 Rust를 **병행 개발**한다는 점이 비효율적으로 보임 차라리 메모리 안전한 언어 하나로 통일하는 게 낫지 않을까 생각함 - 하지만 Firefox처럼 **혼합 코드베이스**도 충분히 가능함 각 컴포넌트가 한 언어로만 작성되면 문제 없음 - 완전 전환을 시도하면 **모멘텀 손실**이 커서 프로젝트가 멈출 수 있음 - C++의 **엄격한 서브셋**을 사용하면 메모리 안전성을 확보할 수도 있음 - 2024년 Swift 채택 당시 Andreas가 Rust에 대해 트윗한 내용이 있음 Rust는 단기 실행 프로그램엔 훌륭하지만, **복잡한 객체 그래프를 유지하는 장기 실행 프로그램엔 불편**하다고 했음 커뮤니티가 **독성적**이라는 평가도 덧붙였음 [관련 트윗 링크](https://xcancel.com/awesomekling/status/1822241531501162806) - 그가 마음을 바꾼 걸까? 처음부터 C++을 바꿀 필요가 있었는지도 모르겠음 - Rust 커뮤니티의 **배타적 분위기**에 공감함 - 아마도 **스폰서 요구**로 AI 기반 Rust 전환을 추진한 것일 수도 있음 - 비정형 Rust 코드가 나중에 **기술 부채**로 남을 수 있을지 궁금함 - 위험은 주로 정리 단계에 있음. C++식 포인터 패턴이 Rust의 **소유권 규칙**과 충돌할 수 있음 Servo 프로젝트도 이런 문제를 겪었지만, 그 과정에서 **잠재 버그**를 잡을 수 있었음 - C++ 자체에 문제가 있었던 건 아니고, Rust로 옮긴 이유는 **메모리 안전성** 때문임 - Andreas는 예전부터 JS 런타임의 **GC 안전성** 문제를 언급하며 더 안전한 언어를 원했음 Rust로의 전환은 그 철학에 맞는 **성숙한 선택**으로 보임