GNU Guix로 전환하기: 초보자의 시각

10년 넘게 사용한 Arch Linux 홈 서버를 GNU Guix로 전환해, 여러 파일과 패키지 관리 이력에 흩어진 시스템 상태를 Git 기반 선언적 구성으로 관리함 NixOS도 시험했지만 문서 분산과 실험적 기능에서 불편을 겪었고, 구성 언어부터 서비스 관리자까지 Guile Scheme으로 통일된 Guix를 선택함 Guix System과 Guix Home을 하나의 Org-mode 파일로 관리하며, 서비스와 주변 인프라 설정, 예약 작업의 스크립트와 의존성을 함께 정의함 guix shell 로 일회성 도구의 임시 환경을 만들고, 컨테이너 모드에서 공유 디렉터리와 네트워크 접근을 지정해 AI 코딩 에이전트를 격리함 작은 패키지 생태계와 로컬 빌드 대기가 주요 제약이며, 이전 커밋 고정, 직접 패키지 정의, 언어 생태계 도구 실행, 지원되는 대체 소프트웨어로 대응함 Arch Linux 홈 서버에서 선언적 운영체제로 Arch Linux는 롤링 릴리스, 최소 기본 구성, ArchWiki 덕분에 10년 넘게 사용한 배포판이었음 주력 Linux 장비는 Home Assistant, 로컬 DNS, 백그라운드 작업, 개발용 샌드박스를 운영하는 24시간 가동 홈 서버로, 장기 안정성과 유지보수성이 중요했음 수년에 걸친 수정으로 시스템 상태가 /etc, /usr, systemd 서비스 유닛, 패키지 관리자 작업 이력에 흩어짐 변경할 때마다 어떤 파일을 언제, 왜 수정했는지 꼼꼼히 기록해야 했음 이전 Caddy 관련 글에서 다룬 Arch Linux AUR 보안 사고와 Omarchy 관련 동향을 계기로 구성을 재검토함 목표는 선언적이고 재현 가능하며, 전부 코드로 관리할 수 있는 운영체제였음 NixOS 시험과 GNU Guix 선택 첫 후보였던 NixOS를 가상 머신에 설치해 Arch에서 운영하던 핵심 서비스를 재현했으며, 구성 파일로 전체 시스템 상태를 선언하고 즉시 롤백하는 방식은 잘 작동했음 다만 문서의 일관성이 걸림돌이 됨 새로운 nix CLI와 Flakes는 여전히 실험적 기능이며, 기본 활성화되거나 생태계 전체에서 표준화되지 않아 문서와 튜토리얼이 갈림 위키도 두 개로 나뉘어 있어 안내를 찾기 어려웠음 System Crafters의 David Wilson이 만든 Why I Choose Guix Over NixOS와 YouTux의 One of the Best Linux Distros Isn’t Even in DistroWatc...