고속 링커 mold, Rust로 재작성해 3.0.0 출시

AI 요약

고속 링커 mold가 C++에서 Rust로 구현을 전면 재작성하고 3.0.0을 내놓았습니다. C++ 버전의 마지막 릴리스는 2.42.1이며, 3.0은 사용자가 기존 버전을 대체해 쓸 수 있도록 같은 명령행 옵션과 대상 아키텍처를 지원합니다. 버그 수정 항목을 제외하면 출력도 동일하게 유지하는 것이 목표입니다. 개발팀은 링크 성능이 2.42.1과 비슷한 수준이라고 밝혔습니다.

호환성과 검증

개발팀은 지원하는 모든 대상에서 테스트 스위트를 실행하고, 실제 사용 사례와 다양한 옵션 조합에서 링커 출력을 비교했습니다. Gentoo 패키지도 모두 빌드해 확인했으며, 회귀 문제는 발견하지 못했다고 합니다. mold 3.x의 목표는 GNU ld와 남아 있는 호환성 차이를 줄이는 것입니다. 특히 링커 스크립트 지원을 개선해 Linux 배포판의 기본 링커로 채택될 기반을 마련하려 합니다.

Rust 전환과 빌드 방식

이번 전환으로 손상된 입력 파일을 처리하는 방식도 달라졌습니다. C++ 버전은 잘못된 입력을 읽다가 메모리 경계를 벗어나 세그멘테이션 오류로 종료될 수 있었습니다. Rust 버전은 해당 읽기를 경계 검사로 막고, 잘못된 접근 지점에서 panic을 내며 중단합니다.

직접 빌드하는 절차도 바뀌었습니다. CMake 대신 Cargo를 사용하며 Rust 1.95 이상과 C 컴파일러가 필요합니다. cargo build --release로 빌드하고 ./install-mold.sh로 설치합니다. 설치 스크립트는 PREFIX와 DESTDIR을 받습니다. CMake 옵션은 제거됐습니다. 라이브러리를 $PREFIX/lib가 아닌 /usr/lib64 같은 경로에 설치한다면, 빌드와 설치 때 모두 MOLD_LIBDIR을 설정해야 mold -run이 mold-wrapper.so를 찾습니다.

mold는 oneTBB 의존성을 없앴습니다. mimalloc 3.5.3은 이전처럼 정적으로 링크하며, --features system-allocator를 주면 시스템 malloc을 사용합니다. 시스템 zlib이 있으면 이를 링크하고, zstd와 BLAKE3은 포함합니다. 시스템 zstd를 링크하려면 ZSTD_SYS_USE_PKG_CONFIG=1을 설정합니다. 테스트는 ctest 대신 cargo test로 실행하며, 테스트 의존성 설치 스크립트도 install-test-deps.sh로 바뀌었습니다.

수정된 버그와 아키텍처 지원

이번 릴리스는 정적 실행 파일에 버전 스크립트나 --default-symver를 적용할 때 발생하던 충돌, 출력 파일을 입력 파일로 함께 지정할 때의 충돌과 출력 손상을 수정했습니다. --gc-sections가 --init과 --fini로 지정한 함수를 제거하지 않도록 했고, 이름이 같은 common symbol의 크기와 정렬은 GNU ld 및 lld처럼 가장 큰 크기와 가장 엄격한 정렬을 따릅니다. 비결정적 출력을 내던 여러 경우도 수정했습니다.

재배치(relocation) 처리와 -r 부분 링크 관련 수정도 포함합니다. 잘못된 주소를 조용히 내던 GOT 상대 재배치는 올바르게 처리하거나 오류로 보고합니다. 위치 독립 출력에서 사용할 수 없는 PC 상대 재배치에는 원인과 해결 방법을 설명하는 오류를 추가했습니다. 여러 아키텍처에서 재배치 유형 지원과 큰 프로그램의 분기 처리도 개선했습니다. AArch64, ARM32, RISC-V, LoongArch, PPC64, SH4, SPARC64 등이 수정 목록에 포함됩니다.

Reddit 반응

• @u/aapoalas — 와, 재작성 계획을 알리는 글을 못 봐서 제게는 갑작스럽네요. 그래도 멋집니다. 개발팀이 이 전환을 즐겁고 유익하게 받아들이길 바랍니다. 링커에 영향을 주는 언어 설계 문제를 mold 개발자들이 다루거나, mold와 wild 사이에 흥미로운 아이디어 교류가 생길지도 모르겠습니다.
  • @u/syklemil — 저도 발표를 봤지만, 불과 한 달 전에 알려져서 여전히 갑작스럽다고 생각합니다.
  • @u/geo-ant — 궁금해서 묻습니다. LLM을 활용해 재작성한 건가요? 릴리스 자료만으로는 알기 어렵습니다. 2.42.1 글에서 LLM 코딩 보조 도구가 소프트웨어 재작성에 실용적이라고 언급했던 것 같아서요.
  • @u/AlyoshaV — X 게시물을 보면 AI 도움을 받은 건 맞지만, ‘바이브 코딩’은 아닌 것 같습니다. Rui가 코드를 읽고 이해하고 있으며, AI에도 단순히 “Rust로 다시 써”라고만 지시하지 않은 것 같습니다.
  • @u/nicoburns — 책임감 있는 AI 보조 포팅은 분명 가능합니다. 점진적으로 진행하거나, 이 사례처럼 코드베이스가 작아 한 번에 옮겨도 제대로 검토할 수 있다면요.
• @u/eras — 어떻게 작업했는지 궁금합니다. 직접 재작성했을까요? Rust 코드를 처음 추가한 커밋은 다른 저장소의 코드를 가져온 것으로 보이고, AI가 쓴 흔적은 없어 보입니다. 그래도 한 커밋에 Rust 코드 4만 5천 줄이 들어갔네요.
  • @u/SupermarketAntique32 — 기여자 목록에 Claude가 있습니다. 다만 1위 기여자와 비교하면 기여량은 아주 적습니다.
  • @u/Wh00ster — 그게 좋은 지표인가요? 웃기네요.
  • @u/AlyoshaV — 제가 X 게시물에서 이해한 바로는 AI 도움은 받았지만, 코드를 읽고 이해하면서 진행했습니다. AI에게 단순히 재작성만 시킨 건 아닌 듯합니다.
• @u/jakkos_ — wild README 벤치마크에서는 wild가 더 빠르고 mold README에서는 mold가 더 빠르게 나오는데, 이유를 아는 분 있나요? CPU 코어 수가 다른 곳에서 벤치마크를 실행한 탓인가요?
  • @u/The_8472 — 이 글을 참고하세요: https://davidlattimore.github.io/posts/2026/09/18/benchmarking-wild-vs-mold.html
  • @u/Pretty_Jellyfish4921 — 상황에 따라 한쪽이 다른 쪽보다 빠릅니다. 예전 토론도 참고하세요: https://www.reddit.com/r/rust/comments/1w45j6n/comment/p751cc6
• @u/agent_kater — Rust 애플리케이션 링크에도 쓸 수 있나요? 증분 컴파일로 컴파일 시간은 줄었지만, 1분 넘는 링크 시간이 괴롭습니다.
  • @u/LGXerxes — 네. 링크 시간이 꽤 줄어드는 경우가 많습니다.
  • @u/flashmozzg — 쓸 수는 있지만, 이미 LLD를 사용한다면 개선 폭은 크지 않을 겁니다. 제가 알기로 Rust는 Linux에서 대략 1.90부터 기본 링커로 LLD를 쓰기 시작했습니다.
• @u/AdventurousFly4909 — 이제 기본 링커로 사용되나요?
• @u/Other_Class1906 — 왜요?
  • @u/syklemil — 변경 기록에서 이전 글로 이어지는 링크를 따라가면 이유를 볼 수 있습니다. mold는 수십 년 동안 쓰일 가능성을 고려해야 하는 도구이며, 개발을 시작한 2020년과 달리 2026년의 Rust는 시스템 소프트웨어에 실용적인 선택지가 됐다고 개발자가 설명했습니다. C++에 가까운 성능과 메모리 안전성을 제공하고, AI 보조 코딩의 발전으로 대규모 재작성도 더 현실적이 됐지만 위험이 사라진 것은 아니라고 했습니다. 사용자가 느끼기에는 구현만 바뀌고 동작은 그대로인 것이 목표라고 밝혔습니다.
  • @u/puttak — Rust가 미래이기 때문입니다.
  • @u/Other_Class1906 — 일부 분야에서는 Rust가 지나치게 제한적일 수 있어 C++ 같은 언어가 계속 쓰일 여지도 있습니다. 프로젝트를 Rust로 다시 쓰자고 제안할 때는 “미래니까”보다 나은 근거가 필요합니다. 다만 AI 도움으로 지금은 시간이 훨씬 덜 들 수도 있겠네요.
  • @u/insanitybit2 — Rust는 메모리 안전하기 때문입니다. 정말 그게 전부입니다.

원문: GitHub 릴리스 / 번역·요약: Trawling