
오픈소스 듀얼 라이센싱 전략: 무료의 역설과 생존의 기술
MySQL에서 시작된 듀얼 라이센싱, MongoDB의 SSPL 충격, HashiCorp의 BSL 전환, 그리고 Elastic과 Redis의 U턴까지. 오픈소스 생태계의 8년간 라이센스 전쟁을 사례 중심으로 완전 해부한다. 2026년, 오픈소스의 지속가능성을 둘러싼 핵심 논쟁과 실무 전략.

MySQL에서 시작된 듀얼 라이센싱, MongoDB의 SSPL 충격, HashiCorp의 BSL 전환, 그리고 Elastic과 Redis의 U턴까지. 오픈소스 생태계의 8년간 라이센스 전쟁을 사례 중심으로 완전 해부한다. 2026년, 오픈소스의 지속가능성을 둘러싼 핵심 논쟁과 실무 전략.
2020년, XKCD 만화 #2347 "Dependency"는 IT 업계의 불편한 진실을 한 컷으로 포착했다. 거대한 디지털 인프라가 "네브래스카에 사는 어떤 사람이 2003년부터 감사도 없이 유지보수하는" 작은 프로젝트 위에 아슬아슬하게 서 있는 그림이다.
이 만화는 농담이 아니었다.
2024년 XZ Utils 백도어 사건은 이를 현실로 증명했다. Linux의 핵심 압축 라이브러리인 XZ의 유일한 메인테이너 Lasse Collin이 번아웃에 시달리던 틈을 타, 악의적인 공격자가 2년에 걸쳐 신뢰를 쌓은 뒤 백도어를 심었다. 전 세계 서버 인프라가 한 명의 지친 자원봉사자에게 의존하고 있었던 것이다.
2024년 Tidelift 보고서의 숫자는 더 충격적이다:
3억 개 기업이 오픈소스를 사용하지만, 후원에 참여하는 기업은 4,200개에 불과하다. 이 구조적 모순 — 모두가 쓰지만 아무도 내지 않는 — 이것이 듀얼 라이센싱이 탄생한 배경이다.
오픈소스 라이센싱을 이해하려면, 먼저 세 가지 축을 알아야 한다.
| 구분 | 허용적 (Permissive) | 카피레프트 (Copyleft) |
|---|---|---|
| 핵심 원칙 | "자유롭게 써라" | "파생물도 공개해라" |
| 대표 라이센스 | MIT, Apache 2.0, BSD | GPL, LGPL, AGPL |
| 상용 제품에 포함 | 제한 없음 | 소스 공개 의무 |
| SaaS 제공 | 제한 없음 | GPL: 가능 / AGPL: 소스 공개 |
| 채택 비율 (2026) | ~70% | ~30% |
RedMonk의 Stephen O'Grady에 따르면, 업계는 2014~2017년 사이 카피레프트 다수에서 허용적 라이센스 다수로 전환점을 넘었다. 2026년 현재, 허용적 라이센스가 압도적 주류다.
OSI(Open Source Initiative)가 인정하는 오픈소스의 핵심 조건:
4번이 핵심이다. "SaaS로 제공하면 안 된다"는 조건이 붙는 순간, 그것은 OSI 기준의 오픈소스가 아니다. 이것이 SSPL과 BSL이 "Source-Available(소스 공개형)"이라 불리는 이유다.
하나의 소프트웨어를 두 가지 라이센스로 동시에 제공하는 전략이다:
원리는 단순하다: GPL 의무사항(소스 공개)을 지키기 싫다면, 돈을 내고 상용 라이센스를 사라. 이렇게 하면 오픈소스의 확산 효과와 상용 수익을 동시에 얻을 수 있다.
듀얼 라이센싱의 진정한 기원은 1996년으로 거슬러 올라간다. Berkeley DB의 원저자 중 한 명인 Keith Bostic이 Sleepycat Software를 설립하면서, 하나의 소프트웨어를 자유 소프트웨어 라이센스와 상용 라이센스 두 가지로 동시에 제공하는 모델을 최초로 만들었다. Bostic은 FSF(자유 소프트웨어 재단)가 수용할 수 있는 라이센스를 직접 설계하는 데 상당한 시간을 투자했다.
원리는 단순했다: 자기 소프트웨어를 오픈소스로 공개하고 싶지 않은 기업은 Sleepycat에 비용을 지불하고 상용 라이센스를 구매하면 된다.
1995년 설립된 스웨덴의 MySQL AB는 Sleepycat의 모델을 가장 성공적으로 확장했다.
핵심 인사이트는 "GPL의 '전염성'을 지렛대로 활용한 것"이다. 기업이 MySQL을 자사 상용 제품에 포함하려면, GPL에 따라 전체 소스코드를 공개하거나, 상용 라이센스를 구매해야 했다. 대부분의 기업은 후자를 택했다.
MySQL의 성장 궤적은 이 모델의 위력을 증명한다:
CEO Marten Mickos는 MySQL을 "2세대 오픈소스 기업"이라 불렀다. 그의 핵심 통찰: 1,000명의 사용자 중 100명이 코드에 기여하고, 단 1명이 비용을 지불한다. 그리고 그 1명의 비용이 나머지 999명을 지탱한다.
Mikko Välimäki의 2003년 논문 "Dual Licensing in Open Source Software Industry"는 이 모델을 학술적으로 분석한 최초의 연구 중 하나다. 그는 MySQL AB, Sleepycat Software, Trolltech를 사례로 들며 듀얼 라이센싱이 오픈소스 기업의 가장 성공적인 비즈니스 모델이라고 결론 내렸다.
MySQL AB의 여정:
공동 창업자 Michael "Monty" Widenius는 Oracle 인수에 반대하며 MySQL을 포크해 MariaDB를 만들었다. 이것은 이후 반복될 패턴 — 라이센스 변경 → 커뮤니티 포크 — 의 시작이었다.
"오픈소스는 비즈니스 모델이 아니다. 오픈소스는 배포 모델이자 소프트웨어 개발 모델이다." — Marten Mickos, MySQL AB CEO
1991년, 노르웨이 Trolltech가 개발한 Qt는 처음에 독자적인 "Qt Free Edition License"로 배포되었다. 자유 소프트웨어 진영에서 문제가 터졌다.
1998년, KDE 데스크톱 환경이 Qt에 의존한다는 이유로 큰 논란이 벌어졌다. Qt가 진정한 자유 소프트웨어 라이센스를 사용하지 않았기 때문이다. 이 압력에 Trolltech는 Qt를 GPL + 상용 듀얼 라이센싱으로 전환했다.
이후 Qt는 Nokia에 인수(2008년), 다시 Digia에 넘어갔고, 현재까지 LGPL/GPL + 상용 라이센스 듀얼 라이센싱을 유지하고 있다. 30년 이상 지속된, 가장 오래된 듀얼 라이센싱 모델 중 하나다.
2010년대 중반, 클라우드 시장이 폭발적으로 성장하면서 새로운 긴장이 생겼다:
MongoDB는 가장 극적인 사례다:
MongoDB CEO Dev Ittycheria는 이를 "기생(parasitic)" 관계라고 표현했다. 개발 비용은 MongoDB가 지불하고, 수확은 클라우드 대기업이 가져간다.
2018년부터 시작된 대규모 라이센스 변경의 물결을 시간순으로 정리한다.
8년간의 사례에서 놀라울 정도로 동일한 패턴이 반복된다:
만든 곳: MongoDB (2018)
왜 논란인가?: AWS가 MongoDB를 서비스로 제공하려면, AWS 인프라 전체의 소스코드를 공개해야 한다는 뜻이다. 사실상 클라우드 대기업의 SaaS 제공을 금지하는 조항이다. OSI는 이를 "특정 사용 분야에 대한 차별"로 판단해 오픈소스로 인정하지 않는다.
만든 곳: MariaDB (2013) — MySQL 포크의 창시자 Monty Widenius가 설계
핵심 메커니즘: "시간 잠금(time lock)" 방식이다. 일정 기간(보통 4년) 후에 자동으로 오픈소스 라이센스(GPL 호환)로 전환된다. 이것이 BSL의 가장 중요한 특징이며, 완전 프로프라이어터리와의 차별점이다.
채택 기업: HashiCorp(Terraform, Vault), CockroachDB(초기), MariaDB, Sentry(초기)
만든 곳: Sentry (2023)
BSL의 진화형으로, Fair Source 운동의 핵심 라이센스다:
Sentry CEO Chad Whitacre는 Fair Source를 이렇게 정의했다:
소스코드를 읽고, 학습하고, 내부에서 실행하고, 수정하고, 개선안을 제안할 수 있다. 단 하나, 생산자를 경제적으로 잠식하는 무임승차만 금지한다.
| 라이센스 | OSI 인증 | SaaS 제공 | 시간 잠금 | 대표 사례 |
|---|---|---|---|---|
| MIT / Apache 2.0 | ✅ | 자유 | 없음 | React, Kubernetes |
| GPL v3 | ✅ | 자유 (소스 공개 불필요) | 없음 | Linux, WordPress |
| AGPL v3 | ✅ | 가능 (소스 공개 필수) | 없음 | MongoDB(초기), Grafana |
| SSPL | ❌ | 사실상 불가 | 없음 | MongoDB(현재) |
| BSL 1.1 | ❌ | 경쟁 서비스 금지 | 4년 | HashiCorp, MariaDB |
| FSL | ❌ | 경쟁 서비스 금지 | 2년 | Sentry, Codecov |
| 프로프라이어터리 | ❌ | 라이센스에 따름 | 없음 | Oracle DB, SQL Server |
연대기:
교훈: SSPL은 클라우드 대기업의 무임승차를 효과적으로 차단했지만, 커뮤니티 생태계에서의 고립이라는 대가를 치렀다. 그러나 MongoDB Atlas(자체 클라우드)의 성장으로 비즈니스 자체는 크게 성공했다. 2026년 현재 MongoDB의 시가총액은 IPO 당시 대비 10배 이상 성장했다.
Elastic의 이야기는 이 전체 역사에서 가장 교훈적인 사례다.
1막 — 오픈소스의 성공:
2막 — AWS의 도전:
3막 — 라이센스 전환과 포크:
4막 — 반전, 오픈소스 복귀:
왜 돌아왔나? Elastic 창시자 Shay Banon은 이렇게 밝혔다:
"Elasticsearch와 Kibana를 다시 오픈소스라 부를 수 있게 되어 순수한 기쁨이다. 나는 25년간 오픈소스의 진정한 신봉자였다."
그러나 내부적 이유는 더 현실적이었다. SSPL 전환 후 3년이 지나면서, 라이센스 제한이 가져온 커뮤니티 이탈의 비용이 클라우드 보호의 이익보다 커진 것이다. OpenSearch는 포크 첫 해에 496명의 기여자와 1억 회 이상의 다운로드를 달성하며 독자 생태계로 자리잡았다.
그러나 개발자들의 반응은 냉담했다. Socket.dev의 조사에 따르면, OpenSearch로 이전한 개발자 대부분은 다시 돌아올 의사가 없다고 응답했다. 한번 잃은 신뢰는 라이센스 변경만으로 회복되지 않는다.
2023년 8월, HashiCorp는 Terraform, Vault, Consul 등 모든 제품을 MPL 2.0 → BSL 1.1로 전환했다.
즉각적 결과:
IBM 인수는 라이센스 변경과 무관하게 전략적 판단이었을 수 있지만, 타이밍이 의미심장하다. BSL 전환으로 독립 성장이 어려워진 상황에서의 인수였기 때문이다. IBM 산하 Red Hat이 OpenTofu에 관여한다는 점에서, Terraform이 다시 오픈소스로 돌아올 가능성도 남아 있다.
Redis의 라이센스 여정은 가장 극적인 3막 구조를 보여준다:
왜 바꿨나? 숫자가 말해준다. Redis 내부 추산에 따르면, AWS는 Redis 기술로 연간 최대 10억 달러 이상의 매출을 올렸다. Redis 자체 수익의 10배 이상이다. 사용자의 1%만 유료 고객이 되는 "1% 전환 문제"에 시달리는 동안, 인프라 비용은 계속 올라갔다.
1막: 2009년부터 BSD 3-Clause로 15년간 순수 오픈소스 2막 (2024.03): BSD → SSPL + RSALv2. 며칠 만에 Linux Foundation이 Valkey 포크 발표, AWS·Google·Oracle 등이 지원. 대기업 83%가 Valkey 채택 또는 검토(Percona 조사) 3막 (2025): Redis 8.0에서 AGPLv3로 복귀. 이전 상용 전용이었던 기능들까지 오픈소스화
Redis 창시자 Salvatore Sanfilippo(antirez)는 복귀 후 이렇게 말했다:
"SSPL은 실질적으로 커뮤니티에 받아들여지지 못했다."
Redis의 사례는 "라이센스 전환의 비용"을 가장 명확하게 보여준다. 15년간 쌓은 BSD 생태계를 1년 만에 되돌려야 했고, 그 사이 Valkey라는 강력한 경쟁자를 스스로 만들어버렸다. 2025년 4분기 Valkey 채택률은 전년 대비 300% 성장했고, Valkey 8.0은 3배의 처리량 개선까지 달성했다.
오픈소스 라이센싱 논쟁은 소프트웨어를 넘어 AI 모델로 확장되었다.
Meta는 Llama 시리즈를 "오픈소스"라고 마케팅했지만, 실제 라이센스에는:
2024년 10월, OSI는 "Open Source AI Definition"을 발표하며 이에 대응했다. 이 정의에 따르면 AI가 오픈소스로 인정받으려면 학습 데이터에 대한 충분한 정보가 공개되어야 하는데, Meta는 이를 충족하지 않는다.
자유 소프트웨어 재단(FSF)도 2025년 1월 Llama 3.1의 라이센스를 "비자유 소프트웨어 라이센스"로 분류했다.
그리고 2025년 12월, Meta는 전략을 완전히 전환해 프로프라이어터리 모델("Avocado")로 이동한다고 발표했다. "오픈소스"라는 이름으로 생태계를 구축한 뒤, 충분한 시장 지배력을 확보하자 문을 닫은 것이다. 이것이야말로 오픈소스 커뮤니티가 두려워하는 "오픈 워싱(open-washing)"의 전형이다.
2025년 arXiv 논문 "Open Source at a Crossroads: The Future of Licensing Driven by Monetization"은 AI가 가져온 새로운 라이센싱 과제를 분석했다:
이 논문은 오픈소스가 "기로(crossroads)"에 서 있다고 결론 내린다. 기존의 라이센스 프레임워크가 AI 시대의 현실을 담지 못하고 있다는 것이다.
2024년의 가장 충격적인 오픈소스 사건은 라이센스가 아닌 거버넌스에서 터졌다.
2024년 9월, WordPress 공동 창시자이자 Automattic CEO Matt Mullenweg는 WordCamp US에서 호스팅 기업 WP Engine을 "WordPress의 암"이라고 공격했다. WP Engine이 WordPress로 막대한 수익을 올리면서 프로젝트에 충분히 기여하지 않는다는 것이었다.
이후 벌어진 사태:
이 사건은 오픈소스의 또 다른 위험을 보여줬다. 코드는 자유롭지만, 인프라(WordPress.org)의 통제권은 한 기업/개인에게 집중될 수 있다. 라이센스만으로는 거버넌스 문제를 해결할 수 없다.
듀얼 라이센싱으로 수익을 만드는 방법은 진화해왔다:
| 세대 | 모델 | 수익원 | 대표 사례 |
|---|---|---|---|
| 1세대 (2000년대) | 순수 듀얼 라이센싱 | GPL 면제를 위한 상용 라이센스 판매 | MySQL, Qt, Sleepycat |
| 2세대 (2010년대) | 오픈코어 (Open Core) | 핵심은 오픈소스, 엔터프라이즈 기능은 유료 | GitLab, Confluent, Elastic |
| 3세대 (2018~) | 소스 공개형 + 매니지드 서비스 | SaaS 경쟁 차단 + 자체 클라우드 서비스 | MongoDB Atlas, Redis Cloud |
| 4세대 (2023~) | Fair Source (시간 잠금) | 일정 기간 경쟁 보호 후 완전 오픈소스화 | Sentry (FSL), MariaDB (BSL) |
모든 프로젝트가 듀얼 라이센싱을 할 수 있는 것은 아니다. 핵심 전제 조건:
세 번째 조건이 가장 중요하다. 포크가 쉬운 소프트웨어는 듀얼 라이센싱이 어렵다. HashiCorp가 BSL로 전환하자마자 OpenTofu가 나온 것이 이를 증명한다.
2024년, Sentry가 주도해 Open Source Pledge를 시작했다:
OSI 공동 창립자 Bruce Perens는 2024년, 기존 오픈소스 라이센스가 "작동하지 않는다"고 선언하며 "Post-Open" 라이센싱을 제안했다:
아직 초기 단계이지만, "오픈소스의 아버지" 중 한 명이 기존 체계의 한계를 인정했다는 것 자체가 시사하는 바가 크다.
2024~2025년의 가장 주목할 트렌드는 AGPL(Affero GPL)의 재평가다:
AGPL은 오픈소스의 정의를 지키면서도 클라우드 무임승차에 대한 최소한의 방어선을 제공하는 "황금 균형점(golden middle)"으로 재평가받고 있다.
| 전략 | 작동한 점 | 실패한 점 |
|---|---|---|
| SSPL 전환 | 클라우드 무임승차 차단, 자체 SaaS 보호 | 커뮤니티 이탈, 배포판 퇴출, 포크 생성 |
| BSL 전환 | 시간 잠금으로 "결국 오픈소스" 약속 | 신규 고객 급감, 기존 사용자 불신 |
| 오픈소스 복귀 (AGPL) | 정당성 회복, 배포판 재포함 | 이미 떠난 커뮤니티는 돌아오지 않음 |
| Fair Source (FSL) | 짧은 잠금(2년), 명확한 규칙 | 아직 대규모 검증 부족 |
| AGPL 처음부터 | 오픈소스 유지 + SaaS 방어 | 상용 내장(embed) 사용에 부담 |
체크리스트:
| 상황 | 추천 라이센스 | 이유 |
|---|---|---|
| 순수 커뮤니티 프로젝트 | MIT 또는 Apache 2.0 | 최대 확산, 기여 장벽 최소화 |
| SaaS 보호가 필요한 스타트업 | AGPLv3 | 오픈소스 유지 + SaaS 방어. Elastic/Redis가 검증 |
| 초기 수익화가 필수인 스타트업 | FSL (Fair Source) | 2년 잠금 후 Apache 2.0. 가장 현대적인 선택 |
| 엔터프라이즈 소프트웨어 | 오픈코어 (Apache + 상용) | 핵심은 오픈소스, 관리·보안 기능 유료 |
| AI 모델 | OSI Open Source AI 정의 준수 | 학습 데이터 정보 공개 포함. "오픈 워싱" 방지 |
8년간의 라이센스 전쟁이 남긴 교훈은 역설적으로 단순하다:
첫째, 한번 잃은 신뢰는 라이센스만으로 되돌릴 수 없다. Elastic이 AGPL로 돌아왔지만, OpenSearch로 떠난 개발자들은 돌아오지 않았다. Redis가 BSD로 돌아갈 수 없었기에 AGPL을 택했지만, Valkey는 이미 독립 생태계가 되었다.
둘째, 공정한 보상 없이는 지속가능성도 없다. 60%의 무급 메인테이너, 44%의 번아웃 이탈. "무료" 위에 세워진 디지털 경제는 기반이 흔들리고 있다. Open Source Pledge 같은 시도가 있지만, 아직 규모가 너무 작다.
셋째, AGPL이 현실적 균형점으로 부상하고 있다. 오픈소스의 정의를 지키면서도 SaaS 무임승차에 최소한의 방어선을 제공한다. 2024~2025년 Elastic과 Redis의 복귀가 이를 증명했다.
넷째, AI가 새로운 전선을 열었다. "오픈 가중치"는 "오픈소스"가 아니며, Meta의 Llama 사례는 거대 기업이 "오픈소스"라는 이름을 전략적으로 활용하다 버릴 수 있음을 보여줬다.
궁극적으로, 오픈소스의 미래는 코드의 자유와 개발자의 생존 사이의 균형을 찾는 데 달려 있다. Richard Stallman이 말한 "free as in freedom, not free as in beer" — 자유는 공짜가 아니다. 그 자유를 유지하기 위한 공정한 비용 분담 구조를 만드는 것이 2026년 오픈소스 생태계의 가장 시급한 과제다.
참고 자료