Google 엔지니어들이 Linux 커널 코드 리뷰를 위한 Agentic AI 시스템 'Sashiko' 공개

TL;DR Highlight

Google의 Linux 커널 팀이 Gemini 3.1 Pro 기반의 AI 코드 리뷰 에이전트 'Sashiko'로 인간 리뷰어가 놓친 버그의 53%를 탐지했다.

Who Should Read

Linux 커널 기여자나 대형 오픈소스 프로젝트 유지관리자 중 자동화된 코드 리뷰 파이프라인 도입을 검토 중인 개발자. AI 에이전트를 코드 품질 검증에 실제 적용하는 사례가 궁금한 백엔드/시스템 개발자.

Core Mechanics

Google의 Linux 커널 팀 소속 Roman Gushchin이 Sashiko를 공개했다. 수개월 간 Google 내부에서 사용하던 시스템을 이제 모든 Linux 커널 메일링 리스트 패치 제출에 적용하도록 확장했다.
Sashiko는 'Fixes:' 태그가 붙은 최근 upstream Linux 커널 이슈 1,000개를 기준으로 테스트했을 때 53%의 버그를 탐지했다. 발표자는 '이 53%는 인간 리뷰어가 100% 놓친 이슈들'이라고 강조했다.
기본적으로 Gemini 2.5 Pro(원문에는 'Gemini 3.1 Pro'로 표기)를 사용하도록 설계됐지만, Claude 및 다른 LLM과도 동작하도록 만들어졌다. 흥미롭게도 시스템 자체는 Rust로 작성됐고 Claude와 공동 작성됐다.
Google이 Sashiko의 토큰 비용과 인프라를 지원하며, 프로젝트 호스팅은 Linux Foundation으로 이전 예정이다. 코드는 GitHub(github.com/sashiko-dev/sashiko)에서 오픈소스로 공개됐다.
웹 인터페이스(sashiko.dev)를 통해 현재 리뷰 중인 패치셋과 결과를 볼 수 있다. 리뷰 결과에는 'Critical', 'High' 등의 심각도가 붙은 findings가 포함된다.
중요한 설계 원칙으로, Sashiko는 메일링 리스트에 직접 스팸성 댓글을 남기지 않도록 설계됐다. 리뷰 결과는 별도 웹 인터페이스에서만 확인 가능하고, 커널 커뮤니티의 기존 워크플로우를 방해하지 않는 방향을 택했다.
Agentic AI 코드 리뷰라는 점에서 단순 정적 분석과 다르게, LLM이 패치의 맥락을 이해하고 버그 가능성을 판단하는 방식으로 동작한다. 한 댓글 작성자는 '코드를 작성하는 모델과 리뷰하는 모델을 분리하는 것 자체가 핵심'이라고 지적했다.

Evidence

53% 탐지율에 대해 false positive(오탐) 비율을 함께 공개해야 한다는 비판이 제기됐다. '모든 코드를 버그라고 표시하면 100% 탐지율을 달성할 수 있다'는 반론처럼, precision(정밀도)없이 recall(재현율)만 강조하면 실제 유용성을 판단하기 어렵다는 의견이다. 인간 리뷰어가 AI 오탐 보고서에 치이게 되면 시스템 전체에 대한 신뢰가 무너질 수 있다는 우려도 있었다.
'100%의 이슈가 인간 리뷰어에게 놓쳤다'는 표현에 대해 의미 해석 논쟁이 있었다. 한 댓글 작성자는 '최초 코드 리뷰 단계에서 놓쳤다는 뜻이지, 이후 개발 과정에서 개발자가 스스로 발견한 버그까지 포함한 건 아닐 것'이라고 지적했다. 코드는 한 번 리뷰되고 끝이 아니라 계속 사람들이 보기 때문에, 표현이 다소 과장됐다는 뉘앙스였다.
웹 UI(sashiko.dev)의 UX에 대한 피드백이 있었다. Status 컬럼이 'Pending', 'In Review' 같은 내부 파이프라인 상태를 보여주는 반면, 실제 중요한 findings는 화면 오른쪽 끝에 묻혀 있다는 지적이다. Critical/High 심각도 findings를 필터링하거나 강조해서 보여주는 기능이 없어 실용성이 떨어진다는 의견이었다.
스타일/구조 변경 패치를 자동으로 제출하는 것에 대한 우려가 있었다. 한 댓글 작성자가 실제 Sashiko 리뷰 결과 링크를 보여주며, 코드 스타일 변경이 자동화된 방식으로 대규모 커널 코드베이스에 적용될 경우 기존 개발 흐름에 부담을 줄 수 있다고 지적했다. 버그 탐지보다 스타일 정리 중심으로 동작하는 것처럼 보인다는 우려였다.
작성 모델과 리뷰 모델을 분리하는 접근 방식에 대해 긍정적인 반응이 있었다. 한 댓글 작성자는 '자신도 소규모로 같은 방식을 쓰고 있는데, 같은 이유로 자기 PR을 스스로 리뷰하지 않는 것처럼 self-review는 놓치는 게 많다'고 공감했다. 시스템이 Rust로 작성됐고 Claude와 공동 개발된 점도 흥미롭다는 댓글도 있었다.

How to Apply

Linux 커널에 패치를 제출하는 개발자라면, 메일링 리스트에 보내기 전에 sashiko.dev에서 해당 패치셋의 리뷰 결과를 미리 확인할 수 있다. Critical/High findings가 있다면 제출 전에 수정해 리뷰 사이클을 단축할 수 있다.
자체 대형 코드베이스에 유사한 AI 코드 리뷰 파이프라인을 구축하려면, Sashiko의 오픈소스 코드(github.com/sashiko-dev/sashiko)를 참고해 '작성 모델 ≠ 리뷰 모델' 원칙을 적용할 수 있다. Gemini 외에도 Claude API로 교체 가능하도록 설계됐으므로 이미 Claude를 사용 중인 팀도 적용이 용이하다.
AI 코드 리뷰 시스템 도입을 검토 중이라면, Sashiko 사례처럼 리뷰 결과를 기존 커뮤니케이션 채널(메일링 리스트, PR 댓글)에 직접 스팸하지 않고 별도 대시보드로 분리하는 설계를 고려해야 한다. false positive가 많을 경우 직접 알림보다 별도 UI가 팀 신뢰를 유지하는 데 유리하다.
53% 버그 탐지율이라는 지표를 그대로 신뢰하기보다, 실제 도입 전에 false positive rate(오탐률)도 함께 측정해야 한다. 자신의 코드베이스에서 최근 'Fixes:' 커밋 100~200개를 뽑아 AI 리뷰 결과와 대조하는 방식으로 precision/recall을 직접 측정해볼 수 있다.

Terminology

Agentic AI단순히 질문에 답하는 게 아니라, 여러 단계의 작업을 스스로 계획하고 실행하는 AI 시스템. 코드 리뷰 맥락에서는 패치를 읽고, 관련 컨텍스트를 찾고, 버그 가능성을 판단하는 일련의 과정을 자율적으로 처리한다.

upstreamLinux 커널의 공식 메인 저장소(Linus Torvalds가 관리하는 저장소)를 가리킨다. 'upstream에 패치를 보낸다'는 건 공식 커널에 변경 사항을 제안한다는 의미다.

Fixes: 태그Linux 커널 커밋 메시지에 붙는 특수 태그로, 이 커밋이 어떤 이전 커밋의 버그를 고치는지 명시한다. Sashiko의 벤치마크에서는 이 태그가 붙은 커밋의 원인 코드를 AI가 미리 찾아낼 수 있는지를 측정했다.

recall (재현율)전체 버그 중 AI가 실제로 잡아낸 비율. 53% recall이면 100개 버그 중 53개를 찾아냈다는 뜻. 높을수록 좋지만, 오탐도 많아질 수 있어 precision(정밀도)과 함께 봐야 한다.

precision (정밀도)AI가 '버그다'라고 판단한 것 중 실제로 버그인 비율. precision이 낮으면 오탐이 많아 개발자가 거짓 경보를 처리하느라 시간을 낭비하게 된다.

LKMLLinux Kernel Mailing List의 약자. Linux 커널 개발의 핵심 소통 채널로, 패치 제출, 리뷰, 토론이 모두 이 메일링 리스트를 통해 이뤄진다.