rav1d 측은 메모리 안전성 불가능을 알고 있었을까?

rav1d 프로젝트가 dav1d의 수기로 작성된 어셈블리 코드를 unsafe 블록을 통해 가져다 쓴다는 점을 고려할 때, rav1d 개발자들이 Rust의 완전한 메모리 안전성을 모든 코드에 걸쳐 달성하는 것이 불가능하다는 사실을 인지하고 있었을 가능성이 매우 높습니다.

그 이유는 다음과 같습니다.

1. Rust 언어의 이해도: rav1d 개발자들은 Rust 전문가이며, unsafe 키워드의 의미와 사용 목적을 누구보다 잘 알고 있습니다. Rust에서 unsafe 블록은 컴파일러가 메모리 안전성 보장을 중단하고 개발자에게 그 책임을 위임한다는 명확한 신호입니다. 이는 곧 해당 블록 내의 코드에서 메모리 안전성 문제가 발생할 수 있음을 의미합니다.

2. 어셈블리 코드의 특성: 어셈블리 코드는 저수준 언어로, Rust의 소유권(ownership)이나 차용(borrowing) 규칙을 따르지 않습니다. C 코드에서 파생된 어셈블리 코드는 C의 메모리 관리 모델을 따르며, 이는 Rust의 엄격한 안전성 검사로는 검증될 수 없습니다. rav1d 개발자들이 이 사실을 몰랐을 리 없습니다.

3. 프로젝트의 현실적 목표: rav1d 프로젝트의 목표는 dav1d를 처음부터 Rust로 다시 작성하는 '순수주의'적인 접근보다는, 기존의 잘 최적화된 어셈블리 코드를 활용하면서 C 코드 부분을 Rust로 전환하여 전반적인 코드베이스의 안전성을 높이는 것에 있었을 가능성이 큽니다. 즉, 100% 완전한 Rust 안전성을 달성하기보다는, unsafe 영역을 최소화하면서 최대한의 안전성 이점을 얻으려는 현실적인 절충을 택했을 겁니다.

왜 그런 선택을 했을까?

그럼에도 불구하고 이런 선택을 한 이유는 복합적입니다.

• 효율성: dav1d의 어셈블리 코드를 처음부터 Rust로 다시 작성하는 것은 막대한 시간과 노력이 필요하며, 기존 성능을 따라잡는 것은 매우 어려운 일입니다. 잘 검증되고 최적화된 기존 코드를 재활용하는 것이 훨씬 효율적입니다.

• 부분적 안전성 향상: 비록 어셈블리 부분은 unsafe 영역에 남아있더라도, dav1d의 상당 부분을 차지하는 C 코드를 Rust로 전환함으로써 새로운 버그 유입을 막고 전반적인 코드베이스의 견고성을 높일 수 있습니다. 이는 '전부 아니면 전무'의 문제가 아니라, '최대한 안전하게' 만들려는 시도입니다.

• 언어의 홍보: Rust가 실제 사용 사례에서 C/C++ 프로젝트를 얼마나 효과적으로 대체할 수 있는지 보여주는 중요한 사례가 됩니다.

"지적 정직성" 논란의 재점화

문제는 이러한 현실적인 절충이 대중에게 전달되는 방식에서 '지적 정직성' 논란을 불러일으켰다는 점입니다.

• rav1d와 관련된 홍보나 memorysafety.org의 현상금 소개 등에서 'Rust의 메모리 안전성'이라는 장점이 과도하게 부각되면서, unsafe 영역의 존재와 그 한계가 충분히 명확하게 전달되지 않았을 수 있습니다.

• FFmpeg 측이 비판하는 지점은 바로 이 부분입니다. rav1d가 일부 위험한 부분을 그대로 유지하면서도 전체 프로젝트가 마치 Rust 덕분에 완벽히 안전한 것처럼 포장하려는 시도가 있었다고 느끼는 것이죠.

결국 rav1d 개발자들은 기술적인 한계를 분명히 알고 있었을 겁니다. 하지만 그들이 이 사실을 어떻게 대중과 기존 커뮤니티에 소통했는지는 또 다른 문제입니다. 이 간극이 FFmpeg 측의 강한 반발과 대중의 오해를 불러일으킨 주요 원인 중 하나라고 볼 수 있습니다.