Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 7월 29일, 15줄이라는 선
정책이 실제로 요구하는 것 — 그리고 금지하지 않는 것
왜 하필 15줄인가 — 저작권 양도, DCO, 그리고 두 갈래 리스크
다른 프로젝트들은 어디에 선을 그었나
기여자에게 실제로 달라지는 것
이 논쟁의 양쪽
마치며 — 이 정책은 코드 품질이 아니라 출처 이력에 관한 것입니다
참고 자료

들어가며 — 7월 29일, 15줄이라는 선

2026년 7월 29일, David Edelsohn이 GCC 메일링 리스트에 AI 정책 발표를 올렸습니다. 운영위원회가 Jonathan Wakely가 이끈 AI 정책 작업 그룹의 권고안을 그대로 받아들였다는 내용입니다. 작업 그룹에는 Carlos O'Donell, Sudakshina Das, Jason Merrill, Joel Sherrill, Sam James, Robin Dapp, Arthur Cohen이 참여했습니다.

정책 본문은 gcc.gnu.org/ai-policy.html에 있고, 한 문장으로 줄이면 이렇습니다 — 법적으로 유의미한 기여에 LLM 생성 콘텐츠가 포함되거나 그로부터 파생된 경우 받지 않습니다. 그리고 "법적으로 유의미한"의 기준은 GNU 유지보수자 지침을 따라 약 15줄입니다.

헤드라인은 대체로 "GCC가 AI 코드를 금지했다"로 나왔지만, 정책 본문을 읽으면 그림이 훨씬 세밀합니다. 금지되지 않은 것이 꽤 많고, 새로 요구되는 것도 있으며, 예외가 하나 있는데 그 예외가 하필 테스트 케이스입니다. 이 글은 정책이 실제로 무엇을 요구하는지, 그 배경에 있는 법적 구조가 무엇인지, 다른 주요 프로젝트들은 어디에 선을 그었는지, 그리고 기여자 입장에서 실제로 달라지는 것이 무엇인지를 봅니다. 어느 편이 옳은지는 판정하지 않겠습니다. 양쪽 논거가 모두 실체가 있고, 실제로 갈리는 지점이 어디인지를 아는 것이 더 쓸모 있기 때문입니다.

정책이 실제로 요구하는 것 — 그리고 금지하지 않는 것

정책을 항목으로 펼치면 넷입니다.

금지되는 것. 법적으로 유의미한 기여 중 LLM이 만든 내용을 포함하거나 그로부터 파생된 것. 여기서 "파생"이라는 단어가 넓게 쓰였다는 점이 중요합니다. 모델이 쓴 코드를 사람이 손본 결과도 파생에 해당합니다.

허용되는 것. 법적으로 유의미하지 않은 기여, 즉 대략 15줄 미만은 LLM이 생성했더라도 명확히 표시하고 다른 통상 요건을 만족하면 받을 수 있습니다.

예외. 유지보수자는 법적으로 유의미한 테스트 케이스에 대해서는 LLM이 전부 또는 일부 생성한 것이라도 받을 수 있습니다. 이 예외의 설계 의도는 분명합니다 — 테스트 케이스는 컴파일러가 판정해 주는 산출물이라 사람 리뷰 부담이 낮고, 저작권 관점에서도 대개 표현의 폭이 좁습니다. 앞서 본 대규모 마이그레이션 사례들이 테스트 스위트를 기계 심판으로 쓴 것과 같은 논리가 여기에도 적용됩니다.

새로 생기는 의무. AI의 도움을 받은 작업에는 커밋 메시지에 Assisted-by: 트레일러를 붙여야 합니다. 그리고 사람이 변경 내용을 이해하고, 질문에 답할 수 있어야 하며, 포함 여부를 승인해야 합니다. DCO 서명은 오직 사람만 할 수 있습니다.

여기서 자주 오해되는 대목을 분명히 해 둘 필요가 있습니다. 정책은 개인이 LLM을 쓰는 것 자체를 막지 않습니다. 접근성 도구, 연구, 분석, 버그 발견과 신고, 패치 리뷰에 쓰는 것은 명시적으로 허용됩니다. 조건은 하나 — 그 출력이 프로젝트에 그대로 제출되지 않으면 됩니다. 즉 이 정책이 통제하려는 것은 개발자의 작업 방식이 아니라 저장소에 들어가는 바이트의 출처입니다.

마지막으로 정책 자체가 잠정적입니다. 본문은 이 정책이 커뮤니티나 GNU 프로젝트 전체 입장에 따라 바뀔 것으로 예상하며 늦어도 2027년 초에 재검토하겠다고 적어 두었습니다. 그리고 태도에 관한 문장이 하나 붙어 있는데, LLM에 대한 입장과 무관하게 기여자를 존중해서 대하고 거절보다 준수 쪽으로 안내하라는 것입니다. 정책 문서에 이런 문장이 들어간 것은 이 논쟁이 커뮤니티 내부에서 얼마나 날카로웠는지를 보여 줍니다.

왜 하필 15줄인가 — 저작권 양도, DCO, 그리고 두 갈래 리스크

15줄이라는 숫자는 새로 만든 것이 아니라 GNU 프로젝트가 오래 써 온 저작권 귀속 기준선입니다. 그 아래는 저작권으로 보호될 만한 창작적 표현으로 보기 어렵다는 실무적 관행입니다. AI 정책이 이 선을 그대로 재사용했다는 사실 자체가 이 정책의 성격을 말해 줍니다 — 이것은 품질 정책이 아니라 저작권 정책입니다.

배경을 알면 왜 GCC가 유독 보수적인지 이해가 됩니다. GCC 기여 안내에 따르면 FSF는 큰 기여에 대해 여전히 저작권 양도를 선호하고, 그 대안으로 커밋에 Signed-off-by: 태그를 붙이는 DCO 방식을 받습니다. 저작권 양도가 존재하는 이유는 하나입니다 — GPL 위반 소송에서 원고 자격을 한곳에 모아 라이선스를 실제로 집행할 수 있게 하는 것입니다. 카피레프트는 저작권 위에 얹힌 계약이므로, 저작권이 흔들리면 GPL도 같이 흔들립니다.

여기서 LLM 출력이 만드는 문제가 두 갈래로 갈립니다. 어느 쪽으로 가도 카피레프트 프로젝트에는 불리합니다.

첫 번째 갈래 — 저작권이 없다면. 인간 저작자성이 없는 순수 기계 생성물에 저작권이 인정되지 않는다면, 그 코드에는 GPL이 부과하는 조건이 붙을 근거가 약해집니다. 재배포자에게 소스 공개를 요구할 지렛대가 사라진다는 뜻입니다. (미국 저작권청이 인간 저작자성을 요구해 왔다는 것은 널리 알려진 배경이지만, 이 글에서 1차 자료를 직접 확인하지는 않았습니다.)

두 번째 갈래 — 저작권이 있다면. 그 저작권이 누구 것인지가 문제가 됩니다. 학습 데이터에 있던 GPL 코드나 독점 코드의 파생물일 가능성을 배제할 방법이 현재로서는 없고, 기여자는 DCO가 요구하는 "이 코드를 기여할 권리가 있음"을 정직하게 선언할 수 없게 됩니다. Gentoo가 정책 본문에서 든 첫 번째 이유가 정확히 이것입니다 — 그런 자료를 쓰면 저작권을 침해할 위험이 있을 뿐 아니라 Gentoo 자신의 카피레프트 보호를 약화시킬 수 있다는 것입니다.

정리하면 GCC의 선은 "AI 코드가 나쁘다"는 판단이 아니라 "출처 이력이 끊긴 코드를 GPL 저장소에 넣을 수 없다"는 판단입니다. 그래서 15줄이고, 그래서 테스트 케이스는 예외이고, 그래서 개인 사용은 자유입니다.

다른 프로젝트들은 어디에 선을 그었나

같은 문제를 두고 주요 프로젝트들이 서로 다른 답을 냈습니다. 확인된 것만 정리합니다.

프로젝트	입장	시점·근거
GCC	법적으로 유의미한 기여는 거절. 테스트 케이스 예외, Assisted-by 필수, 2027년 초 재검토	2026-07-29 운영위 승인
리눅스 커널	허용하되 공개 의무. Assisted-by 트레일러 형식 지정, Signed-off-by는 사람만	Documentation/process/coding-assistants.rst, 2026년 4월 초 병합, 59줄
Debian	결정 진행 중. 전면 금지부터 조건부 허용까지 다섯 안이 총선거에 부쳐짐	논의 기간 2026-07-24 개시, 이 글 시점 결과 없음
Gentoo	자연어 AI 도구로 만든 콘텐츠 기여 전면 금지	2024-04-14 평의회 표결
NetBSD	LLM 생성 코드는 "오염된" 것으로 간주, 코어 팀의 사전 서면 승인 없이 커밋 금지	커밋 지침
QEMU	AI 생성 콘텐츠가 포함됐다고 판단되는 기여는 거절	code-provenance 문서
curl	공개를 조건으로 허용. 리뷰 시간을 정당화하지 못하는 대량 AI PR은 거절	기여 가이드

리눅스 커널과 GCC의 대비가 이 지형을 가장 잘 보여 줍니다. 커널은 공식 문서에서 AI 보조 기여를 허용하되 Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] 형식의 공개를 요구하고, Signed-off-by는 오직 사람만 붙일 수 있다고 못 박습니다. 즉 커널은 책임 소재를 사람에게 고정하는 방식으로 문제를 풀고, GCC는 애초에 들어오는 것을 제한하는 방식으로 풉니다. 커널 쪽 합의는 2025년 유지보수자 서밋에서 Sasha Levin이 밀어붙인 세 원칙 위에 서 있습니다 — 사람의 책임은 협상 불가, 사람 리뷰 없는 순수 기계 제출물은 환영하지 않음, 도구 사용은 공개.

Debian은 아직 진행 중입니다. 2026년 7월 24일 논의 기간이 시작된 총선거에 다섯 안이 올라 있고, Matthias Geiger의 전면 금지안부터 Lucas Nussbaum의 조건부 허용안, Ian Jackson의 자제 권고안, Pierre-Elliott Bécue의 지침 동반 허용안, Marc Haber의 중립안까지 스펙트럼이 넓습니다. 흥미로운 설계 하나는 범위가 Debian 자체 작업으로 한정되고 업스트림은 대상이 아니라는 점입니다. 리눅스 커널을 패키징해야 하는 배포판이 커널의 AI 정책까지 규율할 수는 없으니까요.

Qt에 대해서는 확인하지 못했습니다. Qt 프로젝트의 기여 가이드라인에서 AI 생성 코드에 관한 명시적 조항을 이 글을 쓰는 시점에 찾지 못했습니다. 다른 프로젝트들과 같은 표에 넣을 근거가 없어 뺐습니다.

전체 지형을 숫자로 보면 GCC 쪽이 소수파입니다. Andre Hora와 Romain Robbes가 GitHub 스타 상위 1,000개 저장소를 조사한 연구에 따르면, AI 정책을 가진 118개 저장소 중 78퍼센트가 AI 보조 기여를 허용했고(51퍼센트는 명시적으로 환영, 27퍼센트는 권장하지 않되 허용) 22퍼센트가 명시적으로 자제를 요구했습니다. 51퍼센트가 공개를 요구했고 74퍼센트가 사람의 개입을 의무화했습니다.

기여자에게 실제로 달라지는 것

정책 문서를 실무로 번역하면 이렇습니다.

GCC에 패치를 보낸다면, 15줄 이상의 코드나 문서에 대해서는 모델 출력을 손보는 방식으로 작성하면 안 됩니다. 이건 "티 안 나게 고치면 된다"의 문제가 아니라 DCO 서명의 정직성 문제입니다. 반대로 코드를 이해하기 위해, 버그를 찾기 위해, 남의 패치를 리뷰하기 위해 모델을 쓰는 것은 아무 문제가 없습니다. 테스트 케이스는 유지보수자 재량으로 받아 줄 수 있으니 미리 물어보는 편이 좋습니다.

# GCC: 사람이 쓴 패치에 AI 도구의 보조를 받았다면
Signed-off-by: Your Name <your@email>
Assisted-by: <도구와 모델 표기>

# 리눅스 커널: 형식이 명시돼 있다
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
Signed-off-by: Your Name <your@email>

여러 프로젝트에 기여한다면 트레일러가 프로젝트마다 다르다는 점을 감안해야 합니다. Assisted-by:가 사실상 표준으로 수렴하고 있지만, 형식과 의미는 아직 통일돼 있지 않습니다. 커널에서 이 트레일러는 규범적 승인이 아니라 모델별 버그 군집을 나중에 추적하기 위한 포렌식 장치에 가깝습니다. 같은 태그가 프로젝트에 따라 다른 목적을 갖는다는 뜻입니다.

회색 지대가 하나 남습니다. IDE의 자동 완성은 어디에 속하는가. 한 줄 완성은 15줄 기준을 넘지 않지만, 한 세션 동안 수십 번의 완성을 받아들인 결과물은 어떻게 셀 것인가. 어느 프로젝트의 정책도 이 문제에 깔끔한 답을 주지 않습니다. 실무적으로는 "내가 이 코드를 처음부터 설명할 수 있는가, 리뷰어 질문에 답할 수 있는가"가 유일하게 작동하는 자기 검증 기준입니다. 공교롭게도 GCC 정책이 명시적으로 요구하는 것도 정확히 그것입니다.

이 논쟁의 양쪽

한쪽으로 결론 내리지 않고, 실제로 갈리는 지점을 정리합니다.

제한을 지지하는 쪽의 논거. 카피레프트는 저작권 위에 서 있고, 출처가 불분명한 코드는 그 토대를 갉아먹습니다. 30년 넘게 축적된 저장소에 되돌릴 수 없는 오염이 들어가면 나중에 걸러 낼 방법이 없습니다. 게다가 리뷰 부담이 실재합니다 — 그럴듯하지만 틀린 패치를 걸러 내는 비용이 유지보수자에게 전가되고, curl이 정책에 "리뷰 시간을 정당화하지 못하는 기여"라는 표현을 넣은 것이 이 부담의 증거입니다. Gentoo가 든 세 이유(저작권, 품질, 윤리) 중 앞의 둘은 프로젝트 운영 관점에서 반박하기 어렵습니다.

허용을 지지하는 쪽의 논거. 첫째, 집행 불가능성입니다. 제출된 코드가 AI로 만들어졌는지 판별할 신뢰할 만한 방법이 없으므로, 금지는 정직한 기여자만 걸러 내고 부정직한 기여자는 그대로 통과시킵니다. 둘째, 정의의 모호성입니다. "파생"을 넓게 읽으면 검색으로 찾은 스택오버플로 답변과 모델이 알려 준 API 사용법의 경계가 흐려집니다. 셋째, 접근성입니다 — GCC 정책이 접근성 도구를 명시적으로 허용한 것은 이 반론이 실제로 제기됐음을 보여 줍니다. 넷째, 상류가 이미 쓰고 있습니다. Debian이 범위를 자기 작업으로 한정한 것은 이 현실을 인정한 설계입니다.

두 진영이 실제로 동의하는 지점도 있습니다. 사람이 책임진다는 것, 도구 사용은 밝힌다는 것, 사람 리뷰 없는 기계 제출물은 받지 않는다는 것. 커널의 세 원칙과 GCC의 요구 사항은 이 지점에서 사실상 같습니다. 차이는 원칙이 아니라 어디에 문지방을 두느냐입니다. 커널은 사람의 서명에, GCC는 코드의 출처에 둡니다.

마치며 — 이 정책은 코드 품질이 아니라 출처 이력에 관한 것입니다

세 줄로 줄이면 이렇습니다.

GCC의 선은 15줄이고, 그 근거는 AI 코드의 품질이 아니라 GPL을 집행하려면 출처 이력이 끊기면 안 된다는 것입니다. 그래서 테스트 케이스는 예외이고, 개인 사용은 자유이며, 커밋 트레일러가 새로 요구됩니다.
지형은 갈려 있습니다. 커널·curl은 공개를 조건으로 허용하고, GCC·Gentoo·NetBSD·QEMU는 제한하며, Debian은 다섯 안을 놓고 투표 중입니다. 상위 1,000개 저장소 기준으로는 허용이 다수파입니다.
두 진영이 동의하는 것은 사람의 책임, 도구 공개, 무검토 제출물 거부입니다. 갈리는 것은 문지방의 위치이고, 그 위치는 프로젝트의 법적 구조가 정합니다.

기여자로서 지금 할 수 있는 가장 실용적인 대비는 정책 문서를 외우는 게 아닙니다. 보내는 패치에 대해 처음부터 끝까지 설명할 수 있는 상태를 유지하는 것입니다. 어느 프로젝트의 정책이든 결국 그 한 가지를 다르게 표현하고 있습니다.