루트 파일 시스템 (Root Filesystem) / 오버레이 파일 시스템 (OverlayFS)

핵심 인사이트 (3줄 요약)

본질: 루트 파일 시스템 (Rootfs)은 운영체제 커널이 부팅 시 가장 먼저 마운트하는 최상위 디렉토리 구조이며, 오버레이 파일 시스템 (OverlayFS)은 여러 디렉토리를 하나의 가상 디렉토리로 통합하여 보여주는 유니온 마운트 (Union Mount) 기술이다.

가치: 컨테이너 환경에서 읽기 전용 이미지 레이어와 쓰기 가능한 컨테이너 레이어를 결합하여, 스토리지 용량을 효율적으로 절감하고 복사 시점 쓰기 (CoW: Copy-on-Write) 메커니즘을 통해 빠른 컨테이너 생성을 가능케 한다.

융합: 도커 (Docker)의 스토리지 드라이버 표준으로 자리 잡았으며, 임베디드 시스템의 펌웨어 업데이트, 라이브 CD 실행 환경 등 읽기 전용 매체와 가변 데이터를 결합해야 하는 다양한 운영체제 설계 영역에서 핵심 아키텍처로 활용된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 루트 파일 시스템 (Rootfs: Root Filesystem)은 /bin, /etc, /lib 등 시스템 동작에 필수적인 최소한의 디렉토리와 파일을 포함하는 초기 파일 시스템이다. 리눅스 부팅 과정에서 커널은 VFS (Virtual File System)를 통해 루트 장치를 마운트하여 사용자 공간 (User Space)을 초기화한다. 오버레이 파일 시스템 (OverlayFS)은 서로 다른 두 개 이상의 파일 시스템 계층을 겹쳐서 사용자에게는 하나의 통합된 뷰를 제공하는 특수 파일 시스템이다.
필요성: 기존의 단일 파일 시스템 구조에서는 동일한 실행 환경을 가진 100개의 인스턴스를 띄울 때 100배의 저장 공간이 필요했다. 또한 이미지 수정 시 원본 데이터를 건드리지 않으면서 변경 사항만 추적해야 하는 요구가 발생했다. OverlayFS는 공통 데이터는 공유하고 변경된 부분만 별도 계층에 저장함으로써 스토리지 효율성과 격리성을 동시에 확보한다.
💡 비유: OverlayFS는 "투명한 아세테이트 필름지를 겹쳐 놓은 것"과 같다. 맨 아래에는 배경 그림(읽기 전용 이미지)이 있고, 그 위에 투명한 필름(쓰기 가능 레이어)을 올려서 펜으로 덧칠하는 식이다. 위에서 보면 하나의 완성된 그림으로 보이지만, 필름만 걷어내면 원본 배경은 그대로 유지된다.
등장 배경:
1. AUFS (Advanced Multi-Layered Unification Filesystem)의 복잡성: 기존 유니온 파일 시스템의 성능 한계와 복잡한 코드 관리 문제.
2. 컨테이너 기술의 폭발적 성장: 수천 개의 컨테이너가 동일한 베이스 이미지를 효율적으로 공유해야 하는 기술적 요구.
3. 커널 메인라인 통합 필요성: 외부 모듈이 아닌 리눅스 커널 표준 드라이버로서의 안정적인 스토리지 스택 확보.

일반적인 루트 파일 시스템의 구조와 OverlayFS가 적용된 계층 구조의 차이를 시각화하면 다음과 같다. OverlayFS는 물리적으로 분리된 디렉토리들을 논리적으로 통합한다.

  ┌───────────────────────────────┐      ┌───────────────────────────────────┐
  │     일반 루트 파일 시스템      │      │      OverlayFS 계층 구조         │
  ├───────────────────────────────┤      ├───────────────────────────────────┤
  │ / (root)                      │      │ [Merged View] (통합 가상 뷰)      │
  │  ├── bin/                     │      │       /bin, /etc, /tmp ...        │
  │  ├── etc/                     │      ├───────────────────────────────────┤
  │  ├── lib/                     │      │ [Upper Dir] (쓰기 가능 계층)      │
  │  └── var/                     │      │       새로운 파일, 수정본         │
  │                               │      ├───────────────────────────────────┤
  │ (모든 데이터가 단일 파티션 내)   │      │ [Lower Dir] (읽기 전용 계층)   │
  │ (수정 시 원본 데이터 직접 변경)  │      │       OS 기본 파일, 라이브러리 │
  └───────────────────────────────┘      └───────────────────────────────────┘

[다이어그램 해설] 일반적인 루트 파일 시스템은 단일 블록 장치 위에 모든 파일이 물리적으로 존재하며, 파일 수정 시 원본 데이터 블록이 직접 갱신된다. 반면 OverlayFS 구조는 하위 계층 (Lower Dir)과 상위 계층 (Upper Dir)으로 분리된다. 하위 계층은 읽기 전용 (Read-only)으로 유지되어 여러 인스턴스가 안전하게 공유할 수 있으며, 모든 데이터 변경(생성, 수정, 삭제)은 상위 계층인 쓰기 가능 계층 (Writable Layer)에서만 일어난다. 사용자나 애플리케이션은 이 두 계층이 합쳐진 Merged View를 통해 일반적인 파일 시스템처럼 접근하지만, 커널 내부적으로는 읽기 전용 계층을 보호하면서도 동적인 데이터 쓰기를 지원하는 고도의 추상화를 수행한다.

📢 섹션 요약 비유: 원본 책(Lower) 위에 투명 필름(Upper)을 씌워 놓고 글자를 고치거나(CoW) 메모를 추가하면, 독자(User)는 고쳐진 책을 보지만 원본 책은 전혀 손상되지 않는 것과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

구성 요소

요소명	역할	내부 동작	관련 기술	비유
Lower Directory	기반이 되는 불변 데이터	읽기 전용 접근만 허용, 여러 개 적층 가능	Read-only Bind Mount	수정 불가능한 원본 서류
Upper Directory	데이터 변경 사항 저장소	파일 생성, 수정, 삭제 시 변경 분을 저장	Read-Write Layer	포스트잇 메모지
Merged Directory	사용자에게 노출되는 통합 뷰	Lower와 Upper를 합성하여 단일 경로로 제공	Union Mount, VFS	합쳐진 스캔 결과물
Work Directory	쓰기 작업용 임시 공간	원자적(Atomic) 연산을 위해 내부적으로 사용	Whiteout, O_TMPFILE	임시 작업용 책상
Whiteout File	파일 삭제 상태를 표현	하위 계층 파일이 삭제되었음을 알리는 특수 노드	Character Device (c 0:0)	삭제 도장

OverlayFS 마운트 및 레이어 합성 원리

OverlayFS는 마운트 시 lowerdir, upperdir, workdir 옵션을 지정하여 동작한다. 동일한 파일이 양쪽 레이어에 모두 존재할 경우, 상위 레이어의 파일이 하위 레이어의 파일을 덮어쓰는(Shadowing) 방식으로 동작한다.

  ┌───────────────────────────────────────────────────────────────┐
  │                 OverlayFS Mount & Layering                    │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │   [Merged View] :  File A(v2),  File B,  File C(v1)           │
  │           ▲              ▲               ▲                    │
  │           │              │               │                    │
  │   ┌───────┴────────┐     │       ┌───────┴────────┐           │
  │   │  Upper Layer   │     │       │  Lower Layer   │           │
  │   │  (File A v2)   │     │       │  (File A v1)   │           │
  │   │  (File B-new)  │     │       │  (File C v1)   │           │
  │   └────────────────┘     │       └────────────────┘           │
  │           │              │               │                    │
  │           └───────────┐  │  ┌────────────┘                    │
  │                       │  │  │                                 │
  │                    [OverlayFS Driver]                         │
  │                                                               │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 위 도식에서 File A는 하위(v1)와 상위(v2) 레이어에 모두 존재한다. OverlayFS는 이름이 충돌할 경우 상위 계층의 파일을 우선적으로 선택하여 Merged View에 노출시킨다. File B는 상위 레이어에만 존재하므로 새로 추가된 파일로 인식되며, File C는 하위 레이어에만 존재하므로 원본 그대로 노출된다. 이 매커니즘을 통해 사용자는 여러 레이어의 상태가 합쳐진 최종 상태를 단일 루트 파일 시스템처럼 사용할 수 있다. 도커 이미지를 빌드할 때 나타나는 Layer ID들은 물리적으로는 각각의 lowerdir에 해당하며, 컨테이너가 실행되는 순간 하나의 upperdir이 생성되어 전체가 유니온 마운트된다.

복사 시점 쓰기 (CoW: Copy-on-Write) 메커니즘

하위 계층(읽기 전용)에 있는 파일을 수정하려고 시도하면, 커널은 즉시 해당 파일을 상위 계층으로 복사한 뒤 수정을 진행한다. 이를 복사 시점 쓰기 (CoW: Copy-on-Write)라고 하며, 파일 전체를 복사하는 비용이 발생하므로 대용량 파일 수정 시 주의가 필요하다.

  ┌────────────────── OverlayFS CoW 동작 프로세스 ─────────────────────┐
  │                                                                    │
  │  1. [Open Request] : 사용자가 'file.txt' (Lower에 존재) 열기       │
  │  2. [Search] : Upper에 파일이 있는지 확인 (없음)                   │
  │  3. [Trigger CoW] : 쓰기 권한 요청 시 하위 파일을 상위로 복사      │
  │                                                                    │
  │     [Lower Layer]               [Upper Layer]                      │
  │     ┌───────────┐               ┌───────────┐                      │
  │     │ file.txt  │ ──(Copy)────▶ │ file.txt  │ (새로운 Inode)       │
  │     └───────────┐               └───────────┘                      │
  │                                       │                            │
  │  4. [Write] : 상위 계층에 복사된 파일 내용을 수정 및 저장          │
  │  5. [Completion] : 이후 모든 접근은 상위 계층의 파일을 사용        │
  │                                                                    │
  └────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] CoW 메커니즘은 데이터 무결성을 보장하는 핵심 원리다. 하위 계층은 실제 물리적으로 read-only 마운트되어 있거나 권한이 제한되어 있어 직접 수정이 불가능하다. 수정 요청이 들어오는 즉시 커널은 ① 하위 계층에서 파일을 읽고, ② 상위 계층에 동일한 이름의 파일을 생성한 뒤, ③ 내용을 기록한다. 이 과정은 애플리케이션 입장에서는 투명하게(Transparent) 일어나지만, 내부적으로는 원본 파일의 크기만큼 디스크 쓰기 오버헤드와 Inode 생성이 발생한다. 따라서 로그 파일과 같이 변경이 잦은 데이터는 OverlayFS 내부가 아닌 외부 볼륨(Volume)에 저장하는 것이 성능 최적화의 핵심이다. 파일 삭제 시에는 상위 계층에 Whiteout이라는 특수 파일을 만들어 하위 계층의 파일이 보이지 않도록 마스킹한다.

📢 섹션 요약 비유: 도서관 책(Lower)에 낙서를 하고 싶을 때, 도서관장이 해당 페이지를 복사(CoW)해서 내준 뒤 그 복사본(Upper)에 낙서하게 하는 것과 같습니다. 원본 책은 항상 깨끗하게 유지됩니다.

Ⅲ. 융합 비교 및 다각도 분석

스토리지 드라이버 기술 비교: OverlayFS vs Devicemapper vs Btrfs

비교 항목	OverlayFS	Devicemapper	Btrfs / ZFS
구현 방식	파일 수준 유니온 마운트	블록 수준 스냅샷	파일 시스템 자체 기능
메모리 효율	매우 높음 (Page Cache 공유)	중간	높음
속도 (I/O)	빠름 (네이티브 성능 근접)	상대적으로 느림	파일 시스템 종속적
CoW 단위	파일 단위 (전체 복사)	블록 단위 (64KB 등)	익스텐트/블록 단위
안정성	리눅스 커널 표준 (권장)	복잡한 설정 필요	특정 배포판 위주

OverlayFS의 가장 큰 장점은 페이지 캐시 (Page Cache) 공유 능력이다. 블록 기반인 Devicemapper는 동일한 파일을 가진 컨테이너 100개가 실행될 때 각각 메모리에 데이터를 올리지만, OverlayFS는 호스트 커널의 페이지 캐시를 공유하므로 메모리 사용량이 혁신적으로 줄어든다.

OS 부팅과 루트 파일 시스템 (Initrd/Initramfs 융합)

루트 파일 시스템이 마운트되기 전, 커널은 메모리에 임시 파일 시스템인 initramfs를 올려 필요한 드라이버를 로드한다. 이후 실제 디스크의 rootfs로 제어권을 넘기는 과정에서 pivot_root나 switch_root가 수행된다.

  ┌─────────────────────────────────────────────────────────────────┐
  │              Linux Booting & Rootfs Transition                  │
  ├─────────────────────────────────────────────────────────────────┤
  │                                                                 │
  │  [Bootloader] ──▶ [Kernel Image Load] ──▶ [Initramfs Load]      │
  │                                                │                │
  │  ┌─────────────────────────────────────────────▼──────────┐     │
  │  │ Temporary Rootfs (Memory) : 드라이버 로드, 네트워크 설정 │   │
  │  └─────────────────────────────────────────────┬──────────┘     │
  │                                                │                │
  │  [Pivot Root] : 임시 Rootfs -> 실제 HDD/SSD Rootfs로 변경       │
  │                                                │                │
  │  ┌─────────────────────────────────────────────▼──────────┐     │
  │  │ Real Rootfs (Disk) : /sbin/init 실행, 시스템 서비스 시작 │   │
  │  └────────────────────────────────────────────────────────┘     │
  │                                                                 │
  └─────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 리눅스 부팅의 핵심은 "닭이 먼저냐 달걀이 먼저냐" 문제를 해결하는 것이다. 디스크에서 파일을 읽으려면 파일 시스템 드라이버가 필요한데, 그 드라이버는 파일 시스템 안에 들어있다. 이를 해결하기 위해 부트로더는 커널과 함께 최소한의 환경이 담긴 initramfs (Initial RAM Filesystem)를 메모리에 미리 로드한다. 커널은 메모리상의 이 임시 루트 파일 시스템을 먼저 사용하며 실제 디스크를 읽을 준비를 마친 뒤, pivot_root 시스템 콜을 통해 실제 디스크의 파티션을 /로 승격시킨다. 도커 컨테이너 실행 시에도 이와 유사하게 컨테이너 전용의 rootfs를 구성한 뒤 chroot나 pivot_root를 호출하여 격리된 파일 시스템 환경을 제공한다.

📢 섹션 요약 비유: 부팅 과정은 마치 캠핑장에서 텐트를 치기 위해 먼저 배낭 속의 작은 망치(Initramfs)를 꺼내 쓰는 것과 같으며, 텐트가 다 지어지면 큰 집(Real Rootfs)으로 이사하는 과정입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오 및 최적화 전략

시나리오 — 대용량 데이터베이스 파일의 컨테이너 내 수정: 데이터베이스 서버를 도커로 실행하면서 10GB 크기의 데이터 파일을 컨테이너 레이어 내부에서 수정할 때, 갑자기 디스크 용량이 부족해지고 I/O 지연이 급증하는 현상.
- 판단: 이는 OverlayFS의 파일 단위 CoW 때문이다. 10GB 파일 중 단 1바이트만 고쳐도 10GB 전체가 상위 레이어로 복사된다.
- 대책: 빈번한 수정이나 대용량 파일은 Docker Volume을 사용하여 OverlayFS 계층을 우회(Bypass)하도록 설계해야 한다.
시나리오 — 많은 수의 작은 파일 생성 시 Inode 고갈: 웹 애플리케이션이 임시 파일을 수백만 개 생성하면서 디스크 용량은 남았는데 파일 생성이 안 되는 경우.
- 판단: OverlayFS는 각 파일마다 Inode를 소모하며, 특히 복잡한 레이어 구조에서는 Inode 관리가 병목이 될 수 있다.
- 대책: 호스트 파일 시스템 포맷 시 Inode 밀도를 높게 설정하거나, 임시 파일 전용의 tmpfs를 마운트하여 메모리에서 처리하도록 유도한다.

도입 체크리스트 및 안티패턴

  ┌───────────────────────────────────────────────────────────────────┐
  │               OverlayFS Operational Checklist                     │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   1. [커널 버전] : 리눅스 커널 3.18 이상 (4.x 이상 권장)인가?     │
  │   2. [레이어 수] : 이미지 레이어가 127개(기본 한계)를 넘는가?     │
  │   3. [I/O 특성] : 랜덤 쓰기가 잦은 워크로드인가? (볼륨 권장)      │
  │   4. [공유 여부] : 여러 컨테이너가 동일 파일을 공유하는가?        │
  │                                                                   │
  │   [안티패턴]                                                      │
  │   - OverlayFS 계층 내부에서 로그 파일 생성 및 갱신                │
  │   - 깊은 레이어 구조 (Lowerdir가 너무 많으면 파일 검색 지연)      │
  │   - NFS와 같은 네트워크 파일 시스템 위에 OverlayFS 구축 시도      │
  │                                                                   │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] OverlayFS 운영 시 가장 흔한 실수는 "모든 것을 컨테이너 안에 저장하려는 관성"이다. OverlayFS는 불변성(Immutability)을 전제로 한 공유 기술이지, 고성능 쓰기 전용 저장소가 아니다. 파일 검색 시 상위 레이어부터 하위 레이어로 순차 탐색하므로 레이어가 너무 깊어지면 stat() 시스템 콜 성능이 저하된다. 또한 하드 링크(Hard Link) 처리에 있어 레이어 간 제약이 있으므로 복잡한 링크 구조를 가진 애플리케이션은 검증이 필요하다. 실무에서는 이미지 최적화(Layer flattening)를 통해 레이어 수를 줄이고, 가변 데이터는 볼륨으로 분리하는 전략이 필수적이다.

📢 섹션 요약 비유: 그림을 그릴 때 너무 많은 필름지를 겹치면 아래 그림이 흐릿하게 보이고 찾기 힘든 것처럼, 적절한 레이어 수 관리가 성능의 핵심입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	도입 전 (전통적 방식)	도입 후 (OverlayFS)	기대 효과
스토리지 사용량	인스턴스 개수만큼 정비례 증가	베이스 이미지 공유로 최소화	70~90% 절감
메모리(RAM) 효율	인스턴스마다 중복 로드	페이지 캐시 공유 가능	메모리 집적도 3배 향상
컨테이너 가동 시간	파일 시스템 복제 시간 필요	즉시 마운트 및 실행	배포 가속화

미래 전망

Erofs (Enhanced Read-Only File System): 안드로이드 등에서 사용되는 초고속 읽기 전용 파일 시스템과 OverlayFS의 결합을 통해 컨테이너 시작 성능을 극대화하려는 시도가 활발하다.
Lazy Pulling 기술: 컨테이너 실행 시 전체 이미지를 받지 않고, OverlayFS가 필요한 파일만 네트워크를 통해 실시간으로 긁어오는 Stargz 등의 기술이 클라우드 네이티브의 핵심이 될 것이다.

결론적으로 Rootfs와 OverlayFS는 현대 클라우드 인프라의 "유연성"을 담보하는 핵심 기둥이다. 엔지니어는 파일 시스템의 물리적 한계를 이해하고, CoW의 오버헤드를 회피하는 설계를 통해 안정적이고 빠른 시스템을 구축해야 한다.

📢 섹션 요약 비유: 모든 사람에게 똑같은 책을 한 권씩 사주는 대신, 도서관의 책을 같이 보게 하되 메모만 각자의 수첩에 하게 하는 효율적인 지식 공유 시스템을 만든 것과 같습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
VFS (Virtual File System)	서로 다른 파일 시스템을 동일한 인터페이스로 다룰 수 있게 하는 커널 계층.
CoW (Copy-on-Write)	데이터 수정 시 복사본을 만들어 원본을 보호하는 메커니즘.
Chroot / Pivot_root	프로세스의 루트 디렉토리를 변경하여 파일 시스템 격리를 구현하는 기술.
Tmpfs	메모리에 파일을 저장하는 파일 시스템으로 OverlayFS의 성능 보조 수단으로 사용.
Initramfs	부팅 초기 단계에서 루트 파일 시스템 마운트를 준비하는 임시 램 디스크.

👶 어린이를 위한 3줄 비유 설명

루트 파일 시스템은 컴퓨터가 켜질 때 가장 먼저 열어보는 "시스템 가방" 같은 거예요. 그 안에는 컴퓨터가 움직이는 데 꼭 필요한 도구들이 들어있죠.
오버레이 파일 시스템은 **"투명 스티커"**와 같아요. 원래 있던 그림(이미지) 위에 투명 스티커(컨테이너 레이어)를 붙여서 글씨를 써도, 스티커만 떼면 원래 그림은 깨끗하게 남아요.
이 기술 덕분에 똑같은 프로그램을 수백 개 실행해도 컴퓨터 용량을 아주 조금만 사용하면서도 각자 자기만의 낙서를 할 수 있게 되었답니다.