다시 Zig로 돌아가기 - Zig → Rust → Zig

 (gracefulliberty.com)
1P by GN⁺ | ★ favorite | 댓글 2개
  • Zig는 C의 불편함을 줄이려는 낮은 수준 언어로 출발해, 명시적 메모리 할당과 숨은 제어 흐름 없음 같은 철학으로 다시 검토할 만한 언어가 됨
  • Rust는 Zig의 잦은 변경과 미성숙한 생태계에서 벗어날 실용적 대안이었지만, FFI·크로스 컴파일·숨은 할당 같은 지점에서 한계를 드러냄
  • Zig로 돌아온 결정에는 기술적 이유뿐 아니라, 거버넌스와 LLM 생성 코드 정책을 둘러싼 Rust 프로젝트에 대한 신뢰 저하도 작용함
  • 2026년의 Zig는 여전히 불안정하고 Zig 0.17.0이 빌드 시스템을 깨뜨릴 예정이지만, 언어 감각은 2020년과 크게 다르지 않고 패키지 관리 경험은 좋아짐
  • Zig는 Rust식 컴파일타임 메모리 안전성을 제공하지 않는 대신, ReleaseSafe·테스트·퍼징·assertion 철학으로 단순성과 런타임 안전성의 균형을 택함

Zig에 끌렸던 출발점

  • Zig는 2020년에 처음 접했고, 당시에는 컴파일타임 코드 실행과 단순한 추상화를 갖춘 작은 새 언어로 보였음
  • C를 배우며 컴퓨터를 직접 제어하는 감각은 좋았지만, 오래된 추상화와 부족한 도구가 불편했음
  • 새롭고 불안정했더라도 Zig는 C의 대체 언어를 약속했고, “다음 언어”를 배울 수 있다는 점이 매력적이었음
  • Andrew Kelley의 Software Should Be Perfect는 프로그래밍 언어와 소프트웨어를 보는 기준을 만들었음
    • 실패 가능한 명시적 메모리 할당
    • 숨은 제어 흐름 없음
    • 보편적 재사용성
  • Zig로 장난감 프로그래밍 언어, literate programming 도구, 웹 서버를 만들며 C보다 편하지만 위험 요소는 적은 언어처럼 느꼈음

Rust로 옮겨간 이유

  • Zig는 코드가 자주 깨졌고, 학생 신분으로 최신 언어 버전에 맞춰 프로젝트를 계속 고칠 시간이 부족했음
  • 당시에는 anyzig이 없어 한 시스템에서 여러 Zig 버전을 쉽게 다루기 어려웠음
  • 몇 달 만에 프로젝트로 돌아오면 이해하지 못한 큰 리팩터링을 해야 다시 동작하는 경우가 있었음
  • 생태계도 아직 작았음
    • 새 프로그래머로서 필요한 것을 모두 직접 구현할 역량이 부족했음
    • 라이브러리와 예제가 적었음
    • 표준 라이브러리가 계속 바뀌었음
    • 기본 문서도 불안정했음
  • Rust는 이미 수년간 안정화되어 있었고, 강한 생태계를 갖춘 언어였음
  • Rust 학습은 힘들었지만, 익히고 나면 코드가 안정적으로 동작했고 그 안정성이 중요했음
  • 빠르고 낮은 수준의 언어이면서 필요한 표현력을 제공했고, Zig에서 겪던 불안정성의 비용도 줄여줬음
  • Rust는 더 적은 내장 검사만 있는 언어를 쓸 때도 도움이 되는 메모리 모델을 형성하게 했음
  • panic이 없는 코드에서는 숨은 제어 흐름이나 가비지 컬렉터 없이 재사용 가능한 코드를 작성할 수 있었음
  • 다만 Rust는 메모리 할당을 숨기고 C와의 작업을 어렵게 만드는 면이 있었음

다시 Zig를 보게 만든 불만

  • Rust는 원하는 재사용 가능한 프로그램을 만들기에 완벽한 언어는 아니었음
    • FFI가 어려움
    • 크로스 컴파일이 번거로움
    • 숨은, 실패하지 않는 것으로 취급되는 메모리 할당이 부담스러움
    • LLVM에 묶여 있어 C만큼 많은 플랫폼을 지원하기까지 오래 걸리거나 불가능할 수 있음
  • 거버넌스도 불편한 지점으로 남았음
    • Rust Foundation에는 여러 거대 기업 foundation members가 있음
    • 세계 최대 기업들이 매년 수십만 달러를 제공하면 Rust 개발 방향에 영향을 줄 가능성이 있다고 봄
  • 오픈소스 커뮤니티에서 LLM 생성 코드를 받아들이는 프로젝트가 많아진 점이 충격으로 작용함
  • 여러 프로젝트에서 유지보수자와 사용자가 LLM 정책을 작성하거나 요구했음
  • Zig는 프로젝트에서 LLM을 완전히 금지했음
  • Rust는 설문을 진행했고 커뮤니티의 전반적 정서는 반LLM이었지만, 공식 정책을 바로 만들지는 않았음
  • Rust의 정책 제안에는 PR 댓글에서 다음 주제를 언급하지 못하게 하는 조항이 포함됐음
    • LLM의 장기적 사회·경제적 영향
    • LLM의 환경 영향
    • LLM 출력물의 저작권 상태
    • LLM 사용자에 대한 도덕적 판단
  • 해당 조항은 반발 이후 제거됐지만, 그런 조항이 있었다는 사실만으로 Rust 프로젝트에 대한 신뢰가 낮아짐
  • 정책 자체는 대부분 LLM을 제한하고 slop을 줄이는 내용이라 괜찮다고 봄
  • 이 경험이 몇 년 만에 Zig를 진지하게 다시 살펴보는 계기가 됨

2026년의 Zig

  • Zig는 여전히 불안정함
  • 웹에서 찾은 Zig 0.16.0 예제로 시작하려 했지만, 이미 오래된 예제였음
  • Zig에서 생산적으로 작업하려면 표준 라이브러리 소스 사본을 가까이 두고 익숙해지는 편이 가장 좋음
  • Zig 0.17.0은 곧 릴리스될 예정이며, 모든 프로젝트의 빌드 시스템을 깨뜨릴 예정임
  • 유지보수자들은 안정화로 이동하려고 하며, 이런 깨짐은 그 과정의 일부임
  • 다행히 언어 자체는 2020년 이후 크게 바뀌지 않았음
    • 대부분의 직감은 여전히 통했음
    • 라이브러리 일부는 재작업됐지만 코드는 읽기 쉬웠음
    • 현재 Zig 코드도 6년 뒤 알아볼 수 있을 것이라고 봄
  • 이제 Zig에는 패키지 매니저가 있음
    • 이전에는 의존성 관리에 git submodule을 사용했던 기억이 있음
    • 내장 도구가 훨씬 좋음
    • 프로젝트는 git과 tarball로 의존성을 정의할 수 있음
    • 벤더링이 쉽게 동작함
  • 생태계는 여전히 방대하지 않지만, Zig가 지향한 바도 방대한 생태계는 아님
  • 공식 패키지 레지스트리는 없고, 또 다른 NPM이나 crates.io가 필요하지 않다는 입장임
  • 현재 Zig는 적절한 균형을 이룬 것으로 평가됨

메모리 안전성을 보는 방식

  • Zig는 Rust와 같은 메모리 안전성 보장을 제공하지 않음
  • 이는 단순성을 위한 트레이드오프이며, Rust의 아핀 타입 복잡성이 안전성 이득만큼 가치 있지는 않다고 봄
  • 그렇다고 Zig가 안전성을 포기한 것은 아님
  • Zig is safer than unsafe Rust라는 관점에서는 unsafe Rust를 써야 하는 상황에서 Zig가 더 나은 선택일 수 있음
  • Zig는 언어를 더 안전하게 만들려는 작업도 진행 중임
    • 접근 방식은 unsafe 코드 구역이 아니라 릴리스 모드에 초점을 둠
    • 현재 Zig의 ReleaseSafe 모드는 assertion 실패 시 크래시하고 모든 메모리를 초기화함
    • Andrew Kelley는 ReleaseSafe에 Fil-C 같은 것을 포함하는 방향에 관심이 있음
  • 이런 방식은 unsafe를 피한 Rust의 컴파일타임 메모리 안전성을 제공하지는 않지만, 일부가 말하는 death spiral은 아니라고 봄
  • 메모리 안전성은 스펙트럼이며, 모든 상황에 가장 좋은 하나의 접근법은 없음
  • Zig의 방식은 ReleaseSafe를 런타임에서 가능한 한 안전하게 만들고, 테스트와 퍼징으로 정확성을 확인하는 것임
  • 검사되지 않은 illegal behavior는 이 과정에서 찾아야 하며, 정확성이 입증된 뒤에는 다른 릴리스 모드의 바이너리를 안전하게 배포할 수 있다고 봄
  • 이 방식은 Rust 모델에 비해 단점이 있지만, 단순성을 강하게 추구하는 Zig의 방향에서는 엄격히 열등하다고 보지 않음
  • 컴파일타임 메모리 안전성이 복잡한 타입 시스템과 긴 컴파일 시간의 비용을 감수할 만큼 중요하다면 Rust를 선택하면 됨
  • Zig의 메모리 안전성 모델은 assertion 철학으로도 이어짐
    • ReleaseFast에서 assertion을 비활성화하는 대신, 테스트를 통해 assertion이 올바르고 해당 경로가 unreachable임을 증명했다고 신뢰함
    • 이를 통해 Zig는 코드를 최적화할 수 있음
    • 관련 글로 your assertions are correct가 있음

앞으로의 사용 방향

  • 표준 라이브러리와 릴리스 변경 기록을 곁에 두고 Zig로 소프트웨어 문제를 다룰 준비가 됐음
  • 낮은 수준의 세부 사항을 다루고 싶지 않을 때는 선호하는 스크립팅 언어를 사용할 예정임
  • 앞으로의 소프트웨어에서는 Zig를 핵심 도구로 삼을 계획임
  • Zig에 계속 머물지 않을 가능성도 열려 있음
    • Rust의 안정성이나 타입 시스템이 필요하면 Rust를 사용할 수 있음
    • Zig의 접근법에 대한 생각이 완전히 바뀔 수도 있음
    • 여러 언어는 공존할 수 있고 공존해야 함
  • Zig는 소프트웨어 품질을 무시하지 않고 받아들임으로써 사용자에게 집중하는 소프트웨어 비전을 대표함
  • 사람들은 신뢰할 수 있고 강력한 소프트웨어를 받을 자격이 있으며, LLM 시대에는 정성 들여 만든 소프트웨어가 드물어지고 사람들이 나빠지는 slop을 받아들이도록 압박받는다고 봄

함께 보면 좋은 글 β

click   [-]

zig가 언어 스펙을 바꾸면서 자꾸 하위호환성을 버려버리는데 이러면 최소한 1.0 나오기 전까진 중요한 시스템에서 쓰기에 곤란하다고 생각합니다.
ghostty 가 std.IO 변경때문에 꽤나 고생하는거로 보이는데 이슈
다른 언어의 예를 들어서 만약 자바에서 Future 나온 뒤로 jdbc api 가 Future나 CompletableFuture 를 리턴하는 식으로 바뀌었다면 분명 큰 진보가 있겠지만 대가로 엄청난 혼란을 만들었겠죠

답변달기
GN⁺   [-]
Lobste.rs 의견들

  • 언젠가 Zig를 다시 시도해보고 싶음
    정말 해보고는 싶은데, 지금까지는 다른 일들 때문에 바빴음
    마지막으로 Zig를 만졌을 때는 약 3시간 만에 컴파일러 오류를 만났고 꽤 인상이 남았음. 공평하게 말하면 그 버그는 이미 최신 브랜치에서는 고쳐진 상태였음

  • “LLVM에 묶여 있으니 C만큼 많은 플랫폼을 지원하려면 아주 오래 걸리거나 영영 못 할 것”이라는 말에 의문이 듦
    LLVM이 지원하지 않는 어떤 플랫폼을 대상으로 개발하고 싶은 건지, 이 점에서 Zig가 어떻게 더 나은지 궁금함
    Zig가 tier-4 C 코드를 생성하고, 그걸 GCC가 hppa, alpha, sh용으로 컴파일할 수 있다는 얘기인지 묻고 싶음

    • 이해한 바로는 Zig가 LLVM 의존을 줄이는 작업을 적극적으로 하고 있어서, 앞으로 Zig 컴파일러에 새 대상을 구현할 때 LLVM 프로젝트 자체를 건드릴 필요가 없을 수 있다는 의미에 가까웠음
    • 현재는 C 코드 생성이 그 구현 방식임
      문제는 Zig에는 LLVM 외의 공식 백엔드가 있지만 Rust는 LLVM을 쓴다는 점임
      소프트웨어 재사용성을 극대화하려는 시스템 언어라면 가능한 한 넓게 실행되어야 하고, Zig처럼 C를 대체하려는 의도가 있다면 특히 그렇다고 봄
    • 어렴풋한 기억으로는, 우려의 초점이 플랫폼 지원보다는 컴파일 시간 쪽에 더 가까웠던 것 같음

  • ghostty의 성공을 보고 Zig가 1.0에 도달하면 게임 개발에 써볼 계획임
    다만 내가 만드는 유형의 게임에 그 정도 성능이 정말 필요한지는 잘 모르겠음

  • “Zig가 안전성을 포기한 것은 아니며, unsafe Rust보다 안전하다. 어차피 unsafe Rust를 써야 하는 상황이라면 Zig가 더 나을 수 있다”는 식의 말은 꽤 흔한데, 볼 때마다 이해가 잘 안 됨
    특히 글쓴이가 안전성은 스펙트럼이라고 인정하면서도, 국소적인 unsafe 구역을 쓰는 대신 모든 것이 계속 unsafe인 언어로 바꾸라고 권하는 점이 이상함
    추상 기계를 약간 더 추론하기 쉬울 수는 있어도, 그 교환이 납득되지는 않음

답변달기