🔥 리눅스 커널, AI 코드를 공식 허용하다 — 대신 책임은 전부 사람 몫이다

#linux#ai#open-source#kernel#developer

884자

12분

강의 목차

무슨 일이 있었나
이게 왜 중요한가
여기까지 오는 길이 순탄하지 않았다
결국 투명성이 답이었다
참고 자료

content image
출처: Linux Kernel GitHub Repository

솔직히 이 뉴스를 보는 순간 "드디어"라는 말이 먼저 나왔다. 리눅스 커널이 AI 생성 코드에 대한 공식 정책을 내놓았다. 금지가 아니라 허용이다. 단, 조건이 붙는다. 꽤 날카로운 조건이.

무슨 일이 있었나

리눅스 커널 프로젝트가 coding-assistants.rst라는 공식 문서를 커널 소스 트리에 병합했다. 문서 관리자 Jonathan Corbet이 머지한 이 문서는 AI 보조 도구를 사용한 코드 기여를 공식 허용하면서 동시에 엄격한 공개 규칙을 요구한다.

핵심은 세 가지다.

첫째, AI는 Signed-off-by를 쓸 수 없다. Signed-off-by는 개발자가 Developer Certificate of Origin(DCO)에 따라 "이 코드를 제출할 법적 권리가 있다"고 인증하는 태그다. 법적 구속력이 있다. AI에게 이걸 맡길 수는 없는 노릇이다.

둘째, Assisted-by 태그가 필수다. AI 도구의 도움을 받았으면 커밋 메시지에 Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] 형식으로 밝혀야 한다. 투명성 확보가 목적이다.

셋째, 모든 책임은 인간에게 있다. AI가 만든 코드든 뭐든, 제출 버튼을 누른 사람이 버그와 보안 결함 전부에 대해 책임진다. 예외는 없다.

Linus Torvalds는 이 정책의 철학적 뼈대를 자기 특유의 직설적인 방식으로 요약했다. AI 도구 사용 자체를 금지하자는 논쟁에 대해 "쓸데없는 포즈"라고 잘라 말했다. 가비지 코드를 올리는 나쁜 놈들은 어차피 문서를 안 읽는다. 소프트웨어를 단속할 게 아니라 사람을 단속해야 한다는 거다.

이게 왜 중요한가

리눅스 커널은 오픈소스 세계의 기준점이다. 커널이 어떤 결정을 내리면 수천 개의 다른 프로젝트가 그 방향을 참고한다. 이번 정책이 중요한 이유는 단순히 "AI 코드 OK" 선언이 아니라, 투명성과 책임이라는 프레임워크를 제시했기 때문이다.

지금까지 오픈소스 생태계는 AI 코드 문제를 두고 양극단을 오갔다. 한쪽은 전면 금지, 다른 쪽은 무분별한 사용. 리눅스 커널의 정책은 그 가운데 실용적인 지점을 찍었다.

DCO 문제도 이걸로 정리된다. Red Hat의 분석에 따르면 DCO의 핵심은 모든 코드 라인이 개인의 창작물이어야 한다는 게 아니다. 기여자가 해당 코드를 해당 라이선스 하에서 사용할 권리가 있다고 합리적으로 확인했는가, 그 책임의 문제다. AI 보조 코드도 충분한 공개와 인간의 주의 깊은 검토가 뒷받침되면 DCO의 정신과 양립할 수 있다는 것이 Red Hat의 입장이다.

여기까지 오는 길이 순탄하지 않았다

이 정책이 갑자기 뚝 떨어진 게 아니다. 오픈소스 커뮤니티는 지난 2년간 AI 코드 문제로 격렬하게 싸웠다.

전면 금지파가 먼저 움직였다. 2024년 4월, Gentoo Linux가 FOSS OS 프로젝트 중 최초로 AI 생성 코드를 전면 금지했다. "자연어 처리 AI 도구의 도움을 받아 만든 콘텐츠를 Gentoo에 기여하는 것은 명시적으로 금지된다." 한 달 뒤 NetBSD도 뒤를 따랐다. NetBSD는 LLM 출력물을 저작권과 라이선스 상태가 불확실한 "오염된(tainted)" 코드로 분류했다. BSD 라이선스 코드베이스에 GPL 코드가 실수로 섞여 들어오면 전체 라이선스를 바꾸거나 코드를 교체해야 하니까, NetBSD 입장에서는 합리적인 공포다.

AI slop이 밀려왔다. cURL의 Daniel Stenberg는 2024년 초부터 AI 생성 버그 리포트의 품질 저하를 호소했다. 실제 함수 시그니처와 일치하지 않는 코드 스니펫, 존재하지 않는 변경 로그, 컴파일조차 안 되는 예제. 2025년 말에는 버그 리포트의 정확도가 20~30건 중 1건 수준으로 떨어졌다. 결국 2026년 1월 31일, cURL은 HackerOne 버그 바운티 프로그램을 폐지했다. Stenberg는 "쓰레기를 제출할 인센티브를 없앤다"고 밝혔다.

화이트보드 도구 tldraw는 아예 외부 PR을 자동으로 닫아버리는 조치를 취했다. CEO Steve Ruiz는 외부 기여자들이 AI로만 만든 코드를 PR에 포함시키면서 "코드베이스에 대한 이해 부족"과 "후속 대응 부재"가 반복된다고 지적했다. OCaml 커뮤니티에서는 약 13,000줄짜리 AI 생성 PR이 등장해 메인테이너 사이에서 존재론적 논쟁을 촉발했다.

커널 내부에서도 사건이 터졌다. NVIDIA 엔지니어이자 커널 메인테이너인 Sasha Levin이 커널 6.15에 LLM이 전적으로 작성한 패치를 제출했다. 변경 로그까지 AI가 썼고, Levin은 이를 공개하지 않았다. 코드 자체는 작동했지만 성능 퇴행이 있었고, 리뷰와 테스트를 거쳤음에도 AI 생성이라는 사실이 숨겨져 있어서 제대로 검토되지 못했다. Torvalds 본인도 이 패치가 제대로 리뷰되지 않은 점을 인정했다.

게임 쪽에서도 비슷한 일이 있었다. 20년 넘은 Doom 소스 포트 GZDoom의 수석 개발자 Christoph "Graf Zahl" Oelckers가 비공개로 AI 생성 패치를 커밋했다. 커뮤니티가 투명성 문제를 지적하자 그는 "포크하고 싶으면 해라"고 대응했다. 커뮤니티는 진짜로 포크했다. 기여자 대다수가 UZDoom이라는 새 소스 포트로 옮겨갔고, GZDoom은 "역사적(Historical)" 상태로 격하됐다.

결국 투명성이 답이었다

이 사건들을 쭉 보면 패턴이 보인다. 개발자 커뮤니티가 진짜로 화가 난 건 AI 사용 자체가 아니다. 숨긴 것에 화가 난 거다. Sasha Levin 사건도, GZDoom 사건도, 코드 품질 이전에 신뢰의 문제였다.

리눅스 커널의 정책은 이 지점을 정확히 짚었다. Assisted-by 태그로 투명성을 강제하고 인간 책임을 법적으로 못 박았다. Torvalds의 비유가 맞다. AI를 금지하는 건 특정 브랜드의 키보드를 금지하는 것만큼 무의미하다. 중요한 건 키보드가 아니라, 그 키보드로 무엇을 치고 누가 엔터를 눌렀느냐다.

나는 이 접근이 현실적으로 가장 합리적이라고 생각한다. AI 도구의 사용은 이미 막을 수 없다. 실제로 NVIDIA는 내부적으로 30,000명 이상의 엔지니어가 Cursor의 특화 버전을 쓰고 있다고 밝힌 바 있다. 코드 생산량이 3배로 늘었다고 한다. 금지로 막을 수 있는 흐름이 아니다.

다만 한 가지 걱정은 남는다. Assisted-by 태그를 실제로 쓸지는 결국 개발자의 양심에 달려 있다. Torvalds 말대로 나쁜 놈들은 문서를 안 읽는다. 이 정책이 성실한 개발자에게는 명확한 가이드라인이 되겠지만, 의도적으로 AI 사용을 숨기려는 사람까지 잡아내지는 못한다. 결국 코드 리뷰의 품질이 마지막 방어선이 되는 셈이다.

그래도 방향은 맞다고 본다. 금지 정책은 처벌은 쉽지만 현실을 반영하지 못하고 무제한 허용은 현실적이지만 혼란을 부른다. "써도 된다, 대신 밝혀라, 그리고 네가 책임져라." 이게 2026년 오픈소스 생태계가 찾은, 아마도 유일하게 작동 가능한 답인 것 같다.