초당 3,300만 회 읽기와 캐시 경합의 종말: 리누스 토발즈가 클로드 코드로 짠 리눅스 커널 패치의 득과 실

2년간 묵힌 16바이트의 병목: 토발즈가 인공지능에 커널 운전대를 맡긴 이유

전 세계 서버와 클라우드 인프라의 심장인 리눅스 커널 개발 현장에서 상징적인 사건이 일어났다. 평소 인공지능 생성 코드의 품질과 신뢰성에 대해 극도로 보수적인 태도를 취해 온 리눅스 창시자 리누스 토발즈(Linus Torvalds)가 직접 AI 코딩 어시스턴트인 클로드 코드(Claude Code)를 지휘해 커널 패치 시리즈를 작성하고 이를 깃(Git) 저장소에 공개했다.

이번 작업의 핵심은 2024년부터 리눅스 커널 커뮤니티의 오랜 골칫거리였던 ‘페이지 캐시(Page Cache) 경합’ 문제를 풀어내는 데 있었다. 리눅스는 디스크에서 읽어온 파일 데이터를 메모리의 페이지 캐시에 보관해 두고, 여러 프로그램이 동일한 파일에 접근할 때 메모리에서 즉시 데이터를 넘겨준다. 문제는 여러 스레드가 동시에 같은 파일의 작은 데이터 조각(예: 16바이트 단위의 짧은 읽기 명령)을 쉴 새 없이 읽어 들일 때 발생했다.

스레드가 데이터를 읽을 때마다 해당 메모리 블록(Folio)이 갑자기 사라지지 않도록 사용 횟수(참조 카운트)를 1씩 올리고, 다 읽으면 1씩 내린다. 이 숫자를 바꾸는 과정은 CPU의 여러 코어가 동시에 건드려 숫자가 엉키지 않도록 ‘원자적 쓰기(Atomic Write)’ 방식으로 처리된다. 결국 수많은 CPU 코어가 좁은 은행 창구 하나에 한꺼번에 몰려 서로 번호표를 빼앗으려 다투는 형태가 벌어지며, 코어들이 연산은 하지 못하고 신호만 주고받느라 멈춰 서는 극심한 병목이 발생했다.

토발즈는 자신이 직접 지휘하고 Claude Code가 보조하는 방식으로 총 8개로 구성된 패치 시리즈(noref-filemap-read-with-llm 브랜치)를 작성했다. 메모리를 다 썼다고 해서 즉시 비우는 대신, 읽기 작업이 끝날 때까지 기다려주는 안전 유예 기간(RCU Grace Period)을 둔 뒤 천천히 메모리를 회수하는 방식으로 설계 뼈대를 바꿨다. 그 결과 스레드가 번호표를 일일이 고치지 않고도 안전하게 데이터를 곧바로 복사해 갈 수 있는 고속 전용 통로가 열렸다.

초당 990만 회에서 3,300만 회로: 인텔 코어 i7 벤치마크가 증명한 수치 격차

이번 패치의 효과는 단순한 코드 정리에 그치지 않고 구체적인 수치로 증명되었다. 토발즈는 체코 프라하에서 열린 리눅스 플럼버스 콘퍼런스 현장에서 자신이 지참한 인텔 8세대 Core i7-8565U 노트북(4코어 8스레드 환경)을 통해 16바이트 단위의 파일 읽기(pread()) 벤치마크를 직접 수행했다.

기존 커널에서는 8개 스레드가 동일한 파일 페이지를 읽을 때 코어 간 간섭 지표(HITMs, 수정된 캐시 라인 적중)가 전체 크로스 코어 부하의 무려 99.92%를 차지했다. 연산 능력의 전부를 데이터 읽기가 아니라 캐시 상태를 동기화하는 헛바퀴 돌리기에 소모하고 있었던 셈이다. AI와 협업해 작성한 새 패치를 적용하자 이 경합이 극적으로 사라졌다.

아래 표는 기존 리눅스 메인라인 커널과 토발즈가 공개한 실험용 브랜치 간의 작업 처리량 및 CPU 사이클 소모량을 비교한 팩트 시트다.

처리량이 3배 이상 폭증하고 커널 내부에서 소모되는 CPU 연산 사이클이 4분의 1 토막으로 줄어들었다. 단일 스레드 작업에서도 미세한 사이클 단축이 확인되었으며, 토발즈는 CPU 소켓이 여러 개이거나 코어 수가 수십 개에 달하는 엔터프라이즈 서버 환경에서는 코어 간 간섭 완화 효과가 이보다 훨씬 더 극적으로 나타날 것이라고 덧붙였다.

기업 실무와 서버 인프라에 던지는 충격: 공짜 점심은 없다

이 패치가 리눅스 전반의 속도를 무조건 3배 올려주는 마법의 탄환은 아니다. 리포트 분석팀이 코드와 벤치마크 데이터를 정밀 검증한 결과, 성능을 얻는 대가로 치러야 하는 명확한 기술적 맞교환(Trade-off)이 존재한다.

1. CPU 코어 간 간섭 제거와 고밀도 멀티코어 서버 효율

현대 클라우드 서버는 64코어, 128코어에 달하는 대규모 프로세서를 탑재한다. 웹 서버, 캐시 서버, 인메모리 데이터베이스 등 동일한 정적 설정 파일이나 인덱스 블록을 수천 개의 스레드가 동시에 읽어 들이는 환경에서는 CPU 캐시 동기화 부하가 심각한 서비스 지연(Latency Spike)을 유발한다. 이번 패치는 참조 카운터 갱신을 생략함으로써 16바이트 안팎의 잦은 읽기 요청에서 발생하는 CPU 발열과 유휴 대기 시간을 획기적으로 줄여줄 잠재력을 지녔다.

2. 메모리 즉각 회수 포기와 RCU 대기 시간이 부르는 메모리 압박

세상에 공짜 성능은 없다. 기존 커널은 페이지 캐시에서 빠져나온 메모리를 즉각 다른 용도로 재할당할 수 있었다. 하지만 새 패치는 읽기 스레드가 안전하게 작업을 마칠 때까지 메모리 해제를 강제로 미룬다. 토발즈 본인도 깃 커밋 메시지에서 “메모리 회수(Reclamation) 지연 문제는 이번 패치 시리즈에서 가장 덜 풀린 영역”이라고 인정했다. 메모리 여유 공간이 극도로 빡빡한 임베디드 장비나 초고밀도 컨테이너 노드에서는 반환되지 않은 메모리 조각들이 쌓여 시스템 전체의 메모리 부족(OOM) 현상을 앞당길 위험이 있다.

3. 매핑되지 않은 사용자 페이지 예외 실패가 유발하는 성능 후퇴

새로운 경로는 메모리가 이미 준비되어 있다는 가정을 바탕으로 동작한다. 만약 읽어 들이려는 메모리 페이지가 아직 가상 주소 공간에 매핑되지 않은 상태라면, 고속 통로는 예외(Exception)를 일으키며 실패하고 결국 기존의 느린 코드로 되돌아가는 이중 단계를 밟는다. 결과적으로 특정 특이 조건에서는 기존 커널보다 오히려 시스템 콜 처리 속도가 떨어지는 성능 후퇴 현상이 발생한다. 바로 이 결함 때문에 이 코드는 리눅스 7.3 메인라인에 정식 병합되지 못하고 별도 실험 브랜치에 격리되어 있다.

장인 엔지니어의 통제권과 차세대 AI 도구의 실무적 결합

토발즈의 이번 실험은 소프트웨어 엔지니어링 생태계에 중요한 이정표를 남겼다. 불과 2년 전만 해도 “AI는 버그를 찾는 보조 도구일 뿐 코드를 짜는 주체가 될 수 없다”고 선을 그었던 그가, 이제는 실제 커널의 가장 깊숙하고 위험한 메모리 관리 서브시스템에 AI를 깊숙이 끌어들였다.

현장 개발자들에게 익숙한 차세대 AI 코드 편집 도구 Cursor나 Claude Code 같은 도구들은 이미 단순 자동완성을 넘어 복잡한 시스템 아키텍처의 트레이드오프를 코드로 구현하는 단계에 진입했다. 그러나 이번 사례에서 진짜 주목해야 할 지점은 ‘AI가 코드를 짰다’는 사실이 아니라, ‘누가 어떻게 지휘했는가’에 있다.

토발즈는 프라하 대담에서 “AI는 올바르게 다루고 도구로 대할 때 비로소 훌륭하며, 프로그래밍을 훨씬 즐겁게 만들어준다”고 밝히면서도, “진짜 중요하고 본질적인 시스템 작업을 할 때는 지극히 신중해야 한다”고 선을 그었다. AI가 작성한 8개의 패치 시리즈 중 성능을 올리는 코드는 완벽해 보였지만, 메모리 반환과 비정상 케이스 예외 처리라는 시스템 안정성의 핵심 고리는 결국 인간 리드 엔지니어의 날카로운 눈을 통과하지 못해 ‘미완성’ 꼬리표를 달았다.

시스템 소프트웨어 엔지니어링 조직의 AI 도입 적합도 판정

이번 리눅스 커널 패치 실험은 고성능 시스템 소프트웨어와 인프라 백엔드를 다루는 기술 조직에 명확한 가이드라인을 제시한다. AI 코딩 어시스턴트를 현장에 투입할 때 즉각적인 성과를 낼 수 있는 환경과, 반대로 치명적인 장애를 부를 수 있는 영역을 냉정하게 판정해야 한다.

지금 즉시 도입해야 할 기업 (Fit 조건 3가지)

• 마이크로 벤치마크 및 테스트 스위트 자동화가 절실한 팀: 이번 사례에서 Claude Code가 가장 뛰어난 역량을 발휘한 영역 중 하나는 성능 개선을 입증하는 테스트 프로그램과 코너 케이스 검증 스위트를 빠르게 짜낸 점이다. 복잡한 시스템 콜을 반복 호출하며 CPU 사이클을 측정하는 테스트 코드를 구축하는 데 드는 공수를 70% 이상 아낄 수 있다.

• 도메인 전문가가 명확한 설계 방향성을 쥐고 있는 조직: “RCU 유예 기간을 활용해 폴리오 참조 카운트를 우회하자”는 설계 가설은 토발즈의 머리에서 나왔다. 이처럼 소프트웨어 아키텍처와 메모리 모델을 완벽히 이해하는 시니어 엔지니어가 키를 잡고, AI를 빠른 손발로 부릴 수 있는 팀이라면 개발 주기를 수개월에서 수일 단위로 단축할 수 있다.

• 격리된 프로토타입 브랜치에서 사전 실험을 진행하는 조직: 메인 배포 브랜치에 직접 코드를 붓는 것이 아니라, 별도 실험 브랜치에서 하드웨어 프로파일링을 거치며 한계를 투명하게 문서화할 수 있는 성숙한 코드 리뷰 문화를 가진 조직에 최적이다.

도입을 보류하고 지켜봐야 할 기업 (Non-Fit 리스크 3가지)

• 코드 리뷰어가 내부 동작 원리를 설명하지 못하는 조직: AI가 토해낸 코드가 벤치마크 점수를 3배 올려주더라도, 그 뒤에서 일어나는 메모리 반환 지연(RCU Grace Period)이나 언매핑 예외 실패 같은 2차 파급력을 짚어낼 시니어 인력이 없다면 시스템 전체가 원인 모를 먹통(OOM Hang)에 빠지게 된다.

• 극도의 메모리 제약 환경을 다루는 임베디드 및 엣지 시스템 팀: 처리 속도를 올리기 위해 메모리 즉각 회수를 희생하는 최적화 기법은 자원이 넉넉한 멀티코어 서버에 적합하다. 램 용량이 수 메가바이트 단위로 제한된 기기에서는 AI가 제안한 캐시 최적화 코드가 치명적인 메모리 누수와 기기 리셋을 부른다.

• 구체적인 성능 프로파일링 환경이 갖춰지지 않은 조직: 토발즈는 캐시 라인 적중률(HITMs)과 코어별 연산 사이클을 측정하는 명확한 하드웨어 도구를 가지고 있었기에 AI 패치의 효과와 한계를 검증할 수 있었다. 실측 도구 없이 겉으로 드러나는 성공 여부만 보고 AI 코드를 배포하는 관행은 장애 발생 확률을 높일 뿐이다.