Determinate Nix의 미래: Wasm/WASI, 빌드 출처 추적, Flake Schemas
요약
기사 전체 정리
Nix에 Wasm/WASI가 들어간다
Determinate Systems가 Determinate Nix에 WebAssembly(Wasm)과 WASI 지원을 추가함. Nix 역사상 flakes 도입 이후 가장 큰 변화라고 자평하고 있음
왜 이게 큰 건가: 대규모 조직에서 Nix를 쓸 때 가장 고통스러운 게 "고성능, 잘 테스트된 Nix 표현식 작성"임. Nixpkgs stdenv를 자체 교체하거나, Nix로 Bazel를 재구현하거나, 모노레포용 복잡한 매크로를 만드는 팀들이 실제로 있었음
Wasm으로 가능해지는 것들:
- Go의
go.mod/go.sum파일을 evaluation 타임에 파싱 - derivation 래퍼 없이 YAML 파싱/생성
- flake 안에서 IP 주소 관리 같은 로직 구현
- Go의
WASI는 Wasm과 달리 파일시스템 접근이 가능해서, Nix가 아닌 언어로 derivation을 만들 수 있게 됨. Rust 같은 언어로 복잡한 빌드 로직을 작성하고 Nix에서 호출하는 구조
중요
> 핵심 패러다임 전환: Nix 언어와 Nixpkgs lib 함수에 의존하던 복잡한 로직을 Rust 같은 "제대로 된 언어"로 옮길 수 있게 됨. Nix의 표현력 한계를 근본적으로 우회하는 접근
Provenance — 빌드 출처 추적
기존 Nix의 provenance는 derivation 그래프 수준이었음. "이 store path가 어디서 왔는지" — 로컬 빌드인지, CI에서 빌드해서 캐시에 푸시한 건지, 어느 머신에서, 어느 캐시에서 왔는지는 알 수 없었음
Determinate Nix는 이제 store path의 출처 데이터를 서명해서 저장함. FlakeHub Cache에 푸시하면 자동으로 기록됨. 현재는 GitHub Actions 워크플로우 데이터를 첨부하는 수준이고, 향후 TPM(Trusted Platform Module) 기반 빌드 머신 신원 증명까지 확장할 계획
Flake Schemas — 출력 구조의 자유화
기존 flakes는 출력 타입이
packages,nixosConfigurations,devShells등 고정된 목록에 한정되어 있었음. 이 목록에 안 맞는 출력은nix flake show에서 "unknown"으로 표시됨Flake schemas를 쓰면 자체 출력 구조를 의미 있는 방식으로 정의할 수 있음. 사실 오래전에 발표했는데 이번 주에 드디어 실제 출시
전체 방향성: Wasm/WASI로 표현력 확장, Provenance로 하드웨어 수준까지 검증 가능한 신뢰성, Flake Schemas로 생태계 유연성. "Nix를 빌드 도구가 아니라 컴퓨팅의 기반 플랫폼으로" 만들겠다는 비전
댓글
댓글
댓글을 불러오는 중...