오픈소스 AI 코드 전쟁: Flathub 전면 금지 vs QEMU 조건부 허용

Flathub는 '허용 가능한 AI 사용'과 '허용 불가능한 AI 사용' 사이의 미묘한 경계선을 긋는 대신, 아예 검토 자체가 유지보수 비용이 되어버렸기 때문에 금지를 택했다. 이 플랫폼은 기술을 따라잡지 못한 법 체계를 탓하기 전에, 사람들의 주의력과 정신 건강을 지키는 쪽을 선택했다.

QEMU의 유턴: 투명성 공개라는 중간 지점 실험

QEMU는 2025년 중반 오픈소스계에서 가장 엄격한 AI 정책 중 하나를 채택했었다. ChatGPT, Claude, Copilot, Llama 등으로부터 나온 것으로 보이기만 해도 기여를 거절하는 것이 공식적인 코드 원천 규칙이었다 . 그 근거는 AI 코드는 개발자 원천 증명(DCO)을 충족시킬 수 없다는 논리였다. 서명해야 할 '인간 저작자'가 존재하지 않기 때문이다 .

그러나 2026년 5월 말, 프로젝트는 반대 방향으로 움직이기 시작했다. Red Hat의 수석 엔지니어이자 KVM 유지보수자인 파올로 본치니(Paolo Bonzini)는 저작권 침해의 파장이 되돌리기 쉽고 확산될 우려가 적은 저위험 영역에 한해 AI 지원 패치를 허용하자고 제안했다. 핵심 코드는 유지보수자의 사전 동의 없이는 여전히 금지된다 .

본치니의 논리는 지극히 실용적이었다. AI 지원 기여를 받아들인 프로젝트들이 아직 심각한 법적 소송에 휘말린 사례가 없으며, Red Hat의 내부 법무팀도 특정 범주의 변경에 대해서는 리스크를 감수할 만한 수준으로 평가했다는 것이다 . 이 제안은 기여자에게 AI 사용 여부를 숨기지 말고 명시적으로 표시하도록 하는 의무 공개 요건을 덧붙인다 .

QEMU는 사실상 '투명성'에 기반한 중간 지점이 통할 수 있다는 베팅을 한 것이다. 특히 테스트 케이스, 문서 수정, 단순 버그 패치 같은 기계적인 기여들에까지 전면 금지가 마찰만 일으키고 비례하는 법적 이득이 없다는 판단이다.

왜 DCO가 단층선인가?

Flathub의 강경 금지와 QEMU의 신중한 완화는 모두 하나의 풀리지 않은 법적 질문을 공전한다. AI가 만든 코드가 개발자 원천 증명(DCO)과 만나면 어떻게 되는가?

DCO는 기여자에게 "이 기여물을 내가 만들었거나, 프로젝트 라이선스로 제출할 권리를 내가 가지고 있다"는 증명을 요구한다. 하지만 현행법상 AI 생성 코드에는 신원 확인이 가능한 인간 저작자가 없다. 미국 저작권청은 2025년 1월, AI 결과물은 인간이 충분한 표현적 요소를 기여한 경우에만 저작권 등록이 가능하며, 아무리 정교한 프롬프트 조작도 이에 해당하지 않는다고 판시했다 . Thaler v. Perlmutter 사건에서 D.C. 순회 법원은 2025년 3월, 저작권법은 애초에 인간에 의한 창작만을 요구한다고 확정 판결했다. 2026년 3월 현재, 대법원은 이 이상의 도전을 기각한 상태다 .

이는 오픈소스 개발자들을 불편한 딜레마에 빠트린다. AI가 만든 코드를 제출하는 개발자는 DCO에 진실하게 서명할 수 없게 된다. 2026년 4월, 리눅스 커널은 사상 최초의 'AI 코딩 도우미 정책'을 만들어 오직 인간만이 Signed-off-by 태그를 추가할 수 있으며, 그 인간이 AI가 만든 모든 코드 줄에 대한 완전한 법적 책임을 진다고 공식화했다 . 그러나 QEMU의 원 금지 조항은 AI 코드로 DCO를 준수한다고 주장하는 것은 라이선스 모호성 때문에 **"신뢰할 수 없다"**고 단언했었다 .

아직 어떤 법원도 AI 생성 코드에 저작권이 존재하는지, 있다면 누구에게 귀속되는지, 어떤 하위 라이선스 의무가 파생되는지 명확히 판결하지 못했다. 법 체계가 명쾌한 답을 주지 않기 때문에, 각 프로젝트가 자체적으로 리스크 계산을 하고 있는 상황이다.

저작권 너머, '사람 값'의 문제

법적 공방도 중요하지만, Flathub를 결정적인 순간으로 몰고 간 실체는 유지보수자의 소진(Burnout)이었다. 여러 프로젝트의 유지보수자들이 동일한 패턴을 보고한다. AI가 제출한 코드는 대개 방대하지만 얄팍하다. 진정한 이해 없이 거대한 변경 이력(diff)만 만들어내며, 가치에 비해 엄청난 검토 부담을 유발한다 .

GNOME 셸 확장 기능 심사자들도 비슷한 홍수를 겪었다. 2025년 말, 심사자들은 하루에 15,000줄이 넘는 AI 생성 확장 코드와 함께 심사 질문에 대한 AI 생성 답변까지 받고 있다고 보고했다 . Flathub 유지보수자 피오트로프스키는 이 한계점을 단도직입적으로 요약했다. 그가 이 정책을 밀어붙인 이유는 일부 제출자들이 **"도대체 정상적인 의사소통 방법을 모르기 때문"**이라는 것이다 .

사람이 치르는 비용은 법적 비용과 분리할 수 없다. DCO 문제가 중요한 이유는 유지보수자들이 자신들이 승인한 코드에 대해 실제 법적 책임을 지기 때문이다. 소진 문제가 중요한 이유는 유지보수자들이 시간과 호의의 얇은 빙판 위를 걷는 자원봉사자들이기 때문이다. AI 생성 제출물은 이 두 가지를 동시에 압박한다.

세 개의 진영, 합의는 없다

2026년 2월 RedMonk는 32개의 오픈소스 조직을 분석한 끝에 어떤 합의도 나타나지 않고 있다고 결론 내렸다 . 프로젝트들은 크게 세 진영으로 나뉘었다:

• 전면 금지파: Flathub, Gentoo(2024년 만장일치 의결), NetBSD(AI 코드를 "오염된 것으로 간주"), GNOME의 EGO 리뷰 시스템은 AI 생성 기여를 무조건 거부한다 .
• 공개 조건부 수용파: QEMU의 제안은 Apache, Fedora, Linux Foundation, EFF와 같은 길을 걷는다. 이들은 의무적 라벨링과 유지보수자의 재량을 전제로 AI 사용을 허용한다 .
• 인간 책임형 허용파: 리눅스 커널과 Red Hat은 인간 개발자가 전적인 책임을 지고 DCO에 서명하며 사용 도구를 태그하는 한 AI를 허용한다. 단, Signed-off-by는 오직 인간에게만 독점된다 .

이 진영들은 단순히 규칙만 다투는 것이 아니다. AI 코드가 '관리 가능한 도구'인지 '배제해야 할 위협'인지, 그리고 그 관리 비용을 유지보수자가 져야 하는지 아니면 준비 안 된 법 체계가 떠안아야 하는지에 대한 관점 자체가 갈린다.

앞으로 벌어질 일

Flathub와 QEMU는 예외적인 사례가 아니다. AI 코딩 도구가 발전하고 생성되는 제출물의 양이 증가할수록 이 스펙트럼은 계속 넓어질 것이다. 일부 관찰자들은 1~2년 내에 AI가 생성한 코드를 기술적으로 감별하는 것이 사실상 불가능해져, 금지 정책은 의도와 무관하게 집행 불가능한 선언이 될 것이라고 지적한다 .

EFF는 LLM 사용이 너무나 만연해 전면 금지 정책을 집행하는 것은 현실성이 없다고 이미 결론지었다 . 그러나 기술적 집행 불가능성이 Flathub의 결정을 이끌었던 유지보수자 소진 문제를 해결해 주지는 않는다.

법원이나 입법부가 AI 생성 코드의 저작권과 법적 책임에 대한 명확한 기준을 마련하기 전까지, 모든 오픈소스 프로젝트는 본질적으로 자신만의 도박을 선택할 수밖에 없다. Flathub는 AI 도구로의 문을 닫는 대가로 지금 당장 검토자들을 보호하는 쪽을 택했다. QEMU는 투명성 요구와 함께 '저위험 기여에 대한 법적 리스크는 관리 가능할 것'이라는 계산 아래, 문을 좁게 열기로 결정했다. 인간의 저작권과 자발적 노동에 기반해 지어진 커뮤니티에서, 코드가 이 두 가지 없이 밀려 들어올 때 당신은 무엇을 해야 하는가라는 불편한 질문 앞에 두 팀은 각자의 합리적인 답을 내놓았을 뿐이다.