제목: 러스트의 '견고함'이 대규모 리팩토링의 덫이 될 때

방금 올라온 '러스트는 선택받은 소수만의 언어'라는 글을 흥미롭게 읽었습니다. 글쓴이께서는 러스트의 장점이 발현되는 대규모 프로젝트에 참여할 기회가 적다는 점을 지적하셨죠.

저는 그 의견에 반대하며, 오히려 러스트의 가장 큰 장점인 '엄격한 소유권 시스템'이 특정 상황의 대규모 프로젝트에서는 거대한 기술 부채나 개발 장벽으로 작용할 수 있다고 생각합니다.

'수정은 한 줄, 컴파일 에러는 백 군데'

간단한 시나리오를 가정해 봅시다.

수십 개의 모듈로 구성된 대규모 러스트 프로젝트가 있고, 여러 팀이 각자 맡은 모듈을 개발하고 있습니다.

어느 날 core-utils 모듈을 담당하는 개발자가 효율성을 위해 핵심 데이터 구조(struct)의 필드 하나를 바꾸거나, 함수의 파라미터를 &str (빌려오기)에서 String (소유권 이전)으로 변경했습니다. 이 개발자 입장에서는 자신의 모듈 내에서 완벽하게 컴파일되는 합리적인 수정이었죠.

바로 그 순간 '리팩토링 대참사'가 시작됩니다.

이 core-utils 모듈에 의존하는 다른 모든 모듈에서 도미노처럼 컴파일 에러가 번져나갑니다. 빌림 검사기(borrow checker)는 자비가 없으니까요. 단순한 API 사용법 변경이 아니라, 데이터의 '소유권'이라는 근본적인 개념이 바뀌었기 때문에 해당 데이터를 사용하는 모든 코드의 논리를 다시 점검하고 수정해야 합니다.

대규모 프로젝트에서 더 고통스러운 이유

• 작은 프로젝트: 어차피 혼자 또는 소수의 개발자가 전체 코드를 파악하고 있으므로, 이런 '소유권 연쇄 파괴'가 발생해도 어떻게든 수습할 수 있습니다.
• 큰 프로젝트: 내 코드가 아닌, 다른 팀이 몇 달 전에 짜놓은 코드까지 제가 수정해야 하는 상황이 발생합니다. 그 팀은 이미 다른 업무를 하고 있을 가능성이 높죠. 변경점 하나를 전파하고 수정하기 위한 커뮤니케이션 비용이 기하급수적으로 늘어납니다.

물론, 이는 '잘못된 설계를 초기에 바로잡는' 긍정적인 강제력이 될 수도 있습니다. 하지만 이미 수십만 라인이 넘는 코드베이스에서 이런 '대격변' 수준의 리팩토링은 사실상 프로젝트를 마비시킬 수 있는 리스크입니다.

결론

러스트의 엄격함은 버그를 사전에 차단하는 최고의 방패입니다. 하지만 이 방패는 때로 변화에 대응해야 하는 아군에게 겨눠진 칼이 되기도 합니다.

러스트는 '완벽하게 설계된' 대규모 프로젝트에는 최고의 언어일지 몰라도, 비즈니스 요구사항에 따라 '끊임없이 진화하고 리팩토링해야 하는' 대규모 프로젝트에는 최고의 독이 될 수도 있습니다.

러빨러들의 말들은 반드시 검증을 해봐야 합니다. 러빨러들은 혹세무민, 곡학아세를 멈추시기 바랍니다.