NixOS를 더 이상 사용하지 않는 이유들

2025-09-20

거의 1년 동안 NixOS를 시험해보면서, 사용하는 기기들의 설정값들을 한 레포지토리에 적어두었습니다. NixOS를 돌리는 모든 기기들에 프로그램을 새로 설치할 때마다, 설정값을 바꿀 때마다, 커밋으로 작성하여 레포지토리에 올려두었죠.

거의 1년 간 사용을 마무리지으며, 배운 장점과 단점들을 나열해보고, 왜 결국엔 NixOS를 더 이상 사용하지 않을지 적어보겠습니다.

주의

이런 글에는 집단주의가 언제나 따라오기 마련이니 항상 적어두는 주의사항입니다.

이 블로그 글은 왜 제가 NixOS를 더 이상 사용하지 않는지 서술합니다. 아래 나열하는 장단점은 본인에게 적용되지 않을 수 있습니다. 어떤 것들은 쉬운 해결책을 찾으실 수도 있습니다. 어떤 것들은 말도 안 된다고 생각하실 수 있죠.

아래 댓글을 작성하신다면 다른 분들에게 도움이 되기를 바라면서 작성하시기 바랍니다. (그리고 만약 블로그 글에 관련성이 높다면 글을 수정하여 댓글을 참조하겠습니다.) 하지만 댓글에 본인 입장이 가장 올바르고 좋은 의견이라고 작성하시지 마시기 바랍니다. 거의 대부분 모든 분들께 적용되는 입장이 아닐 가능성이 높으니까요. 감사합니다.

장점들

일단 장점부터 나열하고 싶은데, NixOS를 사용하면서 몇 가지 점들은 진짜 사용성을 편리하게 해주었습니다.

초기 복구 시간 단축

만약 노트북이 고장나거나, SSD가 죽거나, 엄청난 실수를 저질러 작업공간을 망친다면, 일반적인 재설치 절차는 설치 미디어를 생성하고, 드라이브를 지우며, OS를 재설치하고, 드라이버를 다시 깔고 (macOS도 당연히 해당됩니다 — 모든 드라이버가 포함되어 있지 않죠), 프로그램들을 모조리 다시 설치하고, 하나하나 설정해야 했습니다.

NixOS도 비슷하지만, 운영체제 설치 후에는 이야기가 조금 달라집니다. 상기 서술한 절차와 다르게, 그냥 레포지토리를 복사하고, “symlink”를 만든 다음 sudo nixos-rebuild switch를 돌리면 컴퓨터가 거의 대부분1 복원됩니다. 설치했던 프로그램들을 전부 포함해서 말이죠!

물론, 만약 프로그램들이 NixOS를 통한 설정을 지원하지 않는다면 수동으로 설정해야 되지만, 무슨 프로그램들이 깔려 있었는지 외운 다음에 다시 다 설치하지 않아도 되어 전반적으로 시간을 많이 절약해줍니다.

잘못된 설정값들에 대한 빠른 복구

만약 설정을 잘못 만지거나, 원하지 않는 프로그램을 설치한다면, 복구는 그냥 git revert 후 sudo nixos-rebuild switch로 해버릴 수 있습니다.

게다가 컴퓨터에 문제가 생기면 무슨 변경사항이 문제를 일으켰는지 git bisect로 확인할 수 있습니다. 어떤 결정사항이 컴퓨터에 문제를 일으켰는지 이분법으로 찾는 상상을 하셨다면, NixOS에선 그게 가능합니다.

그리고 각 설정값 변경이 Git 커밋 메시지로 서술되니, 6개월 후에 왜 이런 이상한 결정을 했는지 기억 깊숙한 곳에서 끄집어내지 않아도 되죠.

단점들

장점은 2개밖에 안 적고 바로 단점으로 들어간다고요? (아니, 블로그 제목을 보면 맞긴 하지만…)

프로그램 설치할 때의 불편함

다른 운영체제들에 어플을 설치하려면 .exe 파일을 더블클릭하여 프롬프트들을 답해 나가거나, .dmg 안 앱을 폴더로 드래그하거나, 아니면 sudo pacman -S blender를 입력하면 됩니다. NixOS에서는 프로그램 설치를 할 때마다 설정값 레포지토리를 열고, 현재 사용중인 호스트의 Nix 설정 파일을 찾은 후, 설치하고 싶은 프로그램에 대해 줄을 추가해야 합니다.

사실은요. 전체 절차는 먼저 search.nixos.org에 접속하여, 설치하고 싶은 패키지의 패키지명을 검색하고, 설정 레포지토리를 연 다음, 현재 사용중인 호스트의 Nix 설정 파일을 찾은 후, 설치하고 싶은 프로그램에 대해 줄을 추가해야 합니다.

(물론 어떤 NixOS 전문가들이 nix-locate와 같은 명령들이 있다는 점을 얘기하겠지만, 제가 지난 몇 달간 테스트해본 결과 이 방법도 완벽하지는 않습니다. 예를 들어 dnsutils 패키지 안 dig 도구를 찾을 때 nix-locate로는 찾을 수 없었지만 실제 사이트에서는 찾을 수 있었습니다.)

그리고 이건 nixpkgs에서 추적되고 있는 프로그램에 대해서만 해당되죠. 하지만 추적되지 않는 프로그램들은 어떻게 될까요?

NixOS 사용, Nix를 배우는 전제 조건

“전 NixOS를 사용하면서 Nix를 배울 필요가 없었는데요?”

아마도 그랬을 수도 있습니다. 하지만 이런 문제를 겪고 나면, 차우리 배워야 되겠다는 생각을 하실 수도 있죠.

nixpkgs 안에 제공되는 패키지들만을 사용한다면, NixOS를 사용하면서 크게 불편하지는 않을 겁니다. 하지만 제공되지 않는 패키지를 사용한다면 거기서부터 문제가 시작되죠.

제 경우에는, 리눅스에서 한국어 입력 방식으로서 애용중인 nimf라는 패키지와, 제 ThinkPad T480의 지문인식 센서를 돌려주는 python-validity라는 패키지가 둘 다 nixpkgs에서 제공되지 않고 있습니다. nixpkgs에 추가를 요청하는 요청서로 올라가 있긴 했지만 (두 번째 요청서는 제가 직접 작성했죠):

NixOS 개발진이 패키지 요청서를 더 이상 받지 않기로 하면서 닫혀버렸습니다2. 이제 이러한 패키지들을 원한다면, 직접 기여해야 합니다.

자동으로 닫는 봇이 작성한 메시지

If you wish to see this package in Nixpkgs, we encourage you to contribute it yourself, via a Pull Request.

(한국어 번역):

만약 이 패키지를 Nixpkgs에서 만나보고 싶으시다면, 저희는 Pull Request를 통해 이 패키지를 직접 기여하실 것을 권장합니다.

그래서 만약 Nix를 모른다면, NixOS의 모든 것이 Nix를 기반으로 하고, 이러한 기여나 다른 작업을 할 수 없기에, 사용하고 싶은 도구를 사용하는데 시간을 할애하지 않고 Nix를 배우는 데 쏟아야 되죠.

“이건 모든 배포판에 해당되지 않나요?”라고 하실 수도 있습니다. 그럼요. Arch에서는 프로그램을 패키징하기 위해 PKGBUILD manifest를 작성해야 하겠죠. 하지만 완전히 새로운 언어를 배울 필요는 없을 겁니다. (제가 든 PKGBUILD 예시는 bash만 알면 작성할 수 있고, 절차도 Arch 위키에 매우 친절하게 서술되어 있죠.)

그럼 Arch의 PKGBUILD를 배우고 싶지 않다고 가정해보겠습니다. 그러면 아직도 다른 수단이 준비되어 있죠. 바로 Arch User Repository(AUR)에 커뮤니티의 다른 사용자들이 기여한 PKGBUILD들을 사용하면 됩니다.

“하지만 사용자들이 기여한 PKGBUILD에 악성코드가 숨어있을 수도 있잖아요!” 그러면 다른 방법을 더 찾아보겠습니다. (여기에서 nixpkgs와 여기에 기여하는 모든 분들이 완전히 믿을만한 존재로 여겨진다는 부분은 무시하겠습니다.) 다른 배포판에서는 아직도 추가 수단이 준비되어 있는데, 바로 패키징 도구를 사용하지 않고 곧바로 패키지 자체를 컴파일한 후 설치를 할 수 있습니다. NixOS에선 이게 불가능한데, 바로 시스템 파일을 수정할 수 없도록 읽기 전용으로 처리되어 있기 때문이죠. 만약 강제로 파일을 바꾸더라도, 다음 시스템 세대 빌드를 진행해버리면 수정사항들이 전부 사라지게 됩니다.

NixOS가 Nix를 기반으로 만들어졌으면 안된다는 말이 아닙니다. 말이 안되는 부분이죠. 배포판 이름에도 포함되어 있는데요. 하지만 이 방식은 운영체제를 돌리는 언어를 모르는 새로운 사용자들이 빠르게 적응하여 새로운 프로그램을 설치하는데 도움이 되질 않습니다.

“당연히 NixOS를 사용하려면 Nix를 배워야죠! 일본에 가서 한국어로 대화하길 바라나요?” 하지만 일본어를 배우지 않고도 일본에서 불편하게라도 생활은 가능합니다. 다른 배포판에서는 이러한 PKGBUILD 시스템을 배우고 싶지 않으면서도 필요한 도구를 사용할 수 있도록 대응책이 마련되어 있지만, NixOS와 Nix에서는 불변성을 중요시하기 때문에 이러한 불편사항을 조금이라도 완화해줄 대응책들이 막혀버리게 됩니다. 어떤 분들은 이것이 NixOS의 장점, 또는 기능이라고 여기실 수 있지만, 결국에는 이러한 사항들을 모른다면 불편한 점이 존재하는 부분은 동의하실만하다고 생각합니다.

프로그램을 업그레이드할 때의 불편함

예시를 들어, 만약 버전 3.6.12를 필요로 하는 파일을 받았다고 가정해보겠습니다. 하지만 컴퓨터에 깔려있는 버전은 3.6.6입니다. 어떻게 진행할까요?

다른 운영체제에서는 3.6.12 버전의 설치 파일을 다운받아 설치한 후 바로 진행하면 됩니다. 아니면 sudo pacman -S blender 아니면 sudo apt upgrade blender 아니면 다른 명령만 실행하면 되죠. 요약하자면, 다른 운영체제에서는 이 부분이 쉽다는 점입니다.

하지만 NixOS에서는 이것이 불가능합니다. 모든 패키지 메타데이터는 nixpkgs 레포지토리 안에 저장되는데, 각 버전 업그레이드는 Git 커밋으로 기록됩니다. 아마도 이 시스템을 유지보수하는 NixOS 개발진에게는 좋은 시스템일지 모르겠지만, 이 방식으론 사용자의 Nix “flake” lockfile (잠금파일, 버전이나 Git 커밋 해시를 특정 시점에 고정시켜버리는 파일)에 기록된 커밋 해시에 대응하는 프로그램 버전들만 설치된다는 문제가 있습니다. 따라서 3.6.12로 업그레이드를 원한다면 커밋 해시를 버전 3.6.12를 포함하는 해시로 변경해야 하죠.

문제는, 최초에 기록되었던 커밋 해시와 새로운 3.6.12 커밋 사이에 있던 커밋들이 전부 포함되면서 해당 커밋들에 상응하는 패키지들도 모조리 업그레이드되는데, 한 패키지 업그레이드를 시도하다가 전부 다 업그레이드를 진행하면서 최소 20분 (너무 업그레이드를 안 했다면 몇 시간!)이 걸려 골치아픈 상황이 생길 수 있습니다.

그리고 업그레이드가 완성되면, 마지막 flake lock과 현재 lock 사이에 어떤 버전들이 변경되었는지 쉽게 확인할 방법이 없는 부분도 문제가 됩니다. 제 경우에는 컴퓨터를 재부팅한 후 바탕화면이 바뀌면 KDE가 업그레이드 되었다는 것을 알게 되고, 프로그램을 열 떄 “변경사항” 팝업이 나타나면 그제서야 알게 됩니다. NixOS는 업그레이드할 패키지 목록을 표시해주지 않으니까요.

컴파일 속도

그러면 업그레이드 절차가 왜 이렇게 오래 걸릴까요?

시스템 업그레이드를 진행하면서 콘솔을 확인해보면 거의 대부분 패키지들이 실행할 수 있는 바이너리 형식으로 컴파일되는 부분을 확인하게 됩니다.

하지만 NixOS는 cache.nixos.org에 바이너리 캐시가 있는데요? 빌드가 그렇게 오래 걸릴 리 없어요. 뭐가 문제죠?

서브도메인의 이름에서 유추할 수 있듯이, 패키지들이 먼저 NixOS의 서버에서 컴파일되어야 베포를 위해 서버에 캐싱됩니다. 만약 요청한 패키지가 예전에 요청된 적 없는 패키지거나, 아니면 기존 패키지에 새로운 업데이트가 추가된다면, 캐시된 바이너리를 받을 수 있는 상태가 되려면 빌드 작업이 진행되어야 합니다.

그리고 만약 설정값 안에 빌드 절차 수정사항이 들어 있다면 다른 바이너리를 요구로 하는데, 이런 경우에는 NixOS 서버에 존재할 이유가 거의 없죠. 그러면 NixOS는 곧바로 패키지를 시스템 상에서 소스를 사용해 컴파일하는 방식으로 전환하게 됩니다.

물론 노트북을 매번 switch3를 돌릴 때마다 전기장판으로 변신시키지 않도록 빌드 캐시 서버를 직접 구성하실 수 있지만, 이 역시 설정을 처음부터 다 하고 문제가 없는지 항상 확인해야 되는 번거로움이 생기게 됩니다.

NixOS를 통한 “전체” 설정

NixOS 설정에 모든 설정값들을 작성하고 설명하는 부분은 어느 정도까지는 매우 좋습니다. 이 “어느 정도”가 끝나는 부분은 바로 Nix 설정줄로 변환되지 않은 설정값과 맞닥뜨리는 경우죠.

예를 들어, 애용하는 생산성 프로그램에 있는 어떤 숨겨진 체크박스가 설정값을 변경하는데 이 설정 변경이 파일에 기록되지 않는다고 가정해보겠습니다. 아니면 어떤 클라우드 방식 어플이 호스트네임을 기반으로 설정을 클라우드에 저장한다고 생각해보고요. 조금 억지스러운 예시일 수 있지만, 제가 말씀드리고자 하는 부분은 “전부 다” NixOS에서 설정을 할 수 있다는 부분이 아니라는 점입니다.

그리고 어쩔 땐 크게 문제가 되지는 않습니다. 예시로 제가 사용한 데스크탑 환경인 KDE에서는 각 시스템마다 설정하고 싶은 옵션값들이 존재합니다. 하지만 만약 시스템 재설치 시 설정이 지속될 수 있도록, 매번 옵션을 변경하거나 체크박스를 수정할 때마다 설정 파일을 변경해야 한다면, 아마도 빠르게 미치지 않을까 싶습니다.

물론, KDE 예시에서는 현재 설정값을 Nix 설정으로 변환해주는 rc2nix와 같은 도구가 존재하기는 합니다. 하지만 제가 사용해본 경험으론 완벽하지 않은데, KDE와 같이 오는 어플들은 설정하는 방식이 제각각이고 다 다른 곳에 설정 파일을 저장하기 때문입니다. (아니, 파일 매니저인 Dolphin만 보더라도 .dolphinrc에 설정을 저장하는데, rc2nix는 이를 확인하지 않기 때문에, 이 파일이 어디에 저장되어 있고 어떤 줄들이 현재 호스트에 영향을 끼치며 어떻게 파일을 Nix 설정 레포지토리에서 symlink해 올 수 있는지 확인해야 되고 Dolphin이 만약 새로운 줄들을 추가한다면 기존 설정 파일에 제대로 추가되는지 확인해야 되며 만약 리빌드할 경우 설정 파일 안 변경사항들이 지워지지 않는지 확인해야 되고 이런 것들을 계속 반복하다 보면 머리가 아파오기 마련이죠.)

Dolphin 예시처럼, 모든 프로그램들이 외부적으로 설정되는 것을 달가워하지 않습니다. 프로그램들은 대부분 어디에서나 아무 운영체제에서나 (그리고 리눅스에서는 아무 베포판에서나) 실행되도록 짜이기 때문에, 거의 대부분 NixOS의 존재조차 모를 가능성이 높습니다. 따라서 NixOS가 운영하는 방식을 알지 못해 동일하게 맞춰 나가지 않는 부분이 많죠.

그리고 만약 설정 변경이 설정 파일을 복사하거나 symlink하는 것을 요구한다면, NixOS가 리빌딩을 진행할 경우 프로그램에서 만든 수정사항들이 전부 날라가버리면서 사용자 경험을 망치게 됩니다. NixOS에서 (설정할 수 있는) “모든 것”을 설정하는 것을 원칙으로 하지만, 아까 보셨던 것처럼 NixOS를 통해 “모든 것”을 설정하는 것은 불가능하기 때문에, 이렇게 2개 이상의 설정 원천이 서로 대립하면서 설정값들이 삭제되고 나쁜 시간이 펼쳐지죠.

마치면서

그러면 NixOS가 엄청 나쁘고 아무도 쓰지 않아야 되는 베포판인가요? 아니요. 위에 적은 단점들을 겪음에도 불구하고 NixOS를 사용하고 배우는 시간이 재밌었습니다. 하지만 저는 시스템을 사용할 때 저만의 방식을 고집하고, 시간이 지나면서 이러한 컴퓨팅 방식이 NixOS가 추구하는 선언적 및 불변적 방식과는 다르다는 부분을 인지하게 되었습니다.

아마도 나중에 시간이 나서 Nix를 완전하게 배울 수 있고, 위에서 겪었던 단점들을 어느 정도 완화할 수 있도록 자료와 문서가 나아진다면 다시 NixOS를 시도해볼 의향이 있습니다. 하지만 지금은 제가 원하는 일을 할 수 있도록 컴퓨터를 구성하고 싶고, NixOS의 단점들이 기능을 통해 제공하는 장점보다 더욱 많아 업무에 지장을 주게 되어 한번 글을 작성해보았습니다.

Footnotes

  1. 여기에서 “거의 대부분”이라고 말하는 이유는 하단의 단점 부분에서 더 서술하겠습니다. ↩

  2. 물론 당연히 개발진이 안 받겠다고 하는데 이게 잘못되었다는 건 아닙니다! 그래도 사용자들이 사용하기에 불편해지는 건 다름없으니, 제 단점이 틀리게 되는 것도 아니죠. ↩

  3. 이 명령구는 엄청 쓰기 편리한데 왜 기본이 아닌지 모르겠습니다. 원하시면 이렇게 설정해보시면 됩니다. ↩