Zig 증분 컴파일, 이제 실사용 앱도 50~70밀리초에 다시 빌드

• Zig 컴파일러의 증분 컴파일이 이제 장난감 수준을 벗어나 실사용 단계까지 올라옴

  • Zig 코어팀 멤버가 직접 구현에 참여한 기능이고, 최근 몇 번의 릴리스 사이클을 거치며 개념 증명 수준에서 실제 프로젝트에 쓸 수 있는 수준으로 발전했다고 함
  • 지금은 Zig 코어팀 대부분이 매일 쓰는 기능이라고 하니, 내부 실험 플래그 느낌은 꽤 벗어난 셈임

• 핵심 아이디어는 “프로젝트 전체를 다시 빌드하지 말자”가 아니라, 훨씬 더 잘게 쪼개는 쪽임

  • 컴파일러가 마지막 빌드 이후 어떤 함수와 선언이 바뀌었는지 감지함
  • 바뀐 코드만 다시 컴파일하고, 그 결과 바이트를 출력 바이너리에 직접 꽂아 넣음
  • 즉, 링크부터 바이너리 생성까지 매번 풀코스로 다시 도는 게 아니라 필요한 부분만 외과수술하듯 바꾸는 구조임

• 숫자가 꽤 세다. 실제 복잡한 앱 수정이 밀리초 단위로 돌아간다고 함

  • 예시로 든 앱은 Fizzy라는 픽셀 에디터 애플리케이션임
  • 초기 빌드는 약 5초 걸렸고, 이후 코드를 조금씩 바꿀 때마다 재빌드는 50~70밀리초에 끝남
  • 이 정도면 “빌드 누르고 기다림”이 아니라 “저장하자마자 거의 바로 확인”에 가까운 경험임

• Zig 입장에선 이게 꽤 중요한 퍼즐 조각임

  • 시스템 프로그래밍 언어는 빌드 시간이 길어질수록 실험 속도가 확 떨어짐
  • 특히 그래픽 앱, 게임, 툴링처럼 “조금 바꾸고 바로 확인”하는 작업에서는 재빌드 시간이 개발 감각을 좌우함
  • Zig가 C/C++ 대체재를 노린다면 언어 문법이나 안전성만큼 빌드 경험도 설득 포인트가 됨

• 아직 원문은 내부 구현 소개의 출발점에 가깝지만, 방향은 명확함

  • 변경 추적 단위를 함수와 선언까지 낮춤
  • 결과물을 새로 만드는 대신 기존 바이너리를 패치함
  • 코어팀이 매일 쓰는 수준까지 올라왔다는 점에서, “언젠가 될 기능”이 아니라 Zig 생태계의 현재 개발 경험으로 들어오고 있음

---

기술 맥락

• 여기서 Zig가 고른 선택은 파일 단위 재컴파일보다 더 작은 함수와 선언 단위 추적이에요. 왜냐면 개발자가 실제로 바꾸는 건 보통 파일 전체가 아니라 함수 하나, 상수 하나, 타입 선언 하나인 경우가 많거든요.

• 출력 바이너리에 바이트를 직접 패치하는 방식도 꽤 공격적인 선택이에요. 전체 링크 과정을 다시 태우면 작은 수정에도 고정 비용이 생기는데, Zig는 그 비용을 피해서 “수정 후 실행” 사이의 시간을 줄이려는 거예요.

• 이 기능이 의미 있는 이유는 단순히 빌드 숫자가 예쁘기 때문만은 아니에요. 초기 빌드가 5초 걸리는 실제 픽셀 에디터에서 이후 수정이 50~70밀리초에 끝난다면, 개발자는 컴파일러를 기다리는 대신 계속 실험할 수 있어요.

• 시스템 언어 쪽에서는 이런 피드백 속도가 생산성에 바로 영향을 줘요. C나 C++ 프로젝트에서 빌드 시간이 길어지는 문제를 겪어본 팀이라면, Zig의 증분 컴파일이 언어 선택의 실질적인 근거가 될 수 있어요.