Apple Silicon의 비밀 무기: XNU Clutch Scheduler 분석과 엔지니어의 시선

최근 Apple이 조용히 GitHub에 공개한 문서 하나가 로우 레벨 엔지니어들 사이에서 꽤 흥미로운 떡밥이 되고 있습니다. 바로 XNU 커널의 스케줄러, 그중에서도 ‘Clutch Scheduler’에 대한 문서입니다.

우리가 흔히 M1, M2 맥북을 쓰면서 “와, 배터리가 안 닳네?” 혹은 “컴파일 돌리면서 유튜브 봐도 안 끊기네?”라고 감탄하곤 합니다. 보통은 Apple Silicon이라는 하드웨어의 공으로 돌리지만, 사실 그 하드웨어를 지휘하는 OS 스케줄러 의 역할이 8할입니다. 오늘은 이 문서와 Hacker News의 반응을 토대로, Apple이 멀티코어 환경을 어떻게 제어하고 있는지, 그리고 Principal Engineer 입장에서 이게 왜 대단하면서도 동시에 골치 아픈지 뜯어보겠습니다.

Clutch? 자동차 부품 아닙니다

문서의 핵심은 Clutch라는 개념입니다. 리눅스 커널의 CFS(Completely Fair Scheduler)나 최근의 EEVDF에 익숙한 분들이라면 “Task Group”이나 “cgroup”을 떠올리실 텐데, Apple의 접근은 조금 더 계층적이고 복잡합니다.

XNU 스케줄러는 단순히 스레드를 코어에 던지는 게 아니라, 다음과 같은 계층 구조를 가집니다:

  • Root: 최상위 레벨
  • Thread Group: 관련된 스레드들의 묶음
  • Clutch: 스케줄링 속성(QoS 등)을 공유하는 스레드들의 집합
  • Bucket: 실제 스케줄링 우선순위 큐

여기서 ‘Clutch’는 스레드 그룹과 실제 실행 큐(Bucket) 사이를 연결하는 중간 관리자 역할을 합니다. 흥미로운 점은 이 구조가 AMP(Asymmetric Multiprocessing), 즉 P-core(성능 코어)와 E-core(효율 코어)가 섞인 환경을 극도로 효율적으로 제어하기 위해 설계되었다는 점입니다.

Edge Scheduler와 Latency의 싸움

문서 제목에 포함된 ‘Edge’라는 단어는 스케줄링 결정이 일어나는 경계(boundary)를 의미하는 것으로 보입니다. Apple은 모바일(iOS)에서 시작해 데스크톱(macOS)으로 역진입한 케이스라, 서버 사이드 리눅스와는 철학이 완전히 다릅니다. 리눅스가 Throughput (처리량)에 목숨을 건다면, XNU는 Latency (반응성)와 Energy Efficiency (전력 효율)에 목숨을 겁니다.

솔직히 문서를 읽으면서 감탄한 부분은 스레드의 ‘인터랙티브’ 여부를 판단하고, 이를 적절한 ‘Clutch’에 할당해 P-core로 즉시 승격시키거나 E-core로 유배 보내는 로직의 정교함입니다. 이는 하드웨어와 소프트웨어를 한 회사가 만들 때만 가능한 ‘수직 통합’의 끝판왕을 보여줍니다.

Hacker News의 반응: “그래서 내 오디오가 안 끊기는구나”

이 주제에 대해 Hacker News에서도 꽤 깊이 있는 토론이 오갔습니다. 특히 오디오 엔지니어링이나 고성능 컴퓨팅(HPC)을 다루는 유저들의 반응이 인상적입니다.

한 유저는 “M-series 칩에서 특정 코어에 C/C++ 프로젝트를 고정(pinning)하려고 삽질했을 때 eclecticlight.co의 분석이 큰 도움이 되었다”고 언급했습니다. 실제로 Apple Silicon에서 task_policy_set 같은 API 없이 맘대로 코어 어피니티(Affinity)를 조절하려다 보면, 스케줄러가 강제로 개입해서 성능이 오히려 떨어지는 경험을 하게 됩니다. 스케줄러가 “내가 너보다 더 잘 알아”라고 말하는 격이죠.

또 다른 흥미로운 포인트는 DAW(Digital Audio Workstation) 성능입니다. 한 유저는 “이게 macOS가 오디오 작업에 유리한 이유인가?”라고 물었고, 이에 대해 다른 유저들이 “CoreAudio는 전용 Realtime 스레드를 사용하며, 이는 문서에 나오는 FIXPRI(Fixed Priority) 버킷에 해당할 것”이라고 분석했습니다. 리눅스의 Pipewire나 JACK도 훌륭하지만, OS 레벨에서 QoS를 강제하는 Apple의 방식이 ‘그냥 꽂으면 작동하는(Just Works)’ 경험을 만드는 핵심이라는 것이죠.

엔지니어로서의 Verdict: 블랙박스의 양면성

개인적으로 이 문서를 보면서 든 생각은 두 가지입니다.

첫째, “부럽다.” 리눅스 진영에서도 sched_ext 등을 통해 BPF로 스케줄러를 커스터마이징 하려는 시도가 있지만, Apple처럼 하드웨어 아키텍처(SoC)에 맞춰 커널 스케줄러를 나노 단위로 깎는 것은 불가능에 가깝습니다. 아이폰 배터리가 오래 가고, 맥북이 절전 모드에서 순식간에 깨어나는 건 마법이 아니라 이런 집요한 엔지니어링 덕분입니다.

둘째, “무섭다.” 개발자 입장에서 OS가 너무 똑똑해지면 디버깅이 지옥이 됩니다. 내 코드가 느린 이유가 알고리즘 문제인지, 아니면 내가 실수로 Background QoS 태그를 달아서 스케줄러가 나를 E-core 구석에 박아뒀기 때문인지 파악하기 어렵습니다. 시스템이 블랙박스화 될수록 우리는 Apple이 정해준 ‘길’로만 다녀야 합니다.

결론적으로, 이 문서는 단순한 커널 문서가 아닙니다. Apple이 미래의 컴퓨팅을 어떻게 정의하고 있는지 보여주는 청사진입니다. 시스템 프로그래밍에 관심 있는 분들이라면 원문을 꼭 한 번 정독해 보시길 권합니다.

References: