오픈소스라이선스AI저작권클린룸chardetGPLMIT라이선스론더링

AI가 오픈소스 라이선스를 세탁한다? — chardet 사건으로 본 라이선스 론더링의 모든 것

2026년 3월, AI가 오픈소스 라이브러리를 5일 만에 재작성하고 라이선스를 바꿔버린 사건이 전 세계를 뒤흔들었다. 클린룸 구현의 역사부터 AI 시대의 저작권 위기까지, 개발자라면 반드시 알아야 할 이야기.

코어닷투데이2026-04-0442분

세탁기에 들어간 오픈소스

2026년 3월 4일, 인터넷에서 15년간 자취를 감췄던 한 프로그래머가 갑자기 나타났다. Mark Pilgrim — Python의 대표적 문자 인코딩 감지 라이브러리 chardet의 원작자다. 그가 15년의 침묵을 깬 이유는 단 하나. 자신이 만든 코드의 라이선스가 바뀌어 있었기 때문이다.

AI가 코드를 변환하는 모습의 일러스트

무슨 일이 벌어진 걸까? chardet의 현 유지보수자 Dan Blanchard가 Anthropic의 AI 코딩 에이전트 Claude Code를 사용해 단 5일 만에 라이브러리 전체를 재작성하고, 라이선스를 LGPL에서 MIT로 변경한 것이다. 연간 다운로드 수 8억 5천만 회에 달하는 핵심 인프라 라이브러리의 라이선스가, AI의 힘을 빌려 하룻밤 사이에 바뀌어버렸다.

GitHub 이슈에는 순식간에 242개 이상의 댓글이 달렸다. 전 세계 기술 매체가 동시에 보도했고, 오픈소스 진영은 두 쪽으로 갈라졌다. 이 사건은 단순한 라이선스 분쟁이 아니다. AI 시대에 소프트웨어 저작권이라는 개념 자체가 붕괴할 수 있다는 경고음이다.

"모든 copyleft 프로젝트는 Claude 세션 한 번이면 MIT가 될 수 있다." — Luka Kladaric, ShiftMag

이 글에서는 이 사건의 배경을 처음부터 차근차근 풀어본다. 오픈소스 라이선스가 뭔지 모르는 사람도 이해할 수 있도록, 역사의 시작점부터 2026년 현재까지 하나씩 따라가 보자.

오픈소스 라이선스, 대체 뭘까?

오픈소스 라이선스는 크게 두 부류로 나뉜다.

허용적 라이선스 (Permissive) — "가져다 마음대로 써"

MIT, Apache 2.0, BSD 같은 라이선스들이다. 핵심은 간단하다: "저작권 표시만 남기면, 상업적이든 비상업적이든 마음대로 써도 된다." 기업 입장에서 가장 편한 라이선스다.

카피레프트 라이선스 (Copyleft) — "받은 대로 돌려줘"

GPL, LGPL, AGPL 같은 라이선스들이다. "내 코드를 쓰려면, 네 코드도 같은 조건으로 공개해야 해." 자유 소프트웨어 운동의 철학이 담긴 라이선스다. 리처드 스톨먼이 1989년 처음 만든 GPL이 대표적이다.

항목	MIT (허용적)	GPL (카피레프트)	LGPL (약한 카피레프트)
상업적 사용	자유	자유	자유
소스코드 공개	불필요	파생작품 전체 공개	수정한 라이브러리만 공개
라이선스 전염	없음	강력 (전체 프로젝트)	제한적 (라이브러리만)
기업 선호도	매우 높음	낮음	보통
대표 프로젝트	React, jQuery	Linux 커널, WordPress	chardet (구 버전)

핵심은 이것이다. GPL/LGPL 코드를 가져다 쓰면, 내 코드도 같은 라이선스로 공개해야 한다. 이것이 바로 "전염성(viral)"이라 불리는 특성이다. 기업들이 GPL을 꺼리는 이유가 여기에 있다.

그런데 만약... 원본 코드를 직접 베끼지 않고, AI를 시켜 처음부터 새로 작성하게 하면? 그래도 "파생작품"일까? 이 질문이 chardet 사건의 핵심이다.

클린룸 구현 — 40년 된 법적 방패

이 질문에 답하려면, 소프트웨어 역사에서 가장 유명한 법적 기법 중 하나를 알아야 한다. 바로 클린룸 구현(Clean Room Implementation)이다.

클린룸 역공학 개념의 일러스트

1982년, Compaq이 IBM을 이긴 방법

1981년, IBM이 IBM PC를 출시했다. 혁명적인 제품이었다. 그런데 핵심 소프트웨어인 BIOS(Basic Input/Output System)에 IBM의 저작권이 걸려 있었다. 다른 회사가 IBM 호환 PC를 만들려면, 이 BIOS를 그대로 복제해야 했는데, 그건 불법이었다.

1982년 Compaq의 클린룸 역공학 일러스트

1982년, Compaq이라는 신생 기업이 기발한 방법을 생각해냈다.

팀 A

분석팀: IBM BIOS의 동작을 분석하고, 각 기능이 "무엇을 하는지"를 문서로 작성. 원본 코드는 철저히 격리.

벽

물리적 분리: 두 팀은 서로 만나지 않음. 문서만 전달. 팀 A가 쓴 코드를 팀 B가 볼 수 없고, 팀 B가 IBM 코드를 볼 수 없음.

팀 B

구현팀: 문서만 보고 BIOS를 처음부터 새로 작성. IBM 코드를 한 줄도 본 적 없는 엔지니어들이 담당.

이것이 클린룸 역공학(Clean Room Reverse Engineering)이다. 핵심 원칙은 딱 하나다:

"구현하는 사람은 원본 코드를 절대 봐서는 안 된다."

Compaq은 이 방법으로 IBM BIOS와 기능적으로 동일하지만 코드가 완전히 다른 BIOS를 만들었다. IBM이 소송을 걸었지만, 법원은 Compaq의 손을 들어줬다. 기능(아이디어)은 저작권으로 보호할 수 없고, 오직 표현(코드)만 보호할 수 있기 때문이다.

클린룸의 전설적 사례들

이후 클린룸 구현은 기술 산업의 핵심 법적 도구가 되었다.

Phoenix Technologies (1984)

IBM PC BIOS의 클린룸 복제에 성공. 이를 통해 수많은 IBM 호환 PC 제조사가 탄생하며, PC 혁명이 가속화.

리눅스와 UNIX (1991~)

리누스 토르발즈가 UNIX의 기능 명세만 참고하여 리눅스 커널을 처음부터 작성. UNIX 코드를 한 줄도 사용하지 않음. (이후 SCO가 소송을 걸었지만 패소.)

Wine 프로젝트 (1993~)

Windows API를 리눅스에서 구현하기 위해 클린룸 방식 사용. Microsoft의 코드를 본 사람은 프로젝트 참여 불가.

Google vs. Oracle (2021)

미국 대법원이 Google의 Java API 재구현을 공정 이용으로 판결. API의 기능적 성격이 핵심 근거.

40년간 클린룸 구현의 핵심은 변하지 않았다. "아는 사람"과 "만드는 사람"을 철저히 분리하는 것이다. 그런데 2026년, AI가 이 벽을 허물어 버렸다.

chardet 사건의 전말

등장인물

chardet의 이야기를 이해하려면 세 명의 주인공을 알아야 한다.

Mark Pilgrim
chardet 원작자 (2006)
LGPL 라이선스 선택
2011년 인터넷에서 은퇴

Dan Blanchard
유지보수자 (2012~)
12년간 700회+ 커밋
chardet 7.0 MIT 릴리스

Claude Code
Anthropic의 AI 코딩 에이전트
5일 만에 전체 재작성
48배 생산성 향상

그리고 chardet 자체도 특별한 역사가 있다

사실 chardet 자체가 클린룸의 아이러니를 품고 있다. 원본은 Mozilla의 C언어 문자 인코딩 감지 코드(MPL 라이선스)였고, Mark Pilgrim이 이를 Python으로 수동 포팅한 것이 chardet이다. 즉, chardet 자체가 이미 "다른 라이선스 코드에서 파생된" 프로젝트였다.

타임라인

무슨 일이 있었나

2025년 12월, Dan Blanchard는 chardet을 Python 표준 라이브러리에 포함시키고 싶었다. 문제는 Python 표준 라이브러리가 허용적 라이선스만 수용한다는 것이었다. LGPL로는 들어갈 수 없었다.

Dan은 결심했다. Claude Code를 사용해 chardet을 처음부터 새로 작성하기로.

Dan Blanchard의 접근 방식

Claude에게 설계 문서를 먼저 생성하게 함
빈 저장소에서 개발 시작 — 기존 코드베이스를 참조하지 않도록 지시
Claude에게 명시적으로 지시: "GPL이나 LGPL 코드에 기반하지 마라"
모든 코드를 직접 리뷰, 테스트, 반복 수정
코드 유사도 분석 도구 JPlag로 독립성 검증

결과는 놀라웠다. JPlag 분석에 따르면, chardet 7.0.0과 이전 버전의 파일 최대 유사도는 1.29%에 불과했다. 반면 이전 버전들 사이의 유사도는 80~93%였다.

코드 유사도 비교 (JPlag)

v5 ↔ v6

93%

v4 ↔ v5

87%

v3 ↔ v4

80%

v6 ↔ v7 (AI 재작성)

1.29%

수치만 보면 완벽한 독립성이다. 그런데 왜 논쟁이 벌어졌을까?

"이건 클린룸이 아니다"

2026년 3월 4일, 15년간 인터넷에서 사라져 있던 Mark Pilgrim이 GitHub 이슈에 등장했다. 그의 메시지는 명확했다.

"유지보수자는 원본 라이선스 코드에 광범위하게 노출되어 있었다. 이것은 클린룸이 아니다."

그가 지적한 문제점은 다섯 가지였다.

12년간의 코드 노출

Dan은 2012년부터 12년간 원본 chardet 코드를 유지보수하며 700회 이상 커밋했다. 클린룸의 핵심 전제인 "구현자가 원본을 본 적 없어야 한다"는 요건이 근본적으로 충족되지 않는다.

AI의 학습 데이터 오염

Claude는 인터넷의 공개 데이터로 학습된다. chardet은 연간 8.5억 회 다운로드되는 핵심 라이브러리이므로, Claude의 학습 데이터에 원본 코드가 포함되어 있을 가능성이 매우 높다.

메타데이터 참조 발견

개발 과정에서 Claude Code가 이전 버전의 metadata/charsets.py 파일을 참조한 것이 확인되었다. "전혀 참조하지 않았다"는 주장과 모순.

패키지 정체성 유지

새 코드임에도 같은 PyPI 패키지명(chardet), 같은 GitHub 저장소, 같은 버전 번호 체계를 사용. "독립적 새 프로젝트"라면 왜 같은 이름을 쓰는가?

기능적 동등성의 함정

코드는 달라도 기능이 동일하다는 것 자체가 원본에 대한 깊은 이해를 전제한다. 클린룸에서는 "무엇을 구현할지"에 대한 지식조차 제한되어야 한다는 엄격한 해석도 존재.

반론도 만만찮았다

Dan과 그의 지지자들의 주장도 강력했다.

1.29%의 유사도는 압도적 증거

표절 검사 도구가 사실상 "전혀 다른 코드"라고 판정했다. 80~93%였던 기존 버전 간 유사도와 비교하면 차이가 극명하다.

12년간 무관심했던 커뮤니티

Dan이 혼자서 무급으로 핵심 인프라를 12년간 유지보수하는 동안, 아무도 도와주지 않았다. 분노는 라이선스 변경 이후에야 터졌다.

GPLv3 공동저자의 지지

GPLv3/LGPLv3 공동저자인 Richard Fontana가 "chardet 7.0.0이 LGPL 하에 릴리스되어야 한다고 결론 내릴 근거를 보지 못했다"고 발언. 이는 매우 무게감 있는 법적 의견이다.

"라이선스 세탁"이란 무엇인가

이 사건을 계기로 새로운 용어가 등장했다. 라이선스 세탁(License Laundering)이다.

"만약 이 기법이 합법이라면, 모든 copyleft 프로젝트는 Claude 세션 한 번으로 MIT가 될 수 있다." — Luka Kladaric

돈세탁(Money Laundering)에서 따온 이 용어의 원리는 이렇다:

GPL/LGPL 코드
(카피레프트)

→

AI가 학습
(통계적 재조합)

→

기능 동등한 새 코드
(구조적 비유사)

→

MIT/Apache 릴리스
("독립 저작물")

전통적인 코드 복사는 리터럴 카피(literal copy) — 한 줄 한 줄 그대로 옮기는 것이다. 이건 표절 탐지 도구로 금방 잡힌다. 하지만 LLM(대형 언어 모델)은 다르다. 학습 데이터를 통계적으로 재조합하여 구조적으로는 완전히 다르지만 기능적으로는 동등한 코드를 생성한다. 기존의 표절 검사 기법으로는 잡을 수 없다.

이것이 왜 위험한가? 세 가지 시나리오를 생각해보자.

시나리오 1

대기업이 경쟁사의 GPL 프로젝트를 AI로 재작성 → MIT로 릴리스 → 커뮤니티와 기여자들의 노력을 무상 흡수

시나리오 2

스타트업이 인기 AGPL 프로젝트를 AI로 "세탁" → 프로프리어터리 SaaS로 출시 → 원본 프로젝트의 비즈니스 모델 붕괴

시나리오 3

악의적 행위자가 보안 라이브러리를 AI로 재작성 → 미묘한 백도어 삽입 → 허용적 라이선스로 광범위 배포

기존 법 체계는 왜 대응하지 못하는가

현행 저작권법은 포토카피기 시대에 만들어졌다. "복사"의 정의가 "원본과 실질적으로 유사한 표현의 재생산"이다. 하지만 AI가 만든 코드는:

원본과 구조적으로 다르다 (1.29% 유사도)
기능적으로는 동등하다 (같은 입력에 같은 출력)
원본의 아이디어를 구현하되 표현은 새롭다

미국 저작권법은 아이디어가 아닌 표현만 보호한다(아이디어-표현 이분법). AI가 아이디어를 학습하고 새로운 표현으로 재구현한다면, 현행법으로는 이를 침해로 보기 어렵다.

Bruce Perens의 경고 — "소프트웨어 경제의 종말"

미래 전망 — AI와 오픈소스

이 논쟁에서 가장 충격적인 발언은 Bruce Perens — 오픈소스 정의(Open Source Definition)의 원 저자 — 에게서 나왔다.

"소프트웨어 개발의 경제 전체가 죽었다. 끝났다. 사라졌다."

Perens는 자신의 경험을 공유했다. AI를 사용해 사이트 신뢰성 엔지니어링(SRE) 플랫폼 전체를 빠르게 프로토타이핑했다고. 그의 결론은 냉혹했다:

Bruce Perens의 진단

1. 프로프리어터리 소프트웨어의 종말 소프트웨어가 사소하게 복제 가능해지면, 비싸게 파는 비즈니스 모델이 무너진다.

2. 오픈소스의 기존 의미 상실 코드 공유가 더 이상 특별하지 않다. AI가 어떤 코드든 다시 작성할 수 있으니까.

3. 법적 보호의 소멸 법원 판례는 AI를 매개로 한 재작성을 침해로 보지 않는다. "잘못된 쪽이 이겼을 수 있지만, 어쨌든 이겼다."

Thaler v. Perlmutter — AI 저작물에 저작권은 있는가?

2023년, 미국 컬럼비아 특별구 연방지방법원은 Thaler v. Perlmutter 판결에서 "AI가 생성한 이미지에 저작권이 없다"고 판결했다. 2025년, 미국 대법원은 이 판결에 대한 재심 요청을 기각했다.

이 판결의 논리를 소프트웨어에 적용하면:

AI가 생성한 코드

→

저작권 없음?

→

라이선스 무의미?

저작권이 없는 코드에 라이선스를 붙일 수 있을까? 이것은 아직 법원이 답하지 않은 질문이다. 하지만 만약 AI 생성 코드에 저작권이 없다면, GPL이든 MIT든 라이선스 자체가 법적 구속력을 잃을 수 있다.

현실 세계의 영향 — 기업들의 공포

이 논쟁이 학문적 토론에만 머물렀다면 이렇게 큰 이슈가 되지 않았을 것이다. 하지만 실제 피해가 발생하고 있다.

NVIDIA 엔지니어의 경고

chardet 7.0.0 릴리스 직후, NVIDIA의 한 엔지니어가 GitHub에 다음과 같은 댓글을 남겼다:

"chardet v7.0.0은 절대적으로 유독(toxic)하다."

그 이유는 이렇다:

법적 리스크의 역설

원래 LGPL이든, 정당한 MIT 전환이든, 기업의 법무팀은 논쟁이 존재한다는 사실 자체만으로 해당 라이브러리 사용을 금지한다. LGPL보다도, MIT보다도, 분쟁 중인 라이선스가 가장 위험하다.

기업의 법무팀은 리스크를 관리한다. 코드의 법적 상태가 불확실하면, 그 코드가 아무리 좋아도 사용할 수 없다. chardet에 의존하는 프로젝트들 — requests, urllib3, pip 자체까지 — 모두가 이 불확실성에 노출되었다.

공급망 파급 효과

chardet 의존성 체인

chardet

8.5억/년

→ requests

Python의 심장

→→ pip

패키지 관리자

→→→ 모든 Python 프로젝트

전체 생태계

하나의 라이브러리의 라이선스 분쟁이 Python 생태계 전체를 오염시킬 수 있다. 이것이 소프트웨어 공급망 리스크(Supply Chain Risk)의 무서움이다.

오픈소스 유지보수자의 비극

이 사건에는 또 하나의 중요한 레이어가 있다. 오픈소스 유지보수자의 번아웃과 고독이다.

Dan Blanchard는 12년간 무급으로, 혼자서 Python 생태계의 핵심 인프라를 유지보수했다. 감사하다는 말을 해주는 사람도 드물었고, 공동 유지보수자도 없었다. 그런데 라이선스를 바꾸자, 전 세계가 분노했다.

Luka Kladaric의 지적

"거버넌스에 목소리를 내고 싶다면, 프로젝트에 거버넌스가 필요할 때 먼저 나타나야 한다."

"관리되지 않은 의존성 — 그 속에 당신의 chardet 순간이 기다리고 있다."

이것은 오픈소스의 지속가능성 역설이다:

1단계

개발자가 열정으로 오픈소스 프로젝트를 시작한다. 카피레프트 라이선스로 "자유 소프트웨어" 철학을 지킨다.

2단계

프로젝트가 인기를 얻는다. 수억 번 다운로드된다. 하지만 기여자도, 후원자도 나타나지 않는다. 카피레프트 라이선스 때문에 기업 채택이 제한된다.

3단계

유지보수자가 지친다. 라이선스를 바꿔서라도 기업 지원을 받거나 표준 라이브러리에 포함되고 싶어한다. → 이것이 chardet의 상황이다.

자유 소프트웨어 재단(FSF)의 입장

Zoe Kooyman FSF 상무이사의 발언은 이 논쟁의 또 다른 축을 보여준다:

"AI 모델은 재구현하려는 코드를 흡수한다. '진정한 클린'이란 존재하지 않는다."

FSF의 관점에서, AI를 통한 라이선스 우회는 "고도로 반사회적(highly antisocial)" 행위다. 카피레프트의 정신은 "공유하면 공유해야 한다"인데, AI가 이 원칙을 기술적으로 무력화하는 것이기 때문이다.

하지만 실용주의자들은 반문한다:

"코드가 '사소하게 재작성 가능'해지면, 라이선스의 의미 자체를 재고해야 하지 않나?" — Armin Ronacher

테스트 스위트만 있으면 AI가 어떤 코드든 재작성할 수 있는 세계에서, 소프트웨어의 가치는 어디에 있는가? 코드 자체에? 아키텍처에? 커뮤니티에? 데이터에?

전략적 실수 — 이름을 바꿨어야 했다

ShiftMag의 Luka Kladaric는 Dan의 전략적 실수를 정확하게 짚었다:

"코드가 독립적이라면, 독립적인 정체성을 가져야 한다."

만약 Dan이 새로운 라이브러리를 chardet2나 pychardetect 같은 이름으로 출시했다면, 법적 논쟁은 훨씬 적었을 것이다. 새 이름 = 새 프로젝트 = 파생 관계 불명확. 하지만 그는 같은 이름, 같은 저장소, 같은 PyPI 패키지를 그대로 유지했다.

판단 기준	Dan이 한 것	더 나았을 방법
패키지 이름	chardet (동일)	pychardetect (새 이름)
저장소	같은 repo	새 repo
버전 번호	7.0.0 (연속)	1.0.0 (새 시작)
파생 관계	암시됨	단절됨
법적 리스크	높음	낮음

2026년, 우리는 어디에 서 있는가

chardet 사건은 빙산의 일각이다. AI가 소프트웨어 개발의 근본을 바꾸고 있는 현재, 이 논쟁은 훨씬 큰 질문들로 이어진다.

아직 답하지 못한 질문들

저작권

라이선스

클린룸

AI가 학습 과정에서 코드를 "봤다"면, AI를 이용한 클린룸 구현은 원리적으로 가능한가?

가치

코드가 사소하게 재작성 가능한 세계에서, 소프트웨어의 가치는 무엇으로 측정해야 하는가?

실무자를 위한 체크리스트

이 글을 읽는 개발자와 기업 관계자를 위해, 현 시점에서의 실무 가이드를 정리한다.

AI 시대의 오픈소스 라이선스 체크리스트

개발자 / 유지보수자

AI로 재작성한 코드도 원본의 라이선스 맥락을 문서화하라
라이선스를 변경하려면 새로운 패키지명으로 출시하라
기여자 동의(CLA)를 확보하라
법률 전문가와 상의하라 — 이 분야는 아직 판례가 부족하다

기업 / 법무팀

의존성의 라이선스 분쟁 여부를 모니터링하라
AI 재작성 코드의 법적 지위가 불확실하다는 점을 인지하라
"클린룸 AI 재작성" 주장에 대해 추가 검증을 요구하라
SBOM(Software Bill of Materials)에 AI 생성 여부를 포함시켜라

커뮤니티

의존하는 프로젝트에 기여하라 (코드, 문서, 후원)
유지보수자 한 명에게 핵심 인프라를 맡기지 마라
라이선스 거버넌스를 사전에 정립하라

마치며 — 코드는 사라져도, 맥락은 남는다

chardet 사건이 우리에게 알려주는 것은 명확하다. AI 시대에 코드 자체의 가치는 급락하고 있다. 어떤 코드든 AI가 재작성할 수 있다. 유사도 1.29%. 법적으로 잡기 어렵다.

하지만 코드가 전부는 아니다. 12년간의 버그 리포트 대응, 커뮤니티와의 신뢰, API의 안정성, 실전 환경에서의 검증 — 이런 것들은 AI가 5일 만에 재생산할 수 없다.

코드는 AI가 쓸 수 있다. 하지만 소프트웨어는 코드 이상이다.

오픈소스의 미래가 위협받고 있다고 말하는 사람들이 있고, 이제야 비로소 오픈소스가 진짜 의미를 찾게 될 것이라고 말하는 사람들도 있다. 확실한 건, 2006년 Mark Pilgrim이 chardet을 LGPL로 공개할 때 상상했던 세계와, 2026년 AI가 그 코드를 5일 만에 재작성하는 세계는 같은 법적 프레임워크로 다룰 수 없다는 것이다.

다음 번 pip install 을 칠 때, 그 패키지의 라이선스를 한번 확인해 보는 것은 어떨까. 그 라이선스가 AI에 의해 "세탁"되지 않았다고 확신할 수 있는가?

"관리되지 않은 의존성 속에, 당신만의 chardet 순간이 기다리고 있다."