지난 몇 달간 분명해진 사실이 하나 있다. 코딩 에이전트가 일종의 '클린룸 구현' 방식으로 코드를 재작성하는 데 놀라울 정도로 뛰어나다는 것이다. 클린룸 구현의 가장 유명한 사례는 1980년대 Compaq이 IBM BIOS를 역설계 없이 독자적으로 복제해낸 일이다.
클린룸 구현의 가장 유명한 사례는 1982년 Compaq이 IBM BIOS를 클린룸 방식으로 복제해낸 일이다. Compaq은 한 팀의 엔지니어에게 BIOS를 역설계해 명세서를 작성하게 한 뒤, 그 명세서를 다른 팀에 넘겨 완전히 새로운 버전을 처음부터 구현하도록 했다.
이 과정에는 원래 여러 엔지니어 팀이 수 주에서 수 개월을 투입해야 했다. 그런데 코딩 에이전트를 쓰면 비슷한 작업을 몇 시간 만에 해낼 수 있다. 나도 지난 12월 JustHTML을 대상으로 이 패턴의 변형을 직접 실험해본 적이 있다.
이와 관련해 윤리적으로나 법적으로 수많은 미해결 질문이 존재한다. 그리고 이 문제가 유서 깊은 Python 라이브러리 chardet에서 본격적으로 불거지고 있다.
chardet은 Mark Pilgrim이 2006년에 만들어 LGPL로 공개한 라이브러리다. Mark는 2011년 공개적인 인터넷 활동을 중단했고, 이후 chardet의 유지보수는 다른 이들이 이어받았다. 그중 가장 대표적인 인물이 Dan Blanchard로, 2012년 7월 1.1 버전 이후 모든 릴리스를 책임져왔다.
이틀 전 Dan은 chardet 7.0.0을 릴리스하면서 릴리스 노트에 다음과 같이 적었다.
chardet을 처음부터 완전히 새로 작성하여 MIT 라이선스로 공개합니다. 패키지 이름과 공개 API는 동일하며, chardet 5.x/6.x의 드롭인 대체(drop-in replacement)로 사용할 수 있습니다. 훨씬 빠르고 정확해졌습니다!
다음 날, Mark Pilgrim이 #327: No right to relicense this project 이슈를 등록했다.
[...] 먼저, 현재 메인테이너분들과 그동안 이 프로젝트에 기여하고 개선해주신 모든 분들께 감사드립니다. 진정한 자유 소프트웨어 성공 사례입니다.
그러나 7.0.0 릴리스에서 메인테이너들이 프로젝트를 '재라이선싱'할 권리가 있다고 주장하고 있다는 사실을 전해 들었습니다. 그런 권리는 없습니다. 이는 LGPL을 명백히 위반하는 행위입니다. LGPL로 라이선스된 코드를 수정할 경우 동일한 LGPL 라이선스로 공개해야 합니다. '완전히 새로 작성했다'는 주장은 무의미합니다. 원래 라이선스가 적용된 코드에 충분히 노출된 상태에서 작업한 것이므로, 이는 '클린룸 구현'이 아닙니다. 고급 코드 생성기를 끼워넣는다고 해서 추가적인 권리가 생기는 것이 아닙니다.
Dan은 긴 답변을 통해 다음과 같이 밝혔다.
원본 코드베이스에 깊이 노출되어 있었다는 점은 맞습니다. 10년 넘게 유지보수해왔으니까요. 전통적인 클린룸 방식은 원본을 아는 사람과 새로 구현하는 사람을 엄격히 분리하는 것인데, 이번에는 그런 분리가 존재하지 않았습니다.
하지만 클린룸 방법론의 목적은 결과물이 원본의 파생 저작물이 아님을 보장하는 것입니다. 클린룸은 그 목적을 달성하기 위한 수단이지, 수단 자체가 목적은 아닙니다. 이번 경우, 프로세스 보증만이 아니라 직접적인 측정을 통해 새 코드가 구 코드와 구조적으로 독립적이라는 동일한 결론에 도달할 수 있습니다.
Dan은 이어서 JPlag 도구(스스로를 "최첨단 소스 코드 표절 및 공모 탐지"라고 소개하는 도구)의 분석 결과를 공개했다. 새로운 7.0.0 버전은 직전 릴리스와의 최대 유사도가 1.29%, 1.1 버전과는 0.64%에 불과했다. 반면, 다른 릴리스 버전 간의 유사도는 80~93% 범위였다.
그런 다음 Dan은 자신의 작업 과정을 상세히 공개했다. 강조는 내가 추가한 것이다.
투명성을 위해 재작성 과정을 전부 공개합니다. 저는 superpowers의 브레인스토밍 스킬을 활용해 다음 요구사항에 기반한 설계 문서를 작성했습니다. [...]
그 후 기존 소스 트리에 접근할 수 없는 빈 저장소에서 작업을 시작했으며, Claude에게 LGPL/GPL 라이선스 코드를 기반으로 하지 말라고 명시적으로 지시했습니다. 이후 Claude를 활용해 결과물을 검토하고 테스트하며 반복적으로 개선했습니다. [...]
이것이 새롭고 불편한 영역이라는 점, 그리고 오랜 역사를 가진 오픈소스 프로젝트를 AI 도구로 재작성하는 것이 타당한 문제 제기를 불러일으킨다는 점을 이해합니다. 하지만 증거는 명확합니다. 7.0은 LGPL 라이선스 코드베이스의 파생 저작물이 아닌 독립적인 저작물이며, MIT 라이선스가 적법하게 적용됩니다.
이번 재작성은 Claude Code를 사용해 진행되었기 때문에, 저장소에 흥미로운 산출물이 다수 남아 있다. 특히 2026-02-25-chardet-rewrite-plan.md는 매우 상세한데, 테스트부터 시작해 대체 코드를 구체화하는 과정까지 재작성의 각 단계를 순서대로 기록하고 있다.
이 사안을 쉽게 판단할 수 없게 만드는 복잡한 요소가 여러 가지 있다.
이 사안이 어떻게 귀결될지 나도 전혀 모르겠다. 개인적으로는 재작성이 정당하다는 쪽에 기울고 있지만, 양측의 주장 모두 충분히 설득력이 있다.
나는 이 사건을 코딩 에이전트로 기존의 성숙한 코드를 새로 구현하는 것에 대한 더 큰 질문의 축소판으로 본다. 이 문제는 오픈소스 세계에서 먼저 불거졌지만, 머지않아 상업 세계에서도 Compaq 사례와 유사한 형태로 등장하리라 예상한다.
기업들이 자사의 핵심 지식재산(IP)이 위협받고 있다는 사실을 인지하게 되면, 자금력을 갖춘 대규모 소송이 이어질 것이다.
2026년 3월 6일 업데이트: 한 가지 강조할 만한 세부사항이 있다. Dan은 새 구현이 순수한 '클린룸' 재작성이라고 주장하지 않는다는 점이다. 그의 댓글을 다시 인용한다.
전통적인 클린룸 방식은 원본을 아는 사람과 새로 구현하는 사람을 엄격히 분리하는 것인데, 이번에는 그런 분리가 존재하지 않았습니다.
지금은 찾을 수가 없는데, 어딘가에서 본 댓글 하나가 인상적이었다. 기존 오픈소스 라이브러리를 자원봉사로 유지보수해왔다는 이유로, 해당 분야의 새로운 구현을 만들 수 없게 된다는 것이 얼마나 부조리한 상황인지를 지적한 내용이었다.
Armin이 AI And The Ship of Theseus에서 이 상황에 대해 쓴 글도 흥미로웠다. 특히 이 부분이 인상적이다.
이것은 엄청난 파급 효과를 가져온다. 코드 생성 비용이 이 정도로 낮아지고, 테스트 스위트만으로 재구현이 가능해지면 소프트웨어의 미래에는 어떤 의미가 될까? 더 관대한 라이선스로 재탄생하는 소프트웨어가 대거 등장할까? 독점 소프트웨어가 오픈소스로 재탄생할까? 반대로 오픈소스 소프트웨어가 독점 소프트웨어로 재탄생할까?
이 블로그의 장문 아티클만 보고 계십니다. 모든 글을 받아보시려면 /atom/everything/을 구독하시거나, 다른 구독 옵션을 확인해보세요.