38. init 프로세스 / systemd (리눅스 첫 번째 프로세스)

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

본질: init 프로세스는 운영체제 부팅 시 커널이 가장 먼저 실행하는 프로세스 (PID 1)로, 모든 사용자 모드 프로세스의 공통 조상이며 시스템의 상태 (Runlevel/Unit) 관리 및 자식 프로세스 수거를 담당하는 루트 관리자다.

가치: 서비스 간의 의존성 (Dependency)을 관리하고 병렬 부팅을 지원함으로써 시스템 기동 시간을 획기적으로 단축하며, 소멸한 프로세스를 입양하여 좀비 프로세스 발생을 방지하는 안정성 (Stability)의 근간이다.

융합: 현대 리눅스 표준인 systemd는 단순한 초기화 도구를 넘어 로그 관리 (journald), 네트워크 관리 (networkd), 장치 관리 (udev) 등을 통합한 거대 시스템 관리 프레임워크로 진화하여 인프라 운영의 통합성 (Integration)을 제공한다.

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

개념: init 프로세스는 유닉스 계열 운영체제에서 커널이 부팅 과정의 마지막 단계에서 실행하는 첫 번째 사용자 프로세스다. 고정적으로 프로세스 ID (PID) 1번을 부여받으며, 시스템이 종료될 때까지 가장 마지막까지 살아남는다. 과거의 전통적인 SysV init 방식에서 현대의 이벤트 기반 병렬 처리 방식인 systemd로 주류가 변화했다.
필요성: 수많은 하드웨어 장치와 서비스 소프트웨어가 얽혀 있는 현대 시스템에서, 각 구성 요소를 '누가, 어떤 순서로' 실행할 것인가는 매우 복잡한 문제다. 예를 들어, 데이터베이스는 네트워크 드라이버가 로드된 후에 실행되어야 한다. init 프로세스는 이러한 서비스 간의 선후 관계를 정리하고, 시스템이 목표로 하는 동작 상태 (예: 다중 사용자 모드, 그래픽 모드)에 도달하도록 총괄 지휘하는 '마에스트로' 역할을 수행한다.
💡 비유: init 프로세스는 회사의 "창업자이자 총괄 관리자"와 같다. 회사가 설립될 때 가장 먼저 출근하여 부서(서비스)들을 만들고, 각 부서가 업무를 시작할 수 있게 사무실과 장비를 배정하며, 만약 부서장이 사퇴(프로세스 종료)하면 그 책임을 맡아 수습하는 것과 같다.
등장 배경:
1. SysV init의 직렬 실행 한계: 과거 방식은 서비스를 하나씩 차례대로 실행했기 때문에 부팅 속도가 매우 느렸다.
2. 현대 하드웨어의 동적 변화: USB나 핫플러그 장치처럼 부팅 후에 수시로 바뀌는 하드웨어 상태에 기민하게 반응하는 이벤트 기반 관리 도구가 필요해졌다.
ASCII 다이어그램: 부팅 시퀀스와 PID 1의 탄생 이 그림은 하드웨어 전원이 켜진 후 커널을 거쳐 최종적으로 사용자 영역의 첫 번째 프로세스인 init/systemd가 주도권을 잡는 과정을 시간순으로 보여준다.

 [ BIOS / UEFI ] ────▶ [ Boot Loader ] ────▶ [ Kernel Entry ]
                                                       │
                                         (Init Hardware)
                                                       │
                                         (Mount Root FS)
                                                       │
 [ User Space ] ◀───────────────────────────────┴──── [ PID 1 Start ]
      │                                                │
 (Runlevel 3/5) ◀── [ Load Services in Parallel ] ◀── [ init / systemd ]

[다이어그램 해설] 부팅 과정은 크게 하드웨어 초기화와 소프트웨어 초기화로 나뉜다. ① 커널은 메모리에 로드된 후 최소한의 하드웨어와 루트 파일 시스템을 준비한다. ② 이후 커널은 사용자 영역의 입구로서 /sbin/init (또는 systemd로의 심볼릭 링크)을 실행한다. 이 순간 PID 1번이 탄생하며, 운영체제의 통제권이 커널에서 사용자 영역으로 완전히 넘어온다. ③ 전통적인 init은 정해진 스크립트를 하나씩 실행했지만, 현대의 systemd는 서비스들 사이의 소켓 (Socket)을 미리 열어두는 등의 기법을 통해 의존 관계가 있는 서비스들을 동시에 '병렬 실행'한다. 이 혁신적인 단계가 현대 리눅스 부팅 속도를 수 초 내로 단축시킨 핵심 원동력이다.

📢 섹션 요약 비유: 도미노를 하나씩 쓰러뜨리는 구식 방식(SysV init)에서, 한 번에 여러 개의 도미노를 동시에 쓰러뜨리는 스마트 장치(systemd)로 진화한 것과 같습니다.

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

구성 요소 (표)

요소명	역할	내부 동작	프로토콜	비유
Unit (유닛)	systemd의 최소 관리 단위	서비스, 마운트, 소켓 등을 `.service`, `.target` 파일로 관리	Unit Configuration	부품 모듈
Target (타겟)	시스템 동작 상태의 묶음	여러 유닛을 그룹화하여 특정 Runlevel 모사	Target Unit	건물의 층(Floor)
Dependency (의존성)	서비스 간 선후 관계 정의	`After=`, `Requires=` 등을 통한 실행 순서 제어	DAG (Directed Acyclic Graph)	요리 레시피 순서
Socket Activation	지연 로딩 및 병렬화 지원	소켓 요청이 올 때까지 서비스 기동을 미루거나 선점	소켓 인터페이스 공유	예약 호출 시스템
Journald	시스템 통합 로그 관리	바이너리 형태의 고속 인덱싱 로그 기록	Binary Logging	블랙박스 기록 장치

ASCII 구조 다이어그램: systemd의 병렬 실행 및 의존성 그래프 구조 이 도식은 서비스들이 단순 나열이 아니라 복잡한 의존 관계(DAG)를 형성하고 있으며, systemd가 이를 어떻게 효율적으로 처리하는지 보여준다.

       ┌────────────────┐
       │ Multi-User│ (Target)
       └───┬───┬───┘
           │            │
   ┌───────▼───┴────────┐
   │ Network.target    │ (의존성 상위)
   └───┬───────┬────────┘
       │                │
┌──────▼───┐ ┌─▼────────┐
│  SSHD    │ │  Apache  │ (병렬 실행 가능)
└──────────┘ └──────────┘

[다이어그램 해설] systemd 아키텍처의 정수는 유닛 (Unit) 간의 의존성 관리다. ① 모든 서비스는 DAG (Directed Acyclic Graph, 방향성 비순환 그래프) 구조로 연결된다. ② 예를 들어 'Multi-User' 타겟에 도달하기 위해서는 'Network' 타겟이 먼저 완료되어야 한다는 관계가 설정되어 있다. ③ 하지만 systemd는 단순히 순서를 기다리는 것이 아니라, SSHD와 Apache처럼 상위 의존성(Network)만 충족되면 서로 상관없는 서비스들은 '동시에' 실행시킨다. 또한 소켓 활성화 (Socket Activation) 기법을 쓰면, 네트워크 서비스가 실제로 준비되기 전이라도 소켓만 미리 열어둠으로써 의존성이 있는 다른 서비스들이 기다리지 않고 즉시 기동을 시작할 수 있게 한다. 이는 부팅 병목을 제거하는 최첨단 오케스트레이션 기법이다.

심층 동작 원리 (The Orphan Adoption & Zombie Reap):
1. Orphan Adoption (고아 입양): 부모 프로세스가 자식보다 먼저 죽으면, 자식 프로세스는 '고아'가 된다. 이때 커널은 즉시 이 고아의 부모를 PID 1 (init/systemd)로 바꾼다.
2. Zombie Reaping (좀비 수거): 프로세스가 종료되면 최소한의 정보(종료 코드 등)를 남긴 좀비 상태가 된다. 부모가 wait() 시스템 호출로 이 정보를 읽어가야 완전히 사라지는데, 부모가 죽어버리면 좀비가 영원히 남을 수 있다. PID 1은 입양한 고아들이 죽을 때 성실하게 wait()를 호출하여 시스템에 좀비가 쌓이지 않도록 청소부 역할을 수행한다.
핵심 코드 (systemd 서비스 유닛 파일 예시)

[Unit]
Description=My Custom Web Service
After=network.target        # 네트워크가 준비된 후 실행

[Service]
ExecStart=/usr/bin/python3 /app/server.py
Restart=always              # 죽었을 때 자동으로 다시 살림
User=www-data
Group=www-data

[Install]
WantedBy=multi-user.target  # 멀티유저 모드일 때 자동 시작 등록

📢 섹션 요약 비유: 복잡한 부품들이 들어있는 레고 세트에서 설명서(유닛 파일)에 따라 가장 밑판부터 튼튼하게 쌓아 올리되, 양손(병렬 처리)을 써서 빠르게 조립하는 과정과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

심층 기술 비교: SysV init vs systemd

항목	SysV init	systemd	비고
실행 방식	직렬 (Serial) 스크립트 실행	병렬 (Parallel) 유닛 실행	부팅 속도 결정
상태 관리	Runlevel (0-6)	Target (Unit)	유연성 차이
의존성 해결	수동 번호 지정 (S99...)	선언적 의존성 (`After=`)	관리 복잡도
모니터링	실행 후 추적 어려움	cgroups 기반 완벽 추적	프로세스 관리
부가 기능	초기화 전용	로그, 네트워크, 장치 관리 통합	시스템 도구 통합

과목 융합 관점:
1. 가상화/컨테이너 (Docker): 도커 컨테이너는 대개 PID 1번을 사용자가 지정한 프로세스(예: /usr/bin/python)가 갖는다. 만약 이 프로세스가 좀비 수거 기능을 갖추지 못하면 컨테이너 내부에 좀비가 가득 차는 'PID Exhaustion' 문제가 발생한다. 이를 위해 tini 같은 경량화된 init 프로세스를 컨테이너의 입구로 사용하기도 한다.
2. 보안 (Security): systemd는 각 서비스 유닛 파일 내에서 PrivateTmp=yes, NoNewPrivileges=yes 같은 보안 옵션을 선언적으로 설정할 수 있게 하여, 운영체제 레벨의 샌드박싱 (Sandboxing)을 손쉽게 구현할 수 있게 돕는다.
ASCII 다이어그램: Cgroups를 이용한 프로세스 추적 이 도식은 systemd가 단순히 PID만 아는 것이 아니라, cgroups를 통해 자식 프로세스들까지 하나의 그룹으로 묶어 완벽하게 제어하는 원리를 보여준다.

 [ systemd (PID 1) ]
                        │
    ┌─────┴─────────────┐
 [ Service A ] [ Service B ] (Cgroup Layer)
    │                   │
 ┌──┴──┐       ┌──┴──┬──┐
[P1]  [P2]    [P3]  [P4][P5] (Actual Processes)

[다이어그램 해설] 전통적인 init은 서비스가 자식을 낳고 그 자식이 또 자식을 낳으면 추적이 불가능했다. 하지만 systemd는 리눅스 커널의 Cgroups (Control Groups) 기술을 활용한다. ① 서비스 A가 실행되면 systemd는 전용 cgroup 폴더를 만든다. ② 이후 서비스 A가 낳은 모든 자식 프로세스는 부모가 누구든 상관없이 이 cgroup 폴더에 강제로 묶인다. ③ 덕분에 관리자가 systemctl stop A를 내리면, systemd는 cgroup 폴더를 뒤져 숨어있는 모든 손자 프로세스까지 빠짐없이 찾아내어 종료시킬 수 있다. 이는 '통제 불가능한 프로세스'를 원천 차단하는 현대 운영체제의 강력한 관리 기법이다.

📢 섹션 요약 비유: 아이들이 흩어져 놀아도 반별로 이름표(cgroups)를 붙여두어, 선생님(systemd)이 종을 치면 반 전체 아이들이 한꺼번에 모이게 하는 것과 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오:
1. 부팅 속도 최적화: 서버의 부팅 속도가 비정상적으로 느린 상황. 기술사적으로 systemd-analyze blame 명령을 통해 어떤 유닛이 시간을 가장 많이 잡아먹는지 정량적으로 분석한다. 의존성 관계가 잘못 설정되어 불필요한 대기가 발생하는 지점을 찾아 After= 설정을 수정하거나 소켓 활성화를 도입하여 기동 속도를 개선한다.
2. 서비스 자동 복구 전략: 웹 서버가 간헐적으로 죽을 때, 사람이 직접 살리는 대신 유닛 파일에 Restart=always와 RestartSec=5를 설정한다. 이를 통해 장애 발생 시 5초 내에 시스템이 스스로 서비스를 복구하게 하여 서비스 가용성 (SLO)을 확보한다.
3. 좀비 프로세스 창궐 대응: 시스템에 좀비 프로세스가 수천 개 쌓여 더 이상 프로세스를 생성할 수 없는 상황. PID 1번이 제 역할을 수행하고 있는지 확인하고, 만약 컨테이너 환경이라면 애플리케이션 코드를 수정하거나 dumb-init 같은 도구를 도입하여 좀비 수거 로직을 강제 주입한다.
도입 체크리스트:
- 사용자 정의 서비스가 적절한 타겟(multi-user.target)에 연결되어 있는가?
- 서비스 간의 선후 관계가 After=와 Requires=로 명확히 정의되어 있는가?
- 보안을 위해 서비스 실행 권한이 특정 일반 사용자로 제한되어 있는가?
- 로그 누적으로 인한 디스크 고갈을 막기 위해 journald 보관 정책이 설정되어 있는가?
안티패턴:
- Hard-coded Sleep: 서비스 간 순서를 맞추기 위해 쉘 스크립트에 sleep 30 같은 코드를 넣는 행위. 시스템 상태에 따라 30초가 부족하거나 과할 수 있으므로, 반드시 systemd의 의존성 옵션을 사용해야 한다.
- Direct Process Execution: /etc/rc.local에 직접 명령어를 넣는 구식 방식. 이 방식은 systemd의 통합 관리, 자동 복구, 로그 수집 기능을 전혀 활용할 수 없게 만든다.
ASCII 운영 플로우: systemd를 통한 서비스 생명주기 관리 이 순서도는 관리자가 명령을 내렸을 때 systemd 내부에서 어떤 판단과 절차를 거쳐 서비스 상태가 전이되는지 보여준다.


 [ Admin Command  / 관리자 명령] --▶ [ Unit File Parsing  / 유닛 파일 구문 분석] --▶ [ Dependency Check  / 의존성 검사]
                                                       │
 [ Running ] ◀── [ ExecStart  / ExecStart] ◀── [ Success?  / 성공?] ◀── [ Condition Check  / 조건 검사]
      │                                                │
 [ Crash!  / 충돌!] --▶ [ Restart Policy?  / 재시작 정책?] ----┘
                                                       │
 [ Stop Command  / 정지 명령] --▶ [ SIGTERM  / SIGTERM] --▶ [ SIGKILL  / SIGKILL] --▶ [ Dead  / 종료됨]

[다이어그램 해설] systemd의 운영은 선언적(Declarative)이다. 관리자가 실행 명령을 내리면 ① systemd는 유닛 파일을 읽어 실행 조건을 확인한다. ② 의존 관계에 있는 다른 서비스가 이미 실행 중인지 체크하고, 필요하다면 그들부터 먼저 실행시킨다. ③ 실행 후에는 프로세스의 생사를 지속적으로 감시한다. 만약 프로세스가 죽으면 'Restart' 정책에 따라 다시 살릴지 결정한다. ④ 종료 시에는 먼저 정중하게 SIGTERM을 보내 안전한 종료를 유도하고, 일정 시간 응답이 없으면 강력한 SIGKILL을 보내 자원을 강제 회수한다. 이 체계적인 절차는 시스템 관리를 '예측 가능한' 영역으로 끌어올린다.

📢 섹션 요약 비유: 주먹구구식으로 가게를 여는 게 아니라, 정해진 체크리스트(유닛 파일)에 따라 준비를 마치고 손님을 맞이하며, 문제가 생기면 매뉴얼대로 즉시 조치하는 전문 점장과 같습니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

정량/정성 기대효과 (표)

구분	도입 전 (SysV init)	도입 후 (systemd)	개선 효과
부팅 시간	1~2분 (직렬 처리)	5~10초 (병렬 처리)	기동 속도 90% 이상 단축
운영 안정성	수동 복구 필요	자동 재시작 정책 적용	무중단 서비스 유지력 향상
관리 통합성	로그, 설정 등이 파편화됨	systemctl/journalctl로 통합	관리 복잡도 및 학습 곡선 완화

미래 전망:
- Universal init: 리눅스 진영을 넘어 다양한 POSIX 시스템들이 systemd의 표준을 따르거나 유사한 이벤트 기반 아키텍처를 도입하고 있어, 크로스 플랫폼 운영 지식이 상향 평준화될 것이다.
- Serverless Integration: 서버리스 컴퓨팅의 '콜드 스타트' 문제를 해결하기 위해, systemd의 소켓 활성화 기법을 극단적으로 최적화하여 0.1초 내에 서비스를 깨우는 기술이 더욱 발전할 것이다.
참고 표준:
- LSB (Linux Standard Base): 리눅스 표준 기반 및 초기화 규격
- Systemd Interface Stability Promise: 하위 호환성 보장을 위한 API 표준
📢 섹션 요약 비유: 단순히 첫 번째 프로세스라는 타이틀을 넘어, 이제는 시스템 전체의 심장과 신경망을 통합 관리하는 '운영체제 안의 운영체제'로 거듭나고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
PID 1	모든 프로세스의 최상위 부모로서 init/systemd가 갖는 유일한 식별자
좀비 프로세스 (Zombie)	종료되었으나 부모가 수거하지 않은 자원으로, PID 1의 핵심 정화 대상
Cgroups	systemd가 하위 프로세스들을 그룹 단위로 추적하고 제어할 수 있게 돕는 커널 기술
Target / Runlevel	시스템의 전체적인 동작 목표 상태를 정의하는 논리적 단위
Journald	systemd와 밀접하게 결합하여 시스템의 모든 로그를 통합 수집하는 도구

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

init은 컴퓨터 세상의 **'제일 큰 형님'**이에요. 컴퓨터가 켜지면 제일 먼저 일어나서 다른 동생(프로세스)들을 깨워주고 자리를 정해줘요.
만약 어떤 동생이 길을 잃거나 갈 곳이 없어지면(부모가 없어지면), 이 큰 형님이 친절하게 새로운 부모님이 되어 돌봐준답니다.
systemd라는 똑똑한 형님은 여러 동생을 한꺼번에 깨우는 마법을 써서, 우리가 컴퓨터를 켰을 때 아주 빠르게 화면이 나오게 도와줘요!