리눅스 커널 빌드가 빨라질까, 병목을 쪼갠 패치 시리즈

Linux 커널을 한 번이라도 직접 빌드해 본 사람이라면 소스 코드를 조금 고친 뒤에도 컴파일이 한참 이어지는 상황을 잘 아실 겁니다.

CPU 코어가 여러 개여도 모든 작업이 동시에 진행되는 것은 아니기 때문입니다. 이번에는 커널 빌드 과정에 남아 있던 단일 스레드 병목을 줄이는 패치 시리즈가 제안됐습니다.

변경을 주도한 사람은 ARM 엔지니어이자 리눅스 개발자인 Lorenzo Stoakes입니다. 첫 번째 버전에 이어 두 번째 버전의 패치가 제출됐고 현재 목표는 Linux 7.4 주기에 반영되는 것입니다.

아직 메인라인에 들어간 최종 기능은 아니므로 수치만 보고 당장 모든 배포판의 빌드가 빨라진다고 받아들이면 안되겠죠.

여러 코어를 두고도 기다리던 시간

커널 빌드는 소스 파일을 컴파일하는 일만으로 끝나지 않습니다. 빌드 설정에 따라 생성된 정보를 정리하고 심볼을 모으고 모듈을 점검하는 여러 단계가 차례로 이어집니다.

이 중 일부가 한 번에 한 작업만 처리하면 다른 코어가 놀면서 전체 시간이 그 단계에 서 병목이 생기죠.

쉽게 말해서 식당에 일손이 충분한데도 주문을 받는 창구 하나만 열어 둔 상황과 비슷합니다. 요리하는 사람을 더 늘려도 주문이 한 줄로만 들어가면 손님이 기다리는 시간은 크게 줄지 않습니다.

이번 작업은 커널 빌드의 이런 창구를 찾아 여러 작업이 겹쳐 진행될 수 있도록 구조를 손보는 데 초점을 맞췄습니다.

보고된 벤치마크에서는 모든 모듈을 포함하는 allmodconfig 빌드가 약 36% 빨라졌습니다. 이미 빌드한 뒤 일부만 다시 만드는 증분 빌드는 최대 약 70% 단축됐고 실제로 바뀐 내용이 없어 확인만 하는 noop 빌드는 약 90%까지 줄어든 결과가 제시됐습니다.

다만 이 수치는 특정 패치와 하드웨어, 커널 설정을 조합해 측정한 결과입니다.

Kbuild부터 Rust 빌드까지 손질

패치는 커널 빌드 시스템인 Kbuild와 커널 심볼을 처리하는 kallsyms, 모듈 정보를 점검하는 modpost, objtool과 mksysmap 등에 걸쳐 있습니다.

Rust 코드를 커널에 포함해 빌드하는 경로도 영향을 받습니다. 한 부분만 빠르게 만드는 것이 아니라 서로 이어진 단계에서 불필요한 직렬 처리를 줄이려는 접근입니다.

이 과정에는 대규모 언어 모델도 활용됐습니다. Lorenzo Stoakes는 모델이 병목을 찾고 개선 방향을 제시하는 데 도움을 줬지만 생성된 코드 가운데 상당수는 그대로 쓸 수 없었다고 설명했습니다.

개발자가 코드를 직접 감사하고 다시 고쳤으며 빌드·테스트·디버깅과 실행 중인 커널의 정확성 확인도 수작업으로 진행했습니다.

각 커밋에는 Assisted-by 표시도 붙었습니다. 개발 과정에서 대규모 언어 모델의 도움을 받았다는 사실을 기록하는 방식입니다.

자동 생성 코드를 검토 없이 넣었다는 뜻은 아닙니다. 커널처럼 시스템 전체에 영향을 주는 프로젝트에서는 속도 향상만큼 변경 이유와 검증 과정을 남기는 일이 중요합니다.

두 번째 버전에서는 기존 패치의 수정과 최신 커널 소스에 맞춘 재정렬이 이뤄졌습니다. 제안된 모든 코드가 Linux 커널 7.4 버전에 들어가려면 각 담당자의 검토와 테스트를 더 거쳐야 합니다.

Rust 컴파일러의 병렬 프런트엔드는 선택적으로 사용할 수 있도록 바뀌었고 나머지 변경도 리뷰를 받을 수 있도록 다듬어졌습니다.

커널을 직접 빌드하는 사용자에게 어떤 의미일까

일반적인 데스크톱 사용자는 배포판이 제공하는 커널 패키지를 설치하므로 이 패치의 효과를 바로 체감하지 못할 수 있습니다.

반면 새 하드웨어를 시험하거나 드라이버를 개발하는 사람, 커널 설정을 자주 바꾸는 배포판 패키지 관리자는 빌드 대기 시간이 줄어드는 만큼 작업을 더 빠르게 반복할 수 있습니다.

증분 빌드가 빨라지는 점은 특히 실용적입니다. 작은 코드 한 줄을 바꿀 때마다 전체 커널을 처음부터 다시 만드는 대신 관련 부분만 재생성하는데 이 과정에서 불필요한 직렬 단계가 줄면 수정과 확인 사이의 간격이 짧아집니다.

다만 모든 빌드가 70% 빨라진다는 의미는 아니며 변경한 파일과 설정에 따라 결과는 달라집니다.

패치가 병합되더라도 커널 빌드 시간은 CPU와 저장장치, 메모리, 병렬 작업 수, 배포판의 빌드 설정에 영향을 받습니다.

그래서 자신의 환경에서는 같은 비율이 나오지 않을 수 있습니다. 그래도 여러 코어를 갖춘 현대적인 컴퓨터에서 오래된 순차 처리 때문에 시간을 낭비하던 부분을 줄인다는 방향 자체는 분명한 이점입니다.

Linux 7.4 반영 여부와 최종 성능은 리뷰가 끝난 뒤 다시 확인해야 합니다. 이번 사례는 대규모 언어 모델을 커널 개발에 활용하는 방식에 대해서도 현실적인 선을 보여줍니다.

모델이 코드를 만들어 주는 것만으로는 충분하지 않고 병목을 측정하고 변경을 검토한 뒤 실제 커널과 빌드 결과를 확인하는 개발자의 책임이 남습니다.

원문 뉴스: Phoronix

🐧 Linuxroom의 생각 :

Linux 커널 빌드가 빨라진다는 소식은 일반 사용자에게는 조금 생소하게 들릴 수 있습니다.

하지만 배포판을 만들거나 드라이버를 고치는 개발자에게 커널을 포함한 여러 빌드 시간은 하루에도 수십 번 만나는 지루한 대기 시간이죠..

이번 패치에서는 AI를 앞세우기보다 병목을 찾는 도구로 제한한 점이 인상적이라고 생각합니다. 생성된 코드가 많았지만 그대로 받아들이지 않았고 사람이 다시 읽고 테스트했다는 과정이 함께 제시됐습니다. 제가 생각하기에도 반드시 그래야한다고 생각이 들구요.

커널처럼 작은 실수도 시스템 불안정으로 이어질 수 있는 프로젝트에서는 이 순서가 바뀌면 안 된다고 생각합니다.

아직 Linux 커널 7.4 버전에 최종 반영된 것은 아니므로 지금 당장 빌드 시간을 계산해 기대치를 정할 단계는 아니라고 생각합니다.

패치가 실제 환경의 다양한 설정에서도 같은 안전성을 보일지, 성능 향상이 유지보수 부담을 늘리지는 않을지 리뷰 결과를 지켜볼 필요가 있습니다.