Linux의 systemd가 세월이 흘러도 여전히 분열적인 이유

systemd가 세상에 등장한 지 10년이 되었지만, 리눅스 커뮤니티 내에서 이에 대한 의견은 여전히 팽팽하게 맞서고 있습니다. 수많은 주요 리눅스 배포판에서 systemd를 채택했음에도 불구하고, 강력한 반대 여론은 좀처럼 수그러들지 않고 있습니다.

리눅스 부팅 과정

컴퓨터 전원을 켜면 하드웨어가 먼저 작동을 시작합니다. 그다음 컴퓨터 종류에 따라 부트 섹터 또는 마스터 부트 레코드(MBR)가 실행되거나, 확장 가능한 펌웨어 인터페이스(UEFI)가 구동됩니다. 이러한 과정의 최종 목표는 리눅스 커널을 실행하는 것입니다.

커널은 메모리에 로드된 후 압축을 풀고 초기화 과정을 거칩니다. 이후 임시 파일 시스템이 생성되는데, 보통 initramfs 또는 initrd라는 유틸리티를 통해 RAM에 만들어집니다. 이 단계를 통해 필요한 드라이버를 확인하고 로드할 수 있습니다. 이어서 사용자 공간 파일 시스템이 로드 및 준비되어 사용자 공간 환경을 설정하게 됩니다.

사용자 공간 환경 설정은 init 프로세스에 의해 이루어집니다. 이는 커널이 사용자 공간에서 실행하는 첫 번째 프로세스이며, 프로세스 ID(PID) 1을 가집니다. 다른 모든 프로세스는 이 init 프로세스의 직간접적인 자식 프로세스입니다.

systemd가 등장하기 전에는 유닉스 시스템 V 초기화가 init 프로세스의 기본 표준이었습니다. 다른 선택지도 있었지만, 시스템 V init는 대부분의 버클리 소프트웨어 배포(BSD) 파생 배포판 외의 시스템에서 사용되었습니다. 이는 리눅스의 정신적 조상인 시스템 V 유닉스에서 직접 가져온 것이기 때문에 많은 이들이 ‘공식적인’ init 방식으로 여겼습니다.

init 프로세스는 운영 체제가 원활하게 작동하고 사용자와 상호작용할 수 있게 만드는 데 필요한 모든 데몬 및 서비스를 실행하는 역할을 합니다. 이러한 데몬들은 네트워크 스택과 같은 작업을 처리하여 컴퓨터 내부의 다양한 하드웨어를 활성화하고 부팅 화면을 제공합니다.

이러한 백그라운드 프로세스 중 상당수는 시작된 후에도 계속 실행됩니다. 이벤트 정보를 기록하거나, 하드웨어 변경 사항을 관찰하거나, 사용자 로그인을 관리하는 등의 역할을 수행합니다. 따라서 init 시스템은 서비스를 관리하는 기능을 필수로 포함합니다.

PID가 1인 프로세스를 확인하려면 ps 명령과 함께 f(전체 형식 목록) 및 p(PID) 옵션을 사용할 수 있습니다.

ps -fp 1

위 결과에서 PID 1의 프로세스가 systemd임을 확인할 수 있습니다. 만자로 리눅스에서 같은 명령을 실행하면 다른 결과가 나타납니다. PID 1의 프로세스는 /sbin/init로 식별되며, 이 파일은 systemd에 대한 심볼릭 링크임을 알 수 있습니다.

ps -fp 1
ls -hl /sbin/init

ps 명령에 ppid(상위 프로세스 ID) 옵션을 사용하면 systemd에서 직접 실행한 프로세스를 확인할 수 있습니다.

ps -f --ppid 1

아래 이미지에서 볼 수 있듯이, 그 목록은 꽤 깁니다.

대안들

여러 프로젝트에서 기존의 시스템 V init를 대체하기 위한 대안을 만들려고 시도했습니다. 시스템 V init의 주요 문제점 중 하나는 모든 프로세스가 순차적으로 시작된다는 점이었습니다. 따라서 부팅 순서의 효율성을 개선하기 위해 많은 대안 프로젝트에서는 병렬 처리를 사용하여 프로세스를 동시에 비동기식으로 시작합니다.

몇 가지 대안에 대한 정보는 다음과 같습니다.

업스타트(Upstart): 캐노니컬에서 개발했으며, 우분투 9.10에서 사용되었습니다. 레드햇, 레드햇 엔터프라이즈 리눅스(RHEL) 6, 센트OS 6, 그리고 페도라 9에서도 사용되었습니다.
루닛(runit): 프리BSD 및 기타 BSD 파생 제품, macOS, 솔라리스, 그리고 리눅스 시스템에서도 실행됩니다. 또한 보이드 리눅스의 기본 초기화 시스템입니다.
s6-linux-init: 시스템 V init의 대안으로, 유닉스 철학을 밀접하게 따르도록 설계되었습니다. 이는 종종 “하나의 일을 하고, 그 일을 잘 하라”는 말로 요약됩니다.

기능과 설계 면에서 여러 가지 대안들이 존재했지만, 그 어떤 것도 systemd만큼의 논쟁을 불러일으키지는 못했습니다.

systemd의 등장

systemd는 2010년에 처음 출시되었고, 2011년에 페도라에서 채택되었습니다. 이후 많은 배포판에서 사용되기 시작했습니다. 이 시스템은 레나르트 포터링케이 시버스, 두 명의 레드햇 소프트웨어 엔지니어에 의해 개발되었습니다.

systemd는 단순히 init 시스템의 대체재 그 이상입니다. 오히려 시스템 초기화, 데몬 및 서비스 관리, 로깅 및 저널링, 그리고 과거에 리눅스의 전용 모듈에서 처리되던 다양한 기능을 담당하는 약 70개의 바이너리 모음입니다. 이 바이너리 중 대부분은 시스템 초기화와 직접적인 관련이 없습니다.

systemd에서 제공하는 몇 가지 데몬은 다음과 같습니다.

  • systemd-udevd: 물리적 장치를 관리합니다.
  • systemd-logind: 사용자 로그인을 관리합니다.
  • systemd-resolved: 로컬 애플리케이션에 대한 네트워크 이름 확인을 제공합니다.
  • systemd-networkd: 네트워크 장치를 관리 및 감지하고, 네트워크 구성을 관리합니다.
  • systemd-tmpfiles: 휘발성 및 임시 파일과 디렉토리를 생성, 삭제 및 정리합니다.
  • systemd-localed: 시스템 로케일 설정을 관리합니다.
  • systemd-machined: 가상 머신과 컨테이너를 감지하고 모니터링합니다.
  • systemd-nspawn: 경량 네임스페이스 컨테이너에서 명령이나 다른 프로세스를 시작할 수 있게 하여, chroot와 유사한 기능을 제공합니다.

이는 빙산의 일각일 뿐이며, 이것이 바로 논쟁의 핵심입니다. systemd는 반대자들의 주장대로 init 시스템에 요구되는 범위를 넘어선 과도한 기능을 제공합니다.

“너무 크고, 너무 많은 일을 한다”

systemd 반대자들은 systemd에 포함된 방대하고 다양한 기능들을 지적합니다. 이 모든 기능들은 리눅스에 이미 존재했으며, 일부 기능들은 새로운 접근 방식이나 개선이 필요했을 뿐입니다. 그러나 이 모든 기능을 init 시스템의 일부로 묶는 것은 구조적으로 이해하기 어렵다는 주장입니다.

systemd는 너무 많은 중요한 기능에 대한 단일 실패 지점이라고 비판받고 있지만, 이 주장이 완전히 정당화되는 것 같지는 않습니다. 분명히 systemd는 작은 도구를 조합하여 큰 소프트웨어를 만드는 유닉스 철학에 반하는 것처럼 보입니다. systemd는 엄밀히 말해 모놀리식(하나의 거대한 바이너리)은 아니지만(여러 개의 바이너리로 구성됨), 하나의 큰 우산 아래에 여러 이질적인 관리 도구와 명령이 포함되어 있습니다.

비록 단일체는 아닐지라도, 그 규모가 크다는 것은 사실입니다. 규모를 가늠하기 위해, 커널 5.6.15 코드베이스와 systemd master 브랜치의 텍스트 줄 수를 세어 보았습니다. GitHub 저장소에서 확인했습니다.

이 방법은 다소 조잡한 측정 방법이었습니다. 코드 줄뿐만 아니라 텍스트 줄을 모두 계산했기 때문입니다. 따라서 주석, 문서 등 다른 모든 것이 포함되었습니다. 그럼에도 불구하고, 비슷한 비교를 통해 단순한 척도를 얻을 수 있었습니다.

( find ./ -name '*.*' -print0 | xargs -0 cat ) | wc -l

커널에는 약 2800만 줄(정확히 27,784,340줄)의 텍스트가 있었습니다. 반면 systemd는 1,349,969줄, 즉 약 140만 줄이었습니다. 이렇게 단순한 방식으로 비교해 보면, systemd가 커널 크기의 약 5%를 차지하는 것을 알 수 있으며, 이는 엄청난 수치입니다!

또 다른 비교로, 아치 리눅스 배포판에서 사용되는 시스템 V init 최신 구현의 줄 수는 1,721줄이었습니다.

레나르트 포터링은 전기전자공학회(IEEE) 컴퓨터 학회, 휴대용 운영 체제 인터페이스(POSIX) 표준을 고려하지 않는 것으로 보입니다. 실제로 그는 개발자들이 POSIX를 무시하도록 장려했습니다.

“따라서, 리눅스 프로그래밍 인터페이스 복사본을 가져와 POSIX 호환성에 대한 모든 것을 무시하고 멋진 리눅스 소프트웨어를 만드세요. 매우 편안해질 겁니다!”

일부에서는 systemd가 레드햇에서만 이득을 보는 레드햇 프로젝트임에도 불구하고, 더 넓은 리눅스 세계에 강제로 적용되고 있다고 비판했습니다. 물론, systemd는 레드햇에서 개발되었고 레드햇이 관리하고 조정합니다. 하지만 1,321명의 기여자 중 레드햇에서 근무하는 사람은 극히 일부에 불과합니다.

그렇다면 레드햇이 얻는 이점은 무엇일까요?

짐 화이트허스트, IBM의 사장으로 재직하기 전에는 레드햇 CEO였는데, 그는 다음과 같이 말했습니다.

“레드햇은 여러 선택지를 검토했고, 레드햇 엔터프라이즈 리눅스 6에는 캐노니컬의 Upstart를 사용했었습니다. 최종적으로 우리는 systemd가 우리가 보고 있는 문제를 해결하기 위해 확장성, 단순성, 확장성 및 명확히 정의된 인터페이스를 제공하는 최고의 아키텍처라고 판단했습니다. 오늘뿐 아니라 미래를 내다보면서요.”

화이트허스트는 또한 임베디드 시스템에서도 이점을 발견했다고 말했습니다. 레드햇은 “특히 안정성과 신뢰성이 가장 중요한 통신 및 자동차 산업에서 세계 최대의 임베디드 공급업체”와 파트너 관계를 맺고 있습니다.

기술적으로는 그럴듯한 이유처럼 보입니다. 안정성에 대한 회사의 요구를 이해할 수 있으며, 레드햇이 자사의 이익을 추구하는 것이 비합리적이라고 할 수는 없지만, 다른 모든 사람들도 그들의 결정을 따라야 할까요?

systemd ‘쿨에이드’를 마시고 있습니까?

systemd 반대자 중 일부는 배포판과 사람들이 레드햇의 주장을 맹목적으로 따르고 systemd를 채택하고 있다고 주장합니다.

하지만 ‘쿨에이드를 마신다’는 표현처럼 상황이 단순하지 않습니다. 1978년 컬트 지도자 짐 존스가 900명이 넘는 추종자들에게 시안화물이 섞인 포도맛 음료를 마시고 자살하도록 강요한 사건 때문에 이 문구가 생겨났습니다. 실제로는 Flavor Aid라는 음료를 마셨지만, 이후 Kool-Aid가 이 사건과 연관되게 되었습니다.

또한 리눅스 배포판이 레드햇을 맹목적으로 따르는 것도 아닙니다. 이들은 충분한 고민 끝에 systemd를 채택하고 있습니다. 데비안에서는 메일링 리스트를 통해 이 문제에 대해 오랫동안 격렬한 논쟁이 있었습니다. 그러나 2014년 커뮤니티는 systemd를 기본 초기화 시스템으로 채택하기로 결정했지만, 대안도 계속 지원하고 있습니다.

데비안은 레드햇, 페도라 또는 센트OS에서 파생되지 않았다는 점에서 매우 중요한 예입니다. 레드햇이 데비안에 영향을 미친 부분은 전혀 없습니다. 그리고 PID 1에서 알 수 있듯이, 데비안은 우분투와 그 파생물을 포함한 수많은 후손을 가지고 있습니다.

데비안 커뮤니티의 결정은 상당히 광범위하게 이루어졌습니다. 커뮤니티는 격렬하게 토론을 벌였고, 콩도르세 투표 방식을 사용하여 투표를 진행했습니다. 커뮤니티는 이러한 결정을 가볍게 여기지 않았습니다.

2019년 12월에는 systemd에 계속 집중하고 대안을 계속 탐색하기 위해 다시 투표를 실시했습니다. 맹목적으로 따르는 대신, 이러한 과정은 실제로 민주주의와 선택의 자유를 보여주는 훌륭한 예입니다.

선택의 제약

일반적으로 사용자는 특정 리눅스 배포판에서 systemd를 사용할지 여부를 선택할 수 없습니다. 오히려 사용 중인 배포판 자체가 systemd를 사용할지 여부를 결정하며, 사용자는 단순히 자신이 선호하는 리눅스 배포판을 선택할 수 있을 뿐입니다. 좋아하는 뮤지션이 장르를 바꾼 것처럼, 이 상황은 불편하게 느껴질 수 있습니다.

데비안, 페도라, 센트OS, 우분투, 아치, 솔러스, 그리고 오픈수세 등을 사용하는 사람들이나 systemd 채택에 반대하는 사람들은 자신이 선택한 배포판을 사용하는 데 어려움을 느낄 수 있습니다. POSIX에 대한 아키텍처적 선택, 범위 확장, 또는 무시에 대해 강한 불만을 가지고 있다면, 해당 배포판을 계속 사용하는 것이 더 이상 의미가 없을 수 있습니다.

물론 이 문제에 대한 의견은 스펙트럼처럼 다양합니다. 한쪽 끝에는 문제를 잘 이해하지 못하거나 아예 관심이 없는 사람들이 있고, 다른 한쪽 끝에는 열렬한 반대자들이 있습니다. 중간에는 변화를 좋아하지는 않지만, 배를 떠날 만큼 문제라고 생각하지 않는 사람들이 있습니다. 그렇다면, 자신의 취향이나 원칙 때문에 선택한 배포판에 머무를 수 없는 배포판 난민들은 어떻게 해야 할까요?

불행히도 원하는 초기화 시스템을 설치하는 것은 그리 간단하지 않습니다. 모든 사람들이 그럴 만한 기술적인 능력을 가지고 있는 것은 아닙니다. 게다가 GNOME과 같은 애플리케이션이나 데스크톱 환경에 systemd에 대한 의존성이 있다는 점도 문제입니다.

다른 배포판으로 옮기는 것은 어떨까요? 데부안처럼 systemd를 채택한 배포판에서 파생된 비systemd 배포판도 있습니다. 데부안을 사용하는 것은 상위 배포판과 비슷해야 하지만, 모든 비systemd 포크가 다 그런 것은 아닙니다. 예를 들어, 페도라를 사용하다가 안티엑스, 젠투, 또는 슬랙웨어로 이동한다면, 매우 다른 경험을 하게 될 것입니다.

현실에 대한 인정

systemd가 하는 일(프로세스에 대한 간단하고 표준화된 제어 메커니즘)에 대해서는 긍정적입니다. 하지만 바이너리 로그를 사용하는 이유에 대해서는 이해가 가지 않습니다. 또한 일부 기능(홈 폴더 변경 등)은 개인적으로 싫어합니다. (누가 그런 기능을 필요로 했는지 의문입니다.)

데비안과 같은 배포판은 현명한 선택을 하고 있으며, 선택의 여지를 남겨두기 위해 대안을 모색하고 있습니다. 하지만 systemd는 장기적으로 계속 사용될 가능성이 높습니다.

만약 다른 사람들을 위해 리눅스 시스템을 관리하고 있다면, 시스템 V init처럼 systemd를 배워두는 것이 좋습니다. 그러면 어떤 상황에서도 업무를 수행할 수 있을 것입니다.

개인적으로 리눅스만 사용하고 있습니까? 그렇다면 자신의 기술적 요구 사항을 충족하고 리눅스 철학을 보완하는 배포판을 선택하는 것이 좋습니다.