# Nix Flakes와 그에 대응하는 Guix 기능들

> Clean Markdown view of GeekNews topic #30457. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30457](https://news.hada.io/topic?id=30457)
- GeekNews Markdown: [https://news.hada.io/topic/30457.md](https://news.hada.io/topic/30457.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-13T20:05:45+09:00
- Updated: 2026-06-13T20:05:45+09:00
- Original source: [coopi.neocities.org](https://coopi.neocities.org/posts/nix-flakes-vs-guix#guix-purity-by-design_6eece251b1ca)
- Points: 1
- Comments: 1

## Topic Body

- **Nix Flakes**는 프로젝트 의존성, 잠금, 출력 스키마, 개발 환경을 `flake.nix`와 `flake.lock` 중심으로 묶고, Guix는 channels, manifests, `guix describe`, `guix shell`, `operating-system` 같은 직교 도구 조합으로 같은 종류의 기능을 제공함
- **Flakes**는 프로젝트별 `inputs`와 자동 `flake.lock`으로 의존성을 고정하고, Guix는 사용자별 `guix describe`와 프로젝트에 커밋을 적은 `channels.scm`, `guix time-machine`으로 재현 가능한 환경을 구성함
- **순수성**은 Flakes에서 restricted evaluation으로 강제되고, Guix에서는 Scheme 모듈 구조와 명시적 입력, 격리된 빌드 컨테이너를 통해 설계상 달성됨
- **출력 구조**는 Flakes가 `packages`, `devShells`, `nixosConfigurations` 같은 표준 attrset을 제공하는 반면, Guix는 `<package>`, manifest, `operating-system`, service 같은 투명한 Scheme 레코드와 파일을 각 명령이 직접 소비함
- **선택 기준**은 단일 진입점과 표준 스키마를 선호하면 Flakes가 맞고, 작고 독립적인 도구를 조합하는 방식을 선호하면 Guix가 더 잘 맞음

---

### 핵심 비교
- Nix flake에 해당하는 단일 Guix 기능은 없으며, Nix Flakes가 여러 문제를 하나의 큰 기능으로 해결하는 반면 Guix는 더 작고 직교적인 도구들의 조합으로 대응함
- Guix는 Nix daemon을 재사용했으며, build isolation과 store management를 담당하는 C++ 구성요소를 공유함
- Guix는 Nix daemon 위의 언어, 패키지 정의, 서비스 시스템 등 대부분을 Guile Scheme으로 새로 구현함
- Guix와 Nix는 derivation format인 ATerm과 daemon 계보를 공유하지만, daemon 위의 구조는 Guix 자체 방식으로 구성됨
- Guix는 Flakes가 제공하는 capabilities를 갖고 있지만, 이를 다른 형태로 제공함

### Nix Flake의 기본 구조
- **Nix flake**는 root에 `flake.nix` 파일을 가진 source tree이며, 보통 Git repository 형태임
- `flake.nix`의 존재가 source tree를 flake로 만들며, 파일은 `description`, `inputs`, `outputs` 같은 구조를 가짐
- `description`은 사람이 읽을 수 있는 문자열로 flake가 제공하는 내용을 나타냄
- `inputs`는 다른 flakes, Git repos, tarballs 같은 dependencies를 선언하며, Nix가 이를 fetch하고 evaluate한 뒤 `outputs` 함수에 전달함
- `outputs`는 resolved inputs와 특별한 `self` input을 받아 packages, dev shells, NixOS configurations, overlays 등을 담은 structured attrset을 반환하는 함수임
- ## 예시 구조와 실행 대상
  - 예시 `inputs`의 `nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";`는 GitHub의 `NixOS/nixpkgs` 저장소에서 `nixos-unstable` branch를 가져온다는 의미임
  - 예시 flake는 `supportedSystems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" ];`와 `nixpkgs.lib.genAttrs`를 사용해 여러 CPU architecture별 outputs를 생성함
  - Flakes는 `packages.<system>` 수준을 요구하며, 예시에서는 `packages` 아래 `default` package를 `pkgs.buildGoModule`로 정의함
  - `src = ./.;`는 전체 Git repository를 source로 사용함
  - `devShells`는 `nix develop`이 참조하는 개발 shell 정의이며, 예시에서는 `pkgs.mkShell`과 `buildInputs = with pkgs; [ go gopls gotools ];`를 사용함
- ## `flake.lock`과 순수 평가
  - Nix 명령을 flake에 대해 실행하면 Nix는 모든 input과 transitive input을 정확한 revision으로 고정하는 JSON 파일 `flake.lock`을 생성함
  - `flake.lock`은 machine과 시간에 걸쳐 build reproducibility를 가능하게 하는 lock file임
  - Flakes는 pure evaluation을 강제하며, `$NIX_PATH`, `builtins.currentSystem`, environment variables가 암묵적으로 들어오지 못하고 모든 것이 explicit해야 함
  - Flakes가 수행하는 기능은 dependencies 선언, dependencies pinning, purity 강제, standard output schema 제공, reproducible sharing, development environments 정의로 정리됨

### Guix의 대응 방식
- Guix는 Nix 2.4에서 Flakes가 2021년 11월 1일 도입되기 전에 Flakes 기능 상당수에 대한 해법을 이미 갖고 있었음
- Guix channels mechanism은 2018~2019년경 도입됨
- Guix의 해법은 **orthogonal**하며, 단일 monolithic abstraction을 채택하지 않고 각 도구를 독립적으로 사용할 수 있음
- ## Channels와 의존성 선언
  - Flake에서는 `flake.nix` 안에 dependencies를 직접 선언하며, 예시에서 `nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.11";`와 `home-manager.url = "github:nix-community/home-manager";`를 사용함
  - Flake input의 `inputs.nixpkgs.follows = "nixpkgs";`는 `home-manager` 자체의 `nixpkgs` input을 가져오지 않고 현재 flake의 `nixpkgs`를 사용하게 해 서로 다른 nixpkgs copy 두 개가 생기는 상황을 피함
  - Guix의 **channels**는 Guile modules를 포함하는 Git repository이며, 보통 package definitions를 담지만 services, system configurations, 임의 Scheme code도 포함할 수 있음
  - Guix channels는 `~/.config/guix/channels.scm`에 선언하며, 이 Scheme 파일은 channel records의 list를 반환함
  - `guix pull`은 모든 channels를 fetch하고 compile하며, 해당 modules를 모든 `guix` command에서 사용할 수 있게 함
  - Channels는 repository root의 `.guix-channel` 파일을 사용해 다른 channels에 대한 dependencies를 선언할 수 있음
  - Guix channels의 channel dependency는 flake의 `inputs`와 대략 유사하며, `guix pull` 실행 시 transitive channel dependencies가 함께 fetch됨
- ## 프로젝트별 의존성과 사용자별 의존성
  - Flakes는 per-project 방식으로 각 repository가 자체 `flake.nix`와 inputs를 가지며, channels는 system-wide 또는 per-user 방식으로 `channels.scm`이 모든 `guix` invocations에 적용됨
  - Flakes는 서로 다른 프로젝트가 서로 다른 dependency set을 자연스럽게 갖도록 지원하며, Guix에서는 같은 효과를 위해 보통 `guix time-machine` 또는 separate profiles를 사용함
  - Flakes는 `github:NixOS/nixpkgs`, `git+https://...` 같은 URL-like syntax를 사용하며, channels는 plain Git URLs를 사용함
  - Flake syntax는 quick references에 더 ergonomic하고, channels는 더 단순하고 explicit함
  - Flakes는 `flake = false;`로 `flake.nix`가 없는 repositories를 non-flake inputs로 지원함
  - Guix에서 channel은 Scheme files가 들어 있는 Git repository이므로 특별한 opt-in이 필요 없으며, Guile modules가 있는 어떤 repository도 channel이 될 수 있음

### 고정, 재현성, 시간 이동
- ## `flake.lock`
  - `flake.lock`은 JSON graph이며, 모든 input은 정확한 commit hash로 pinning되고 Nix는 fetch한 source tree 전체의 hash인 `narHash`를 검증함
  - `flake.lock`은 repository에 commit되므로, clone한 사람은 동일한 dependency versions를 받음
  - `flake.lock`의 `original`은 요청한 대상이고 `locked`는 실제로 얻은 대상임
  - `flake.lock`의 two-layer system은 `nix flake lock --update-input nixpkgs`처럼 특정 input만 업데이트하고 나머지는 유지하는 selective update를 가능하게 함
- ## `guix describe`와 `guix time-machine`
  - Guix는 `guix pull` 실행 시 모든 channels의 정확한 commits를 기록하며, `guix describe`가 이 정보를 보여줌
  - `guix describe` 출력은 generation 번호, 날짜, current 표시, channel 이름, repository URL, branch, commit을 포함함
  - Guix의 recorded channel commits는 lock file에 해당하지만, project directory의 파일이 아니라 `~/.config/guix/current`에 Guile profile로 존재함
  - 재현 가능한 환경을 공유하려면 Guix에서 **`guix time-machine`** 을 사용할 수 있음
  - `guix time-machine --commit=8a1ab328 -- shell -m manifest.scm`은 Guix 자체를 특정 revision으로 pinning한 뒤 그 revision의 package definitions를 사용해 `guix shell`을 실행함
  - `guix time-machine`은 필요한 경우 해당 revision을 download하고 compile하며, package definitions가 정확히 해당 commit 상태인 isolated environment를 생성함
  - 프로젝트 repository에 pinned commits를 가진 `channels.scm`을 check in하는 Guix 패턴도 있음
  - `guix time-machine -C channels.scm -- shell -m manifest.scm`은 repository에 포함된 `channels.scm`을 사용해 exact environment를 재현함
- ## 두 방식의 차이
  - `flake.lock`은 per-project이면서 automatic이고, `guix describe`는 per-user이면서 automatic임
  - Pinned commits가 들어간 `channels.scm`은 Guix에서 per-project pinning을 제공하지만 manual 방식임
  - Guix는 per-project pinning ergonomics를 개선 중이지만, 현재 workflow는 더 explicit setup이 필요함
  - `flake.lock`은 machine-readable JSON graph이고, Guix의 대응물은 commit hashes를 가진 channels를 나열한 Scheme file임
  - 두 방식 모두 dependency pinning 목표를 달성하지만, flake lock은 모든 transitive input에 `original`과 `locked` entries를 가진 full dependency graph라 더 structured함
  - `guix time-machine`은 direct flake equivalent가 없는 기능이며, pinned dependency versions뿐 아니라 package collection의 완전히 다른 historical state로 이동할 수 있음

### 순수성 모델
- Flakes는 restricted evaluation context에서 실행되며, `builtins.currentSystem`, `builtins.getEnv`, `$NIX_PATH` 사용이 금지되거나 무시됨
- Flakes에서 모든 것은 declared inputs에서 와야 하며, implicit state에 accidental dependency가 생기기 어렵게 함
- Flakes의 pure evaluation trade-off는 system detection을 위해 명시적 `system` parameters가 곳곳에 필요하고, environment variables 읽기가 불가능하다는 점임
- Flakes에서 impure escape hatch가 필요할 때는 `--impure`를 명시적으로 전달해야 함
- Guix는 별도 pure evaluation mode가 필요 없으며, evaluation이 convention상 이미 pure함
- Guile modules는 environment variables에 명시적으로 전달하지 않는 한 접근하지 않음
- Guix에는 `$NIX_PATH`에 해당하는 것이 없으며, packages를 search path가 아니라 module system을 통해 resolve함
- Guix에는 `builtins.currentSystem`에 해당하는 개념이 없고, systems는 package metadata와 `--system` flag로 명시함
- Guix의 build도 pure하며, builds는 explicitly declared inputs만 보이는 isolated containers에서 실행됨
- Guix builds에서는 `/usr/bin`, `/etc`, network access가 없으며, network access 예외는 fixed-output derivations에 한정됨
- Build sandboxing 방식은 Nix와 Guix가 본질적으로 같은 접근을 공유함
- Guix는 Scheme modules 구조를 통해 architecture 차원에서 purity를 달성하고, Flakes는 원래 impure한 system 위에 restricted evaluation mode를 얹어 purity를 강제함

### 출력 스키마와 데이터 모델
- ## Flake output schema
  - Flakes는 outputs에 대한 standard schema를 정의하며, `packages.<system>.<name>`은 `nix build`, `devShells.<system>.<name>`은 `nix develop`, `apps.<system>.<name>`은 `nix run`에서 사용됨
  - Flake output schema에는 `nixosConfigurations.<name>`, `overlays.<name>`, `nixosModules.<name>`, `formatter.<system>`, `templates.<name>`, `checks.<system>.<name>`도 있음
  - Flake output schema의 standardization은 `nix build .`, `nix run`, `nix flake show`가 일관된 위치를 참조하게 해 discoverability를 높임
  - Flake output schema의 단점은 rigid하다는 점이며, 임의 output types를 추가하려면 Nix 자체 수정이 필요하지만 작은 extension mechanism은 존재함
  - Flake의 `<system>` parameter 때문에 multi-platform support를 explicit하게 처리해야 하며, `forAllSystems`, `flake-utils`, `flake-parts` 같은 helper functions 또는 libraries가 사용됨
- ## Guix의 first-class data types
  - Guix에는 Flakes처럼 단일 output schema가 없고, 여러 command가 소비할 수 있는 first-class data types가 있음
  - Guix에서 packages는 `<package>` records로 정의되고 `guix install`, `guix build`가 사용함
  - Guix에서 manifests는 Scheme files로 정의되고 `guix shell -m`, `guix package`가 사용함
  - Guix에서 system configs는 `operating-system`으로 정의되고 `guix system reconfigure`가 사용함
  - Guix에서 home configs는 `home-environment`로 정의되고 `guix home reconfigure`가 사용함
  - Guix에서 services는 `<service>` records로 정의되고 `operating-system`의 `services` field가 사용함
  - Guix에서 channels는 Git repos이며 `guix pull`이 사용함
  - Guix에서 package variants는 Scheme procedures이며 `--with-input`, `--transform`이 사용함
- ## 파일과 패키지 정의
  - Guix project는 package definitions가 있는 channel, development용 `manifest.scm`, deployment용 `system.scm`, `operating-system` 또는 `home-environment` declaration 등을 조합해 제공할 수 있음
  - Guix에서는 이런 파일들이 special entry point file을 요구하지 않으며, Scheme values를 정의하는 Scheme files일 뿐임
  - Guix에서는 관련 `guix` subcommand에 파일을 지정하면 command가 처리하며, 별도 ceremony나 schema validation이 필요 없음
  - 예시 `manifest.scm`은 `specifications->manifest`에 `"guile"`, `"guile-git"`, `"guile-json"` package names list를 넘겨 development environment를 선언함
  - 예시 `mylib.scm`은 Guix의 Nix derivation 대응물인 `<package>` record를 정의하며, package fields를 programmatically query할 수 있음
  - 예시 package definition은 `(name "mylib")`, `(version "0.1.0")`, `(source (local-file "."))`, `(build-system gnu-build-system)`, `(inputs (list guile guile-git))`, `(home-page "https://example.com")`, `(license gpl3+)`를 가짐
  - Guix의 `local-file`은 build time에 current directory의 files를 가져오며, Nix의 `src = ./.;`와 유사함
  - Guix의 `gnu-build-system`은 `./configure && make && make install` 방식이며, Guix에는 `cmake-build-system`, `python-build-system` 등 다른 build systems도 있음
  - Guix는 Nix에서 `stdenv`가 `gcc`와 `coreutils`를 implicit하게 제공하는 것과 달리 dependencies를 모두 explicit하게 둠

### 개발 환경
- Flakes의 `devShells` 예시에서는 `devShells.x86_64-linux.default = pkgs.mkShell { buildInputs = with pkgs; [ go gopls gotools ]; shellHook = '' echo "Welcome to the devShell!" ''; };`를 사용함
- `mkShell`은 build될 때 shell environment를 만드는 derivation을 생성하며, `buildInputs`는 shell 안의 `PATH`에 들어가고 `shellHook`은 shell 진입 시 arbitrary bash를 실행함
- Flake dev shell에는 `nix develop` 또는 named shell용 `nix develop .#my-shell`로 진입함
- Guix development environment는 `manifest.scm`에서 `specifications->manifest`에 package specification strings list를 넘겨 정의할 수 있음
- 예시 Guix manifest는 `"go"`, `"gopls"`, `"go-tools"`를 선언함
- Guix manifest 기반 shell에는 `guix shell -m manifest.scm`으로 진입함
- Guix는 ad-hoc environment에서 파일 없이 `guix shell go gopls go-tools`처럼 command line package names만 전달할 수 있음
- `guix shell`은 full isolation을 위한 `--container`, standard Linux filesystem layout을 기대하는 프로그램 실행용 `--emulate-fhs`, Guix container 안에서 Guix를 실행하는 `--nesting`을 지원함
- Guix manifests는 더 큰 `flake.nix` 구조에 embedded되지 않은 standalone Scheme files임
- `guix shell`은 파일 없이도 동작할 수 있지만, `nix develop`은 flake 또는 legacy interface의 `shell.nix`가 필요함
- Flakes는 `devShells.x86_64-linux.test`, `devShells.x86_64-linux.default` 같은 named dev shells를 제공함
- Guix manifests는 named dev shells 대신 `manifest.scm`, `test-manifest.scm` 같은 별도 파일을 나란히 두는 방식임
- Nix Flakes와 Guix 모두 containerized development를 지원함

### 시스템 구성
- ## NixOS와 Flakes
  - Flakes의 `nixosConfigurations` 예시에서는 `nixpkgs.lib.nixosSystem`이 NixOS modules list를 받아 kernel, services, config files 등을 포함한 full system derivation을 생성함
  - Flake 기반 NixOS 배포 예시 명령은 `nixos-rebuild switch --flake .#myhost`임
  - 예시 `nixosConfigurations.myhost`는 `system = "x86_64-linux";`와 `modules = [ ./configuration.nix home-manager.nixosModules.home-manager ];`를 포함함
  - NixOS modules는 `options`, `config`, `mkIf`, `mkDefault`, `mkForce`를 통한 priority-based merging을 사용하는 module system임
  - NixOS 모듈 시스템은 여러 모듈이 같은 옵션을 설정해도 시스템이 우선순위를 해소하며, 수십 개 모듈이 같은 구성에 기여해도 충돌을 피하기 쉬움
- ## Guix `operating-system`
  - Guix의 `operating-system`은 function이 아니라 Scheme record이며, 각 field는 named typed value로 Guix가 validate함
  - Guix system 배포 예시 명령은 `guix system reconfigure config.scm`임
  - 예시 `operating-system` record는 `(host-name "myhost")`, `(timezone "Etc/UTC")`, bootloader configuration, file systems, services를 포함함
  - Guix bootloader configuration 예시는 `grub-efi-bootloader`와 target `"/boot/efi"`를 사용하며, Guix는 GRUB, U-Boot 등을 지원함
  - Guix file systems는 list로 선언되며, `%base-file-systems`는 `/dev`, `/proc`, `/sys` 등에 대한 defaults를 제공함
  - Guix services는 directed acyclic graph(DAG)를 이루며, 각 service는 다른 services를 extend할 수 있음
  - `%base-services`는 Shepherd init system, syslog, networking 등 필수 services를 제공함
  - Guix system configuration에는 special output type이 필요 없고, `operating-system` record를 반환하는 파일을 `guix system`에 지정하면 됨
  - Guix의 서비스 조합은 기존 시스템에 임의의 방식으로 연결되는 새 서비스를 작성하기 쉽게 만듦

### 탐색성과 레지스트리
- Flakes에는 프로젝트 의존성, 출력, 발견 가능한 스키마를 한 파일에서 선언하는 표준 진입점 `flake.nix`가 있음
- Guix 프로젝트는 `manifest.scm`, `channels.scm`, `guix.scm`, `package.scm` 등 관례 기반 파일을 사용할 수 있음
- `guix shell`이 자동으로 인식하는 프로젝트 파일로 `guix.scm`를 표준화하려는 움직임이 있지만, `flake.nix`만큼 확립되지는 않았음
- Flakes에는 짧은 이름을 URL에 매핑하는 전역 레지스트리 [flake-registry](https://github.com/NixOS/flake-registry)가 있으며, 예시는 `nix run nixpkgs#hello`, `nix build github:NixOS/nixpkgs#firefox`임
- Guix는 비슷한 편의성을 위해 패키지 명세를 사용하며, 예시는 `guix shell hello`, `guix install firefox`임
- Guix에는 임의의 Git 저장소를 짧은 이름으로 가리키는 레지스트리 대응물이 없고 URL을 직접 사용함
- Nix 레지스트리는 `nixpkgs`가 레지스트리 항목인지, 로컬 경로인지, 다른 대상인지 항상 명확하지 않아 혼란의 원천이 된 적이 있음
- `nix flake show`는 flake가 제공하는 모든 항목을 트리 뷰로 보여주는 명령임
- Guix에는 패키지용 `guix search`와 서비스용 `guix system search`가 있지만, 특정 프로젝트나 저장소가 제공하는 모든 항목을 보여주는 대응 명령은 없으며 Scheme 파일을 직접 확인해야 함
- Flakes는 `nix flake show`가 project가 제공하는 것들을 consistent view로 보여준다는 점에서 discoverability가 강함
- Guix projects는 더 ad-hoc하며, 어떤 파일을 봐야 하는지 알아야 하고 standard single-entry-point file이 없음
- Guix는 모든 것이 Scheme이기 때문에 schema 없이 원하는 것을 정의하고 조합할 수 있어 flexibility가 강함

### 패키지 모델과 그래프 재작성
- Nix에서 패키지는 `stdenv.mkDerivation { ... }` 호출로 derivation을 반환하는 함수이며, 그 결과는 불투명한 attribute set임
- Guix에서 패키지는 `<package>` 레코드이며, 이름이 붙은 필드를 가진 투명한 데이터 구조라 표준 Scheme 절차로 검사, 변환, 조합할 수 있음
- Guix package definitions는 opaque functions가 아니라 transparent records이므로 special tooling 없이 inspect와 transform을 programmatically 수행할 수 있음
- Guix에서는 packages가 data이므로 graph rewrites를 쉽게 수행할 수 있음
- Guix에서는 `package-input-rewriting`으로 전체 의존성 그래프를 순회해 `perl`을 `perl-minimal`로 바꾸는 작업을 표현할 수 있음
- Guix의 `inherit` 키워드는 `coreutils`의 모든 필드를 물려받고 지정한 필드만 덮어쓰는 방식으로 패키지를 재정의함
- Nix에는 비슷한 목적의 overlays가 있지만, 불투명한 함수 인터페이스 때문에 검사와 변환이 더 어려워 사용성이 떨어짐

### 보안 업데이트, 부트스트랩, 인증
- Guix의 [grafting](https://guix.gnu.org/manual/en/html_node/Security-Updates.html)은 모든 의존 패키지를 다시 빌드하지 않고 의존성 트리에 보안 업데이트를 적용할 수 있게 함
- glibc 같은 저수준 라이브러리에 취약점이 있을 때 Guix는 저장소 경로를 다시 작성해 수정 버전으로 교체할 수 있음
- Nix는 보안 업데이트 상황에서 모든 것을 다시 빌드하며, 큰 의존성 트리에서는 빌드 시간이 몇 시간 차이 날 수 있음
- Guix는 [소스 기반 부트스트래핑](https://guix.gnu.org/manual/en/html_node/Bootstrapping.html)에 강하게 집중하며, 전체 시스템을 작은 신뢰 기반에서 빌드할 수 있음
- Guix의 부트스트랩 체인은 약 500바이트 hex assembler에서 시작해 Scheme으로 작성된 `mes` C 컴파일러, `tcc`, 전체 GNU toolchain으로 이어짐
- [bootstrappable builds](https://bootstrappable.org/) 프로젝트는 전체 소스 부트스트랩 세부 사항을 다룸
- Nix는 Guix보다 더 많은 바이너리 시드에 의존함
- 부트스트랩 체인을 감사할 수 없으면 시스템이 실제로 의도한 소스에서 빌드됐는지 완전히 검증할 수 없으므로, 전체 소스 부트스트래핑은 신뢰와 검증 가능성에 중요함
- Guix channels는 [암호학적 인증](https://guix.gnu.org/manual/en/html_node/Channel-Authentication.html)을 기본 지원함
- Guix channel은 특정 커밋과 그 Ed25519 서명으로 구성된 “introduction”을 지정하며, Guix는 해당 introduction부터 현재 커밋까지 전체 서명 체인을 검증함
- Flakes는 신뢰 모델로 HTTPS와 GitHub 인프라를 사용하며, 이는 Guix의 Ed25519 channel authentication과 다른 보안 모델임

### 요약 표의 핵심 대응 관계
- 의존성 선언은 Flakes가 `flake.nix`의 `inputs`, Guix가 `channels.scm`과 `.guix-channel`을 사용함
- 의존성 고정은 Flakes가 자동·프로젝트별 `flake.lock`을 사용하고, Guix가 사용자별 자동 `guix describe`와 프로젝트별 수동 커밋 지정 `channels.scm`을 사용함
- 순수 평가는 flake mode에서 강제되고, Guix에서는 설계상 내재된 특성임
- 출력 스키마는 Flakes가 `outputs`의 구조화된 attrset을 쓰고, Guix가 ad-hoc Scheme records를 씀
- 개발 환경은 Flakes가 `devShells`와 `nix develop`, Guix가 `manifest.scm`와 `guix shell`을 씀
- 시스템 구성은 Flakes가 `nixosConfigurations`와 모듈 시스템, Guix가 `operating-system`과 서비스 DAG를 씀
- 한 명령 재현성은 Flakes가 `nix build github:foo/bar`, Guix가 `guix time-machine -C channels.scm -- build` 형태임
- 프로젝트별 고정은 Flakes가 `flake.lock`으로 자동 처리하고, Guix가 커밋이 들어간 `channels.scm`으로 수동 처리함
- 탐색성은 Flakes가 `nix flake show`, Guix가 Scheme 모듈 검사에 의존함
- 패키지 모델은 Flakes/Nix가 불투명 함수, Guix가 투명 레코드임
- init system은 Nix가 systemd, Guix가 GNU Shepherd를 사용함
- 보안 업데이트는 Nix가 전체 재빌드, Guix가 빠른 grafting을 사용함
- 부트스트랩 신뢰는 Nix가 바이너리 시드, Guix가 전체 소스 부트스트랩에 기반함
- 인증된 업데이트는 Flakes가 HTTPS/GitHub 신뢰, Guix가 Ed25519 channel authentication을 사용함
- FHS 지원은 Nix가 `buildFHSUserEnv`, Guix가 `--emulate-fhs`를 제공함
- 비 Linux 지원은 Nix가 macOS용 nix-darwin, Guix가 GNU Hurd로 정리됨
- 자유 소프트웨어 전용 여부는 Nix가 전용이 아니며 구성 가능하고, Guix는 FSDG를 준수함

### 결론
- Flakes와 Guix는 재현성, 의존성 관리, 시스템 선언이라는 같은 종류의 문제를 서로 다른 아키텍처 철학으로 해결함
- Flakes는 하나의 파일, 하나의 스키마, 하나의 잠금 파일, 하나의 관례 집합을 갖춘 단일 기능에 가까움
- Guix는 배포용 channels, 환경용 manifests, 구성용 `operating-system`, 재현성용 `guix time-machine`, 기타 구조를 위한 Scheme records 같은 직교 도구들의 조합임
- 하나의 표준 방식, 하나의 진입점 파일, 하나의 출력 스키마, 하나의 잠금 형식을 선호하면 Flakes가 자연스럽게 맞음
- 작고 독립적인 도구를 조합해 각 도구가 한 가지를 잘하게 하는 Unix 철학을 패키지 관리에 적용하는 방식을 선호하면 Guix가 잘 맞음
- 두 생태계는 패키지 관리가 함수형, 선언적, 재현 가능해야 한다는 아이디어를 중심으로 발전했으며, 서로 다른 구현으로 같은 아이디어를 밀어붙이고 있음

## Comments



### Comment 59559

- Author: neo
- Created: 2026-06-13T20:05:47+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/fybei2/nix_flakes_their_guix_equivalents) 
- 이 사이트는 모바일에서 읽기가 너무 답답함: 글자가 약간 작고, 스크롤할 때마다 계속 방해함  
  첫 번째 비교 이후로는 읽을 수가 없었는데, 계속 **목차로 튕겨 올라가기** 때문임
  - 아예 읽을 수가 없음. 요요처럼 움직임. 최근에 정말 읽고 싶었던 글 중 하나였는데, 역대급으로 **좌절스러운 읽기 경험**이라 실망스러움
  - 데스크톱에서도 같은 일이 생김. 말도 안 되고, 의도적으로 접근성을 망친 것처럼 보임

- 글을 읽고도 프로젝트의 의존성을 어떻게 지정하고 고정해야 하는지 아직 잘 모르겠음. 배포하고 공유하려면 `channels.scm`에 각 전이 의존성의 커밋 해시를 수동으로 찾아 넣어야 하는 것처럼 보임  
  `time-machine`은 Guix 패키지 집합에만 동작하고, 트리 밖 의존성에는 안 되는 듯함  
  `nix run github:nixos/nixpkgs/<commit hash>#<package>`처럼 nixpkgs의 과거 시점 코드도 꽤 쉽게 실행 가능함  
  Guix가 독특한 부분은 **패키지 모음 버전**과 **패키지 관리자 버전**을 분리하지 않는다는 점임. 오래된 패키지를 실행하려면 오래된 Guix 릴리스도 함께 실행하게 되는데, 왜 그걸 원해야 하는지 잘 모르겠음  
  글에서는 flakes가 커밋을 수동으로 찾아 지정해야 한다고 하면서, 바로 뒤에 커밋을 지정해야 하는 Guix 명령을 예로 듦. Nix flake에서도 `--override-input`으로 nixpkgs 버전을 덮어쓸 수 있지만 지저분하고, 그래서 unflake에서 개선하려는 부분 중 하나임
  - 내가 글쓴이보다 Guix 사용 경험은 적지만 문서는 어느 정도 봤으니 몇 가지 답해보겠음  
    보통 전용 `guix shell` 환경에서 개발하다가, 공유할 단계가 되면 `guix describe -f channels > channels.scm`로 모든 커밋 해시를 `channels.scm`에 기록하는 흐름임  
    [declaring channel dependencies](https://guix.gnu.org/manual/devel/en/html_node/Declaring-Channel-Dependencies.html) 문서를 보면 의존성 커밋은 지정할 수 있지만, 그 의존성이 다시 의존성을 가질 때 그쪽도 특정 커밋에 고정됐는지 검증하는 옵션은 없어 보임  
    `time-machine`의 `--commit=` 표기는 Guix 채널에 해당하지만, `-C`로 파일에서 채널을 추가로 불러올 수 있음  
    패키지 관리자와 패키지 레코드에 **호환성 깨지는 변경**이 생겨도, 이력과 재현성을 잃지 않게 해주는 장점이 있음
  - 이를 위해 nixpkgs의 역색인을 만들면 가능함: nixpkgs의 커밋 X부터 Y까지가 특정 패키지의 버전 A를 포함한다는 식임  
    다만 각 커밋마다 nixpkgs 체크아웃이 필요해서 처음 구축 비용이 매우 큼. 한 번 만든 뒤 색인을 유지하는 비용은 낮을 것임

- 사이트 문제와 이 스레드를 coopi에게 알려뒀으니 곧 고쳐지길 바람  
  완전히 Guix 쪽으로 기운 입장에서, coopi가 말한 것처럼 Guix에도 Nix처럼 `flake.nix` 하나나 `nix` 디렉터리 하나로 모든 것을 담는 **표준 파일/디렉터리**가 있으면 좋겠음. 다만 Scheme 모듈을 가져오려면 올바른 경로를 지정해야 해서 불가능할 수도 있음  
  이 Lobsters 글에는 저자가 말하는 것들이 들어 있으니 태그는 `nix`와 `lisp`만으로도 충분해 보임
  - `linux`를 빼자는 건 설득되지 않음. 둘이 공통으로 가진 유일한 커널이니까 :P 다만 말한 대로 `unix`는 어울리지 않을 가능성이 큼
  - flakes처럼 채널이 무엇을 제공하는지 자동으로 추론하는 데 도움을 주는 **구조화된 채널 자료형**도 있으면 좋겠음  
    예를 들면 이런 식임:  
    ```scheme  
    (channel  
      (operating-systems  
        (list my-vm))  
      (services  
        (list my-system-service)))  
    ```  
    그리고 새 채널을 만들고 다루는 데 도움을 주는 `guix channel` 명령도 있으면 좋겠음

- Guix에도 Nix flake의 `.inputs.nixpkgs.follows`처럼 **전이 의존성의 고정값을 덮어쓰는** 기능이 있는지 궁금함  
  또 저자의 Guix 설명 상당 부분이 flakes 이전의 Nix를 떠올리게 함: 표준 진입점이 없고 채널을 쓰는 구조 등. 다만 Guix에서는 형식 체계와 진짜 언어가 있어서 같은 패턴이 고통점이 덜 되는 것 같음. Nix가 더 낫거나 다른 언어였다면 나왔을 대체역사처럼 느껴짐
  - 그 기능은 무엇에 쓰는 건가?

- 다른 댓글에서 지적한 사용성 문제 때문에 추천하기가 망설여짐. 기본으로 JavaScript를 끄는 NoScript를 써서 나는 알아차리지 못했음  
  그래도 이 글은 딱 필요한 시점에 왔음. 회사에서 Nix를 많이 쓰는 방향으로 가고 있고 flakes 때문에 조금 고생 중인데, 이 글의 설명이 이전에 읽은 것들보다 훨씬 명확했음
  - Coopi가 말하길, JavaScript나 CSS가 없어도 읽을 수 있게 **점진적 향상**을 따르려고 노력했고, JavaScript 쪽은 망쳤지만 적어도 그 철학은 동작하고 있었다고 함. 이제 JavaScript도 고쳐졌을 것이라고 함

- Coopi의 답변임: 오늘 아침 변경을 했지만 일 때문에 테스트를 못 했고, 알고 보니 **JavaScript에 문제**가 있었다고 함

- 이 사이트는 iOS 모바일에서 사용할 수 없음. 페이지가 아래쪽에서 로드된 뒤 즉시 위로 스크롤되는 것 같고, 내가 한 화면 이상 아래로 내리면 무언가가 트리거되어 다시 위로 올려버림  
  읽기 모드는 동작하지만 강조 표시와 원래 꽤 괜찮은 세부 스타일링이 사라짐

- flakes가 하는 일을 Guix의 여러 도구로도 할 수 있다고 말하는 건 타당하지만, Nix에도 같은 문제를 해결할 수 있는 작고 직교적인 도구들이 예전부터 있었고 지금도 있다는 점은 짚어야 함  
  flakes가 제공하는 건 **표준 프로젝트 진입점**과 그것이 가능하게 하는 생태계, 예를 들면 레지스트리임. 글에서도 Guix에는 이 부분이 없다고 함  
  Guix 사용자들은 표준 진입점이 필요 없다고 판단할 수 있고, 많은 Nix 사용자도 그렇게 판단해 왔음  
  하지만 직교적인 도구 모음으로 flakes를 할 수 있다고 말하는 건, FreeBSD는 jail로 필요한 걸 다 할 수 있으니 OCI 지원이 필요 없다는 주장과 비슷하게 들림. 표준화가 생태계를 가능하게 한다는 부분을 놓침  
  Guix에 관심이 많고 기여도 조금 했는데, `channels.scm`과 함께 `guix time-machine`으로 빌드하는 것이 flake 고정값을 바꾸고 Nix 평가를 하는 것보다 왜 그렇게 오래 걸리는지 비교해보고 싶음. 3배 정도 느려지는 것, 예를 들어 5~10초가 15~30초가 되는 정도라면 받아들일 수 있지만, 내가 시도했을 때는 그 정도와는 거리가 멀었음