Zig 빌드가 150ms에서 14ms로 빨라진 이유

Zig 빌드가 150ms에서 14ms로 빨라진 이유

AI 뉴스 썸네일

Zig 팀이 `zig build` 내부 구조를 크게 바꿨어요. 겉으로 보이는 명령은 비슷하지만, 안에서는 빌드 설정을 만드는 일과 실제 빌드 그래프를 실행하는 일이 갈라졌어요.

이번 변화는 새 기능을 더 넣으면서도 빌드 시작 시간을 짧게 유지하려는 작업에 가까워요. 숫자로는 `zig build --help` 평균 실행 시간이 150ms에서 14.3ms로 줄었다고 해요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
빌드 구조	`configurer`와 `maker` 프로세스로 역할을 나눴어요	`build.zig`를 고칠 때마다 빌드 시스템 전체를 다시 엮는 부담을 줄여요
캐시	빌드 그래프를 바이너리 설정 파일로 저장해요	바뀐 게 없으면 같은 설정을 다시 쓸 수 있어요
속도	`zig build --help`가 150ms에서 14.3ms로 줄었어요	개발 도구에서 자주 실행하는 명령의 체감 대기 시간이 줄어요
호환성	대부분 API는 유지돼요	다만 `b.args` 직접 확인 코드는 `addPassthruArgs()`로 바꿔야 해요

1. Zig 빌드 시스템이 설정 생성과 실행을 나눴어요

빌드 시스템을 둘로 나눴어요

기존에는 `build.zig`와 빌드 시스템 구현이 한 프로세스 안에서 함께 컴파일됐어요. 사용자의 빌드 스크립트가 빌드 그래프를 메모리에 만들면, 같은 덩어리 안의 build runner가 그 그래프를 실행했어요.

새 구조에서는 먼저 `build.zig`만 작은 Debug 모드 프로세스로 컴파일해요. Zig 쪽 표현으로는 이 역할이 `configurer`예요. 이 프로세스는 빌드 그래프를 만든 뒤, 그 결과를 바이너리 설정 파일로 저장해요. 2

실행 쪽은 `maker`가 맡아요. 부모 `zig build` 프로세스는 설정 파일을 다음 실행에 쓸 수 있게 캐시하고, 동시에 `maker`를 Release 모드로 비동기 컴파일해요. `maker`는 Zig 버전마다 전역 캐시에 한 번만 만들어두면 돼요.

이 차이가 꽤 커요. 사용자가 `build.zig`를 조금 고쳤다고 해서 빌드 시스템 전체를 함께 다시 컴파일하지 않아도 돼요. `--watch`, `--fuzz`, `--webui`처럼 빌드 시스템 기능이 늘어날수록 이 분리의 효과가 더 커져요.

150ms가 14.3ms로 줄었어요

Zig devlog에 나온 벤치마크를 보면 `zig build --help` 평균 실행 시간은 150ms에서 14.3ms로 줄었어요. 벽시계 시간 기준으로 약 90.4% 감소예요. CPU 사이클은 593M에서 24.1M으로 줄었고, 명령어 수도 995M에서 43.7M으로 줄었어요. 2

물론 `zig build --help` 하나만으로 모든 프로젝트 빌드 시간을 설명할 수는 없어요. 그래도 개발 도구에서는 이런 짧은 명령이 자주 반복돼요. 도움말, 설정 확인, watch 모드 재시작, 에디터 연동처럼 작은 실행이 누적되면 체감이 커져요.

핵심은 캐시된 설정을 다시 쓸 수 있다는 점이에요. 예를 들어 `zig build` 명령줄에 `-freference-trace` 같은 옵션을 추가해도, 빌드 그래프 자체가 달라지지 않는다면 `build.zig` 로직을 다시 실행하지 않을 수 있어요.

개발자 도구에도 영향이 있어요

이번 변경은 Zig 사용자만 보는 이야기가 아니에요. ZLS 같은 도구는 지금까지 빌드 러너 쪽 구현을 따라가야 하는 부담이 있었어요. 앞으로는 직렬화된 설정 파일을 읽는 방향으로 이점을 얻을 수 있다고 Zig 쪽은 설명해요. 2

개발자 경험 관점에서는 꽤 현실적인 선택이에요. 새 언어가 기능을 늘리는 일도 중요하지만, 저장하고 다시 빌드하고 에디터가 반응하는 시간이 길어지면 매일 쓰기 어려워져요. Zig 팀이 빌드 시작 시간과 피드백 루프를 직접 줄이려는 이유도 여기에 있어요.

다만 모든 변화가 공짜는 아니에요. 대부분 API는 그대로지만, `b.args`를 직접 들여다보던 코드는 바꿔야 해요. 기존에는 `b.args`를 읽어 `run_cmd.addArgs(args)`로 넘길 수 있었지만, 새 방식에서는 `run_cmd.addPassthruArgs()`를 쓰는 쪽으로 바뀌어요. 이 인자를 빌드 스크립트가 관찰하는 기능은 사라져요.

대신 그 인자를 바꿀 때마다 빌드 스크립트를 소스에서 다시 빌드하지 않아도 돼요. Zig 팀은 이 트레이드오프를 속도와 캐시 재사용 쪽으로 잡은 셈이에요.

Zig 0.17.0 전에 확인할 점

Zig 0.17.0은 몇 주 안에 나올 예정이라고 해요. 개발 버전을 쓰는 프로젝트라면 빌드 스크립트가 이번 변경에 영향받는지 미리 확인하는 편이 좋아요. 특히 `b.args`를 직접 읽는 패턴이 있다면 먼저 찾아보는 게 안전해요. 2

Hacker News 쪽 반응은 기대와 조심스러움이 섞여 있어요. Zig가 도구용 언어로 좋다는 의견도 있고, 릴리스마다 API 변화가 커서 1.0까지 기다리고 싶다는 의견도 있어요. 개발 속도가 빠른 언어를 실제 프로젝트에 넣을 때 늘 만나는 장면이에요. 1

그래도 이번 변경의 방향은 분명해요. 더 많은 기능을 넣기 전에, 매번 반복되는 빌드 작업을 작게 쪼개고 캐시하기 쉬운 모양으로 바꿨어요. Zig를 쓰지 않더라도 빌드 시스템 설계에 관심이 있다면 볼만한 사례예요.

왜 중요한가요

빌드 시스템은 보통 눈에 잘 띄지 않아요. 하지만 매일 수십 번씩 실행되는 도구라면 100ms 단위 차이도 개발 리듬을 바꿔요. 이번 Zig 변경은 “컴파일러가 빨라졌다”보다 조금 더 구체적인 이야기예요.

사용자 코드와 빌드 도구 코드를 같은 덩어리로 묶지 않고, 설정 생성과 실행을 나눴어요. 그리고 실행 쪽은 최적화된 `maker`로 옮겼어요. 이 구조 덕분에 빌드 시스템이 커져도 사용자의 작은 빌드 스크립트 변경이 전체 비용으로 번지지 않아요. 2

언어와 도구를 만드는 팀에게도 참고할 만해요. 새 기능을 더하기 전에 반복 실행 경로를 분리하고, 캐시할 수 있는 결과를 파일로 남기고, 에디터와 외부 도구가 그 결과를 읽을 수 있게 했어요. 빠른 피드백 루프는 기능 목록보다 덜 화려하지만, 실제 사용에서는 더 오래 남아요.

참고 자료

1. Zig: 빌드 시스템 재작업 — GeekNews
2. Build System Reworked — Zig Programming Language Devlog