다시 Zig로 돌아가기

• 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을 받아들이도록 압박받는다고 봄