GPL 라이브러리를 상용 앱에 썼다가 소스코드를 공개해야 한다고요? — 오픈소스 라이선스의 오해와 진실
MIT부터 AGPL까지, 복잡한 라이선스 결정 트리와 호환성 매트릭스로 법적 리스크를 제거하는 방법
현업에서 개발하다 보면 정말 자주 마주치는 상황이 있어요. 정말 유용한 라이브러리를 찾았는데, 라이선스가 GPL인 거죠. 이때 많은 분이 “어? 이거 쓰면 우리 회사 소스코드 다 공개해야 하는 거 아냐?”라며 겁을 먹거나, 반대로 “오픈소스니까 그냥 공짜겠지” 하고 무심코 가져다 씁니다.
사실 GPL 소프트웨어를 상업적으로 판매하는 것 자체는 아무 문제가 없어요. 다만, 그걸 판매하거나 배포할 때 전체 소스코드와 수정 사항을 사용자에게 제공해야 한다는 강력한 조건이 붙을 뿐이죠 [1].
여기서 우리가 꼭 짚고 넘어가야 할 점이 있어요. 오픈소스 라이선스는 단순히 ‘무료냐 아니냐’의 문제가 아닙니다. ‘어떤 방식으로 배포할 것인가’와 ‘어디까지를 파생물로 볼 것인가’에 따라 내 코드를 공개해야 할 의무가 결정되는 일종의 법적 계약이에요. 이걸 제대로 모르면 나중에 서비스가 커졌을 때 정말 곤란한 상황에 처할 수 있습니다.
왜 우리는 매번 ‘GPL 상용 이용’을 구글링할까
개발자 커뮤니티나 스택 오버플로우를 보면 “GPL을 상용 앱에 써도 되나요?”라는 질문이 끝도 없이 올라옵니다. 왜 그럴까요? 정보가 너무 많아서 그래요. 어떤 블로그에서는 “절대 안 된다”고 하고, 어떤 오래된 스레드에서는 “괜찮다”고 하니 혼란스러울 수밖에 없죠 [2].
사실 가장 큰 오해는 ‘사용’과 ‘배포(Distribution)’의 차이를 구분하지 않는 데서 옵니다. 단순히 내부적으로 사용하거나 서버에서만 돌리는 것과, 설치 파일 형태로 고객에게 전달하는 것은 완전히 다른 이야기거든요. 하지만 Permissive(허용적) 라이선스와 Copyleft(카피레프트) 라이선스라는 용어 자체가 직관적이지 않다 보니, 많은 엔지니어가 매번 구글링의 굴레에 빠지게 됩니다.
실제로 이런 혼란을 해결하기 위해 oss-license-helper 같은 도구를 만든 개발자도 있더라고요. 그분이 남긴 말이 참 공감됐습니다.
“I got tired of Googling ‘Can I use GPL in a commercial app?’ so I built a tool for it”
(상용 앱에 GPL을 써도 되는지 구글링하는 게 지겨워서 직접 도구를 만들었습니다) [1]
결국 우리에게 필요한 건 파편화된 블로그 글이 아니라, “내 상황이 A이고 B라면, 결과는 C다”라고 명확하게 알려주는 결정 트리(Decision Tree) 기반의 가이드라인입니다.
Permissive vs Copyleft: 당신의 코드를 지키는 법
라이선스를 크게 두 진영으로 나누면 ‘허용적(Permissive)’ 진영과 ‘카피레프트(Copyleft)’ 진영으로 볼 수 있어요. 내 소스코드를 닫아두고 싶은지, 아니면 생태계의 공유를 강제하고 싶은지에 따라 선택이 갈립니다.
허용적 라이선스 (MIT, Apache)
MIT 라이선스는 정말 쿨합니다. 저작권 표시만 잘 해주면 파생물을 어떤 조건으로든 라이선스할 수 있어요. 덕분에 상용 제품을 만들면서 소스코드를 꽁꽁 숨겨두고 싶을 때 최적의 선택지가 됩니다 [3, 4].
카피레프트 라이선스 (GPL, AGPL)
반면 GPL은 아주 강력합니다. “내가 공유했으니, 너도 공유해”라는 철학이죠. GPL 코드를 가져와서 수정하거나 결합해 새로운 소프트웨어를 만들었다면, 그 파생물 역시 반드시 동일한 GPL 라이선스로 공개해야 합니다 [3, 5].
여기서 한 단계 더 나간 것이 AGPL입니다. 일반 GPL은 ‘배포’를 해야 공개 의무가 생기지만, AGPL은 네트워크를 통해 서비스를 제공(SaaS)하기만 해도 소스코드를 공개해야 하는 무시무시한(?) 의무가 발생합니다.
절충안 (MPL)
MPL(Mozilla Public License)은 그 중간쯤에 있어요. 파일 단위로 라이선스를 적용하거든요. MPL로 작성된 파일만 공개하면, 그와 결합된 다른 독점 코드베이스는 닫아둘 수 있습니다 [6].
Apache 2.0이 기업용 프로젝트의 표준이 된 결정적 이유
많은 기업이 MIT 대신 Apache 2.0을 선택하는 이유가 뭘까요? 겉보기엔 둘 다 ‘허용적’이라 비슷해 보이지만, 실무적인 ‘법적 안전장치’에서 큰 차이가 납니다.
가장 결정적인 건 바로 ‘명시적인 특허권 부여’입니다. MIT는 특허에 대한 언급이 없어요. 그래서 만약 라이브러리 제작자가 나중에 “사실 이 코드에 내 특허가 들어있으니 사용료를 내라”고 소송을 걸면 법적으로 복잡해질 수 있습니다. 하지만 Apache 2.0은 기여자가 사용자에게 특허 라이선스를 명시적으로 부여합니다. 기업 입장에서는 이런 법적 확실성이 소송 리스크를 줄여주는 엄청난 메리트가 되죠 [7, 4].
또한 Apache 2.0은 사용자가 작성자의 상표를 함부로 사용할 수 없다는 조항을 명시하고 있어, 브랜드 보호 측면에서도 유리합니다 [4]. 기여(Contribution)에 대한 규칙도 더 명확해서, 대규모 협업이 필요한 기업용 프로젝트에서는 사실상 표준처럼 쓰이고 있습니다.
치명적인 함정: 라이선스 호환성과 ‘데스 스파이럴’
라이선스를 하나만 쓰면 편한데, 실제 프로젝트는 수십 개의 라이브러리가 얽혀 있죠. 여기서 ‘호환성’ 문제가 터집니다. 서로 다른 라이선스를 섞어 썼는데, 알고 보니 두 라이선스의 조건이 충돌하는 경우예요.
대표적인 사례가 Apache 2.0과 GPLv2의 관계입니다. Apache 2.0은 특허 조항 때문에 GPLv3와는 잘 지내지만, GPLv2와는 호환되지 않습니다 [4, 8]. 만약 내 프로젝트가 GPLv2 기반인데 Apache 2.0 라이브러리를 깊게 통합했다면, 법적으로 어느 쪽 라이선스도 완전히 만족시키지 못하는 모순된 상태가 될 수 있습니다.
여기서 꼭 기억해야 할 ‘생존 팁’ 하나 드릴게요. “내부 사용(Internal Use)”은 안전합니다. GPL 코드를 수정해서 회사 내부 시스템에서만 쓰고 외부로 배포하지 않는다면, 소스코드를 공개할 의무가 전혀 없습니다 [1]. 문제는 이 코드가 고객의 기기에 설치되거나, AGPL처럼 네트워크 서비스 형태로 제공될 때 시작된다는 점을 잊지 마세요.
실무자를 위한 라이선스 선택 가이드
상황별로 어떤 라이선스를 골라야 할지 고민된다면, 이 기준을 참고해 보세요.
- “최대한 많은 사람이 썼으면 좋겠고, 제약 없이 퍼지길 원한다” $\rightarrow$ MIT [7]
- “기업 간 협업이 중요하고, 특허 소송 리스크를 원천 차단하고 싶다” $\rightarrow$ Apache 2.0 [7]
- “커뮤니티의 개방성을 강제하고, 누구나 기여한 만큼 돌려받게 하고 싶다” $\rightarrow$ GPL [7]
- “SaaS 형태로 서비스하면서도, 소스코드 공개를 통해 공정한 경쟁을 유도하고 싶다” $\rightarrow$ AGPL
- “독점 소프트웨어와 공존하면서도 특정 모듈의 개방성은 유지하고 싶다” $\rightarrow$ MPL [6]
짚고 넘어갈 한계와 안티패턴
가장 흔한 오해 중 하나가 “GPL 소프트웨어는 돈 받고 팔 수 없다”는 거예요. 전혀 아닙니다. GPL 소프트웨어를 얼마에 팔든 그건 자유입니다. 다만, 구매자에게 “여기 소스코드도 같이 드릴게요”라고 해야 할 의무가 있을 뿐이죠 [1].
또 하나, 최근 일부 프로젝트들이 비즈니스 모델 보호를 위해 AGPL이나 SSPL 같은 제한적 라이선스로 전환하는 추세입니다. 언뜻 보면 수익 보호에 유리해 보이지만, 실제로는 기업 고객들이 법적 불확실성 때문에 사용을 꺼리게 되고, 결국 커뮤니티가 파편화되는 리스크를 안게 됩니다 [7].
핵심 요약
- 상용 앱에서 소스코드를 숨기고 싶다면 MIT나 Apache 2.0 라이선스 라이브러리를 우선 고려하세요.
- GPL 라이브러리를 썼다면 ‘배포’ 여부를 확인하세요. 내부 사용은 안전하지만, 외부 배포 시엔 소스 공개 의무가 생깁니다.
- Apache 2.0은 MIT보다 복잡해 보이지만, 기업 환경에서 꼭 필요한 ‘특허 보호’ 조항이 들어있어 더 안전합니다.
- 라이선스 호환성 매트릭스를 통해 의존성 간의 충돌(예: Apache 2.0 $\neq$ GPLv2)이 없는지 꼭 검토하세요.
oss-license-helper같은 결정 트리 도구를 활용해 법적 판단의 기초 근거를 마련하는 습관을 들이세요.
사실 저도 연차 초반에는 라이선스 파일의 LICENSE 텍스트를 읽는 게 세상에서 제일 지루한 일이라고 생각했어요. 하지만 경험이 쌓일수록 느끼는 건, 라이선스 선택이 단순한 행정 절차가 아니라는 점입니다. 내가 만든 코드의 가치를 어떻게 정의하고, 누구와 어떤 방식으로 공유하며 보호할 것인지 결정하는 아주 전략적인 선택이더라고요. 법률 전문가는 아니더라도, 우리 개발자들이 이 기본 원리를 이해하는 것만으로도 팀의 리스크를 획기적으로 줄일 수 있습니다.
참고 자료 (References)
1. [reddit.com] Which License Should I Use? MIT vs. Apache vs. GPL — https://www.reddit.com/r/programming/comments/8ipnif/which_license_should_i_use_mit_vs_apache_vs_gpl 2. [reddit.com] I got tired of Googling “Can I use GPL in a commercial app?” so I built a tool for it — https://www.reddit.com/r/programming/comments/1u7kzyd/i_got_tired_of_googling_can_i_use_gpl_in_a/ 3. [endorlabs.com] Open Source Licensing Simplified: A Comparative Overview of Popular Licenses — https://www.endorlabs.com/learn/open-source-licensing-simplified-a-comparative-overview-of-popular-licenses 4. [soos.io] Apache vs MIT License Comparison – SOOS — https://soos.io/apache-vs-mit-license 5. [wikipedia.org] GNU General Public License — https://en.wikipedia.org/wiki/GNU_General_Public_License 6. [wikipedia.org] Mozilla Public License — https://en.wikipedia.org/wiki/Mozilla_Public_License 7. [credativ.de] Understanding Open Source Licenses: GPL, MIT, Apache Compared — https://www.credativ.de/en/blog/credativ-inside/understanding-open-source-licenses-gpl-mit-apache-compared 8. [opensource.stackexchange.com] What are the practical differences between MIT, Apache and BSD licenses? — https://opensource.stackexchange.com/questions/11109/what-are-the-practical-differences-between-mit-apache-and-bsd-licenses
관련 글 추천
- https://infobuza.com/2026/06/17/20260617-rk68mo/
- https://infobuza.com/2026/06/16/20260616-d47ecq/
FAQ
GPL 라이선스 소프트웨어를 상업적으로 판매할 수 있나요?
네, GPL 소프트웨어를 상업적으로 판매하는 것 자체는 문제가 없습니다. 다만, 판매하거나 배포할 때 전체 소스코드와 수정 사항을 사용자에게 제공해야 한다는 조건이 있습니다.
GPL 라이브러리를 사용했을 때 무조건 소스코드를 공개해야 하나요?
아닙니다. 단순히 내부적으로 사용하거나 서버에서만 돌리는 '내부 사용(Internal Use)'의 경우에는 소스코드를 공개할 의무가 없습니다. 하지만 설치 파일 형태로 고객에게 전달하는 등 '배포'가 이루어질 때 공개 의무가 발생합니다.
MIT 라이선스와 Apache 2.0 라이선스의 가장 큰 차이점은 무엇인가요?
가장 결정적인 차이는 '명시적인 특허권 부여' 여부입니다. MIT는 특허에 대한 언급이 없지만, Apache 2.0은 기여자가 사용자에게 특허 라이선스를 명시적으로 부여하여 기업의 법적 소송 리스크를 줄여줍니다.
AGPL 라이선스는 일반 GPL과 어떻게 다른가요?
일반 GPL은 소프트웨어를 '배포'해야 공개 의무가 생기지만, AGPL은 네트워크를 통해 서비스를 제공(SaaS)하기만 해도 소스코드를 공개해야 하는 의무가 발생합니다.
MPL(Mozilla Public License)의 특징은 무엇인가요?
MPL은 파일 단위로 라이선스를 적용하는 절충안적인 성격을 가집니다. MPL로 작성된 파일만 공개하면, 그와 결합된 다른 독점 코드베이스는 공개하지 않고 닫아둘 수 있습니다.
