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

> Clean Markdown view of GeekNews topic #28916. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28916](https://news.hada.io/topic?id=28916)
- GeekNews Markdown: [https://news.hada.io/topic/28916.md](https://news.hada.io/topic/28916.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-27T06:39:26+09:00
- Updated: 2026-04-27T06:39:26+09:00
- Original source: [lightwhale.asklandd.dk](https://lightwhale.asklandd.dk/)
- Points: 2
- Comments: 1

## Topic Body

- **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 다운로드](https://lightwhale.asklandd.dk/download/lightwhale-latest-x86.iso) 또는 [다운로드 섹션](https://lightwhale.asklandd.dk/download)에서 이미지를 받아 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](https://bitbucket.org/asklandd/lightwhale/src/be46fe51a6346fb732d38e32de8965788bfbbaa6/custom/rootfs-overlay/lib/lightwhale/setup-persistence?at=3.0.0%2Fdev)는 `/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](https://bitbucket.org/asklandd/lightwhale/issues/29/make-lightwhale-for-raspberry-pi)에 올라가 있음
- Apple M-series는 베어메탈로 지원하지 않지만, **가상화 실행**은 가능함
- VMWare/ESX/Proxmox/cloud 같은 가상 환경에서 실행 가능하며, QEMU/KVM과 VMware ESXi용 게스트 에이전트를 포함함
- 소프트웨어는 **Docker 컨테이너만 설치 가능**하며, 루트 파일시스템에 직접 설치하는 방식은 불가능함
- 코어 시스템은 불변이지만, 설정·커스터마이징·컨테이너 데이터는 기본적으로 메모리에 기록되고 영속성을 켤 때만 재부팅 뒤에도 유지됨
- 기본 호스트명에는 네트워크 충돌 방지를 위해 machine ID가 포함되며, `setup-hostname`으로 변경하면 현재 셸을 제외하고 즉시 반영됨
- 보증은 없으며, 사용 결과에 대한 책임은 사용자에게 있음
- 루트 파일시스템에 `wget`, `nano` 같은 선호 도구를 추가하는 방향은 지향하지 않으며, **목적 특화 최소 서버 OS**라는 제약을 유지함
- 프라이버시 정책 TL;DR로는 개인 데이터를 수집하지 않으며, 텔레메트리에 동의한 경우에만 [익명 데이터](https://bitbucket.org/asklandd/lightwhale/src/1866a427543fff943f65d6ba580d61d46f1d6da2/custom/rootfs-overlay/usr/share/lightwhale/TELEMETRY-PRIVACY?at=3.0.0%2Fdev)를 수집하고 그 내용도 검토 가능함
- 연령 관련 규제 준수는 OS 자체가 아니라, 그 위에 배포하는 **사용자 서비스의 책임**으로 둠

### 관련 링크
- [Download](https://lightwhale.asklandd.dk/download)
- [ChangeLog](https://bitbucket.org/asklandd/lightwhale/raw/d6517c5a3578e3ad58aed9b3debe3c179595f436/custom/rootfs-overlay/usr/share/lightwhale/CHANGELOG)
- [Source](https://bitbucket.org/asklandd/lightwhale/src)
- [Issues](https://bitbucket.org/asklandd/lightwhale/issues)

## Comments



### Comment 56346

- Author: neo
- Created: 2026-04-27T06:39:27+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47896163) 
- 뭔가를 **실제로 출시**한 건 축하할 일인데, 왜 굳이 이걸 써야 하는지는 아직 잘 안 보임  
  **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/](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 클러스터** 용도로도 아주 잘 맞음

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