▲

Ladybird가 Rust를 채택, AI의 도움으로 전환 가속

 (ladybird.org)
1P by GN⁺ 17시간전 | ★ favorite | 댓글 1개
  • 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의 미래를 위한 올바른 선택으로 평가함
▲
GN⁺ 17시간전  [-]
Hacker News 의견들

  • 이 프로젝트에서 바이트 단위로 동일한 출력을 요구한 점이 가장 똑똑한 부분임
    덕분에 기존 파이프라인과 새 파이프라인을 나란히 돌려서 diff를 비교할 수 있고, 번역 중 생긴 버그를 즉시 잡을 수 있음
    많은 리라이트가 실패하는 이유는 사람들이 포팅 중에 “개선”을 시도하다가 구버전, 신버전, 혹은 단순한 동작 차이에서 생긴 유령 버그를 쫓기 때문임
    Rust로의 C++ 번역 버전이 처음엔 어색해 보여도 괜찮음. 나중에 C++ 쪽을 완전히 퇴역시키면 점진적으로 더 idiomatic하게 바꿀 수 있음

    • 포팅은 많은 걸 개선할 좋은 시점이지만, 새로운 기능을 추가할 시점은 아님
      출력이 동일하게 유지되는 한에서 리팩터링, 효율화, 문서화를 할 수 있음
      코드를 읽으며 문서화하는 게 가장 좋은 타이밍이라고 생각함. Ladybird 같은 인기 프로젝트는 문서화가 곧 개발 속도를 높이는 방법임
    • 이런 방식의 순수 포팅이 더 많아지길 바람
      예전에는 마이그레이션 비용이 너무 커서 “이왕 하는 김에 개선하자”는 식으로 정당화했지만, 결국 유령 버그를 더 많이 쫓게 됐음
    • 이 접근법이 정말 마음에 듦. 며칠 전 테스트와 검증 관점에서 쓴 글이 있는데, 이렇게 복잡한 프로젝트에 적용된 걸 보니 놀라움
    • 나도 웹 프레임워크를 이런 식으로 여러 번 변환했음. 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 중심이 아니라는 링크가 있음
    • 언어 방향이 자주 바뀌는 게 조금 불안함. 프로젝트의 연속성이 흔들릴 수 있음

  • 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는 단기 실행 프로그램엔 훌륭하지만, 복잡한 객체 그래프를 유지하는 장기 실행 프로그램엔 불편하다고 했음
    커뮤니티가 독성적이라는 평가도 덧붙였음
    관련 트윗 링크

    • 그가 마음을 바꾼 걸까? 처음부터 C++을 바꿀 필요가 있었는지도 모르겠음
    • Rust 커뮤니티의 배타적 분위기에 공감함
    • 아마도 스폰서 요구로 AI 기반 Rust 전환을 추진한 것일 수도 있음

  • 비정형 Rust 코드가 나중에 기술 부채로 남을 수 있을지 궁금함

    • 위험은 주로 정리 단계에 있음. C++식 포인터 패턴이 Rust의 소유권 규칙과 충돌할 수 있음
      Servo 프로젝트도 이런 문제를 겪었지만, 그 과정에서 잠재 버그를 잡을 수 있었음
    • C++ 자체에 문제가 있었던 건 아니고, Rust로 옮긴 이유는 메모리 안전성 때문임
    • Andreas는 예전부터 JS 런타임의 GC 안전성 문제를 언급하며 더 안전한 언어를 원했음
      Rust로의 전환은 그 철학에 맞는 성숙한 선택으로 보임
답변달기