GCC도 AI 코드에 선을 그었다 — 컴파일러 진영이 던진 질문은 '저작권은 누구 것인가'

올해 오픈소스 커뮤니티에서 가장 자주 반복된 문장이 있습니다. “AI가 짜준 코드, 받아줄 건가 말 건가.” 리눅스 커널이 먼저 가이드라인을 냈고, Zig는 강경하게 선을 그었고, Godot은 사실상 문을 닫았습니다. 그리고 이제 GCC 차례인데요. 여기서부터 이야기가 좀 달라집니다.

먼저 솔직하게 말씀드리면, 이 주제는 지금 커뮤니티에서 뜨겁게 타오르고 있는 실시간 논쟁은 아닙니다. 레딧에서 최근 30일치를 훑어봐도 관련 스레드가 거의 잡히지 않았습니다. 그런데 저는 오히려 이 조용함이 흥미롭다고 봅니다. GCC가 건드린 지점은 소셜미디어에서 몇 시간 만에 소비되고 끝날 성질의 것이 아니거든요. 법률 문서를 읽어야 이해되는 종류의 문제입니다.

다른 프로젝트들은 ‘품질’을 말했고, GCC는 ‘소유권’을 말한다

지금까지 나온 AI 코드 정책들을 늘어놓고 보면 논거가 꽤 비슷합니다.

Zig의 앤드류 켈리는 AI 생성 코드를 받지 않겠다고 밝히면서, 핵심 이유로 리뷰 부담을 들었습니다. 기여자가 자기 코드를 설명하지 못하면 리뷰어가 그 부담을 대신 진다는 겁니다. Godot도 비슷한 결의 공지를 냈습니다. 검증되지 않은 대량의 PR이 메인테이너 시간을 갉아먹는다는 문제의식이었죠. 리눅스 커널 쪽은 상대적으로 유연했습니다. 도구를 쓰는 건 자유지만 Signed-off-by에 서명하는 순간 그 코드에 대한 책임은 전적으로 사람에게 있다는 취지였습니다.

세 프로젝트 모두 결국 “누가 이 코드를 책임지느냐"를 물었습니다. 품질과 리뷰 비용의 문제입니다.

GCC는 다른 걸 묻습니다. 이 코드의 저작권은 애초에 누구에게 있느냐는 질문입니다. 훨씬 앞단이고, 훨씬 골치 아픈 질문입니다.

FSF의 저작권 양도라는 특수 조건

GCC를 이해하려면 이 프로젝트가 어떻게 굴러가는지부터 봐야 합니다.

GCC는 GNU 프로젝트고, 전통적으로 일정 규모 이상의 기여에 대해 자유소프트웨어재단(FSF)에 저작권을 양도하도록 요구해왔습니다. 최근에는 DCO(Developer Certificate of Origin) 방식도 병행하고 있지만, 저작권 귀속을 명시적으로 관리한다는 구조 자체는 그대로입니다.

왜 이런 걸 요구할까요. FSF가 저작권을 한곳에 모아두면 GPL 위반이 발생했을 때 법적으로 대응할 주체가 명확해지기 때문입니다. 수백 명의 기여자에게 흩어져 있는 권리로는 소송을 걸기 어렵습니다. 라이선스를 나중에 GPLv3로 올린다든지 하는 결정도 마찬가지고요.

여기서 문제가 터집니다. 저작권 양도는 양도할 저작권이 존재한다는 전제 위에 서 있습니다. 그런데 LLM이 생성한 코드에 저작권이 있느냐는 질문에, 지금 아무도 자신 있게 답을 못 합니다.

“저작권이 없는 것"을 어떻게 양도합니까

미국 저작권청은 인간의 창작적 기여가 없는 순수 AI 산출물에 저작권을 인정하지 않는다는 입장을 유지해왔습니다. 사람이 개입한 정도에 따라 판단이 갈리는데, 그 경계선이 어디인지가 명확하지 않습니다.

이걸 GCC 상황에 대입해보면 이렇게 됩니다.

기여자가 Copilot으로 함수 하나를 만들어 GCC에 제출합니다. 그리고 “이 코드의 저작권을 FSF에 양도합니다"라는 서류에 서명합니다. 그런데 만약 그 코드에 애초에 저작권이 없다면? 서명은 아무것도 이전하지 않은 빈 문서가 됩니다. 반대로 기여자가 프롬프트를 정교하게 다듬고 출력물을 상당히 수정했다면 저작권이 생겼을 수도 있습니다. 그럼 어느 쪽인지 누가 판단하나요.

메인테이너는 판단할 수 없습니다. PR 하나하나가 어떻게 만들어졌는지 알 방법이 없으니까요. 결국 기여자의 자기 신고에 의존하게 되는데, 이건 법적 보호 장치라기엔 너무 얇습니다.

문제는 여기서 끝나지 않습니다. 학습 데이터 문제가 남아 있거든요. LLM이 GPL 코드를 학습해 만들어낸 출력물이 원본과 상당히 유사하다면, 이건 사실상 라이선스 표시 없는 파생 저작물일 수 있습니다. GPL로 배포되는 GCC에 라이선스 이력이 불투명한 코드가 섞이면, 나중에 GPL 위반을 주장할 때 자기 발밑이 무너집니다. FSF가 저작권을 모아온 이유 자체가 훼손되는 겁니다.

왜 이 논의가 조용한가

레딧에서 이 주제로 활발한 토론이 안 잡히는 이유도 여기 있다고 봅니다.

“AI 코드 받지 마라 vs 받아라"는 누구나 한마디 얹을 수 있는 주제입니다. 반면 “저작권 양도 계약의 유효성이 AI 생성물에 대해 성립하는가"는 답하려면 저작권법과 GNU의 거버넌스 역사를 둘 다 알아야 합니다. 참여 장벽이 훨씬 높습니다.

그리고 GCC는 원래 이런 프로젝트입니다. 메일링 리스트에서 몇 달에 걸쳐 논의가 익어가고, 트위터로는 거의 새어나오지 않습니다. 조용한 게 논의가 없다는 뜻은 아닙니다. 저는 이게 오히려 이 논의의 무게를 보여준다고 생각합니다.

컴파일러라는 자리의 특수성

한 가지 더 짚고 싶은 게 있습니다. GCC는 그냥 큰 오픈소스 프로젝트가 아닙니다.

리눅스 커널이 GCC로 빌드됩니다. glibc도, 대부분의 배포판 패키지도 그렇습니다. GCC에 문제가 생기면 그 위에 쌓인 모든 것에 파장이 갑니다. 컴파일러는 신뢰 사슬의 맨 아래에 있고, 맨 아래가 흔들리면 위쪽 전부가 흔들립니다.

켄 톰슨이 1984년 튜링상 수상 강연에서 던진 이야기가 유명하죠. 컴파일러에 백도어를 심으면 소스코드를 아무리 들여다봐도 찾을 수 없다는 내용이었습니다. 지금 상황은 그때와 성격이 다르지만, “컴파일러에 들어가는 것에 대해서는 더 높은 기준을 적용해야 한다"는 결론은 같습니다. 미묘한 최적화 버그 하나가 수천 개 패키지에 조용히 퍼지는 자리입니다.

법적으로 지위가 불확실한 코드가 여기 섞이는 걸 GCC가 다른 프로젝트보다 훨씬 신중하게 다루는 건, 이 위치 때문이라고 봅니다.

남는 문제

정리하면 이렇습니다.

Zig와 Godot이 던진 질문은 “이 코드를 리뷰할 시간이 있는가"였습니다. 실무적이고 즉각적인 문제입니다. GCC가 던진 질문은 “이 코드를 우리가 소유할 수 있는가"입니다. 답이 나오려면 법원 판결이나 입법이 필요할 수도 있는 문제입니다.

그리고 이 질문은 GCC만의 것이 아닙니다. CLA를 요구하는 모든 프로젝트, 그러니까 아파치 재단 산하 프로젝트들, 기업이 후원하는 오픈소스 대부분이 같은 구조를 안고 있습니다. GCC가 먼저 부딪혔을 뿐입니다.

당장 실무자 입장에서 취할 수 있는 태도는 이 정도인 것 같습니다. 기여하려는 프로젝트의 CLA와 AI 정책을 먼저 확인할 것. AI 도구를 썼다면 숨기지 말고 밝힐 것. 그리고 자기가 제출하는 코드를 설명할 수 있는 상태로 만들어둘 것.

AI가 짠 코드는 누구의 것일까요. 앞으로 몇 년간 이 질문이 오픈소스 생태계에서 가장 골치 아픈 문제로 남을 것 같습니다. GCC는 그 질문을 가장 먼저, 가장 진지하게 꺼낸 프로젝트가 됐습니다.