1. 왜 부팅 과정을 알아야 하는가

04편에서 부트로더 GRUB이 디스크의 어느 위치에 설치되는지 배웠습니다. 이제 그 부트로더가 실제로 무엇을 하는지, 그리고 그 뒤로 로그인 화면이 뜨기까지 어떤 프로그램들이 순서대로 실행되는지를 살펴봅니다.

이 흐름을 알아야 하는 실질적인 이유가 있습니다. 리눅스 서버를 운영하다 보면 “부팅이 안 된다”, “특정 서비스가 자동으로 안 뜬다” 같은 문제를 마주치는데, 이때 문제가 부팅의 어느 단계에서 생겼는지 짚을 수 있어야 원인을 좁혀 갈 수 있습니다. 2급 1차 시험에서는 이 순서 자체를 묻는 문제와, 뒤에 나올 런레벨·systemd 타깃 대응 문제가 반복해서 출제됩니다.

쉽게 말하면: 부팅은 “전원 → 하드웨어 점검 → 부트로더 → 커널 → 최초 프로세스 → 로그인 화면”이라는 정해진 순서로 진행되는 계주 경기입니다.

2. 전원부터 로그인까지 — 부팅 단계

2.1 전체 흐름

2.2 각 단계 자세히 보기

1단계 — 전원 인가와 자체 점검(POST): 전원 버튼을 누르면 컴퓨터의 펌웨어인 BIOS(Basic Input Output System) 또는 그 후속 규격인 UEFI(Unified Extensible Firmware Interface)가 가장 먼저 동작합니다. 이 펌웨어는 POST(Power-On Self Test, 전원을 켰을 때 CPU·메모리·기본 장치가 정상인지 확인하는 자체 점검)를 수행합니다. 이 시점에는 아직 리눅스도, 어떤 운영체제도 실행되지 않은 상태입니다.

2단계 — 부트로더 실행: POST가 끝나면 펌웨어는 04편에서 배운 위치(BIOS 방식이면 MBR, UEFI 방식이면 EFI 시스템 파티션)에서 부트로더를 찾아 실행합니다. 부트로더인 GRUB은 설정된 메뉴를 보여 주고(또는 자동으로 기본 항목을 선택하고), 사용자가 고른 커널을 디스크에서 읽어 메모리에 올릴 준비를 합니다.

3단계 — 커널 적재: GRUB은 리눅스 커널 이미지 파일(흔히 vmlinuz로 시작하는 이름)과, 커널이 초기 구동에 필요로 하는 임시 파일시스템인 initramfs(initial RAM filesystem, 실제 디스크의 파일시스템 드라이버를 읽어 들이기 전 최소한의 환경을 제공하는 임시 메모리 파일시스템)를 함께 메모리에 올립니다. 이후 제어권이 커널로 넘어가면서, 커널이 하드웨어를 직접 인식하고 실제 루트 파일시스템(/)을 마운트합니다.

4단계 — 최초 프로세스 실행: 커널이 초기화를 마치면, 커널은 사용자 공간(user space, 커널이 아닌 일반 프로그램들이 실행되는 영역)에서 실행될 최초의 프로세스를 하나 띄웁니다. 이 프로세스의 PID(Process ID, 실행 중인 각 프로세스에 부여되는 고유 번호)는 항상 1입니다. 옛날 리눅스에서는 이 최초 프로세스가 init이었지만, 지금 대부분의 배포판(CentOS 7 이후, 최신 Ubuntu 등)은 systemd를 최초 프로세스로 씁니다.

5, 6단계 — 타깃까지 서비스 순차 시작: PID 1번인 systemd는 이후 필요한 데몬(daemon, 백그라운드에서 계속 실행되며 서비스를 제공하는 프로세스 — 13편에서 자세히 다룹니다)들을 fork(부모 프로세스를 복제해 자식 프로세스를 만드는 방식, 14편에서 다시 다룹니다) 방식으로 자신의 자식 프로세스로 하나씩 띄웁니다. 네트워크 서비스, 로그인 관리자 등이 이 단계에서 순서대로 올라옵니다. 어디까지 서비스를 띄우고 멈출지는 시스템에 설정된 타깃(target, 아래에서 자세히 다룹니다)이 정합니다.

7단계 — 로그인 화면 표시: 텍스트 모드라면 콘솔에 로그인 프롬프트가, 그래픽 모드라면 디스플레이 매니저가 그래픽 로그인 화면을 띄우며 부팅이 마무리됩니다.

3. 런레벨과 systemd 타깃의 대응

3.1 런레벨이라는 옛 개념

옛 리눅스(System V 계열 init 방식)에서는 시스템이 “지금 어떤 상태로 동작해야 하는가”를 런레벨(runlevel)이라는 0에서 6까지의 숫자로 표현했습니다. 예를 들어 런레벨 3이면 “텍스트 모드로 다중 사용자가 쓸 수 있는 상태”, 런레벨 5면 “그래픽 로그인까지 가능한 상태”를 뜻했습니다.

지금은 systemd가 이 역할을 대신하면서, 숫자 대신 의미를 알 수 있는 이름을 가진 타깃(target)이라는 단위를 씁니다. 예를 들어 런레벨 5에 대응하는 타깃은 graphical.target입니다. 그런데 시험에는 옛 런레벨 번호와 새 타깃 이름을 짝지어 묻는 문제가 매우 자주 나오므로, 이 대응 관계를 정확히 외워야 합니다.

3.2 런레벨 ↔ systemd 타깃 대응표

3.3 현재 타깃 확인하고 바꾸기

systemd 시스템에서는 다음 명령으로 기본 부팅 모드를 확인하고 바꿀 수 있습니다.

# 현재 기본 타깃(런레벨에 해당) 확인
systemctl get-default
 
# 기본 타깃을 그래픽 모드로 변경
systemctl set-default graphical.target

get-default는 “지금 무엇으로 설정되어 있는지 확인”하는 명령이고, set-default는 “설정 자체를 바꾸는” 명령입니다. 두 명령의 이름이 비슷해 시험에서 자리를 바꿔 놓는 함정이 나옵니다. 동사 부분(get은 조회, set은 변경)에 주목하면 구분하기 쉽습니다.

4. 종료와 재부팅 명령의 차이

4.1 왜 명령이 여러 개인가

시스템을 끄거나 다시 켜는 상황에도 몇 가지 명령이 있고, 이들은 동작 방식과 여러 사용자에게 미리 알리는지 여부에서 차이가 있습니다. 여러 사람이 동시에 접속해 쓰는 서버에서 예고 없이 전원을 내려 버리면 작업 중이던 데이터가 손상될 수 있으므로, 이 차이를 아는 것이 실무에서도 중요합니다.

4.2 정상 종료가 중요한 이유

리눅스는 디스크에 쓰기 작업을 할 때 성능을 위해 일단 메모리(캐시)에 먼저 기록해 두고, 나중에 한꺼번에 디스크에 실제로 반영하는 방식을 씁니다. 이 방식 때문에 전원을 그냥 뽑아 버리면, 아직 디스크에 반영되지 않은 데이터가 통째로 사라지거나 파일시스템 자체가 손상될 수 있습니다. shutdown, halt, poweroff, reboot 같은 명령은 이 마지막 반영 작업(동기화, sync)과 실행 중인 프로세스들의 정상 종료 절차를 거친 뒤 전원을 내리므로, 강제로 전원을 끄는 것보다 훨씬 안전합니다.

직접 해보기

rocky-init 컨테이너 안에서 지금 기본 타깃이 무엇인지, 어떤 타깃들이 존재하는지, 지금 런레벨이 몇인지 차례로 확인합니다.

docker exec -it rocky-init bash
systemctl get-default
systemctl list-units --type=target | head
runlevel

무엇을 보아야 하나: get-default가 출력하는 타깃 이름이 3.2 대응표의 몇 번 런레벨과 짝인지, list-units 목록에 multi-user.target·graphical.target 같은 이름이 실제로 보이는지, runlevel이 출력하는 두 숫자(이전 런레벨, 현재 런레벨) 중 뒤 숫자가 대응표와 맞는지 눈으로 확인합니다.

왜 이걸 해보나: 런레벨 숫자와 타깃 이름을 뒤바꾸는 문제(자주 틀리는 점 2)가 반복 출제됩니다. 표로 외운 대응 관계를 실제 명령 출력으로 한 번 보면 헷갈릴 여지가 줄어듭니다.

일반 rocky 컨테이너에서는 왜 안 되는지도 직접 오류로 확인해 봅니다.

docker exec -it rocky bash
systemctl get-default

무엇을 보아야 하나: “Failed to connect to bus” 같은 오류 메시지가 뜨는지 확인합니다. 이 오류가 바로 “일반 컨테이너는 부팅 과정을 거치지 않아 systemd(PID 1)가 아예 떠 있지 않다”는 사실을 증명합니다.

왜 이걸 해보나: “systemctl은 아무 리눅스 환경에서나 된다”는 막연한 생각을 실제 오류로 깨는 것이 목적입니다. 시험에서도 systemd가 최초 프로세스로 반드시 실행되어 있어야 타깃 전환이 가능하다는 점이 함정으로 나옵니다.

핵심 정리

• 부팅은 전원 → BIOS/UEFI(POST) → 부트로더(GRUB) → 커널 적재 → 최초 프로세스(PID 1, systemd) → 타깃까지 서비스 순차 시작 → 로그인 화면의 순서로 진행된다
• 사용자 공간의 최초 프로세스는 반드시 PID 1이며, 이후 서비스는 fork 방식으로 그 자식 프로세스로 생성된다(PID 0이나 exec와 혼동하지 말 것)
• 런레벨과 systemd 타깃의 대응은 0=poweroff, 1=rescue, 3=multi-user(텍스트), 5=graphical(그래픽), 6=reboot이다
• systemctl get-default는 조회, systemctl set-default 타깃은 변경 명령이다
• 종료·재부팅 명령은 shutdown -h(종료)/shutdown -r(재부팅), halt/poweroff, reboot처럼 짝을 이루며, 강제 전원 차단 대신 정상 종료 절차를 거쳐야 데이터 손상을 막을 수 있다

마무리 복습

참고 자료

• KAIT 리눅스마스터 자격안내 
• The Linux Documentation Project