Rust로 다시 쓰기: 성능, 실패, 그리고 2026년의 현실 점검
Rewriting in Rust
Rust로 다시 쓰기(RIIR) 운동은 여전히 진행 중이지만, 그 결과는 예상과 다를 수 있습니다. 이 글은 실제 프로젝트 사례를 통해 Rust 재작성이 성능과 안전성에서 실질적인 이점을 제공하는지, 어떤 실패 사례가 있는지, 그리고 2026년 현재 Linux 커널과 Windows에서 Rust의 위상을 살펴봅니다. uutils, sudo-rs, Prisma, curl/hyper 통합 등의 사례를 통해 성공과 실패의 요인을 분석하고, 점진적 확장과 테스트의 중요성을 강조합니다.
Rust는 정말 훌륭하지만, 시스템 프로그래밍 언어로 설계되었으며, 그곳에서 최고의 성능을 발휘합니다. 모든 성능이나 안전 문제에 대한 기본 답변으로 RIIR을 취급하는 것은 2년의 재작성 프로젝트가 6개월 늦게 출시되고 이미 해결한 버그를 다시 도입하는 결과를 낳을 수 있습니다.
HN 토론
61- joshka
이 글은 정말 좋은 블로그 글이 될 것 같아요. 제가 꼭 읽고 싶은 그런 글이요. 하지만 생성된 AI 산문이 산만하게 하고, 신뢰를 잃게 만들어서 읽고 싶지 않게 만드네요. 저는 AI에 매우 친화적이지만, 이것은 AI 전체에 대한 비판이 아니라 이 글에 대한 비판입니다.
- collinfunk
참고로 저는 GNU coreutils의 공동 유지보수자입니다. 제 의견이 관련성이 있는지, 편향되었는지, 아니면 둘 다인지는 여러분이 판단하세요. :)
저는 여기서 벤치마킹 방법론을 문서화했거나, 적어도 독자들이 보여진 벤치마크를 기반으로 성급한 결론을 내리지 않도록 주의를 주었으면 좋았을 것입니다.
GNU 'sort'의 성능은 사용 중인 로케일, 입력, 그리고 --buffer-size 및 --parallel 옵션에 주어진 인자에 따라 크게 달라질 수 있습니다. GNU 'sort'는 기본적으로 사용할 스레드 수에 대해 상당히 보수적이며, 제 경험상 uutils보다 훨씬 더 보수적입니다. 이는 'sort'에 더 많은 스레드를 투입하면 더 빨라질 수도 있고 그렇지 않을 수도 있지만, 메모리 부족 위험도 있기 때문입니다. 이것은 외부 정렬을 사용할 시기를 결정하는 데 약한 uutils의 문제입니다:
$ export LC_ALL=C
$ for i in {a..z}; do yes $i | head -n $(numfmt --from=iec 512M) | tr -d '\n' >> input; done
$ time sort input > /dev/null
real 0m24.245s
user 0m0.896s
sys 0m19.161s
다음은 'make PROFILE=release'로 컴파일된 최신 uutils 커밋을 사용한 동일한 명령입니다:
$ time uu-sort input > /dev/null
Killed uu-sort input > /dev/null
real 2m53.560s
user 1m40.634s
sys 0m59.847s
프로세스는 OOM 킬러에 의해 종료됩니다. 이는 아마도 uutils 'sort'가 GNU 'sort'가 사용하는 1개 대신 18개의 스레드를 사용하기로 결정했기 때문일 것입니다. 방법론이나 인용 없이 벤치마크가 던져지는 것이 좀 답답합니다. 왜냐하면 그것들은 종종 의심 없이 신뢰되기 때문입니다. 이것들은 ...
- tonyedgecombe
잠시 동안 저는 JetBrains가 그들의 도구를 Rust로 다시 작성하고 있어서 우리가 약간의 성능 향상을 얻을 수 있을 것이라고 생각했습니다.
- ameliaquining
이 글은 한 번에 모두 다시 작성하는 대신 점진적으로 다시 작성하는 것을 옹호합니다. Joel이 2000년에 말했던 것처럼, 그리고 오늘날까지 모든 사람들이 계속 말하는 것처럼요. 그러나 실제로 사람들은 이렇게 하지 않습니다. 특히 C가 아닌 언어에서 다시 작성할 때, 완전한 재작성은 점진적인 것보다 훨씬 더 일반적입니다. Linux, Windows, Firefox와 같은 주목할 만한 예외는 너무 거대하고 오래된 코드베이스로, 처음부터 다시 쓸 수 없음이 명백합니다. 처음부터 다시 쓰는 것이 가능할 때, 그렇게 하는 경향이 있습니다.
이유는 꽤 간단합니다: 다른 언어(특히 C가 아닌 경우)에서 Rust로 코드베이스를 점진적으로 포팅하는 것은 매우 불쾌한 경험입니다. 왜냐하면 상호 운용 도구가 충분히 좋지 않아서 대부분의 시간을 그것과 싸우며 보내기 때문입니다. C++에서 다시 작성하는 경우를 고려해 보세요. 가장 간단한 경우에는 bindgen과 cbindgen을 사용하는데, 이들은 두 언어 모두에서 extern "C" 함수에서만 작동합니다. 따라서 각 API를 먼저 관용적인 C++에서 C-in-C++로 다시 작성한 다음 C-in-Rust로 번역하고, 다시 관용적인 Rust로 다시 작성해야 합니다. 그리고 다음 API에 대해 반복합니다. 계속해서요. 대부분의 프로그래머가 "제기랄, Joel이 뭐라고 하든 상관없어. 적어도 내 모든 작업을 다시 작성할 때는 무엇이든 무엇이든 호출할 수 있는 하나의 언어로 하고 있을 거야"라고 말하는 데는 오래 걸리지 않을 것입니다. cxx와 autocxx는 상황을 약간 개선하지만, 여전히 빈약한 API 어휘와 비슷한 문제를 남기며, 여전히 ...
- kmaitreys
이 주제는 최근에 양극화된 반응을 불러일으키는 의미를 갖게 되었습니다. 사람들은 언어에 "지쳤고" Bun 재작성과 같은 에피소드는 특히 현재 LLM에 집착하는 시대에 도움이 되지 않습니다.
이런 가운데, 제가 그다지 주목받지 못하는 분야(과학/수치 프로그래밍)에서 일하면서 언어에 대한 제 개인적인 경험을 말씀드리겠습니다. 몇 년 전, Python을 더 빠르게 만들려고 지친 후, 저는 시뮬레이션 코드를 작성할 언어를 찾고 있었습니다. Fortran(그리고 C/C++)은 제 분야에서 수십 년 동안 표준 선택이었지만, 저는 현대적인 언어를 시도해 보고 싶었습니다. Julia를 시도했지만 워크플로가 자연스럽지 않았습니다. 또한 기본적으로 AOT 컴파일도 되지 않았습니다. Rust가 두 번째 선택이었지만, 그 타입 시스템/디자인, 표현력, 그리고 도구(rust-analyzer)가 저를 사로잡았습니다. 저는 그것을 많이 작성했고, 작성하는 것을 정말 즐깁니다. 빌림 검사기는 과학 코드를 작성할 때 99%의 경우 실제로 문제가 되지 않습니다. 그리고 문제가 될 때(자기 참조 데이터 구조) 아레나(또는 이와 동등한 것)를 사용하면 됩니다. C/Fortran 상호 운용이 훌륭해서 ODE 해결이나 희소 행렬과 같은 더 일반적인 것들을 위해 제 자신의 추상화를 그 위에 구축하는 것이 여전히 쉽습니다.
그리고 물론 속도, 메모리 안전성, 그리고 병렬화를 그렇게 쉽게 할 수 있는 능력(rayon은 마법적입니다)이 있지만, 저는 그것들이 실제로 저를 사로잡은 것은 아니라고 느낍니다. 그 언어는 단지 작성하는 것이 즐거웠습니다.