Compute Platforms - 02. 서버 부팅 과정

전원 버튼부터 systemd까지 — 서버가 켜지는 30초의 비밀

AWS EC2 콘솔에서 "Launch Instance" 버튼을 누르면, 상태가 Pending에서 Running으로 바뀌는 데 보통 30초에서 1분이 걸린다. 클라우드를 쓰는 대부분의 사람은 "서버가 만들어지는 중이겠지"라고 넘긴다. 하지만 그 30초 안에는 정교한 일련의 과정이 일어난다 — 전원이 인가되고, 메인보드의 펌웨어가 하드웨어를 검사하고, 부트로더가 커널 이미지를 메모리에 올리고, initramfs가 루트 파일시스템을 임시로 마운트하고, systemd가 수십 개의 서비스를 병렬로 띄운다. 이 과정을 부팅(booting)이라 부른다. 이걸 이해하지 못하면 — 부팅이 실패했을 때 왜 안 되는지, 부팅 시간을 왜 줄여야 하는지, 클라우드가 "인스턴스 만들기"에 왜 30초나 쓰는지를 알 수 없다.

2017년 2월 28일, AWS us-east-1 리전의 S3 장애로 수만 개의 서비스가 멈췄다. 복구 과정에서 많은 인스턴스가 재부팅됐다. 이때 부팅 시간이 곧 서비스 복구 시간이었다. 만약 한 인스턴스가 부팅에 2분씩 걸렸다면, 만 대를 순차 재부팅하면 2만 분(약 2주)이 걸린다. 실제로는 병렬 부팅과 Nitro 시스템 최적화로 수시간 만에 복구됐지만 — 그날 부팅 시간의 중요성이 업계에 다시 각인됐다. foundations 02에서 본 RTO(복구 시간 목표)가 부팅 시간의 하한을 정한다는 걸 떠올리자. RTO 30초를 목표로 하면, 부팅 자체가 이미 30초라면 그 목표는 달성 불가능하다.

이 글은 서버가 켜지는 30초 안에 일어나는 일들을 단계별로 파헤친다. 전원 버튼부터 systemd가 서비스를 띄울 때까지. 각 단계가 왜 필요하고, 어떻게 망가지고, 어떻게 빠르게 만드는지. 그리고 클라우드 인스턴스가 왜 가상 머신임에도 부팅에 시간이 걸리는지.

부팅의 전체 흐름 — 여섯 단계

부팅은 대략 여섯 단계로 나뉜다. 각 단계는 다음 단계로 제어를 넘긴다.

flowchart TD
    PWR["1. 전원 인가<br/>(Power button)"] --> FW["2. 펌웨어<br/>(UEFI 또는 BIOS)"]
    FW --> BL["3. 부트로더<br/>(GRUB, systemd-boot)"]
    BL --> KR["4. 커널 로드<br/>(vmlinuz + initramfs)"]
    KR --> INIT["5. init 프로세스 (PID 1)<br/>(systemd)"]
    INIT --> SVC["6. 서비스 시작<br/>(nginx, sshd, ...)"]

각 단계는 이전 단계가 만들어 놓은 환경 위에서 동작한다. 펌웨어는 하드웨어 위에서, 부트로더는 펌웨어가 만든 최소 환경 위에서, 커널은 부트로더가 메모리에 올려준 환경에서, systemd는 커널이 만든 프로세스 환경에서. 위층으로 갈수록 추상화 단계가 올라가고, 인프라 엔지니어가 다룰 수 있는 영역이 넓어진다. 펌웨어는 거의 건드릴 수 없지만(제조사가 정함), systemd는 설정 파일로 마음대로 제어할 수 있다. 부팅 튜닝은 보통 4 ~ 6단계에서 이루어진다.

1단계 — 전원 인가와 하드웨어 초기화

전원 버튼을 누르면(또는 클라우드가 가상 전원을 인가하면), 메인보드의 전원 관리 칩이 CPU에 전원을 공급하기 시작한다. CPU는 자체 펌웨어(Microcode, Intel ME, AMD PSP)를 로드하고, 메모리·PCIe 장치를 초기화한다. 이 단계는 수 초가 걸리고, 인프라 엔지니어가 거의 건드릴 수 없는 영역이다. 다만 서버의 BMC(Baseboard Management Controller, IPMI·Redfish)가 이 단계의 상태를 외부에 알려준다 — 베어메탈 프로비저닝 글에서 다시 볼 원격 관리의 출발점이다.

2단계 — 펌웨어 (UEFI vs BIOS)

펌웨어(firmware)는 메인보드에 내장된 소프트웨어로, 하드웨어 초기화를 마친 뒤 부트로더를 찾아 실행한다. 두 가지 세대가 있다.

Legacy BIOS(Basic Input/Output System) — 1980년대 IBM PC에서 시작된 구형 펌웨어. 16비트 리얼 모드로 동작해 1MB 메모리만 인식하고, MBR(Master Boot Record, 디스크 첫 512바이트)에서 부트로더를 찾는다. MBR은 디스크 크기 2TB 한계와 파티션 4개(주 파티션) 제한이 있다. 2010년대 초반까지 널리 쓰였지만, 현재는 레거시.

UEFI(Unified Extensible Firmware Interface) — 2005년 Intel이 발표, 2010년대 중반부터 BIOS를 대체한 현대 펌웨어. 32비트 또는 64비트 모드로 동작해 대용량 메모리를 인식하고, GPT(GUID Partition Table)를 지원해 2TB 이상 디스크와 128개 파티션을 다룬다. 네트워크 부팅(PXE)·Secure Boot(신뢰할 수 없는 부트로더 차단)·Shell·Setup GUI를 기본 제공한다. 2026년 현재 새 서버는 거의 다 UEFI.

UEFI의 작동은 대략 이렇다. POST(Power-On Self-Test)를 돌려 하드웨어를 검사하고(메모리 테스트·PCIe 장치 열거), 부팅 순서(BootOrder 변수)에 따라 부트로더를 찾는다. UEFI는 NVRAM(비휘발성 메모리)에 부팅 설정을 저장하는데 — efibootmgr 명령으로 이 설정을 볼 수 있다. 클라우드 VM의 UEFI는 하이퍼바이저가 흉내 낸 가상 UEFI라, 일부 기능(Secure Boot 등)이 제한적일 수 있다.

3단계 — 부트로더 (GRUB)

부트로더(bootloader)는 디스크에서 커널 이미지를 찾아 메모리에 올리고, 커널 파라미터를 전달하는 프로그램이다. Linux 세계에서는 GRUB(GRand Unified Bootloader)가 사실상 표준이고, 최근에는 systemd-boot도 인기를 끈다. 클라우드 VM은 보통 GRUB을 쓴다.

GRUB의 주된 일은 두 가지다. 첫째, /boot 파티션(또는 /boot 디렉터리)에서 커널 이미지(vmlinuz-*)와 initramfs 이미지(initrd.img-*)를 찾는다. 둘째, 사용자에게 부팅 메뉴를 보여주고(다중 커널이 설치된 경우), 선택된 커널에 전달할 파라미터(cmdline)를 읽는다.

GRUB 설정은 /etc/default/grub(기본 설정)와 /boot/grub/grub.cfg(생성된 설정)에 있다. 사용자가 /etc/default/grub를 편집한 뒤 update-grub(또는 grub2-mkconfig)을 실행하면 grub.cfg가 재생성된다. grub.cfg를 직접 편집하면 안 된다 — 다음 번 update-grub 때 덮어쓰기 때문.

커널 파라미터(kernel cmdline) — 부트로더가 커널에 전달하는 설정값. 부팅 동작을 제어하는 핵심 스위치들이다.

파라미터	의미	사용 사례
root=UUID=...	루트 파일시스템 장치	어디서 루트를 마운트할지
ro	읽기 전용 마운트(초기)	fsck(파일시스템 검사)를 위해
quiet	부팅 메시지 숨김	보통 배포판 기본값
splash	그래픽 부팅 화면	데스크탑용
init=/bin/bash	init 프로세스 대신 bash 실행	복구 모드(긴급)
systemd.unit=rescue.target	rescue 모드로 부팅	단일 사용자 복구
systemd.unit=emergency.target	더 최소 복구 모드	루트 마운트도 안 될 때
nomodeset	그래픽 드라이버 모드 설정 안 함	GPU 문제 회피
console=ttyS0	직렬 콘솔로 로그 출력	클라우드·원격 서버 표준

마지막 console=ttyS0는 클라우드에서 핵심이다. 데이터센터 서버는 보통 물리 모니터가 없고, 직렬 콘솔(serial console)로 부팅 로그를 봅니다. AWS EC2의 "Get System Log"가 이 직렬 콘솔 출력이다.

4단계 — 커널 로드와 initramfs

GRUB이 커널 이미지(vmlinuz-*)를 메모리에 올리고 실행을 넘기면, 커널이 해독돼 동작하기 시작한다. 커널은 다음 순서로 일한다.

1. 커널 압축 해제 — vmlinuz의 z는 압축을 의미. 커널은 압축된 채 디스크에 있고, 메모리에 올라간 뒤 자기 자신을 푼다. 수 초 소요.
2. 하드웨어 초기화 — 커널이 CPU·메모리·PCIe 장치를 다시 검사하고 드라이버를 로드한다. 이때 01 글에서 본 하드웨어들이 커널에 "등록"된다.
3. 루트 파일시스템 마운트 — 커널이 root= 파라미터로 지정된 장치를 마운트해야 한다. 그런데 문제가 있다 — 루트 파일시스템이 NVMe인데 NVMe 드라이버가 커널에 내장(built-in)돼 있지 않고 모듈(module)로 돼 있으면? 모듈은 루트 파일시스템에서 읽어와야 하는데, 루트를 아직 마운트 못 한 상태. 계란-닭 문제다.

이 계란-닭 문제를 푸는 게 initramfs(initial RAM filesystem) 다. initramfs는 부트로더가 커널과 함께 메모리에 올리는 작은 파일시스템(cpio 아카이브). 안에는 최소한의 도구와 드라이버 모듈이 들어 있다. 커널은 initramfs를 임시 루트로 마운트하고, 거기서 필요한 드라이버를 로드한 뒤, 진짜 루트 파일시스템을 마운트하고 pivot_root로 전환한다. 전환 뒤엔 initramfs는 메모리에서 해제된다.

initramfs가 없으면 — 특정 하드웨어(소프트웨어 RAID·LUKS 디스크 암호화·NFS 루트)에서 부팅이 안 된다. 배포판은 mkinitramfs·dracut 같은 도구로 initramfs를 자동 생성한다. 다만 새 하드웨어 드라이버를 설치하면 initramfs를 다시 만들어야 한다 — 안 그러면 부팅 시 "루트를 못 찾겠다"며 커널 패닉(kernel panic)이 난다. 이 함정은 아래 진단 표에서 다시 본다.

5단계 — init 프로세스 (PID 1)

커널이 루트 파일시스템을 마운트하고 나면, 첫 번째 사용자 공간 프로세스를 실행한다. 이 프로세스는 PID 1을 갖고, 모든 다른 프로세스의 조상이 된다. 전통적으로 이 자리는 init이었다.

init의 세대교체 — sysvinit(1980년대~2010년대)는 /etc/inittab과 런레벨(runlevel) 기반으로 직렬 실행했다. 부팅이 느렸다 — 서비스 하나씩 차례로 시작. Upstart(Ubuntu, 2006 ~ 2014)가 이벤트 기반으로 병렬화를 시도했고, systemd(Lennart Poettering, 2010년 발표)가 오늘날 사실상 표준이 됐다. systemd는 서비스 의존성 그래프를 분석해 최대한 병렬로 서비스를 시작하고, 부팅 시간을 획기적으로 줄였다.

2026년 현재 대부분의 Linux 배포판(Ubuntu·RHEL·Rocky·Debian·SUSE)이 systemd를 기본 init으로 쓴다. 일부 파생 배포판(Devuan·Alpine Linux의 OpenRC 옵션)이 systemd를 거부하지만, 클라우드·데이터센터 표준은 systemd다.

6단계 — systemd의 서비스 시작

systemd는 "unit"이라는 단위로 서비스·마운트·타이머·소켓을 관리한다. 가장 흔한 unit은 .service(서비스)다. nginx.service·sshd.service·docker.service 같은 것들.

부팅 시 systemd가 하는 일:

1. target 결정 — 어디까지 부팅할지 결정. multi-user.target(텍스트 로그인, 구 runlevel 3) 또는 graphical.target(GUI 로그인, 구 runlevel 5). 서버는 보통 multi-user.target.
2. 의존성 그래프 계산 — 각 unit이 선언한 Requires=·Wants=·After=를 분석해 시작 순서를 정한다.
3. 병렬 실행 — 의존성이 없는 unit들은 동시에 시작된다. sysvinit 대비 부팅이 훨씬 빠른 이유.
4. 소켓 활성화(socket activation) — 서비스가 실제로 요청을 받을 때까지 시작을 미루고, 소켓만 먼저 열어둔다. 요청이 오면 그때 서비스를 띄운다. 부팅 시간을 더 줄이는 기법.

target과 runlevel의 대응을 표로 보자. 여전히 "runlevel 3"이라는 말을 쓰는 사람이 있어서 변환이 필요하다.

runlevel(구)	systemd target	의미
0	poweroff.target	종료
1, s, single	rescue.target	단일 사용자, 복구
2, 3, 4	multi-user.target	다중 사용자, 네트워크, 텍스트
5	graphical.target	다중 사용자 + GUI
6	reboot.target	재부팅

부팅 시간 분석 — 어디서 느려지나

부팅이 느린 서버는 RTO에 직결된다. systemd는 부팅 시간을 분석하는 도구를 기본 제공한다.

# 전체 부팅 시간
systemd-analyze
# 어느 unit이 가장 오래 걸렸나 (top-down)
systemd-analyze blame | head -20
# 임계 경로 — 이 unit이 느리면 전체가 늦어지는 연쇄
systemd-analyze critical-chain

blame은 각 unit의 시작 시간을 나열하지만 — 그 자체로는 의미가 없다. 느린 unit이 다른 unit들과 병렬로 실행 중이었다면, 그 느림이 전체 부팅을 늦추지 않는다. 진짜 중요한 건 critical-chain이 보여주는 임계 경로다. 임계 경로에 있는 unit만이 전체 부팅 시간을 결정한다. 임계 경로에 없는 unit은 아무리 느려도 부팅이 빨라진다(병렬로 돌고 있으니까).

일반적으로 부팅 시간을 줄이는 전략은 — 임계 경로상의 unit을 비활성화하거나(불필요한 서비스 끄기), 지연 시작(enabled late)으로 돌리거나, 소켓 활성화로 미룬다. 네트워크 대기(network-online.target)가 흔한 병목인데 — 서비스가 네트워크가 "준비될 때까지" 기다리면 부팅이 멈춘다. 보통은 네트워크를 기다리지 않고 서비스를 띄운 뒤, 필요할 때 재연결하는 게 낫다.

부팅 장애와 복구 — 부팅이 안 될 때

부팅이 실패하는 경우는 크게 세 가지다.

1. 하드웨어 문제 — 디스크 고장·메모리 불량·전원 문제. UEFI POST 단계에서 에러 코드(BEEP 또는 BMC 로그)를 낸다. 이 영역은 베어메탈 프로비저닝 글과 성능 분석 글에서 더 깊이.

2. 부트로더·커널 문제 — GRUB 설정 오류, 커널 이미지 손상, initramfs 누락. 증상은 "부팅하다가 멈춤" 또는 kernel panic 메시지. 복구하려면 외부 미디어(USB·ISO)로 부팅하거나, 클라우드라면 복구 모드 인스턴스(rescue instance)를 띄워 디스크를 마운트하고 고친다.

3. 루트 파일시스템 문제 — fsck(파일시스템 검사) 실패, 마운트 실패, 디스크 꽉 참. 부팅이 멈추고 emergency 모드로 떨어진다. 단일 사용자 모드(systemd.unit=rescue.target 커널 파라미터)로 들어가 수동 복구.

복구 모드 진입은 GRUB 메뉴에서 e를 눌러 편집 모드로 들어간 뒤, linux 행 끝에 systemd.unit=rescue.target(또는 init=/bin/bash로 더 극단적으로)을 추가하고 Ctrl+X로 부팅. 클라우드 VM은 이 GRUB 메뉴에 접근하기 어려울 수 있어 — AWS EC2의 경우 부트로더 설정을 수정한 다음 인스턴스를 재시작하거나, 복구 인스턴스를 띄워 디스크를 분리·재부착한다.

클라우드 인스턴스 부팅 — 왜 30초나 걸리나

EC2·GCE·Azure 인스턴스를 만들 때 걸리는 30 ~ 60초를 분해해 보면 대략 이렇다.

• 이미지 스냅샷에서 볼륨 생성 (5 ~ 15초) — AMI(이미지)에서 EBS 볼륨을 만드는 시간. 클라우드는 디스크를 물리적으로 파티셔닝하는 대신, 이미 준비된 블록 스냅샷을 복사해 새 볼륨을 만든다.
• 하이퍼바이저가 VM 인스턴스 할당 (2 ~ 5초) — 클라우드 벤더의 스케줄러가 여유 호스트를 찾아 가상 머신을 배치한다. AWS Nitro·GCP Hyper-V 같은 하이퍼바이저가 VM을 띄운다.
• 가상 UEFI·GRUB·커널 로드 (5 ~ 10초) — 물리 서버와 비슷한 부팅 흐름이 가상 하드웨어 위에서 재현된다.
• initramfs·systemd·서비스 시작 (10 ~ 30초) — 운영체제가 서비스를 띄우는 시간. 서비스가 많을수록 길어진다.

이 중 인프라 엔지니어가 줄일 수 있는 건 마지막 단계(systemd 부팅 시간) 정도다. AMI 최적화(불필요한 서비스 제거·systemd 병렬화·소켓 활성화)로 10초에서 5초로 줄일 수 있다. 오토스케일링(auto-scaling)이 빈번한 서비스에선 이 5초가 중요하다 — 트래픽 스파이크 때 새 인스턴스가 뜨는 속도가 곧 사용자 경험이니까.

부팅 시간이 비용인 이유 — EC2 인스턴스가 "Running" 상태가 된 시점부터 과금된다. "Pending" 중에는 무료지만, 부팅 중인 인스턴스는 트래픽을 못 받으니 비용 대비 효율이 0이다. 부팅 시간을 절반으로 줄이면 — 스팟 인스턴스·오토스케일링 비용 효율이 거의 2배 가까이 좋아진다. Netflix·Uber 같은 대규모 서비스가 부팅 시간 최적화에 집착하는 이유다.

실습 — 부팅 상태 직접 확인하기

1. 부팅 시간 분석

# 전체 부팅 시간
systemd-analyze
# 가장 오래 걸린 unit들
systemd-analyze blame | head -10
# 임계 경로 (이 unit들이 느리면 전체가 늦어짐)
systemd-analyze critical-chain

확인할 것: blame의 Time 열에서 비정상적으로 큰 unit. 네트워크 대기·DNS 조회·원격 마운트(NFS)가 흔한 원인.

# 예상 출력 (blame)
8.234s networkd-dispatcher.service
5.102s apt-daily.service
3.891s systemd-networkd-wait-online.service
2.105s docker.service
1.234s nginx.service

2. 부팅 로그 보기

# 현재 부팅 로그
journalctl -b
# 이전 부팅 로그 (이전 부팅이 실패한 경우 핵심)
journalctl -b -1
# 부팅 시 발생한 에러만
journalctl -b -p err

확인할 것: -p err로 에러 레벨 이상만 필터. 의존성 실패·타임아웃·마운트 실패가 보인다.

3. 커널 파라미터와 부트로더 설정

# 현재 부팅 시 전달된 커널 파라미터
cat /proc/cmdline
# GRUB 기본 설정
cat /etc/default/grub | grep -v '^#' | grep -v '^$'
# UEFI 부팅 항목 (UEFI 시스템)
efibootmgr 2>/dev/null

확인할 것: console=ttyS0가 있으면 직렬 콘솔 활성화(클라우드 표준). root=로 루트 장치 확인.

# 예상 출력 (/proc/cmdline)
BOOT_IMAGE=/boot/vmlinuz-6.8.0-50-generic root=UUID=a1b2c3d4-... ro quiet splash console=ttyS0 systemd.show_status=true

4. systemd target과 현재 상태

# 기본 target (어디까지 부팅했나)
systemctl get-default
# 현재 동작 중인 target
runlevel
# 부팅 실패한 unit
systemctl --failed

확인할 것: get-default가 multi-user.target이면 서버 표준. --failed가 있으면 그 unit이 부팅 시 실패한 것 — 원인을 journalctl -u <unit>로 파악.

# 예상 출력
$ systemctl get-default
multi-user.target

$ systemctl --failed
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION
● nginx.service  loaded failed failed A high performance web server

5. initramfs 내용 확인

# initramfs에 어떤 드라이버가 들어있는지 (디스크 암호화·RAID 사용 시 중요)
lsinitrd 2>/dev/null || lsinitramfs /boot/initrd.img-$(uname -r) 2>/dev/null | head -30

확인할 것: NVMe 드라이버(nvme.ko)·파일시스템 드라이버(ext4·xfs)가 들어있는지. 새 하드웨어·RAID를 추가한 뒤엔 initramfs를 다시 만들어야 한다(update-initramfs -u 또는 dracut -f).

미검증: 위 명령의 정확한 출력은 배포판·커널 버전·클라우드에 따라 다르다. 클라우드 VM은 GRUB 메뉴를 직접 보기 어려워 — AWS EC2의 "Get System Log"가 직렬 콘솔 부팅 로그의 대체. man 페이지(man systemd-analyze, man journalctl)가 공식 필드 정의.

부팅 장애 진단 체크리스트

부팅이 안 되거나 느릴 때 단계별로 점검하는 기본 흐름이다.

증상	의심 단계	점검 명령	흔한 원인
화면이 안 켜짐	전원·펌웨어	BMC 로그(IPMI/Redfish)	전원·메모리·CPU 불량
GRUB loading에서 멈춤	부트로더	USB/ISO로 부팅 후 디스크 검사	디스크 고장·GRUB 손상
GRUB rescue> 프롬프트	부트로더	ls, set 명령	파티션·GRUB 설정 손상
kernel panic - unable to mount root fs	initramfs	복구 모드에서 lsinitrd	initramfs 누락·드라이버 부재
fsck 실패로 멈춤	파일시스템	fsck -y /dev/sdX	디스크 손상·비정상 종료
systemd에서 Failed to start X	서비스	journalctl -u X, systemctl status X	설정 오류·의존성 실패·타임아웃
부팅은 되나 느림	systemd	systemd-analyze blame	네트워크 대기·DNS·불필요 서비스

부팅은 "끝"이 아니라 "시작"이다

도입의 AWS 장애 복구 사건으로 돌아가자. 그날 부팅 시간이 곧 복구 시간이었다. 부팅을 이해하지 못한 팀은 — 왜 복구가 늦는지, 어디서 막히는지를 몰랐다. 반면 부팅 흐름을 이해한 팀은 — 어느 단계가 느린지(systemd 부팅), 어디서 실패하는지(커널 파라미터), 어떻게 줄일지(systemd 병렬화·소켓 활성화)를 진단하고 대응했다.

이 흐름을 이해하면 다른 질문에도 답할 수 있다. "왜 EC2 인스턴스가 만들어지는 데 30초나 걸리나" → 부팅의 물리적 한계. "왜 새 서비스를 추가하면 부팅이 느려지나" → systemd 임계 경로 변경. "왜 클라우드 VM이 갑자기 부팅이 안 되나" → initramfs·커널 업데이트·설정 변경 중 어디서 문제가 생겼는지. 이 모든 게 같은 부팅 흐름 안에서 일어난다.

다음 글에서는 이 부팅 흐름을 수천 대의 베어메탈 서버로 확장하는 법을 본다 — 베어메탈 프로비저닝. PXE 부트·IPMI·Redfish·cloud-init로, 사람이 서버 한 대씩 손으로 설치하지 않고 수천 대를 자동으로 설정하는 방법. 01·02 글이 다룬 "한 대의 하드웨어"와 "부팅 흐름"이 이제 데이터센터 규모로 확장된다.

---

참고

• AWS, "Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region", 2017-02-28 — 2017 S3 장애 공식 보고서. 접근 2026-07-21. URL: https://aws.amazon.com/message/41926/
• UEFI Forum, "UEFI Specification 2.10", 2022 — UEFI 표준. 접근 2026-07-21. URL: https://uefi.org/specifications
• GNU Project, "GNU GRUB Manual 2.06", 2021 — GRUB 공식 문서. 접근 2026-07-21
• Poettering, L., Sievers, K. "systemd for Administrators", 2010 — systemd 발표와 설계 원칙. 접근 2026-07-21. URL: https://systemd.io/
• freedesktop.org, "systemd Documentation" — unit·target·socket activation. 접근 2026-07-21. URL: https://www.freedesktop.org/wiki/Software/systemd/
• Linux kernel documentation, kernel.org — initramfs, /proc/cmdline, 부팅 파라미터. 접근 2026-07-21
• AWS, "Amazon EC2 User Guide — Boot Time" — Nitro 기반 인스턴스 부팅 시간. 접근 2026-07-21
• Bovet, D. P., Cesati, M. 3rd ed, O'Reilly, 2005 — 커널 부팅·초기화. 접근 2026-07-21
• Nemeth, E., Snyder, G., Hein, T. 5th ed, Addison-Wesley, 2017, Ch.2·Ch.3 — 부팅·systemd 실무. 접근 2026-07-21