NixOS 랩탑 설정의 재현가능성 - 선언적 시스템의 힘

NixOS로 랩탑 설정하기 - 재현가능한 시스템 구성의 힘

들어가며: 삼성 노트북과의 싸움

삼성 갤럭시북 NT930SBE를 Ubuntu에서 사용하려 했던 경험은 고통스러웠다. 밝기 조절이 안되고, 배터리 임계값 설정을 위해 커널 모듈을 수동으로 컴파일해야 했으며, 커널 업데이트 때마다 DKMS가 깨지는 일이 반복되었다. “왜 메이저 배포판에서 랩탑 하드웨어 지원이 이렇게 어려운가?”라는 질문이 시작점이었다.

NixOS로 전환한 후, 같은 하드웨어가 완전히 다른 경험을 제공했다. 단순히 “작동한다”를 넘어서, 재현가능하고, 공유가능하며, 유지보수가 쉬운 시스템이 되었다. 이 문서는 그 여정과 인사이트를 기록한다.

문제의 본질: 명령형 vs 선언형 시스템

Ubuntu 방식: 명령형 (Imperative) 시스템

전형적인 삼성 노트북 설정 과정

Ubuntu에서 삼성 노트북을 제대로 사용하려면:

드라이버 수동 컴파일

git clone https://github.com/joshuagrisham/samsung-galaxybook-extras
cd samsung-galaxybook-extras
make
sudo make install
sudo modprobe samsung_galaxybook

DKMS 설정 (커널 업데이트 대비)

sudo dkms add -m samsung-galaxybook -v 1.0
sudo dkms build -m samsung-galaxybook -v 1.0
sudo dkms install -m samsung-galaxybook -v 1.0

TLP 설치 및 설정

sudo add-apt-repository ppa:linrunner/tlp
sudo apt update
sudo apt install tlp tlp-rdw
sudo systemctl enable tlp
sudo vim /etc/tlp.conf  # 수동 편집

밝기 조절 권한 설정

sudo tee /etc/udev/rules.d/90-backlight.rules <<EOF
ACTION=="add", SUBSYSTEM=="backlight", RUN+="/bin/chgrp video /sys/class/backlight/%k/brightness"
ACTION=="add", SUBSYSTEM=="backlight", RUN+="/bin/chmod g+w /sys/class/backlight/%k/brightness"
EOF
sudo usermod -aG video $USER
sudo reboot

키 바인딩 설정 (i3 사용자)

vim ~/.config/i3/config
# 매번 경로 확인하고 수동 입력

문제점: 상태의 불확실성

비재현성: 같은 과정을 다른 노트북에서 반복해도 미묘하게 다른 결과
의존성 지옥: PPA, 수동 컴파일, 시스템 라이브러리 버전
업데이트 공포: 커널 업데이트 = 모든 것이 깨질 수 있음
문서화 어려움: “내가 무엇을 설치했더라?”
롤백 불가능: 잘못되면 재설치 or 길고 긴 디버깅

근본 원인: 명령의 누적

Ubuntu 시스템은 *명령의 누적*이다:

apt install 명령이 쌓이고
설정 파일이 여기저기 흩어지고
수동으로 추가한 스크립트들이 존재하고
순서가 중요하고 (A를 먼저 설치해야 B가 동작)
*현재 상태*를 완전히 알 수 없다

“You can’t step into the same river twice.” 명령형 시스템은 강물과 같다. 같은 명령을 내려도, 시스템의 상태에 따라 결과가 다르다.

NixOS 방식: 선언형 (Declarative) 시스템

같은 하드웨어, 다른 접근

NixOS에서 삼성 노트북 설정:

# machines/laptop.nix
{
  # TLP 배터리 관리 (선언)
  services.tlp = {
    enable = true;
    settings = {
      START_CHARGE_THRESH_BAT0 = 40;
      STOP_CHARGE_THRESH_BAT0 = 80;
      CPU_SCALING_GOVERNOR_ON_AC = "performance";
      CPU_SCALING_GOVERNOR_ON_BAT = "powersave";
    };
  };
 
  # 터치패드 (선언)
  services.libinput = {
    enable = true;
    touchpad = {
      tapping = true;
      naturalScrolling = true;
    };
  };
}

# users/junghan/modules/i3.nix
{
  # 밝기 조절 (선언)
  "XF86MonBrightnessUp" =
    "exec --no-startup-id ${pkgs.brightnessctl}/bin/brightnessctl set +5%";
  "XF86MonBrightnessDown" =
    "exec --no-startup-id ${pkgs.brightnessctl}/bin/brightnessctl set 5%-";
}

*단 두 파일, 약 40줄*로 완료.

핵심 차이점

측면	Ubuntu (명령형)	NixOS (선언형)
설정 방법	명령 실행 → 상태 변경	원하는 상태 선언
재현성	낮음 (순서/타이밍 의존)	완벽 (동일 입력 = 동일 출력)
롤백	불가능 (또는 스냅샷)	즉시 (부팅 메뉴 선택)
공유	스크립트 + 긴 설명서	config 파일 공유
업데이트	불안 (깨질 수 있음)	안전 (원자적 업데이트)
문서화	별도 필요	config가 곧 문서
학습 곡선	낮음 (익숙함)	높음 (새로운 패러다임)

NixOS의 핵심 장점: 재현가능성 (Reproducibility)

1. 설정 = 시스템 상태

NixOS에서 configuration.nix는 단순한 “설정 파일”이 아니다. 이것은 *시스템의 완전한 명세(specification)*다.

“If you can describe it, you can reproduce it.”

예시: 노트북 교체 시나리오

Ubuntu 방식:

새 노트북에 Ubuntu 설치
이전 노트북에서 dpkg --get-selections 추출
PPA 목록 복사
수동 설정 파일들 찾아서 복사 (어디에 뭐가 있더라?)
스크립트 실행 (순서 중요!)
문제 발생 → 디버깅 → 반복
결과: 비슷한 시스템 (완전히 같지는 않음)

NixOS 방식:

새 노트북에 NixOS 설치
이전 config 파일 복사 (또는 git clone)
nixos-rebuild switch
결과: 동일한 시스템 (차이 없음)

소요 시간: Ubuntu 반나절 vs NixOS 30분

2. Git으로 관리하는 시스템

NixOS 설정은 일반 텍스트 파일이므로, Git으로 버전 관리가 자연스럽다.

~/repos/gh/nixos-config/
├── .git/
├── machines/
│   ├── laptop.nix
│   └── desktop.nix
├── users/
│   └── junghan/
└── flake.nix

이점:

히스토리: “2주 전에 뭘 바꿨더라?” → git log
실험: 브랜치 만들어서 테스트 → 안되면 버리기
협업: 다른 사람 설정 참고 → fork & modify
백업: GitHub/GitLab에 push → 언제든 복원

실제 사례: 밝기 조절 키 추가

# Git 히스토리에 명확히 기록됨
git log --oneline users/junghan/modules/i3.nix
 
# a1b2c3d Add screen brightness keybindings (XF86MonBrightness*)
# e4f5g6h Add keyboard backlight support (samsung-galaxybook)
# ...

문제 발생 시:

git revert a1b2c3d
nixos-rebuild switch

즉시 이전 상태로.

3. 공통 설정 + 개별 설정 분리

구조적 모듈화

NixOS는 설정을 *논리적 모듈*로 분리할 수 있다:

# flake.nix
{
  nixosConfigurations = {
    laptop = nixpkgs.lib.nixosSystem {
      modules = [
        ./machines/laptop.nix      # 랩탑 특화 (TLP, brightness)
        ./modules/common.nix        # 공통 (git, vim, 기본 패키지)
        ./modules/wm/i3.nix         # 윈도우 매니저
        ./users/junghan/home.nix    # 개인 설정 (home-manager)
      ];
    };
 
    desktop = nixpkgs.lib.nixosSystem {
      modules = [
        ./machines/desktop.nix      # 데스크탑 특화 (CUDA, GPU)
        ./modules/common.nix        # 같은 공통 설정!
        ./modules/wm/i3.nix         # 같은 i3 설정!
        ./users/junghan/home.nix    # 같은 개인 설정!
      ];
    };
  };
}

의미:

공통: 한 번 설정하면 모든 기기에 적용
개별: 기기별 특수 사항만 분리
재사용: 모듈을 다른 프로젝트에서도 import

예시: 랩탑 vs 데스크탑

# machines/laptop.nix (랩탑만의 특별 설정)
{
  imports = [ ./common.nix ];  # 공통 설정 상속
 
  services.tlp.enable = true;           # 랩탑: 배터리 관리
  powerManagement.cpuFreqGovernor = "powersave";  # 전력 절약
  services.thermald.enable = true;      # 열 관리
}
 
# machines/desktop.nix (데스크탑만의 특별 설정)
{
  imports = [ ./common.nix ];  # 같은 공통 설정!
 
  services.xserver.videoDrivers = [ "nvidia" ];  # 데스크탑: GPU
  hardware.nvidia.modesetting.enable = true;
  powerManagement.cpuFreqGovernor = "performance";  # 성능 우선
}

결과:

공통 패키지 (git, vim, emacs): 양쪽 동일
i3 키바인딩: 양쪽 동일
전력 관리: 각자 최적화
하드웨어 드라이버: 각자 맞춤

메이저 배포판보다 쉬운 공통 설정

역설: “어려운 NixOS가 더 쉽다?”

학습 곡선:

Ubuntu: 낮음 (익숙한 명령어)
NixOS: 높음 (새로운 언어, 새로운 개념)

하지만 *유지보수와 확장*에서:

Ubuntu: 점점 어려워짐 (복잡도 누적)
NixOS: 점점 쉬워짐 (재사용 증가)

사례 1: 여러 기기에 같은 개발 환경 구축

요구사항:

노트북, 데스크탑, 원격 서버에서
같은 에디터 (Emacs)
같은 셸 (Zsh + Oh-My-Zsh)
같은 개발 도구 (Python, Node.js, Rust)
같은 설정 파일들

Ubuntu 방식:

노트북에서 구축 (수많은 apt, pip, npm 명령)
데스크탑에서 “비슷하게” 재구축 (미묘한 차이 발생)
서버에서 또 재구축 (SSH로 하나씩…)
패키지 업데이트 → 세 기기 모두 따로 관리
설정 변경 → 세 기기에서 따로 수정

NixOS 방식:

한 번 정의 (modules/development.nix)

{
  home.packages = with pkgs; [
    emacs python3 nodejs rustc cargo
  ];
  programs.zsh = {
    enable = true;
    oh-my-zsh.enable = true;
  };
}

모든 기기에서 import

imports = [ ../modules/development.nix ];

끝. (정확히 동일한 환경)

사례 2: 삼성 노트북 설정 공유

내가 만든 Samsung NT930SBE 설정을 다른 사람이 사용하려면:

Ubuntu 방식:

20페이지 가이드 작성
“먼저 이거 설치, 그 다음 저거 설치…”
버전 차이로 안되면 → “제 환경에서는 되는데요…”

NixOS 방식:

# GitHub에서 config 공유
git clone https://github.com/junghanacs/nixos-config
cd nixos-config
nixos-rebuild switch --flake .#laptop

*단 3줄*로 완전히 동일한 시스템 재현.

실전 인사이트: 삼성 노트북 사례

발견 1: 커널 모듈은 자동으로 관리된다

Ubuntu:

samsung-galaxybook 모듈 수동 컴파일
DKMS로 자동 재빌드 설정 (자주 깨짐)
커널 업데이트 때마다 불안

NixOS:

커널에 이미 포함됨 (mainline since 5.18)
hardware-configuration.nix 자동 생성으로 감지
커널 업데이트 = 모듈도 자동 업데이트
문제 생기면 → 이전 커널로 부팅 (grub 메뉴)

발견 2: TLP는 선언형이 훨씬 명확하다

Ubuntu /etc/tlp.conf (일부):

# Battery charge thresholds (ThinkPad only, not ThinkPad Edge).
# Charging starts when the remaining capacity falls below the
# START_CHARGE_THRESH value and stops when exceeding the STOP_CHARGE_THRESH
# value. Main / Internal battery (values in %)
# Default: <none>
 
#START_CHARGE_THRESH_BAT0=75
#STOP_CHARGE_THRESH_BAT0=80

문제:

주석 처리되어 있음 (기본값?)
ThinkPad 전용이라는데 삼성도 되나?
주석 풀고 저장 → 재부팅? 서비스 재시작?

NixOS machines/laptop.nix:

services.tlp = {
  enable = true;
  settings = {
    START_CHARGE_THRESH_BAT0 = 40;
    STOP_CHARGE_THRESH_BAT0 = 80;
  };
};

장점:

명확함: enable = true → TLP 활성화, 아니면 비활성화
타입 안전: 숫자 자리에 문자열 넣으면 빌드 에러
문서화: 코드가 곧 현재 상태
테스트: nixos-rebuild test → 재부팅 없이 확인

발견 3: 밝기 조절 권한은 자동 처리

Ubuntu:

udev 규칙 수동 작성
그룹에 사용자 추가
재부팅 (또는 재로그인)
brightnessctl vs light vs xbacklight 선택 고민

NixOS:

pkgs.brightnessctl 사용 선언 → 끝
logind 통합으로 자동 권한 처리
D-Bus 기반이라 setuid 불필요
재부팅 불필요

철학적 함의: “도구의 도구”

전통적 배포판: 도구

Ubuntu, Fedora, Arch 등은 *도구*다:

패키지 매니저로 소프트웨어 설치
설정 파일로 시스템 조정
명령어로 작업 수행

한계: 도구는 시간이 지나면 무뎌진다.

설정이 누적되고
의존성이 얽히고
“이게 왜 여기 있지?” 하는 파일들이 생기고
결국 재설치가 답

NixOS: 도구를 만드는 도구 (Meta-tool)

NixOS는 *시스템을 정의하는 언어*다:

시스템 = 함수(설정)
같은 설정 → 같은 시스템 (수학적 순수성)
부작용 없음 (pure functional)

“Give me a place to stand, and I will move the earth.” - Archimedes

NixOS는 시스템 관리에 “지렛대”를 제공한다. 단순히 명령을 내리는 것이 아니라, *시스템의 본질을 정의*한다.

비유: 건축 vs 요리

Ubuntu (요리):

레시피 따라하기
재료 순서대로 넣기
타이밍 중요
결과물: 비슷하지만 매번 약간 다름
실패하면: 버리고 다시 시작

NixOS (건축):

청사진 (blueprint) 작성
청사진대로 건물 지어짐
같은 청사진 → 같은 건물
결과물: 완전히 동일
실패하면: 청사진 수정, 재건축

재현가능성의 진짜 가치

기술적 이점:

롤백 가능
테스트 가능
공유 가능
문서화 자동

하지만 진짜 가치는 심리적:

두려움의 제거:

“업데이트해도 괜찮을까?” → “안되면 롤백하면 되지”
“이거 바꿔도 될까?” → “테스트 먼저 해보고”
“새 노트북에서 될까?” → “같은 config면 무조건 됨”

자신감의 획득:

시스템을 *이해*할 수 있다 (모든 게 config에 있음)
시스템을 *제어*할 수 있다 (선언적 정의)
시스템을 *신뢰*할 수 있다 (재현가능성)

한계와 trade-off

NixOS가 만능은 아니다

높은 진입 장벽:

Nix 언어 학습 필요
함수형 프로그래밍 개념
기존 Linux 지식과 충돌 (FHS 안따름)

때때로 더 복잡:

간단한 작업도 선언적으로 정의 필요
공식 패키지 없으면 직접 패키징
디버깅이 어려울 수 있음 (추상화 레이어)

커뮤니티 크기:

Ubuntu/Debian보다 작음
한국어 자료 부족
문제 해결에 더 많은 시간

그럼에도 불구하고

투자 가치:

초기 학습 비용 > 장기 유지보수 절감
한 번 익히면 모든 시스템에 적용
지식이 쌓인다 (명령어는 휘발, 설정은 누적)

적합한 사용자:

여러 기기 사용 (노트북 + 데스크탑 + 서버)
설정 자주 변경/실험
재현가능성 중요 (개발자, DevOps)
시스템 완전히 제어하고 싶은 사람

결론: 랩탑에서 NixOS는 게임 체인저

핵심 깨달음

1. 랩탑은 “변화하는 환경”:

이동 중: WiFi 변경, 배터리/AC 전환
다양한 작업: 개발, 프레젠테이션, 미디어
하드웨어 특수성: 밝기, 배터리 임계값, Fn 키

2. 변화를 관리하는 방법:

명령형: 상태를 직접 조작 → 복잡도 증가
선언형: 원하는 상태 정의 → 시스템이 알아서

3. NixOS의 강점:

랩탑 특화 설정을 *모듈*로 분리
다른 기기와 공통 설정 공유
문제 발생 시 즉시 롤백
새 노트북으로 완벽히 이전

삼성 노트북 사례의 시사점

Ubuntu에서 악몽이던 삼성 노트북 설정이:

NixOS에서는 *단 40줄*로 완료
자동으로 하드웨어 감지
안전하게 업데이트
쉽게 공유 가능

이것은 단순히 “NixOS가 좋다”가 아니라:

*선언적 시스템*이 복잡한 하드웨어 관리에 근본적으로 우수하다는 증거

미래 전망

개인적 계획:

모든 기기를 NixOS로 통합 (laptop, desktop, servers)
공통 모듈 라이브러리 구축
커뮤니티에 설정 공유

기대 효과:

기기 추가 시간: 하루 → 1시간
설정 동기화: 수동 → 자동 (git pull)
업데이트 불안: 높음 → 낮음 (롤백 가능)
지식 축적: 휘발 → 영구 (config 히스토리)

참고 자료

문서

커뮤니티

NixOS Discourse: https://discourse.nixos.org/
NixOS Wiki: https://nixos.wiki/
Reddit r/NixOS: https://reddit.com/r/NixOS

메타데이터

작성일: 2025-10-28
대상 기기: Samsung NT930SBE (Galaxy Book)
NixOS 버전: 25.05
태그: #llmlog #nixos #laptop #reproducibility #declarative
관련 문서: 기술 가이드

“Simplicity is the ultimate sophistication.” - Leonardo da Vinci

NixOS는 겉보기엔 복잡하지만, 본질은 단순하다: 시스템의 상태를 정의하라. 나머지는 시스템이 알아서 한다.

junghanacs🧠

Backlinks

NixOS 랩탑 설정의 재현가능성 - 선언적 시스템의 힘

NixOS로 랩탑 설정하기 - 재현가능한 시스템 구성의 힘

들어가며: 삼성 노트북과의 싸움

문제의 본질: 명령형 vs 선언형 시스템

Ubuntu 방식: 명령형 (Imperative) 시스템

전형적인 삼성 노트북 설정 과정

문제점: 상태의 불확실성

근본 원인: 명령의 누적

NixOS 방식: 선언형 (Declarative) 시스템

같은 하드웨어, 다른 접근

핵심 차이점

NixOS의 핵심 장점: 재현가능성 (Reproducibility)

1. 설정 = 시스템 상태

예시: 노트북 교체 시나리오

2. Git으로 관리하는 시스템

실제 사례: 밝기 조절 키 추가

3. 공통 설정 + 개별 설정 분리

구조적 모듈화

예시: 랩탑 vs 데스크탑

메이저 배포판보다 쉬운 공통 설정

역설: “어려운 NixOS가 더 쉽다?”

사례 1: 여러 기기에 같은 개발 환경 구축

사례 2: 삼성 노트북 설정 공유

실전 인사이트: 삼성 노트북 사례

발견 1: 커널 모듈은 자동으로 관리된다

발견 2: TLP는 선언형이 훨씬 명확하다

발견 3: 밝기 조절 권한은 자동 처리

철학적 함의: “도구의 도구”

전통적 배포판: 도구

NixOS: 도구를 만드는 도구 (Meta-tool)

비유: 건축 vs 요리

재현가능성의 진짜 가치

한계와 trade-off

NixOS가 만능은 아니다

그럼에도 불구하고

결론: 랩탑에서 NixOS는 게임 체인저

핵심 깨달음

삼성 노트북 사례의 시사점

미래 전망

참고 자료

문서

커뮤니티

관련 프로젝트

메타데이터

Graph View

Explorer

Backlinks