부채가 쌓이는 언어들

기본적으로 메모리 안전성 (Memory Safety)이 보장되지 않는 모든 언어는 청구서를 쌓아가고 있습니다. 해당 언어로 코드를 작성하는 팀은 매일 디버깅 시간과 사고 대응이라는 이자를 지불합니다. 결국 원금 상환 시기가 도래하게 됩니다.

Rust는 메모리 안전성을 기본값으로 설정하고, 안전하지 않은 코드 (Unsafe code)를 선택적(opt-in)이며 검색 가능한(greppable) 영역으로 만드는 유일한 프로덕션 시스템 언어입니다. Go, Zig, C, C++는 이 범주에 속하지 않습니다. 이들은 주의를 기울일 수 있는 도구들을 제공하지만, 주의를 기울이는 것만으로는 보장할 수 없습니다.

"선택적 안전성 (Opt-in safety)"은 마치 트레이드오프 (Tradeoff)처럼 들릴 수 있습니다. 하지만 그렇지 않습니다. 그것은 유예된 비용입니다. 저는 2015년 5월 Rust 1.0이 출시된 이후의 모든 CVE를 전수 조사하여, 안전한 Rust (Safe Rust)가 컴파일 타임에 방지할 수 있었던 것이 무엇인지 확인했습니다. 221,860건 중 36,942건이었습니다. 이는 지난 10년 동안 발생한 모든 CVE의 16.7%가 언어적 기능 하나로 제거될 수 있었음을 의미합니다. 2017년에는 그 비중이 25.8%로 정점을 찍었으며, 취약성 네 건 중 한 건꼴이었습니다. 주요 카테고리는 다음과 같습니다: 경계 외 쓰기 (Out-of-bounds writes) 11,800건, Heartbleed를 포함한 경계 외 읽기 (Out-of-bounds reads) 6,681건, 버퍼 오류 (Buffer errors) 6,660건, 그리고 Use-after-free 4,804건이었습니다.

이는 대략 369,000시간의 정리 작업, 177 개발자 연수(developer-years), 그리고 3,700만 달러의 인건비에 해당합니다. 컴파일러가 컴파일을 거부할 수 있는 부류의 버그를 고치기 위해 20명 규모의 보안 팀이 9년 동안 매달린 셈입니다.

그 비중은 감소하고 있습니다. 2017년 25.8%에서 2025년 7.9%로 줄었습니다. 도구와 관행이 개선되고 있기 때문입니다. 하지만 그 수치는 여전히 매년 수천 건의 예방 가능한 메모리 버그가 발생하고 있음을 보여줍니다.

청구서가 도착한 최신 사례는 Bun입니다. Jarred Sumner는 타당한 이유로 2021년에 Zig를 선택했고, Node를 능가하는 JavaScript 런타임을 출시했지만, 그 후 수년간 메모리 안전성 디버깅 세금을 지불하며 시간을 보냈습니다. 며칠 전, 팀은 300개의 규칙이 담긴 Zig-to-Rust 포팅 가이드와 AI로 번역된 966,000줄의 Rust 코드를 커밋했습니다. PR 노트에는 메모리 버그로 인해 팀이 엄청난 양의 개발 시간을 소모했다고 명시되어 있습니다. 이것이 바로 그 비용을 지불한 사람들이 항목별로 정리한 청구서입니다.

이 마이그레이션 (Migration)이 가능했던 유일한 이유는 AI 에이전트 (AI agents)가 번역을 수행할 수 있기 때문입니다. 5년 전이었다면 이 포팅 (Port) 작업은 수년이 걸리는 인간의 노력이 필요했을 것이고, Bun은 영원히 Zig에 머물렀을 것입니다. 부채를 축적하는 선택으로부터 탈출하는 비용이 급격히 낮아졌습니다. 이는 현재 그러한 선택을 안고 있는 모든 팀의 계산법을 변화시킵니다.

2026년의 그린필드 (Greenfield) 시스템은 특별한 이유가 없는 한 Rust를 선택할 것입니다. 기본값이 뒤집혔습니다. 여전히 안전하지 않은 (Unsafe) 쪽에 베팅하고 있는 팀들은, 나중에 AI 에이전트가 해결 비용을 지불하게 될 청구서를 쌓아가고 있는 중입니다.