9개월 동안 리눅스 커널은 AI 도움을 받은 패치에 Assisted-by: 태그를 붙이라고 요구했습니다. 2026년 10월, 메인테이너들은 그 요구를 걷어내기로 했습니다. 이유는 "AI가 나쁘다"도 "AI가 좋다"도 아닙니다. 그 태그가 실제로 아무것도 알려주지 않았기 때문입니다. 이 결정은 AI 사용을 표기하게 만드는 정책이 왜 잘 작동하지 않는지, 그리고 그러면 무엇이 남는지를 보여줍니다.

정책이 오간 시간

정책의 시작은 2025년 메인테이너 서밋의 합의였습니다. 이후 2025년 12월 23일 제출돼 2026년 1월 Jonathan Corbet이 승인한 패치로 문서화됐고, Documentation/process/coding-assistants.rst로 리눅스 7.0에 들어갔습니다. 내용은 "패치 작성에 어떤 종류의 고급 코딩 도구든 사용했다면 커밋 메시지에 Assisted-by 태그로 밝히라"였습니다.

그런데 2026년 7월, 태그를 없애자는 첫 제안이 실패했습니다. 당시에는 Greg Kroah-Hartman도 태그를 유지하는 쪽을 지지했습니다. 분위기가 바뀐 것은 10월입니다.

[정책 타임라인]

2025-07       AI 표기 제안 구체화
2025-12-23    관련 패치 제출 (Jonathan Corbet 승인)
2026-01       coding-assistants.rst 문서화, 리눅스 7.0에 포함
2026-07       태그 제거 첫 제안 → 실패 (Kroah-Hartman도 유지 지지)
2026-10-08    프라하 메인테이너 서밋, 태그 폐기에 합의
2026-10-09    Sasha Levin, 문서 요구를 제거하는 패치 제출
2026-10-13    수정 패치(3가지 이유) + 토르발스의 공개 반박
2026-10-14~16 Corbet이 docs-next에 병합 / 언론 보도 확산

표기가 왜 무의미해졌나

핵심 근거는 숫자입니다. 리눅스 7.3의 -rc7까지 병합 커밋을 제외한 변경셋은 18,533개로 역대 최다였는데, 그중 Assisted-by 태그가 붙은 것은 1,884개, 약 10%였습니다. 실제 AI 사용은 이보다 훨씬 많을 것으로 보입니다. 태그를 안 다는 이유는 다양합니다. 규칙을 모르는 사람도 있고, 일부러 숨기는 사람도 있으며, 태그를 요구하는 메인테이너는 거의 없습니다.

Red Hat의 Jeff Layton은 태그를 걷어내야 할 이유를 세 가지로 정리했습니다.

[태그를 걷어내는 이유 (Jeff Layton)]

1. 모두가 규칙을 지키지 않는다
   → 태그가 없어도 AI를 썼을 수 있고, 있어도 신뢰의 근거가 못 된다

2. 독점 LLM 회사의 무료 광고가 된다
   → 커밋 메시지에 도구·회사 이름이 쌓이는 효과

3. 이 정보를 왜 수집하는지 자체가 불분명하다
   → 수집해도 유지보수 판단에 쓰이지 않는다

태그를 낸 장본인 Sasha Levin의 요약도 비슷합니다. 태그가 없으면 패치가 어떻게 만들어졌는지 알 수 없고, AI를 거의 모든 작업에 쓰는 사람에게는 태그가 있어도 정보가 되지 않습니다. 결국 "투명성"을 위해 만든 장치가, 정작 투명성을 주지 못했습니다.

토르발스의 반박: 도구를 금지하는 규칙은 어리석다

논쟁이 뜨거워진 지점은 Laurent Pinchart의 반대였습니다. 그는 10월 13일 "다른 필수 표기 메커니즘 없이 태그를 없애는 건 달갑지 않다. 그러면 제출자들이 질문에 반발할 것"이라고 썼고, "강제할 수 없다"는 논리에 반대했습니다. 기대치를 정하는 규칙이라는 것입니다.

Linus Torvalds의 답은 강했습니다. 요지는 이렇습니다.

[토르발스의 논지 (요약)]

- "AI를 쓰지 마라" 같은 규칙을 만드는 발상 자체가 우스꽝스럽다
- 같은 논리라면 "커널 제출에 컴파일러를 쓰지 마라"도 성립한다
  → 어셈블러로 직접 쓰지 않으면 코드를 이해 못 한다는 뜻이 되니까
- 중요한 것은 어떤 도구를 썼는가가 아니라, 그 코드를 이해하는가다
- 따라서 "도구를 쓰지 마라"는 식의 규칙은 만들지 않는다

이 발언은 그와 Dirk Hohndel의 공개 대화(10월 9일, 프라그 오픈소스 서밋 유럽)와도 이어집니다. Torvalds는 한때 AI를 "그다지 좋지 않다"고 봤지만 입장이 바뀌었다고 말했습니다. AI가 커널의 실제 보안 결함을 찾고, 20년 동안 아무도 손대지 않던 드라이버의 결함도 찾아낸다고 합니다. 요약하면 AI는 "코드베이스를 개선하고 있다"입니다. 동시에 그는 비용도 인정했습니다. AI가 메인테이너들을 "문제가 될 정도로 스트레스 받게 만든다"는 것입니다. 서밋에서 발표의 약 4분의 3이 AI 도구를 덜 부담스럽게 만드는 방법에 관한 것이었다고 전합니다. 메일링 리스트에 리뷰를 올리는 에이전트형 리뷰 시스템 'Sashiko'도 그 예입니다.

표기가 사라진 뒤에도 남는 것

핵심은 "표기를 없앤다 = 검증을 포기한다"가 아니라는 점입니다.

[무엇이 바뀌고, 무엇이 그대로인가]

바뀌는 것
- 커밋 메시지의 Assisted-by 태그 요구 제거
- checkpatch.pl의 해당 처리 제거
- 어떻게 만들었는지는 커버 레터(패치와 함께 보내는 이메일)에 서술

그대로인 것
- 투명성에 대한 요구 자체는 남는다 (다만 위치가 커밋에서 커버 레터로)
- 책임은 제출자에게 그대로 있다
- AI 에이전트는 Signed-off-by 라인을 추가해서는 안 된다

패치는 문서 브랜치(docs-next)에 병합됐고, 메인라인 반영을 남겨 두고 있습니다. Torvalds와 Kroah-Hartman이 지지하는 만큼 통과 가능성이 높다고 보도됐지만, 아직 완료된 변경은 아닙니다. 한 가지 짚을 점은, 이 결정이 특정 배포판이나 도구를 금지하는 것이 아니라 표기 규칙을 정리하는 것이라는 사실입니다.

개발자에게 남는 교훈

이 논쟁은 "AI를 썼다고 표기해야 하나"라는 질문을, 더 쓸모 있는 질문으로 바꿉니다. "이 변경을 이해하고 검증했다는 걸 무엇으로 증명하나"입니다.

[AI 생성 PR에 남겨야 할 증거]

- [ ] 변경 이유: 무엇이 문제였고 왜 이 방식인가
- [ ] 테스트 근거: 어떤 테스트를 돌렸고 결과가 무엇인가
- [ ] 실패 조건: 어떤 입력·환경에서 이 변경이 깨지는가
- [ ] 검토 범위: 이해하지 못한 부분이 남아 있다면 어디인가
- [ ] 서명 책임: Signed-off-by는 사람이, 이해한 사람이 붙인다

표기 태그는 사라질 수 있습니다. 하지만 리뷰어가 코드를 승인하거나 거부하는 기준, 그리고 제출자의 책임은 사라지지 않습니다. 태그가 사라졌다고 해서 "AI가 썼다"는 사실이 코드 품질의 근거가 되지도, 면책이 되지도 않습니다.

결론: 형상관리 도구로는 이해를 강제할 수 없다

커널의 결정은 냉정합니다. 태그는 아무도 지키지 않았고, 지킨 경우에도 정보를 주지 않았습니다. 그래서 걷어냅니다. 대신 남는 것은 원래부터 있던 기준입니다. 코드를 이해하는가, 검증했는가, 책임을 질 수 있는가. 규칙은 도구가 아니라 사람을 향합니다.

그래서 지금 필요한 역량은 AI가 코드를 얼마나 잘 짜는지가 아니라, 그 코드를 설계하고 리뷰하고 디버깅하는 능력입니다. AI가 만든 PR에도 왜 이 변경이 필요한지, 어떤 테스트로 확인했는지, 어디서 실패하는지를 남기는 습관이 곧 신뢰가 됩니다. 이 흐름은 Claude Code 팀의 코드 리뷰 6계층과 조직 단위 코드 리뷰와 Copilot 과금 구조에서 더 깊게 다뤘고, 커밋·브랜치·이력 관리의 기본기는 Git 실무에서 배우는 형상관리에서 확인할 수 있습니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

표기를 걷어내도 책임은 커밋과 리뷰에 남습니다. 브랜치 보호, 커밋 메시지, 이력 관리, 되돌리기를 손으로 다뤄 보면 왜 "누가 무엇을 바꿨는가"를 기록하는 일이 여전히 중요한지 감이 옵니다.