Rust를 떠나 Zig로 돌아간 개발자가 본 저수준 언어의 기준

Rust를 떠나 Zig로 돌아간 개발자가 본 저수준 언어의 기준

AI 뉴스 썸네일

Zig와 Rust 사이를 오간 개발자의 글이 개발 언어 선택에서 꽤 현실적인 질문을 던져요. 빠른 실행 속도나 문법 취향보다, 생태계 안정성, 메모리 모델, 오픈소스 거버넌스, LLM 생성 코드 정책이 언어 신뢰에 얼마나 영향을 주는지가 더 선명하게 보여요.

728x90

핵심 요약

구분	핵심	왜 볼 만한가요
언어 선택	글쓴이는 Zig에서 Rust로 옮겼다가 다시 Zig를 진지하게 검토해요	저수준 언어를 고를 때 성능보다 유지보수 비용이 먼저 보이기 때문이에요
Rust의 장점과 부담	Rust는 안정적인 생태계와 강한 메모리 모델을 줬지만, FFI와 크로스 컴파일, 숨은 할당에서 불편함을 남겼어요	안전한 언어가 항상 단순한 배포와 재사용으로 이어지지는 않는다는 점을 보여줘요
Zig의 현재 위치	Zig는 아직 1.0 이전이고 0.17.0에서도 빌드 시스템 변경이 예정돼 있어요	실험적인 언어를 실무 도구로 볼 때 어디까지 감수할지 판단하는 기준이 돼요
개발 문화	글쓴이는 Rust의 LLM 생성 코드 정책 논의와 거버넌스에 실망했고, Zig의 강한 금지 정책을 긍정적으로 봐요	요즘 오픈소스 프로젝트에서는 코드 품질뿐 아니라 커뮤니티 운영 방식도 기술 선택에 들어가요

1. Zig와 Rust 사이에서 드러난 선택 기준

Zig는 C의 불편함을 줄이려는 언어로 출발했어요. 글쓴이가 처음 Zig에 끌린 이유도 단순해요. 컴파일 타임 코드 실행, 명시적인 메모리 할당, 숨은 제어 흐름을 줄이는 태도가 C보다 현대적인 저수준 언어처럼 보였기 때문이에요. 2

하지만 초기 Zig는 언어와 표준 라이브러리가 자주 바뀌었어요. 몇 달 뒤 프로젝트를 다시 열면 코드를 크게 고쳐야 했고, 당시에는 여러 Zig 버전을 편하게 다루는 도구도 부족했어요. 결국 글쓴이는 안정된 생태계와 더 많은 예제를 가진 Rust로 옮겼어요. 1

Rust는 기대한 만큼 실용적인 대안이었어요. 배우기는 힘들었지만, 익힌 뒤에는 코드가 오래 버텼고, 라이브러리도 충분했어요. 특히 Rust의 메모리 모델은 더 적은 검사를 가진 언어를 쓸 때도 도움이 되는 사고방식을 만들어 줬다고 해요. 다만 Rust가 모든 불편을 없애지는 못했어요. FFI는 어렵고, 크로스 컴파일은 번거롭고, 메모리 할당이 코드 밖에서 숨어 보이는 지점은 저수준 도구를 만들 때 부담으로 남았어요. 2

글에서 흥미로운 대목은 기술 밖의 이유예요. 글쓴이는 Rust Foundation의 기업 회원 구조와 LLM 생성 코드 정책 논의를 보며 Rust 프로젝트에 대한 신뢰가 흔들렸다고 적어요. Zig 프로젝트는 LLM 생성 코드를 강하게 금지하고 있고, 글쓴이는 이 태도를 소프트웨어 품질을 지키려는 신호로 받아들여요. 3

2026년의 Zig도 완성된 언어는 아니에요. Zig 0.17.0은 빌드 시스템을 다시 깨뜨릴 예정이고, 표준 라이브러리도 계속 변하고 있어요. 그래도 글쓴이는 언어의 큰 감각은 2020년과 크게 다르지 않다고 봐요. 패키지 매니저가 생겼고, 의존성을 git과 tarball로 관리하고 벤더링하는 경험도 좋아졌다고 말해요. 2

메모리 안전성을 보는 관점도 Rust와 달라요. Zig는 Rust처럼 컴파일 타임에 메모리 안전을 강하게 보장하지 않아요. 대신 ReleaseSafe, assertion, 테스트, 퍼징으로 런타임 안전성과 단순성 사이의 균형을 잡으려 해요. 글쓴이는 이 방식이 Rust보다 항상 낫다고 말하지 않아요. 복잡한 타입 시스템과 긴 컴파일 시간이 감당할 만하면 Rust가 맞고, 단순한 모델과 폭넓은 재사용성을 더 중시하면 Zig가 맞을 수 있다고 봐요. 4

왜 중요한가요

이 글은 “Zig가 Rust보다 낫다”라는 선언보다, 저수준 언어를 고르는 기준이 얼마나 입체적인지 보여줘요. 언어가 빠른지, 안전한지, 문법이 마음에 드는지만으로는 부족해요. 프로젝트가 얼마나 자주 깨지는지, 도구가 버전 변화를 감당하게 해 주는지, 외부 라이브러리를 얼마나 믿을 수 있는지도 같이 봐야 해요. 2

Rust를 쓰는 팀이라면 이 글이 Rust를 버리라는 말로 읽히지는 않아요. 오히려 Rust가 왜 강한 선택지인지도 함께 확인할 수 있어요. 안정된 생태계, 엄격한 메모리 모델, 풍부한 도구는 여전히 큰 장점이에요. 다만 FFI, 크로스 컴파일, 빌드 대상 확장, 숨은 할당이 핵심 문제라면 Rust의 장점만 보고 넘어가기 어렵다는 점을 짚어 줘요. 1

Zig를 보는 팀에는 더 냉정한 체크리스트가 돼요. 1.0 이전 언어를 제품의 핵심에 넣으려면 빌드 깨짐과 표준 라이브러리 변경을 감수해야 해요. 반대로 작은 런타임, 명시적인 제어, C 대체 가능성, 단순한 모델이 중요하다면 지금의 Zig도 충분히 다시 볼 만해요. 2

LLM 생성 코드 정책 이야기도 가볍지 않아요. 오픈소스 프로젝트가 AI로 만든 코드를 어떻게 다루는지는 코드 품질, 저작권, 리뷰 비용, 커뮤니티 신뢰와 이어져요. 언어와 도구를 고를 때 이제는 문법과 성능뿐 아니라 프로젝트가 어떤 품질 문화를 지키는지도 함께 봐야 해요. 3

참고 자료

1. 다시 Zig로 돌아가기 - Zig → Rust → Zig — GeekNews
2. Returning to Zig — Anna Liberty
3. Strict No LLM/No AI Policy — Zig Code of Conduct
4. Zig is safer than unsafe Rust — zackoverflow.dev