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

> Clean Markdown view of GeekNews topic #31153. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31153](https://news.hada.io/topic?id=31153)
- GeekNews Markdown: [https://news.hada.io/topic/31153.md](https://news.hada.io/topic/31153.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-06T06:03:50+09:00
- Updated: 2026-07-06T06:03:50+09:00
- Original source: [gracefulliberty.com](https://gracefulliberty.com/articles/return-to-zig/)
- Points: 2
- Comments: 3

## Topic Body

- 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](https://www.youtube.com/watch?v=Z4oYSByyRak)는 프로그래밍 언어와 소프트웨어를 보는 기준을 만들었음
  - 실패 가능한 명시적 메모리 할당
  - 숨은 제어 흐름 없음
  - 보편적 재사용성
- Zig로 장난감 프로그래밍 언어, literate programming 도구, 웹 서버를 만들며 C보다 편하지만 위험 요소는 적은 언어처럼 느꼈음

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

### 다시 Zig를 보게 만든 불만
- Rust는 원하는 재사용 가능한 프로그램을 만들기에 완벽한 언어는 아니었음
  - FFI가 어려움
  - 크로스 컴파일이 번거로움
  - 숨은, 실패하지 않는 것으로 취급되는 메모리 할당이 부담스러움
  - LLVM에 묶여 있어 C만큼 많은 플랫폼을 지원하기까지 오래 걸리거나 불가능할 수 있음
- 거버넌스도 불편한 지점으로 남았음
  - Rust Foundation에는 여러 거대 기업 [foundation members](https://rustfoundation.org/members/)가 있음
  - 세계 최대 기업들이 매년 수십만 달러를 제공하면 Rust 개발 방향에 영향을 줄 가능성이 있다고 봄
- 오픈소스 커뮤니티에서 LLM 생성 코드를 받아들이는 프로젝트가 많아진 점이 충격으로 작용함
- 여러 프로젝트에서 유지보수자와 사용자가 LLM 정책을 작성하거나 요구했음
- Zig는 프로젝트에서 LLM을 [완전히 금지](https://ziglang.org/code-of-conduct/#strict-no-llm-no-ai-policy)했음
- Rust는 설문을 진행했고 커뮤니티의 전반적 정서는 반LLM이었지만, 공식 정책을 바로 만들지는 않았음
- Rust의 [정책 제안](https://github.com/rust-lang/rust-forge/pull/1040)에는 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](https://zackoverflow.dev/writing/unsafe-rust-vs-zig/)라는 관점에서는 unsafe Rust를 써야 하는 상황에서 Zig가 더 나은 선택일 수 있음
- Zig는 언어를 더 안전하게 만들려는 작업도 진행 중임
  - 접근 방식은 unsafe 코드 구역이 아니라 **릴리스 모드**에 초점을 둠
  - 현재 Zig의 ReleaseSafe 모드는 assertion 실패 시 크래시하고 모든 메모리를 초기화함
  - Andrew Kelley는 ReleaseSafe에 [Fil-C](https://fil-c.org/) 같은 것을 포함하는 방향에 관심이 있음
- 이런 방식은 `unsafe`를 피한 Rust의 컴파일타임 메모리 안전성을 제공하지는 않지만, 일부가 말하는 death spiral은 아니라고 봄
- 메모리 안전성은 스펙트럼이며, 모든 상황에 가장 좋은 하나의 접근법은 없음
- Zig의 방식은 ReleaseSafe를 런타임에서 가능한 한 안전하게 만들고, 테스트와 퍼징으로 정확성을 확인하는 것임
- 검사되지 않은 illegal behavior는 이 과정에서 찾아야 하며, 정확성이 입증된 뒤에는 다른 릴리스 모드의 바이너리를 안전하게 배포할 수 있다고 봄
- 이 방식은 Rust 모델에 비해 단점이 있지만, 단순성을 강하게 추구하는 Zig의 방향에서는 엄격히 열등하다고 보지 않음
- 컴파일타임 메모리 안전성이 복잡한 타입 시스템과 긴 컴파일 시간의 비용을 감수할 만큼 중요하다면 Rust를 선택하면 됨
- Zig의 메모리 안전성 모델은 assertion 철학으로도 이어짐
  - ReleaseFast에서 assertion을 비활성화하는 대신, 테스트를 통해 assertion이 올바르고 해당 경로가 unreachable임을 증명했다고 신뢰함
  - 이를 통해 Zig는 코드를 최적화할 수 있음
  - 관련 글로 [your assertions are correct](https://kristoff.it/blog/fix-your-asserts/)가 있음

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

## Comments



### Comment 61319

- Author: clastneo
- Created: 2026-07-06T12:39:26+09:00
- Points: 1

Zig 학습 도중에 새 버전 나온다는 얘기를 보고 학습을 포기했던 경험이 있습니다.  
안정화 버전이 나오면 다시 학습목록에 올려볼만 하겠지만 아직까진 브레이크체인지가 너무 심해서 손대기가 겁나네요.

### Comment 61302

- Author: click
- Created: 2026-07-06T09:19:50+09:00
- Points: 1

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

### Comment 61295

- Author: neo
- Created: 2026-07-06T06:03:51+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/svm2dp/returning_zig) 
- 언젠가 **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](https://ghostty.org)의 성공을 보고 Zig가 1.0에 도달하면 **게임 개발**에 써볼 계획임  
  다만 내가 만드는 유형의 게임에 그 정도 성능이 정말 필요한지는 잘 모르겠음
  - Godot을 안다면 https://github.com/godot-zig/godot-zig 를 시도해볼 수 있음

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