NixOS를 사랑하는 이유 — 선언적 시스템 관리의 매력과 현실

운영체제를 코드로 정의한다는 것

서버를 세팅하거나 개발 환경을 구축할 때, 필요한 패키지를 하나씩 설치하고, 설정 파일을 수정하고, 환경 변수를 세팅하는 과정을 거칩니다. 문제는 이 과정이 어디에도 기록되지 않는다는 것입니다. 시간이 지나면 "이 서버에 왜 이 패키지가 설치되어 있지?", "이 설정은 누가 언제 바꾼 거지?"라는 의문이 생기고, 같은 환경을 다른 머신에 재현하는 것은 거의 불가능에 가까워집니다.

NixOS는 이 문제를 근본적으로 해결합니다. 운영체제 전체를 하나의 설정 파일(configuration.nix)로 선언적으로 정의하는 것입니다. 어떤 패키지가 설치되어야 하는지, 어떤 서비스가 실행되어야 하는지, 방화벽 규칙은 어떠한지 등 시스템의 모든 상태를 코드로 기술합니다. 그리고 nixos-rebuild switch 한 번으로 시스템을 그 상태로 만듭니다.

최근 한 개발자가 NixOS를 사랑하게 된 이유를 상세히 다룬 글을 발표했는데, 그 내용을 중심으로 NixOS의 매력과 현실적 고려사항을 살펴보겠습니다.

NixOS의 핵심 철학

NixOS를 이해하려면 그 기반인 Nix 패키지 매니저의 핵심 개념을 알아야 합니다.

순수 함수적 패키지 관리: Nix에서 각 패키지는 입력(소스 코드, 의존성, 빌드 스크립트)의 해시로 식별되는 고유한 경로에 설치됩니다. 예를 들어 /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-131.0처럼요. 이 해시는 패키지의 모든 입력에서 계산되기 때문에, 버전이 다르거나 빌드 옵션이 다른 같은 패키지가 충돌 없이 공존할 수 있습니다. Python 2와 Python 3을 동시에 설치해도, 서로 다른 버전의 OpenSSL에 의존하는 두 앱을 동시에 실행해도 문제가 없습니다.

원자적 업그레이드와 롤백: 시스템 업데이트는 원자적(atomic)으로 이루어집니다. 업데이트 중간에 전원이 나가도 시스템이 불완전한 상태에 빠지지 않습니다. 그리고 모든 이전 세대(generation)가 보존되어 있어, 업데이트 후 문제가 생기면 부팅 시 이전 세대를 선택하여 즉시 롤백할 수 있습니다. 이것은 실무에서 엄청난 안정감을 줍니다. "이 업데이트 때문에 시스템이 망가지면 어떡하지"라는 걱정을 하지 않아도 되니까요.

재현 가능한 빌드: 같은 Nix 표현식은 어디서 빌드하든 동일한 결과를 보장합니다(결정론적 빌드). 이것은 "내 컴퓨터에서는 되는데"를 근본적으로 없애줍니다. 팀원 모두가 동일한 flake.nix 파일을 공유하면, 모든 사람의 개발 환경이 정확히 동일하게 구성됩니다.

실제 사용 경험에서 빛나는 순간들

글의 저자가 특히 강조하는 사용 사례들이 있습니다.

개발 환경 관리: 프로젝트마다 다른 언어 버전, 다른 도구 세트가 필요한 상황은 개발자라면 모두 경험합니다. Nix의 nix develop (또는 direnv와의 통합)을 사용하면, 프로젝트 디렉토리에 진입할 때 자동으로 해당 프로젝트에 필요한 모든 도구가 PATH에 추가됩니다. Node.js 18이 필요한 프로젝트와 Node.js 20이 필요한 프로젝트를 오가는 것이 완전히 자연스러워집니다. nvm이나 pyenv 같은 버전 매니저가 필요 없어지는 것입니다.

서버 관리: NixOS의 설정 파일을 Git으로 관리하면, 서버의 전체 상태가 버전 관리됩니다. 새 서버를 세팅하는 것은 configuration.nix를 복사하고 nixos-rebuild switch를 실행하는 것으로 끝납니다. Ansible이나 Chef 같은 구성 관리 도구의 역할을 NixOS 자체가 수행하는 셈입니다. 구성 관리 도구와의 가장 큰 차이는, Ansible은 "이 명령을 실행하라"는 절차적 접근인 반면 NixOS는 "이 상태가 되어라"는 선언적 접근이라는 점입니다.

임시 환경: nix-shell -p python3 ffmpeg imagemagick처럼, 영구적으로 설치하지 않고 일시적으로 패키지를 사용할 수 있습니다. 작업이 끝나고 셸을 나가면 해당 패키지들은 PATH에서 사라집니다. 시스템을 깨끗하게 유지하면서도 필요한 도구를 즉시 사용할 수 있는 것입니다.

NixOS의 현실적 어려움

공정하게 말하면, NixOS에는 분명한 단점도 있습니다.

가파른 학습 곡선: Nix 언어는 함수형 프로그래밍 패러다임을 따르는 독자적인 언어입니다. Lazy evaluation, 재귀적 attribute set 등의 개념이 처음에는 낯설 수 있습니다. 에러 메시지가 친절하지 않기로 유명하고, 공식 문서도 개선의 여지가 많다는 것이 커뮤니티의 공통된 의견입니다.

서드파티 소프트웨어 호환성: FHS(Filesystem Hierarchy Standard)를 따르지 않기 때문에, /usr/lib나 /usr/bin에 바이너리가 있을 것을 가정하는 소프트웨어가 그대로 동작하지 않는 경우가 있습니다. 특히 상용 소프트웨어나 사전 컴파일된 바이너리를 사용할 때 추가 작업이 필요할 수 있습니다.

커뮤니티 분열: Nix 커뮤니티 내에서 거버넌스와 기술적 방향성을 둘러싼 논쟁이 있었고, Lix라는 포크가 등장하기도 했습니다. 이런 커뮤니티 이슈는 장기적인 생태계 안정성에 대한 우려를 낳기도 합니다.

경쟁 기술과의 비교

NixOS와 유사한 문제를 풀려는 기술들이 있습니다. GNU Guix는 Nix에서 영감을 받아 Guile Scheme을 설정 언어로 사용하는 시스템입니다. Docker/컨테이너는 환경 재현성 문제를 다른 방향에서 해결하지만, 호스트 OS 자체를 관리하지는 않습니다. Ansible/Terraform은 인프라를 코드로 관리하지만, 패키지 수준의 결정론적 빌드를 보장하지는 않습니다.

NixOS의 고유한 강점은 패키지 관리부터 시스템 구성까지 하나의 일관된 모델로 다룬다는 점입니다.

한국 개발자에게 주는 시사점

한국에서 NixOS를 메인 운영체제로 사용하는 개발자는 아직 소수이지만, Nix 패키지 매니저만 단독으로 사용하는 것은 macOS나 기존 Linux에서도 가능합니다. 팀 프로젝트에서 "환경 세팅하는 데 반나절 걸렸다"는 경험이 있다면, flake.nix로 개발 환경을 정의하는 것을 시도해볼 가치가 있습니다. 특히 온보딩 프로세스가 복잡한 팀에서는 효과가 클 수 있습니다.

또한 Nix의 개념은 DevOps와 IaC(Infrastructure as Code) 트렌드의 연장선에 있으므로, 직접 사용하지 않더라도 선언적 시스템 관리의 사고방식을 익히는 것은 인프라 엔지니어링 역량을 키우는 데 도움이 됩니다.

마무리

NixOS는 "시스템을 코드로 정의한다"는 아이디어를 가장 극단적으로 실현한 운영체제입니다. 학습 비용이 높지만, 그 투자를 넘어서면 다른 시스템으로 돌아가기 어렵다는 것이 사용자들의 공통된 증언입니다. 여러분의 개발 환경 관리에서 가장 고통스러운 부분은 무엇인가요? NixOS가 그 문제를 해결할 수 있을지 한번 생각해보시면 좋겠습니다.