리누스 토르발스, Linux 메모리 개선에 Claude Code 활용했지만 리뷰에서 경쟁 조건 발견

Linux 창시자이자 커널 개발을 총괄하는 리누스 토르발스는 파일 읽기 경로에서 2년 넘게 지속된 병목을 해결하는 데 Anthropic의 Claude Code 도구를 활용했다. 10개 패치로 구성된 시리즈는 64코어 Threadripper 시스템의 합성 테스트에서 읽기 처리량을 23배 향상시켰지만, Linux 커널 리뷰어들은 이후 경쟁 조건을 발견하고 메모리 회수 설계의 안전성에 관한 의문을 제기했다. 이에 따라 패치는 아직 병합되지 않았다.

페이지 메모리 참조 카운터 문제

이 작업은 page cache 내부에서 folio로 알려진 객체의 참조 카운터를 둘러싼 경합과 관련이 있다. page cache는 파일에서 읽은 데이터를 보관해 접근 속도를 높이는 계층이다. 이 병목은 한 고객의 워크로드에서 나타난 뒤 2024년에 보고됐으며, 토르발스의 노트북에서 수행한 테스트에서는 8개 스레드를 사용하는 테스트에서 이 경합이 코어 간 HITM 작업의 99.92%를 차지하는 것으로 나타났다.

토르발스는 이 문제에 대한 자신의 이전 수정본 중 결함이 있는 버전을 18개월 동안 실행했다고 말했다. 다른 개발자들은 각자의 시도에서 문제를 겪었다. 새로운 패치들은 가장 널리 사용되는 캐시 읽기 경로에서 folio 참조를 증가·감소시키는 작업을 제거하는 것을 목표로 한다. 다만 토르발스는 실제 워크로드에서는 합성 테스트와 비교해 성능 향상이 훨씬 작을 것이라고 경고했다.

Claude Code의 역할과 결과의 한계

토르발스의 트리에는 noref-filemap-read-with-llm이라는 이름의 실험 브랜치가 등장했으며, 이후 시리즈에는 Claude Code의 역할에 대한 설명이 포함됐다. 토르발스가 전한 바에 따르면 이 도구는 구현, 테스트, 초기 문서화를 작성하고 그의 지시에 따라 코드를 검토했으며, 성능 테스트를 직접 실행한 것은 토르발스였다.

첫 번째 시리즈는 그의 노트북에서 읽기 처리량을 초당 약 1,000만 회에서 3,300만 회로 높였고, 읽기 한 회당 커널 사이클 수를 약 2,950회에서 725회로 줄였다. 수정된 시리즈는 Threadripper 시스템에서 높은 부하가 걸린 상태의 성능을 초당 1,330만 회에서 3억 400만 회로 높였으며, 읽기 한 회당 사이클 수는 약 20,000회에서 735회로 감소했다.

성능 수치만으로는 충분하지 않은 이유

이러한 향상에는 잠재적인 비용이 따랐다. 초기 구현은 CPU가 회수 대기 중인 페이지 1,024개를 초과하면 강제 대기 구간을 발생시켰다. 또한 연결되지 않은 사용자 페이지를 읽을 때 기존 경로로 돌아가기 전에 추가 오류가 발생해, 16바이트 단일 스레드 읽기의 비용이 약 4,150사이클에서 6,550사이클로 증가했다. 이 회귀가 rcu-free-v3 버전에도 남을지는 아직 명확하지 않다.

리뷰에서 더 중요한 위험이 드러나다

Matthew Wilcox는 새로운 플래그 PG_rcu_free의 사용에 이의를 제기하고, 페이지 유형과 비활성 folio를 회수하는 다른 메커니즘에 기반한 대안을 제안했다. Kiryl Shutsemau는 이 플래그를 64비트 시스템으로 제한하자고 제안했으며, David Hildenbrand도 이 방향을 지지했다.

Shutsemau는 또한 filemap_read_rcu_batch() 함수에서 경쟁 조건을 발견했다. folio를 교체한 뒤 파일 크기가 확장되면 실제로 기록되지 않은 데이터가 노출될 수 있다는 내용이다. 토르발스는 파일 크기를 더 이른 시점에 읽고 검사를 통합하자고 제안했으며, 이 내용은 수정된 패치에 포함됐다.

certi.news의 편집적 해석: 이 사례는 AI 프로그래밍 도구가 커널 테스트에서 큰 개선에 빠르게 도달할 수 있지만, 동시성과 메모리 수명 주기를 이해하는 전문적인 리뷰의 필요성을 없애지는 못한다는 점을 보여준다. 여기의 기록적인 수치는 특정 환경에서의 성능 향상을 입증할 뿐, 자동으로 병합할 수 있는 상태이거나 구현의 안전성을 보장한다는 뜻은 아니다.