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

NixOS는 다른 리눅스 배포판과 근본적으로 접근 방식이 다릅니다. 대부분의 배포판은 명령어를 하나씩 실행하며 시스템을 “명령형(imperative)“으로 구성하지만, NixOS는 하나의 설정 파일에 원하는 시스템 상태를 “선언(declare)“하면 그 상태를 그대로 만들어주는 “선언형(declarative)” 방식을 취합니다.

명령형과 선언형의 차이

일반적인 배포판에서 웹 서버를 설정한다고 하면 이런 순서를 거칩니다.

1. apt install nginx로 패키지 설치
2. 설정 파일을 직접 편집
3. 서비스 활성화 및 시작

문제는 이 과정을 반복하면서 시스템이 “지금까지 실행한 명령어의 누적 결과”가 되어버린다는 점입니다. 같은 결과를 다른 컴퓨터에서 재현하려면 실행했던 모든 명령을 정확히 기억하고 순서대로 다시 실행해야 합니다.

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)로 즉시 부팅할 수 있습니다.
• 완벽한 재현성: 같은 configuration.nix 파일이라면 어떤 컴퓨터에서 빌드하든 동일한 결과가 나오는 것을 목표로 설계되었습니다.

개발 환경에서의 활용: nix-shell

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

진입 장벽: Nix 언어

NixOS를 배우는 데 가장 큰 장벽은 Nix라는 함수형 설정 언어 자체입니다. 일반적인 셸 스크립트나 YAML과는 문법이 많이 달라서, 처음에는 간단한 설정을 작성하는 데도 시간이 꽤 걸립니다. 하지만 공식 매뉴얼과 커뮤니티가 만든 학습 자료(Nix Pills 등)가 잘 정리되어 있어서, 시간을 투자할 의지만 있다면 충분히 극복 가능한 수준입니다.

어떤 사람에게 어울릴까

• 여러 프로젝트의 개발 환경을 완벽하게 격리하고 싶은 개발자
• 시스템 설정을 텍스트 파일로 관리하고 버전 관리 시스템(Git)에 올려 팀과 공유하고 싶은 경우
• 여러 대의 서버나 컴퓨터에 동일한 환경을 정확히 재현해야 하는 인프라 엔지니어

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