Linux 7.2의 핵심 변화: 더 영리해진 캐시 활용과 빨라진 저장장치 경로

8월 16일 공개된 Linux 7.2는 단일 기능에 초점을 맞춘 업데이트라기보다 CPU 스케줄러, 저장장치 경로, 파일시스템, 하드웨어 드라이버를 동시에 다듬은 대형 커널 릴리스입니다. 가장 눈에 띄는 변화는 CPU 캐시 구조를 고려해 작업을 배치하는 Cache Aware Scheduling입니다. 동시에 9주간의 개발 과정에서 2,100명이 넘는 기여자가 참여하고 AI 보조 도구가 만들어낸 보고서와 패치가 늘어나면서, 커널 유지보수의 부담도 수면 위로 올라왔습니다.

핵심은 CPU 캐시를 고려한 스케줄링

Linux 7.2는 CONFIG_SCHED_CACHE 옵션 뒤에 Cache Aware Scheduling을 추가했습니다. 기존처럼 모든 코어와 캐시 영역을 동일하게 취급하는 대신, 서로 데이터를 공유하는 작업을 같은 최종 레벨 캐시(LLC) 영역을 공유하는 코어에 배치하려는 방식입니다.

작업이 여러 캐시 영역 사이를 오가면 캐시 데이터가 반복적으로 이동하고 캐시 미스가 늘어날 수 있습니다. 새 스케줄링 방식은 이를 줄여 데이터 접근 효율을 높이는 것이 목표입니다. 특히 여러 칩렛이나 소켓으로 구성된 AMD EPYC, Intel Xeon 같은 복잡한 CPU 토폴로지에서 의미가 있을 수 있습니다.

다만 모든 시스템에서 곧바로 성능이 향상되는 만능 스위치는 아닙니다. 실제 효과는 프로세서의 캐시 구조와 실행하는 작업의 특성에 따라 달라집니다. 관련 작업을 서로 다른 캐시 영역으로 이동시키는 비용이 큰 서버와 워크로드를 겨냥한 스케줄러 개선으로 보는 편이 정확합니다.

저장장치와 파일시스템의 병목을 겨냥하다

Linux 7.2의 성능 개선은 사용자 인터페이스보다 I/O 경로와 메타데이터 처리처럼 시스템 내부의 병목을 다루는 데 집중돼 있습니다.

• 파이프 쓰기 관련 변경은 테스트 구성과 워크로드에 따라 처리량이 약 6~28% 향상된 것으로 보고됐습니다.
• ext4는 fast commit 경로를 다시 구성해 잠금 경합과 데드락 위험을 줄이는 한편, 디렉터리 해시 계산도 개선했습니다.
• iomap 관련 작업은 ext4와 XFS의 일부 경로를 최적화했습니다. NVMe SSD와 io_uring을 사용하는 고 IOPS 환경에서 성능 향상이 확인됐지만, 모든 디스크와 애플리케이션에 동일하게 적용되는 수치는 아닙니다.
• Btrfs의 대형 폴리오(large folio) 지원은 실험 단계를 벗어나 기본 활성화됐습니다. 최대 2MB 크기의 초대형 폴리오(huge folio) 지원도 실험 기능으로 추가됐습니다.
• exFAT는 iomap 인프라로의 전환을 더 진행해 버퍼드 I/O, 직접 I/O, 관련 탐색 작업을 개선했습니다. 부하가 큰 테스트에서 상당한 향상이 보고됐지만, 결과는 사용 환경에 따라 달라집니다.

따라서 Linux 7.2의 성능 이야기는 여러 하위 시스템에 분산돼 있습니다. CPU 캐시 지역성, 파일시스템 메타데이터, 고속 스토리지, 파이프 기반 프로세스 간 통신, Btrfs 메모리 관리에 부하가 걸리는 시스템에서 개선 폭을 체감할 가능성이 더 큽니다.

Apple·AMD·Intel·NVIDIA 하드웨어 지원 확대

이번 릴리스에는 새로운 플랫폼을 위한 기반 작업도 여럿 포함됐습니다.

• Apple M3 MacBook은 업스트림 Asahi Linux 작업을 통해 메인라인 커널로 시리얼 콘솔까지 부팅할 수 있게 됐습니다. 중요한 초기 구동 단계지만, 모든 MacBook 부품을 지원하는 완성도 높은 데스크톱 환경이 마련됐다는 뜻은 아닙니다.
• Intel은 USB4 케이블을 통해 데이터 스트림을 전송하는 USB4STREAM을 지원합니다.
• AMDGPU에는 HDMI 2.1 Fixed Rate Link(FRL) 지원이 초기 형태로 들어갔고, AMD 플랫폼 코드에는 차세대 Zen 6 시스템을 위한 초기 준비 작업이 포함됐습니다.
• Intel Xe 드라이버에는 초기 CRI 플랫폼 지원이 추가됐고, Nouveau는 GSP를 통해 NVIDIA GA100 컴퓨팅 가속기를 지원합니다. Apple Silicon의 배터리 보고 기능도 개선됐습니다.
• Rust 지원 범위는 IBM의 s390 아키텍처까지 확장됐습니다. 이에 따라 Rust로 작성하는 커널 구성 요소를 개발할 수 있는 플랫폼이 넓어졌습니다.

이 밖에도 네트워크, 가상화, 보안, 임베디드 시스템, 전력 모니터링 관련 변경이 이어졌습니다. Linux 7.2는 성능 개선판인 동시에 다양한 플랫폼을 준비하는 하드웨어 지원 릴리스이기도 합니다.

1세대 x86 코드와 오래된 장치 지원 정리

Linux 7.2는 1세대 x86 계열인 i486의 x87 부동소수점 에뮬레이션 코드 1만 3,000줄 이상을 제거했습니다. AppleTalk와 레거시 ISA·PCMCIA ARCnet 어댑터 지원도 빠졌습니다.

x86에서는 이제 사용 가능한 타임스탬프 카운터(TSC)를 항상 요구합니다. 현대적인 x86 데스크톱과 서버는 대체로 이미 TSC에 의존하므로, 실제 영향은 지원 대상에서 사실상 벗어난 매우 오래된 장치나 특수한 하드웨어에 집중될 전망입니다.

또한 커널 트리에서 더 이상 권장되지 않는 strncpy() API 사용을 제거하는 장기 정리 작업도 이번 주기에 마무리됐습니다. 해당 코드는 strscpy()와 같은 더 명시적인 문자열 처리 함수로 대체됐습니다.

AMD 그래픽 회귀 문제로 GPU 스케줄러는 FIFO로 되돌려

개발 과정에서 Linux 7.2에는 GPU 작업 순서를 더 공정하게 조정하려는 새로운 ‘fair’ GPU 스케줄러가 잠시 포함됐습니다. 그러나 AMD 그래픽 회귀 문제가 발생하면서, 최종 릴리스에서는 해당 스케줄러가 FIFO 방식으로 되돌아갔습니다.

새 기능이 개발 트리에 들어갔다고 해서 안정 버전 사용자에게 그대로 제공되는 것은 아닙니다. 이번 결정은 더 야심 찬 스케줄링 모델을 출시하는 것보다 예측 가능한 그래픽 동작과 안정성을 우선한 사례입니다.

9주 개발 주기와 AI가 키운 검토 부담

Linux 7.2 개발 주기는 약 9주였으며, 2,100명이 넘는 기여자가 참여해 병합 창 참여 규모와 관련한 기록을 세운 것으로 보고됐습니다. 분석 자료에 따르면 커밋의 약 **5%**에는 AI 지원을 나타내는 표기가 붙었습니다.

핵심 쟁점은 AI가 Linux 7.2의 주요 기능을 독자적으로 작성했다는 데 있지 않습니다. AI 도구가 취약점 보고, 패치 제안, 코드 검토 결과, 후속 수정의 흐름을 크게 늘리고 있다는 점이 더 중요합니다. AI 보조 분석으로 발견된 문제를 해결하는 패치가 실제로 반영되더라도, 제안된 변경 하나하나는 결국 사람이 검토하고 테스트하고 통합해야 할 작업으로 남습니다.

Linus Torvalds가 늦은 시점에 대규모 수정이 몰리는 현상을 ‘새로운 일상(new normal)’이라고 표현한 것은 낮아진 검토 기준을 지지한다기보다, 커널 개발 운영이 맞닥뜨린 현실을 받아들이는 말에 가깝습니다. Linux 7.2는 예정대로 출시됐지만, 막판 변경과 후속 수정이 늘어날수록 유지보수자는 패치 품질과 회귀 버그, 검토 가능성을 더 엄격하게 관리해야 합니다.

다음은 Linux 7.3, Ubuntu 26.10

Linux 7.3의 병합 창은 Linux 7.2 출시 직후 열렸고, 약 40개의 풀 리퀘스트가 이미 대기 중인 것으로 전해졌습니다. 앞으로 2주 안팎의 병합 과정에서 7.3에 들어갈 주요 기능이 가려질 전망입니다.

Canonical의 커널 팀은 Ubuntu 26.10 ‘Stonking Stingray’의 현재 목표 커널로 Linux 7.2를 지정했습니다. Ubuntu 26.10은 2026년 10월 15일 출시 예정이며, 커널 동결은 10월 1일로 계획돼 있습니다. 이 일정상 Linux 7.2가 더 안정적인 선택지이지만, 테스트 과정에서 심각한 회귀나 통합 문제가 발견되면 배포판의 최종 계획은 달라질 수 있습니다.

일반 사용자가 주목할 지점은 버전 번호 자체가 아닙니다. 사용하는 하드웨어와 작업 환경이 Linux 7.2의 강점인 캐시 지역성, 파일시스템 처리량, 최신 플랫폼 지원, 장치 드라이버 개선 중 어디와 맞물리는지가 실제 체감 성능을 결정합니다.