NixOS를 쓰면서 새로운 서비스를 덜 망설이게 됐습니다

AI 요약

글쓴이는 휴대전화에서만 관리하던 RSS 피드를 서버에서 운영하려고 FreshRSS를 설치했습니다. 피드가 많아지자 기기 변경 때 읽음 상태를 잃었고, 큰 화면에서 읽고 싶다는 필요도 있었습니다. 서버형 피드 리더를 원했지만 새 서비스의 배포와 유지보수까지 맡아야 한다는 생각에 미뤄 왔습니다.

NixOS 설정으로 줄어든 배포 부담

NixOS를 쓰면서 FreshRSS와 백업 설정을 9줄의 Nix 코드로 작성했습니다. nginx 리버스 프록시 설정에는 12줄가량이 더 들었습니다. 특정 location에서 프록시하려고 쿠키 경로를 다시 써야 했지만, 글쓴이는 이를 NixOS 자체의 문제와 구분합니다. 설치한 서비스는 몇 달 동안 별도 손질 없이 작동했고, 서버가 고장 나도 같은 설정으로 새 서버를 약 15분 만에 세울 수 있다고 봅니다.

NixOS를 쓰지 않으면 압축 파일을 풀고 권한을 맞춘 뒤 nginx와 php-fpm, 필요한 의존성을 설치해야 합니다. php-fpm 풀과 nginx 연결, Let's Encrypt 인증서, 백업도 각각 설정해야 합니다. 컨테이너 이미지를 쓰면 일부 설치 과정은 줄지만, 컨테이너 실행용 systemd 서비스와 백업, TLS 종료를 맡을 nginx 설정은 여전히 필요합니다. 나중에 다시 설치할 때 같은 이미지를 쓰려면 다운로드한 이미지의 정확한 버전도 기록해야 합니다. 같은 Dockerfile로 이미지를 다시 빌드해도 시간이 지나면 결과물이 달라질 수 있다고 설명합니다.

문서화한 절차를 실행 가능한 설정으로

글쓴이는 자신의 코드뿐 아니라 직접 호스팅하는 남의 서비스도 유지보수 부담으로 꼽습니다. 간간이 몇 분씩 손보는 일은 괜찮지만 업그레이드에 몇 시간씩 일정을 비우거나 긴급 상황에 대응해야 하는 일은 컴퓨터 작업 의욕을 꺾는다고 말합니다. CFEngine, Ansible, podman, k3s를 써 봤지만 설치와 배포 경험이 크게 나아지지는 않았습니다. 꼼꼼히 적어 둔 지침이나 SSH 명령을 실행하는 셸 스크립트가 더 나았던 경우도 있었습니다. 다만 셸 스크립트는 시간이 지나거나 다른 환경에서 실행할 때 전제가 어긋날 수 있습니다. NixOS 설정은 자신을 위한 지침처럼 읽히면서도 실행 가능하고 매번 같은 결과를 내는 점이 다릅니다.

Lobsters 반응

• @nemin — 전부 Nix로 옮기지 않아도 저장소에서 받은 소프트웨어를 설치할 때 Nix가 좋습니다. 무작위로 많은 의존성을 가져와도 주 환경을 어지럽히지 않습니다. 하지만 저는 배포판 자체는 계속 쓰다 돌아오게 됩니다. 선언형 설정이 너무 강해서인지 모르겠지만, 장기적으로 기술 부채와 문제가 생기더라도 직접 이것저것 만지는 편을 좋아합니다.
  • @quasi_qua_quasi — 패키지가 없는 소프트웨어용 패키지를 직접 정의하고 빌드 과정을 기록해 두면 좋습니다. 나중에 업데이트하거나 지울 때 어떤 빌드 의존성을 그 프로그램 때문에 설치했는지 기억하지 않아도 됩니다.
  • @nickmonad — 그런 설정을 관리하는 방법을 알려주는 자료가 있을까요? Nix와 NixOS를 시작한 지 얼마 안 됐습니다. configuration.nix 옆에 .nix 파일로 derivation을 정의하고 설정에 포함하는 방식인가요?
• @msangi — NixOS를 쓰면서 새로 시도하는 일도 덜 두려워졌습니다. git revert 후 다시 빌드하면 이전 시스템으로 돌아갈 수 있습니다. 시스템이 크게 망가져도 부팅 메뉴에서 이전 버전을 고를 수 있어 든든합니다.
  • @quasi_qua_quasi — 예전에 다른 컴퓨터의 설정을 복사하다 GUID가 맞지 않아 부팅 설정을 망친 적이 있습니다. 메뉴를 지나 부팅하지 못했지만 이전 버전으로 부팅해 실수를 고쳤습니다.
• @nelson — 작은 VM과 컨테이너를 NixOS로 옮기면서 많이 활용하고 있습니다. Claude Code는 Nix flake를 꽤 잘 만듭니다. 선언형 OS는 시스템 사양을 생성하는 LLM과 잘 맞습니다. 명령의 부수 효과를 추적할 필요 없이 테스트하고 재현할 수 있고, 필요한 패키지가 없으면 Claude가 직접 만들기도 합니다.
  • @toastal — Claude Code가 Nix flake를 잘 만든다는 데 동의하기 어렵습니다. overlay로 만들고 안정 버전에서도 쓸 수 있는 코드를 실험적인 flake 생태계에 묶는 나쁜 패턴을 자주 봅니다. overlay를 모듈에서 켜고 끄거나 시스템 코드와 결합하고 overlay를 노출하지 않는 식입니다. 자동 생성한 flake 때문에 안정 버전 Nix 시스템에서 쓸 수 없는 코드도 있습니다.
  • @phaer — flake.nix가 있는 저장소와 default.nix가 있는 저장소의 수를 비교하는 통계는 정확한 측정은 아니지만 저렴한 추정치로는 쓸 만합니다. 모델에 안정 버전 Nix를 명시하면 그에 맞는 결과를 얻을 수 있습니다. 다만 입력 고정, 가져오기, 출력 스키마를 정해야 합니다. flakes는 그런 선택을 한데 묶어 결정 수를 줄이지만, 구조 개선을 어렵게 만드는 설계상 약점도 있습니다. 중간 규모 flake가 작동하는 결과를 만드는 능력은 경험상 부정하기 어렵습니다.
  • @viccuad — 명령의 부수 효과가 없다는 약속은 저도 좋아하지만 실제로는 그렇지 않은 경우를 몇 번 봤습니다. NixOS 패키지로 서비스를 설치했다가 제거해도 systemd 유닛 등이 남았습니다.
  • @altano — 이 점을 완전히 믿을 수는 없고 매번 확인해야 합니다. 예를 들어 networking.firewall.extraCommands 규칙은 설정을 바꿔도 정리되지 않습니다. 동작을 얻으려면 사용자 정의 체인에 규칙을 넣고 재설정할 때 체인을 지워야 합니다. 남은 방화벽 규칙은 매우 위험합니다. Nix로 부수 효과를 거의 피할 수 있다는 점은 맞지만 완벽하지는 않습니다.

원문: Entropic Thoughts / 번역·요약: Trawling