# NixOS를 사랑하는 이유

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27784](https://news.hada.io/topic?id=27784)
- GeekNews Markdown: [https://news.hada.io/topic/27784.md](https://news.hada.io/topic/27784.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-23T23:33:53+09:00
- Updated: 2026-03-23T23:33:53+09:00
- Original source: [birkey.co](https://www.birkey.co/2026-03-22-why-i-love-nixos.html)
- Points: 12
- Comments: 8

## Summary

시스템을 코드처럼 다루는 **NixOS**는 개발 환경을 완전히 **결정적이고 재현 가능한 상태**로 관리할 수 있게 합니다. 모든 설정과 패키지를 하나의 선언적 구성으로 정의해 새 장비에서도 동일한 환경을 즉시 복원할 수 있으며, 실험용 shell을 통해 시스템 오염 없이 도구를 교체하거나 테스트할 수 있습니다. 특히 LLM 코딩 시대처럼 빠르게 변하는 툴체인에서도, Nix의 **격리된 빌드 모델**은 Docker보다 일관된 배포와 안정성을 제공합니다.

## Topic Body

- **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는 이러한 철학을 **가장 완전하게 일상에서 구현한 형태**임

## Comments



### Comment 53732

- Author: dongho42
- Created: 2026-03-24T22:18:31+09:00
- Points: 1

저도 옛날에 반년남짓 NixOS 쓰다가 다른 OS에서는 따로 찾아볼것도 없는 아주 간단한 작업을 아무리 구글링해도 해결하지못해 NixOS 포럼 같은곳에서 어떤 NixOS 전문가?분이 기록해두신 솔루션을 봤는데 그 수십줄짜리 hacky한 솔루션이 제일 따봉많이 받은걸 보고 앞으로의 NixOS생활이 캄캄하게 느껴져서 아치로 돌아갔었어요...

### Comment 53733

- Author: dongho42
- Created: 2026-03-24T22:23:27+09:00
- Points: 1
- Parent comment: 53732
- Depth: 1

그리고 잘은 기억 안나는데 flake엿나 무슨 기능이 어디는 best practice 라 하고 어디는 experimental이라 하고 어디는 둘다라 하고 그런게 수년째 지속되고 있는걸보고 고생길이 훤하더라구요..  
  
물론 전체 데스크탑 환경을 쉽게 코드화 할수있는경험은 즐거웠습니다

### Comment 53722

- Author: pmc7777
- Created: 2026-03-24T19:47:11+09:00
- Points: 1

Firebase Studio도 Nix를 사용합니다

### Comment 53726

- Author: laeyoung
- Created: 2026-03-24T21:36:28+09:00
- Points: 1
- Parent comment: 53722
- Depth: 1

오...그렇군요!  
  
그나저나 R.I.P. Firebase Studio ㅠㅠ

### Comment 53714

- Author: grenade
- Created: 2026-03-24T15:44:48+09:00
- Points: 1

너무 어려워요 좀 시도해보다가 포기 ㅠㅠ  
(I use Arch btw)

### Comment 53704

- Author: ztaka
- Created: 2026-03-24T12:57:41+09:00
- Points: 1

아는 사람은 알음알음 쓰고있죠 ㅋㅋㅋ  
선언적 함수형 언어로 구현하는 재현가능한 셋업

### Comment 53697

- Author: ytuniverse
- Created: 2026-03-24T10:37:48+09:00
- Points: 1

러닝커브가 말도 안됩니다. 재현성 보장하는 만큼 높은 수준을 요구해요.  
flake 쓰더라도 까다롭습니다.  
  
또 내부적으로 sqlite를 쓰는 것 같은데, 이게 또 성능이 오락가락해서 한번 환경 다시 재현하는데 걸리는 시간의 fluctuation이 좀 있습니다.

### Comment 53670

- Author: neo
- Created: 2026-03-23T23:33:53+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47479751) 
- 나는 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 공개 저장소](https://github.com/jacopone/nixos-config)에 있음. 피드백 환영임
  - 나도 Claude에게 NixOS 설정 문제를 해결하게 시켜봤는데, 정말 잘 작동했음  
    새로운 구조로 설정을 옮기거나 여러 **WM/DE 테스트 환경**을 만들 때도 Claude가 대부분의 반복 작업을 처리함  
    지금은 시스템이 완전히 안정돼서 수동으로 할 일이 거의 없음  
    다른 OS에서는 이런 신뢰를 갖기 어려움
  - 예전엔 Nix가 너무 난해해 보여서 AI가 발전할 때까지 기다렸음  
    대신 Docker 스크립트로 개발 환경을 관리했는데, 이제는 **Nix와 AI의 궁합**이 완벽하다고 느낌  
    앞으로 AI가 더 쉽게 다룰 수 있는 소프트웨어들이 많이 나올 것 같음

- 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.wiki, wiki.nixos.org)라 혼란스러움  
    둘 다 업데이트되지만 어떤 게 최신인지 검색할 때마다 달라짐
  - 나도 예전엔 문서 부족에 불평했지만, 지금은 **소스 코드 자체가 문서**라고 생각함  
    nixpkgs를 클론해서 직접 읽는 게 가장 빠름
  - ChatGPT가 여러 자료를 모아 **작동하는 코드 예시**를 만들어주는 데 꽤 유용함  
  - 사실 많은 사용자가 문서를 읽지 않고, **Claude Code**에게 Nix 코드를 작성하게 맡김

- 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 옵션](https://search.nixos.org/options?channel=unstable&query=envi...), [home-manager 옵션](https://home-manager-options.extranix.com/?query=xdg.configF...)
  - `mkOutOfStoreSymlink` 관련 문서를 찾다가 “간단하니 문서가 필요 없다”는 답변을 보고 웃었음  
    그럼에도 불구하고 NixOS의 장점이 너무 커서 **홈랩 → 노트북 → 데스크탑** 순으로 완전히 이전 중임  
    다만 문서 상황은 여전히 절망적임
  - Flake는 두 가지 역할을 함:  
    1) 코드베이스의 입력과 출력을 선언  
    2) 입력 소스 버전을 **고정(pinning)**  
    즉, package.json과 lock 파일의 역할을 Nix 수준에서 수행함  
  - 왜 아직 아무도 LLM을 이용해 문서를 개선하지 않았는지 의아함

- 예전부터 NixOS를 좋아했는데, LLM 시대 이후엔 더 좋아짐  
  Codex에게 “이 서버 설정을 수정해서 와일드카드 인증서가 작동하게 해줘”라고 하면 5분 만에 해결됨  
  **재현 가능한 서버 관리**가 이렇게 쉬워진 건 처음임

- NixOS로 전환한 뒤, apt나 brew로 관리하던 시절이 **석기시대 기술**처럼 느껴짐  
  Copilot 같은 AI 도구와의 궁합도 훌륭함
  - NixOS는 95%는 훌륭하지만, 5%는 매우 고통스러움  
    문제를 해결하려면 일반 리눅스보다 더 깊은 이해가 필요함  
    대신 복잡성을 **초기에 한 번에** 치르는 구조임
  - 20년간 여러 리눅스를 써봤지만, NixOS는 처음으로 “이게 정답”이라는 느낌을 줌  
    nix-shell로 임시 설치를 하거나, 설정 파일 하나로 설치된 모든 패키지를 확인할 수 있는 점이 최고임  
    **자동 스냅샷** 덕분에 실험이 두렵지 않음. 잘못되면 이전 세대로 부팅하면 끝임  
    예전엔 커널 파라미터 수정이 무서웠지만, 이제는 마음껏 시도할 수 있음  
    Lisp를 좋아해서 Guix System도 고려했지만, 실사용성 면에서는 NixOS가 더 나음

- NixOS의 **특이한 파일시스템 구조**만 없었으면 좋겠음  
  여러 버전의 Python을 동시에 쓰는 문제를 해결하려는 접근이지만, 내겐 불필요함  
  단순히 모든 머신에서 동일한 설정을 유지하고 싶을 뿐임  
  현재는 Fedora bootc 이미지와 Podman을 실험 중인데, `nixos-rebuild switch` 같은 즉시 반영 기능이 없어 불편함  
  결국 **쉽게 실험 가능한 Nix**와 **표준 파일시스템의 Fedora** 사이의 트레이드오프임

- NixOS의 가장 큰 장점은 **CI 캐시의 결정적 재현성**임  
  패키지를 매번 다시 빌드할 필요가 없고, 개발 환경 설정도 간단함
  - Nix를 CI에 쓰는 건 정말 잘 맞는 조합임  
    예를 들어 Tangled는 CI 시스템 전체를 Nix로 구축했는데, GitHub Actions의 캐싱 문제를 완전히 해결했음

- 시스템 전체는 아니지만, [devenv.sh](https://devenv.sh/)를 즐겨 씀  
  로컬 컨테이너보다 훨씬 간단하게 개발 환경을 구성할 수 있음
  - 다만 **버전 고정(pinning)** 방식이 명확하지 않음  
    asdf의 `.tool-versions`처럼 간단히 버전을 맞추는 방법이 없어 아쉬움  
    Nix 진영에서는 “그건 잘못된 접근”이라 하지만, 나는 여전히 개별 버전을 고정하고 싶음
  - home-manager와의 차이가 궁금함  
  - 단순한 `pkgs.mkShell`로도 비슷한 환경을 만들 수 있는데, 굳이 devenv를 써야 하는 이유가 궁금함

- 나는 NixOS도 좋지만, **Guix**를 더 선호함  
  Guile 언어가 더 익숙하고, 문서도 더 잘 되어 있음. 두 시스템은 자매 관계라고 생각함
  - Guix가 더 많은 사랑을 받아야 한다고 생각함  
    **실제 프로그래밍 언어(Scheme)** 를 사용하는 점이 큰 장점임  
    단순한 설정 언어보다 훨씬 강력한 기반을 가짐