RAII, Rust/Linux의 환상
(kristoff.it)요약
Rust 개발자와 기존 Linux 개발자 사이의 분쟁을 지켜보고 쓰는 글입니다. 여러 개발자가 각자 다른 코딩 스타일을 가질 순 있으나, Linux 프로젝트는 이미 C++을 배제해서 그것의 코드 스타일과 구조(RAII)를 피한 전적이 있습니다.
Asahi Lina가 언급한 코드의 작동 방식은 그 프로그램을 종료할 때 너무 느리며, 성능 지향 소프트웨어를 만드는 데 가장 기초적인 방식인 일괄 작업과 대립합니다. 예를 들어, 메모리 영역을 사용해 일괄 작업을 하는 것은 여러 개의 수명을 하나로 조정할 수 있어 RAII가 필요 없습니다.
여기 제 주장을 뒷받침하는 자료를 제시합니다. 이 자료들 모두 일괄 작업이 왜 좋은지 알려주고 있습니다:
- Casey Muratori | Smart-Pointers, RAII, ZII? Becoming an N+2 programmer
- CppCon 2014: Mike Acton "Data-Oriented Design and C++"
- Modern Systems Programming: Rust and Zig - Aleksey Kladov
따라서 저는 Linux가 평생 RAII를 받아들이지 말아야 한다고 생각합니다.
제가 이 글을 가져온 이유는 이렇습니다. 한국의 러스트 개발자분들이 저 글을 보고 매우 화가 난 모습을 여러 번 봐서 여기 분들은 어떤 생각을 가졌을지 궁금했기 때문입니다. 여러분은 어떻게 생각하시나요.
저도 나름대로 Rust를 주력 언어로 사용하는 개발자인데 화는 나지 않았으나 좀 극단적인 예시("그 프로그램을 종료할 때 너무 느리며"라며 링크된 영상에서도 Rust 프로젝트에서의 사례와 직접적 관련은 없는, Visual Studio를 종료할 때 각 개별 컴퍼넌트의 소멸자가 호출되면서 너무 오래 걸린다는 사례를 들고 있습니다)를 들고 오는 게 아닌가 싶긴 합니다.
성능상 여러 컴퍼넌트의 Clean-up이 한 번에 처리되는 것이 필요한 경우에는 개별 컴퍼넌트에 대해 Drop을 구현하는 대신 해당 컴퍼넌트들의 수명을 들고 있는 타입에서 Clean-up을 한 번에 수행하도록 Drop을 구현하는 방식을 택할 수 있을 것 같습니다. 해당 컴퍼넌트를 그 타입의 API를 통해서만 생성할 수 있게 하는 안전장치를 두면 더 좋을 거고요.
물론 위 글의 저자분이 우려하는 바는 RAII를 사용하는 관행이 Linux 코드베이스에 들어올 경우 방대한 코드베이스에서의 복잡성 속에서 굉장히 암시적인 성능 우려가 있는 코드가 누적되면서 장기적으로 Visual Studio와 유사한 일이 벌어질 수 있다는 점일 것 같은데 이는 충분히 우려할만한 지점인 것 같습니다. 다만 다른 댓글에서 말씀하신 것처럼 RAII가 제공하는 안정성도 있으니 선택은 다소 트레이드오프라고 봅니다.
양쪽 다 맞는 말을 하고 있습니다.
비유를 들자면, 온라인 게임 롤의 캐릭터 아지르는 스플릿 운영과 한타에서의 지역장악력, 그리고 궁 밸류가 압도적으로 좋은 고티어 챔프라는 인식이 있는데, 이건 고도로 숙련된 프로 경기에서나 통하는 얘기고, 일반인 레벨에선 라인전도 너무 약하고 체급도 약해서 그저 최하티어 챔피언일 뿐이죠.
아사히 리나처럼 상위 10% 이상의 프로그래밍 및 운영체제 지식이 있는 사람들의 입장에선 RAII 이외의 안이 당연히 좋겠지만, 나머지 90%가 다루는 부분에선 RAII나 Rust만한게 없다고 생각합니다.
다만 메모리 안정성/안전성을 보장해야 하는 큰 이유 중 하나에 보안 문제가 있기 때문에... tradeoff는 불가피하다고 봅니다.