필사 모드: 모던 Zig 2026 — Zig 0.14 / Andrew Kelley / Bun / TigerBeetle / Ghostty / comptime / Zon / Roc 심층 가이드
한국어1장 · 2026년 Zig — Andrew Kelley의 비전 그리고 산업 적용
2026년 5월 시점, Zig는 여전히 **1.0이 아니다**. 가장 최근 릴리스는 2025년 3월의 0.14다. 그런데 이 "버전 0.x" 라벨에 속으면 안 된다. 이미 Bun · TigerBeetle · Ghostty 같은 굵직한 프로덕트가 Zig로 출하되고 있고, 수천 개의 C/C++ 프로젝트가 `zig cc` 한 줄로 크로스 컴파일러를 갈아치우고 있다.
Zig의 핵심 아이덴티티는 Andrew Kelley(앤드류 켈리)라는 한 명의 솔로 BDFL과 그 위에 얹힌 Zig Software Foundation이다. Rust가 Mozilla → 재단으로 넘어가며 거버넌스를 분산시킨 것과는 반대로, Zig는 의도적으로 한 사람의 취향을 깊게 새긴 언어다. 그 결과:
- **C와 비슷하게 단순한 표면**, 그러나 `comptime`이라는 강력한 컴파일 타임 메타 프로그래밍
- **숨겨진 제어 흐름이 없다** — operator overloading, RAII, hidden allocator 없음
- **명시적 메모리 관리**, allocator를 함수 인자로 받는 패턴
- **`zig cc` / `zig c++`** — Zig가 LLVM을 번들링해 C/C++ 크로스 컴파일러로 동작
- **`build.zig`** — Make/CMake/Bazel을 대체하는 빌드 시스템, Zig 코드 그 자체로 빌드 그래프를 짠다
산업 적용은 "여전히 작지만 굉장히 진지"하다. Bun이 npm 통계에서 차지하는 비중, TigerBeetle이 핀테크 백엔드에 들어가는 비율, Ghostty가 macOS 개발자 터미널 점유율을 빠르게 깎고 있는 속도 — 이 셋만으로도 "Zig는 장난감이 아니다"라는 증명은 충분하다.
이 글은 Andrew Kelley의 디자인 철학에서 시작해 0.14의 실체, 0.15/1.0 로드맵, 그리고 Bun · TigerBeetle · Ghostty를 거쳐 comptime · allocator · build system · zig cc · ZLS · Roc까지 — 2026년 5월 시점에서 Zig를 진지하게 봐야 하는 이유와 함정을 한 번에 정리한다.
2장 · Zig 0.14 (2025.3) — 컴파일 속도 + async 재설계 대기
2025년 3월 5일, Zig 0.14가 풀렸다. 핵심 변화:
1. **`x86 backend`의 안정화 진전** — LLVM 없이 Zig 자체 백엔드로 디버그 빌드를 빠르게 굴리는 작업. 디버그 빌드 컴파일 속도가 2배 가까이 빨라진 케이스가 보고됐다.
2. **`@import` 의존성 트리 단순화** — 모듈 시스템이 좀 더 직관적으로.
3. **`std.Build`(빌드 시스템) API 갈리기** — `build.zig`를 짜는 손맛이 또 바뀌었다. 0.13에서 0.14로 올리려면 `step.addArgs` 같은 API 시그니처 변경을 꼭 보고 가야 한다.
4. **`async`/`await`는 여전히 빠져 있다** — 0.11에서 일시적으로 제거된 비동기 기능이 0.14에서도 아직 안 돌아왔다. Andrew는 "stackless coroutine 모델을 다시 디자인할 거다"라고 했고, 그 재설계가 1.0 전에 들어올지가 큰 이슈다.
코드로 본 0.14의 분위기:
const std = @import("std");
pub fn main() !void {
var gpa = std.heap.GeneralPurposeAllocator(.{}){};
defer _ = gpa.deinit();
const allocator = gpa.allocator();
var list = std.ArrayList(u8).init(allocator);
defer list.deinit();
try list.appendSlice("Hello, Zig 0.14!\n");
try std.io.getStdOut().writeAll(list.items);
}
- `try`는 에러 전파, `defer`는 스코프 종료 시 실행
- `std.heap.GeneralPurposeAllocator`를 직접 만들고 `allocator()`로 인터페이스를 추출
- 모든 컬렉션이 `allocator`를 받는다 — 숨겨진 alloc 없음
0.14의 큰 그림: "**컴파일러가 자기 발로 더 빨라지고 있다**". Rust가 `rustc` 컴파일 속도로 욕먹는 것과 정반대 방향이다.
3장 · Zig 0.15 / Zig 1.0 로드맵
2026년 5월 현재, **0.15는 아직 풀리지 않았다**. 0.14 → 0.15 사이에 들어올 거라고 예상되는/논의되는 것들:
- **자체 x86 백엔드 기본화** — 디버그 빌드에서 LLVM을 우회하는 게 기본이 된다. release 빌드는 여전히 LLVM.
- **async/await 재설계** — Andrew는 "I/O-driven concurrency"라는 새 모델을 제안했다. 핵심은 "스택리스 코루틴이 아니라 명시적인 io 인자를 통한 비동기". 즉 `fn read(io: *Io, ...) []u8` 같은 식. 라이브러리가 비동기에 동의할 때만 비동기가 된다.
- **`std.Io`** — 비동기 I/O의 표준 인터페이스. 여전히 변동 중.
- **incremental compilation** 강화
- **package manager (Zon) 안정화** — 0.14에서 `build.zig.zon`이 표준이 됐고, 0.15에서 더 다듬어진다
**Zig 1.0은 언제 나오나?** 누구도 못 박지 못한다. Andrew는 공식적으로 "1.0은 stability 약속이 가능한 시점에 낸다"라고만 말했다. 보수적으로 보면 2027년, 낙관적으로 봐도 2026년 하반기다. Bun · TigerBeetle · Ghostty 같은 진지한 사용자들은 이미 "Zig 0.x로 출하"하고 있다 — 1.0을 기다리는 게 아니라, 매 버전 업데이트마다 자기 코드를 같이 갈고 있다.
4장 · Bun 런타임 — Zig로 쓴 가장 큰 검증
Bun은 Jarred Sumner(저드 섬너)가 만든 JavaScript 런타임이다. 핵심 포지셔닝은 "Node.js 대체"이고, 내부는 **거의 전부 Zig로 작성**되어 있다. 2024~2025년에 Bun 1.x가 풀리고 1.1/1.2를 거치면서 Node 호환성이 거의 99%에 도달했다. 2026년 시점, Bun은 "Zig라는 언어가 진지한 인프라 소프트웨어를 짤 수 있다"는 가장 큰 산업 증거다.
Bun이 Zig를 선택한 이유:
- **컴파일 속도** — JS 런타임은 거대한 C++ 의존성(JSC, V8)을 끌어와야 하는데, Zig는 그걸 자기 빌드 시스템 안에서 깔끔하게 묶는다
- **`zig cc`로 C/C++ 의존성 크로스 컴파일** — Bun은 macOS/Linux/Windows 바이너리를 한 머신에서 다 뽑는다
- **allocator 컨트롤** — JS 런타임의 핵심 hot path에서 alloc/free를 손으로 잡을 수 있다
- **comptime** — `bun:ffi`, `bun:sqlite` 같은 모듈의 boilerplate를 컴파일 타임에 생성
Bun 코드의 한 조각(개념):
// Bun의 HTTP 서버 hot path (단순화)
pub fn handleRequest(
arena: *std.heap.ArenaAllocator,
socket: *Socket,
req: *Request,
) !void {
var response_buffer = std.ArrayList(u8).init(arena.allocator());
try writeStatusLine(&response_buffer, 200);
try writeHeaders(&response_buffer, req);
try socket.writeAll(response_buffer.items);
}
- **arena allocator** — 요청 단위로 메모리를 묶고, 응답이 끝나면 arena를 한 번에 해제. malloc/free 호출이 거의 없다
- **명시적 에러 전파** — `try`로 모든 I/O 에러를 위로 던진다
- **숨겨진 alloc 없음** — `ArrayList`도 `init(allocator)`로 명시
Bun이 보여준 게 뭐냐: "**작은 팀(10명 이하)이 Zig로도 Node급 인프라를 만들 수 있다**". 이건 Rust로 짜는 것보다 압도적으로 코드량이 적고, C로 짜는 것보다 압도적으로 안전하다.
5장 · TigerBeetle — 분산 회계 DB
TigerBeetle은 Joran Dirk Greef가 이끄는 금융용 분산 DB다. 100% Zig로 작성됐고, 단일 목적이 분명하다 — **double-entry accounting transactions를 OLTP 속도로 처리**. 핀테크/지급 시스템의 ledger 백엔드를 노린다.
TigerBeetle이 흥미로운 이유:
- **NASA Power of 10 규칙** + **TIGER STYLE 코딩 가이드** — 함수 길이 70줄 제한, recursion 금지, dynamic alloc은 시작 시 한 번만, 모든 loop에 명시적 bound, assert 적극 사용
- **deterministic simulation testing** — VOPR(Viewstamped Operation Replication)이라는 자체 합의 알고리즘을 fault injection으로 수십억 번 시뮬레이션
- **single-binary, zero-dependency** — `zig build` 한 번이면 바이너리 하나가 떨어진다
- **performance** — 노드당 초당 100만 transactions를 목표로 함
코드로 본 TIGER STYLE 일부:
fn transfer(ledger: *Ledger, from: AccountId, to: AccountId, amount: u64) !void {
assert(from != to);
assert(amount > 0);
const from_account = try ledger.lookup(from);
const to_account = try ledger.lookup(to);
assert(from_account.balance >= amount); // 사전조건 명시
from_account.balance -= amount;
to_account.balance += amount;
try ledger.commit();
}
- `assert`가 마치 주석처럼 깔린다 — 디버그 빌드에서 invariant를 강제
- 모든 alloc은 시작 시 끝, hot path에는 alloc이 없다
- 함수가 짧고, 한 가지 일만 한다
TigerBeetle은 "Zig가 미션 크리티컬에도 쓸 수 있다"의 산업 증거다. 핀테크 ledger는 한 푼이라도 틀리면 회사가 망하는 도메인이고, 거기에 Zig를 박았다.
6장 · Ghostty — Mitchell Hashimoto의 터미널
Ghostty는 Mitchell Hashimoto(미첼 하시모토 — Vagrant/Terraform의 그 사람)가 만든 GPU 가속 터미널 에뮬레이터다. 2024년 12월 1.0이 풀렸고, 2026년에는 macOS · Linux 양쪽 모두에서 1급 시민이 됐다.
Ghostty가 Zig를 선택한 이유:
- **크로스 플랫폼 네이티브 UI** — macOS는 Swift, Linux는 GTK4. 그 가운데 코어 로직은 Zig
- **comptime으로 터미널 시퀀스 파서 생성** — VT100/xterm escape sequence를 컴파일 타임에 lookup 테이블로 풀어버린다
- **zero-copy 렌더링** — GPU 텍스처에 직접 쓰기 위해 alloc을 손으로 관리
- **Mitchell의 개인 선택** — Terraform을 Go로 짠 사람이 "다음은 Zig"라고 한 건 사건이었다
Ghostty가 보여주는 패턴:
const Cell = struct {
char: u21,
fg: Color,
bg: Color,
attrs: packed struct(u8) {
bold: bool,
italic: bool,
underline: bool,
_reserved: u5,
},
};
- **`packed struct(u8)`** — 비트 레이아웃을 명시. C로 짜면 매크로/주석으로 했던 일을 언어가 안다
- **`u21`** — 정확히 21비트 정수, 유니코드 코드포인트 표현에 딱 맞는 폭
Ghostty는 "Zig로 GUI 앱을 짤 수 있다"는 증거이기도 하다. 보통 새 시스템 언어가 GUI에서 막히는데, Mitchell은 "코어는 Zig, 플랫폼별 chrome은 네이티브"라는 답을 보여줬다.
자세한 비교는 별도 글(2026-05-16 터미널 셸 도구)에서 다뤘다.
7장 · Zig 빌드 시스템 (build.zig) + Zon 매니페스트
Zig는 외부 빌드 도구를 안 쓴다. Make · CMake · Bazel · Cargo가 다 사라지고, 그 자리에 **`build.zig`** 하나가 들어선다. 즉 **빌드 스크립트도 Zig 코드**다.
전형적인 `build.zig` 모양:
const std = @import("std");
pub fn build(b: *std.Build) void {
const target = b.standardTargetOptions(.{});
const optimize = b.standardOptimizeOption(.{});
const exe = b.addExecutable(.{
.name = "myapp",
.root_source_file = b.path("src/main.zig"),
.target = target,
.optimize = optimize,
});
b.installArtifact(exe);
const run_cmd = b.addRunArtifact(exe);
const run_step = b.step("run", "Run the app");
run_step.dependOn(&run_cmd.step);
}
- `b: *std.Build` — 빌드 그래프 빌더 객체
- `b.standardTargetOptions` — `-Dtarget=x86_64-linux-gnu` 같은 옵션을 자동으로 받는다
- 빌드가 데이터가 아니라 코드 — for loop, if 분기, 동적 의존성 모두 가능
Zon 매니페스트 — `build.zig.zon`
0.11부터 도입된 Zig Object Notation. JSON과 비슷하지만 Zig 문법이다.
.{
.name = "myapp",
.version = "0.1.0",
.minimum_zig_version = "0.14.0",
.dependencies = .{
.httpz = .{
.url = "https://github.com/karlseguin/http.zig/archive/abc123.tar.gz",
.hash = "1220abcdef...",
},
},
.paths = .{ "src", "build.zig", "build.zig.zon" },
}
- **`.hash` 필수** — content-addressed, 의존성이 바뀌면 빌드가 멈춘다
- **중앙 레지스트리 없음** — npm/crates.io 같은 게 없다. 모든 의존성이 URL 직접 참조
- 이건 의도된 디자인 — Andrew는 "패키지 매니저는 보안 표면이 너무 크다"고 했다
장단:
- 장점: 의존성 그래프가 폭주하지 않는다, 누군가 npm 같은 사고를 칠 수 없다
- 단점: 발견(discovery)이 어렵다, "Zig version of lodash"가 어디 있는지 직접 찾아야
8장 · Zig as C cross-compiler — 다른 프로젝트가 Zig를 쓰는 이유
`zig`를 설치하면 따라오는 가장 강력한 도구가 **`zig cc`** / **`zig c++`** 다. 이건 단순한 wrapper가 아니라, **LLVM을 번들링한 정식 C/C++ 컴파일러**다.
Linux x86_64에서 macOS aarch64 바이너리 만들기
zig cc -target aarch64-macos main.c -o main
Windows x86_64로 크로스 컴파일
zig cc -target x86_64-windows-gnu main.c -o main.exe
이게 뭐가 대단하냐:
- **glibc 버전 명시 가능** — `-target x86_64-linux-gnu.2.17`로 RHEL 7 호환 빌드
- **libc 번들** — Zig는 musl, glibc, mingw 등 libc 소스를 같이 갖고 있다
- **단일 설치** — Zig 하나 깔면 모든 타겟에 대한 크로스 컴파일러가 같이 깔린다
산업 사용:
- **uv (Python 패키지 매니저, by Astral)** — wheel 빌드에 `zig cc` 사용
- **TigerBeetle** — `zig build`가 모든 플랫폼 바이너리를 한 머신에서 뽑음
- **Bun** — 위에서 본 것처럼 의존성 컴파일에 사용
- **gcc/clang 대체** — Drew DeVault 같은 사람들이 자체 프로젝트에서 도구 체인을 갈음
핵심 메시지: **Zig 언어를 안 써도 Zig 도구는 쓰게 된다**. 크로스 컴파일이라는 단 하나의 기능 때문에.
9장 · Zig vs Rust 논쟁 — 차이점
2026년에 "Rust vs Zig"는 이미 진영전이다. 양쪽 다 C/C++의 후계자를 자처한다. 그러나 결이 매우 다르다.
| 차원 | Rust | Zig |
|---|---|---|
| 메모리 안전 | borrow checker (컴파일 타임 강제) | allocator-aware + runtime checks |
| Generics | trait + monomorphization | comptime |
| 컴파일 속도 | 느리기로 악명 | 빠름, 자기 백엔드로 더 빨라지는 중 |
| Async | async/await (stabilized) | 일시 제거, 재설계 중 |
| 표준 라이브러리 | 거대함 | 작음, 의도적으로 |
| 빌드 도구 | cargo | build.zig |
| 1.0 | 2015년 5월 | 미정 (2026 하반기 ~ 2027) |
| 거버넌스 | 재단 + 팀 | Andrew Kelley + ZSF |
| 학습 곡선 | 매우 가파름 | 가파름, 그러나 결이 다름 |
Zig의 "borrow checker가 없는데 안전한가?"에 대한 답은:
1. **allocator를 명시적으로 받음** — 누가 메모리를 소유하는지 함수 시그니처에 적힌다
2. **runtime safety checks** — 디버그 빌드에서 out-of-bounds, integer overflow, null deref가 자동 panic
3. **`defer` / `errdefer`** — RAII가 아니지만 결정적 정리
4. **GeneralPurposeAllocator의 leak detection** — 디버그 빌드에서 leak이 잡힌다
Andrew Kelley는 "Rust의 borrow checker는 안전을 위해 너무 많은 자유를 포기한다. Zig는 명시성과 단순성을 택한다"고 말했다. 둘 다 옳다. 도메인에 따라 답이 다르다.
10장 · comptime — Zig의 킬러 기능
`comptime`은 Zig의 핵심 차별점이다. **컴파일 타임에 임의의 Zig 코드를 실행**할 수 있고, 그 결과를 타입과 상수로 쓸 수 있다.
10.1 제네릭은 함수다
fn List(comptime T: type) type {
return struct {
items: []T,
len: usize,
pub fn append(self: *@This(), item: T) void {
// ...
}
};
}
const IntList = List(i32);
const StrList = List([]const u8);
- `T`가 `comptime` 인자, 타입 자체를 값으로 받는다
- `List`는 함수, 호출하면 타입을 돌려준다
- C++ template, Rust generic과 같은 일을 한다 — 그러나 **언어 안에서 1급 시민**
10.2 컴파일 타임 코드 실행
const lookup_table = comptime blk: {
var t: [256]u8 = undefined;
for (&t, 0..) |*v, i| {
v.* = @intCast(i * 2 % 256);
}
break :blk t;
};
- `comptime blk: { ... }` — 이 블록이 컴파일 타임에 실행되어 결과가 박힌다
- 런타임에는 lookup_table이 그냥 256바이트 데이터로 존재
- C로 짜면 매크로/스크립트로 풀어야 할 일을 Zig는 같은 언어 안에서
10.3 자기 자신을 검사하는 코드
fn serialize(value: anytype, writer: anytype) !void {
const T = @TypeOf(value);
const info = @typeInfo(T);
switch (info) {
.Int => try writer.print("{}", .{value}),
.Bool => try writer.print("{}", .{value}),
.Struct => |s| {
inline for (s.fields) |field| {
try serialize(@field(value, field.name), writer);
}
},
else => @compileError("unsupported type"),
}
}
- `@typeInfo`로 타입을 introspect
- `inline for`는 컴파일 타임 unroll
- `@compileError`로 컴파일 타임 실패 메시지
이건 Rust의 `proc-macro` + `serde` + `syn`이 하는 일을 **언어 레벨에서** 한다. 외부 매크로 없이.
11장 · Allocator-aware 프로그래밍
Zig의 메모리 모델은 한 문장으로 요약된다: "**메모리를 쓰는 모든 함수는 allocator를 인자로 받아야 한다**".
pub fn readFile(allocator: std.mem.Allocator, path: []const u8) ![]u8 {
const file = try std.fs.cwd().openFile(path, .{});
defer file.close();
const stat = try file.stat();
const buffer = try allocator.alloc(u8, stat.size);
errdefer allocator.free(buffer);
_ = try file.readAll(buffer);
return buffer;
}
- `allocator`를 명시적으로 받음 — 함수가 어떤 alloc을 쓰는지 호출자가 안다
- `defer`로 파일 닫기
- `errdefer`로 에러 발생 시에만 buffer 해제
표준 라이브러리가 제공하는 allocator들:
| Allocator | 용도 |
|---|---|
| `std.heap.GeneralPurposeAllocator` | 디버그 빌드에서 leak/double-free 감지 |
| `std.heap.page_allocator` | OS 페이지 직접 |
| `std.heap.c_allocator` | malloc/free |
| `std.heap.ArenaAllocator` | 요청 단위 묶음 해제 |
| `std.heap.FixedBufferAllocator` | 사전 할당 버퍼 |
| `std.testing.allocator` | 테스트, leak 강제 검출 |
**Arena 패턴**이 핵심:
var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator);
defer arena.deinit();
const alloc = arena.allocator();
// 이 scope 안의 모든 alloc은 arena.deinit() 한 방에 해제됨
const a = try alloc.alloc(u8, 100);
const b = try alloc.alloc(u8, 200);
// a, b 개별 free 불필요
Bun의 HTTP 요청 처리, TigerBeetle의 트랜잭션 처리가 모두 arena 패턴 위에 굴러간다. **alloc 횟수가 적어지면서 성능이 평균적으로 빨라진다**.
12장 · ZLS (Zig Language Server)
`ZLS`는 Zig 공식이 아닌 커뮤니티 LSP다. 2026년 시점, VS Code · Neovim · Helix · Zed 모두에서 1급 시민이다.
ZLS가 주는 것:
- **goto definition / find references**
- **autocomplete** (comptime 결과까지 어느 정도)
- **inlay hints** — 추론된 타입을 inline 표시
- **diagnostics** — Zig 컴파일러를 호출해 에러를 실시간 표시
- **rename refactoring**
주의:
- ZLS는 **Zig 버전과 짝이 맞아야 한다**. 0.14용 ZLS, 0.13용 ZLS가 따로다
- comptime 추론은 한계가 있다 — 특히 `anytype` 인자
- 0.14 시점에서도 여전히 가끔 멈춘다 — Rust analyzer 수준의 안정성은 아직
설정 (`.zls.json`):
{
"enable_inlay_hints": true,
"enable_argument_placeholders": false,
"warn_style": true,
"enable_autofix": true
}
13장 · Roc — 함수형 대안
Roc은 Richard Feldman(리처드 펠드먼 — Elm 커뮤니티 출신)이 만든 함수형 시스템 언어다. 이상하게도 **Zig와 묶여서 자주 언급**된다. 이유:
- **Roc 컴파일러가 Zig로 작성**되어 있다
- **`roc build`도 LLVM을 번들링** — Zig와 비슷한 접근
- **함수형 + GC 없음 + ML 계열 문법** — Haskell의 미관 + Zig의 실행 모델
- **Andrew Kelley가 공개적으로 응원**
Roc 코드 한 조각:
greet : Str -> Str
greet = \name -> "Hello, \(name)!"
main =
Stdout.line! (greet "World")
- 함수형, 패턴 매칭, 타입 추론
- `!`로 effect를 명시 — Haskell의 `IO`와 비슷한 발상
- GC 없이 reference counting + opportunistic in-place mutation
2026년 시점, Roc은 아직 0.x다. 그러나 "Zig 위에 짠 진지한 ML 계열 언어"라는 자리가 있고, 함수형을 좋아하는 사람들에게 매력적이다. **Zig 생태계의 다양성을 보여주는 사례**.
14장 · 한국 / 일본 — 빌더에서의 Zig 도입, Cybozu Zig 실험
14.1 한국 — 빌더(Builder) 도입
한국의 SaaS 빌더 회사(노션/Webflow류 도구를 만드는 곳들)들이 2025년부터 Zig를 코어 렌더링 엔진에 실험적으로 도입하고 있다.
- **이유 1**: WASM 타겟 — Zig는 WASM을 1급으로 지원, 결과 바이너리 크기가 Rust보다 작은 경우가 많다
- **이유 2**: `zig cc`로 기존 C/C++ 의존성을 WASM으로 끌어옴 — emscripten 의존 줄임
- **이유 3**: 코어 팀 규모가 작은 스타트업에 잘 맞는다 — Rust 학습 비용 대비 진입이 낫다
물론 아직 작다. JS/TS 스택이 압도적이다. 그러나 "WASM 타겟이 필요한 hot path"에서는 Zig 채택이 늘고 있다.
14.2 일본 — Cybozu(사이보즈) Zig 실험
Cybozu(사이보즈, 그룹웨어 회사)는 Kintone의 일부 모듈에서 Go → Rust → Zig로 옮기는 실험을 공개했다. 결과:
- **Rust**: 안전하지만 컴파일 속도 + 학습 곡선이 문제
- **Zig**: 컴파일이 빠르고, Go에서 옮긴 사람도 며칠이면 읽기 가능
- **단점**: 1.0이 아니므로 매 버전 업데이트마다 코드 수정 필요 — 이게 받아들일 수 있는 비용인지가 결정 포인트
후지쯔 · NTT의 일부 인프라 팀도 zig cc만 도입해서 빌드 파이프라인을 단순화한 사례가 있다 — "**언어를 쓰진 않지만 도구는 쓴다**" 패턴.
15장 · 누가 Zig를 골라야 하나 — 시스템 / 임베디드 / C 교체
다음 도메인이면 진지하게 Zig를 봐라:
1. **C/C++ 프로젝트의 빌드 시스템 교체** — Make/CMake가 지긋지긋한 사람. `zig build` + `zig cc`로 단번에 깨끗해진다
2. **크로스 컴파일이 필요한 CLI 도구** — Bun이 보여준 패턴
3. **임베디드 / OS 개발 / 펌웨어** — `no std`, 정확한 비트 레이아웃, allocator 컨트롤이 필요한 곳
4. **WASM 타겟의 hot path** — 빌더 사례
5. **금융 / 미션 크리티컬 백엔드** — TigerBeetle 사례, 단 TIGER STYLE 정도의 디시플린이 필요
피해야 할 곳:
- **웹 백엔드 (CRUD)** — Go · Node · Rust가 훨씬 빠르게 짠다
- **데이터 사이언스 / ML** — Python 생태계가 압도적
- **GUI 앱 전체** — 코어만 Zig로, chrome은 다른 거 (Ghostty 패턴)
- **장기 안정성이 결정적인 곳** — 1.0이 아직 안 풀렸다. 매 버전 마이그레이션 비용 감수 필요
**한 줄 결론**: 2026년의 Zig는 "**진지한 실험 단계의 진지한 언어**". Bun · TigerBeetle · Ghostty가 1.0 전에 출하한 것 자체가 증거다. 1.0을 기다리지 말고, 부담 작은 코너에서 한 번 써보고 결정하면 된다.
16장 · 참고 / References
- Zig 공식 사이트: [https://ziglang.org/](https://ziglang.org/)
- Zig 0.14 릴리스 노트: [https://ziglang.org/download/0.14.0/release-notes.html](https://ziglang.org/download/0.14.0/release-notes.html)
- Zig Software Foundation: [https://ziglang.org/zsf/](https://ziglang.org/zsf/)
- Andrew Kelley 블로그: [https://andrewkelley.me/](https://andrewkelley.me/)
- Zig 언어 레퍼런스: [https://ziglang.org/documentation/master/](https://ziglang.org/documentation/master/)
- Zig 빌드 시스템 가이드: [https://ziglang.org/learn/build-system/](https://ziglang.org/learn/build-system/)
- Zon 패키지 매니페스트: [https://ziglang.org/learn/build-system/#zig-package-manager](https://ziglang.org/learn/build-system/#zig-package-manager)
- Bun: [https://bun.sh/](https://bun.sh/)
- Bun GitHub: [https://github.com/oven-sh/bun](https://github.com/oven-sh/bun)
- TigerBeetle: [https://tigerbeetle.com/](https://tigerbeetle.com/)
- TigerBeetle 디자인 문서: [https://docs.tigerbeetle.com/](https://docs.tigerbeetle.com/)
- TIGER STYLE 코딩 가이드: [https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md](https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md)
- Ghostty: [https://ghostty.org/](https://ghostty.org/)
- Ghostty GitHub: [https://github.com/ghostty-org/ghostty](https://github.com/ghostty-org/ghostty)
- ZLS (Zig Language Server): [https://github.com/zigtools/zls](https://github.com/zigtools/zls)
- Roc 언어: [https://www.roc-lang.org/](https://www.roc-lang.org/)
- uv (Astral, zig cc 사용): [https://docs.astral.sh/uv/](https://docs.astral.sh/uv/)
- "Zig 언어가 C/C++을 대체할 수 있을까" Andrew Kelley 강연: [https://www.youtube.com/results?search_query=andrew+kelley+zig](https://www.youtube.com/results?search_query=andrew+kelley+zig)
- Bun 내부 Zig 사용 패턴 글: [https://bun.sh/blog](https://bun.sh/blog)
- Zig 커뮤니티 Discord: [https://discord.gg/zig](https://discord.gg/zig)
현재 단락 (1/319)
2026년 5월 시점, Zig는 여전히 **1.0이 아니다**. 가장 최근 릴리스는 2025년 3월의 0.14다. 그런데 이 "버전 0.x" 라벨에 속으면 안 된다. 이미 Bun ...