Linux 커널 기여 시 AI 코딩 어시스턴트 사용 공식 가이드라인
AI assistance when contributing to the Linux kernel
TL;DR Highlight
Linux 커널 공식 문서가 AI 코딩 도구 사용 정책을 추가하여 AI 생성 코드의 법적 책임을 전적으로 사람에게 귀속시키고 'Assisted-by' 태그 명시를 의무화했다.
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
관련 논문
LLM이 TLA+로 실제 시스템을 제대로 모델링할 수 있을까? — SysMoBench 벤치마크
LLM이 TLA+ 명세를 작성할 때 문법은 잘 통과하지만 실제 시스템과의 동작 일치도(conformance)는 46% 수준에 그친다는 걸 체계적으로 검증한 벤치마크 연구로, AI 기반 형식 검증의 현실적 한계를 보여준다.
Natural Language Autoencoders: Claude의 내부 활성화를 자연어 텍스트로 변환하는 기법
Anthropic이 LLM 내부의 숫자 벡터(활성화값)를 직접 읽을 수 있는 자연어로 변환하는 NLA 기법을 공개했다. AI가 실제로 무슨 생각을 하는지 해석하는 interpretability 연구의 새로운 진전이다.
ProgramBench: LLM이 프로그램을 처음부터 다시 만들 수 있을까?
LLM이 FFmpeg, SQLite, PHP 인터프리터 같은 실제 소프트웨어를 문서만 보고 처음부터 재구현할 수 있는지 측정하는 새 벤치마크로, 최고 모델도 전체 태스크의 3%만 95% 이상 통과하는 수준에 그쳤다.
MOSAIC-Bench:코딩 에이전트의 Compositional Vulnerability 유도 측정
티켓 3장으로 쪼개면 Claude/GPT도 보안 취약점 코드를 53~86% 확률로 그냥 짜준다.
LLM의 거절(Refusal) 동작은 단 하나의 방향(Direction)으로 제어된다
13개의 오픈소스 채팅 모델을 분석했더니, 모델이 유해한 요청을 거절하는 동작이 내부 활성화 공간에서 단 하나의 1차원 벡터 방향으로 인코딩되어 있었다. 이 방향을 제거하면 안전 파인튜닝이 사실상 무력화되므로, 현재 안전 학습 방식이 얼마나 취약한지 보여준다.
LLM의 구조화된 출력(Structured Output)을 테스트하는 새 벤치마크 SOB 공개
스키마 준수 여부만 보던 기존 벤치마크의 한계를 넘어, 실제 값의 정확도까지 7가지 지표로 평가하는 Structured Output Benchmark(SOB)가 공개됐다. 인보이스 파싱, 의료 기록 추출처럼 JSON 출력의 정확성이 중요한 프로덕션 시스템에서 어떤 모델을 써야 할지 판단하는 데 직접적으로 참고할 수 있다.