일주일 전만 해도 저는 오픈 소스 커뮤니티가 네 가지 명백한 이유로 AI를 거부하고 있다고 말씀드렸을 것입니다. 하지만 그 이유들을 하나씩 제대로 방어해 보려고 시도해 보았습니다. 그중 대부분은 면밀한 검토 끝에 무너졌고, 남은 것은 훨씬 더 다루기 쉬운 대화 주제가 되었습니다.

관습적인 답변

제가 아는 모든 메인테이너(Maintainer)들은 AI 도구에 대해 대략 비슷하게 세 가지 또는 네 가지의 불만을 가지고 있습니다.

첫째, 아무도 훈련 데이터(Training data)가 어디에서 왔는지 알 수 없으며, 이는 출처(Provenance)에 집착하는 문화와 상충합니다. 둘째, 메인테이너들은 AI가 생성한 PR(Pull Request)과 CVE(Common Vulnerabilities and Exposures) 보고서에 파묻혀 있습니다. 이와 관련하여 curl 측면에서 작성된 Daniel Stenberg의 포스트는 이제 전형적인 사례가 되었습니다. 셋째, AI는 기여자들이 몇 달에 걸쳐 리뷰 신뢰를 쌓으며 코드베이스를 학습하던 기존의 도제식 루프(Apprenticeship loop)를 단축해 버립니다. 그리고 넷째, 권력의 비대칭성입니다. 프런티어 모델(Frontier models)은 하이퍼스케일러(Hyperscaler)의 자본을 필요로 하는데, 이는 "당신은 이것을 읽고, 수정하고, 재배포할 수 있다"라는 원칙 위에 세워진 운동 내에서 불안정한 위치를 차지합니다.

이것이 표준적인 주장입니다. FOSDEM의 어떤 기여자에게 이 내용을 제시하더라도 모두가 고개를 끄덕일 것입니다. 또한 이것은 제가 일주일 전, 즉 이 주장을 상세히 방어하려 시도하기 전과 대부분이 실제로 성립하지 않는다는 것을 깨닫기 전의 입장이기도 했습니다.

윈-윈(Win-win) 논거

개발자들로부터 듣는 가장 흔한 반박은 명쾌합니다. 만약 AI가 오픈 소스를 기반으로 훈련되고, 그 후 더 많은 오픈 소스를 작성하는 데 사용된다면, 그것은 분명 모두에게 이득이라는 것입니다. 기본적으로 그 논거는 오픈 소스가 모델을 가르쳤고, 이제 그 모델이 사람들이 더 많은 오픈 소스를 출시할 수 있도록 돕는다는 것입니다.

첫 번째 차원의 답변은 가치가 순환되지 않는다는 것입니다. 코드는 모델 내부로 무료로 '투입'되어 학습을 통해 세탁된 후, 민간 기업으로부터 임대한 유료 결제 장벽(Paywall) 뒤에서 다시 나옵니다. GPT-5나 Claude 또는 Copilot을 형성하는 데 기여한 코드를 제공한 기여자는 수익 배분도 받지 못하고, 기여 인정(Attribution)도 받지 못하며, 다른 모든 사람과 동일한 구독료를 지불합니다. 이것을 오픈 소스가 통상적으로 복리로 성장하는 방식과 비교해 보십시오. 제가 libcurl의 버그를 수정하면, 그 수정 사항은 libcurl에 남고, 모든 다운스트림(Downstream) 사용자가 혜택을 보며, 프로젝트는 영구적으로 더 나아집니다. 하지만 LLM(대규모 언어 모델)의 경우, 업스트림(Upstream) 프로젝트는 아무것도 얻지 못합니다.

그 답변은 만족스럽습니다. 하지만 동시에 그 논거가 흔들리기 시작하는 지점이기도 합니다.

RHEL 문제

AI 추출(Extraction)에 반대하는 커뮤니티의 논리는, 지난 수십 년간 훨씬 더 큰 규모의 추출을 기꺼이 용인해 왔다는 사실을 직시해야 합니다.

Red Hat은 커널 패치를 업스트림에 배포하지만, Satellite, Insights, 그리고 Ansible Automation Platform은 독점적(Proprietary)입니다. 그들은 자신들이 작성하지 않은 커널로 수십억 달러를 벌어들였고, 2023년에는 소스 배포를 유료 고객으로 제한했으며, 여전히 Linux의 기업 기여도 최상위권을 유지하고 있습니다. 커뮤니티는 불평하면서도 RHEL을 계속 사용했습니다. 클라우드 제공업체의 추출은 Elasticsearch와 MongoDB에 충분히 큰 타격을 주어, 두 기업 모두 자기방어를 위해 라이선스를 재설정(Re-licensed)하게 만들었습니다. Elastic은 AWS를 직접 겨냥했고, MongoDB는 클라우드 카테고리 전체를 대상으로 선제적으로 대응했습니다. 그럼에도 우리는 여전히 모두 AWS를 사용합니다. Amazon Linux 2023은 Fedora의 다운스트림입니다. 그들은 오케스트레이션 평면(Orchestration plane)을 폐쇄된 상태로 유지합니다. 아무도 보이콧을 주도하지 않습니다.

만약 RHEL이 자신들이 작성하지 않은 커널로 수십억 달러를 벌면서도 폐쇄 소스인 Satellite를 사용하는 것이 용인된다면, AI에 대한 비판은 단순히 "그들이 공유 자원(Commons)으로 돈을 벌었다"라고만 할 수는 없습니다. 그것은 너무 많은 것을 증명해 버리기 때문입니다. 그 논리는 오픈 소스가 의존하게 된 매니지드 서비스(Managed-services) 산업 전체를 부정하는 결과가 됩니다.

Valve가 실제로 보여주는 것

Valve는 아마도 반(anti)-AI 입장이 가질 수 있는 가장 강력한 반례일 것입니다. Steam Deck는 데스크톱 모드에서 KDE Plasma를 탑재하여 출시되므로, Valve의 Steam Deck 작업은 컨설팅 업체(2025년부터는 Techpaladin, 그 전에는 Blue Systems)에 자금을 지원하며, 이 업체는 Nate Graham과 David Edmundson을 포함한 KDE Plasma 개발 팀의 상당 부분을 고용하고 있습니다. Valve는 또한 유사한 계약을 통해 Mesa, 커널 그래픽(kernel graphics), Wine, gamescope, 그리고 PipeWire 작업을 지원합니다. 2026년 Wayland 기반의 KDE Plasma는 2022년에 비해 극적으로 향상되었으며, 그 중 무시할 수 없는 상당 부분은 Valve의 자금 덕분입니다.

하지만 이것이 작동하는 '이유'가 중요합니다. 왜냐하면 이 사례가 커뮤니티가 때때로 원하는 방식으로는 일반화될 수 없기 때문입니다.

Valve는 그들이 출시하는 모든 Deck에 GPL 라이선스가 적용된 바이너리(binaries)를 **재배포(redistributing)**하고 있습니다. 라이선스가 그 뒤에 따르는 모든 것을 강제합니다. 그들은 소스 코드를 제공해야 하며, 카피레프트(copyleft)를 준수해야 합니다. 또한 업스트림(upstream)에 자금을 지원하는 것은 부분적으로는 깨달은 이기주의(enlightened self-interest)인데, 그 대안은 세상을 포크(forking)하여 영원히 유지보수하는 것이기 때문입니다. 이것은 도덕적 관대함이 아니라, 라이선스의 물리 법칙입니다. Linux 커널이 그들로 하여금 Linux의 규칙을 따르도록 만든 것입니다.

AI 벤더들은 코드를 재배포하지 않습니다. 그들은 코드로 학습합니다. 이것이 라이선스를 트리거(trigger)하는지 여부가 전체 법적 쟁점이며

만약 저작권법이 "코드로 학습하는 것"을 침해로 간주한다면, 소프트웨어 산업은 그 무게를 견디지 못하고 붕괴할 것입니다. 제가 아는 모든 시니어 엔지니어들은 수년간 다른 사람의 코드를 읽으며 무의식적으로 그 패턴을 전수해 왔습니다. 저 또한 Builder의 플러그인 코드를 읽음으로써 GTK 앱을 구조화하는 법을 배웠습니다. 제가 실무용 C 언어에 대해 알고 있는 것의 절반은 curl을 읽으면서 얻은 것입니다. 그 과정 중 그 어떤 것도 libcurl이나 Builder에게 제가 다음에 작성할 코드에 대한 권리를 부여하지 않았습니다. 불편한 지점은 LLM이 인간은 결코 할 수 없는 규모로 그 과정을 산업화하고 있다는 것이며, 커뮤니티의 많은 본능적인 반응은 근저에 깔린 법적 질문이 아니라 바로 그 규모의 변화에 향해 있다는 점입니다.

정직한 법적 질문은 "학습이 침해인가"가 아닙니다. 지금까지 미국 법원은 학습 데이터가 적법하게 획득되었을 때 학습과 관련된 변형적 이용 (transformative-use) 논리에 우호적인 것으로 보입니다. 다만, 작년에 해적 사이트에서 입수한 도서들을 대상으로 한 Bartz v. Anthropic 사건에서 Anthropic이 지불한 15억 달러 규모의 합의는 살아있는 반례이며, 이는 문제를 두 부분으로 나눕니다. 적법하게 라이선스가 부여된 텍스트로 학습하는 것은 방어 가능해 보이지만, 코퍼스 (corpus)가 어떻게 구성되었는가는 별개의 문제입니다. 그리고 EU는 또 다른 방향으로 나아가고 있습니다. 남은 흥미로운 질문은 "학습 데이터를 그대로 재현했을 때 그 출력물 (output) 이 침해인가"입니다. 이는 적어도 법원이 논리적으로 판단할 수 있는 문제입니다.

그리고 "학습이 일어났다"는 사실과 "특정한 표현이 재현되었다"는 사실을 분리하고 나면, 소프트웨어는 저작권이 설계되었던 대부분의 창의적 미디어와는 어색할 정도로 달라 보이기 시작합니다. 코드를 작성하는 방법에는 한계가 있기 때문입니다.

저작권법에는 이미 이를 위한 개념이 존재합니다. 바로 **합체 원칙 (merger)**입니다. 만약 무언가를 표현하는 합리적인 방법이 몇 가지 되지 않는다면, 저작권 보호는 매우 희박해집니다. 누구도 표준적인 for 루프를 소유할 수 없습니다. 누구도 퀵 정렬 (quicksort)이나 이진 탐색 (binary search)의 표준적인 형태를 소유할 수 없습니다. 특정 장르에서 피할 수 없는 전형적인 요소들에 대해서는 **장르적 관습 (scènes à faire)**이라 불리는 관련 원칙이 있습니다. Google v. Oracle (2021) 판결은 이와 인접한 영역을 다루었습니다. 법원은 Java의 선언 코드 (declaring code)를 매우 기능적인 것으로 취급했으며, 기능적 제약 (functional constraint)을 분석을 Google 측으로 기울게 만든 요인 중 하나로 삼아 최종적으로 Google의 사용이 공정 이용 (fair use)이라고 판결했습니다.

이를 AI 논쟁에 적용해 보면, "보라, 모델이 GPL 코드를 출력했다!"라는 주장 중 상당수는 면밀히 검토했을 때 설득력이 약해집니다. 충분한 양의 코드로 학습하면 정확히 일치하는 것만으로는 많은 것을 말해주지 못합니다. 대부분의 비사소한 (non-trivial) 코드베이스는 표면적인 패턴을 충분히 공유하고 있기 때문에 무언가 충돌하는 현상이 발생할 수밖에 없습니다. 진짜 법적 테스트는 "출력이 일치하는가"가 아닙니다. "기능적 정당성이 없는 방식으로 출력이 일치하는가"입니다.

복제의 강력한 증거: 특이한 변수 이름, 독특한 주석 스타일, 특이한 알고리즘 선택, 재현된 버그, 그대로 출력된 저작권 헤더 (copyright headers), 저자 특유의 습관 등. 유명한 Copilot 사례들 — // what the fuck?이라는 주석이 그대로 포함된 Quake III의 fast inverse square root, 전체 GPL 라이선스 헤더 등 — 은 실재하며 결정적인 증거가 됩니다. 이러한 사례들은 합체 원칙 (merger doctrine)에 의한 방어를 할 수 없습니다.

복제의 약한 증거: 다른 모든 퀵 정렬과 비슷해 보이는 퀵 정렬, 합리적인 작성 방법이 6가지 정도뿐이라서 일치하게 된 해시 함수 (hash function), 보일러플레이트 (boilerplate)가 수렴하기 때문에 수렴하게 된 보일러플레이트 등. 합체 원칙을 적용하는 법원이라면 이러한 사례 대부분을 아무런 어려움 없이 기각할 것입니다.

따라서 실제 남아있는 침해 우려 사항은 "재현(regurgitation)이 발생한다"는 것이 아닙니다. 그것은 바로 "특이하고 기능적으로 제약되지 않은 표현의 표적화된 재현(targeted regurgitation of idiosyncratic, non-functionally-constrained expression)"입니다. 정확히 일치하는 결과물을 억제하는 것은 다룰 수 있는 문제이며, 일부 벤더들은 이미 이를 수행하고 있습니다. 변형되었거나 부분적으로 암기된 출력을 탐지하는 것은 실제 적용 측면에서 훨씬 더 어렵지만, 바로 그 지점이 진정한 엔지니어링 작업이 필요한 곳입니다. 하지만 이것은 여전히 엔지니어링의 영역이지, 철학적 교착 상태가 아닙니다.

실제로 남아있는 것들

구호들을 걷어내고 나면, 반대 의견들은 꽤 빠르게 좁혀집니다. 남아있는 것들 중 틀린 것은 없습니다. 또한 그것들은 보통의 담론에서 들리는 내용과도 다릅니다.

첫 번째는 감사 가능성(auditability)입니다. 오픈 소스 문화는 증거(receipts)를 바탕으로 운영됩니다. git blame, 메일링 리스트 아카이브, CVE 데이터베이스, sign-off 라인 등 모든 체계는 가치를 그 출처까지 추적할 수 있도록 구축되어 있습니다. RHEL이 공공재(commons)에 기여하는 방식은 패치 단위까지 감사 가능합니다. Valve의 기여는 개발자 단위까지 감사 가능합니다. 하지만 AI 벤더들은 그에 상응하는 것을 제공하지 않습니다. 학습 코퍼스(training corpus)는 공개되지 않았고, 가중치(weights)는 폐쇄적이며, 모델의 역량 중 어느 정도가 귀하의 프로젝트에서 왔고 어느 정도가 다른 사람의 것에서 왔는지 계산할 방법이 없습니다. 반대 의견의 본질은 사실 "우리 코드를 가져갔다"가 아닙니다. 그것은 "우리 코드를 가져갔는데, 그 이후에 어떤 일이 일어났는지 우리가 감사할 방법이 없다"는 것입니다. 이는 프로세스에 대한 불만이지만, 정당한 불만이며 원칙적으로는 해결될 수 있는 문제입니다.

두 번째는 표적화된 재현(targeted regurgitation)입니다. 이는 모델이 표준적인 패턴으로 통계적으로 수렴하는 것이 아니라, 학습 데이터의 특이한 조각들을 그대로 내뱉는 경우, 즉 독특한 표현을 실제로 재현하는 경우를 말합니다. 이것은 실제적인 침해 우려 사항이지만, 엔지니어링적인 문제입니다. 정확히 일치하는 탐지(Exact-match detection)는 해결된 문제입니다. 의미론적으로 동일한 암기(Semantically equivalent memorisation)는 아직 해결되지 않았습니다. 이는 실질적인 과제이지만, 문제의 범위가 한정되어 있습니다.

세 번째는 더 어렵습니다. 왜냐하면 저작권(Copyright)으로 해결할 수 있는 답이 전혀 없기 때문입니다. Linux를 읽고 영감을 받은 인간은 다음 프로젝트에서 완만한 생산성 향상을 얻습니다. 그들은 여전히 코드를 직접 작성해야 합니다. 반면 Linux로 학습된 LLM(Large Language Model)은 이를 사용하는 모든 개발자에게 상당한 생산성 향상을 제공하며, 구독 모델을 통해 수백만 명의 사용자에게 판매됩니다. 법적 지위는 영감을 받은 인간과 동일합니다. 하지만 경제적 전이는 완전히 다릅니다. 저작권은 이러한 격차를 규제하도록 설계된 적이 없습니다. 지금까지는 그 격차가 존재하지 않았기 때문입니다. 영감은 인간의 인지적 처리량(Cognitive throughput)에 의해 제한되었습니다. 이는 실질적인 우려 사항이지만, 산업적 규모의 영감에 대해 새로운 세금이나 라이선스 체제를 원하는지에 대한 '정책(Policy)' 문제입니다. 대부분의 커뮤니티 수사법이 그러하듯 이를 저작권과 혼동하는 것은 조잡한 방식입니다. 저작권은 우리가 실제로 화가 나 있는 지점을 다루지 않습니다.

결론적으로 세 가지가 있습니다. 훈련 코퍼스(Training corpora)를 공개할 것. 특이한 형태의 역전(Idiosyncratic regurgitation)을 억제할 것. 이 정도 규모의 생산성 전이에 정책적 대응이 필요한지에 대해 진지하게 논의할 것. 이 중 그 어느 것도 AI를 거부할 것을 요구하지 않습니다.

프레임의 재구성 (The reframe)

이는 제가 실제로 도달한 결론으로 저를 이끕니다. 즉, 커뮤니티가 AI 벤더들을 잘못된 기준으로 판단해 왔다는 것입니다.

제가 속해 있는 오픈 소스 커뮤니티들 — GNOME, Rust crates 생태계, 데스크톱 Linux 세계 — 에서 AI 보조 개발은 이미 상당한 규모로 공공 코드베이스(Public codebases)에 환원되고 있습니다. 누군가가 에디터에서 유능한 페어 프로그래머(Pair programmer)를 가졌기 때문에 더 빠르게 배포되는 모든 Rust crate, 모든 GTK 위젯, 모든 커널 패치는 공공재(Commons)에 대한 기여입니다. 다만 그것이 AI 벤더의 장부에는 나타나지 않을 뿐입니다. 만약 기여를 '모델 벤더가 무엇을 오픈 소스로 공개하는가'가 아니라 '무엇이 공공재로 귀속되는가'로 측정한다면, 장부는 이미 순이익(Net positive) 상태일지도 모릅니다. 우리는 잘못된 열(Column)을 측정하고 있습니다.

커뮤니티의 현재 입장은 부분적으로 범주 오류 (Category error)라고 생각합니다. 우리는 AI 벤더들을 포지 (Forges) — GitHub, GitLab, SourceHut — 에 적용하는 기준으로 판단하고 있지만, 더 유사한 비교 대상은 컴파일러 (Compilers) 및 IDE입니다. 아무도 GCC의 최적화 휴리스틱 (Optimisation heuristics)이 공개 데이터로부터 재현 가능해야 한다거나, JetBrains가 IntelliJ를 오픈 소스로 공개하기 전까지는 그 안에서 Linux 패치를 작성하는 것을 허용해서는 안 된다고 요구하지 않았습니다. 이 비유가 완벽하지는 않습니다. 컴파일러는 파운데이션 모델 (Foundation models)처럼 저작권이 있는 코퍼스 (Corpora)를 흡수하지는 않으니까요. 하지만 문화적으로 우리는 그것들을 인프라 제공자라기보다는 생산성 도구 (Productivity tools)로 취급했습니다. 우리는 그것들을 사용자들이 무엇을 만들어내는지로 판단했습니다.