NixOS 입문: 선언형 시스템 설정이란

설정 파일 딱 하나로 다른 컴퓨터에 완전히 동일한 시스템을 그대로 복제할 수 있다면 어떨까요. NixOS는 이걸 실제로 가능하게 만든 배포판이에요. 대부분의 배포판은 명령어를 하나씩 실행하며 시스템을 “명령형(imperative)“으로 구성하지만, NixOS는 하나의 설정 파일에 원하는 시스템 상태를 “선언(declare)“하면 그 상태를 그대로 만들어주는 “선언형(declarative)” 방식을 취해요. 도대체 이 선언형 시스템 설정이라는 게 실제로 어떻게 동작하는 걸까요?

명령형과 선언형은 시스템을 다루는 방식 자체가 다르다

일반적인 배포판에서 웹 서버를 설정한다고 하면 apt install nginx로 패키지를 설치하고, 설정 파일을 직접 편집하고, 서비스를 활성화하는 순서를 거쳐요. 문제는 이 과정을 반복하면서 시스템이 “지금까지 실행한 명령어의 누적 결과”가 되어버린다는 점이에요. 같은 결과를 다른 컴퓨터에서 재현하려면 실행했던 모든 명령을 정확히 기억하고 순서대로 다시 실행해야 하죠.

NixOS에서는 /etc/nixos/configuration.nix 파일에 다음과 같이 원하는 상태를 적어요.

services.nginx = {
  enable = true;
  virtualHosts."example.com" = {
    root = "/var/www/example";
  };
};

그리고 nixos-rebuild switch 명령 한 번이면, Nix가 이 설정에 필요한 모든 것(패키지 설치, 설정 파일 생성, 서비스 활성화)을 알아서 계산해 시스템에 적용해요. 이 설정 파일 하나만 있으면 다른 컴퓨터에서도 완전히 동일한 시스템을 그대로 재현할 수 있어요.

Nix 패키지 매니저의 핵심은 격리와 재현성이다

Nix 패키지 매니저는 모든 패키지를 /nix/store/해시값-패키지이름 형태의 고유한 경로에 저장해요. 여기서 해시값은 패키지의 소스, 버전, 빌드 옵션, 의존성을 모두 포함해 계산되기 때문에, 같은 소프트웨어라도 빌드 조건이 다르면 완전히 다른 경로에 별도로 저장돼요. 이 구조 덕분에 얻는 이점이 커요.

버전 충돌이 없음: 같은 패키지의 다른 버전이 동시에 시스템에 존재할 수 있어요. 프로젝트 A는 Python 3.9를, 프로젝트 B는 Python 3.12를 쓰더라도 서로 전혀 간섭하지 않아요.
안전한 롤백: 시스템을 업데이트해도 이전 설정으로 만들어진 /nix/store 경로는 그대로 남아 있어서, 문제가 생기면 이전 세대(generation)로 즉시 부팅할 수 있어요. Btrfs 스냅샷으로 롤백을 구현하는 방식과 목표는 비슷하지만, NixOS는 패키지 단위까지 훨씬 세밀하게 추적한다는 차이가 있어요.
완벽한 재현성: 같은 configuration.nix 파일이라면 어떤 컴퓨터에서 빌드하든 동일한 결과가 나오는 걸 목표로 설계되었어요.

개발 환경에서는 nix-shell로 진가를 발휘한다

NixOS의 진가는 개발 환경 구성에서 더욱 두드러져요. 프로젝트 루트에 shell.nix 파일을 만들어 필요한 도구와 라이브러리 버전을 명시해두면, nix-shell 명령 한 번으로 해당 프로젝트에 필요한 정확한 버전의 개발 환경이 그 자리에서 구성돼요. 팀원 전체가 완전히 동일한 개발 환경을 공유할 수 있다는 뜻이고, “내 컴퓨터에서는 되는데” 문제를 근본적으로 줄여줘요.

진입 장벽은 Nix 언어 자체다

NixOS를 배우는 데 가장 큰 장벽은 Nix라는 함수형 설정 언어 자체예요. 일반적인 셸 스크립트나 YAML과는 문법이 많이 달라서, 처음에는 간단한 설정을 작성하는 데도 시간이 꽤 걸려요. 하지만 공식 매뉴얼과 커뮤니티가 만든 학습 자료(Nix Pills 등)가 잘 정리되어 있어서, 시간을 투자할 의지만 있다면 충분히 극복 가능한 수준이에요. 같은 함수형 철학을 공유하면서도 설정 언어로 범용 언어인 Scheme을 쓰는 GNU Guix System과 비교해보면, Nix 전용 언어를 새로 배우는 것과 기존 범용 언어를 활용하는 것 사이의 트레이드오프가 더 뚜렷하게 보여요.

어떤 사람에게 어울릴까

개발 환경을 완벽하게 격리하고 싶은 개발자: 프로젝트마다 다른 버전의 도구를 서로 간섭 없이 동시에 쓸 수 있어요.
설정을 텍스트 파일로 관리하고 싶은 경우: Git으로 버전 관리하며 팀과 설정 자체를 공유할 수 있어요.
여러 대의 서버에 동일한 환경을 재현해야 하는 인프라 엔지니어: 설정 파일 하나로 모든 서버를 정확히 같은 상태로 맞출 수 있어요.

반대로 GUI 위주의 설정과 즉흥적인 시스템 커스터마이징을 선호한다면 NixOS의 방식이 오히려 불편하게 느껴질 수 있어요. 이 점에서는 GUI 통합 관리 도구를 앞세운 openSUSE Leap 같은 배포판이 더 편하게 느껴질 수도 있고요. 하지만 “시스템 상태를 코드로 관리한다”는 개념 자체는, 한 번 익히고 나면 다른 배포판으로 돌아가더라도 인프라를 대하는 사고방식에 오래 남는 경험이 될 거예요.