C와 C++ 코드베이스를 Rust로 옮기는 일은 더 이상 실험적 아이디어에 머물지 않는다. 메모리 안전성을 높이고, 장기 유지보수 비용을 줄이며, 성능이 중요한 시스템을 현대화하려는 목적으로 Rust를 실무적 선택지로 검토하는 팀이 늘고 있다. 다만 핵심 질문은 'Rust가 인기 있으니 전부 다시 쓰자'가 아니라 훨씬 실용적인 쪽에 있다. 기존 C·C++ 시스템에 Rust를 고려할 이유는 무엇이고, 어느 부분을 옮겨야 하며, 이미 잘 돌아가는 것을 망가뜨리지 않고 어떻게 진행할 것인가다. 이 글은 JetBrains RustRover 팀이 진행한 라이브 방송에서 Mainmatter의 Luca Palmieri(100 Exercises To Learn Rust 저자, C to Rust Migration 책 집필 중)와 JetBrains의 Vitaly Bragilevsky가 나눈 논의를 바탕으로, 실제 마이그레이션이 어디서 성공하고 어디서 막히는지 정리한 것이다.
왜 지금이고, 어떤 프로젝트인가
몇 년 전만 해도 운영 트래픽을 감당하거나 사업적으로 중요한 시스템을 Rust로 옮기자는 제안은 위험 부담이 컸다. 수년의 엔지니어링 투자를 쏟아붓다가 중간에 막다른 길을 만나는 상황을 누구도 원하지 않기 때문이다. 그러나 이런 망설임은 약해지고 있다. 구글 같은 회사는 단순히 Rust로 옮기는 데 그치지 않고, Rust 도입이 특히 메모리 안전 취약점을 줄여 안전성을 높이고 결함률을 낮춘다는 데이터를 공개하며 근거를 제시하고 있다.
그렇다고 모든 프로젝트가 이관의 이득을 보는 것은 아니다. 취미 프로젝트라면 Rust를 배우고 싶거나 끌린다는 이유만으로 충분하지만, 운영 시스템은 사업적 타당성이 있어야 한다. 가장 강력한 후보는 이미 유지보수 비용이 비싼 코드베이스다. 성공적인 이관은 기능을 더 빨리 출시하거나 결함률을 낮추거나, 혹은 둘 다를 개선한다. 결국 재작업 감소, 보안 사고 축소, 개발 생산성 향상, 운영비 절감 같은 실익이 이관 비용을 정당화해야 한다.
전면 재작성과 점진적 이관
전면 재작성과 점진적 이관 사이의 선택은 이념 문제가 아니라 배포 모델, 코드베이스 특성, 테스트 인프라에 달려 있다. 백지에서 시작해 경계를 원하는 대로 긋는 전면 재작성은 매력적으로 들린다. 백엔드로 배포되는 서비스는 실제로 좋은 후보가 될 수 있는데, 새 구현으로 섀도 트래픽을 흘려 기존 시스템의 응답과 비교하고 부하를 점진적으로 옮길 수 있기 때문이다. 문제가 생기면 즉시 롤백하거나, 트래픽 비중을 아주 낮게 유지하거나, 특정 고객 세그먼트로만 제한하는 등 여러 안전장치를 쓸 수 있다. 핵심은 새 구현이 옛것과 똑같이, 사용자가 무심코 의존하던 사소한 동작까지 동일하게 작동함을 증명하는 신뢰 확보 장치다.
하지만 규모가 크거나 활발히 개발 중이거나 고객 환경에 배포되는 시스템에는 점진적 이관이 대체로 더 안전하다. 코드 전체를 한꺼번에 갈아치우는 대신 한 조각을 옮겨 출시하고, 거기서 배우고, 이어간다. 한 릴리스가 C·C++ 95%에 Rust 5%였다면 다음 릴리스는 90% 대 10%가 되는 식이다. 옮겨진 모든 조각이 실제 제품에 통합되므로 사용자가 새 코드를 쓰고, 성능이 나은지 나쁜지 팀이 직접 확인하며, 버그는 평소의 이슈 트래커에 잡힌다. 개발자가 과정 내내 참여하므로 전면 재작성이 안는 지식 손실 위험도 줄어든다.
잎에서 시작하기, 그리고 경계를 다루는 법
실무적으로 유용한 접근은 모듈 그래프에서 고립된 모듈, 즉 다른 부분에 의존이 없거나 거의 없는 잎(leaf)부터 시작하는 것이다. 첫 Rust 코드가 C·C++를 호출할 필요 없이 기존 코드에서 호출되기만 하면 되기 때문에 가장 쉬운 출발점이다. 이 단계의 목표는 거창한 로직이 아니라, 거의 아무것도 하지 않지만 올바르게 빌드되고 링크되며 모든 CI 흐름에서 동작하는 한 줄의 Rust를 출시하는 것이다. 빌드 시스템, 테스트 설정, FFI 관례, 릴리스 프로세스가 자리 잡는 이 이륙 단계가 가장 어렵고, 그다음 모듈부터는 수월해진다. 반대로 특정 사용자 흐름을 세로로 관통하는 방식은 사업 가치를 즉시 보여주지만, Rust가 끊임없이 C를 호출하고 C에서 호출되며 원시 포인터가 곳곳에 등장해 'C 스타일 Rust'처럼 느껴진다.
점진적 이관에서 가장 어려운 부분은 언어 경계를 넘는 일이다. 순수 Rust 안에서는 컴파일러가 소유권과 대여, 수명을 강제하지만, 원시 포인터가 Rust와 C 사이를 오가는 순간 그 안전망은 약해지고 프로그래머가 직접 가정을 추적하는 '사람 보로우 체커'가 되어야 한다. 여기서 FFI가 핵심으로 떠오른다. 유용한 원칙은 '메모리를 할당한 쪽이 해제한다'는 것으로, 경계를 아주 신중하게 설계하지 않는 한 C에서 할당해 Rust에서 해제하는 식은 피해야 한다. 혼합 코드베이스에서 unsafe 코드가 등장하는 것은 당연하며 그 자체가 잘못은 아니다. 다만 아무도 보지 않는 접착 코드가 아니라 중요한 설계 표면으로 다뤄져야 한다. 마이그레이션 작업의 상당 부분은 이미 C·C++에 존재하던 동작을 Rust 컴파일러의 눈에 보이고 올바르게 드러나도록 만드는 일이며, 정적 분석의 이점을 얻으려면 도구가 도울 수 있는 구조로 코드를 다듬어야 한다.
결국 C++에서 Rust로의 이관은 단순한 재작성이 아니라 빌드 시스템, 릴리스 프로세스, 테스트 전략, 그리고 이후 코드를 책임질 사람들에게까지 영향을 미치는 장기 엔지니어링 프로젝트다. 가장 안전한 이관은 작게 시작해 통합 문제를 초기에 풀고, FFI 경계를 이해 가능한 상태로 유지하며, 팀이 새 코드를 스스로 소유할 만큼 Rust를 익히면서 릴리스마다 신뢰를 쌓는 방식이다. 모든 줄을 최대한 빨리 갈아치우는 것이 아니라, 위험을 줄이고 지식을 보존하며 제품을 계속 전진시키는 방향으로 옳은 부분을 옮기는 것이 실무적 핵심이다.