이제야 배우는 OSS란 무엇인가? — 무료함 뒤에 숨겨진 10가지 규칙과 AI 시대의 불씨

「OSS란, 결국 공짜로 쓸 수 있는 소프트웨어를 말하는 거지?」

엔지니어라면 한 번쯤 입 밖으로 내뱉었다가, 베테랑에게 진지한 표정으로 정정당당하게 교정받은 경험이 있을 것이다. 나 또한 젊은 시절에 "소스 코드가 공개되어 있으면 OSS 아닌가요"라고 호기롭게 말했다가, 선배로부터 조용히 고개를 저음 당했던 적이 있다… orz

OSS는 「공짜 소프트웨어」가 아니다. OSS란, 레시피를 공개한 요리책이라고 생각해주길 바란다. 요리(=작동하는 소프트웨어)뿐만 아니라, 그 만드는 법(=소스 코드)까지 통째로 공개하고, 게다가 「자유롭게 만들어도 좋고, 자신만의 스타일로 어레인지해서 배포해도 좋다」라는 명확한 약속(라이선스, License)이 세트로 되어 있다. 이 기사에서는 그 「약속」을 요리책의 메타포(Metaphor)를 통해 일관되게 풀어내고자 한다.

본 기사는 2026년 6월 시점의 1차 정보(OSI 공식 정의 등)를 바탕으로 합니다. 라이선스는 시대와 함께 변하는 「생물」입니다. 최신 정보는 반드시 공식 사이트를 확인해 주세요.

• OSS를 사용하고는 있지만, 라이선스의 내용을 읽어본 적이 없는 사람

• MIT, GPL, Apache의 차이를 분위기로만 이야기하는 사람

• LLM을 「오픈 소스 모델(Open Source Model)」이라고 불러도 될지 망설였던 적이 있는 사람

• OSS의 정체(공짜가 아닌 「자유」에 관한 이야기)를 확실히 이해할 수 있다

• OSI가 정한 10가지 규칙과 라이선스 선택의 지도를 얻을 수 있다

• AI 시대의 「오픈 웨이트(Open Weights)」와 「오픈 소스(Open Source)」의 차이를 알 수 있다

• xz 사건으로 대표되는 「OSS의 그림자」에 대한 해상도가 높아진다

• 개별 라이선스의 조문 해설 (변호사의 영역입니다)

• 자사 프로덕트의 라이선스 선정에 대한 최종 판단 (법무팀에 상담하세요)

먼저, 세상에 만연한 두 가지 큰 오해를 성불시켜 보자.

흔한 오해	실제로는
「무료니까 OSS」	무료 여부는 무관함. OSS를 유상으로 판매해도 됨
「소스가 보이면 OSS」	소스 공개만으로는 불충분함. 배포 조건이 정의를 충족해야 함

레시피 북의 비유로 말하자면 다음과 같다.

무료로 배포할지 여부는 가게의 판단이다. OSS 레시피 북을 제본해서 팔아도 전혀 문제없다. -
레시피를 읽을 수 있는 것만으로는 「요리책」이라 부를 수 없다. 「이 레시피로 만든 요리를 팔면 안 된다」라고 적혀 있다면, 그것은 그저 "보기만 하는 메뉴"일 뿐, 진짜 요리책이 아니다.

이러한 경계선을 누가 어떻게 결정하고 있는가. 그것을 정한 것이 다음의 「10가지 규칙」이다.

OSS의 정의를 세계 표준으로 관리하고 있는 곳이 OSI (Open Source Initiative)라는 비영리 단체다. 1998년에 Bruce Perens와 Eric S. Raymond 등이 설립하였으며, Debian Free Software Guidelines를 바탕으로 한 **The Open Source Definition (OSD)**를 공개하고 있다.

OSD는 어떤 라이선스가 「OSS라고 자칭해도 되는가」를 판정하기 위한 10가지 기준을 정하고 있다. 요리책으로 치환하면 다음과 같은 10개 조항이다.

#	규칙 (OSD)	레시피 북으로 치면
1	자유로운 재배포	이 레시피 북은 누구에게 배포해도 좋고 팔아도 좋다
...
여기서 제6조가 그야말로 "OSS답다". 일부러 원문과 번역을 함께 두겠다.

원문 (OSD 제6조 제목): No Discrimination Against Fields of Endeavor

번역: 이용 분야에 대한 차별을 해서는 안 된다

출처: OSI 공식 The Open Source Definition (후술하는 참고문헌에 링크 카드가 있음)

즉 「군사 이용은 안 됨」, 「악인은 사용하지 마라」와 같은 제한조차 OSS의 정의상으로는 붙일 수 없다. 자유를 모두에게 준다는 것은, 마음에 들지 않는 상대에게도 준다는 것이다, 라는 OSI의 강직한 사상이 여기에 나타나 있다.

10개 조항은 테마별로 4개 그룹으로 정리하면 기억하기 쉽다.

전절에서 「배포 조건이 정의를 충족하는가」가 OSS의 갈림길이라고 언급했다. 그 「배포 조건」을 실제로 문장화한 것이 다음에 이야기할 **라이선스 (License)**이다.

라이선스란, 레시피 북의 첫 페이지에 적힌 이 레시피의 사용법에 관한 약속이다. 세상에는 무수히 많은 OSS 라이선스가 있지만, 성격에 따라 크게 두 파벌로 나뉜다.

퍼미시브 (Permissive, 관용) 계열: MIT / BSD / Apache 2.0

• 「내 이름만 적어준다면, 그 뒤로는 끓이든 굽든 마음대로 해라」

• 개정판을 비공개로 해도 좋다 (Proprietary, 독점 소프트웨어화 가능)

• 카피레프트 (Copyleft) 계열: GPL / AGPL

• 「내가 만든 레시피로 만든 요리는, 그 레시피도 반드시 공개해줘」

• 개량판도 동일한 조건으로 공개할 의무가 있음 (전염성)

「그럼 내가 공개하는 입장이라면 무엇을 선택할까?」를 지도로 나타내면 다음과 같다. 이것은 우열을 비교하는 것이 아니라, 목적별 선정 가이드로서 읽어주길 바란다.

대표적인 면면을 요약표로 정리해 두었다.

라이선스	계통	개량판 공개 의무	한마디로 말하면
MIT	퍼미시브 (Permissive)	없음	어쨌든 매우 완만함. 고민된다면 이것
...	...	...	...

여기까지는 「약속 사항은 고정되어 있다」는 전제로 이야기해 왔다. 하지만 현실의 라이선스는 기업의 사정에 따라 수시로 변하는 생물이다. 그 생생한 실례가 바로 다음의 Redis 극장이다.

레시피 북의 출판사가 어느 날 갑자기 「다음 달부터 우리 레시피로 가게를 여는 것은 금지합니다」라고 규약을 바꾼다면? 단골 요리사들은 격분하고, 일부는 노렌와케 (Norenwake, 분가/Fork) 하여 독립한다. 이것이 바로 2024~2025년에 Redis에서 일어난 일이다.

사건의 발단은 AWS 등의 클라우드 대기업이 Redis를 매니지드 서비스 (Managed Service)로 제공하며 이익을 흡수해 가는 구도였다. Redis사는 2024년 3월, 관대한 BSD에서 SSPLv1/RSALv2라는 "소스 어베일러블 (Source Available)" 라이선스로 전환하며 클라우드 기업들에게 과금을 요구했다.

그런데 이 SSPL은 OSI 비승인, 즉 「OSS라고 자칭할 수 없는 라이선스」다. 커뮤니티는 반발했고, AWS·Google·Oracle이 뒷받침이 되어 Valkey라는 노렌와케 (Fork)가 탄생했다. 원래의 BSD 라이선스를 계승한 Valkey는 순식간에 지지를 모았다.

결국 Redis사는 1년 만에 백기를 들었고, 2025년 5월의 Redis 8에서 OSI 승인 라이선스인 AGPLv3를 추가하며 OSS로 "복귀"했다. Redis의 창시자인 antirez 씨는 자신이 쓰는 코드는 오픈 소스여야만 직성이 풀린다는 취지의 이야기를 열정적으로 하고 있다. 반면 「이미 때가 늦었다」, 「Valkey로 옮긴 사람은 돌아오지 않는다」라는 냉담한 목소리도 많아, 커뮤니티의 신뢰를 한 번 잃는 대가가 얼마나 큰지를 보여준다.

이 사건의 교훈은 단순하다. OSS의 라이선스는 기업의 판단에 따라 변할 수 있다. 그렇기에 공통 언어인 OSI 정의와 최종 수단인 포크 (Fork)가 커뮤니티의 안전장치 역할을 한다.

자, 이제부터가 이 글의 백미다. 로컬 LLM (Local LLM)을 만지다 보면 반드시 이 의문에 부딪히게 된다.

「HuggingFace에서 내려받은 이 모델, "오픈 소스"라고 불러도 될까?」

답을 먼저 말하자면, 대부분의 경우 안 된다. 그것들은 「오픈 소스」가 아니라 「오픈 웨이트 (Open Weights)」인 경우가 대부분이다.

OSI는 2024년 10월 28일, Open Source AI Definition 1.0 (통칭 OSAID) 을 공개했다. AI를 레시피 북에 비유하면 구성 요소는 다음과 같다.

모델의 가중치 (Weights, 파라미터) = 완성된 비법 소스 -
학습 코드 · 추론 코드 = 소스 만드는 법 · 불 조절 메모 -
학습 데이터 = 소스의 재료와 배합

OSAID 1.0이 「오픈 소스 AI」로 인정하기 위해서는, 가중치와 코드를 공개하고, 나아가 학습 데이터에 대해 "충분히 상세한 정보"를 공개할 것을 요구한다.

원문 (OSAID 1.0 / 학습 데이터 요구사항의 핵심): so that a skilled person can build a substantially equivalent system

의역: 기술에 능숙한 사람이 실질적으로 동등한 시스템을 구축할 수 있는 정도로 (정보를 공개할 것)

출처: OSI 공식 The Open Source AI Definition 1.0

포인트는, 학습 데이터 그 자체를 공개하는 것까지는 필수 사항이 아니라는 점이다 (프라이버시나 권리 관계를 고려하여). 하지만 「동등한 제품을 재현할 수 있는 설명」은 필요하다.

여기서 많은 공개 모델이 탈락한다. MIT나 Apache 2.0 라이선스로 배포되고 있더라도, 그것은 「소스는 나눠줄게, 하지만 만드는 법은 비밀이야」라는 상태 ―― 즉 오픈 웨이트 (Open Weights) 에 불과하다.

llama.cpp나 vLLM과 같은 추론 엔진 (Inference Engine) 자체는 당당한 OSS이다. 하지만 그 위에서 구동되는 GGUF 모델이 "오픈 소스인가"는 별개의 문제이며, 이것이 AI 시대의 새로운 불씨이다. "우리 모델은 오픈 소스"라는 홍보 문구를 본다면, 우선 가중치(Weights)·코드·데이터의 공개 상황을 확인하는 습관을 들여야 한다.

OSS의 이상은 아름답다. 하지만 그림자도 있다. 2024년 3월에 발각된 xz Utils 백도어 사건 (CVE-2024-3094, CVSS 스코어 최대치인 10.0)은 OSS의 구조적인 약점을 세상에 드러냈다.

요리책으로 비유해 보자. 전 세계 주방에서 사용되는 스테디셀러 요리책이 있었다. 하지만 그 편집을 지탱하고 있었던 것은 단 한 명의, 지칠 대로 지친 자원봉사 요리사 (실존 인물 Lasse Collin 씨)였다.

그때 "Jia Tan"이라고 자칭하는 인물이 나타난다. 2년에 걸쳐 선량한 개선 제안을 지속하며 요리사의 신뢰를 얻었고, 마침내 공동 편집자의 자리에 올랐다. 그리고 때를 기다려 ―― 요리책에 몰래 독 (백도어)을 심은 것이다 (;ﾟдﾟ)ﾎﾟｶｰﾝ

이 백도어는 특정 키를 가진 공격자에게 OpenSSH를 통한 원격 코드 실행 (Remote Code Execution)을 허용하는 물건이었다. 거의 모든 Linux 배포판이 오염되기 직전, Microsoft의 엔지니어 Andres Freund 씨가 "SSH 로그인이 0.5초 정도 느리다"는 위화감을 통해 우연히 발견했고, 세상은 간발의 차로 구원받았다.

이 사건의 본질은 기술이 아니라 메인테이너 (Maintainer)의 지속 가능성입니다. 인프라급 OSS가 보상 없는 소수의 자원봉사자에 의해 지탱되고 있는 현실이 소셜 엔지니어링 (Social Engineering)의 좋은 표적이 되었습니다. 당신이 무료로 사용하고 있는 라이브러리 뒤에는 번아웃 직전의 요리사가 있을지도 모릅니다.

OSS는 "모두의 것"이지만, "모두가 돌봐주는 것"은 아니다. 사용하는 것에 그치지 않고, Issue 보고·기부·작은 PR을 통해 요리사를 지원하는 측에 서는 것 ―― 그것이 이 사건으로부터 우리가 배워야 할 교훈이다.

증상·오해	원인	대처법
"무료니까 OSS"라고 생각함	자유 (freedom)와 무료 (free)의 혼동	OSS의 "free"는 「자유」임을 이해하고, 유상 OSS도 존재함을 인지한다
...	...	...

OSS와의 관계는 「사용하기 → 기여하기 → 운영하기」의 3단계 로켓을 통해 깊어진다.

초급: 우선 평소 사용하는 Python이나 JavaScript 라이브러리의 LICENSE 파일을 열어본다. 이것만으로도 세상이 달라진다. -
중급: 오타 수정 정도면 충분하다. 첫 번째 PR을 제출해 보자. 요리사는 사소한 기여일수록 기뻐한다. -
상급: 자신의 리포지토리(Repository)에 라이선스를 부여하고 커뮤니티를 육성한다. Redis 극장의 당사자 의식이 싹튼다.

용어	의미
OSS	Open Source Software. OSD 준수 라이선스로 배포되는 소프트웨어
...	...

• OSS는 「무료」가 아니라 「자유」에 관한 이야기다. 유상 OSS도 존재한다.
• 소스 공개만으로는 불충분하며, OSI 정의의 10가지 규칙을 충족해야 비로소 OSS라고 부를 수 있다.
• 라이선스는 허용적 (Permissive) vs 카피레프트 (Copyleft) 두 파벌로 나뉜다. 목적에 따라 선택한다.
• 라이선스는 살아있는 생물이다. Redis 극장이 보여주듯 기업의 사정에 따라 변하며, 커뮤니티는 포크 (Fork)로 대항한다.
• AI 시대는 **오픈 웨이트 (Open Weights) ≠ 오픈 소스 (Open Source)**이다. OSAID가 새로운 척도가 되었다.
• xz 사건이 보여주듯, OSS의 이상은 메인테이너의 헌신에 의해 지탱되고 있다. 사용하는 것을 넘어 지원하는 측으로.

솔직히 고백하자면, 나 자신도 이 글을 쓰기 전까지는 「오픈 웨이트」와 「오픈 소스」를 대충 동일시했었다. 레시피를 공개하는 문화에 이토록 깊은 사상과 생생한 공방이 담겨 있을 줄이야 ―― OSS, 너무 깊어서 놀랍다 (草). 무료로 사용하게 해주는 요리사들에게 다시 한번 감사를 표한다.

[The Open Source Definition (OSI 공식 · 10개 조항 원문)]

[The Open Source AI Definition 1.0 (OSI 공식 · AI 버전 정의)]

[Redis is now available under the AGPLv3 open source license (Redis 사 공식 라이선스 페이지)]

[XZ Utils backdoor / CVE-2024-3094 (사건 개요)]

최신 AI · GPU · OSS 정보는 X에서도 발신하고 있습니다.