C++ RAII(Resource Acquisition Is Initialization)의 해석

조만간 번역서가 출판될 Effective Modern C++ 어딘가에 다음과 같은 문구가 나옵니다:

관련해서 기억나는, 10년도 더 된 논의가 하나 있습니다: GpgStudy 포럼 “클래스 생성시 ... ”

특히 조순현 님의 답글과 제 답글이 이번 블로그 글과 관련이 있는데요. 제 답글에 등장하는 http://tinyurl.com/4ogc8는 현재는 깨진 링크이고, 원래 의도한 해당 뉴스그룹 글은 이것입니다.

당시는 “RAII의 핵심은 초기화가 아니라 파괴”라는 관점에서 답글을 달았지만, 지금은 조순현 님(당시 닉은 ‘수렁’)의 “자동변수뿐만 아니라 자원 획득은 거의 모든 경우에 있어서 초기화(준비 완료)여야 한다고 생각합니다.”라는 의견을(곁들여서 C++의 예외에 대해서도) 좀 더 논의했다면 좋았겠다고 후회하고 있습니다.

한편, 그 논의와는 무관하게, 저는 전부터 RAII라는 용어의 유래가 궁금했습니다. ‘함흥차사’가 무슨 뜻인지가 아니라 그런 뜻에 왜 ‘함흥차사’라는 이름이 왜 붙었는지 궁금해하는 것과 비슷하게요. 겸사겸사 해서 지금까지 생각한 것들을 장황하게나마 써보겠습니다.

“Resource Acquisition Is Initialization”이라는 문장은 다음 두 가지로 해석할 수 있습니다.

1. “자원 획득은 초기화이다”
2. “자원 획득이 초기화이다”

토씨 하나만 다른 문장들이지만 의미는 사뭇 다릅니다. 1번은 “자원 획득은 무엇인가?”에 대한 답이고, 2번은 “무엇이 초기화인가?”에 대한 답입니다.

C++ 객체의 수명 주기를 참작할 때, 그리고 답의 ‘초기화’라는 단어를 생각할 때, “자원 획득은 무엇인가?”라는 질문에는 “자원 획득은 언제 일어나야 하는가?”라는 질문이 포함되어 있다고 생각할 수 있습니다. 비슷한 논리로, “무엇이 초기화인가?”라는 질문에는 “초기화 시점에서 주로 수행해야 할 작업은 무엇인가?”라는 질문이 포함되어 있겠고요.

그 두 질문의 답을 합친다면, “자원 획득은 초기화 시점에서 일어나야 하며, 초기화 시점에서 해야 할 중요한 작업은 자원 획득이다”가 되겠습니다. 그런데 이러한 답이 의미가 있으려면, 객체의 유효성(앞의 포럼 논의에서는 Testors 님이 여러 번 강조하신 ‘인스턴스의 무결성’)에 대한 다음과 같은 관점이 필요합니다.

1. 생성이 완료된 객체는 유효한 객체이어야 한다. 즉, 유효하지 않은 객체가 생성되어서는 안 된다.
2. 필요한 자원들을 획득하지 못한 객체는 유효한 객체가 아니다.

이러한 관점에서 “자원 획득은/이 초기화이다”는 모든 자원은 생성자 안에서 완전하게 획득해야 하며, 획득하지 못한 자원이 하나라도 있는 상태에서 생성자가 완료되어서는 안 된다는 뜻이라 할 수 있습니다. 그리고 대칭성에 의해, 파괴(소멸)되어서 더 이상 유효하지 않게 된 객체는 그 어떤 자원도 가지고 있지 않아야 합니다. 이로부터 흔히 통용되는 RAII의 뜻, 즉 “(예외가 발생해도 누수가 일어나지 않도록)소멸자에서 자원을 해제하는 기법”을 이끌어 낼 수 있고요.

물론 이는 “꿈보다 해몽”입니다. 사실 “Resource Acquisition Is Initialization”이라는 문구를 만든(The Design and Evolution of C++ 참고) 비야네 스트롭스트룹 본인은 RAII가 어떤 중심 개념을 대표하는 이름치고는 ‘clumsy’한(서투른, 재치 없는, 꼴사나운 등등) 이름이라고 말합니다(Bill Venners와의 인터뷰). 다른 인터뷰에서도 비슷한 말을 한 것으로 기억하며, 그렇다고 더 나은 이름을 제시한 적도 없는 것으로 알고 있습니다. 어쨌든, 비록 자원 획득이 초기화 시점에서 일어나지 않았다고 해도 소멸자에서 자원을 해제하는 기법은 여전히 유효하고 유용하다는 점에서^[1], 그런 기법을 RAII라고 부르는 것은 그리 적합하지 않은 것은 사실입니다. 그래서 “scope guard” 같은 용어를 사용하는 경우도 있고요.

덧붙여 말하자면, 앞에서 말한 ‘관점’이 단지 RAII를 제대로 해석하는 데 필요한 것은 물론 아닙니다. 이런 관점은 거창하게 말하면 코드의 정확성 검증이나 보장에 큰 도움이 되고, 실용적으로 표현하자면 “제대로 사용하기는 쉽고 잘못 사용하기는 어려운” 클래스를 만드는 데에도 도움이 될 것입니다. 이 주제에 대해서도 언제 한 번 글을 써보겠습니다.

마지막으로 한 마디 더…. 언급한 포럼 논의에서는 예외와 오류 처리에 관한 논의를 자제해 달라고 했지만^[2], 사실 RAII를 이야기하면서, 그리고 “생성이 완료된 객체는 유효한 객체이어야 하고 유효하지 않은 객체가 생성되어서는 안 된다”는 관점으로 객체를 고찰할 때 예외에 대한 이야기를 빼놓는 것은 예외 입장에서는 서운한 일일 것입니다. 이와 관련해서 comp.lang.c++.moderated에 Andrei Alexandrescu(Loki 라이브러리와 Modern C++ Design 저자)가 올린 질문 “Are throwing default constructors bad style, and if so, why?”에서 시작된 논의가 있는데, 곱씹어 볼만한(그리고 앞에서 언급한 GpgStudy 포럼 논의에서 다루지 못한) 부분들이 많이 있습니다. 앞의 ‘관점’에 대한 글을 쓰게 된다면(아마도), 예외에 대한 이야기도 당연히 포함될 것입니다.