제9부 사업·전략·법·윤리

9.2 오픈소스·라이선스 생태계

"우리 서비스에 오픈 모델을 쓰자." 회의실에서 이 문장이 나오는 순간, 방 안의 절반은 서로 다른 것을 상상한다. 누군가는 "가중치를 받아 우리 GPU에서 돌린다"를, 누군가는 "공짜니까 마음대로 팔아도 된다"를, 또 누군가는 "리눅스처럼 소스가 다 열려 있으니 우리가 원하는 대로 고쳐 재배포한다"를 떠올린다. 세 상상은 전부 "오픈"이라는 한 단어에서 갈라져 나오는데, 서로 다르고, 뒤의 둘은 대체로 틀렸다. 그 어긋남을 회의 시점에 다루지 못하면, 반년 뒤 라이선스 조항 한 줄 때문에 서비스 아키텍처를 전면 재설계하거나, 실사 나온 투자자 앞에서 컴플라이언스 구멍을 자백하게 된다.

이 장이 남기려는 문장은 둘이다. 첫째, "오픈"은 하나가 아니라 두 개의 독립된 축이다 — 무엇이 공개됐는가(투명성·재현성)와 그것으로 무엇을 해도 되는가(권리)는 별개다. 많이 공개된 모델이 권리는 좁을 수 있고, 거의 공개하지 않은 모델이 권리는 넓을 수 있다. 둘째, 라벨이 아니라 라이선스 원문이 계약이다. "오픈 소스"라고 홍보하는 페이지 상단의 헤드라인이 아니라, 그 아래 놓인 조항 하나하나가 당신이 서명하는 것이다. 그리고 "오픈"이라는 라벨이 붙었다고 제약이 없는 것도 아니다 — 오히려 오늘날 유명한 오픈 모델 상당수는 제공자가 직접 쓴 맞춤 계약을 달고 나오며, 그 안에는 규모 상한·용도 금지·증류 제한이 명시되어 있다.

이 장은 그 두 축을 분해하는 법, 라이선스를 네 부류로 갈라 판정하는 법, 그리고 "이 모델을 우리 서비스에 써도 되는가"를 논리곱으로 직접 계산하는 법을 세운다. 등장하는 모델명·계열·조항·수치는 전부 지도를 그리기 위한 예시이자 특정 시점의 스냅숏이며, 오픈 생태계는 몇 달 단위로 새 계열과 새 라이선스 개정이 잇따른다. 그러니 목표는 "지금 무엇이 1등이고 어떤 라이선스다"를 외우는 것이 아니라, 어떤 모델을 만나든 그것을 두 축으로 분해하고 조항을 논리곱으로 판정하는 방법을 손에 쥐는 것이다.

9.2.1 "오픈 웨이트"는 "오픈 소스"가 아니다

가장 먼저 깨야 할 것은 "오픈 모델 = 오픈 소스 소프트웨어"라는 등식이다. 소프트웨어에서 "오픈 소스"에는 수십 년 묵은 정의가 있다. Open Source Initiative(OSI)의 정의는 소스 코드가 공개될 것, 자유롭게 사용·수정·재배포할 수 있을 것, 특정 개인·집단·활동 분야를 차별하지 않을 것을 요구한다. 이 정의의 핵심은 "소스가 있으니 원리상 누구나 처음부터 빌드할 수 있다"는 재현 가능성이다. 그런데 오늘날 "오픈"이라 불리는 대형 언어모델 대다수는 이 정의를 엄밀히는 만족하지 않는다. 그래서 더 정확한 이름이 오픈 웨이트(open weights) 다 — "학습이 끝난 가중치 파일을 받아 돌릴 수 있게 공개했다"는 뜻이지, "그 소스가 오픈 소스 정의를 충족한다"는 뜻이 아니다.

왜 다른지는 언어모델 하나를 "완전히 재현"하는 데 필요한 재료를 늘어놓으면 분명해진다. 가중치는 학습이 끝난 파라미터로, 이것만 있으면 추론은 실행할 수 있다. 추론 코드·아키텍처는 그 가중치를 실행하는 모델 구조 정의로, 대개 함께 또는 표준 라이브러리로 공개된다. 학습 코드는 그 가중치를 애초에 어떻게 만들었는가 — 전처리·학습 루프·하이퍼파라미터·데이터 스케줄이다. 학습 데이터는 무엇으로 학습했는가 — 데이터의 구성·출처·필터링·중복제거 레시피다. 그리고 이 모든 재료를 무엇에 어떻게 써도 되는가를 규정하는 라이선스가 있다.

오픈 웨이트 모델은 보통 앞의 둘, 즉 가중치와 추론 코드만 공개하고, 학습 데이터와 정확한 학습 레시피는 비공개로 둔다. 즉 "받아서 쓸 수는 있지만, 처음부터 다시 만들 수는 없는" 상태다. 소프트웨어에 빗대면 이것은 소스 코드 배포가 아니라 컴파일된 바이너리 배포에 가깝다 — 가중치는 학습이라는 "컴파일"의 산출물이고, 데이터와 레시피가 그 소스에 해당하는데 그 소스는 닫혀 있다. 다만 순수 바이너리보다는 열려 있다. 파인튜닝으로 그 "바이너리를 이어서 학습"해 개조할 수 있고, 양자화해 다시 패키징할 수도 있기 때문이다. 이 어중간함 — "받아서 돌리고 개조는 되지만 원점에서 재현은 안 되는" 상태 — 이 "오픈 웨이트 ≠ 오픈 소스"의 실체다.

업계는 이 구분을 흐린 채 "오픈 소스 모델"이라는 말을 느슨하게 남발한다. 마케팅과 관행이 그렇게 굳었으니 그 표현 자체를 탓할 필요는 없다. 다만 그 라벨을 근거로 삼는 순간이 위험하다. "오픈 소스라고 했으니 마음대로 써도 되겠지"는 두 겹으로 틀린 추론이다 — 첫째로 그 모델은 대개 실제 오픈 소스 정의를 충족하지 않고, 둘째로 설령 충족하더라도 "무엇을 공개했나"와 "무엇을 허용하나"는 별개 축이기 때문이다. 한편 일부에서는 "재현에 필요한 데이터·코드·가중치를 모두 공개해야 진짜 오픈 소스 AI"라는 더 엄격한 정의를 밀고 있는데, 그 정의를 충족하는 대형 모델은 지금으로선 소수다. 정의 자체가 아직 논쟁 중이라는 사실이야말로, "오픈"이라는 단어에 하나의 고정된 의미를 기대하면 안 된다는 방증이다.

9.2.2 공개 범위와 라이선스 허용은 직교한다

"오픈이냐 폐쇄냐"는 스위치가 아니라 연속적인 스펙트럼이다. 한쪽 끝은 "API로만 접근하고 가중치는 절대 못 보는" 완전 폐쇄, 반대쪽 끝은 "가중치·학습 코드·데이터·레시피가 모두 공개돼 원점에서 재현 가능한" 완전 개방이고, 실제 모델은 거의 다 그 사이에 있다. 이 축 위에 모델을 놓아 두면 어떤 모델을 만나든 "이건 어디쯤인가"를 물을 수 있다.

여기서 이 장 전체를 뒷받침하는 관찰이 나온다. 공개 범위와 라이선스 허용은 서로 직교하는 별개의 축이다. 축 1은 "무엇을 받았는가"로 투명성·재현성의 문제이고, 축 2는 "받은 것으로 무엇을 해도 되는가"로 권리의 문제다. 이 둘은 같이 움직이지 않는다. 네 조합이 전부 실재한다. 데이터·코드·가중치를 다 공개(축 1 최고)하면서 "연구 목적만, 상업 금지"(축 2 최저)일 수 있고, 데이터는 철저히 비공개(축 1 낮음)이면서 Apache 2.0으로 "상업·재배포 자유"(축 2 최고)일 수 있다. 학술 컨소시엄이 투명성을 자랑하며 낸 모델이 정작 상업 사용을 막고, 상업 기업이 데이터 한 줄 안 밝히고 낸 가중치가 마음껏 팔아도 되는 경우가 나란히 존재한다.

이 직교성이 실무에서 갖는 무게는 크다. 사람들은 "이 모델 기술 보고서가 이렇게 상세하고 투명한데 설마 못 쓰게 하겠어"라고 축 1의 인상으로 축 2를 추정하는데, 그 추정은 근거가 없다. 반대로 "데이터도 안 밝히는 걸 보니 폐쇄적이고 제약이 많겠지"도 틀릴 수 있다. 도입을 실제로 막는 것은 대개 축 1이 아니라 축 2다 — 가중치를 손에 쥐고도, 라이선스가 당신의 용도를 금지하면 그 가중치는 당신에게 쓸모가 없다. 그러니 두 축을 반드시 따로 물어야 한다. "얼마나 공개됐나"와 "우리가 무엇을 해도 되나"는 서로의 답이 아니다.

9.2.3 오픈웨이트 계열의 지형

이제 실제 계열들을 지도 위에 배치한다. 아래는 큰 그림을 파악하기 위한 예시 목록이며, 순위·우열·최신성을 단정하지 않는다. 각 계열의 세대·라이선스·공개 범위는 버전마다 시점마다 바뀌므로, 특정 모델을 도입할 때는 반드시 그 버전의 원문을 다시 확인해야 한다. 여기서 배울 것은 "누가 최고냐"가 아니라 "이런 종류의 제공자와 이런 종류의 라이선스가 세상에 있다"는 지형 파악이다.

이 표에서 외울 것은 개별 셀이 아니라 세 가지 패턴이다. 첫째, 제공자 유형에 따라 라이선스 경향이 갈리되, 그것은 경향일 뿐 법칙이 아니다. 상업적 대형 플랫폼은 "가중치는 열되 대규모 경쟁 사용은 조인다"는 커뮤니티 라이선스 쪽으로, 연구·비영리 계열은 관대형·완전 개방 쪽으로 기우는 경향이 관찰된다. 그러나 예외가 흔하고 버전마다 뒤집힌다. 경향으로 예단하면 사고가 난다.

둘째, 한 계열 안에서도 모델마다 라이선스가 다르다. "Mistral은 Apache다"처럼 브랜드로 뭉뚱그리면 틀린다 — 같은 브랜드가 어떤 모델은 관대한 라이선스로, 어떤 모델은 자체 상용 라이선스로 낸다. 라이선스는 브랜드 단위가 아니라 모델 단위, 심지어 같은 모델의 버전·크기 단위로 확인해야 하는 대상이다. 어제 Apache였던 계열이 다음 세대에서 커뮤니티 라이선스로 바뀌기도 하고, 그 반대도 있다.

셋째, "무엇이 공개되나"와 "라이선스"는 별개다 — 앞 절의 두 축이 이 표에서 그대로 확인된다. 기술 보고서가 상세하다고(투명성 높음) 라이선스가 관대한 것은 아니고, 라이선스가 관대하다고 데이터를 공개한 것도 아니다. 그러니 이 책은 어떤 계열도 추천하거나 서열화하지 않는다. 의미 있는 질문은 오직 하나, "당신의 그 용도에 그 버전의 라이선스가 맞는가"뿐이다.

9.2.4 라이선스 네 부류 — 관대형·커뮤니티·비상업·연구전용

라이선스를 네 부류로 나누면 대부분의 오픈 모델을 분류할 수 있다. 부류마다 "무엇을 근본적으로 제약하는가"가 다르고, 그 차이가 도입 가능 여부를 가른다.

9.2.4.1 관대형 — Apache 2.0과 MIT

소프트웨어 세계에서 그대로 건너온, 가장 자유로운 부류다. 상업 이용·수정·재배포·파인튜닝·증류가 원칙적으로 모두 허용되고, "이걸로 돈 벌지 마라", "이 용도로는 쓰지 마라" 같은 용도 제한이 없다. 의무 부담은 작다 — 대개 저작권·라이선스 고지를 유지하는 정도다. 도입 판단이 가장 단순한 부류이며, 실제 오픈 소스 정의에 가장 가깝다.

Apache 2.0과 MIT의 차이는 실무에서 종종 무시되지만 특허를 다루는 조직에는 중요하다. MIT는 저작권 고지 유지만 요구하는 극도로 짧은 라이선스로, 특허에 대해서는 침묵한다. Apache 2.0은 여기에 명시적 특허 라이선스 부여를 더한다 — 기여자가 자신의 관련 특허를 사용자에게 무상 허락한다. 그리고 특허 소송 방어 종료 조항이 붙어, 만약 당신이 이 소프트웨어에 대해 특허 소송을 걸면 당신에게 부여됐던 특허 라이선스가 종료된다. 즉 Apache 2.0은 "특허로 서로 찌르지 말자"는 상호 방어를 내장한 반면 MIT는 그런 장치가 없다. 특허 리스크가 신경 쓰이는 큰 조직은 이 한 조항 때문에 Apache 쪽을 선호하기도 한다. 어느 쪽이든 실무 원칙은 같다 — 고지만 지키면 대체로 된다.

9.2.4.2 커뮤니티 라이선스 — 상업 허용하되 조건부

가장 오해가 많고, 실무 사고가 가장 자주 나는 부류다. 이름에 "커뮤니티"나 "오픈"이 붙어 자유로워 보이지만 실제로는 제공자가 직접 쓴 맞춤 계약이며, 표준 오픈 소스 라이선스가 아니라 그 제공자만의 조항 묶음이다. 상업 사용을 열어 주되 여러 제한을 함께 적용한다. 대표적인 네 갈래의 제한이 있다.

규모 상한이 첫째다. 예컨대 "월간 활성 사용자가 특정 임계를 넘는 사업자는 별도 상업 라이선스를 받아야 한다"는 조항이다. 대부분의 스타트업에는 무해하지만 초대형 사업자에게는 사실상 상업 금지로 작동한다. 이 조항의 함정은 시한폭탄이라는 데 있다 — 지금은 안 걸려도 성장하면 어느 날 걸린다(9.2.6에서 그 시점을 계산한다). 허용 사용 정책(Acceptable Use Policy, AUP) 부속이 둘째다. 무기·불법·특정 위험 용도를 금지하는 별도 정책이 라이선스에 딸려 오고, 이 정책을 어기면 곧 라이선스 위반이다. AUP는 라이선스 본문과 다른 문서에 있을 때가 많아 놓치기 쉽다. 파생물 명명·귀속 의무가 셋째다 — "이 모델로 만든 파생 모델 이름에 특정 접두어를 넣어라", "'Built with X'를 표기하라" 같은 요구가 붙는다. 출력물로 타 모델을 학습하는 것에 대한 제한(증류 제한)이 넷째로, "이 모델의 출력을 다른 대형 언어모델을 개선·학습하는 데 쓰지 마라"는 조항이 들어 있을 수 있다(9.2.7에서 따로 다룬다).

요컨대 커뮤니티 라이선스는 "상업적으로 써도 되지만, 제공자가 그은 선 안에서만"이다. 헤드라인의 "상업 가능" 뒤에 예외가 줄줄이 붙는 구조라, 이 부류는 도입 전에 조항을 한 줄씩 읽어야 하는 대상이다. 헤드라인이 아니라 본문이 계약이다.

9.2.4.3 비상업 — 상업적 사용 금지

연구·개인·평가에는 자유롭지만 상업적 사용을 금지하는 부류다(대표적으로 CC BY-NC 계열이나 자체 비상업 라이선스). 프로토타입·벤치마크·논문 재현에는 쓸 수 있어도, 그 모델을 돈 받는 서비스에 넣는 순간 위반이다. 실무에서 가장 흔한 사고 지점이 바로 여기다 — "개념 증명(PoC)이 잘 됐으니 그대로 프로덕션에 올리자"는 결정. 비상업 모델로 만든 PoC는 프로덕션으로 넘어가지 못한다. 능력을 확인하는 데까지가 그 모델의 역할이고, 서비스에는 다른 라이선스의 모델을 써야 한다. "상업"의 경계도 생각보다 넓다는 점을 유의해야 한다 — 유료 서비스뿐 아니라 광고 기반 무료 서비스, 사내 업무 자동화, 상업 제품의 부속 기능도 관할·해석에 따라 상업으로 볼 수 있다.

9.2.4.4 연구 전용 — 배포 자체 불가

비상업보다 한 칸 더 좁다. 연구 목적 사용만 허용하고 서비스로의 배포 자체를 금지한다. 초기 프리뷰나 특정 규모 이상 모델의 제한 공개에서 종종 보인다. 이런 모델은 아이디어 검증·내부 실험용으로만 봐야 하며, 어떤 형태로든 외부에 제공되는 서비스에 추가하면 안 된다.

네 부류 어느 것에나 "오픈"이라는 라벨이 붙을 수 있다는 사실을 마지막으로 명시해 둔다. 축 1에서 가중치를 공개했다는 이유만으로 넷 다 "오픈 모델"로 홍보될 수 있지만, 축 2에서 ②·③·④는 당신의 용도를 금지할 수 있다. 라이선스 파일의 실제 문구가 유일한 근거이고, 그 문구는 개정된다. 특정 버전에 대해 확인하고 그 파일을 증적으로 보관해 두어야 한다.

9.2.5 "오픈"이 실제 허용하는 것 — 허용 매트릭스와 논리곱

부류를 행동 단위로 다시 정리하면 도입 판단이 명확해진다. 실제로 물어야 하는 질문은 다섯 개다. 상업 서비스에 쓸 수 있나, 수정(파인튜닝)해도 되나, 재배포해도 되나, 산출물(출력)을 자유롭게 써도 되나, 그 출력으로 다른 모델을 학습해도 되나(증류). 부류별 전형적 답을 표로 요약하되, 어디까지나 전형이며 개별 라이선스가 이를 뒤집을 수 있다는 점을 전제한다.

이 매트릭스는 논리 연산으로 읽어야 실전에서 안전하다. "우리 서비스에 이 모델을 써도 적법한가"는 필요한 권리들의 논리곱, 즉 전부 참이어야 참이 되는 조건이다.

$$ \text{적법} \;=\; \text{상업허용} \,\land\, \text{파인튜닝허용} \,\land\, \text{재배포조건충족} \,\land\, \text{규모·AUP충족} \,\land\, \text{산출물·증류허용} $$

어느 한 항이라도 거짓이면 전체가 거짓이다. "대부분 허용되니까 되겠지"는 성립하지 않는다 — 다섯 중 넷이 허용돼도 나머지 하나가 당신의 용도를 막으면 서비스 전체가 막힌다. 그래서 실무 관점은 "허용되는 것을 세는" 쪽이 아니라 "금지되는 것이 하나라도 우리 용도에 걸리는가"를 세는 쪽이다. 관대한 라이선스에서 넘어지는 경우는 드물다. 사고는 언제나 "상업 가능"이라는 헤드라인만 보고 그 밑의 규모 상한이나 증류 제한을 못 본 데서 난다. 표에서 "조건부"라고 적힌 칸은 전부 "여기서 원문을 펴라"는 신호다. 그 조건이 당신에게 유리하게 풀릴지 불리하게 풀릴지는 헤드라인이 아니라 조항이 정한다.

9.2.6 규모 상한은 언제 발동하나 — 수계산

커뮤니티 라이선스의 규모 상한이 왜 시한폭탄인지는 숫자를 넣어 보면 분명해진다. 이 조항은 도입 시점에 거의 항상 무해해 보이기 때문에 무시되는데, 바로 그 "지금은 무해함"이 함정이다.

가상의 상황을 상정하자. 우리 서비스는 지금 월간 활성 사용자(MAU) 500만 명이고, 커뮤니티 라이선스에는 "MAU 7억 명을 넘는 사업자는 별도 상업 라이선스를 받아야 한다"는 조항이 있다(임계값과 대상 범위는 라이선스·버전마다 다르므로 여기서는 계산을 보이기 위한 예시 수치다). 500만은 7억의 0.7%에 불과하니 "우리랑 무관한 조항"으로 넘기기 쉽다. 그런데 서비스가 잘돼서 MAU가 월 15%씩 늘어난다고 하자. 상한에 언제 닿는가.

복리 성장이므로 $n$ 개월 뒤 MAU는 $5{,}000{,}000 \times 1.15^{n}$ 이다. 이것이 7억에 닿는 $n$ 을 풀면

$$ 5\times10^{6} \times 1.15^{n} = 7\times10^{8} \;\Rightarrow\; 1.15^{n} = \frac{7\times10^{8}}{5\times10^{6}} = 140 $$

양변에 로그를 취해

$$ n = \frac{\ln 140}{\ln 1.15} = \frac{4.942}{0.1398} \approx 35.4 \ \text{개월} $$

약 3년이다. 성장 궤적을 몇 지점만 계산해 보면 규모가 더 분명해진다.

두 가지가 이 계산에서 드러난다. 첫째, 도입 시점의 "0.7%"라는 여유는 완전한 착시다 — 복리 성장에서는 대부분의 거리가 마지막 몇 달에 순식간에 사라진다. 24개월까지 20%밖에 안 오다가 그 후 1년 만에 상한에 닿는다. 둘째, 이 조항은 성공할수록 발동한다. 서비스가 실패하면 걸릴 일이 없고, 크게 성공해서 회사의 가치가 정점일 때 정확히 문제가 된다 — 하필 대형 고객·투자자 실사가 몰리는 그 시점에. 그래서 규모 상한은 "지금 안 걸리니 무시"할 대상이 아니라, 성장 계획에 재검토 트리거로 고정해 둘 대상이다. MAU가 상한의 일정 비율(예컨대 50%)에 닿으면 법무 검토와 별도 상업 라이선스 협상을 시작하도록 릴리스·성장 체크리스트에 걸어 두는 것이 최소한의 방어다.

한 가지 해석 함정을 더 정리해 둔다. "MAU"가 정확히 누구의 사용자를 세는지 — 우리 제품의 사용자인가, 우리가 재배포한 모델을 쓰는 다운스트림 사업자의 사용자까지 합산인가, 특정 계열사·관계사를 포함하는가 — 는 조항마다 정의가 다르고 해석 여지가 크다. 임계값 자체보다 이 "무엇을 세는가"가 실제 분쟁의 핵이 되기 쉽다. 이런 정의성 조항이야말로 법무의 몫이다(9.2.12).

9.2.7 증류·파생물 제한 — 기술과 권리가 갈리는 곳

라이선스가 유독 신경 쓰는 지점이 "이 모델로 다른 모델을 만드는 것", 즉 증류(distillation)와 파생물이다. 3.9에서 기술로 다룬 증류가 여기서 계약과 만난다. 값싸게 능력을 옮기는 증류의 매력 뒤에는 언제나 "그렇게 만든 데이터·모델을 배포·판매할 권리가 있는가"라는 물음이 붙는다.

두 층위를 반드시 구분해야 한다. 오픈 웨이트 모델을 교사로 삼아 증류할 때는 그 모델의 라이선스를 본다. 교사가 관대형(①)이면 대체로 자유롭지만, 커뮤니티 라이선스(②)에는 "이 모델의 출력을 다른 대형 언어모델을 학습·개선하는 데 사용하는 것을 금지한다"류의 조항이 들어 있을 수 있다. 때로는 "같은 계열 파생은 허용하되 타 계열 개선은 금지" 같은 카브아웃이 붙기도 한다. "오픈이니까 증류도 당연히 되겠지"가 여기서 틀린다 — 가중치를 열어 준 것과 그 출력으로 경쟁 모델을 키워도 좋다는 것은 별개의 허락이다. 폐쇄 API를 교사로 삼아 증류할 때는 라이선스가 아니라 이용약관(ToS)의 문제가 된다. 대다수 폐쇄 제공자는 약관에서 "자사 출력으로 경쟁 모델을 학습하는 행위"를 금지하는데, 이것은 오픈 라이선스가 아니라 계약·법의 영역이라 3.9.17과 9.3에서 다룬다.

핵심은 "증류가 기술적으로 되는가"와 "증류가 계약적으로 허용되는가"가 완전히 다른 질문이라는 것이다. 전자는 손실 함수와 소프트 타깃의 문제이고(3.9), 후자는 라이선스 조항과 약관의 문제다. 두 질문은 서로의 답을 주지 않는다 — 기술적으로 아주 잘 되는 증류가 계약적으로는 명백한 위반일 수 있다. 그리고 증류의 산물은 흔적을 남긴다. 학생 모델이 교사의 독특한 어투나 거부 패턴을 그대로 복제하면, 그것이 어디서 왔는지 나중에 추궁당할 수 있다. 그래서 어떤 교사로 어떤 데이터를 만들어 어떤 모델을 학습했는지 출처와 생성 이력을 문서화(8.3)해 두는 것이, 이 리스크를 관리하는 최소 방어선이다.

9.2.8 생태계와 계보 — 파생의 파생을 어디까지 믿나

오픈 모델의 힘은 개별 모델이 아니라 그 주위에 자라는 생태계에서 온다. 가중치가 공개되면 커뮤니티가 그 위에 층층이 쌓는다.

모델 허브는 가중치·모델 카드·버전을 중앙에서 배포하는 장이다. 라이선스·용도·평가 정보가 모델 카드로 함께 배포되는 것이 이상적이지만, 카드의 라이선스 표기가 실제 라이선스와 어긋나거나 아예 누락되는 일이 흔하다 — 파생본 제작자가 태그만 대충 달거나, 상위 라이선스를 잘못 이해해 관대한 라이선스로 표기해 버리는 식이다. 카드는 인덱스일 뿐 계약이 아니니, 카드만 믿지 말고 원 라이선스 파일을 봐야 한다. 양자화 파생본은 커뮤니티가 원본을 INT4·INT8·GGUF 같은 포맷으로 낮춰(5.2) 작은 GPU·CPU·엣지에서 실행될 수 있게 만든 것으로, 원본이 못 실행되던 하드웨어에서 서비스를 가능하게 하는 오픈 생태계의 핵심 증폭기다. 파인튜닝 커뮤니티는 base 모델 위에 instruct 튜닝·도메인 특화·언어 특화·모델 병합 파생본을 무수히 만들어 낸다(3.8).

여기에 오픈 생태계 특유의 함정이 있다. 라이선스는 파생본으로 승계된다. 허브에서 받은 이 파인튜닝 버전의 라이선스 표기가 아무리 관대해 보여도, 원본이 커뮤니티·비상업이면 그 제한은 파생본에도 살아 있다 — 파인튜닝을 했다고 상위 라이선스가 세탁되지 않는다. 그리고 오픈 생태계는 파생의 파생의 파생이 흔하다. "A를 파인튜닝한 B를, C와 병합한 D"를 쓴다면, 최종 산출물이 적법하려면 A·B·C·D의 라이선스가 모두 당신의 용도를 허용해야 한다 — 또 하나의 논리곱이다. 하나라도 비상업·연구전용이면 최종물도 그 제약을 진다.

이 계보 리스크가 왜 깊이에 따라 급격히 나빠지는지는 간단한 어림으로 느낄 수 있다. 계보의 각 조상이 우리 용도에 "깨끗할" 확률을 독립적으로 $p$ 라고 두면(실제로는 독립도 아니고 이것은 경험 법칙일 뿐이지만, 개략을 파악하는 데 쓴다), 계보 전체가 깨끗할 확률은 대략 $p^{k}$ 로 준다. $p=0.85$ 라 해도

$$ k=1:\ 0.85 \qquad k=3:\ 0.85^{3}\approx 0.61 \qquad k=5:\ 0.85^{5}\approx 0.44 $$

조상 하나하나는 십중팔구 괜찮아 보여도, 다섯 단을 거친 병합 모델은 어딘가 한 곳이 걸릴 확률이 절반을 넘는다. 이 숫자는 통계가 아니라 직관을 위한 도구다 — 말하려는 것은 "깊은 계보일수록 위반 확률이 곱으로 쌓인다"이다. 그러니 화려한 병합 파생본을 채택하기 전에 계보를 원본까지 끝까지 거슬러 올라가 각 단의 라이선스를 확인하고, 그 확인 결과를 증적으로 남겨야 한다. 계보를 추적할 수 없는 파생본은, 아무리 벤치마크가 좋아도 도입 후보에서 빼는 것이 안전하다.

9.2.9 능력 격차는 시점에 종속된 질문이다

"오픈 모델이 폐쇄 모델을 따라잡았는가"는 뜨거운 논쟁이지만 이 책은 여기에 답을 주지 않는다 — 답이 측정 시점에 종속되기 때문이다. 특정 시점에 "최상위 폐쇄 모델과 최상위 오픈 모델 사이에 몇 개월치 격차가 있다"는 식의 주장이 자주 나오는데, 그 격차가 넓어졌다거나 좁혀졌다는 서술은 측정 시점·벤치마크·과제 종류에 따라 뒤집힌다. 어떤 과제, 이를테면 일반 지식이나 코딩의 일부에서는 격차가 작고, 어떤 과제, 이를테면 최전선 추론이나 긴 에이전트 궤적의 신뢰성에서는 크다는 식으로 과제별로도 다르다.

단정하면 안 되는 이유가 셋 있다. 벤치마크는 오염되고 오버핏될 수 있다(4.1) — 오픈 모델이 특정 벤치마크에서 강하다고 당신의 실사용에서 강한 건 아니다. "최상위"의 정의가 유동적이다 — 오픈이 따라잡는 동안 폐쇄 진영도 멈춰 있지 않다. 그리고 오픈·폐쇄 각 진영에서 어떤 모델을 대표로 뽑느냐에 따라 결론 전체가 바뀐다. "오픈이 이겼다"와 "폐쇄가 앞선다"는 대개 서로 다른 두 모델을 대표로 골라 붙인 말싸움이다.

그래서 실무 판단은 "오픈이 폐쇄를 이겼나"가 아니라 "우리 과제·품질 기준에서 이 오픈 모델이 충분한가"로 질문을 바꿔야 한다. 이 질문은 리더보드 순위가 아니라 당신의 평가셋(4.2)에서 직접 측정해야 답이 나온다. 리더보드 1등이 당신의 도메인·언어·데이터 분포에서도 최적이라는 보장은 없고, 반대로 리더보드에서 뒤처진 모델이 당신의 좁은 과제에서는 충분할 수도 있다. 통념 두 개를 조용히 깨 두자. "오픈은 언제나 폐쇄보다 약하다"는 틀렸다 — 많은 과제에서 잘 고른 오픈 모델이 폐쇄 모델과 실용적으로 대등하다. "이제 오픈이 폐쇄를 다 따라잡았다"도 과장이다 — 최전선 능력, 안전 튜닝의 성숙도, 멀티모달 통합 같은 영역에서는 격차가 남는 시점이 있다. 진실은 "경우에 따라 다르다"이고, 이 책의 어떤 문장도 특정 시점의 순위표를 대신하지 못한다.

9.2.10 오픈의 실제 이점과 대가

능력 격차를 단정할 수 없다면, 오픈을 고르는 판단은 능력 순위가 아니라 통제권과 비용 구조의 트레이드오프에서 온다. 오픈이 주는 것부터 보자.

가장 큰 것은 통제와 이식성이다. 가중치를 손에 쥐면 어디서든 실행할 수 있어 특정 벤더에 묶이지 않는다. 모델을 동결(freeze)해 두면 "밑의 API가 조용히 바뀌어 우리 프롬프트가 어느 날 깨지는" 회귀(8.2)를 원천 차단한다 — 폐쇄 API는 당신 허락 없이 모델을 갱신하거나 폐기할 수 있지만, 당신이 받아 둔 가중치는 그러지 않는다. 프라이버시와 데이터 주권이 다음이다. 요청을 외부로 보내지 않고 자체·프라이빗·온프레미스·엣지로 서빙할 수 있어(8.4), 규제·기밀·개인정보 제약이 강한 도메인 — 의료·금융·공공 — 에서 결정적 이점이 된다. 비용 구조의 전환도 있다. 토큰당 API 과금이라는 가변비를, 자체 서빙이라는 고정비 중심 구조로 바꾼다. 처리량이 높으면 토큰당 단가가 유리해질 수 있지만, 손익분기가 활용률에 달렸다는 함정이 있다(9.2.11에서 계산한다). 마지막으로 깊은 커스터마이즈다. 파인튜닝(3.8)·양자화(5.2)·아키텍처 개조·특수 디코딩까지 모델 내부에 손댈 수 있어, 폐쇄 API로는 불가능한 수준의 최적화가 열린다.

대가도 정직하게 비교 평가해야 한다. 가장 큰 대가는 운영 부담이다. 서빙 인프라·GPU 운영·오토스케일·업데이트·모니터링을 직접 부담한다(5.4·5.5). "가중치는 공짜"여도 GPU·엔지니어링·온콜은 무비용이 아니다 — 총소유비용에는 이 운영비가 전부 들어간다. 최상위 능력의 한계 가능성이 둘째다. 과제에 따라 최전선 폐쇄 모델과 격차가 남을 수 있고(9.2.9), 하필 "가장 어려운 소수 과제"에서 이 격차가 병목이 되기도 한다. 안전·정렬이 당신 몫이 된다는 것이 셋째다. 폐쇄 API가 뒤에서 대신 해 주던 가드레일·모더레이션·안전 튜닝을 직접 갖춰야 한다(7.3·7.4). 오픈 모델은 안전 조치가 더 얇거나, 파인튜닝 몇 스텝으로 벗겨지기 쉬울 수 있다. 그리고 라이선스·법무 부담 — 바로 이 장의 주제 — 을 당신이 진다.

그래서 누구에게 언제 맞느냐를 방식으로 펼치면 이렇다.

현실의 성숙한 서비스 대부분은 둘 중 하나를 고르지 않고 폐쇄와 오픈을 라우팅한다(5.6) — 어렵고 드문 요청은 폐쇄로, 대량이거나 민감한 요청은 오픈으로 보낸다. "오픈 아니면 폐쇄"의 양자택일로 몰지 말 것. 내 견해로는, 오픈을 택하는 가장 견고한 이유는 "능력이 더 좋아서"가 아니라 "통제·프라이버시·이식성이 제품의 요구사항이라서"다. 능력만으로 정당화하려 들면 시점이 바뀔 때마다 결정을 뒤집게 되지만, 통제권을 이유로 삼으면 그 이유는 시점에 따라 변하지 않는다.

9.2.11 "가중치는 공짜"라는 착시 — TCO의 수계산

오픈을 비용으로 정당화할 때 가장 흔한 착각이 "가중치가 공짜니 오픈이 싸다"이다. 청구서를 실제로 그려 보면 이 문장이 왜 위험한지 드러난다.

오픈 모델 하나를 GPU 한 장에 적재해 자체 서빙한다고 하자. 클라우드 온디맨드로 이 GPU가 시간당 2.5달러라 하면(개략 예시), 24시간 켜 두는 월 비용은

$$ 2.5\ \text{\$/hr} \times 730\ \text{hr/월} \approx 1{,}825\ \text{\$/월} $$

이 GPU가 높은 활용률에서 출력 토큰을 초당 1,500개가량 지속 생성한다고 하자(모델·배칭·컨텍스트에 따라 크게 달라지는 개략값이다, 5.1). 월간 생성 토큰은

$$ 1{,}500\ \text{tok/s} \times 3{,}600\ \text{s/hr} \times 730\ \text{hr/월} \approx 3.94\times10^{9}\ \text{토큰/월} $$

약 39억 토큰이다. 그러면 출력 100만 토큰당 비용은

$$ \frac{1{,}825\ \text{\$}}{3{,}940\ (\text{백만 토큰})} \approx 0.46\ \text{\$ / 1M 토큰} $$

이 비용 어디에도 "가중치 값"은 없다. 가중치가 기여한 금액은 0원이고, 비용 전부가 GPU다 — 게다가 이것은 순수 GPU 임대료일 뿐, 서빙 엔지니어·온콜·모니터링·안전 파이프라인·법무 검토의 인건비는 한 푼도 안 들어갔다. "가중치가 공짜"라는 말은 TCO의 관점에서 0을 자랑하는 것과 같다. 실제 청구서는 무비용이 아닌 항목들로 채워진다.

더 중요한 것은 이 단가가 활용률에 전부 매여 있다는 점이다. 방금 계산은 GPU가 쉬지 않고 꽉 찼다는 이상적 가정이다. 트래픽이 뜸해 실효 활용률이 10%로 떨어지면 — 같은 GPU를 24시간 켜 두지만 실제로는 초당 150개꼴로만 생성한다면 — 같은 월 1,825달러로 3.9억 토큰만 나오므로 단가는 10배로 증가한다.

$$ \frac{1{,}825\ \text{\$}}{394\ (\text{백만 토큰})} \approx 4.6\ \text{\$ / 1M 토큰} $$

이 지점에서 "싼 오픈"은 더 이상 저렴하지 않다 — 활용률 낮은 자체 서빙은 토큰당 API 과금보다 오히려 비용이 클 수 있다. 그래서 오픈 대 폐쇄의 비용 비교는 "가중치가 공짜냐"가 아니라 "우리 활용률에서 손익분기가 어디냐"의 문제이고(9.1·7.5), 그 답은 트래픽 패턴이 정한다. 꾸준히 높은 활용률로 자체 서빙 GPU를 꽉 채울 수 있는 조직에게 오픈은 실제로 저렴하고, 트래픽이 낮거나 불균일한 조직에게는 "공짜 가중치"가 고가의 GPU를 유휴 상태로 두는 함정이 된다.

9.2.12 라이선스 실무 — 도입 전 검토와 위반 리스크

기술 판단이 끝나도 법무 관문이 남는다. 오픈 모델 도입은 소프트웨어 의존성을 하나 들이는 것과 같은 절차적 엄밀함을 요구한다 — "그냥 받아서 쓰면 되는 것"이 아니다. 도입 전 확인은 대략 이런 순서를 밟는다.

먼저 정확한 대상을 특정한다. 어떤 계열이 아니라 어떤 모델·어떤 버전·어떤 크기인지 명시한다 — 라이선스는 이 단위로 다를 수 있다. 다음으로 라이선스 원문을 확보해 그 시점의 사본을 보관한다. 모델 카드가 아니라 라이선스 파일 원문을 받고, 라이선스는 개정되므로 "받을 때 이랬다"를 나중에 증명할 수 있도록 사본을 증적으로 남긴다. 그리고 우리의 실제 용도를 대조한다 — 상업인가, 규모는 어디인가, 재배포하는가, 파인튜닝하는가, 증류하는가, 산출물을 어떻게 쓰는가를 9.2.5의 다섯 항목에 하나씩 대본다. 파생본이라면 원본까지 계보를 거슬러 각 단의 라이선스를 확인하고(9.2.8), 라이선스에 딸린 허용 사용 정책·상표·명명 조건을 읽는다. 여기까지 해서 "조건부"로 걸리는 항목이 하나라도 있으면 법무·법률 자문을 건다 — 특히 커뮤니티 라이선스의 규모 상한, MAU 정의, 증류 제한은 해석 여지가 커서 엔지니어가 판단할 대상이 아니다. 마지막으로 재확인 트리거를 설정한다. 모델·버전을 배포할 때, 또는 사업 규모가 상한에 근접할 때 라이선스를 다시 보도록 릴리스·성장 체크리스트에 명시해 둔다(8.2).

체크리스트로 압축하면 도입 전에 반드시 통과해야 할 관문은 이렇다.

• [ ] 대상 모델·버전·크기를 특정하고 라이선스 원문을 확보·보관했는가(모델 카드가 아니라 원문).
• [ ] 상업 사용이 허용되는가. 커뮤니티 라이선스면 규모 상한에 현재와 성장 후 둘 다 걸리지 않는가.
• [ ] 파인튜닝이 허용되는가. 파생물 명명·귀속·AUP 조건은 무엇인가.
• [ ] (재배포한다면) 재배포·라이선스 승계 조건을 충족하는가.
• [ ] (증류한다면) 출력으로 타 모델 학습이 허용되는가, 금지 조항이 있는가(9.2.7).
• [ ] 파생본이면 원본까지 계보 전체의 라이선스를 논리곱으로 확인했는가.
• [ ] 조건부 항목에 법무 검토를 걸고, 증적 보관과 재검토 트리거를 체크리스트에 넣었는가.

위반이 추상적 위험이 아니라는 것도 알아 두어야 한다. 라이선스는 계약이므로, 어기면 사용 권리 자체가 소멸할 수 있고 이미 배포한 서비스가 소급해서 무권리 상태가 된다. 조건을 어긴 재배포·파생본은 내려야 할 수 있고, 그 위에 추가한 제품까지 변동한다. 대형 고객·투자자 실사에서는 모델 라이선스 컴플라이언스를 점검하는데, 위반이 드러나면 거래가 깨진다 — 앞서 본 규모 상한이 하필 회사 가치가 정점일 때 발동하는 이유가 여기서 아프게 겹친다. 증류 제한이나 약관 위반은 분쟁·조사로 번지기도 한다(업계에서 이런 사안이 반복돼 왔다는 점은 3.9.17에서 다룬다). 마지막으로 이 절 전체는 법률 자문이 아니라는 점을 분명히 한다. 라이선스 해석은 관할·사업 형태·구체 용도에 따라 달라지고 문구와 판례가 유동적이라, 이 책이 줄 수 있는 것은 "무엇을 확인하고 누구에게 물어야 하는가"라는 절차뿐이다. "책에 된다고 적혀 있었다"는 방어가 되지 못한다.

9.2.13 수계산 — 한 서비스 시나리오의 라이선스 판정

원리를 하나의 구체 시나리오에 통과시켜 보자. 어떤 실제 모델·라이선스도 지목하지 않는 가상 사례이며, 판정하는 방법을 보이기 위한 것이다.

우리는 B2B SaaS로 "문서 요약·질의응답" 기능을 유료로 판다. 후보 오픈 모델을 하나 골라 사내에서 도메인 파인튜닝을 하고, 그 파인튜닝 버전을 자체 서버에 배포해 서비스하며, 나중에 이 모델의 출력으로 더 작은 학생 모델을 증류해 비용을 줄일 계획이다. 가중치를 외부에 공개하는 재배포는 하지 않는다. 우리에게 필요한 권리를 9.2.5의 논리곱으로 늘어놓으면 이렇다.

$$ \text{적법} = \underbrace{\text{상업허용}}_{\text{유료 서비스}}\land\underbrace{\text{파인튜닝허용}}_{\text{도메인 튜닝}}\land\underbrace{\text{규모·AUP충족}}_{\text{현재 규모}}\land\underbrace{\text{증류허용}}_{\text{장래 학생모델}}\land\underbrace{\text{산출물사용허용}}_{\text{요약 판매}} $$

재배포는 하지 않으므로 재배포 조건 항은 이번엔 빠진다 — 필요한 권리만 검사한다. 이제 후보 라이선스의 부류에 따라 결정 트리를 탄다.

후보가 관대형(①)이면 상업·파인튜닝·증류·산출물 사용이 모두 대체로 열려 있어 전부 통과한다 — 고지 유지만 준수하면 채택 후보이고, 가장 단순한 경로다. 후보가 커뮤니티(②)이면 세 관문을 차례로 넘어야 한다. 상업이 허용되고 우리 규모가 상한 이하인가 — 지금은 스타트업이라 무해할 가능성이 높지만, 9.2.6에서 봤듯 성장하면 발동하므로 재검토 트리거가 반드시 붙어야 한다. 그다음 증류 제한 조항이 있는가 — 있으면 우리의 장래 증류 계획이 곧 위반이므로 "증류를 빼거나" "모델을 바꿔야" 한다. 마지막으로 파인튜닝 파생본의 명명·귀속·AUP 조건을 충족하는가. 셋을 다 넘으면 법무 검토를 거쳐 조건부 채택이다. 후보가 비상업(③)이나 연구전용(④)이면 유료 서비스라는 전제에서 즉시 탈락이고, PoC로 능력만 확인한 뒤 프로덕션에는 다른 모델을 써야 한다.

이 시나리오의 급소는 세 번째 관문, 증류였다. 같은 "오픈 모델"이라도 우리의 구체적 권리 요구 — 상업에 더해 파인튜닝, 거기에 증류까지 — 에 라이선스를 대보면 결과가 갈린다. 특히 증류 계획이 커뮤니티 라이선스의 증류 제한과 정면으로 부딪히는 지점이, 3.9가 다룬 "증류의 기술"과 이 장이 다룬 "증류의 권리"가 만나는 곳이다. 기술적으로 완벽히 되는 계획이 계약 한 줄에 막히는 경험은, "오픈이니까 마음대로"라는 첫 문장의 착각을 가장 아프게 교정해 준다.

라이선스가 계약으로서의 권리를 다룬다면, 그 위에는 저작권·프라이버시·규제라는 더 넓은 법의 층이 있다 — 학습 데이터의 저작권, 폐쇄 API 약관 위반의 법적 성격, EU AI Act·GDPR·개인정보보호법이 학습과 서비스에 지우는 의무는 9.3에서 이어 다룬다. 오픈 모델을 자체·프라이빗·엣지로 실제 배포하는 방법과 제약은 8.4이고, 이 모든 판단을 "만들 것인가 살 것인가"의 전략 틀에 놓는 것은 9.1이다. 이 장이 남기려는 것은 특정 모델이나 순위가 아니라 방법이다 — 어떤 모델을 만나든 오픈을 두 축으로 분해하고, 라이선스를 네 부류로 갈라, 필요한 권리를 논리곱으로 판정하는 것. 여기 등장한 모델명·조항·수치는 전부 예시이자 특정 시점의 스냅숏이며, 오픈 생태계는 빠르게 변하고 라이선스는 개정된다. 실제 도입 판단은 그 모델의 라이선스 원문을, 그 버전에 대해, 그 시점에, 당신의 법률 전문가와 함께 내려야 한다.