핵심 요약
2026년 4월 17일, Kernel Summit에서 리누스 토르발스가 키노트 중 한 질문에 답하며 AI 생성 커널 패치에 대해 단호한 입장을 밝혔다. 발언은 곧바로 Reddit과 LWN에서 하루 만에 수천 개 댓글로 번졌다.
문제의 발언 원문 요지
"자동화된 도구가 버그를 '찾아 주는' 것은 환영한다. 그러나 그 도구가 만들어 낸 해결책이 메인라인에 들어오려면, 그걸 제출한 사람이 그 한 줄 한 줄을 설명할 수 있어야 한다. 최근 내가 본 일부 패치는, 제출자가 왜 그렇게 고쳤는지조차 모르고 있었다. 그런 건 커널에 안 들어간다."
무엇이 리누스를 자극했나
지난 몇 달 사이 AI 기반 자동 버그 헌팅 도구(Syzkaller + LLM 리포터, Claude Mythos Preview 등)가 커널 메일링 리스트에 패치를 쏟아내기 시작했다. 일부는 실제로 유효했지만, 몇 건에서 "표면 증상만 덮는" 수정이 발견됐다. 대표 사례로 지난달 제출된 ext4 lock 관련 패치가 얘기된다. 리뷰어가 "이 수정이 왜 안전한가"를 물었을 때 제출자가 답변하지 못한 사건이다.
Greg KH의 확장 코멘트
safety maintainer인 Greg Kroah-Hartman도 같은 세션에서 동의했다. "우리는 지난 20년간 '패치를 낸 사람이 책임진다'는 원칙으로 커널을 운영해 왔다. AI가 쓴 패치의 책임은 누가 지는가. 그 질문에 '제 이름으로 제가 책임집니다'라고 말할 수 있어야 한다."
반대 의견도 만만치 않다
- 찬성파: "엔지니어의 판단이 끝에 남는 한 도구는 도구다. AI를 금지하는 게 아니라 검증 없는 제출을 금지하는 것이 합리적."
- 반대파: "이미 많은 기여자가 코드 생성에 AI를 쓴다. 출처를 숨기는 쪽이 오히려 더 나쁠 것이다. 규칙은 투명성이어야 한다."
- 중립파: "AI 생성 코드는 DCO(Developer Certificate of Origin) 차원에서 별도 태그가 필요하다."
실질적 변화 예고
리누스는 구체적 규칙을 제시하지는 않았지만, 관계자 인터뷰에 따르면 다음 rc 사이클부터 메일링 리스트 가이드라인 업데이트가 검토된다.
- 자동 생성 도구를 사용한 경우 커밋 메시지에 명시
- AI가 작성한 부분의 근거를 제출자가 설명할 의무
- 일부 하위 시스템(메모리 관리·스케줄러)은 더 엄격한 리뷰 적용
다른 오픈소스 프로젝트는 어떤가
- Rust: AI 도구 사용을 허용하되 PR 본문에 표기 권고
- Python: 공식 입장 없음. 개별 메인테이너 재량
- Kubernetes: SIG 회의에서 "AI 제안 PR은 자동 라벨 부착" 실험 중
개발자에게 남기는 교훈
리누스의 메시지는 "AI를 쓰지 마라"가 아니다. "네가 모르는 코드에 네 이름을 걸지 마라"에 가깝다. 이는 AI 시대에도 엔지니어링의 핵심 원칙이 바뀌지 않는다는 선언으로 받아들여진다.
자주 묻는 질문
커널에 AI 생성 코드가 아예 들어간 적이 없나?
이미 들어갔을 가능성이 높다. 단지 출처가 표기되지 않았을 뿐. 토르발스의 발언은 "출처 불명 + 제출자도 이해 못 하는" 이중 요건이 문제라는 것.
기업 개발자는 어떻게 대응해야 하나?
업스트림 기여 시 AI 생성 코드의 검증 로그를 남기는 문화가 필요하다. 내부 리뷰에서 "이 수정이 왜 안전한가"를 문서화하지 못하면 외부에 내보내지 않는다는 규칙이 점점 표준이 될 것이다.
리누스가 과한가?
메인라인 안정성은 전 세계 수십억 장치의 문제다. 보수적인 게 오히려 시스템의 건강이라는 의견이 중론이다.
댓글 0