차세대 빌드 시스템, Nix와 Bazel의 한계를 넘어서

Nix는 derivation을 통해 `execve` 호출을 격리하고 해시 기반으로 결과를 캐싱하여 신뢰성을 높입니다. 하지만 Monadic 빌드 지원이 부족하여 복잡한 의존성 그래프 처리나 내부 빌드 시스템 통합에 어려움이 있습니다. 특히 `import from derivation (IFD)`는 평가 시간을 크게 늘려 병렬성을 저해하는 문제로 지적됩니다. 이는 빌드 시스템의 격리성(Isolation)과 효율성(Efficiency) 사이의 트레이드오프(Trade-off)를 보여줍니다.

Bazel과 Buck2에서 사용하는 Persistent Worker는 컴파일러의 시작 오버헤드(Startup Overhead)를 줄여 작은 단위의 증분 빌드를 가능하게 합니다. 이는 Hermeticity(밀폐성)를 유지하면서도 낮은 지연 시간(Low Latency)과 높은 처리량(High Throughput)을 달성하는 데 기여합니다. 글에서는 이러한 접근 방식이 컴파일러 내부의 빌드 시스템과 통합될 때 가장 큰 효과를 발휘할 수 있다고 강조합니다.

포스트모던 빌드 시스템은 '빌드 정체성(Build Identity)'을 의도적으로 배제하여 멀티테넌시(Multitenancy)와 격리성을 강화합니다. 즉, 이전 빌드와의 의미론적 동등성(Semantic Equivalence)보다는 입력 해시(Input Hash)에 기반한 이진 동등성(Binary Equivalence)만을 신뢰합니다. 이는 계산 낭비를 초래할 수 있지만, 증분 빌드 버그(Incremental Build Bugs)의 가능성을 최소화하여 프로덕션 환경에서의 신뢰도를 높이는 데 중점을 둡니다.

글에서는 WebAssembly(WASM)를 활용하여 기존 프로그램을 순수 함수(Pure Function)처럼 실행하고, Monadic 의존성을 지원하는 새로운 빌드 시스템 구현 가능성을 제시합니다. 이는 코드와 입력을 받아 격리된 환경에서 실행하며, 메모이제이션(Memoization) 및 분산 빌드(Distributed Build)를 지원할 수 있습니다. WASM은 기존 언어들을 컴파일 타겟으로 삼아 샌드박싱(Sandboxing)과 이식성을 높이는 데 기여할 수 있습니다.

대규모 Haskell 코드베이스에서 Nix의 한계를 극복하기 위해 Buck2로 전환한 사례가 소개됩니다. Buck2는 Monadic 빌드를 지원하여 타겟 의존성 그래프(Target Dependency Graph)와 모듈 의존성 그래프(Module Dependency Graph) 간의 불필요한 의존성을 제거하고, 동적 의존성(Dynamic Dependencies)을 통해 더 유연한 빌드 계획 수립을 가능하게 합니다. 이는 빌드 성능(Build Performance)과 개발자 경험(Developer Experience)을 크게 향상시켰습니다.