Skip to content
Published on

모던 Zig 2026 — Zig 0.14 / Andrew Kelley / Bun / TigerBeetle / Ghostty / comptime / Zon / Roc 심층 가이드

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

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++의 후계자를 자처한다. 그러나 결이 매우 다르다.

차원RustZig
메모리 안전borrow checker (컴파일 타임 강제)allocator-aware + runtime checks
Genericstrait + monomorphizationcomptime
컴파일 속도느리기로 악명빠름, 자기 백엔드로 더 빨라지는 중
Asyncasync/await (stabilized)일시 제거, 재설계 중
표준 라이브러리거대함작음, 의도적으로
빌드 도구cargobuild.zig
1.02015년 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_allocatorOS 페이지 직접
std.heap.c_allocatormalloc/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

Discuss on Twitter • View on GitHub