제목: C/C++ 리팩토링이 러스트 재작성이라는 주장은 틀렸다


“C/C++의 리팩토링은 러스트로 재작성하는 것이고, 그 외의 리팩토링은 아무 의미가 없다”는 주장이 있는데, 리팩토링과 재작성부터 구분하지 못한 말이다.

리팩토링은 외부 동작을 유지하면서 내부 구조를 개선하는 작업이다.
러스트 재작성은 구현 언어와 구현체를 교체하는 마이그레이션이다.

둘은 같은 작업이 아니다.

C/C++ 코드에서 다음과 같은 변경은 언어를 바꾸지 않아도 분명한 효과가 있다.


  • 원시 포인터를 std::unique_ptr, std::shared_ptr로 교체
  • 수동 자원 관리를 RAII로 전환
  • 소유권과 생명주기 경계 명확화
  • 전역 상태와 공유 가변 상태 축소
  • 모듈 경계와 인터페이스 단순화
  • AddressSanitizer, UBSan, Valgrind, 정적 분석 도입
  • Clang-Tidy와 C++ Core Guidelines 적용
  • 위험한 코드를 좁은 영역으로 격리
  • 테스트와 퍼징을 통해 기존 동작 검증


이런 작업들은 실제로 메모리 오류, 자원 누수, 결합도, 변경 비용, 디버깅 난이도를 줄인다.

러스트가 더 강한 기본 보증을 제공하는 것은 맞다.
러스트는 소유권과 빌림 규칙을 컴파일러가 강제하므로, C++의 선택적 모범 사례보다 일관된 메모리 안전성을 제공한다.

하지만 여기서 나오는 결론은

“러스트는 특정 종류의 오류를 더 강하게 방지한다”

이지,

“C/C++ 리팩토링은 아무 의미가 없다”

가 아니다.

이 둘 사이에는 큰 논리적 비약이 있다.

전면 재작성은 기존 구현에서 이미 해결한 수많은 예외 상황과 버그 수정 이력을 버리고 다시 구현하는 작업이다. 그 과정에서 기존 버그가 사라질 수도 있지만, 새로운 논리 오류와 호환성 문제, 성능 회귀, 기능 누락이 생길 수도 있다.


특히 대규모 코드베이스에서는 다음 비용이 발생한다.


  • 재개발 기간
  • 기존 동작 재검증
  • 테스트 재작성
  • 운영 노하우 손실
  • FFI와 언어 경계 복잡성
  • 이중 코드베이스 유지
  • 새 언어 학습 비용
  • 기존 라이브러리와 도구 재구축


그래서 실제 산업계에서는 보통 세 가지 전략을 비교한다.


  1. 기존 C/C++ 코드 현대화
  2. 위험한 일부 모듈만 러스트로 교체
  3. 전체 시스템을 러스트로 재작성


어느 것이 맞는지는 코드베이스 상태, 결함률, 보안 요구, 인력, 예산, 유지보수 기간에 따라 달라진다.

예를 들어 신규로 작성하는 보안 민감 모듈이라면 러스트가 매우 좋은 선택일 수 있다.
반대로 수십 년간 검증된 대규모 C/C++ 시스템이라면, 전체 재작성보다 점진적 현대화와 일부 교체가 더 안전할 수도 있다.

“러스트 재작성 외에는 의미가 없다”는 말은 공학적 판단이 아니라 거짓 양자택일이다.

C/C++ 리팩토링은 러스트와 같은 보증을 제공하지 않을 수 있다.
그러나 보증 수준이 다르다는 것과 개선 효과가 없다는 것은 전혀 다른 주장이다.

공학은 완벽한 선택 하나를 찾는 일이 아니다.
비용, 위험, 성능, 안전성, 유지보수성을 비교해서 가장 적합한 변경 전략을 선택하는 일이다.