Arch 기반 배포판은 무엇을 바꾸는가, 계층별로 살펴보기

CachyOS 서브레딧에 CachyOS와 Omarchy 중 무엇을 설치해야 하냐고 물으면, 가장 많은 추천을 받은 두 답글은 추천이 아닙니다. 하나는 "Asking this in related to CachyOS sub…bruh."이고, 다른 하나는 Honda 포럼에 들어가 Accord와 Camry 중 무엇을 사야 하냐고 묻는 것에 비유합니다.

두 답글 모두 옳으며, 그 이유는 태도가 아니라 구조에 있습니다. Arch 기반 배포판의 차이는 결국 각 프로젝트가 순정 Arch의 어디를 수정하느냐로 귀결됩니다. 여기서 비교하는 배포판들의 경우, 그 수정은 대체로 다섯 곳에 몰려 있습니다. 설치 프로그램, 커널과 컴파일 대상, 패키지 저장소, 데스크톱 셸과 설정, 그리고 업데이트와 롤백 정책입니다. CachyOS와 Omarchy는 서로 다른 계층에서 가장 큰 변화를 줍니다.

요약

• 여기서 비교하는 배포판들의 경우, 의미 있는 차이는 대체로 다섯 계층에 들어갑니다. 설치 프로그램, 커널과 컴파일 대상, 패키지 저장소, 데스크톱 셸과 설정, 업데이트와 롤백 정책입니다.
• 프로젝트는 한 계층만 바꾸고 나머지 넷은 그대로 둘 수 있습니다. 두 배포판이 모두 "Arch 기반"이면서도 공유하는 게 거의 없을 수 있는 이유가 여기에 있습니다.
• CachyOS는 커널/컴파일 계층과 저장소 계층을 크게 바꾸고, 설치 프로그램을 다듬으며, 데스크톱 셸은 강제하지 않습니다. 셸은 설치 시 직접 고릅니다.
• Omarchy는 데스크톱 셸 계층과 업데이트 정책 계층을 크게 바꾸고, 자체 패키지 채널을 운영하며, 성능을 이유로 커널이나 컴파일 대상을 바꾸지는 않습니다.
• 계층은 따로따로 채택할 수 있습니다. CachyOS는 기존 Arch 설치에 자체 저장소를 추가하는 방법을 문서화했고, 사람들은 Omarchy에서 그 경로를 시도해 엇갈린 결과를 얻었습니다.

이 글이 결론 내리지 않는 것

이 질문과 혼동될 만큼 가까운 질문이 셋 있는데, 각각은 분류 체계가 제공할 수 없는 다른 종류의 근거를 필요로 합니다.

• CachyOS가 전반적으로 더 빠른지 여부. 그 질문에는 별도의 근거 자료와 별도의 글이 있습니다.
• 둘 중 무엇을 설치해야 하는지.
• 존재하는 모든 Arch 파생 배포판. 여기서는 다섯 개를 다루며, 이 다섯 계층은 이 그룹을 위한 비교 모델이지 모든 Arch 파생판을 망라하는 분류 체계가 아닙니다.

이 비교가 추적하는 다섯 계층

여기서 비교하는 파생판들의 경우, 의미 있는 차이의 대부분은 다섯 계층으로 설명됩니다. 설치 프로그램, 커널과 컴파일 대상, 패키지 저장소, 데스크톱 셸과 설정, 업데이트와 롤백 정책입니다. 프로젝트는 그중 하나를 바꾸고 나머지 넷은 Arch가 제공하는 그대로 둘 수 있습니다.

설치 프로그램은 맨 하드웨어에서 부팅된 시스템에 이르는 경로이며, 프로젝트가 사용자에게 얼마나 많은 선택을 넘길지 결정하는 계층입니다. 순정 Arch는 수동 설치 경로를 문서화하고 라이브 ISO에 안내형 설치 프로그램 archinstall도 포함하지만, 파생판은 그 경험을 자체 안내형 기본값으로 대체할 수 있습니다. 중요한 것은 그 설치 프로그램이 사용자를 대신해 무엇을 정하느냐입니다. 파일 시스템, 부트로더, 암호화, 드라이버, 데스크톱. 기본값 하나하나가 누군가가 취한 입장입니다.

커널과 컴파일 대상 계층은 흔히 뒤섞이는 세 가지를 다룹니다. 어떤 커널 빌드로 부팅하는가. 패키지가 어떤 CPU 명령어 집합을 대상으로 컴파일되었는가. 어떤 스케줄러가 무엇을 언제 실행할지 결정하는가.

컴파일 대상은 패키지가 빌드된 마이크로아키텍처 수준입니다. x86-64는 모든 x86-64 프로세서가 지원하는 기준선입니다. x86-64-v3는 AVX, AVX2, BMI1, BMI2, FMA 등의 기능을 추가하고, x86-64-v4는 v3 위에 AVX-512 요구 사항을 더합니다. 어느 수준으로 빌드된 패키지든 필요한 기능 집합이 없는 프로세서에서는 실행되지 않습니다. 스케줄러는 실행 가능한 작업 중 어느 것이 다음에 프로세서를 차지할지 결정하며, 스케줄러마다 처리량과 대화형 반응성의 비중을 다르게 둡니다. 파생판은 셋 모두를 바꿀 수도, 하나만 바꿀 수도, 아무것도 바꾸지 않을 수도 있습니다.

패키지 저장소 계층은 출처의 문제입니다. 누가 빌드한 패키지를 받는지, 얼마나 최신인지, 그것이 도착하는 채널을 누가 통제하는지입니다. 순정 Arch는 core, extra, multilib에서 바이너리를 가져오며, 그 옆에는 직접 컴파일하는 빌드 레시피인 AUR이 있습니다. 파생판은 그 위에 자체 저장소를 얹거나, Arch 저장소 앞에 의도적인 지연을 두거나, 둘 다 할 수 있습니다.

데스크톱 셸과 설정 계층은 화면에 무엇이 나타나고 어떻게 배치되는지에 관한 것이며, 사람들이 용어에 걸려 넘어지는 지점입니다. KDE Plasma나 GNOME 같은 데스크톱 환경은 완전한 패키지입니다. 창 관리, 패널, 파일 관리자, 설정, 애플리케이션까지 갖췄습니다. i3 같은 타일링 창 관리자나 Hyprland 같은 타일링 Wayland 컴포지터는 완전한 데스크톱 모음을 제공하지 않고 창 배치만 담당하며, 바, 런처, 알림, 잠금 화면은 별개의 조각으로 남깁니다. 파생판은 셸을 강제할 수도, 메뉴를 제공할 수도, 아무 입장도 취하지 않을 수도 있습니다.

업데이트와 롤백 계층은 시스템이 어떻게 앞으로 나아가고, 잘못된 곳으로 갔을 때 어떻게 돌아오는지를 다룹니다. 순정 Arch에서는 둘 다 사용자의 몫입니다. 원할 때 pacman -Syu를 실행하고, 복구는 패키지 캐시나 직접 구성한 스냅샷 체계로 합니다. 파생판은 그 명령을 감싸거나, 막거나, 그대로 둘 수 있고, 스냅샷이 저렴하도록 파일 시스템을 배치해 복구를 기본값으로 만들 수도 있습니다. Btrfs 서브볼륨 구성이 사 주는 것이 바로 그것입니다. 스냅샷은 서브볼륨 하나의 특정 시점 복사본이며, 부트로더와 통합하면 파생판은 그 스냅샷을 복구 선택지로 노출할 수 있습니다.

CachyOS가 바꾸는 것

CachyOS는 커널과 컴파일 대상 계층 그리고 패키지 저장소 계층을 크게 바꾸고, 설치 프로그램을 다듬으며, 데스크톱 셸은 강제하지 않습니다. 자체 커널 빌드를 제공하고 Arch의 패키지를 더 새로운 CPU 기능 수준에 맞춰 다시 컴파일한 다음, 화면에 무엇이 나타날지는 설치하는 사람에게 맡깁니다.

설치 프로그램에서 데스크톱, 파일 시스템, 커널은 물론 패키지와 부트 관리자까지 고를 수 있고, 하드웨어 감지 도구가 발견한 장치에 맞는 드라이버를 설치합니다. 프로젝트의 주장은 설치 프로그램 안이 아니라 그 아래에 있습니다.

기본 linux-cachyos 커널은 Clang ThinLTO와 AutoFDO 프로파일링으로 빌드되며, 이 계열은 BORE, EEVDF, BMQ를 선택 가능한 스케줄러로 제공합니다. 별도로, 새 커널을 빌드하지 않고 사용자 공간에서 BPF 스케줄러를 로드하는 프레임워크인 sched-ext도 지원합니다. 둘은 다릅니다. sched-ext는 실행 중에 스케줄러를 교체하는 것이지, 그 목록의 네 번째 항목이 아닙니다.

CachyOS는 또한 Arch의 패키지를 x86-64-v3, x86-64-v4, Zen4+용으로 다시 컴파일하며, 위키에서는 기준선 대비 x86-64-v3에서 5%에서 20%의 향상을 주장합니다. 이는 CachyOS가 자기 작업에 대해 내놓은 자체 수치이지 독립적인 측정이 아닙니다. 다시 빌드된 패키지는 Arch의 core, extra, multilib를 대체하는 것이 아니라 그 위에 얹힌 CachyOS 저장소에 있습니다. 대체 대신 계층화하면 출처가 읽기 쉬운 상태로 유지됩니다. 어떤 패키지든 어느 채널이 빌드했는지 여전히 말할 수 있습니다.

데스크톱 셸은 CachyOS가 강제하지 않는 계층입니다. 환경은 직접 고르지만, 몇몇 선택지는 CachyOS가 관리하는 설정이나 dotfiles와 함께 제공됩니다. 온라인 설치 프로그램은 KDE Plasma, GNOME, Hyprland, Niri, Sway, Xfce를 포함해 열일곱 개 이상의 환경을 제공하며, 선택은 사용자의 몫입니다. CachyOS Hello와 Kernel Manager는 시스템 관리 유틸리티이지 셸이 아닙니다.

CachyOS는 자체 업데이트 래퍼를 요구하지 않습니다. 직접 pacman -Syu를 실행하는 것이 문서화된 경로로 남아 있으며, Shelly, Octopi, 오프라인 업데이트 같은 선택 도구도 있습니다. Btrfs에 설치하면 CachyOS는 별도의 서브볼륨을 배치하고 복구 스냅샷에 Snapper를 사용하며, 지원되는 부트로더 구성에서는 그 스냅샷을 복구용으로 노출할 수 있습니다.

읽기

CachyOS는 정말 더 빠를까? 성능 향상은 실제로 어디에서 오는가

Omarchy가 바꾸는 것

Omarchy는 데스크톱 셸 계층과 업데이트 정책 계층을 크게 바꾸고, 자체 패키지 채널을 제공하며, 성능을 이유로 커널이나 컴파일 대상을 바꾸지는 않습니다. 고정된 데스크톱 하나를 설치하고, pacman을 사용자에게 맡기는 대신 업데이트 명령의 주도권을 가져갑니다.

Omarchy는 자체 ISO에서 설치되며, 디스크 전체 또는 다른 운영체제 옆의 빈 공간에 설치할 수 있고, 기본적으로 디스크를 암호화합니다. 설치 프로그램은 데스크톱에 대해 묻지 않습니다. 답이 하나뿐이기 때문입니다.

커널과 컴파일 대상 계층은 거의 손대지 않았습니다. Omarchy의 자체 매뉴얼은 이를 Hyprland와 Quickshell을 중심으로 구축된 Arch 기반 배포판으로 설명하며, 설치 프로그램, 업데이트, dotfiles, CLI 페이지 어디에서도 커스텀 커널, 컴파일 대상, 스케줄러 선택을 문서화하지 않습니다. 일반 하드웨어에서 Omarchy는 순정 Arch 커널 패키지를 실행하며, 이 패키지는 시스템의 나머지 부분과 마찬가지로 Arch 미러에서 옵니다. 매뉴얼이 문서화한 유일한 커널 교체는 하드웨어 지원을 위한 것입니다. T2 칩이 탑재된 Intel Mac에서는 설치 프로그램이 패치된 linux-t2 커널을 설정합니다.

저장소 계층은 실제로 바꾸지만, CachyOS와는 다른 축에서 바꿉니다. Omarchy는 자체 Package Repository에서 일반 pacman 패키지로 설치되며, 기본 stable 채널은 최신보다 한 달 뒤처진 Arch 미러를 따라가므로 비호환 문제가 먼저 상류에서 드러납니다. 나머지 세 채널(RC, edge, dev)은 그 완충 장치를 최신성과 맞바꿉니다.

Hyprland와 Quickshell은 함께 오며, 빠질 수 없습니다. Hyprland는 타일링 Wayland 컴포지터이고, Quickshell은 바, 런처, 메뉴, 알림, 잠금 화면을 만드는 구성 키트입니다. 그래서 Omarchy는 테마를 배포하는 대신 한 릴리스에서 셸 전체를 교체할 수 있습니다. 이 분리 덕분에 Omarchy는 프로젝트가 정의한 재현 가능한 기준선을 갖추면서도 사용자의 재정의는 따로 유지합니다. 설정은 둘로 나뉩니다. 사용자의 dotfiles는 ~/.config에, 프로젝트 기본값은 /usr/share/omarchy에 있으며, 후자는 패키지 소유이고 업데이트 시 덮어써집니다. 업데이트를 견디게 하고 싶은 것은 모두 이 분리의 사용자 쪽에 두어야 합니다.

업데이트 정책은 Omarchy의 입장이 가장 뚜렷한 곳입니다. omarchy update 명령은 대기 중인 마이그레이션과 패키지 업데이트를 한 번의 작업으로 실행하며, 먼저 스냅샷을 찍습니다. 롤백은 부트로더에서 그 스냅샷을 고르는 것을 뜻합니다. 대신 pacman -Syu에 손을 뻗으면 가드에 부딪힙니다. Omarchy는 직접적인 시스템 업그레이드를 멈추고 자체 명령으로 안내하지만, 매뉴얼에 따르면 가드는 단일 트랜잭션에 한해 우회하는 방법을 알려 줍니다. 핵심은 결합입니다. 마이그레이션은 패키지 업데이트와 함께 움직입니다.

읽기

Omarchy가 같은 이유로 찬사와 미움을 동시에 받는 이유

비교 스레드가 결코 수렴하지 않는 이유

CachyOS와 Omarchy는 같은 계층 여럿에 손을 대지만, 가장 강한 변화를 서로 다른 곳에 둡니다. CachyOS는 커널, 컴파일 대상, 패키지 빌드에 집중하고, Omarchy는 데스크톱 셸과 업데이트 워크플로에 집중합니다. "어느 쪽이 더 나은가"는 이 별개의 질문들을 하나로 뭉개 버립니다.

둘은 설치 프로그램, 저장소, 복구 계층에서 겹치지만, 같은 방식은 아닙니다. CachyOS의 저장소는 Arch 패키지가 어떻게 빌드되는지를 바꾸고, Omarchy의 저장소는 언제 도착하는지를 바꿉니다. CachyOS는 직접 pacman 업데이트를 열어 두고 그 주위에 스냅샷을 더하며, Omarchy는 패키지 업데이트, 마이그레이션, 스냅샷을 자체 업데이트 명령 뒤에 결합합니다.

그 CachyOS 스레드 맨 위의 두 답글은 정확히 이것을 압축한 것이었습니다. 올바른 진단을, 그 뒤에 있는 다섯 계층 없이 전달한 것입니다.

계층은 섞을 수 있다

다섯 계층은 서로 배타적이지 않고 따로 채택할 수 있습니다. CachyOS는 자체 저장소를 Arch 설치에 추가하고 다시 제거하는 문서화된 경로를 공개하고 있습니다. Omarchy는 Arch 설치이므로, 같은 경로로 CachyOS의 최적화 저장소를 그 위에 옮길 수 있습니다.

실제로 그렇게 하는 사람들이 있습니다. r/linux_gaming의 한 스레드에서 어떤 댓글 작성자는 이렇게 단언했습니다. "There's nothing stopping you from installing the cachyos kernel and repositories on omarchy." 누군가는 이 조합을 위한 설치 스크립트를 만들어 Hacker News에 올렸습니다.

원칙적인 독립성이 실제의 안정성은 아닙니다. 둘 사이의 이전을 다룬 r/omarchy 스레드에서 한 댓글 작성자는 "All of the install scripts and such to do this are currently not working for many people"라고 보고했고, 수동으로 개입해도 작동시키지 못했다고 했습니다. 이는 한 스레드의 한 사람 이야기이지만, 대비할 가치가 있는 종류의 문제입니다.

두 번째 한계는 이 조합이 얼마나 가치 있느냐입니다. 공개된 성능 비교에서는 게임의 평균 FPS 차이가 거의 없으며, CachyOS의 커널, 스케줄러, 컴파일 대상에서 오는 더 넓은 이득은 자동적이라기보다 워크로드에 따라 다릅니다.

CachyOS의 커널 작업과 컴파일 대상이 더 넓은 범위에서, 그리고 어떤 종류의 워크로드에서 의미 있는 이득을 내는지는 이 글이 결론 내리는 근거가 아니라 다른 근거 자료에 달려 있습니다.

EndeavourOS와 Manjaro는 같은 계층의 어디에 있는가

EndeavourOS와 Manjaro도 같은 다섯 계층에 각자의 조합으로 자리 잡으며, 바로 그 점이 이 모델을 두 프로젝트 비교 이상으로 가치 있게 만듭니다. EndeavourOS는 설치 프로그램 계층을 가장 많이 바꾸지만, initramfs 생성에 Dracut도 사용하고 EndeavourOS 전용 도구와 패키지를 위한 작은 저장소도 유지합니다. Manjaro는 저장소 계층을 가장 많이 바꾸고, 설치 프로그램은 어느 정도, 컴파일 대상 계층은 전혀 바꾸지 않습니다.

EndeavourOS는 스스로를 가볍고 터미널 중심인 Arch 시스템이라고 설명하며, 더하는 것은 안내형 설치 프로그램, 짧게 엄선한 패키지 세트(Firefox, Yay, FirewallD, Pipewire), 그리고 GPU와 VM 드라이버용 자체 도구입니다. 커스텀 커널 없음, Arch 일반 저장소의 CPU 맞춤 재빌드 없음, 강제되는 데스크톱 없음. 여기서 언급한 파생판 중에서 여전히 순정 Arch에 가장 가깝습니다.

Manjaro의 프레임은 단계적 안정성이라는 접근법입니다. 패키지는 Arch 저장소를 직접 따라가는 대신 Manjaro 자체 저장소 안에서 unstable, testing, stable 브랜치를 거쳐 이동합니다. 그래서 Manjaro 패키지가 같은 이름의 Arch 패키지보다 오래된 경우가 있습니다. 설치 프로그램은 공식 Plasma, GNOME, Xfce 에디션과 커뮤니티 Cinnamon, i3, Sway 빌드 중에서 데스크톱을 고르게 해 줍니다.

커널 도구도 갖추고 있는데, 이 구분이 중요합니다. Manjaro Settings Manager는 커널을 추가하고 제거하여 다른 미리 빌드된 커널 버전을 실행할 수 있게 해 줍니다. 패키지화된 커널 버전 중에서 고르는 것은 더 새로운 CPU 명령어 집합에 맞춰 패키지를 다시 빌드하는 것과 같은 작업이 아닙니다. 둘 다 커널과 컴파일 대상 계층에 속하긴 하지만요.

이 브랜치 모델은 Manjaro를 고정 릴리스 세계와 구분 짓는 요소이기도 합니다. Ubuntu와 대비되는 Manjaro의 롤링 모델은 Arch 계열 바깥에서 던져진 같은 저장소와 업데이트 정책 질문입니다. 같은 셈법은 그 계열 너머에서도 통합니다. Ubuntu는 Debian에서 파생되었으며, 릴리스 주기, 패키징 정책, 기본 데스크톱에서 Debian과 다릅니다.

새 파생판의 첫 페이지를 보면 대개 이 계층들 중 어디에 손을 대는지, 그리고 이 다섯 계층 모델 바깥의 무언가를 바꾸는지 알 수 있습니다.

자주 묻는 질문

Omarchy는 진짜 배포판인가, 아니면 그저 dotfiles인가?

다섯 계층 테스트로 보면 Omarchy는 dotfiles 모음 이상입니다. 자체 ISO 설치 프로그램, 네 개의 릴리스 채널을 가진 자체 패키지 저장소, pacman -Syu를 대신하는 자체 업데이트 도구를 제공합니다. 성능을 이유로 커널이나 컴파일 대상을 바꾸지는 않습니다. 매뉴얼이 문서화한 유일한 커널 교체는 T2 칩 Intel Mac을 위한 하드웨어 지원 패치입니다. 그 아래 시스템은 그 외에는 순정 Arch입니다. 이것이 "배포판"에 해당하는지는 이름표를 둘러싼 논쟁입니다.

CachyOS의 커널과 저장소를 Omarchy에서 쓸 수 있는가?

기술적으로는 가능합니다. CachyOS는 기존 Arch 설치에 자체 저장소를 추가하는 방법을 문서화했고, Omarchy는 내부적으로 Arch 패키지를 사용합니다. 하지만 호환성이 보장되지는 않습니다. Omarchy의 지연된 패키지 채널과 업데이트 워크플로는 움직이는 부품을 하나 더 추가하며, r/omarchy의 한 댓글 작성자는 편의 스크립트가 많은 사람에게 실패했다고 보고했습니다. 수동 개입에 대비하세요.

CachyOS는 데스크톱 환경을 강제하는가?

아니요. CachyOS는 데스크톱 선택을 사용자에게 맡깁니다. 온라인 설치 프로그램은 KDE Plasma 같은 완전한 환경부터 Hyprland와 Niri 같은 타일링 Wayland 컴포지터까지 열일곱 개 이상의 선택지를 나열하며, 선택은 설치 중에 이루어집니다. Kernel Manager처럼 CachyOS가 관리하는 도구는 어떤 데스크톱을 골랐든 그 위에서 동작합니다.

x86-64-v3는 무슨 뜻인가?

x86-64-v3는 기준선 x86-64보다 높은 CPU 마이크로아키텍처 기능 수준입니다. AVX, AVX2, BMI1, BMI2, FMA 등의 요구 사항을 추가하므로, v3 전용으로 빌드된 소프트웨어는 그 기능 집합을 지원하는 CPU가 필요합니다. v3용으로 컴파일된 패키지는 그 기능들을 사용할 수 있고, 그 기능이 없는 프로세서에서는 실행되지 않습니다. CachyOS는 Arch의 패키지를 x86-64-v3와 x86-64-v4용으로 다시 빌드하며 v3에서 5%에서 20%의 향상을 주장하는데, 이는 프로젝트 자체의 수치입니다.