서버가 켜지는 동안 무슨 일이 벌어지는가 — 시스템 엔지니어를 위한 OS 부팅 과정
전원 버튼을 누르고 SSH가 될 때까지 2분. 그 사이에 HW와 SW가 어떻게 제어권을 주고받는지, BMC부터 systemd까지 각 단계가 왜 존재하고 무슨 일을 하는지를 정리한 글.
서버 전원을 넣고, 2분 뒤에 SSH로 접속한다. 아무일도 없을 때에는 그 2분 동안 무슨 일이 벌어지는지 굳이 알 필요가 없다.
하지만 이 과정을 한 번이라도 머릿속에 그려두면, 서버를 보는 눈이 달라진다. "BIOS 설정을 바꿨는데 왜 반영이 안 되지?"가 이해가 되고, "fstab을 잘못 건드렸더니 서버가 안 켜진다"가 왜인지 알게 되고, "커널 업데이트 후 재부팅이 무서운" 이유도 납득이 된다.
이 글은 전원 버튼을 누른 순간부터 SSH가 뜰 때까지, HW에서 SW로 제어권이 넘어가는 과정을 따라가는 이야기다.
전체 흐름 — HW에서 SW로
██ HW 영역 ░░ HW+SW 경계 ▓▓ SW 영역
AC 전원 인가
│
▼
┌─────────────────────────────────────────┐
│ ██ BMC (대기 전원으로 동작) │ 서버가 "꺼져있어도" 살아있다
│ │
│ BMC 펌웨어 로딩 → 네트워크 활성화 ────────► 관리 네트워크 연결
│ HW 센서 모니터링 시작 │ (IPMI/Redfish 대기)
└────────────────┬────────────────────────┘
│
전원 버튼 또는 BMC 원격 Power On
│
▼
┌─────────────────────────────────────────┐
│ ██ POST (Power-On Self Test) │ HW가 자기 자신을 점검
│ │
│ CPU 초기화 → 메모리 트레이닝 → │
│ PCIe 디바이스 열거 → │ NIC, RAID, NVMe, GPU
│ RAID 컨트롤러 초기화 │ 가상 디스크 어셈블
│ │ │
│ POST 완료 │ ✓CPU ✓메모리 ✓디스크 ✓NIC
└────────────────┬────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ ░░ UEFI 펌웨어 │ HW 펌웨어가 SW를 찾는 단계
│ │
│ 부트 디바이스 목록 → 1순위 접근 │ NVMe? RAID? PXE? USB?
│ ESP(EFI System Partition) 읽기 │ /boot/efi (FAT32)
│ shimx64.efi → grubx64.efi 실행 │ Secure Boot 체인
└────────────────┬────────────────────────┘
│
─ ─ ─ ─ ─ ─ ─ ─ ┼ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
여기서부터 HW 위에서 SW가 실행된다
│
▼
┌─────────────────────────────────────────┐
│ ▓▓ GRUB2 (부트로더) │ 최초의 SW
│ │
│ grub.cfg → 커널 선택 → │
│ vmlinuz + initramfs 메모리 로딩 │ 커널에 제어권 전달
└────────────────┬────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ ▓▓ Linux 커널 + initramfs │ 커널이 HW를 다시 인식
│ │
│ 드라이버 로딩 → LVM 활성화 → │ RAID, multipath, NVMe
│ 루트(/) 마운트 → switch_root │ 임시 → 진짜 루트로 전환
└────────────────┬────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ ▓▓ systemd (PID 1) │ 서비스 세계의 시작
│ │
│ sysinit → basic → network → │ fstab 마운트, NIC 활성화
│ multi-user.target │ sshd, 모니터링, 서비스
│ │ │
│ ✅ 부팅 완료 │ SSH 접속 가능
└─────────────────────────────────────────┘
시간 흐름:
0초 5초 15초 20초 25초 60~120초
│ │ │ │ │ │
├─ BMC ──├─ POST ──├─ UEFI ─├─ GRUB ─├─ 커널 ──├─ systemd ─►
│ HW █████████████████░░░░░░░░░│▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓│ SWBMC — 서버가 꺼져있어도 살아있는 것
전원 버튼을 누르기 전에 이미 동작하고 있는 게 있다. BMC(Baseboard Management Controller)다. Dell이면 iDRAC, HPE면 iLO, Lenovo면 XCC라고 부른다. 이름만 다르지 역할은 같다.
BMC는 서버 메인보드에 붙어있는 작은 컴퓨터다. 대기 전원(Standby Power)으로 돌아가기 때문에 서버 OS가 꺼져있어도, 심지어 OS가 설치되어 있지 않아도 동작한다. 관리 네트워크에 연결되어 있으면 웹 브라우저로 접속할 수 있고, 원격으로 전원을 켜고 끄고, 콘솔 화면을 볼 수 있다.
시스템 엔지니어에게 BMC는 "서버의 생명줄"이다. SSH가 안 되는 서버에 접근할 수 있는 유일한 경로다. 데이터센터에 가지 않고도 서버 화면을 볼 수 있고, BIOS 설정을 바꿀 수 있고, OS를 재설치할 수도 있다.
BMC는 부팅 과정에서도 역할이 있다. 서버가 켜지면 HW 센서(온도, 전압, 팬 속도)를 모니터링하고, POST 과정에서 발생하는 이벤트를 SEL(System Event Log)에 기록한다. 나중에 "이 서버 부팅할 때 무슨 일이 있었지?"를 추적할 수 있는 건 BMC 덕분이다.
POST — HW가 자기 자신을 점검하는 시간
전원이 들어오면 가장 먼저 POST(Power-On Self Test)가 실행된다. 말 그대로 "전원 켜고 자가 진단". CPU가 살아있는지, 메모리가 인식되는지, PCIe에 뭐가 꽂혀있는지, 디스크가 보이는지 확인하는 과정이다.
POST에서 하는 일을 순서대로 보면:
1. CPU 초기화
CPU의 마이크로코드를 로딩한다. 마이크로코드는
CPU 내부의 "펌웨어" 같은 것으로, 버그 수정이나
보안 패치가 여기에 포함된다.
2. 메모리 트레이닝
DIMM을 하나하나 인식하고, 각 DIMM과의 통신 타이밍을
최적화한다. 메모리가 많을수록 이 과정이 오래 걸린다.
TB급 메모리를 가진 서버는 POST만 1~2분 걸리기도 한다.
3. PCIe 디바이스 열거
PCIe 슬롯에 꽂혀있는 장치들을 인식한다.
NIC, RAID 컨트롤러, NVMe SSD, GPU — 각 장치의
펌웨어가 이 시점에 로딩된다.
4. RAID 컨트롤러 초기화
RAID 컨트롤러가 있으면, 물리 디스크를 스캔하고
가상 디스크(VD)를 어셈블한다. 디스크가 수십 개면
이것도 시간이 꽤 걸린다.POST가 끝나면 벤더 로고 화면에서 F2(BIOS 설정), F11(부트 메뉴), F12(PXE 부팅) 같은 키를 누를 수 있는 순간이 온다. 이 단계까지는 순수하게 HW의 세계다. OS는 아직 등장하지 않았다.
UEFI — HW가 OS를 찾아가는 다리
POST가 끝나면 UEFI 펌웨어가 "어디서 OS를 부팅할 것인가"를 결정한다. UEFI는 예전의 BIOS를 대체하는 표준이다. 신규 서버는 전부 UEFI다.
UEFI는 NVRAM에 저장된 부트 디바이스 목록을 순서대로 시도한다. 1순위가 NVMe SSD면 그 디스크에서 OS를 찾고, 못 찾으면 2순위(RAID 가상 디스크)를 시도하고, 그것도 안 되면 PXE(네트워크 부팅)를 시도한다.
디스크 부팅이면 UEFI는 디스크의 ESP(EFI System Partition)를 읽는다. ESP는 FAT32로 포맷된 작은 파티션(보통 500MB)으로, 여기에 부트로더가 들어있다. Secure Boot가 켜져있으면 shimx64.efi(서명 검증)를 먼저 실행하고, 거기서 grubx64.efi(GRUB)를 실행한다.
UEFI와 Legacy BIOS의 핵심 차이:
┌──────────────┬──────────────────┬──────────────────┐
│ │ Legacy BIOS │ UEFI │
├──────────────┼──────────────────┼──────────────────┤
│ 파티션 방식 │ MBR │ GPT │
├──────────────┼──────────────────┼──────────────────┤
│ 부트 영역 │ MBR 부트섹터 │ ESP 파티션 │
│ │ (512바이트) │ (수백MB) │
├──────────────┼──────────────────┼──────────────────┤
│ 디스크 제한 │ 2TB 이하 │ 제한 없음 │
├──────────────┼──────────────────┼──────────────────┤
│ Secure Boot │ 불가 │ 가능 │
└──────────────┴──────────────────┴──────────────────┘
OS 설치 시 UEFI 모드로 설치했으면 UEFI로만 부팅된다.
Legacy로 설치한 OS를 UEFI로 부팅하면 안 된다. (역도 마찬가지)
이 차이를 모르면 "OS가 설치되어있는데 부팅이 안 돼"를 만난다.UEFI가 GRUB을 실행하는 순간, 제어권이 HW 펌웨어에서 SW로 넘어간다. 여기가 HW와 SW의 경계선이다.
GRUB — 어떤 커널로 부팅할 것인가
GRUB2는 Linux의 표준 부트로더다. 역할은 단순하다. "어떤 커널을 메모리에 올릴 것인가"를 결정하고, 커널과 initramfs를 메모리에 로딩한 뒤, 커널에 제어권을 넘기는 거다.
서버에 커널이 여러 개 설치되어 있을 수 있다. 커널을 업데이트해도 이전 버전이 남아있다. GRUB 메뉴에서 원하는 커널을 선택할 수 있다. 보통은 가장 최신 커널로 자동 부팅되지만, 새 커널에 문제가 있으면 GRUB 메뉴에서 이전 커널을 선택해서 부팅할 수 있다. 이게 "커널 롤백"이다.
GRUB의 설정 파일은 /boot/grub2/grub.cfg다. 이 파일에 커널 목록, 부트 옵션, 타임아웃 등이 들어있다. grub.cfg는 직접 편집하는 게 아니라 grub2-mkconfig 명령으로 생성한다.
GRUB이 커널(vmlinuz)과 initramfs를 메모리에 올리면 GRUB의 역할은 끝난다. 이후는 커널의 세계다.
커널과 initramfs — 닭이 먼저냐 달걀이 먼저냐
커널이 시작되면 HW를 다시 인식하고 초기화한다. "POST에서 이미 HW를 인식하지 않았나?"라고 할 수 있는데, POST는 펌웨어 수준의 인식이고, 커널은 OS 수준에서 디바이스 드라이버를 통해 HW를 제어하는 거라 단계가 다르다.
커널이 해야 할 첫 번째 일은 루트 파일시스템(/)을 마운트하는 거다. 루트가 마운트되어야 시스템 설정 파일도 읽고, 서비스도 시작할 수 있다. 그런데 문제가 하나 있다.
루트 파일시스템을 마운트하려면 드라이버가 필요하다.
예: LVM 드라이버, RAID 드라이버, 멀티패스 드라이버
그런데 그 드라이버는 루트 파일시스템 안에 있다.
루트를 마운트하려면 드라이버가 필요한데,
드라이버는 루트 안에 있다.
→ 닭이 먼저냐 달걀이 먼저냐.이 문제를 해결하는 게 initramfs(Initial RAM Filesystem)다. initramfs는 "루트를 마운트하기 위해 필요한 최소한의 드라이버와 도구"를 담은 작은 파일시스템이다. GRUB이 커널과 함께 메모리에 올려준다.
initramfs가 하는 일:
커널 시작
│
▼
initramfs를 임시 루트(/)로 사용
│
▼
initramfs 안에 있는 드라이버 로딩
(LVM, RAID, multipath, NVMe, SCSI 등)
│
▼
LVM 볼륨 활성화, RAID 어셈블 등
│
▼
진짜 루트 파일시스템을 마운트
(예: /dev/mapper/rootvg-rootlv → /)
│
▼
switch_root: 임시 루트 → 진짜 루트로 전환
│
▼
systemd(PID 1) 실행initramfs가 존재하는 이유를 알면, "RAID 컨트롤러를 교체했더니 부팅이 안 된다"가 왜 그런지 이해된다. 새 RAID 컨트롤러의 드라이버가 initramfs에 없기 때문이다. dracut --force로 initramfs를 재생성하면 새 드라이버가 포함되어 해결된다.
/etc/fstab에서 장치명(/dev/sda2) 대신 UUID를 쓰는 이유도 여기서 나온다. 디스크 장치명은 하드웨어 구성이 바뀌면 달라질 수 있지만, UUID는 파일시스템을 만들 때 고정된다. initramfs가 루트를 찾을 때 UUID로 찾으면 장치명이 바뀌어도 문제없다.
systemd — 서비스 세계의 시작
커널이 루트 파일시스템을 마운트하면 systemd가 시작된다. systemd는 PID 1, 즉 리눅스에서 가장 먼저 실행되는 프로세스다. 이전에는 SysVinit이나 Upstart가 이 역할을 했지만, 지금은 대부분의 배포판이 systemd를 쓴다.
systemd는 "타겟(target)" 단위로 서비스를 순서대로 올린다. 예전의 "런레벨"과 비슷한 개념이다.
systemd 부팅 순서:
sysinit.target 기본 시스템 초기화
│ udev(디바이스 관리), 파일시스템 마운트
│ /etc/fstab에 정의된 파티션들이 여기서 마운트됨
▼
basic.target 기본 서비스
│ journald(로깅), 타이머
▼
network.target 네트워크 활성화
│ NIC 설정, IP 할당 (NetworkManager 또는 systemd-networkd)
▼
multi-user.target 일반 서비스 기동 (= 예전의 runlevel 3)
│ sshd, 모니터링 에이전트, cron, 서비스 데몬들
▼
부팅 완료. SSH 접속 가능.systemd가 fstab을 처리하는 시점이 sysinit.target이라는 게 중요하다. fstab에 NFS 마운트가 있는데 네트워크가 아직 안 올라왔으면? 마운트가 실패한다. 이걸 방지하려면 fstab에 _netdev(네트워크 활성화 후 마운트) 옵션을 넣어야 한다. nofail 옵션은 "마운트 실패해도 부팅을 계속하라"는 뜻이다. 스토리지 시리즈 8편에서 이 옵션들을 강조한 이유가 여기 있다.
부팅 시간이 궁금하면 systemd-analyze로 확인할 수 있다.
$ systemd-analyze
Startup finished in 2.3s (firmware) + 1.1s (loader) +
2.8s (kernel) + 45.2s (userspace) = 51.4s
firmware = POST + UEFI (HW 영역)
loader = GRUB
kernel = 커널 초기화 + initramfs
userspace = systemd 서비스 기동 ← 대부분의 시간이 여기
$ systemd-analyze blame
30.1s NetworkManager-wait-online.service
8.2s firewalld.service
3.1s sshd.service
뭐가 오래 걸리는지가 보인다.5,000대 환경에서 부팅이 중요해지는 순간
평소에 서버 1대의 부팅은 별일이 아니다. 하지만 대규모 환경에서 부팅이 한꺼번에 이슈가 되는 순간이 있다.
데이터센터 전원 사고 후 복전. UPS 런타임을 넘기면 서버가 전부 꺼진다. 전원이 복구되면 수백~수천 대가 동시에 부팅을 시도한다. PXE 서버에 수백 대가 동시 요청을 하고, DHCP에 동시 요청이 몰리고, NFS/스토리지가 아직 안 올라왔는데 서버들이 fstab에서 NFS 마운트를 시도한다. 한꺼번에 다 켜면 인프라 서비스부터 과부하가 걸린다. 그래서 부팅 순서 계획이 필요하다 — 스토리지/네트워크 장비 먼저, 인프라 서버(DNS, DHCP, PXE) 다음, 서비스 서버는 구역별로 순차적으로.
커널 업데이트 후 일괄 재부팅. 보안 패치로 커널을 업데이트하면 재부팅이 필요하다. 5,000대를 한 번에 재부팅하면? 새 커널에 문제가 있으면 전부 부팅 실패다. 그래서 테스트 그룹(10~50대)에서 먼저 재부팅하고 검증한 뒤, 문제 없으면 그룹별로 순차 재부팅(Rolling Reboot)한다. GRUB에 이전 커널이 남아있으니, 문제가 생기면 이전 커널로 부팅하면 된다. 이게 롤백 플랜이다.
부팅 과정 요약
┌─────────┬──────────────────────┬──────────────────────┐
│ 단계 │ 하는 일 │ 왜 알아야 하는가 │
├─────────┼──────────────────────┼──────────────────────┤
│ BMC │ 원격 관리 인터페이스 │ SSH 안 될 때 유일한 │
│ │ HW 센서 모니터링 │ 접근 경로 │
├─────────┼──────────────────────┼──────────────────────┤
│ POST │ CPU, 메모리, 디스크 │ 메모리 많으면 POST가 │
│ │ PCIe 자가 진단 │ 오래 걸리는 이유 │
├─────────┼──────────────────────┼──────────────────────┤
│ UEFI │ 부트 디바이스 선택 │ UEFI/Legacy 혼동 시 │
│ │ ESP에서 부트로더 실행│ 부팅 안 되는 이유 │
├─────────┼──────────────────────┼──────────────────────┤
│ GRUB │ 커널 선택 + 로딩 │ 커널 롤백이 가능한 │
│ │ │ 이유 │
├─────────┼──────────────────────┼──────────────────────┤
│ 커널/ │ 드라이버 로딩 │ RAID 교체 후 부팅 │
│ initramfs│ 루트 마운트 │ 실패하는 이유 │
│ │ │ fstab에 UUID 쓰는 이유│
├─────────┼──────────────────────┼──────────────────────┤
│ systemd │ 서비스 순서대로 기동 │ fstab에 nofail 쓰는 │
│ │ │ 이유. 부팅 시간 분석. │
└─────────┴──────────────────────┴──────────────────────┘부팅 과정을 알면 "왜 이렇게 하는가"가 이해된다. fstab에 UUID를 쓰는 건 initramfs가 루트를 찾는 방식 때문이고, nofail을 쓰는 건 systemd가 fstab을 처리하는 시점 때문이고, 커널 업데이트 후 조심하는 건 GRUB이 커널을 선택하는 구조 때문이다. 각각 따로 외우는 게 아니라, 부팅 흐름을 한 번 이해하면 전부 연결된다.
이 글이 어떠셨나요?
관련 포스트
키보드를 치면 리눅스에서는 어떤 일이 벌어질까?
키보드를 치면 리눅스에서는 어떤 일이 벌어질까? 라는 궁금증에 시작한 리눅스가 입력을 처리한 방법에 대해서 알려준다.
2026. 02. 01. 오전 12:00Infrastructure1. 스토리지, 왜 어렵고 왜 중요한가
서버는 죽어도 살리면 되지만 스토리지는 잃으면 끝이다. 10년차 시스템 엔지니어가 스토리지가 어렵고 중요한 이유, 스토리지 담당자의 실제 업무, 기술의 진화 흐름을 현장 경험 기반으로 풀어본다.
2026. 03. 30. 오후 10:00DevOps1. LLM은 텍스트를 어떻게 처리하는가
LLM이 텍스트 한 줄을 받아서 다음 토큰을 예측하기까지의 전체 과정을 4단계로 따라간다. 토크나이저, 임베딩, 트랜스포머 레이어, 출력까지 "OOM killer가 nginx를" 한 문장이 모델 안에서 겪는 여행.
2026. 03. 03. 오후 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.