Rust는 중간 수준 중간 표현(MIR) 생성 단계에서 drop elaboration을 사용하여 리소스 관리를 처리한다. 제어 흐름에 따라 변수의 초기화가 조건적일 수 있는 경우—예를 들어, match 분기나 if 문에서—컴파일러는 스택에 변수와 함께 부울 drop flag(또는 drop marker로도 알려져 있음)를 삽입한다.
다음과 같은 조건부 초기화를 고려해보자:
let resource: File; if packet.is_control() { resource = File::create("log.txt")?; } // resource는 조건부로 초기화된다
이 플래그는 런타임에서 초기화 상태를 추적한다. 컴파일러는 이 플래그를 체크한 후 소멸자를 실행하도록 MIR을 변환한다. 만약 플래그가 초기화되지 않았음을 나타내면 drop glue가 건너뛰어진다. 이 메커니즘은 각 초기화된 값에 대해 Drop::drop이 정확히 한 번 호출되도록 보장하여, 서로 다른 분기가 값을 이동하거나 다양한 상태로 남길 때 이중 해제 및 사용 후 해제를 방지한다.
고성능 네트워크 패킷 파서를 개발하고 있다고 가정하자. 이 경우, File 디스크립터나 Buffer 핸들과 같은 리소스는 프로토콜 헤더에 따라 조건부로 획득된다. 이 시스템은 매초 수백만 개의 패킷을 처리하며, 제로 복사 작업과 결정론적 지연이 필요하다.
파서는 패킷 타입이 Control일 때만 로그 파일을 열어야 하며, 핸들을 포함하는 확장된 구조체를 반환해야 한다. 만약 타입이 Data이면 핸들은 초기화되지 않은 상태로 남는다. 이런 상황에서 Drop 구현을 수동으로 관리하는 것은 오류가 발생하기 쉬우며, 하나의 분기에서 초기화 상태 체크를 잊으면 유효하지 않은 파일 디스크립터를 닫거나 구조체가 범위를 벗어날 때 이중 닫기를 초래할 수 있다.
한 가지 가능한 해결책은 File을 **Option<File>**으로 감싸는 것이다. 이 접근법은 안전하고 관용적이지만, 매 접근마다 차별화 체크를 위한 런타임 오버헤드를 도입하고 Option 태그로 인해 메모리 소비가 증가한다. 높은 처리량을 요구하는 파싱 루프에서는 이 추가 메모리 트래픽이 캐시 지역성을 감소시키고 성능에 실제 영향을 미친다.
또 다른 해결책은 **std::mem::MaybeUninit<File>**을 사용하고 구조체 내부에 수동 부울 추적 플래그를 결합하는 것이다. 이는 Option 오버헤드를 제거하지만, 플래그를 체크하고 ptr::drop_in_place를 호출하기 위해 unsafe 코드를 구현해야 한다. 이 접근법은 플래그가 실제 초기화 상태와 비동기화되는 경우 정의되지 않은 동작의 위험이 있으며, 특히 패닉 언와인딩 중에 코드 유지 관리가 상당히 복잡해진다.
선택된 해결책은 Rust의 컴파일러 생성 drop 플래그를 활용하는 것으로, 변수를 일반 File로 선언하고 특정 match 분기 내에서만 할당함으로써 이루어진다. 이렇게 하면 컴파일러는 런타임에서 초기화 상태를 추적하는 숨겨진 부울 플래그를 MIR 내에서 생성할 수 있다. 컴파일러는 소멸자를 호출하기 전에 이러한 플래그를 체크하는 삽입 코드를 작성해 수동 개입이나 unsafe 블록 없이 결정론적 정리를 보장하며, 최적화 패스를 거치면서 초기화가 완전하다고 증명되면 플래그가 완전히 제거될 수 있다.
파서는 Option 접근법에 비해 메모리 소비가 15% 줄어들었고, 정의되지 않은 동작에 대해 Miri 검증을 통과했다. unsafe 코드 블록의 제거는 보안 리뷰를 위한 감사 표면적을 상당히 줄였고, 미래의 유지보수자를 위한 코드베이스도 단순화하였다.
drop elaboration은 여러 값이 스택에서 조건부로 초기화될 때 패닉 언와인딩과 어떻게 상호 작용하는가?
언와인딩 중에 런타임은 어떤 값이 드롭할 수 있는지 알아야 한다. Rust는 MIR에서 패닉 착륙 패드에 drop 플래그를 확장한다. 각 착륙 패드는 스코프 내의 변수 드롭 플래그를 읽어 어떤 소멸자를 실행할지 결정한다. 후보자들은 패닉 중 모든 드롭이 단순히 생략된다고 가정하지만, Rust는 복잡한 조건부 분기를 탐색하는 동안에도 초기화된 값이 모두 드롭되도록 보장한다. 컴파일러는 각 가능한 초기화 상태에 대해 별도의 정리 블록을 생성하여 스택 언와인딩 중 메모리 안전성을 유지하도록 한다.
const fn 컨텍스트는 drop 플래그를 사용할 수 있는가? 왜 또는 왜 안 되는가?
Const 평가는 MIR 인터프리터 내에서 전적으로 컴파일 시간에 발생한다. const fn은 힙 메모리를 할당할 수 없으며 실제 스택 언와인딩 없이 샌드박스 환경에서 실행되기 때문에, drop 플래그는 기술적으로 MIR에 존재하지만 다르게 작동한다. 이들은 상수 부울 값으로 평가된다. const 컨텍스트에서 값이 조건부로 초기화되면, 컴파일러는 초기화 상태를 컴파일 타임에 증명할 수 있어야 하며, 그렇지 않으면 const_err를 발생시킨다. const 컨텍스트의 drop 플래그는 초기화가 되지 않은 값에 대해 Drop이 호출되지 않도록 보장하며, 컴파일 타임 실행이 임의의 런타임 소멸자를 실행할 수 없도록 강제한다.
하나의 match 분기에서 값을 변수에서 이동해도 drop 플래그가 필요하지 않은 이유는 무엇인가? 반면 부분 초기화는 왜 필요한가?
값이 무조건 이동될 때, Rust는 원래 변수를 이동된 상태로 간주하고 초기화되지 않은 상태로 간주한다. 컴파일러는 특정 경로에 대해 소멸자가 실행되지 않아야 한다는 것을 정적으로 안다. 그러나 조건부 초기화의 경우—어떤 분기는 초기화되고 어떤 분기는 그렇지 않은 경우—컴파일러는 어떤 분기가 실행되었는지 컴파일 타임에 알 수 없다. 그러므로 런타임 drop 플래그가 필요하다. 후보자들은 이를 NLL(비어있지 않은 생명 주기)에 혼동하여 빌림 검사기가 이를 처리한다고 생각하지만, 실제로는 NLL이 빌림을 처리하고 drop elaboration이 초기화 상태를 처리한다는 점에서 중요한 차이가 있다. NLL은 빌림을 일찍 끝내지만, drop 플래그는 어떤 값이 드롭될 수 있는지를 추적한다.