Lightwhale 3: Linux 서버를 다시 재미있게 만들기

• Docker 컨테이너 전용으로 설계된 Linux 서버 OS로, ISO만 부팅하면 곧바로 Docker Engine 환경에 들어가게 됨
• 코어 시스템을 불변·무상태 구조로 두고 /etc, /var, /home과 Docker 데이터만 별도 쓰기 영역으로 분리해, 설치와 초기 설정 부담을 크게 줄여 줌
• 기본 데이터 파일시스템은 tmpfs 기반 휘발성 저장소이며, 영속성을 켜면 별도 저장장치를 자동 감지해 파티셔닝·포맷·마운트하고 필요하면 Btrfs RAID1으로도 구성됨
• squashfs 기반 읽기 전용 루트와 최소 구성 요소를 사용해 악성코드나 의도치 않은 수정 노출면을 줄이고, 자원 사용량과 전력 소모도 낮추게 만듦
• x86-64 전용으로 베어메탈과 가상머신에서 동작하며, 서버 관리 자체보다 컨테이너 실행과 셀프호스팅 운영에 바로 집중하게 해 줌

---

개요

• Docker 컨테이너 전용으로 설계된 Linux 서버 OS이며, ISO로 라이브 부팅하면 곧바로 Docker Engine 환경에 들어감
• 설치와 초기 설정 부담을 줄이기 위해 코어 시스템은 불변 구조로 두고, 데이터와 사용자 커스터마이징은 별도 저장 영역으로 분리함
• 홈랩, 베어메탈, 가상화 환경, 엣지 노드, 클러스터까지 겨냥하지만, 지원 아키텍처는 x86-64로 한정됨
• 최소 구성과 사용 편의성을 우선해, 서버 관리보다 컨테이너 실행과 운영 자체에 집중하게 만듦

주요 특징

• 플러그 앤 플레이 방식이라 ISO만 내려받아 부팅하면 필요한 도구가 포함된 Docker Engine이 바로 준비됨
• 구성 요소를 최소화해 학습 부담을 낮추고 시스템 동작을 빠르게 파악할 수 있게 함
• 불변·무상태 코어를 사용해 악성코드와 의도치 않은 수정에 대한 노출면을 줄이고, 매번 같은 상태로 부팅됨
• 선택적 영속성을 제공하며, 기본 데이터 파일시스템은 RAM의 휘발성 tmpfs이고 영속성을 켜면 별도 저장장치를 자동 감지해 파티셔닝·포맷·마운트함
• 불필요한 프로세스를 줄여 자원 사용량과 전력 소모를 낮추고, 구형 또는 저사양 장비를 더 오래 활용하게 함
• 셀프호스팅을 쉽게 운영하도록 해 Big Tech 종속에서 벗어나고 데이터와 프라이버시를 직접 관리하게 만듦

시작 방법

• 최신 ISO 다운로드 또는 다운로드 섹션에서 이미지를 받아 USB에 기록한 뒤 부팅하면 됨
• 일부 시스템에서는 부팅 전에 BIOS에서 safe boot 비활성화가 필요할 수 있음
• 기본 로그인은 사용자명 op, 비밀번호 opsecret이며, 인터넷에 노출하기 전에는 비밀번호 변경이 최소한 필요함
• Wi-Fi는 setup-wifi로 선택적으로 설정 가능함
• 컨테이너 실행은 일반 Docker 사용과 같으며, 예시로 docker run -it --rm busybox ps를 사용함
• 영속성 활성화 때는 파티션이 아닌 블록 디바이스에 magic header를 써야 하며, 이 과정에서 기존 데이터가 지워짐

부팅과 실행 구조

• ISO는 베어메탈과 가상머신에서 부팅 가능하며, UEFI와 전통 BIOS를 모두 지원함
• 시작 과정은 sysv 유사 init 시스템을 사용해 단순하고 투명한 부팅 흐름을 유지함
• 부트로더가 Linux 커널과 루트 파일시스템을 메모리에 올린 뒤, 커널이 하드웨어를 초기화하고 /init에 제어를 넘김
• init는 /etc/inittab을 읽고 /tmp, /run용 tmpfs를 마운트한 뒤 /etc/init.d의 스크립트를 실행함
• 초기에 data filesystem을 마운트해 Docker 데이터와 /etc, /var, /home의 overlay 상위 레이어를 제공함
• 모든 파일시스템과 overlay가 준비된 뒤 나머지 서비스가 시작되고, 그 시점부터 컨테이너를 서비스할 수 있음

불변성 설계

• 루트 파일시스템은 압축된 squashfs 정적 이미지로 제공되며, 자체적으로 수정 불가능한 구조임
• 이 구조 덕분에 필수 소프트웨어와 설정이 미리 포함되어, 설치 과정 없이 부팅 가능한 자급형 이미지가 됨
• 패키지 관리자, 의존성 관리, 기존 시스템 업데이트 경쟁을 피하고, 이미 동작하는 것을 다시 설치하는 작업을 재부팅 하나로 대체함
• 루트 파일시스템 파일은 실수로 삭제되거나 바이러스에 의해 수정되지 않으며, 전통적 시스템처럼 커널과 기반 바이너리 전체가 수정 가능 상태로 노출되지 않음
• 읽기 전용 루트 구조라 장기간 운영 중 남는 파일이 쌓이며 백업과 성능, 정리 상태를 해치는 잡동사니 축적을 막음
• 로컬 VM이나 다른 컴퓨터에서 자유롭게 시험해 보고, 재부팅으로 변경을 되돌릴 수 있음
• 부팅 매체에는 중요한 정보가 없고 불변성으로 그 상태가 유지되므로, 장치가 손상되거나 분실돼도 새 복사본으로 복구 가능함

영속성 구조

• 컨테이너 설치·실행, 설정 변경, 데이터 기록에는 쓰기 가능한 파일시스템이 필요하며, 재부팅 뒤에도 유지하려면 영속성이 필요함
• 초기 부팅 단계에서 자동으로 동작하는 하위 시스템이 /mnt/lightwhale-data에 data filesystem을 마운트함
• Lightwhale이 기록하는 데이터는 /mnt/lightwhale-data/lightwhale-state 아래에 모이며, 이 디렉터리가 overlayfs의 쓰기 가능한 상위 레이어가 됨
• 기본값은 휘발성 tmpfs이고, 영속성을 켜면 data filesystem이 별도 저장장치에 위치하게 바뀜
• 전체 루트를 덮지 않고 /etc, /var, /home만 선택적으로 overlay 처리해 불변성의 목적을 유지함
  • /etc는 네트워크, 비밀번호, sshd 같은 시스템 설정 커스터마이징에 사용됨
  • /var는 로그와 기타 애플리케이션 데이터에 사용됨
  • /home은 SSH authorized keys, Git 저장소 클론, Docker·Swarm 스택 관리 같은 사용자 커스터마이징에 사용됨
• Docker의 data root는 /mnt/lightwhale-data/lightwhale-state/docker에 직접 위치하며, 이미지·컨테이너·볼륨·네트워크 상태를 저장함

영속성 활성화와 자동 처리 단계

• 영속성은 echo "lightwhale-please-format-me" | sudo dd conv=notrunc of=/dev/sdx처럼 magic header를 저장장치에 기록해 명시적으로 켜야 함
• 여러 저장장치에 magic header를 기록할 수 있으며, 그 경우 Btrfs RAID1 볼륨으로 조합됨
• 다음 부팅 때 시스템이 magic disk를 감지해 포맷하고 data filesystem으로 사용함
• persistence subsystem는 /etc/init.d/S11persistence에서 시작됨

• 데이터 파일시스템 탐지

  • 모든 디스크를 검사해 파일시스템 라벨이 lightwhale-data인 파티션을 찾음
  • 찾으면 그것을 data filesystem으로 사용하고 이후 마운트 단계로 건너뜀

• magic disk 탐지와 파티션 생성

  • 디스크 시작 위치의 바이트 시퀀스 lightwhale-please-format-me를 찾아 magic disk를 판별함
  • 각 magic disk에는 lightwhale-swap 라벨의 swap 파티션과, 남은 공간 전체를 쓰는 lightwhale-data 라벨의 Linux 파티션을 만듦

• 파일시스템 생성

  • magic swap 파티션은 포맷 뒤 lightwhale-swap 라벨을 붙임
  • magic data 파티션이 하나면 btrfs --data single --metadata dup로 포맷함
  • 여러 개면 RAID1으로 묶고 btrfs --data raid1 --metadata raid1cn으로 포맷함
  • @lightwhale-data, @lightwhale-state, @lightwhale-state-snapshots 서브볼륨을 생성함

• 마운트와 overlay 구성

  • data filesystem이 있으면 @lightwhale-data를 /mnt/lightwhale-data에 마운트하고, 없으면 tmpfs를 대신 마운트함
  • 불변 하위 레이어는 /etc를 /run/lightwhale/overlay/lower/etc에 바인드 마운트하고, 루트 파일시스템 디렉터리 트리를 미러링해 준비함
  • 쓰기 가능한 상위 레이어는 /mnt/lightwhale-data/lightwhale-state/overlay/upper/etc 같은 경로에 준비함
  • 이후 overlayfs로 두 레이어를 합쳐 /etc에 마운트하고, 같은 방식을 /var, /home에도 반복함

제약과 FAQ 핵심

• 지원 하드웨어는 x86-64 전용이며 BIOS와 EFI를 모두 지원함
• Raspberry Pi는 현재 지원하지 않으며, backlog에 올라가 있음
• Apple M-series는 베어메탈로 지원하지 않지만, 가상화 실행은 가능함
• VMWare/ESX/Proxmox/cloud 같은 가상 환경에서 실행 가능하며, QEMU/KVM과 VMware ESXi용 게스트 에이전트를 포함함
• 소프트웨어는 Docker 컨테이너만 설치 가능하며, 루트 파일시스템에 직접 설치하는 방식은 불가능함
• 코어 시스템은 불변이지만, 설정·커스터마이징·컨테이너 데이터는 기본적으로 메모리에 기록되고 영속성을 켤 때만 재부팅 뒤에도 유지됨
• 기본 호스트명에는 네트워크 충돌 방지를 위해 machine ID가 포함되며, setup-hostname으로 변경하면 현재 셸을 제외하고 즉시 반영됨
• 보증은 없으며, 사용 결과에 대한 책임은 사용자에게 있음
• 루트 파일시스템에 wget, nano 같은 선호 도구를 추가하는 방향은 지향하지 않으며, 목적 특화 최소 서버 OS라는 제약을 유지함
• 프라이버시 정책 TL;DR로는 개인 데이터를 수집하지 않으며, 텔레메트리에 동의한 경우에만 익명 데이터를 수집하고 그 내용도 검토 가능함
• 연령 관련 규제 준수는 OS 자체가 아니라, 그 위에 배포하는 사용자 서비스의 책임으로 둠

관련 링크

• Download
• ChangeLog
• Source
• Issues

[GN⁺]

Hacker News 의견들

• 뭔가를 실제로 출시한 건 축하할 일인데, 왜 굳이 이걸 써야 하는지는 아직 잘 안 보임
  Flatcar Container Linux, Fedora CoreOS, Talos Linux, IncusOS처럼 비슷한 목표를 가진 대안들이 이미 있고, 커뮤니티나 상업적 후원도 더 탄탄해 보임
  무엇이 다른지 더 분명하게 설명해줘야 납득될 듯함

  • IncusOS를 홈랩에서 쓰고 있는데, 설정과 사용 경험이 정말 좋음
    Proxmox에서 옮겨와서 VM 전부를 관리하고 있고, 코딩 어시스턴트를 적극 써서 IncusOS CLI 설정 자동화, Docker-Compose 이미지를 Incus로 변환, --dangerously-skip-permissions를 써도 부담 없게 새 컨테이너 띄우는 bash 스크립트 작성 같은 걸 처리함
    가장 좋은 점은 declarative 파일로 관리할 수 있어서 네트워크 구성이나 리소스 설정이 항상 눈에 잘 들어온다는 점임
    비슷한 용도라면 IncusOS를 한 번 봐볼 만함
  • 저런 도구들은 보통 설정에 몇 시간씩 걸리는데, 이건 그냥 부팅하면 바로 돌아간다는 차이가 있음

• 소프트웨어가 있는 한 유지보수를 건너뛸 수는 없음
  버그 없는 건 없고, 업그레이드나 패치, 관리가 전혀 필요 없다고 말하면 결국 침해된 시스템으로 가는 지름길이 되기 쉬움

  • 이 OS가 유지보수 불필요하다고 말하는 건 아님
    전통적인 베이스 시스템에서 신경 써야 할 유지보수 상당수를 줄여준다는 쪽에 가깝고, 이유는 1) 깔린 게 거의 없고 2) 베이스 업그레이드가 쉬워서 재부팅하고 컨테이너만 다시 올리면 되기 때문임
    당연히 그 위에서 돌리는 소프트웨어는 업그레이드가 필요하지만, Docker 기반이면 그 레이어는 대개 다른 쪽에서 관리해주니 새 컨테이너를 받아 다시 시작하면 되고, OS는 데이터가 같은 위치에 붙도록 보장하는 역할에 가까움
    모든 소프트웨어를 Docker로 돌리는 게 괜찮다면 Debian이나 Redhat보다 한 단계 나아간 선택처럼 보이고, CoreOS보다 절차적 복잡성도 덜함
    실제로 얼마나 쓰기 편한지는 특히 스토리지 관리 쪽이 조금 의문이지만, 적어도 무엇을 팔고 싶은지는 아주 명확함
  • 이 얘기는 몇 년째 해오고 있음
    셀프 호스팅은 가능하지만, 근무 시간 외의 여가에도 사실상 SLA를 떠안게 됨
    그래서 사용자 수가 1명을 넘는 건 오래전에 다 치워버렸음
  • 물론 완전히 버그 없는 건 없음
    그래도 Talos 같은 프로젝트가 존재하는 데는 이유가 있음
    터미널도 없고, SSH도 없고, 패키지 매니저도 없고, 읽기 전용 파일시스템에 systemd도 빼고, 실행 파일 수도 최소화하면 공격 표면은 분명 줄어듦
    여기 나온 프로젝트 자체를 말하는 건 아니지만, 더 안전하면서 유지보수도 덜 필요한 시스템은 실제로 존재함
    어차피 100% 안전할 수 없으니 최근 3분 전에 수정된 npm 패키지도 YOLO로 받아들이자는 식으로 가는 건 답이 아님

• 흥미롭긴 한데 패치, 업그레이드, 그리고 자체 ISO 빌드는 어떻게 하는지 궁금함
  소스 저장소를 봐도 그 부분은 거의 드러나지 않음

  The actual repository here hosts the source code for Lightwhale, and is not of any interest for most people.

  https://bitbucket.org/asklandd/lightwhale/src/master/

  • 저장소가 오래된 상태로 보임
    마지막 커밋이 2년 전이고, 3.0 버전 소스는 없는 듯함

• 이건 OS가 아니라 Linux distro 아님?

  • Linux distro가 아니면 뭐가 OS인지 되묻고 싶음

• 이 분야는 초보에 가깝다고 느끼는데, 셀프 호스팅은 10년 넘게 했고 2019년쯤부터는 Unraid로 옮겨감
  웹 포털 중심이라 다루기 쉽고 유지보수도 편했음
  이 홈 서버 OS는 어떻게 상호작용하는지 궁금함
  사이트에 그림이 없는 걸 보면 전부 터미널 기반으로 다뤄야 하는 건가 싶음

• 방금 Ubuntu Server에 Docker를 한 줄로 깔고 바로 쓰기 시작했는데, 여기서 정확히 뭐가 다른지, 가치 제안이 뭔지 잘 모르겠음
  말하는 유지보수가 구체적으로 무엇을 뜻하는지도 궁금하고, 덜 강한 하드웨어에서 돌리려고 더 슬림하게 만든 서버인지도 궁금함
  홈 서버 세팅을 막 시작한 입장이라 어떤 이점이 있는지 순수하게 알고 싶음

  • 나도 똑같이 함
    immutable 방식의 장점은 업데이트에 있다고들 하는데, 새 이미지 버전으로 갔다가 문제가 생기면 이전 버전으로 그냥 부팅해 되돌릴 수 있음
    하지만 기능적으로는 나도 Ubuntu Server면 충분하다고 느낌
    1년에 몇 번 apt update와 업그레이드만 하고, 로컬 전용에 Tailscale로만 접근함
    이런 immutable OS는 홈 서버보다 노트북이나 데스크톱에서 더 매력적으로 느껴짐
    홈 디렉터리만 쓰기 가능하니 OS가 더 안정적이고 쉽게 망가지지 않는다는 기대가 있음

• Lightwhale에서 돌리는 컨테이너 데이터는 정기적으로 어떤 방식으로 백업하는 게 권장되는지 궁금함

• 잘 모르겠음
  그냥 Docker만 돌릴 건데 왜 immutable이 필요한지 모르겠고, 몇 분이면 Docker를 올릴 수 있는 Debian이나 Ubuntu 대신 왜 특수한 Debian 변형이 필요한지도 모르겠음
  유지보수도 원래 배포판 저장소나 공식 Docker 저장소를 패키지 매니저로 관리하면 되는 일 아닌가 싶음
  이런 immutable 유행은 좀 사라졌으면 하고, flatpak이나 snap도 마찬가지라고 봄
  Linux는 이미 이런 솔루션들이 해결하겠다는 걸 원래부터 해왔음
  사용자는 root 없이는 베이스 시스템을 못 건드리고, 애플리케이션은 의존성을 /usr/lib에 깔면 됨

  • 나한테는 Debian stable에 podman/Docker 조합이면 충분히 immutable함
    막히는 일이 생겨도 도움받기 쉬운 게 큰 보험이기도 함
    더 작게 만들 수는 있겠지만, 이미 저사양 BananaPi나 저가형 RISC-V 같은 이상한 하드웨어에서도 잘 돌아가니 다른 걸 원할 이유가 잘 안 생김

• 이런 건 Swarm mode 클러스터에 꽤 잘 맞을 것 같음
  홈 서버에만 초점을 맞춘 건지는 모르겠지만 계속 지켜볼 생각임
  프로젝트도 아주 좋아 보임

  • 지금은 사람들이 가장 부담 없이 시도하는 영역이 홈 서버라서 그쪽으로만 알리고 있음
    하지만 Lightwhale은 이미 프로덕션에서 돌고 있고, Swarm 클러스터 용도로도 아주 잘 맞음

• 엄청 깔끔해 보임
  초보자 입장에서는 설정을 망가뜨리지 않게 해주는 이런 접근이 딱 필요해서 꼭 써볼 생각임