토르발스가 Claude Code로 만든 Linux 고속화 패치 | 읽기 속도 약 3배
機械翻訳 / Machine-translated
A
AI Friends
5時間前・9分で読める
機械翻訳 / Machine-translated
@aifriends
AI Friends（https://aifriends.jp）のクロスポスト公式アカウント。AIツールの紹介・使い方・できることを、中学生でもわかるやさしい日本語で届けます。
AI는 세계에서 가장 엄격하다고 불리는 오픈소스 개발 현장에까지 들어온 걸까요. Linux의 창시자가 자신의 브랜치에서 Claude Code를 사용했다고 밝히며, 속도가 약 3배 향상되었다고 보고했습니다. 무슨 일이 벌어진 것인지, 어디까지 신뢰할 수 있는지 살펴보겠습니다.
2026년 10월 12일 무렵, 리누스 토르발스가 자신의 Linux 트리에 noref-filemap-read-with-llm이라는 브랜치를 공개했습니다.
Hardware Busters에 따르면, 내용은 8개의 패치로 구성된 시리즈입니다. Claude Code가 코드와 테스트를 작성하고, 설명문 초안도 작성했다고 본인이 커버 레터에 직접 밝혔습니다.
커버 레터에는 작업이 "내 지시 아래" 진행되었으며, 측정은 "내 머신"에서 실행했다고 적혀 있습니다. 처음 발견한 것은 Phoronix 기자였으며, 이후 여러 미디어로 확산되었습니다.
대상은 Linux 7.3-rc6 위에 올라가는 코드로, 아직 정식으로 병합되지 않았습니다.
컴퓨터는 한 번 읽은 파일의 내용을 메모리에 남겨둡니다. 다음에 같은 파일을 읽을 때 스토리지까지 가져오지 않아도 되기 때문입니다. 이 구조가 바로 페이지 캐시입니다.
Linux의 파일 읽기 대부분은 이 구조를 통합니다. 그래서 여기가 조금만 빨라져도 서버 동작에 영향을 미칩니다.
문제가 된 것은 여러 스레드(동시에 실행되는 작업 단위)가 같은 파일을 조금씩 읽는 상황입니다.
읽을 때마다 각 스레드는 "지금 몇 명이 이 데이터를 사용 중인가"를 세는 카운터(참조 카운터)를 늘리거나 줄입니다. 모두가 같은 카운터를 수정하기 때문에, CPU 코어끼리 같은 메모리 영역을 두고 경쟁하게 됩니다.
Hardware Busters에 따르면, 8스레드로 16바이트씩 읽는 테스트에서 코어 간 충돌의 99.92%가 이 경쟁에서 비롯되었습니다.
새로운 방식에서는 읽기 중에 카운터를 건드리지 않습니다. 대신 RCU(읽는 쪽을 멈추지 않고, 나중에 일괄적으로 안전하게 정리하는 구조)를 사용합니다.
캐시에서 제거된 데이터는 바로 해제하지 않습니다. 모든 읽는 쪽이 통과한 것을 확인한 뒤 메모리를 반환합니다.
하나의 CPU에 1,024페이지를 초과하는 해제 대기가 쌓이면, 정리를 서두르게 하는 안전 밸브도 내장되어 있습니다.
측정한 것은 토르발스의 Core i7-8565U 노트북(4코어·8스레드)입니다. Hardware Busters의 수치는 다음과 같습니다.
충돌은 약 300분의 1로 감소했습니다. 경쟁이 줄었다는 설명과 수치가 일치합니다.
다만 이것은 16바이트라는 극단적으로 작은 읽기를 8개의 스레드가 같은 파일에 동시에 수행하는 특별한 테스트입니다. 서버 전체가 3배 빨라진다는 의미가 아닙니다.
커버 레터에는 잘 되지 않는 부분도 기술되어 있습니다. DEV Community의 분석 글도 이 점을 다루고 있습니다.
첫 번째는 느려지는 상황이 있다는 것입니다. 아직 할당되지 않은 메모리 영역에 읽기를 수행하면, 한 번 실패한 뒤 기존 경로로 재시도하는 흐름이 됩니다. 1스레드의 16바이트 읽기는 약 4,150사이클에서 약 6,550사이클로 증가했습니다.
두 번째는 메모리 해제가 지연된다는 것입니다. 해제 대기 중인 페이지는 메모리 관리의 여유 용량 수치에 나타나지 않습니다. Hardware Busters에 따르면, 토르발스 본인도 이 부분을 가장 해결하지 못한 점으로 꼽고 있습니다.
실제로 2GiB 가상 머신에서의 부하 테스트에서, 6개 패치 버전은 4CPU와 8CPU에서 OOM 킬러(메모리 부족으로 실행 중인 프로세스를 강제 종료하는 구조)를 유발했습니다. 8개 패치를 모두 적용한 버전에서는 완주했다고 알려져 있습니다.
세 번째는 테스트가 부족하다는 것입니다. 측정한 것은 노트북 1대뿐이며, 다른 기종이나 메모리가 부족한 상황에서의 확인은 아직 남아 있습니다. 제3자에 의한 재현도 아직 이루어지지 않았습니다.
다음으로 AI 활용 규칙을 살펴보겠습니다. Linux 커널에는 AI가 관여한 패치의 처리 방식을 정한 공식 문서가 있습니다. ITsFoss에 따르면, Linux 7.0에서 도입되었습니다.
내용은 다음 세 가지입니다.
즉, AI 활용을 금지하지는 않습니다. 다만 결과에 책임을 지는 것은 반드시 인간인 제출자입니다.
기존 방식과 비교하면 차이가 보입니다.
한편, Startup Fortune에 따르면, 토르발스는 2024년 10월에 AI 관련 이야기의 90%는 과장이라고 말했습니다. 2026년 7월에는 "Linux는 반AI 프로젝트가 아니다"라고 썼습니다. 입장이 상당히 바뀐 셈입니다.
Linux는 한국에서도 웹 서비스, 클라우드, 공장 설비, 스마트폰 등 다양한 곳에서 동작하고 있습니다. 커널의 읽기 처리가 빨라지면, 한국 사용자에게도 혜택이 돌아올지 모릅니다.
어느 중소기업의 인프라 담당자를 생각해 보겠습니다. 자사 서버에서 같은 설정 파일을 대량의 프로세스가 읽고 있다고 합시다. 이번과 같은 개선이 정식으로 병합되면, 설정을 바꾸지 않아도 부하가 줄어들지도 모릅니다.
개발팀에게는 진행 방식 자체가 더 참고가 될 수 있습니다. AI에게 작성하게 하고, 사람이 측정하고, 약점까지 공개하는 절차는 사내 개발 규칙을 만들 때 힌트가 됩니다.
예를 들어 "AI를 사용한 부분은 기록으로 남긴다", "책임자는 반드시 사람으로 한다"는 규칙이라면, 바로 따라 할 수 있을 것입니다.
다만 커널 변경은 영향 범위가 넓으며, 아직 병합되지도 않았습니다. 지금 당장 프로덕션 환경에 적용할 것은 아닙니다.
아니요. 아직 병합되지 않았습니다. Linux 7.3-rc6 위에 올라간 실험적인 브랜치입니다. 다음 개발 사이클(7.4)에 포함될지도 아직 확실하지 않습니다.
특정 테스트에서는 초당 읽기 횟수가 약 3배 증가했습니다. 다만 소규모 읽기를 8스레드로 같은 파일에 수행하는 조건에서, 노트북 1대의 결과입니다. 실제 용도에서는 더 작은 개선에 그칠 가능성이 있습니다.
커널에서는 AI가 작성했는지 여부와 관계없이, 인간인 제출자가 모든 책임을 집니다. 이번에는 토르발스 본인이 직접 측정하고 약점도 명시한 뒤 공개했습니다. 리뷰와 추가 테스트를 통과하기 전까지는 안전하다고 단언할 수 없습니다.
AI가 도운 패치에 붙이는 표시입니다. 형식은 Assisted-by: AGENT_NAME:MODEL_VERSION이며, 사용한 도구도 함께 기재할 수 있습니다. AI를 공동 저자가 아닌 도구로 취급한다는 사고방식에 기반합니다.
다음 단계로, 자신의 팀에서도 "AI를 사용한 부분을 기록하고, 책임자를 정한다"는 규칙을 하나 만들어 보세요.
이 글은 AI Friends의 크로스포스트입니다.
