Linux 커널 기여 시 AI 코딩 어시스턴트 사용 공식 가이드라인

Who Should Read

Linux 커널에 패치를 제출하거나 오픈소스 프로젝트에 AI 도구를 활용해 기여하는 개발자. 또한 자신의 오픈소스 프로젝트에 AI 사용 정책을 도입하려는 메인테이너.

Core Mechanics

• Linux 커널 공식 문서(Documentation/process/coding-assistants.rst)에 AI 코딩 어시스턴트 사용 가이드라인이 정식으로 추가됐다. AI 도구 사용 자체는 허용하되, 기존 커널 개발 프로세스(코딩 스타일, 패치 제출 규칙 등)를 그대로 따라야 한다.
• AI가 생성한 코드라도 GPL-2.0-only와 호환되어야 하고, SPDX 라이선스 식별자를 올바르게 달아야 한다. 라이선스 준수 여부 확인 책임은 AI가 아니라 사람 기여자에게 있다.
• AI 에이전트는 절대로 'Signed-off-by' 태그를 추가할 수 없다. DCO(Developer Certificate of Origin, 개발자가 코드의 출처와 라이선스를 보증하는 서명)는 사람만 법적으로 인증할 수 있기 때문이다.
• 사람 기여자는 AI가 생성한 모든 코드를 직접 검토하고, 라이선스 요건을 확인하고, 자신의 Signed-off-by 태그를 달아서 기여에 대한 전적인 책임을 져야 한다.
• AI 도구를 사용해 기여할 때는 'Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]' 형식의 태그를 커밋 메시지에 추가해야 한다. 예를 들면 'Assisted-by: Claude:claude-3-opus coccinelle sparse' 같은 식이다.
• AGENT_NAME은 사용한 AI 도구나 프레임워크 이름, MODEL_VERSION은 구체적인 모델 버전, 그리고 coccinelle(C 코드 패턴 매칭 도구), sparse(커널 정적 분석 도구), smatch, clang-tidy 같은 특수 분석 도구는 선택적으로 명시할 수 있다. git, gcc, make 같은 기본 개발 도구는 적지 않는다.
• 이 가이드라인의 취지는 AI가 개발 과정에서 어떤 역할을 했는지 추적하기 위한 적절한 귀속(attribution) 체계를 만드는 것이다. 시간이 지남에 따라 커널 개발에서 AI의 역할이 어떻게 변화하는지 파악할 수 있게 된다.

Evidence

• 대부분의 댓글은 이 정책이 상식적이고 합리적이라는 반응이었다. '사람이 책임진다, 라이선스를 지켜라'는 원칙이 특별히 새롭지 않고 오히려 당연한 방향이라는 의견이 많았다. 다만 이렇게 명확하게 문서화된 정책을 다른 유명 오픈소스 저장소에서는 본 적이 없다는 점을 신기하게 여기는 반응도 있었다.
• 라이선스 준수 가능성에 대한 회의적인 시각도 있었다. LLM은 인터넷의 수많은 다양한 라이선스 코드로 훈련됐고 심지어 저작권자 동의 없이 수집된 코드도 포함돼 있는데, 기여자가 AI 생성 코드의 GPL 호환성을 어떻게 보장할 수 있냐는 지적이었다. 실제로 LLM이 훈련 데이터를 높은 충실도로 '재생성(regurgitate)'할 수 있다는 점에서, 기여자가 GPL 준수를 보증하는 것이 사실상 불가능한 요구라는 비판도 있었다.
• 코드 리뷰 부담 증가에 대한 우려도 나왔다. AI 도구 덕분에 누구나 대용량 패치를 쉽게 만들 수 있게 되면서 메인테이너들이 리뷰해야 할 코드 양이 폭발적으로 늘어날 수 있다는 걱정이다. 리뷰어들이 물량에 압도되면 결국 AI 생성 코드를 충분한 검토 없이 '믿고' 머지하게 될 거라는 악순환 시나리오가 언급됐다.
• AI가 가장 자신 있게 틀리는 부분이 바로 커널에서 가장 중요한 영역이라는 지적이 있었다. 레이스 컨디션, 락킹(locking), 메모리 라이프타임 같은 문제들은 모델이 표면적으로는 깔끔해 보이는 코드를 생성하지만 실제 부하 상황에서 몇 주 뒤에 데드락이 발생하는 식의 버그를 만든다는 실제 경험담도 공유됐다. 그래서 기여자 정책보다는 Greg KH가 도입한 Sashiko처럼 메인테이너 쪽에서 AI로 패치를 필터링하는 접근이 더 효과적일 수 있다는 의견도 있었다.
• 'Assisted-by' 태그를 AI 도구 표기에 사용하는 것이 어색하다는 의견도 있었다. 기존에 이 태그는 다른 사람이 커밋에 도움을 줬을 때 쓰는 용도였는데, 이제 AI 도구 표기라는 전혀 다른 용도로도 쓰이게 돼 의미가 혼용된다는 지적이다. 'AI-assistant:' 같은 별도 태그를 만드는 게 더 나았을 거라는 댓글도 있었다.

How to Apply

• Linux 커널에 AI 도구(Claude, Copilot 등)를 활용해 패치를 작성할 경우, 커밋 메시지에 'Assisted-by: Claude:claude-3-7-sonnet' 같은 태그를 반드시 추가하고, 코드 내용을 직접 검토한 뒤 자신의 Signed-off-by 태그를 달아야 한다. AI가 자동으로 Signed-off-by를 추가하도록 설정했다면 해당 기능을 비활성화해야 한다.
• AI가 생성한 커널 코드를 제출하기 전에 coccinelle(패턴 기반 C 코드 분석), sparse(커널 전용 정적 분석), smatch 같은 커널 전용 정적 분석 도구를 돌려서 검증하면 좋다. 이런 도구를 사용했다면 'Assisted-by: Claude:claude-3-7-sonnet coccinelle sparse' 처럼 태그에 함께 명시할 수 있다.
• 자신의 오픈소스 프로젝트에 AI 사용 정책을 도입하려는 메인테이너라면, 이 Linux 커널 문서(coding-assistants.rst)를 템플릿으로 참고해서 '사람이 책임진다 + AI 사용 명시 태그' 구조를 그대로 가져다 쓸 수 있다. 형식도 단순하고 법적 책임 소재도 명확해서 다른 프로젝트에 바로 적용하기 좋은 모델이다.
• AI가 생성한 코드를 한 번에 제출하지 말고, 같은 모델로 여러 차례 리뷰 이터레이션을 돌리는 것이 버그 발견에 도움이 된다는 실사용 경험이 댓글에 공유됐다. 특히 레이스 컨디션이나 락킹 같은 동시성 버그는 코드가 컴파일되고 리뷰에서 깔끔해 보여도 실제 부하에서 터지는 경우가 있으니, AI 생성 코드일수록 직접 스트레스 테스트를 돌려보는 것이 좋다.

Code Example

# 커밋 메시지에 AI 사용 명시 예시
git commit -m "drivers/net: fix memory leak in foo_driver

Fixed a memory leak in the error path of foo_probe() where
the allocated buffer was not freed on failure.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Name <your@email.com>"

Terminology

Related Resources

• Linux 커널 공식 AI 코딩 어시스턴트 가이드라인 문서
• Linus Torvalds 인터뷰 - AI 관련 내용 언급 부분
• Linux 커널 패치 제출 가이드 (Signed-off-by, DCO 설명 포함)