소프트웨어 라이선스 종류 | 강도·인기도 순 완전 정리와 바이브코딩 주의점
소프트웨어를 만들거나 가져다 쓸 때 라이선스를 모르면 법적 분쟁에 휘말릴 수 있다. 깃허브에 올라온 코드가 "무료"처럼 보여도, 라이선스 조건을 지키지 않으면 저작권법 위반이 된다. 특히 요즘 급증한 바이브코딩(AI 도구를 활용한 빠른 소프트웨어 개발) 환경에서는 AI가 자동으로 가져온 오픈소스 코드의 라이선스를 개발자가 직접 파악하지 못하는 경우가 많아 위험성이 더 크다.
라이선스는 단순한 법적 형식이 아니다. 소스코드를 공개해야 하는지, 상업적으로 팔 수 있는지, 수정 후 다른 이름으로 배포할 수 있는지를 모두 결정한다. MIT 라이선스 코드를 가져다 상업 제품에 쓰면 문제가 없지만, GPL 코드를 같은 방식으로 쓰면 전체 소스코드를 공개해야 하는 의무가 생긴다. 이 차이를 모른 채 제품을 출시하면 출시 후 강제 소스 공개나 손해배상 소송으로 이어질 수 있다.
이 문서에서는 라이선스를 강도(소스코드 공개 의무 강도) 및 실제 사용 인기도 순으로 전부 나열하고, 각각의 핵심 조건과 사용 가능 범위를 설명한다. 깃허브 코드를 가져다 쓸 때의 체크포인트, 그리고 바이브코딩으로 만든 소프트웨어를 유료 또는 무료로 배포할 때 반드시 확인해야 할 항목까지 포함했다.
1. 라이선스가 중요한 이유
1.1 법적 강제력과 저작권의 관계
- 오픈소스 코드에는 반드시 저작권이 존재한다. "무료로 공개된 코드"라고 해서 저작권이 없는 게 아니다. 저작자가 자신의 권리를 유지하면서 조건부로 사용을 허락한 것이 바로 라이선스다.
- 라이선스 조건을 위반하면 저작권법 위반이 된다. 단순한 계약 위반이 아니라 형사 처벌 가능성도 있으며, 민사 손해배상 청구 대상이 된다.
- 기업 규모가 클수록 리스크가 크다. 스타트업이 GPL 코드를 실수로 상업 제품에 넣었다가 나중에 투자 심사나 인수합병(M&A) 과정에서 발각되면 거래 자체가 무산될 수 있다.
- 라이선스 전파(전염성) 개념이 존재한다. 특정 라이선스는 해당 코드를 포함한 전체 소프트웨어에 동일 라이선스를 강제한다. 이를 모르고 내부 코드에 섞으면 자사 핵심 코드까지 공개해야 하는 상황이 생긴다.
- AI 코딩 도구가 생성하는 코드도 예외가 없다. GitHub Copilot, Cursor, Claude 등 AI 도구가 오픈소스 코드를 학습해 유사한 코드를 생성할 때, 그 코드가 특정 라이선스 프로젝트에서 유래했다면 법적 불확실성이 남는다.
1.2 라이선스를 반드시 확인해야 하는 시점
- 깃허브에서 코드를 복사·포크할 때: 저장소 루트의 LICENSE 또는 LICENSE.md 파일을 먼저 확인한다. 파일이 없으면 기본적으로 저작권은 원작자에게 있고, 사용 허락이 없는 상태로 간주한다.
- npm, pip, Maven 등 패키지 매니저로 의존성을 추가할 때: 패키지 하나에 수십 개의 전이 의존성이 딸려 오고, 각각 다른 라이선스를 가질 수 있다.
- 상업 제품 출시 전: 전체 의존성 트리를 스캔해 GPL 계열이 포함됐는지 확인해야 한다.
- AI 도구로 자동 생성된 코드를 프로덕션에 배포하기 전: AI가 제안한 코드의 출처와 라이선스를 직접 검증하는 절차가 필요하다.
2. 라이선스 강도 및 인기도 순 전체 목록
라이선스는 소스코드 공개 의무의 강도에 따라 크게 다섯 단계로 나뉜다. 아래 표는 강도 약한 순(자유로운 순)에서 강한 순으로 정렬하며, 각 단계에서 실제 사용 빈도가 높은 것을 앞에 배치했다.
| 단계 | 분류 | 대표 라이선스 | 소스공개 의무 | 기업 사용 난이도 |
|---|---|---|---|---|
| 1단계 | Public Domain | CC0, Unlicense, WTFPL | 없음 | 매우 쉬움 |
| 2단계 | Permissive | MIT, Apache 2.0, BSD-2/3, ISC, Boost, zlib | 없음 | 쉬움 |
| 3단계 | Weak Copyleft | LGPL, MPL, EPL, CDDL, EUPL | 수정 파일/모듈만 | 조건부 가능 |
| 4단계 | Strong Copyleft | GPL v2, GPL v3 | 결합 전체 | 어려움 |
| 5단계 | Network Copyleft | AGPL v3, SSPL | 네트워크 서비스 포함 | 매우 어려움 |
| 별도 | Source Available | BUSL, Elastic License 2.0 | 제한적 공개 | 조건 확인 필수 |
2.1 1단계 — Public Domain(퍼블릭 도메인): 완전 자유
- CC0 1.0 Universal: Creative Commons 재단이 만든 저작권 포기 선언 도구다. 코드보다는 데이터셋, 문서, 이미지에 주로 사용되며, 저작자가 전 세계에서 저작권법상 가능한 최대한의 권리를 포기한다. 저작권 표시도 불필요하다. FSF는 자유 라이선스로 인정하지만 OSI는 공식 승인하지 않았다.
- The Unlicense: 소프트웨어에 특화된 퍼블릭 도메인 선언 라이선스다. OSI 승인을 받았으며, 어떤 조건도 붙지 않는다. 개인 유틸리티 스크립트나 예제 코드에 많이 쓰인다.
- WTFPL(Do What The F* You Want To Public License): 이름 그대로 어떤 제약도 없다. FSF는 인정하지만 OSI 미승인이다. 실무보다는 개인 프로젝트에서 유머성으로 사용된다.
핵심 포인트: Public Domain 라이선스는 저작권 표시조차 불필요하다. 완전히 자유롭지만, 특허 보호가 없으므로 특허 분쟁 가능성이 있는 코드에는 Apache 2.0이 더 안전하다.
2.2 2단계 — Permissive(허용적 라이선스): 저작권 표시만 하면 자유
Permissive 라이선스는 **소스코드를 공개하지 않아도 되고 상업적으로 판매도 가능하며, 저작권 고지(Copyright Notice)와 라이선스 사본을 소프트웨어에 포함시키는 것이 사실상 유일한 의무다. 전체 오픈소스 생태계에서 가장 많이 사용되는 라이선스 유형으로, npm 패키지 기준으로는 MIT가 전체의 약 55% 이상을 차지한다.
- MIT License: 가장 많이 사용되는 라이선스다. React, Vue.js, Next.js, Node.js, jQuery, Ruby on Rails 등 대부분의 인기 프레임워크가 MIT를 사용한다. 라이선스 사본과 저작권 고지를 포함시키기만 하면 상업적 판매, 수정, 재배포, 서브라이선스 모두 가능하다. 특허 보호 조항은 없다.
- Apache License 2.0: MIT와 유사하지만 명시적 특허 허용(Patent Grant) 조항이 포함된다. 라이선스가 적용된 코드에 특허가 걸려 있어도 사용자에게 특허 소송을 제기할 수 없다. 수정된 파일에는 변경 사실을 명시해야 하고, 트레이드마크 사용이 제한된다. Android, Kubernetes, TensorFlow, Swift가 Apache 2.0을 사용한다. 특허 분쟁 가능성이 있는 기업 환경에서는 MIT보다 Apache 2.0이 더 안전하다.
- BSD 2-Clause "Simplified": 소스코드 배포 시 저작권 고지와 면책 조항 유지, 바이너리 배포 시에도 동일 조건을 문서에 포함해야 한다. 소스코드 공개 의무 없음.
- BSD 3-Clause "New" or "Revised": BSD 2-Clause에 원저작자 이름을 사전 서면 동의 없이 홍보·광고에 사용하는 것을 금지하는 조항이 추가됐다. 현재 BSD 라이선스의 표준으로, Go 언어, D3.js 등이 사용한다.
- BSD 4-Clause "Original": BSD 원형이지만 모든 광고물에 특정 문구를 포함해야 하는 광고 조항(Advertising Clause) 때문에 GPL과도 호환되지 않는다. 현재는 사용을 권장하지 않는다.
- ISC License: MIT와 기능적으로 동일하지만 더 간결하게 작성됐다. 베른 협약에 따라 불필요하다고 간주되는 문구를 제거했다. OpenBSD의 공식 라이선스이며, npm의 기본 라이선스로 설정되어 있어 Node.js 생태계에서 매우 많이 쓰인다. OSI와 FSF 모두 승인했다.
- Boost Software License 1.0 (BSL-1.0): Boost C++ 라이브러리 배포를 위해 만들어졌다. 바이너리 배포 시 저작권 표시조차 불필요해 헤더 파일만 추가하면 되는 매우 유연한 라이선스다. C++ 생태계에서 많이 사용된다.
- zlib/libpng License: zlib 압축 라이브러리와 libpng 이미지 라이브러리에 사용된다. 수정 사실 명시 의무가 있고, 원작자 허위 표시를 금지한다. 바이너리 배포 시 별도 고지 의무 없음.
- MIT No Attribution (MIT-0): MIT에서 저작권 고지 의무마저 제거한 버전이다. 사실상 퍼블릭 도메인과 동일하게 작동하면서 법적 명확성을 유지한다. AWS에서 자체 코드 예제에 자주 사용한다.
- PostgreSQL License: PostgreSQL 데이터베이스 전용 라이선스로, MIT/BSD 수준의 완전 자유 라이선스다.
- Python Software Foundation License 2.0 (PSF-2.0): Python 언어 및 표준 라이브러리에 적용된다. Permissive 성격으로 GPL 2.0과 호환된다.
- PHP License v3.01: PHP 언어 배포용 라이선스다. "PHP"라는 명칭을 파생 제품 이름에 사용할 수 없는 조항이 있고 GPL과 호환되지 않아, PHP 언어 자체 외의 용도에는 권장하지 않는다.
- Apache License 1.0 / 1.1: Apache 2.0 이전 버전이다. 1.0에는 광고 조항이 있고, 1.1에서 일부 완화됐지만 GPL 2.0과 호환되지 않는다. 현재는 신규 프로젝트에 쓰지 않는다.
- Universal Permissive License v1.0 (UPL-1.0): Oracle이 만든 라이선스로 MIT와 유사하면서 특허 허용 조항까지 포함된다. OSI 승인.
- Academic Free License v3.0 (AFL-3.0): Lawrence Rosen이 작성한 라이선스로 특허 허용 조항이 포함된다. OSI 승인을 받았지만 GPL과 호환되지 않는다.
- Artistic License 2.0: Perl 커뮤니티 라이선스로, GPL 2.0과 호환된다.
- W3C Software License: W3C 자체 소프트웨어에 사용. BSD와 유사하며 수정 사실 고지 의무 포함.
- FreeType License (FTL): FreeType 폰트 렌더링 라이브러리용 라이선스. BSD 유사.
- X11 License: X Window System용 라이선스로 MIT와 사실상 동일하다.
- NCSA / University of Illinois Open Source License: MIT와 BSD-3-Clause를 결합한 형태. LLVM이 사용한다.
- Zope Public License 2.1 (ZPL-2.1): Zope 웹 프레임워크용 Permissive 라이선스. GPL 호환.
- CeCILL v2.1: 프랑스 연구기관(CEA, CNRS, INRIA)이 프랑스 법률에 맞게 만든 GPL 호환 라이선스.
2.3 3단계 — Weak Copyleft(약한 카피레프트): 수정 부분만 공개
Weak Copyleft는 라이선스가 적용된 코드를 수정한 경우 그 수정 부분(파일·모듈 단위)만 소스코드를 공개해야 한다. 해당 코드를 단순히 링크하거나 결합한 외부 코드에는 소스코드 공개 의무가 전파되지 않는다. 라이브러리 형태로 배포하거나 상용 제품과 함께 배포하는 오픈소스에 자주 쓰인다.
- LGPL v2.1 (GNU Lesser General Public License): FSF가 라이브러리 배포를 위해 GPL에서 파생한 라이선스다. 동적 링킹(Dynamic Linking)으로 사용하는 경우 자체 소스코드 공개 의무가 없다. LGPL 라이브러리 자체를 수정하면 수정 코드를 공개해야 한다. glibc, FFmpeg, Qt(일부)가 LGPL을 사용한다. 가장 많이 사용되는 Weak Copyleft 라이선스다.
- LGPL v3.0: LGPL 2.1에 GPL 3.0의 특허 허용 조항과 안티-티보이제이션(하드웨어로 수정을 막는 행위 금지) 조항이 추가됐다. 사용자 제품 배포 시 설치 정보 제공 의무가 생긴다.
- MPL 2.0 (Mozilla Public License): Firefox, Thunderbird 배포에 사용된 파일 단위 카피레프트 라이선스다. MPL이 적용된 파일을 수정하면 해당 파일만 소스코드로 공개해야 한다. 수정하지 않은 파일이나 별도 파일은 비공개 유지 가능. MPL 2.0은 GPL 2.0 및 LGPL과 호환된다.
- MPL 1.1: MPL 이전 버전. GPL과 호환되지 않아 현재는 2.0 사용을 권장한다.
- EPL 2.0 (Eclipse Public License): Eclipse 재단이 만든 모듈 단위 카피레프트 라이선스다. EPL 코드를 포함하거나 수정하여 배포할 때 해당 모듈의 소스코드를 공개해야 한다. 별개의 모듈로 분리하면 공개 의무가 전파되지 않는다. EPL 2.0에서 특허 허용 조항이 강화됐다. GPL과는 호환되지 않는다.
- EPL 1.0: EPL 이전 버전. 현재는 2.0 사용을 권장.
- CDDL 1.0 (Common Development and Distribution License): Sun Microsystems(현 Oracle)가 MPL을 기반으로 만든 파일 단위 카피레프트 라이선스다. ZFS, OpenSolaris에 사용된다. GPL과 호환되지 않아 Linux 커널과 결합하면 라이선스 충돌이 발생한다. Ubuntu의 ZFS 포함 논란이 이 충돌에서 비롯됐다.
- CPL 1.0 (Common Public License): IBM이 만든 모듈 단위 Weak Copyleft 라이선스로 EPL 1.0의 전신이다. 현재는 EPL로 대체됐다.
- IPL 1.0 (IBM Public License): IBM 오픈소스 프로젝트용. CPL과 유사한 모듈 단위 소스코드 공개 의무.
- OSL 3.0 (Open Software License): AFL의 Copyleft 버전으로 2차 저작물 전체에 동일 라이선스 적용 의무가 있고, 네트워크 서비스도 소스코드 공개 의무를 발생시킨다. GPL과 호환되지 않는다.
- EUPL 1.2 (European Union Public Licence): EU 집행위원회가 공공 소프트웨어 배포를 위해 만든 라이선스다. EU 23개 공식 언어로 번역 제공되며 EU 법률 체계를 따른다. AGPL 3.0, GPL 2.0/3.0, MPL 2.0 등과의 호환성을 명시적으로 지원하며, 네트워크 서비스도 소스코드 공개 의무 대상에 포함된다.
- APSL 2.0 (Apple Public Source License): Apple이 macOS/Darwin 일부 컴포넌트에 사용한다. 파일 단위 소스코드 공개 의무가 있으며, 수정된 코드를 내부 사용하더라도 Apple에 통보해야 하는 조항이 포함된다. GPL과 호환되지 않는다.
- CPAL 1.0 (Common Public Attribution License): OSL 3.0 기반으로 네트워크 사용 시 소스코드 공개 의무가 있고, 소프트웨어를 사용하는 웹 인터페이스에 저작자 표시를 의무화한다. OSI 승인 라이선스.
- Ruby License: Ruby 언어에 사용. 2-Clause BSD와 유사하며 GPL 2.0과 듀얼 라이선스로 제공된다.
2.4 4단계 — Strong Copyleft(강한 카피레프트): 결합 전체 소스 공개
Strong Copyleft 라이선스는 해당 코드를 포함하거나 결합한 소프트웨어 전체를 동일한 라이선스로 소스코드를 공개해야 한다. "전염성(Viral) 라이선스"라고도 불린다. 상업 제품에 하나라도 포함되면 전체 소스코드 공개 의무가 생기므로 기업 환경에서 사용 시 매우 주의해야 한다.
- GPL v2.0 (GNU General Public License): FSF의 리처드 스톨만이 만든 가장 대표적인 카피레프트 라이선스다. GPL 코드를 결합한 소프트웨어를 배포할 때 전체 소스코드를 동일한 GPL 라이선스로 공개해야 한다. 상업적 이용은 허용하지만 소스코드 공개가 반드시 수반된다. Linux Kernel(GPL-2.0-only), Git이 대표적이다. GPL v3와 호환되지 않는 별도 버전이므로 버전 확인이 중요하다.
- GPL v3.0: GPL v2.0에서 세 가지가 강화됐다. 첫째, 명시적 특허 허용 조항으로 기여자가 자신의 특허를 사용자에게 허가한다. 둘째, 안티-티보이제이션 조항으로 하드웨어 잠금을 통해 GPL 소프트웨어 수정을 막는 것을 금지한다. 셋째, Apache 2.0 등 다양한 라이선스와의 호환성이 개선됐다. Bash, GCC, GIMP 등이 GPL v3를 사용한다.
- GPL v2+ (GPL v2 or later): 많은 오픈소스 프로젝트가 "GPL 버전 2 이상"으로 명시한다. 이 경우 GPL v2와 v3 모두 조건에 해당하며 사용자가 선택 가능하다.
핵심 포인트: GPL 코드를 상업 제품의 의존성으로 추가하는 순간 전체 소스코드 공개 의무가 생긴다. npm, pip, Maven으로 패키지를 추가할 때 전이 의존성까지 GPL이 포함되지 않았는지 FOSSA, Snyk, Black Duck 같은 라이선스 스캐너로 확인하는 것이 안전하다.
2.5 5단계 — Network Copyleft(네트워크 카피레프트): SaaS도 배포로 간주
기존 GPL은 소프트웨어를 외부에 배포(distribute) 할 때만 소스코드 공개 의무가 발생했다. 클라우드 시대에 SaaS로 서비스하면 배포 없이 GPL 코드를 활용할 수 있다는 허점이 생겼고, 이를 막기 위해 나온 것이 Network Copyleft 라이선스다.
- AGPL v3.0 (GNU Affero General Public License): GPL v3.0을 기반으로 네트워크를 통한 서비스 제공도 배포로 간주하는 조항을 추가했다. 서버에서 AGPL 소프트웨어를 실행하여 사용자에게 서비스하면 해당 소프트웨어의 소스코드를 공개해야 한다. MongoDB(구버전), Grafana OSS, Nextcloud, Mastodon, Gitea가 AGPL을 사용한다. SaaS 비즈니스를 구축할 때 AGPL 라이브러리를 백엔드에 쓰면 전체 서버 코드 공개 의무가 생긴다.
- SSPL v1.0 (Server Side Public License): MongoDB가 2018년 AGPL 3.0을 기반으로 만든 라이선스다. AGPL보다 훨씬 강력하여, 소프트웨어를 서비스로 제공할 경우 해당 서비스를 구성하는 모든 소프트웨어(모니터링, 백업, 인증 시스템 포함) 의 소스코드를 공개해야 한다. AWS 같은 클라우드 벤더의 무임승차를 막기 위해 설계됐다. OSI는 오픈소스 라이선스로 인정하지 않아 Source Available으로 분류된다.
2.6 별도 — Source Available(소스 공개이나 제한적)
소스코드는 공개되어 있지만 특정 사용 형태(주로 상업적 SaaS 제공)를 제한하는 라이선스다. OSI가 승인한 오픈소스가 아니기 때문에 "오픈소스"라고 부르는 것은 엄밀히 틀리다.
- BUSL 1.1 (Business Source License): MariaDB가 2016년 만든 라이선스다. 소스코드를 공개하지만 상업적 프로덕션 사용을 일정 기간 제한한다. 라이선스 작성 시 지정한 Change Date(보통 3~4년 후) 가 지나면 자동으로 지정된 오픈소스 라이선스(보통 Apache 2.0 또는 GPL)로 전환된다. HashiCorp(Terraform, Vault), Akka, Couchbase, MariaDB MaxScale 등이 채택했다. 비상업적 사용, 테스트, 개발 환경 사용은 자유롭다.
- Elastic License 2.0 (ELv2): Elastic사가 2021년 Elasticsearch와 Kibana에 채택한 라이선스다. 두 가지 핵심 제한만 있다. 첫째, 소프트웨어를 다른 사람에게 관리형(Managed) 서비스로 제공 불가. 둘째, 라이선스 키 기능을 우회하거나 비활성화 하는 행위 금지. 내부 사용, 수정, 파생 작업은 자유롭다.
- Commons Clause: 독립 라이선스가 아닌 기존 오픈소스 라이선스에 추가하는 제한 부가 조항이다. "소프트웨어를 판매하는 행위"를 금지하며, 적용 즉시 OSI 오픈소스 정의를 충족하지 못하게 된다. Apache 2.0 + Commons Clause 형태로 많이 쓰인다.
2.7 AI 모델 전용 라이선스
AI/ML 모델(가중치 포함)에 특화된 라이선스로, 모델 사용은 허용하지만 윤리적·행동 제한이 포함된다.
- CreativeML Open RAIL-M: Stable Diffusion 등 AI 이미지 생성 모델에 사용된다. 딥페이크 생성, 사기, 불법 콘텐츠 생성 등 특정 용도를 명시적으로 금지한다.
- BigScience RAIL License v1.0: BLOOM 등 대규모 언어 모델에 사용되는 책임 있는 AI 라이선스다.
- Meta Llama 2 Community License: Meta의 Llama 2 전용 라이선스다. 연구 및 상업적 사용을 허용하지만 월간 활성 사용자(MAU) 7억 명 이상 서비스에는 별도 상업 라이선스가 필요하다.
- Meta Llama 3 Community License: Llama 3에 적용되는 라이선스로 Llama 2보다 완화됐다. Meta 브랜드 제품명 사용 금지 조항이 포함된다.
2.8 Creative Commons — 콘텐츠·데이터셋 라이선스
CC 라이선스는 소프트웨어 코드보다 문서, 이미지, 영상, 음악, 데이터셋에 주로 사용된다. 네 가지 조건(BY 저작자표시, SA 동일조건변경허락, NC 비영리, ND 변경금지)의 조합으로 만들어진다.
| 라이선스 | 상업적 이용 | 수정 | 동일 조건 |
|---|---|---|---|
| CC BY 4.0 | 가능 | 가능 | 불필요 |
| CC BY-SA 4.0 | 가능 | 가능 | 동일 조건 필수 |
| CC BY-ND 4.0 | 가능 | 불가 | — |
| CC BY-NC 4.0 | 불가 | 가능 | 불필요 |
| CC BY-NC-SA 4.0 | 불가 | 가능 | 동일 조건 필수 |
| CC BY-NC-ND 4.0 | 불가 | 불가 | — |
| CC0 1.0 | 가능 | 가능 | 불필요(퍼블릭 도메인) |
3. 깃허브 코드 사용 시 라이선스 체크포인트
3.1 저장소에서 라이선스를 확인하는 방법
- 저장소 루트의 LICENSE 또는 LICENSE.md 파일을 먼저 확인한다. GitHub은 저장소 화면 우측 사이드바에 라이선스 명을 자동으로 표시하며, 클릭하면 전문을 볼 수 있다.
- 라이선스 파일이 없는 경우를 주의해야 한다. 파일이 없다고 해서 자유롭게 사용할 수 있는 것이 아니다. 라이선스 파일이 없으면 기본적으로 모든 권리는 원작자에게 있고, 사용 허락이 없는 상태로 간주해야 한다. 코드를 가져다 쓰려면 원작자에게 직접 허락을 받아야 한다.
- package.json, pyproject.toml, pom.xml 등 패키지 파일에 명시된 라이선스 필드도 확인한다.
- 전이 의존성(Transitive Dependencies)까지 확인해야 한다. npm install로 설치되는 패키지 하나에 수백 개의 하위 의존성이 딸려 오며, 각각 다른 라이선스를 가질 수 있다. license-checker(Node.js), pip-licenses(Python), mvn license:aggregate-download-licenses(Java) 같은 도구로 전체 의존성 라이선스를 일괄 확인할 수 있다.
- Fork한 저장소도 원본 라이선스를 그대로 상속한다. Fork했다고 해서 라이선스 의무가 사라지지 않는다.
3.2 상황별 라이선스 체크 기준
| 사용 상황 | Permissive(MIT/Apache/BSD) | LGPL | GPL | AGPL |
|---|---|---|---|---|
| 내부 도구(배포 없음) | ✅ 자유 | ✅ 자유 | ✅ 자유 | ✅ 자유 |
| 오픈소스 배포 | ✅ 자유 | ✅ 가능(조건부) | ⚠️ 동일 라이선스 필요 | ⚠️ 동일 라이선스 필요 |
| 상업 제품 배포 | ✅ 자유 | ⚠️ 링킹 조건 확인 | ❌ 소스 전체 공개 | ❌ 소스 전체 공개 |
| SaaS 서비스 제공 | ✅ 자유 | ✅ 가능(조건부) | ✅ 가능(배포 아님) | ❌ 소스 전체 공개 |
4. 바이브코딩 유료·무료 배포 시 라이선스 주의점
4.1 바이브코딩이란 무엇인가
바이브코딩(Vibe Coding)은 GitHub Copilot, Cursor, Claude, Windsurf 같은 AI 코딩 도구를 활용해 빠르게 소프트웨어를 만드는 개발 방식이다. 코드를 직접 타이핑하는 비율이 낮고, AI가 자동 완성하거나 통째로 생성하는 비율이 높다는 특징이 있다. 빠른 프로토타이핑에 유리하지만, AI가 생성한 코드가 어떤 오픈소스를 참고·인용했는지 개발자가 직접 파악하기 어렵다는 구조적 문제가 있다.
4.2 바이브코딩에서 발생하는 라이선스 리스크
- AI가 제안하는 코드의 출처 불명확성: GitHub Copilot은 공개된 코드를 학습 데이터로 사용한다. GPL, AGPL 코드도 학습 대상에 포함될 수 있으며, 생성된 코드가 특정 라이선스 코드와 실질적으로 유사할 경우 법적 불확실성이 생긴다. 현재 이에 대한 판례는 형성 중이며, 기업 환경에서는 Copilot for Business처럼 공개 코드 필터링 옵션을 제공하는 버전을 사용하는 것이 더 안전하다.
- 자동으로 추가되는 패키지의 라이선스 미확인: AI 도구가 npm install some-package나 pip install some-library를 제안할 때, 해당 패키지의 라이선스를 자동으로 알려주지 않는다. 개발자가 직접 확인해야 한다.
- 빠른 개발 사이클로 인한 검토 생략: 바이브코딩은 속도가 장점이지만, 그 속도 때문에 라이선스 검토 단계가 생략되는 경우가 많다. 배포 전 반드시 의존성 스캔 단계를 CI/CD 파이프라인에 포함시켜야 한다.
4.3 무료 오픈소스로 배포할 때 주의점
- 사용한 라이선스 중 가장 강한 라이선스가 전체 라이선스를 결정한다: MIT 코드와 GPL 코드를 섞으면 결합물은 GPL을 따라야 한다. 배포 전 가장 강한 라이선스 조건을 파악하고, 그 조건을 전체에 적용해야 한다.
- 무료 배포라도 GPL 조건은 지켜야 한다: 무료 공개라고 해서 GPL 조건이 면제되지 않는다. GPL 코드를 포함하면 소스코드를 함께 공개해야 하고, 동일한 GPL 라이선스를 적용해야 한다.
- 저작권 고지 문구를 삭제하지 않는다: MIT, Apache, BSD 등 모든 Permissive 라이선스는 저작권 고지 유지를 조건으로 한다. UI에서 "Powered by" 문구를 지우거나, 소스코드 헤더의 저작권 주석을 지우면 라이선스 위반이다.
- 라이선스 파일을 배포물에 포함시킨다: 바이너리 배포 시에도 NOTICE, LICENSE 파일을 함께 패키징해야 한다.
- AGPL 포함 여부를 반드시 확인: 무료 오픈소스로 배포하더라도 AGPL 코드를 포함하면 네트워크 서비스로 제공할 때 소스코드 공개 의무가 생긴다. 나중에 상업화하려 할 때 AGPL 조건이 걸림돌이 된다.
4.4 유료 상업 제품으로 판매할 때 주의점
- GPL 계열 코드를 전부 제거하거나 대체해야 한다: 유료 상업 제품에 GPL, LGPL, AGPL 코드를 포함하면 해당 코드와 결합된 전체 소스코드 공개 의무가 발생한다. Permissive 라이선스(MIT, Apache 2.0, BSD)만 사용하거나, 듀얼 라이선스를 통해 별도 상업 라이선스를 구매하는 방식으로 해결해야 한다.
- LGPL은 동적 링킹으로 사용하면 상업 제품에서도 허용: LGPL 라이브러리를 동적 링킹(DLL, .so 파일 방식)으로 사용하면 자체 코드 공개 의무가 없다. 단, LGPL 라이브러리 자체를 수정하면 안 된다.
- Apache 2.0의 특허 조항을 숙지: Apache 2.0은 특허 허용 조항이 있어서, 만약 라이선시(사용자)가 기여자를 상대로 특허 소송을 제기하면 라이선스가 자동으로 종료된다. 자사 특허와 Apache 2.0 코드의 관계를 법무팀과 확인해야 한다.
- BUSL, Elastic License 2.0의 제한 조건 확인: BUSL은 Change Date 전까지 상업적 프로덕션 사용을 제한한다. Elastic License 2.0은 관리형 서비스로 제공하는 것을 금지한다. 경쟁 제품을 만들거나 SaaS로 판매하려는 경우 이 두 라이선스를 사용한 도구가 의존성에 포함됐는지 확인해야 한다.
- AI 생성 코드의 저작권 귀속 문제: 현행 법률상 AI가 생성한 코드의 저작권 귀속은 국가마다 다르게 해석된다. 미국에서는 2023년 이후 판례가 "AI 단독 생성물은 저작권 없음" 방향으로 형성되고 있으며, 인간의 창작적 기여가 있어야 저작권이 인정된다. 상업 제품에서는 이 불확실성을 줄이기 위해 AI 생성 코드를 반드시 사람이 검토하고 수정하는 절차를 두는 것이 좋다.
- 오픈소스 라이선스 스캐너를 CI/CD에 통합: FOSSA, Snyk, Black Duck, Scancode 같은 도구를 빌드 파이프라인에 연결하면 새 의존성이 추가될 때마다 라이선스 위반 여부를 자동으로 검사할 수 있다. 특히 팀이 여러 명이고 바이브코딩 방식으로 빠르게 개발할 때 이 자동화가 리스크를 크게 줄인다.
4.5 라이선스 전략 요약: 어떤 라이선스를 선택할 것인가
| 목적 | 권장 라이선스 | 이유 |
|---|---|---|
| 최대한 자유롭게 공개 | MIT 또는 Apache 2.0 | 사용 제약 최소화 |
| 특허 보호도 필요 | Apache 2.0 | 명시적 특허 허용 조항 |
| 라이브러리, 상용 사용 허용 | LGPL 2.1 | 링킹 사용은 소스 공개 불필요 |
| 오픈소스 기여 강제 | GPL v3 | 수정 코드 전체 공개 강제 |
| SaaS 무임승차 방지 | AGPL v3 | 네트워크 서비스도 공개 의무 |
| 일정 기간 상업 보호 후 오픈소스 | BUSL 1.1 | Change Date 이후 자동 전환 |
| 완전 자유 공개 (저작권 포기) | CC0 또는 Unlicense | 퍼블릭 도메인 |
5. 마무리
위에서 살펴본 소프트웨어 라이선스의 핵심 내용을 정리하면 다음과 같습니다.
핵심 요약:
- 라이선스는 저작권법과 직결되며, 조건을 어기면 무료 코드라도 법적 분쟁 대상이 된다.
- Permissive(MIT, Apache, BSD, ISC)는 저작권 고지만 지키면 상업 제품에도 자유롭게 사용 가능하며, 전체 오픈소스의 절반 이상이 이 유형이다.
- GPL 계열은 전염성이 있어 상업 제품 의존성에 포함되면 전체 소스 공개 의무가 생긴다. 단 LGPL은 동적 링킹이면 예외다.
- AGPL은 SaaS 서비스 제공도 소스 공개 의무를 발생시키므로, 백엔드 서비스에서 AGPL 라이브러리를 사용할 때 각별한 주의가 필요하다.
- 바이브코딩 환경에서는 AI가 자동 추가한 패키지의 라이선스까지 개발자가 직접 확인해야 하며, FOSSA·Snyk 같은 스캐너를 CI/CD에 연결하는 것이 실질적 방어 수단이다.
- 깃허브 저장소에 LICENSE 파일이 없으면 자유 사용이 아니라 사용 금지가 기본값이며, 유료 판매 전에는 반드시 전체 의존성 트리의 라이선스를 점검해야 한다.
상업 소프트웨어를 개발한다면 MIT 또는 Apache 2.0을 기본 기준으로 삼고, GPL 계열은 필요 시 LGPL로 대체하거나 듀얼 라이선스 상업 버전을 구매하는 방식으로 리스크를 관리하는 것이 현실적이다. 라이선스 판단이 불확실할 때는 법무팀이나 오픈소스 전문 변호사의 검토를 받는 것이 가장 안전하다.