모두가 Rust로 갈아탈 때, 거꾸로 Zig를 택한 팀들

지난 몇 년간 시스템 프로그래밍 세계의 공식은 하나였습니다. “C/C++을 쓰고 있다면 Rust로 갈아타라.” 메모리 안전성, 강력한 타입 시스템, 활발한 커뮤니티까지. Rust는 사실상 차세대 표준처럼 여겨졌는데요. 그런데 최근 흥미로운 역주행이 눈에 띕니다. Rust에서 Zig로 넘어간 팀들의 이야기입니다. 모두가 한 방향으로 달릴 때 반대로 가는 사람들에겐 대개 그럴 만한 이유가 있습니다.

시작하기 전에 솔직히 짚고 넘어가겠습니다. 이번 주제는 최근 30일 사이의 활발한 커뮤니티 신규 논쟁이 많지 않았습니다. 그래서 이 글은 실시간 화제라기보다, 지난 1~2년간 개발자 커뮤니티에 꾸준히 쌓여온 논의와 실제 사례들을 정리하고 해석하는 쪽에 가깝습니다. 최신 속보를 기대하셨다면 이 점 먼저 양해 부탁드립니다.

왜 Rust가 “정답"이 됐었나

먼저 Rust가 왜 그렇게 사랑받았는지 짚어야 반대편 이야기가 이해됩니다. Rust의 핵심 무기는 소유권(ownership) 시스템입니다. 컴파일 시점에 누가 어떤 메모리를 소유하는지 추적해서, 잘못된 접근을 아예 빌드 단계에서 막아버립니다.

쉽게 말하면 이렇습니다. C언어는 “총을 줄 테니 알아서 조심하라"는 방식입니다. Rust는 “안전장치를 채운 채로 총을 주고, 규칙을 안 지키면 방아쇠 자체가 안 당겨진다"는 방식이고요. 덕분에 메모리 관련 버그, 즉 실무에서 가장 잡기 어렵고 보안 취약점의 상당수를 차지하는 문제들을 원천 차단합니다.

그래서 마이크로소프트, 구글, 아마존 같은 대기업이 앞다퉈 Rust를 도입했습니다. 심지어 리눅스 커널에도 Rust 코드가 들어가기 시작했죠. 이 정도면 “논쟁 끝, Rust 승리"처럼 보입니다. 그런데 바로 이 지점에서 일부 팀들이 다른 목소리를 냈습니다.

그들이 Rust를 떠난 이유

Zig로 넘어간 팀들의 불만은 대체로 세 가지로 압축됩니다.

첫째는 컴파일 시간입니다. Rust는 안전성을 보장하기 위해 컴파일러가 엄청난 검증 작업을 합니다. 문제는 프로젝트가 커질수록 빌드가 느려진다는 점입니다. 코드 한 줄 고치고 결과를 확인하는 데 수십 초에서 수 분씩 기다리는 경험은 개발자의 집중력을 갉아먹습니다. Zig는 이 부분에서 확연히 빠른 편이라는 평가가 많습니다.

둘째는 복잡도입니다. 소유권과 라이프타임(lifetime) 개념은 강력하지만, 동시에 진입 장벽이 높습니다. “borrow checker와 싸운다"는 표현이 커뮤니티의 오랜 밈일 정도인데요. 컴파일러를 만족시키기 위해 코드를 이리저리 뜯어고치는 시간이, 정작 만들려던 기능에 쓰는 시간보다 길어지는 순간이 옵니다. 어떤 팀에겐 이 세금이 너무 컸습니다.

셋째는 C와의 상호운용입니다. Zig는 C 코드를 별도 바인딩 없이 거의 그대로 가져다 쓸 수 있게 설계됐습니다. 기존 C 자산이 많은 프로젝트라면 이건 결정적인 장점입니다. Zig를 C 컴파일러 대용으로 쓰는 팀이 있을 정도니까요.

Zig는 뭐가 다른가

그럼 Zig는 어떤 언어일까요. 한마디로 “현대적으로 다시 쓴 C”에 가깝습니다. Rust처럼 소유권으로 안전을 강제하지 않습니다. 대신 개발자에게 통제권을 돌려주되, 위험한 부분을 명시적으로 드러내는 방식을 택했습니다.

대표적인 게 메모리 할당입니다. Zig에서는 메모리를 할당하는 함수가 반드시 allocator를 인자로 받습니다. 어디서 메모리를 쓰는지 코드에 대놓고 드러나는 구조입니다. “숨겨진 마법이 없다(no hidden control flow)“는 게 Zig의 철학인데요. 코드를 읽으면 실제로 무슨 일이 일어나는지 그대로 보인다는 뜻입니다.

물론 대가가 있습니다. Zig는 Rust가 자동으로 막아주던 메모리 오류를 개발자 책임으로 되돌립니다. 안전장치를 일부 내려놓는 대신 단순함과 속도, 투명함을 얻는 거래입니다. 여기서 중요한 건, 이게 “더 좋은 선택"이 아니라 “다른 선택"이라는 점입니다.

진짜 교훈: 언어에 정답은 없다

이 사례에서 얻을 교훈은 “Zig가 Rust보다 낫다"가 아닙니다. 오히려 정반대입니다.

Rust를 버린 팀들의 이야기를 자세히 보면, 대부분 자신들의 상황에 맞춰 결정했습니다. 팀 규모가 작고, 빠른 반복이 중요하고, 기존 C 코드가 많고, 멤버들이 시스템 프로그래밍에 이미 능숙한 경우. 이런 조건이라면 Rust의 안전장치보다 Zig의 단순함이 더 큰 가치를 줄 수 있습니다.

반대로 대규모 팀, 신입이 계속 합류하는 환경, 보안이 생명인 도메인이라면 Rust의 엄격함이 오히려 축복입니다. 컴파일러가 실수를 막아주는 게 사람이 리뷰로 잡는 것보다 훨씬 싸게 먹히니까요. 실제로 대기업들이 Rust를 택한 이유가 바로 이겁니다.

그리고 언어 이주 자체의 비용도 잊지 말아야 합니다. 잘 돌아가는 코드를 다른 언어로 다시 쓰는 건 엄청난 리스크입니다. 새 버그가 생기고, 팀이 새 언어를 익히는 데 시간이 들고, 그동안 신기능 개발은 멈춥니다. “느려서” “복잡해서” 같은 이유만으로 재작성에 뛰어들었다가 후회하는 사례도 많습니다.

마무리

기술 커뮤니티는 종종 “무엇이 정답이냐"를 두고 싸웁니다. 하지만 Rust에서 Zig로 넘어간 팀들이 주는 메시지는 명확합니다. 도구는 유행이 아니라 맥락으로 골라야 한다는 것입니다. 남들이 다 간다고 따라가는 것도, 남들과 다르다고 반대로 가는 것도 그 자체론 이유가 되지 못합니다.

여러분의 팀은 지금 어떤 기준으로 언어와 도구를 고르고 있나요. 혹시 “요즘 다들 쓰니까"라는 이유가 가장 크진 않았나요. 진짜 물어야 할 질문은 “이게 최고의 언어냐"가 아니라 “이게 우리 문제에 맞는 언어냐"일지도 모릅니다.