부트로더 하나 잘못 건드리면 컴퓨터 전원 버튼을 눌러도 검은 화면만 뜨는 상황이 벌어져요. 실제로 리눅스 배포판 대부분은 기본값으로 GRUB(GRand Unified Bootloader)을 쓰지만, Arch Linux나 Fedora 같은 일부 환경에서는 systemd-boot를 선택지로 제공하고 있습니다. 둘 다 커널을 메모리에 올려 운영체제를 시작시키는 같은 역할을 하는데, 이름도 낯설고 설정 파일 생김새도 완전히 다른 두 프로그램이 왜 공존하는 걸까요? 그렇다면 GRUB과 systemd-boot는 구체적으로 어떤 지점에서 갈라지는 걸까요?
GRUB은 왜 지금까지 표준 자리를 지키고 있을까?
GRUB은 ext4, Btrfs, XFS, NTFS 등 거의 모든 파일시스템과 BIOS·UEFI 두 부팅 방식을 동시에 지원하도록 설계된 범용 부트로더예요. 이 범용성 덕분에 리눅스와 윈도우를 한 디스크에 함께 설치하는 듀얼부팅 환경에서도 os-prober라는 기능이 다른 파티션의 운영체제를 자동으로 찾아내 부팅 메뉴에 얹어주는 일이 가능해져요. 다만 이 범용성은 공짜가 아니에요. grub.cfg 설정 파일은 사람이 직접 편집하는 파일이 아니라 grub-mkconfig 스크립트가 설치된 커널 목록, 다른 OS, 테마 정보를 전부 스캔해서 자동으로 만들어내는 파일이라 내용이 수백 줄에 이르는 경우도 흔하고, 그만큼 문제가 생겼을 때 원인을 추적하기도 까다로워져요.
systemd-boot는 어떤 방식으로 단순함을 택했을까?
systemd-boot는 UEFI 펌웨어가 이미 갖춘 부팅 기능을 그대로 활용하는 것을 전제로, 별도의 파일시스템 드라이버나 복잡한 스크립트 없이 최소한의 설정만으로 커널을 실행하는 부트로더예요. 설정은 /boot/loader/entries/ 아래에 커널 경로와 옵션 몇 줄만 적힌 텍스트 파일 하나를 두는 것으로 끝나기 때문에, GRUB의 자동 생성 스크립트 같은 중간 단계 자체가 존재하지 않아요. 대신 이 단순함에는 명확한 전제 조건이 붙는데, systemd-boot는 UEFI 환경에서만 동작하고 레거시 BIOS 시스템에서는 아예 실행되지 않는다는 점이에요. UEFI라는 조건만 충족되면 설정 파일 몇 줄로 부팅 관리가 끝난다는 게 systemd-boot의 핵심이에요.
부팅 속도 차이는 실제로 체감될 정도일까?
부팅 속도는 systemd-boot 쪽이 실제로 더 빠른데, 여기엔 구조적인 이유가 있어요. GRUB은 부팅 시점에 자체 설정 파일을 해석하고 필요한 경우 파일시스템 드라이버까지 로드한 뒤 커널을 찾아 실행하는 반면, systemd-boot는 UEFI 펌웨어가 부트 엔트리 파일을 읽어 커널을 거의 곧바로 넘겨주는 구조라 중간 처리 단계가 훨씬 적어요. systemd 프로젝트 문서에서도 systemd-boot를 “단순하고 빠른 UEFI 부트 매니저”로 소개하고 있으며, 실사용 환경에서는 부트 메뉴가 뜨는 순간부터 커널이 실행되기까지 체감상 1~2초 안팎의 차이가 나타난다고 보고되는 경우가 많습니다. 물론 이 차이는 SSD를 쓰는 최신 시스템에서는 전체 부팅 시간 대비 크게 두드러지지 않을 수도 있어요.
듀얼부팅 환경에서는 어느 쪽이 더 유리할까?
윈도우와 리눅스를 함께 쓰는 환경이라면 GRUB이 더 안전한 선택인데, 앞서 언급한 os-prober가 윈도우 부트 항목을 자동으로 찾아 메뉴에 등록해주기 때문이에요. systemd-boot에도 윈도우를 인식하는 기능이 있긴 하지만, 다른 운영체제 항목을 자동으로 스캔하는 범위와 완성도 면에서는 아직 GRUB만큼 폭넓지 않아요. 여기서 끝이 아니에요. 파일시스템으로 Btrfs를 쓰고 있다면 Btrfs 스냅샷과 Snapper를 부트 메뉴와 엮어주는 grub-btrfs 같은 도구도 GRUB 진영에서 먼저 성숙해진 생태계라, 스냅샷 기반 롤백을 자주 쓰는 사용자라면 이 부분도 고려할 만해요.
그래서 결국 어떤 부트로더를 골라야 할까?
결론부터 말하면 정답은 “환경에 따라 다르다”예요. UEFI 단일 부팅 리눅스 시스템에서 빠른 부팅과 최소한의 설정을 원한다면 systemd-boot가, 윈도우 듀얼부팅이나 다양한 파일시스템·스냅샷 통합이 필요하다면 GRUB이 더 나은 선택이에요. Fedora Silverblue 같은 불변 리눅스 배포판들이 시스템 구성 요소를 최소화하고 예측 가능하게 만드는 방향으로 가는 것처럼, 부트로더 선택도 결국 “내 시스템에 얼마나 많은 유연성이 필요한가”라는 질문으로 되돌아가요. 화려한 기능보다 단순함과 속도가 우선이라면 systemd-boot 쪽으로, 다양한 시나리오를 폭넓게 커버해야 한다면 GRUB 쪽으로 기울어지는 셈이에요.
자주 묻는 질문
Q1. GRUB과 systemd-boot 중 부팅 속도가 더 빠른 건 어느 쪽인가요?
systemd-boot가 더 빠른데, GRUB처럼 자체 설정 파일을 해석하고 여러 파일시스템 드라이버를 로드하는 중간 단계 없이 UEFI 펌웨어가 커널을 거의 바로 실행하기 때문이에요.
Q2. systemd-boot는 왜 레거시 BIOS 컴퓨터에서 못 쓰나요?
systemd-boot는 UEFI 펌웨어 기능만으로 동작하도록 설계된 부트로더라서, UEFI를 지원하지 않는 구형 BIOS 시스템에서는 애초에 실행 자체가 불가능해요.
Q3. 윈도우와 듀얼부팅할 때는 GRUB과 systemd-boot 중 뭐가 더 안전한가요?
GRUB이 더 안전한데, 설치 과정에서 다른 파티션의 운영체제를 자동으로 감지해 부팅 메뉴에 등록해주는 os-prober 기능을 갖추고 있어서 윈도우 항목을 수동으로 챙길 필요가 적어요.
Q4. GRUB에서 systemd-boot로 바꾸면 기존 커널 설정이 사라지나요?
아니요, 전환 자체는 부트로더 프로그램만 교체하는 작업이라 커널이나 initramfs 파일은 그대로 남지만, 각 배포판의 부트로더 관리 스크립트가 systemd-boot를 지원하는지 먼저 확인해야 해요.
Q5. GRUB 설정 파일(grub.cfg)은 왜 이렇게 길고 복잡한가요?
grub.cfg는 사람이 직접 손으로 쓰는 파일이 아니라 grub-mkconfig 스크립트가 설치된 커널·다른 운영체제·테마 정보를 모두 스캔해서 자동 생성하는 파일이라 다루는 항목이 많아질수록 길어지는 구조예요.
Q6. Btrfs 스냅샷으로 부팅하는 기능도 systemd-boot에서 쓸 수 있나요?
네, systemd-boot 자체도 부트 엔트리 파일만 추가하면 스냅샷 커널을 등록할 수 있지만, 스냅샷을 자동으로 감지해 메뉴에 올려주는 grub-btrfs 같은 통합 도구는 아직 GRUB 진영에 더 많아요.
윈도우-리눅스 듀얼부팅, 안전하게 세팅하는 방법
파티션 축소부터 UEFI 부트로더 충돌, GRUB 복구까지 윈도우와 리눅스를 한 컴퓨터에 함께 설치할 때 실제로 자주 터지는 문제와 해결 순서를 정리합니다.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.