리눅스 커널이 LLM 코드를 받아들이는 방식: 인간 책임과 검증 게이트

AI를 거부하지 않되, merge 권한은 인간에게 남긴다

2026년 7월 15일 Linus Torvalds는 자동 LLM 패치 리뷰 시스템 Sashiko를 둘러싼 반발에 답하며 LKML에 “Linux is not an anti-AI project”라는 입장을 밝혔다. 그는 AI를 다른 개발 도구와 마찬가지인 유용한 도구로 규정했고, top-level maintainer로서의 방침을 분명히 했다.

이는 2024년 10월 AI 마케팅의 90%를 hype로 평가했던 태도와 대비된다. 다만 AI 산출물을 무비판적으로 받아들이겠다는 뜻은 아니다. Torvalds는 2026년 5월 AI가 생성한 버그 리포트가 security 메일링 리스트를 “거의 관리 불가능(almost entirely unmanageable)”하게 만들었다고도 지적했다.

논점은 AI 사용 허용 여부가 아니라 저품질 자동 생성물인 AI slop을 어떻게 막고, 검증된 리뷰 도구의 생산성은 어떻게 활용할지에 있다. 커널의 답은 도구 금지가 아닌 인간 책임의 강화다.

기존 정적분석 체인에 더해진 AI 리뷰 레이어

커널 개발에서 LLM은 코드 작성 보조 도구와 패치 리뷰 도구라는 두 흐름으로 들어온다. Copilot·Claude 등의 assistant가 코드 생성을 돕고, Sashiko는 LKML에 제출된 패치를 자동 검토한다.

Google 엔지니어 Roman Gushchin이 공개한 Sashiko 분석은 1500개 email thread를 대상으로 했다. false-positive는 약 10%, true-positive는 약 85%였으며, critical/high 심각도 판정 정확도는 약 97%로 제시됐다.

AI 리뷰 결과는 merge를 결정하는 판정이 아니라 maintainer가 검토할 신호다. 기존의 sparse 타입 검사, coccinelle 패턴 기반 semantic patch, checkpatch와 연결되어 컴파일, 정적분석, AI 리뷰, 인간 리뷰, 회귀 테스트로 이어지는 다층 검증에 포함된다.

⤢✕

커널 코드에서 AI의 신뢰는 제안까지다

커널 결함은 메모리 손상, 권한 상승, 시스템 전체 crash로 번질 수 있다. 기능 단위 장애나 롤백으로 국한될 수 있는 애플리케이션 버그와 비교하면 blast radius가 훨씬 크다.

NVIDIA 엔지니어이자 maintainer인 Sasha Levin은 kernel 6.15에 LLM이 전부 작성한 패치를 미공개 제출했다. 해당 패치는 동작했지만 성능 회귀(performance regression)를 포함했고, 커뮤니티 반발의 계기가 됐다.

이 사례에서 드러난 신뢰 경계는 명확하다. AI 산출물은 제안으로 다룰 수 있지만, 정확성을 certify(인증)하는 역할은 인간에게 남는다. race condition, lock ordering, 메모리 배리어처럼 concurrency 정확성이 필요한 영역은 인간 리뷰가 필수이며, 존재하지 않는 API나 잘못된 error path를 그럴듯하게 만드는 hallucination 위험도 육안 검증을 요구한다.

Assisted-by가 남기는 흔적과 Signed-off-by가 지는 책임

kernel.org는 Documentation/process/coding-assistants.html로 AI 코딩 보조 도구에 관한 프로젝트 전역 정책을 정식 채택했다. 여기서 Signed-off-by는 DCO 인증을 뜻하는 법적 구속력이 있는 태그이며 인간만 사용할 수 있다. AI의 개입은 별도 Assisted-by 태그로 밝혀야 한다.

Assisted-by: Claude:claude-3-opus coccinelle sparse

이 형식은 모델, 에이전트, 보조 도구를 드러내 maintainer에게 추가 검토가 필요할 수 있음을 알린다. 패치를 제출한 인간은 생성 방식과 관계없이 정확성, 보안, 라이선스 준수에 전적 책임을 진다.

정책의 전제는 “악의적 제출자는 어차피 문서를 읽지 않는다”는 판단이다. 따라서 특정 도구를 규제하기보다 책임이 누구에게 귀속되는지 추적하는 데 집중한다. 학습 데이터 출처가 불명확한 AI 코드의 라이선스 오염 가능성 역시 인간 제출자가 검증해야 할 부담으로 남는다.

코드의 영향 범위에 따라 게이트도 달라진다

축	고신뢰 시스템 코드(커널)	애플리케이션 코드(웹·업무)
오류 blast radius	시스템 전체 crash·보안 침해	기능 단위 장애·롤백 가능
AI 코드 신뢰 경계	제안까지만, 인증은 인간	상당 부분 자동 수용 가능
검증 강도	정적분석+AI+인간+회귀 다층	단위 테스트+CR 수준
책임 소재	제출 인간 전적 책임(DCO)	팀/조직 분산 책임
concurrency 정확성	필수 인간 검증 영역	상대적으로 낮은 비중
도입 게이트	Assisted-by 의무 공개	관행적 도구 사용 허용

AI는 recall(누락 탐지)에서 강점을 보이고, 인간은 semantic 정확성과 설계 의도를 판단하는 데 강점이 있다. 고신뢰 코드에는 “AI 보조 + 인간 최종 인증”, 애플리케이션 코드에는 “AI 주도 + 샘플 검증”처럼 위험도에 따라 다른 통제 수준을 적용하는 것이 합리적이다.

커널의 정책은 대규모 오픈소스에서 처음으로 공식 AI 거버넌스를 마련한 사례로 평가된다.

품질 거버넌스에서 보는 AI 코드 통제

ISO/IEC 25010의 신뢰성(Reliability), 보안성(Security), 유지보수성(Maintainability)은 AI 코드 수용 게이트를 판단하는 품질 특성이 된다. CMMI와 ISO/IEC/IEEE 12207 관점에서 AI는 verification·validation 활동에 통합되는 도구이면서 동시에 새 통제 대상이다.

Assisted-by 태그는 SCM에서 AI 개입 이력을 감사 추적(audit trail)으로 남기는 traceability 통제다. DCO 인증을 인간에게 귀속하는 방식은 책임 소재 명확화(accountability) 원칙과도 맞닿아 있다.

라이선스 오염과 hallucination은 SW 개발 리스크 레지스터에 올리고, 게이트 통과 기준으로 관리할 수 있다. 감리에서는 AI 생성 코드 비율, 검증 커버리지, 회귀 결함률을 품질 메트릭으로 계량화해 프로세스 성숙도를 평가한다.

⤢✕

오픈소스 AI 정책이 남긴 과제

커널의 Assisted-by 모델은 disclosure + human accountability 정책을 구성하려는 다른 대규모 오픈소스 프로젝트의 참조 template으로 확산할 전망이다. Sashiko류 AI 리뷰는 maintainer의 초기 triage 부담을 줄일 수 있지만, false-positive 관리와 signal 신뢰도 튜닝은 계속 남는 과제다.

정책 설계의 중심에는 특정 벤더에 묶이지 않고 “도구는 자유, 책임은 인간”으로 두는 원칙이 있다. 고신뢰 코드베이스를 운영하는 조직이라면 코드 등급에 따라 AI 도입 게이트를 차등화하고, 공개·추적·책임을 명문화할 필요가 있다.