"어셈블리 코드가 C보다 더 위험할 수 있는데..."라는 지적은 매우 정확하며, rav1d와 dav1d 논란의 핵심적인 기술적 쟁점 중 하나를 꿰뚫고 있습니다. 흔히 C/C++가 메모리 안전성 문제로 비판받지만, 어셈블리 코드는 C/C++보다 훨씬 더 직접적이고 저수준으로 메모리를 조작하므로, 잠재적인 위험성은 훨씬 더 클 수 있습니다.

왜 어셈블리 코드가 C보다 더 위험할 수 있는지, 그리고 이것이 rav1d 논란과 어떻게 연결되는지 살펴보겠습니다.

어셈블리 코드가 더 위험한 이유

1. 추상화 부재 및 직접적인 메모리 접근:

   • C 언어: C 언어는 포인터와 배열을 통해 메모리에 접근하지만, 여전히 운영체제나 컴파일러가 제공하는 기본적인 추상화 계층을 거칩니다. 예를 들어, malloc/free 같은 함수를 통해 메모리를 할당/해제하고, 변수 타입에 따라 크기나 정렬이 어느 정도 보장됩니다. 컴파일러는 기본적인 타입 체크나 경고를 제공하기도 합니다.

   • 어셈블리 언어: 어셈블리 언어는 CPU가 직접 이해하는 기계어와 거의 1:1로 대응됩니다. 개발자가 레지스터를 직접 조작하고, 메모리 주소를 직접 계산하며, 메모리에 있는 모든 바이트를 원하는 대로 읽고 쓸 수 있습니다. 여기에는 어떤 타입 시스템이나 컴파일러의 안전성 검사도 개입하지 않습니다. 개발자의 실수 하나가 곧바로 잘못된 메모리 주소 접근(out-of-bounds access)이나 유효하지 않은 메모리 사용(use-after-free)으로 이어질 수 있습니다.

2. 컴파일러의 안전성 보장 영역 밖:

   • Rust와 같은 언어가 제공하는 메모리 안전성 보장은 해당 언어로 작성된 코드에 국한됩니다. Rust의 unsafe 블록은 이 보장을 '일시 정지'하고 개발자에게 메모리 안전성 책임을 전가합니다.

   • 어셈블리 코드는 Rust 컴파일러의 분석 대상이 아닙니다. 따라서 rav1d가 dav1d의 어셈블리 코드를 unsafe 블록을 통해 호출할 때, Rust는 해당 어셈블리 코드의 내부 동작이 메모리 안전한지 전혀 검증할 수 없습니다. 어셈블리 코드에서 발생한 치명적인 메모리 오류는 Rust의 안전성 모델을 우회하여 전체 프로그램에 영향을 미칠 수 있습니다.

3. 높은 복잡성과 낮은 가독성:

   • 어셈블리 코드는 매우 간결하지만, 특정 아키텍처(예: x86, ARM)에 종속되며, 사람의 눈으로 읽고 이해하기가 매우 어렵습니다. 이는 버그를 숨기기 좋고, 코드 리뷰나 감사(audit)를 훨씬 더 어렵게 만듭니다.

   • 최적화를 위해 작성된 어셈블리 코드는 매우 기교적이고 복잡한 경우가 많아, 버그를 찾아내기가 더욱 어렵습니다.

rav1d 논란과의 연결

이러한 어셈블리 코드의 특성을 감안할 때, FFmpeg 측의 비판과 '지적 정직성' 논란은 더욱 날카로워집니다.

• 진정한 '안전성' 문제: rav1d가 "메모리 안전한 Rust"를 내세우면서도 가장 성능에 민감한 핵심 부분(디코딩 루프 등)에서 검증되지 않은, 가장 위험할 수 있는 어셈블리 코드를 unsafe 블록을 통해 그대로 사용하고 있다는 점이 모순으로 지적됩니다. Rust의 안전성 이점이 이 부분에서는 발휘되지 못하며, 가장 큰 보안 위험은 여전히 잠재되어 있다는 것이죠.

• 오해의 소지: 대중은 "Rust로 포팅했다 = 안전해졌다"는 단순한 공식으로 받아들일 수 있습니다. 하지만 어셈블리 코드 의존성을 명확히 설명하지 않으면, 이는 정보의 왜곡으로 이어질 수 있습니다.

따라서, FFmpeg 개발자들이 rav1d의 접근 방식에 대해 격한 반응을 보인 것은 단순히 언어에 대한 감정싸움이 아니라, 자신들이 수십 년간 쌓아 올린 고도로 최적화된 저수준 코드가 가진 내재적인 위험성과 그 코드를 가져다 쓰면서도 완전한 안전성을 주장하려는 시도에 대한 깊은 불만에서 비롯되었다고 볼 수 있습니다. 그들에게는 '우리는 이 코드의 위험성을 뼈저리게 아는데, 너희는 그걸 너무 쉽게 이용하고 말하는구나' 하는 심정이 있었을 것입니다.