Zig가 자체 ELF 링커를 만든다 — LLVM에서 벗어나려는 야심찬 여정

왜 갑자기 링커 이야기인가요

시스템 프로그래밍 언어 Zig가 자체 ELF 링커(linker) 개선 작업의 진행 상황을 공유했어요. 링커라는 단어가 좀 낯설 수 있는데, 쉽게 말하면 여러 개의 컴파일된 조각(.o 파일들)을 하나의 실행 파일로 합쳐주는 도구예요. 컴파일러가 요리 재료를 손질하는 거라면, 링커는 그걸 한 접시에 예쁘게 담아내는 단계라고 보면 돼요. 그동안 대부분의 언어들은 이 단계를 LLVM의 lld나 GNU의 ld에 맡겨 왔는데, Zig는 "이제 우리 손으로 직접 만들겠다"는 거예요.

그게 왜 큰 결심이냐면, 링커는 생각보다 엄청 복잡한 소프트웨어거든요. 심볼 해석, 재배치(relocation), 섹션 병합, 디버그 정보 처리, 동적 링킹 등 수십 년간 누적된 ELF 포맷의 모든 엣지 케이스를 다뤄야 해요. 그런데도 Zig가 이걸 직접 만드는 이유는 명확해요.

무엇을 개선하고 있나요

이번 데브로그에서 강조된 핵심은 증분 컴파일(incremental compilation)과 인-프로세스 링킹(in-process linking)이에요. 기존 워크플로는 컴파일러가 코드를 컴파일해서 디스크에 .o 파일을 쓰고, 그걸 다시 별도 프로세스인 링커가 읽어서 실행 파일을 만드는 식이었어요. 이 과정에서 디스크 I/O와 프로세스 간 통신 오버헤드가 매번 발생해요. Zig는 컴파일러와 링커를 한 프로세스 안에 두고, 메모리에 있는 데이터 구조를 직접 주고받아서 이 비용을 거의 0으로 만들려고 해요.

또 하나 흥미로운 건 "바뀐 함수만 다시 링크"하는 접근이에요. 일반적인 링커는 어딘가 한 줄만 고쳐도 전체 실행 파일을 처음부터 다시 만들거든요. Zig가 목표하는 건 변경된 심볼만 그 자리에서 교체하고 나머지는 그대로 두는 방식이에요. 게임 개발자들이 좋아하는 "핫 리로드(hot reload)"의 컴파일러 버전이라고 보면 돼요. 코드 한 줄 고치고 빌드 누르면 0.1초 만에 결과를 확인할 수 있는 세상을 만들겠다는 거죠.

ELF는 리눅스의 표준 실행 파일 포맷인데, 여기에 더해 Zig 팀은 MachO(맥OS), COFF(윈도우), WASM 백엔드도 따로 만들고 있어요. 즉, 어느 플랫폼에서든 외부 링커 없이 Zig 컴파일러 하나만으로 모든 플랫폼용 바이너리를 만들어 낸다는 목표예요. 이게 바로 Zig가 자랑하는 "세상에서 가장 쉬운 크로스 컴파일"의 기반이 되는 셈이에요.

업계에서 어떤 의미인가요

LLVM은 사실상 현대 컴파일러 인프라의 표준이에요. Rust도, Swift도, 그리고 사실상 모든 새로운 시스템 언어가 LLVM 위에 올라가 있죠. 그런데 LLVM은 거대해요. 컴파일 시간도 느리고, 바이너리 크기도 크고, 의존성으로 가져오면 빌드 환경이 무거워져요. Zig는 처음부터 "LLVM은 옵션, 우리 자체 백엔드가 기본"이라는 방향을 잡고 있어요. 자체 링커는 이 비전의 마지막 퍼즐 조각인 셈이에요.

비슷한 시도로는 Rust의 mold 링커가 있어요. mold는 기존 GNU ld보다 수 배 빠른 병렬 링커로, 대형 프로젝트의 빌드 시간을 극적으로 줄여줬어요. 다만 mold는 "외부 도구"라서 컴파일러와 분리돼 있고요. Zig의 접근은 한 발 더 나아가서 링커를 언어 도구체인의 일부로 완전히 내재화하는 거예요. 이게 잘 동작하면 IDE의 자동완성처럼 "코드 입력 → 즉시 실행" 같은 인터랙티브한 개발 경험이 가능해질 수 있어요.

한국 개발자에게는요

당장 실무에 적용할 일은 많지 않을 거예요. Zig 자체가 아직 1.0이 아니라서 프로덕션 도입은 신중해야 하고요. 하지만 빌드 시스템과 개발자 경험(DX)에 관심 있는 분이라면 이 작업을 눈여겨볼 가치가 충분해요. 우리가 매일 쓰는 Webpack, Vite, esbuild 같은 프론트엔드 번들러들의 진화 과정과 본질적으로 똑같은 이야기거든요. "느린 도구를 빠르게, 분리된 단계를 통합으로"라는 방향성 말이에요.

C/C++ 프로젝트에서 빌드 시간 때문에 고생하고 있다면 zig cc를 크로스 컴파일 도구로 써보는 것도 추천이에요. Zig는 자기 자신만의 컴파일러가 아니라 clang의 드롭인 대체재로도 동작하거든요. 별도의 툴체인 설치 없이 맥에서 리눅스 ARM 바이너리를 한 줄로 빌드할 수 있어요. 인디 게임이나 임베디드 분야에서 점점 활용도가 높아지고 있고요.

마무리

링커처럼 보이지 않는 인프라를 직접 다시 만드는 건 미친 짓처럼 보이지만, 그게 진짜 혁신을 만들어 내기도 해요. 여러분의 프로젝트에서 빌드 시간이 가장 큰 골칫거리인 부분은 어디인가요? 만약 "코드 저장하면 0.1초 안에 실행 결과가 갱신되는" 환경이 가능해진다면, 개발 방식이 어떻게 바뀔 것 같으세요?