Zig의 빌드 시스템이 완전히 새로워졌다 — 무엇이 어떻게 바뀌었나

Zig가 왜 점점 더 주목받고 있나

Zig는 C의 대안으로 자주 거론되는 시스템 프로그래밍 언어예요. Rust처럼 안전성에 모든 걸 거는 대신, "C가 잘하는 걸 더 잘하면서 발등 찍히는 경우는 줄이자"는 쪽이에요. 컴파일 타임에 많은 걸 처리할 수 있는 comptime 기능, 숨겨진 제어 흐름이 없다는 명료함, 그리고 무엇보다 다른 언어의 빌드 시스템으로도 쓸 수 있다는 독특한 위치 때문에 팬층이 두텁게 형성되고 있어요.

이번 devlog에서 Zig 팀은 빌드 시스템을 크게 손봤다고 발표했어요. Zig의 빌드 시스템은 이미 "C 프로젝트를 크로스 컴파일하는 가장 쉬운 방법"으로 유명한데, 그걸 한 단계 더 개선한 거예요. 단순한 버전업이 아니라 구조적인 재작업이라 살펴볼 가치가 있어요.

빌드 시스템이 뭐고 왜 중요한가

시스템 언어를 쓰다 보면 "코드 짜는 시간"보다 "빌드 환경 세팅하는 시간"이 더 길어지는 일이 흔해요. CMake, Make, Autotools, Meson 같은 도구들이 다 그 문제를 풀려고 만들어졌지만, 각자 나름의 학습 곡선과 단점이 있어요. 특히 "리눅스에서 빌드한 걸 윈도우용으로도 만들어야 해" 같은 크로스 컴파일 상황에서는 환경 설정 지옥이 시작되거든요.

Zig의 빌드 시스템(zig build)은 빌드 스크립트를 Zig 코드로 직접 쓰게 해줘요. 별도의 DSL(특수 목적 언어)을 안 배워도 되고, IDE에서 자동완성도 받을 수 있어요. 그리고 Zig 컴파일러 자체가 LLVM 기반이라 "리눅스 ARM64용 바이너리" 같은 걸 한 줄 명령으로 뽑을 수 있어요. 이게 다른 언어 진영에서 "빌드는 Zig로 하자"는 움직임이 생기는 이유예요.

이번에 뭐가 바뀌었나

핵심 변화 중 하나는 의존성 그래프 표현 방식의 개선이에요. 빌드 시스템 내부에서 "이 단계가 끝나야 저 단계가 시작될 수 있다"는 관계를 추적하는 방식이 더 명확해졌어요. 이게 왜 중요하냐면, 의존성 그래프가 명확해야 병렬 빌드가 잘 되고, 캐시도 잘 들고, 빌드 실패 시 "어디서부터 다시 해야 하는지"가 정확해지거든요.

또 하나 큰 변화는 빌드 단계(step)들의 API가 정리됐다는 점이에요. 기존엔 "실행 파일을 만든다", "라이브러리를 만든다", "테스트를 돌린다" 같은 단계들이 각자 조금씩 다른 패턴으로 정의돼 있었어요. 새 API에서는 이걸 일관된 형태로 통일해서, 한 번 패턴을 익히면 다른 단계도 쉽게 다룰 수 있게 했어요.

그리고 캐시 시스템의 개선도 있어요. 빌드 캐시는 "이전에 만든 결과물을 재활용해서 빌드 속도를 올리는 장치"인데, 캐시가 무효화되는 조건을 더 정밀하게 잡았어요. 예전엔 "파일 하나만 바꿔도 다 다시 빌드되는" 답답한 상황이 종종 있었거든요. 이게 줄어들면 개발 루프가 훨씬 빨라져요.

마지막으로 외부 패키지 의존성 처리도 정돈됐어요. Zig는 패키지 매니저를 별도 도구가 아닌 빌드 시스템에 통합해놨는데, 이번 개편으로 의존성 해석과 잠금 파일(lockfile) 처리가 더 안정적으로 동작해요.

다른 빌드 시스템과 비교하면

CMake는 사실상 C/C++ 세계의 표준이지만, 문법이 옛스럽고 "왜 이렇게 동작하지?" 싶을 때가 많아요. Meson은 그 대안으로 인기를 끌었고, Python스러운 문법으로 가독성이 좋아요. Bazel은 구글이 만든 대규모 프로젝트용 빌드 시스템이고, 회사 단위로는 좋지만 개인 프로젝트에는 너무 무거워요.

Zig 빌드 시스템의 차별점은 "빌드 스크립트가 진짜 프로그래밍 언어"라는 점이에요. CMake의 if/foreach는 종종 답답한데, Zig에서는 그냥 평범한 Zig 코드를 쓰면 돼요. 조건 분기, 반복, 함수 정의 다 익숙한 문법 그대로예요. 그리고 크로스 컴파일이 "옵션 하나 추가하면 끝"이라는 게 정말 강력해요.

Rust의 Cargo와도 비교돼요. Cargo는 패키지 관리와 빌드를 한 도구로 묶었고 매우 편리하지만, "고도로 커스텀한 빌드"가 필요하면 build.rs 스크립트로 빠져나가야 해요. Zig는 처음부터 "빌드 스크립트는 일반 코드"라는 철학이라, 단순한 케이스와 복잡한 케이스 사이의 경계가 부드러워요.

한국 개발자 입장에서 보면

당장 "우리 회사 코드베이스를 Zig로 옮기자" 같은 결정을 할 일은 거의 없을 거예요. 하지만 몇 가지 시나리오에서는 진지하게 고려해볼 만해요.

첫째, C/C++ 프로젝트의 크로스 컴파일 환경 개선이에요. zig cc 명령은 Zig 컴파일러를 C 컴파일러처럼 쓰는 기능인데, 이걸 통해 기존 C 프로젝트를 거의 수정 없이 여러 플랫폼용으로 빌드할 수 있어요. CI에서 윈도우/리눅스/맥용 바이너리를 한꺼번에 만들어야 한다면 정말 유용해요.

둘째, 임베디드나 시스템 프로그래밍 학습용으로 가치가 커요. C는 진입 장벽이 의외로 높은데(헤더, 포인터, 빌드 시스템 같은 게 동시에 덮쳐오니까요), Zig는 이런 것들을 더 깔끔하게 정리해놨어요. "메모리를 직접 다루는 감각"을 익히기에 좋은 언어예요.

셋째, 사이드 프로젝트 도전 대상으로도 매력적이에요. 1.0이 아직 안 나왔다는 건 단점이자 장점인데, 지금 들어가면 생태계 형성에 기여할 수 있고 커뮤니티가 작아서 도움받기도 좋아요.