러스트와 운영 체제의 재발명
Source: Dev.to
왜 러스트가 현대 운영 체제의 핵심이 되고 있는가 — 리눅스부터 윈도우 11까지
수십 년 동안 운영 체제를 만드는 사람들은 악마와 계약을 맺었다. 최고의 성능을 얻는 대가로 메모리 버그가 난무하는 소프트웨어를 받아들이는 것이었다. 커널은 C와 C++가 지배했는데, 이 언어들은 프로그래머에게 하드웨어에 대한 직접적이고 원시적인 제어권을 주었기 때문이다. 그 대가로 나타난 취약점은 너무 지속적이어서 업계는 결국 이것이 인재 문제가 아니라 언어 문제라는 결론에 이르렀다.
러스트는 그 계약을 깨뜨리려는 산업 차원의 시도다.
Mozilla 안에서 시작된 실험이 이제는 커널, 드라이버, 하이퍼바이저, 클라우드 플랫폼 등에서 필수적인 기반 인프라가 되었다. 러스트는 이제 모험적인 개발자를 위한 호기심거리가 아니다. 점점 더 많은 진지한 시스템 소프트웨어가 러스트로 작성되고 있다. 그 이유는 단순하다: 러스트는 C와 맞먹는 성능을 제공하면서, 재앙적인 버그군을 구조적으로 불가능하게 만든다.
이것은 작은 주장이 아니다. 한 세대에 걸친 시스템 프로그래밍 분야에서 가장 중요한 발전이다.
운영 체제는 전체 컴퓨팅 스택의 가장 아래에 자리한다. 메모리 할당, 프로세스 스케줄링, 하드웨어 통신, 파일 시스템, 네트워킹, 드라이버, 가상화, 보안을 모두 담당한다. 이 모든 것이 50년 넘게 거의 C로 작성되어 왔다.
C가 매력적인 이유는 명확하다. 빠르다. 금속에 가깝게 컴파일된다. 추상화 오버헤드가 거의 없다. 프로그래머가 하드웨어에서 가능한 모든 성능을 끌어내기 위해 필요한 제어권을 제공한다.
하지만 C의 실패 모드는 재앙적이다. 프로그래머를 전적으로 신뢰하고, 프로그래머는 인간이다. 그 결과 버퍼 오버플로, use‑after‑free, 널 포인터 역참조, 데이터 레이스, 정의되지 않은 동작 등이 발생한다. 이는 드문 예외 상황이 아니라, 매년 생산 소프트웨어에서 가장 큰 치명적 취약점의 근원이다.
Microsoft와 Google은 각각 자체 심각한 보안 취약점 중 약 70%가 메모리 안전성 실패에서 비롯된다고 독립적으로 추정했다. NSA는 C와 C++에서 벗어나라는 지침을 발표했으며, 미국 정부 사이버 보안 기관인 CISA도 같은 입장을 밝혔다.
수십 년간 패치를 반복한 결과, 불편하지만 피할 수 없는 결론에 도달했다: 문제는 프로그래밍 모델 자체에 있다. 더 나은 엔지니어, 더 철저한 코드 리뷰, 더 좋은 도구가 피해를 줄일 수는 있지만, 근본적인 오류를 없앨 수는 없다. 진정한 해결책은 처음부터 그런 오류를 불가능하게 만드는 언어이다.
러스트는 “메모리 오류를 런타임이 아니라 컴파일 타임에 잡는다”는 핵심 아이디어를 중심으로 설계되었다.
러스트는 소유권, 빌림, 수명(lifetime)이라는 시스템을 통해 프로그램 전체에서 메모리 사용을 추적한다. 모든 값은 정확히 하나의 소유자를 가진다. 참조는 엄격히 제어된다. 가변 접근은 다른 살아있는 참조와 동시에 존재할 수 없다. 데이터 레이스는 관습이나 규율이 아니라, 규칙을 위반하면 컴파일러가 코드를 빌드하지 않음으로써 구조적으로 방지된다.
특히 러스트는 가비지 컬렉터 없이 이를 구현한다. 가비지 컬렉터는 예측할 수 없는 일시 정지와 런타임 오버헤드를 도입해 커널이나 저수준 시스템 코드에 부적합하다. 러스트는 안전성을 런타임 관리가 아니라 컴파일 타임 분석으로 달성하므로, 결과 바이너리는 C와 비슷한 성능을 유지하면서도 가볍다.
이것이 러스트의 핵심 철학적 전환이다: 올바름이 언어 설계 자체에 포함된다. 컴파일러는 단순히 코드를 번역하는 것이 아니라, 메모리 사용에 대한 계약을 강제한다. 컴파일이 통과하면 그대로 배포한다. 컴파일러가 막아버린 버그는 바이너리 안에 존재하지 않는다.
시스템 프로그래밍에서는 안전성은 속도를 희생한다는 전제가 오래전부터 있었다. Java나 Go 같은 가비지 컬렉션 언어는 안전하지만 커널 작업에는 너무 무겁고 일시 정지가 예측 불가능하다. C는 빠르지만 위험하다. 수십 년 동안 그 사이에 놓인 선택지는 없었다.
러스트는 그 사이에 있다.
러스트가 강제하는 규칙
- 한 시점에 하나의 소유자만 존재한다
- 가변 참조와 다른 살아있는 참조가 동시에 존재할 수 없다
- 데이터 레이스는 타입 시스템에 의해 방지된다
- 잘못된 메모리 접근은 구조적으로 어렵게 만든다
실제로 이는 커널 권한 상승 버그, 메모리 손상 공격, 레이스 컨디션 악용, 원격 코드 실행 취약점 등 광범위한 공격을 가비지 컬렉션 오버헤드 없이, 하드웨어 수준 제어를 포기하지 않고 차단한다.
그 조합은 이전에는 존재하지 않았다. 그 의미는 엄청나다.
Linux 커널은 30년 동안 C 단일 문화였다. 유지보수자들은 대안 언어를 꺼려했는데, 이는 커널이 매우 복잡하고 호환성이 중요하며 새로운 언어 도입이 실질적인 위험을 수반하기 때문이다.
그럼에도 2022년, 러스트 지원이 Linux 커널에 병합된 것은 진정한 역사적 순간이었다. 세계에서 가장 보수적이고 영향력 있는 소프트웨어 프로젝트 중 하나인 Linux는 이제 C만으로는 안전한 미래 개발이 충분하지 않다는 점을 공식적으로 인정한 것이다.
목표는 Linux 전체를 러스트로 다시 쓰는 것이 아니다. 그것은 무모하고 무의미한 일이다. 목표는 보다 외과적인 접근이다: 새로운 드라이버를 러스트로 작성하고, 안전이 중요한 서브시스템을 강화하며, 새로운 코드의 취약점 밀도를 낮추는 것이다. 디바이스 드라이버는 전통적으로 가장 위험한 커널 구성 요소 중 하나다. C로 작성된 버그가 있는 드라이버는 시스템 전체를 다운시킬 수 있다. 러스트는 그런 버그를 작성하기 어렵게 만든다.
이 변화는 확산되고 있다. Linux 배포판들은 러스트 기반 커널 모듈, init 시스템, 네트워킹 도구, 패키지 매니저, 임베디드 환경 등을 실험하고 있다. 모멘텀은 점진적이지만 방향은 명확하다.
Linux가 러스트를 받아들인 것이 놀라웠다면, Microsoft가 같은 길을 걷는 것은 더욱 눈에 띈다. Windows는 수십 년에 걸친 C와 C++ 내부 구조 위에 구축되었다. 이를 바꾸는 일은 비용이 많이 들고 위험하며 느리다. 그럼에도 Microsoft는 진행하고 있다.
핵심은 보안이다. Windows는 전 세계에서 가장 표적이 되는 운영 체제다. 메모리 취약점은 여전히 주요 공격 벡터다. Microsoft 보안팀은 Google, NSA, Linux 커뮤니티와 동일한 결론에 도달했다: 안전하지 않은 언어에서 벗어날 수는 없다. 언어 자체가 더 안전한 동작을 강제해야 한다.
러스트는 이제 보안이 중요한 Windows 구성 요소, 저수준 시스템 유틸리티, 인증 인프라, 네트워킹 레이어, 그리고 Windows 생태계와 연결된 클라우드 서비스에 포함되어 있다. Microsoft는 러스트 도구와 생태계에도 대규모 투자를 진행해, 언어 개발에 기여함으로써 전체 산업에 이익을 주고 있다.
메시지는 명확하다: 현대 운영 체제 보안은 개발자 규율에만 의존할 수 없다. 언어가 무거운 짐을 들어야 한다.
클라우드 인프라가 운영 체제에 요구하는 바를 바꾸면서 C의 약점은 더 이상 무시할 수 없는 문제가 되었다. 현대 시스템은 초대규모 데이터 센터, 컨테이너 오케스트레이션 플랫폼, 가상화 레이어, 엣지 디바이스, 분산 마이크로서비스 등을 동시에, 대규모 동시성으로 실행한다. C 기반 동시성은 악명 높게 위험하다. 레이스 컨디션과 안전하지 않은 공유 메모리 접근은 시스템 규모가 커질수록 기하급수적으로 위험해진다.
러스트의 동시성 모델은 가장 큰 강점 중 하나다. 스레드 안전성은 타입 시스템 자체에 의해 보장된다. 이는 가비지 컬렉션의 성능 오버헤드나 언어 수준 락의 런타임 비용 없이도 더 안전한 병렬 처리와 보다 신뢰할 수 있는 인프라를 가능하게 한다.
이 때문에 컨테이너 런타임, 스토리지 시스템, 네트워킹 레이어, 가상화 플랫폼 등을 구축하는 클라우드 인프라 기업들이 러스트를 일찍이 적극적으로 채택했다. 운영 체제도 같은 요구에 맞게 진화하고 있다.
러스트의 부상은 단순히 개발자 트렌드가 아니다. 정부와 산업계 최고층에서 추진되고 있다. Google, Microsoft, NSA, 그리고 CISA 모두…