토르발즈, Claude Code가 작성한 8개 커널 패치: 노트북에서 3배의 읽기 속도 기록, 병합되지 않음

• 책: AI Agents Pocket Guide
• 저자: Thinking in Go (2권 시리즈) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• 프로젝트: Hermes IDE | GitHub — Claude Code 및 기타 AI 코딩 도구와 함께 개발하는 개발자를 위한 IDE
• 저자: xgabriel.com | GitHub

브랜치 이름이 모든 것을 말해줍니다: noref-filemap-read-with-llm. Linus Torvalds는 이를 자신의 Linux 트리에 푸시했고, Phoronix가 Linux 7.3-rc7 태그를 기다리던 중 (Hardware Busters) 이를 발견했습니다.

이 패치들은 Linux 7.3-rc6을 기반으로 페이지 캐시가 작은 읽기 요청을 처리하는 방식을 재작업한 여덟 개의 패치를 포함하고 있습니다. 커버 레터는 Anthropic의 코딩 에이전트인 Claude Code가 코드, 테스트 프로그램, 미해결 문제 목록에 대한 검토, 그리고 커버 레터 초안 작성 자체를 담당했으며, 모든 것은 Torvalds의 지휘 아래 이루어졌음을 언급합니다 (Hardware Busters, It's FOSS).

그의 노트북에서, 하나의 파일을 읽는 여덟 개의 스레드는 약 10백만 회에서 초당 3천~3만 3백만 회의 읽기 속도로 향상되었습니다 (It's FOSS). 이 시리즈는 병합되지 않았습니다 (Hardware Busters).

에이전트가 작성한 코드를 배포하는 사람이라면, 3배의 성능 향상보다 패키징이 더 중요합니다. 표지 서신에는 누가 어떤 부분을 했는지 명시하고 무엇이 여전히 문제가 되는지 나열해야 합니다.

패치가 변경하는 내용

페이지 캐시에서 발생하는 모든 작은 읽기 작업은 폴리오(folio)에 대한 참조를 가져온 다음 놓아줍니다. 이는 동일한 캐시 라인에 대한 원자적 쓰기(atomic writes)이므로, 여러 코어가 하나의 파일을 읽을 때 그 라인이 코어들 사이에서 왔다 갔다 합니다. Torvalds의 Core i7-8565U 노트북에서 8개의 스레드가 16바이트 pread() 호출을 수행할 때, 이 단일 라인은 교차 코어 로드 HITM(cross-core load HITMs)의 99.92%를 차지했습니다(Hardware Busters). 한 커널 개발자는 고객의 워크로드(customer's workload)를 인용하며 2024년에 이 병목 현상을 지적했습니다(It's FOSS).

이 수정은 RCU에 의존합니다. 캐시를 벗어나는 폴리오는 유예 기간(grace period) 후에만 페이지 할당자(page allocator)로 돌아가므로, 리더는 참조 카운트를 건드리지 않고 페이지에서 바로 복사할 수 있습니다. 그 대가는 재사용되기 전에 잠시 동안 유휴 상태로 있는 메모리입니다(It's FOSS). 8개의 패치 중 두 개는 CPU가 1,024페이지를 초과하여 대기열에 넣을 경우 신속한 유예 기간(expedited grace period)을 강제하는 안전장치를 추가했으며, Torvalds는 여전히 지연된 해제를

아래 내용은 CPU 완화(mitigations) 기능이 비활성화된 4코어, 8스레드 노트북에서 측정된 결과이며, Hardware Busters에 보고되었습니다:

3배라는 수치는 하나의 데이터 포인트일 뿐이며, 해당 시리즈를 지시한 사람이 측정하여 한 대의 장비에서 측정한 것입니다. 이 수치를 서버에 적용하기 전에 반드시 자체 하드웨어에서 브랜치(branch) 테스트를 해보십시오.

커버 레터를 리뷰 체크리스트로 활용하세요

작업 분배가 명확하게 제시되어 있습니다. 에이전트(agent)는 위에서 언급된 모든 것을 Torvalds의 지시에 따라 생성했으며, 벤치마크는 그의 자체 장비에서 실행되었습니다 (Hardware Busters).

이는 팀에 보내는 에이전트 작성 변경 사항(agent-written change)에 적용할 수 있는 네 가지 습관으로 연결됩니다:

1. 브랜치 이름이나 PR 제목에 에이전트가 작성했음을 명시하세요. 리뷰어들이 읽는 방식을 조정하게 됩니다.
2. 이름을 밝히는 하드웨어에서 직접 수치를 실행해 보세요. 벤치마크는 에이전트가 작성할 수 있지만, 결과는 당신의 소유입니다.
3. 회귀 사례를 성공적인 결과 옆에 동일한 정밀도로 게시하세요.
4. 미해결 문제 목록(open-problems list)을 유지하고, 에이전트에게 이를 작성하도록 도움을 받으세요. 에이전트가 자신의 작업을 검토하도록 요청하는 것은 다른 사람이 시간을 들이기 전에 실행하기에 비용이 저렴합니다.

이는 그에게 처음 있는 일이 아닙니다. 그는 Intel Xe 그래픽 드라이버 버그에 대한 이전 AI 지원 수정도 FOSS에서 연결했습니다. 그리고 프라하 열린 소스 서밋 유럽(Open Source Summit Europe)에서 Torvalds는 ZDNet과 It's FOSS의 인용을 통해 "사실 AI를 사용하는 것이 정말 좋다"고 말했습니다.

커널에는 이미 이 규칙이 있습니다

공개(disclosure) 형식을 새로 만들 필요는 없습니다. 커널의 AI 코딩 어시스턴트 가이드는 기여가 Assisted-by: LLM [TOOL1] [TOOL2] 태그를 포함하도록 요청하며, 여기서 도구는 coccinelle이나 sparse와 같은 선택적 분석 도구입니다. 또한 "AI 에이전트는 Signed-off-by 태그를 추가해서는 안 됩니다."라고 명시하는데, 이는 개발자 출신 증명서(Developer Certificate of Origin)는 오직 인간만이 인증할 수 있기 때문입니다. 인간은 모든 AI 생성 코드를 검토하고 그에 대한 전적인 책임을 집니다.

사용자 자신의 레포지토리에서도 일반 git으로 동일한 관례를 채택할 수 있습니다. 커밋할 때 트레일러(trailer)와 자신만의 서명을 추가하세요:

git commit -s --trailer "Assisted-by: LLM"

그러면 검토자는 어떤 브랜치의 커밋이 에이전트의 도움을 받았는지 목록화할 수 있습니다:

git log main..HEAD \
  --format='%h %s %(trailers:key=Assisted-by)'

--trailer 옵션과 %(trailers) 플레이스홀더는 표준 git 기능입니다.

Hermes IDE가 들어맞는 곳

저는 Hermes IDE를 구축했으니 이 부분을 염두에 두고 읽어주세요. Torvalds의 브랜치 형태, 에이전트가 자체 이름의 브랜치에서 작업하고 조각별로 검토하는 방식은 Hermes가 기반으로 하는 워크플로우입니다. ⌘N을 누르면 각 작업이 자체 hermes/<name> 브랜치의 자체 작업 공간(worktree)에서 시작되며, 모든 에이전트의 차례는 저장되어 한 번의 차례를 비교하거나 복원할 수 있고, 검토 데스크(Review Desk)(⌘G)에서는 차례별 또는 파일별로 변경 사항을 보여줍니다(Hermes README). 이 도구는 다른 에이전트 옆의 실제 터미널에서 Claude Code를 실행합니다. 사용자의 벤치마크나 미해결 문제 목록은 작성하지 않으며, 그 부분은 사용자에게 맡겨둡니다. Hermes는 무료이며 소스 코드가 공개되어 있고 macOS, Windows, Linux에서 사용할 수 있으며 Anthropic이나 Linux Foundation과 제휴 관계가 아닙니다.

유용했다면

코딩 에이전트에게 작업을 위임한다면, 다음 에이전트 브랜치에서 Torvalds의 커버레터에 나온 네 가지 습관을 시도해보고, Hermes IDE는 그러한 각 브랜치에 자체 작업 공간과 차례별 검토 기능을 제공합니다. 만약 직접 에이전트를 구축한다면, AI Agents Pocket Guide에서 Claude Code와 같은 도구의 배경 패턴을 다루고 있습니다.