Canonical은 C에서 Rust로의 AI 번역을 후원합니다 - 오픈 소스가 메모리 공격으로 전환합니다

우분투가 AI 기반 자동 C→Rust 변환 프로젝트를 추진 중입니다. 목표는 단순히 컴파일만 되는 코드가 아니라, 정말 안전한 Rust 코드를 만드는 것입니다.

실제 사례

고전적인 버그부터 시작해 보겠습니다: C로 작성된 시스템 데몬에서 발생하는 버퍼 오버플로우입니다. 이 버그는 수정할 수 있지만, C는 기계적으로 이러한 오류가 발생하지 않도록 보장할 수 없기 때문에 6개월 후 다른 형태로 다시 나타날 위험이 있습니다. 이제 동일한 코드를 Rust로 재작성했다고 상상해 보세요. Rust의 컴파일러는 이 버그를 구조적으로 불가능하게 만듭니다.这就是 Canonical(Ubuntu 개발사)이 재정적으로 지원하는 야심찬 프로젝트입니다: 수백만 줄의 C 코드를 안전하고 자동으로 Rust로 번역하는 것, 그리고 이를 위해 인공지능을 활용합니다.

왜 이것이 간단하지 않은가

C에서 Rust로의 자동 번역은 이미 존재합니다. 수년간 c2rust라는 도구가 이 작업을 수행해 왔습니다. 문제는: 이 도구가 생성하는 Rust는 문법적으로는 유효하지만 unsafe가 가득하다는 점입니다. 이는 보안 관점에서 봤을 때 이점이 전혀 없습니다. 구문만 바뀌었을 뿐, 보장되는 안전성은 그대로인 셈입니다.

Canonical이 지원하는 프로젝트가 목표로 하는 것은 idiomatic하고 안전한 Rust입니다. Rust의 타입 시스템(ownership, borrowing, lifetimes)을 활용하여 컴파일 시점에 보안 불변량을 표현하고 검증하는 코드입니다. 이는 근본적으로 어려운 문제입니다. C와 Rust는 동일한 사고 모델을 공유하지 않기 때문입니다:

// C - 사용 맥락에 따라 올바를 수도, use-after-free가 발생할 수도 있음
char* get_value(struct Map* m, const char* key) {
 return hashmap_get(m, key); // m이 수정되면 포인터가 무효화될 수 있음
}

// Rust - 컴파일러가 m을 수정하지 못하도록 보장
fn get_value<'a>(m: &'a HashMap<&str, String>, key: &str) -> Option<&'a String> {
 m.get(key) // lifetime 유효성은 컴파일러가 보장
}

인공지능은 이 두 함수가 기계적으로 동등하지 않다는 점을 이해해야 합니다. 그리고 단순한 번역은 unsafe 블록을 생성할 뿐, 진정한 마이그레이션이 아니라는 점도요.

부차적인 논의: 오픈 소스에서 인공지능의 다음 단계

여기서 우리는 자유 소프트웨어를 둘러싼 논쟁의 직접적인 반향을 확인할 수 있습니다. 리누스 토르발스는 리눅스 커널에 대해 인공지능이 지원하는 기여를 환영하기로 결정했습니다. 반대자들은 포크할 수 있습니다. Canonical은 동일한 실용적인 논리를 따릅니다. 인공지능을 대량 현대화 도구로 활용하는 것입니다. 위협으로 여기지 않는 거죠.

진짜 문제는 인간의 검증입니다. 누가 생성된 Rust를 다시 검토할까요? 누가 C 원본의 의미론적 의미를 보존하는지, 특히 경계 조건에서의 동작까지 보장할까요? 95%는 좋은 Rust를 생성하지만 5%는 미묘하게 잘못된 코드를 생성하는 도구는 위험합니다. 왜냐하면 거짓 보장을 제공하기 때문입니다.

기대되는 결과

이 프로젝트가 약속을 지킨다면, 시스템 계층의 Rust 전환을 가속화할 수 있을 것입니다. 이미 안드로이드, 윈도우, 리눅스 커널, OpenSSL 등에서 진행 중인 움직임입니다. Canonical이 우분투를 대상으로 한다면, 이는 수백만 대의 서버에서 사용 중인 하위 계층에 직접적인 영향을 미치게 됩니다.