NixOS를 사랑하는 이유
(birkey.co)- Nix 패키지 관리자를 기반으로 한 NixOS는 시스템 전체를 코드로 정의하고, 언제든 결정적·재현 가능한 상태로 복원할 수 있는 구조를 가짐
- 모든 설정과 패키지를 하나의 선언적 구성 파일로 관리해, 새 장비에서도 동일한 환경을 단일 소스에서 재구축 가능
- 6개월 주기의 안정적 릴리스와 자동 업데이트, 그리고 필요 시 unstable 채널을 통한 최신 소프트웨어 실험을 지원
- 격리된 개발 환경을 제공해 시스템 오염 없이 다양한 언어와 도구를 실험할 수 있으며, macOS·Linux 간 일관된 개발 경험 유지
- LLM 코딩 시대의 빠른 도구 교체에도 대응하며, Docker보다 결정적이고 계층화된 빌드 모델로 배포까지 일관성 확보
NixOS의 철학과 매력
-
NixOS의 핵심은 리눅스 배포판이 아니라 Nix 패키지 관리자임
- NixOS는 결정적이고 재현 가능한 함수형 패키지 관리자의 결과물로, 입력된 Nix DSL에 따라 전체 운영체제를 구성할 수 있음
- 시스템을 재구축하거나 일부만 수정하고, 마음에 들지 않으면 롤백할 수 있는 구조 제공
- 대부분의 운영체제가 시간이 지나며 불안정해지는 반면, NixOS는 상태를 정의하고 빌드할 수 있음
- 패키지 설치, 설정 변경, 도구 추가·삭제로 인한 불명확한 상태 누적을 방지
- 시스템을 코드로 정의해 언제든 동일한 결과를 재현 가능
선언적 구성과 단일 소스 관리
- NixOS에서는 패키지, 설정, 키보드 매핑 등 전체 시스템을 하나의 선언적 구성으로 정의 가능
- GNOME 확장 설정과 키보드 매핑 예시처럼 세부 동작까지 Nix DSL로 기술 가능
- 새 컴퓨터에서도 단일 소스에서 전체 시스템을 재구축 가능
- 수동 설정이나 산발적인 스크립트 관리 없이 일관된 시스템 상태 유지 가능
안정성과 업데이트 관리
- NixOS는 6개월 주기의 예측 가능한 릴리스를 유지하며 자동 업데이트를 지원
- 일반적인 OS 업그레이드 시 발생하는 불안정성이나 알림, 시스템 드리프트 문제를 최소화
- 필요 시 unstable 채널을 활성화해 최신 소프트웨어를 실험적으로 사용 가능
- HP 노트북에서도 하드웨어 호환성과 안정성이 높아 별도 설정 없이 즉시 사용 가능
실험과 개발 환경의 격리
- NixOS는 안전하고 저비용의 실험 환경을 제공
- 패키지를 시스템에 직접 설치하지 않고 격리된 shell 환경에서 실행 가능
- Nix DSL로 의존성, 빌드 단계, 결과물을 선언적으로 정의해 오염 없는 개발 환경 유지
- macOS와 Linux 모두에서 동일한 Nix 패키지 관리자를 사용할 수 있어 개발 도구와 의존성 관리의 일관성 확보
- FreeBSD용 커뮤니티 지원도 존재
LLM 코딩 시대와의 궁합
- LLM 기반 코딩 도구는 특정 버전의 유틸리티, 컴파일러, 런타임을 자주 교체해야 함
- Nix는 이러한 요구에 맞게 도구를 선언적 입력으로 취급하고, 격리된 환경에서 실행
- 예를 들어 Rust 음성-텍스트 에이전트를 빌드할 때 Nix가 Rust 툴체인을 자동으로 불러와 격리된 빌드 환경을 구성
- 시스템 환경(
~/.cargo,~/.rustup, PATH 등)을 변경하지 않음
-
flake.nix와nix flake check를 통해 에이전트의 실험 환경을 재현 가능한 아티팩트로 고정 가능- 임시 세션을 검증 가능한 빌드 단위로 전환
배포와 일관된 개발 모델
- Nix는 Docker보다 결정적이고 계층화된 이미지 빌드 방식을 제공
-
dockerTools.buildLayeredImage를 사용해 작고 재현 가능한 Docker 이미지 생성 가능 - 동일한 설정으로 다른 아키텍처에서도 동일한 결과를 빌드 가능
-
- 동일한 모델이 노트북, 셸, 프로젝트 의존성, CI 파이프라인, 배포 아티팩트까지 일관되게 적용됨
- 여러 도구를 조합하는 대신 하나의 사고방식으로 전체 소프트웨어 시스템을 관리 가능
결론
- NixOS는 선언적, 재현 가능, 되돌릴 수 있고 안정적인 시스템의 구현체
- 실험과 업그레이드를 두려움 없이 수행할 수 있으며 빠르게 변화하는 도구 환경에서도 시스템을 오염시키지 않음
- LLM 코딩 에이전트와 같은 최신 개발 흐름에서도 안정성과 유연성을 동시에 제공
- NixOS는 이러한 철학을 가장 완전하게 일상에서 구현한 형태임
Hacker News 의견들
-
나는 NixOS가 AI 도구와의 궁합 면에서 독보적이라고 생각함
다른 OS에서는 AI에게 시스템 설정을 맡기기 어렵지만, NixOS는 선언적이고 롤백 가능한 구조 덕분에 신뢰할 수 있음
Pulseaudio에서 Pipewire로 전환하거나 Hyprland를 설치하는 일을 Claude나 Codex에게 맡기진 않겠지만, NixOS라면 Grok에게도 맡길 수 있을 정도로 자신 있음
변경사항을 사전에 검토하고 언제든 되돌릴 수 있는 안정성이 핵심임
개발자라면 “AI가 관리하는 리눅스 데스크탑”을 꿈꾸며 NixOS를 시도해보길 권함. Claude에게 “Flake 기반 Gnome 설정을 VM에서 시연할 수 있게 만들어줘”라고 말하는 것부터 시작하면 됨- 3년째 NixOS를, 1년 넘게 Claude를 쓰고 있음. 둘의 조합은 정말 이상적임
Claude가 GNOME의 dconf 설정을 선언적으로 조정하는 걸 보면 놀라움
다만 AI가 Nix 생태계의 복잡한 맥락을 이해하지 못해 종종 엉뚱한 결과를 내기도 함
Nix의 비정형 람다 구조와 모듈 간 암묵적 스코프 때문에 사람뿐 아니라 AI에게도 어렵다는 점을 느낌
그래서 프로젝트의 구조와 패턴을 명확히 정의해주는 게 중요함. 그럼에도 불구하고 Nix 기반 템플릿을 만드는 과정은 즐겁고 생산적임 - 솔직히 말해, 이건 존재하지 않는 문제를 위한 과도한 기술적 해결책처럼 보임
Hyprland 설치에 굳이 LLM을 쓸 필요가 있을까? 단순히sudo dnf install hyprland면 충분함
Nix가 ‘AI 친화적’이라기보다, 사람이 직접 다루기 번거로워서 LLM을 쓰게 되는 것 같음 - 나도 비슷한 경험을 했음. 예전에 “ClaudeOS”라는 이름으로 HN에 글을 올렸는데, 사실 그건 NixOS + Flakes + Claude Code 조합이었음
여러 머신의 설정을 ‘비즈니스 프로필’로 관리하고, 각 머신에 필요한 repo와 설정을 자동으로 배포함
회사 동료는 원래 Windows 사용자였는데, 지금은 NixOS를 일상적으로 쓰고 있음
모든 하드웨어 설정도 선언적으로 관리 중이며, 내 설정은 GitHub 공개 저장소에 있음. 피드백 환영임 - 나도 Claude에게 NixOS 설정 문제를 해결하게 시켜봤는데, 정말 잘 작동했음
새로운 구조로 설정을 옮기거나 여러 WM/DE 테스트 환경을 만들 때도 Claude가 대부분의 반복 작업을 처리함
지금은 시스템이 완전히 안정돼서 수동으로 할 일이 거의 없음
다른 OS에서는 이런 신뢰를 갖기 어려움 - 예전엔 Nix가 너무 난해해 보여서 AI가 발전할 때까지 기다렸음
대신 Docker 스크립트로 개발 환경을 관리했는데, 이제는 Nix와 AI의 궁합이 완벽하다고 느낌
앞으로 AI가 더 쉽게 다룰 수 있는 소프트웨어들이 많이 나올 것 같음
- 3년째 NixOS를, 1년 넘게 Claude를 쓰고 있음. 둘의 조합은 정말 이상적임
-
30년간 Windows를 쓰다가 1년 전 Nix로 완전히 전환했음
이제는 다시 Windows로 돌아갈 생각이 전혀 없음
전체 OS 설정이 Git 리포지토리에 들어있다는 점이 너무 마음에 듦
Nix 없이 개발하는 건 Git 없이 코딩하는 것만큼이나 비효율적임
한 번 설정해두면 이후 새 시스템 세팅이 매우 간단함- 내 NixOS 설정을 기반으로 격리된 컨테이너를 쉽게 만들 수 있는 프로젝트가 있는지 궁금함
각 앱을 독립된 환경에서 실행해도 시스템 전체에는 영향을 주지 않게 하고 싶음
NixOS가 이런 미래로 가는 길 중 하나라고 생각함 - 한때 Fedora Bazzite로 돌아가려 했지만, Sway에서 HDR을 더 안정적으로 구현할 수 있어서 NixOS에 남았음
Nvidia GPU도 잘 작동하고, Gamescope보다 훨씬 안정적임 - Python 스크립트를 빠르게 실행할 때 nix-shell을 어떻게 활용하는지 예시를 보고 싶음. 아직 Python과 NixOS의 상호작용을 배우는 중임
- 내 NixOS 설정을 기반으로 격리된 컨테이너를 쉽게 만들 수 있는 프로젝트가 있는지 궁금함
-
NixOS를 더 좋아하고 싶지만, 문서화 부족이 가장 큰 문제임
정보가 여러 포럼과 오래된 블로그, 이슈에 흩어져 있음- 게다가 공식 위키가 두 개(nixos.wiki, wiki.nixos.org)라 혼란스러움
둘 다 업데이트되지만 어떤 게 최신인지 검색할 때마다 달라짐 - 나도 예전엔 문서 부족에 불평했지만, 지금은 소스 코드 자체가 문서라고 생각함
nixpkgs를 클론해서 직접 읽는 게 가장 빠름 - ChatGPT가 여러 자료를 모아 작동하는 코드 예시를 만들어주는 데 꽤 유용함
- 사실 많은 사용자가 문서를 읽지 않고, Claude Code에게 Nix 코드를 작성하게 맡김
- 게다가 공식 위키가 두 개(nixos.wiki, wiki.nixos.org)라 혼란스러움
-
NixOS를 노트북용 OS로 써봤는데, 장단이 뚜렷했음
선언적 설정과 스냅샷 기능은 혁신적이지만, 패키지/서비스 구분과 Flake 개념이 혼란스러웠음
KDE 설치 시 최소 구성만 설치돼 추가 설정이 필요했고, 문서도 버전마다 달라서 따라가기 힘들었음
결국 안정적인 머신이 필요해 포기했지만, 시스템 관리자에게는 훌륭한 선택일 듯함- 나도 처음엔 Flake가 어렵게 느껴졌지만, 실제로는 가장 직관적인 방식임
Determinate Systems 설치기가 기본으로 Flake를 활성화함
/etc/nixos설정을 Git 리포지토리로 옮길 수 있고,nixos-install --flake <repo>명령으로 완전한 설정 배포가 가능함
Home-manager를 함께 쓰면 사용자 디렉토리까지 선언적으로 관리 가능함
/etc파일은environment.etc로,.config파일은 home-manager 옵션으로 관리할 수 있음
관련 링크: environment.etc 옵션, home-manager 옵션 -
mkOutOfStoreSymlink관련 문서를 찾다가 “간단하니 문서가 필요 없다”는 답변을 보고 웃었음
그럼에도 불구하고 NixOS의 장점이 너무 커서 홈랩 → 노트북 → 데스크탑 순으로 완전히 이전 중임
다만 문서 상황은 여전히 절망적임 - Flake는 두 가지 역할을 함:
- 코드베이스의 입력과 출력을 선언
- 입력 소스 버전을 고정(pinning)
즉, package.json과 lock 파일의 역할을 Nix 수준에서 수행함
- 왜 아직 아무도 LLM을 이용해 문서를 개선하지 않았는지 의아함
- 나도 처음엔 Flake가 어렵게 느껴졌지만, 실제로는 가장 직관적인 방식임
-
예전부터 NixOS를 좋아했는데, LLM 시대 이후엔 더 좋아짐
Codex에게 “이 서버 설정을 수정해서 와일드카드 인증서가 작동하게 해줘”라고 하면 5분 만에 해결됨
재현 가능한 서버 관리가 이렇게 쉬워진 건 처음임 -
NixOS로 전환한 뒤, apt나 brew로 관리하던 시절이 석기시대 기술처럼 느껴짐
Copilot 같은 AI 도구와의 궁합도 훌륭함- NixOS는 95%는 훌륭하지만, 5%는 매우 고통스러움
문제를 해결하려면 일반 리눅스보다 더 깊은 이해가 필요함
대신 복잡성을 초기에 한 번에 치르는 구조임 - 20년간 여러 리눅스를 써봤지만, NixOS는 처음으로 “이게 정답”이라는 느낌을 줌
nix-shell로 임시 설치를 하거나, 설정 파일 하나로 설치된 모든 패키지를 확인할 수 있는 점이 최고임
자동 스냅샷 덕분에 실험이 두렵지 않음. 잘못되면 이전 세대로 부팅하면 끝임
예전엔 커널 파라미터 수정이 무서웠지만, 이제는 마음껏 시도할 수 있음
Lisp를 좋아해서 Guix System도 고려했지만, 실사용성 면에서는 NixOS가 더 나음
- NixOS는 95%는 훌륭하지만, 5%는 매우 고통스러움
-
NixOS의 특이한 파일시스템 구조만 없었으면 좋겠음
여러 버전의 Python을 동시에 쓰는 문제를 해결하려는 접근이지만, 내겐 불필요함
단순히 모든 머신에서 동일한 설정을 유지하고 싶을 뿐임
현재는 Fedora bootc 이미지와 Podman을 실험 중인데,nixos-rebuild switch같은 즉시 반영 기능이 없어 불편함
결국 쉽게 실험 가능한 Nix와 표준 파일시스템의 Fedora 사이의 트레이드오프임 -
NixOS의 가장 큰 장점은 CI 캐시의 결정적 재현성임
패키지를 매번 다시 빌드할 필요가 없고, 개발 환경 설정도 간단함- Nix를 CI에 쓰는 건 정말 잘 맞는 조합임
예를 들어 Tangled는 CI 시스템 전체를 Nix로 구축했는데, GitHub Actions의 캐싱 문제를 완전히 해결했음
- Nix를 CI에 쓰는 건 정말 잘 맞는 조합임
-
시스템 전체는 아니지만, devenv.sh를 즐겨 씀
로컬 컨테이너보다 훨씬 간단하게 개발 환경을 구성할 수 있음- 다만 버전 고정(pinning) 방식이 명확하지 않음
asdf의.tool-versions처럼 간단히 버전을 맞추는 방법이 없어 아쉬움
Nix 진영에서는 “그건 잘못된 접근”이라 하지만, 나는 여전히 개별 버전을 고정하고 싶음 - home-manager와의 차이가 궁금함
- 단순한
pkgs.mkShell로도 비슷한 환경을 만들 수 있는데, 굳이 devenv를 써야 하는 이유가 궁금함
- 다만 버전 고정(pinning) 방식이 명확하지 않음
-
나는 NixOS도 좋지만, Guix를 더 선호함
Guile 언어가 더 익숙하고, 문서도 더 잘 되어 있음. 두 시스템은 자매 관계라고 생각함- Guix가 더 많은 사랑을 받아야 한다고 생각함
실제 프로그래밍 언어(Scheme) 를 사용하는 점이 큰 장점임
단순한 설정 언어보다 훨씬 강력한 기반을 가짐
- Guix가 더 많은 사랑을 받아야 한다고 생각함