Qwen3.8 라이선스 상용, API와 가중치는 다릅니다

증상: Qwen3.8 API가 상용 제품에서 작동하니 다운로드한 가중치도 상용 배포할 수 있다고 판단합니다. 이때 출시 승인이 멈출 수 있습니다.

가장 빠른 해법: API 서비스 계약, 오픈 웨이트 라이선스, 추론 코드 라이선스를 별도 파일로 확인하세요. 공식 가중치 라이선스가 확인되기 전에는 API 격리 테스트만 진행하고, 자체 배포와 고객 전달은 보류하거나 교체 가능한 이중 경로로 운영해야 합니다.

이 글은 Qwen3.8을 상용 제품, AI 에이전트, 고객 프로젝트에 연결하려는 개발 책임자를 위한 런북입니다. 법무와 조달 담당자는 계약 주체와 지역 조건을 확인하고, 에이전트 팀은 API와 자체 호스팅 사이의 전환 경로를 남겨야 합니다.

마지막 업데이트: 2026년 8월 15일. 확인 기준은 Qwen 공식 블로그, 공식 모델 저장소, Qwen Cloud Customer Agreement, 공식 서비스 약관과 공개 보도입니다. 공식 라이선스가 새로 올라오면 이 판단을 다시 검토해야 합니다.

같은 모델 이름과 다른 권리부터 분리합니다

한 팀이 Qwen3.8 API를 먼저 연결했습니다. API 호출은 정상 작동했습니다. 제품 데모도 통과했습니다. 개발자는 같은 이름의 가중치를 내려받아 자체 서버에 올렸고, 고객사 전용 환경으로 전달하려 했습니다.

법무 검토에서 배포가 멈췄습니다. API를 사용할 권리와 모델 파일을 복제·수정·재배포할 권리는 같은 권리가 아니기 때문입니다.

Qwen3.8이라는 이름 아래에는 적어도 다음 자산이 나뉩니다.

• 온라인 API와 모델 서비스
• 다운로드 가능한 가중치
• 공식 추론 코드와 미세 조정 코드
• 양자화 파일과 배포 프레임워크
• 어댑터와 파생 모델
• 입력 데이터와 생성 출력물
• 플러그인, 검색 도구, 서드파티 데이터

각 자산에는 서로 다른 공급자, 버전, 계약, 고지 의무가 붙을 수 있습니다. 공식 저장소에 있는 과거 Qwen3 모델이 아파치 2.0으로 표시되어도, 그 사실만으로 Qwen3.8의 상용 배포 조건을 결정할 수 없습니다. Qwen 공식 블로그는 Qwen3의 일부 공개 가중치 모델을 아파치 2.0으로 소개했지만, 이는 Qwen3.8에 대한 자동 승인이 아닙니다. Qwen3 공식 발표

따라서 승인 기록의 첫 줄은 제품명이 아니라 자산 식별자여야 합니다.

• 모델 이름: Qwen3.8-Max인지, 다른 변형인지
• 모델 버전 또는 저장소 경로
• 가중치의 해시
• API 모델 이름
• 호출 경로
• 자체 호스팅 여부
• 고객에게 전달되는 파일의 범위

Qwen3.8-Max는 온라인 서비스와 공식 도구 사용 기록이 확인되지만, API 제공 사실은 오픈 웨이트의 재배포 권한을 대신하지 않습니다. 공개 보도에서도 API 제공과 향후 오픈 웨이트 공개가 별도 사건으로 다뤄졌습니다. 관련 공개 분석

API 계약과 모델 라이선스는 승인 경로가 다릅니다

Qwen Cloud Customer Agreement는 서비스 이용 계약입니다. 계약 주체는 등록 정보와 청구 주소에 따라 달라질 수 있습니다. 공개된 계약에는 지역별 제공 조건, 서비스별 규칙, 모델 서비스 부속 문서가 별도로 연결되어 있습니다. 특정 지역의 기능과 제공 범위가 다른 지역과 같다고 가정하지 말아야 합니다. 공식 고객 계약

API 상용 이용을 검토할 때는 다음 순서로 확인합니다.

1. 회사 계정의 계약 주체를 확인합니다.
2. 실제 청구 주소와 서비스 사용 지역을 기록합니다.
3. 사용하려는 API 모델의 상품 페이지와 서비스 규칙을 저장합니다.
4. 입력, 출력, 개인정보, 사용 제한 조항을 확인합니다.
5. 서비스 중단과 계약 변경 조항을 검토합니다.
6. 당시 적용된 약관 파일과 확인 날짜를 승인 기록에 붙입니다.

공식 고객 계약에는 API가 변경되거나 제거될 수 있고, 지역별 서비스와 조건이 달라질 수 있다는 내용이 포함되어 있습니다. 계약 변경은 일반적으로 게시 후 15일 뒤 효력이 발생할 수 있지만, 새 서비스나 법률 준수 목적의 변경은 즉시 적용될 수 있다고 설명합니다. 실제 계약 문구와 계정에 적용되는 부속 조건을 기준으로 확인해야 합니다.

여기서 멈춰야 하는 추론이 있습니다.

• API를 호출할 수 있다 → 가중치를 내려받을 수 있다: 성립하지 않습니다.
• 출력물을 상용 제품에 넣을 수 있다 → 원본 모델을 재배포할 수 있다: 성립하지 않습니다.
• 모델 서비스 계약이 있다 → 미세 조정 가중치 전달이 허용된다: 성립하지 않습니다.
• 같은 회사가 제공한다 → 코드와 모델 파일의 조건이 같다: 성립하지 않습니다.

Qwen3.8 API 상용 이용 여부는 서비스 계약으로 판단합니다. 자체 서버 배포는 모델 저장소에 연결된 라이선스와 고지 파일로 판단합니다. 두 결과를 하나의 승인 문장으로 합치지 마세요.

API 호출을 운영하는 팀이라면 MacHTML 콘솔에서 테스트 계정과 접속 기록을 분리해 보관하는 방식도 검토할 수 있습니다. 중요한 점은 도구의 이름이 아니라 API 검증 기록과 가중치 검증 기록을 서로 다른 폴더와 승인 번호로 관리하는 것입니다.

공식 라이선스가 없을 때는 오픈 웨이트를 멈춥니다

2026년 8월 15일 기준으로 Qwen3.8 공개 가중치에 직접 연결된 공식 라이선스를 확인하지 못했다면, 그 상태를 “무허가”라고 단정할 필요는 없습니다. 다만 상용 자체 배포를 승인할 근거도 부족합니다.

검토 대상은 다음 네 가지입니다.

• 공식 모델 저장소의 라이선스
• 고지 파일 또는 저작권 안내
• 해당 버전에 연결된 모델 카드
• 다운로드 파일과 버전에 연결된 공식 발표

Qwen3-8B 저장소에는 아파치 2.0 라이선스 파일이 실제로 존재합니다. 그러나 이는 Qwen3-8B에 붙은 문서입니다. Qwen3.8의 파일에 같은 문서가 연결되어 있지 않다면, 과거 모델의 라이선스를 새 모델에 복사해서는 안 됩니다. Qwen3-8B 저장소의 라이선스 파일

공개 보도에서 언급된 지역 제한도 같은 방식으로 다뤄야 합니다. 일부 보도와 커뮤니티 분석은 특정 국가와 지역을 대상으로 한 초안 문구를 언급했습니다. 하지만 해당 내용은 최종 공식 라이선스가 아니라 보도와 전언에 기반한 위험 신호입니다. 최종 문서가 공개되기 전에는 확정된 지역 제한이라고 쓰지 마세요. 관련 보도

revenue-share도 마찬가지입니다. 공개 보도는 대형 상용 사용자가 오픈 웨이트에서 발생한 수익의 일부를 공유하게 될 가능성을 언급했지만, 적용 대상과 발동 조건은 공식 문서로 확인해야 합니다. 이 내용이 API 서비스에 대한 요금인지, 자체 호스팅 가중치에 대한 조건인지, 특정 규모의 사업자에게만 적용되는지 아직 추론해서는 안 됩니다. revenue-share 관련 보도는 배포 승인 자료가 아니라 검토 대기 항목으로 보관하세요.

코드와 가중치를 한 묶음으로 배포하면 문제가 커집니다

가중치의 권한 범위는 전체 기술 스택의 권한 범위가 아닙니다.

다음 구성 요소를 따로 확인해야 합니다.

• 공식 추론 코드
• 미세 조정 스크립트
• 양자화 도구
• 서버 프레임워크
• 모델 변환 파일
• 어댑터와 학습 설정
• 검색 플러그인
• 고객 데이터와 외부 데이터셋

과거 Qwen 저장소의 설명에서도 모델 가중치와 코드가 서로 다른 라이선스 체계에 놓일 수 있다고 안내합니다. 코드가 상용 사용을 허용한다고 해서 모델 파일의 조건까지 넓어지는 것은 아닙니다. 관련 저장소 논의

승인 문서에는 다음 연결 관계를 남기면 됩니다.

• 자산: 무엇을 배포하는가
• 출처: 어느 공식 저장소 또는 계약에서 왔는가
• 버전: 어떤 태그, 커밋, 모델 해시인가
• 적용 문서: 어떤 라이선스, 고지 파일, 약관인가
• 책임자: 개발, 법무, 조달 중 누가 확인했는가
• 배포 형태: API, 내부 서버, 고객 서버, 파일 전달 중 무엇인가

양자화 파일도 자동으로 원본 가중치와 같은 권리를 갖는다고 가정하지 마세요. 제3자가 변환한 파일이면 변환 도구와 배포자가 추가 조건을 붙였는지 확인해야 합니다. 어댑터만 전달하는 경우에도 원본 가중치에 의존하는지, 고객이 원본 모델을 별도로 확보해야 하는지, 어댑터에 별도 라이선스가 있는지 기록해야 합니다.

이 과정은 라이선스 용어를 많이 외우기 위한 것이 아닙니다. 출시 당일 “이 파일은 어디서 왔고 누가 재배포를 승인했는가”에 답하기 위한 증거 연결입니다.

내부 사용과 고객 전달은 같은 위험도가 아닙니다

다음 다섯 가지 사용 형태를 분리해서 승인하세요.

내부에서 API만 호출하는 경우

서비스 계약과 사용 정책을 중심으로 확인합니다. 회사 계정, 입력 데이터 권한, 개인정보 처리, 출력물 사용 범위를 검토합니다. 고객에게 가중치를 전달하지 않는다면 오픈 웨이트 라이선스 검토와는 다른 트랙으로 진행할 수 있습니다.

다만 내부 테스트와 생산 서비스는 분리해야 합니다. API 모델 이름이 바뀌거나 서비스가 중단될 수 있으므로, 호출 모델과 약관 버전을 기록하고 대체 백엔드를 연결할 수 있어야 합니다.

상용 제품의 기능으로 API를 제공하는 경우

최종 사용자에게 모델 자체를 제공하는지, 모델을 사용한 기능만 제공하는지 구분합니다. 사용자 입력이 외부 서비스로 전달되는지, 출력물에 어떤 제한이 있는지, 계정 사용자가 계약상 허용된 주체인지 확인합니다.

공개된 고객 계약은 고객 콘텐츠와 모델 서비스 이용 책임을 계약 구조 안에서 다룹니다. 입력과 출력에 관한 권리를 회사가 실제로 보유하는지, 사용자가 필요한 동의를 받았는지도 확인 대상입니다.

자체 서버에서 추론하는 경우

이제 API 계약만으로는 부족합니다. 가중치와 모델 카드에 직접 연결된 라이선스를 확인해야 합니다. 공식 파일이 없으면 운영 서버에 올리는 대신 격리된 검증 환경에 한정하세요.

자체 호스팅은 다음 비용과 책임도 추가합니다.

• 모델 파일 보관과 접근 통제
• 버전 고정과 취약점 대응
• 추론 서버의 로그와 개인정보 처리
• 지역별 배포 위치
• 재배포와 고객 지원 책임
• 라이선스 변경에 따른 롤백

미세 조정 모델을 고객에게 전달하는 경우

가장 보수적으로 접근해야 하는 형태입니다. 고객에게 전체 가중치를 주는지, 어댑터만 주는지, 서버 접근권만 주는지에 따라 계약과 라이선스의 적용이 달라집니다.

특히 revenue-share나 지역 조건이 최종 라이선스에 들어간다고 해도, 적용 대상과 발동 행위는 정의 조항을 읽어야 합니다. “고객에게 전달했다”는 사실만으로 의무가 생기는지, “상용 서비스로 제공했다”는 행위가 기준인지, 매출 규모나 지역이 조건인지 제목만 보고 판단할 수 없습니다.

공개 저장소에 재배포하는 경우

라이선스 파일, 고지 내용, 저작권 표시, 수정 파일 고지, 모델 카드 연결 상태를 모두 확인해야 합니다. 원본 가중치와 파생 파일을 하나의 압축 파일로 묶는다면 각 파일의 출처와 조건도 함께 넣어야 합니다.

공식 라이선스가 없거나 버전 연결이 불명확한 상태에서는 공개 재배포를 승인하지 않는 것이 맞습니다. 이것은 법적 결론이 아니라, 증거가 부족한 배포를 막는 운영 기준입니다.

개발·법무·조달이 같은 승인 기록을 만듭니다

역할을 나누되 결과 문서는 하나로 통합해야 합니다.

개발 책임자

• API 모델 이름과 가중치 모델 이름을 구분합니다.
• 모델 해시와 저장소 주소를 고정합니다.
• 추론 코드, 양자화 파일, 어댑터의 출처를 기록합니다.
• API에서 자체 호스팅으로 전환하는 설정을 준비합니다.
• 이전 모델로 되돌리는 기능을 남깁니다.

법무·컴플라이언스 담당자

• 각 자산에 적용되는 문서를 찾습니다.
• 공식 문서와 보도를 분리합니다.
• 지역, 재배포, 파생 모델, 출력물 조항을 따로 표시합니다.
• 확인하지 못한 항목은 미확정으로 기록합니다.
• 최종 상용 판단이 필요한 경우 외부 법률 자문을 요청합니다.

기술 조달 담당자

• 계약 주체와 청구 주소를 확인합니다.
• 사용 지역과 배포 지역을 분리합니다.
• 서비스 약관의 변경과 중단 조건을 보관합니다.
• API 비용, 자체 호스팅 비용, 대체 모델 비용을 별도로 계산합니다.
• 공급자 변경 시 데이터와 설정을 옮길 수 있는지 확인합니다.

배포 책임자

• 승인된 모델 버전만 릴리스 파이프라인에 넣습니다.
• 승인 번호와 문서 버전을 연결합니다.
• 라이선스가 변경되면 자동으로 배포를 멈춥니다.
• API와 자체 호스팅의 기능 차이를 사용자에게 알립니다.
• 고객 프로젝트별 예외 승인을 별도로 보관합니다.

출시 전 확인용 선택 목록

아래 항목은 출시 승인 회의 전에 그대로 복사해 사용할 수 있습니다.

• [ ] API 모델 이름과 다운로드 모델 이름을 따로 적었습니다.
• [ ] 회사 계약 주체, 청구 주소, 실제 사용 지역을 확인했습니다.
• [ ] API에 적용되는 약관과 모델 서비스 규칙을 저장했습니다.
• [ ] 가중치에 직접 연결된 공식 라이선스 주소를 확인했습니다.
• [ ] 라이선스 파일의 모델 버전과 실제 파일 해시가 일치합니다.
• [ ] 고지 파일과 모델 카드의 변경 사항을 검토했습니다.
• [ ] 추론 코드, 양자화 파일, 어댑터의 출처를 분리했습니다.
• [ ] 고객에게 전달되는 파일과 서버에서만 실행되는 파일을 구분했습니다.
• [ ] 지역 제한과 revenue-share가 공식 문서인지 보도인지 표시했습니다.
• [ ] API 또는 다른 모델로 전환하는 설정과 롤백 경로를 시험했습니다.
• [ ] 승인 담당자와 확인 날짜를 하나의 기록에 남겼습니다.

이 목록에서 하나라도 비어 있으면 다음 분기로 이동합니다.

• 공식 API 계약은 확인됐고 가중치 항목만 비어 있으면 → API 상용 기능만 유지하고 자체 배포는 보류합니다.
• 가중치 라이선스와 고지 파일은 확인됐지만 고객 전달 조건이 비어 있으면 → 내부 검증만 허용하고 고객 전달은 중단합니다.
• 공식 문서는 확인됐지만 회사 지역과 배포 지역이 충돌하면 → 법무 검토가 끝날 때까지 격리 환경으로 후퇴합니다.
• 보도만으로 revenue-share를 판단하고 있으면 → 비용 의무로 확정하지 않고 공식 문서 대기로 표시합니다.
• 모든 항목이 확인되고 전환 경로까지 시험됐으면 → 승인된 배포 형태만 생산에 올립니다.

조건에 따라 출시 경로를 선택합니다

AI 에이전트라면 백엔드 선택기를 별도 모듈로 두세요. 모델 이름을 코드 곳곳에 직접 넣지 말고, 호출 인터페이스와 출력 형식을 고정하세요. 그러면 API에서 다른 모델로 전환하거나 자체 서버를 잠시 내리는 작업을 릴리스 전체의 수정으로 만들지 않을 수 있습니다.

운영 상태는 네 가지 중 하나로 닫으면 됩니다.

• API 상용 출시: API 계약과 사용 정책이 확인되고, 가중치를 고객에게 전달하지 않는 경우
• 격리 검증만 진행: API 테스트와 자체 호스팅 호환성 검증은 가능하지만 외부 공개는 금지하는 경우
• 공식 라이선스 대기: 가중치, 미세 조정 모델, 재배포 조건을 확인할 문서가 없는 경우
• 대체 모델로 전환: 지역 제한, 재배포 조건 또는 계약 불확실성이 사업 요구와 충돌하는 경우

이 기준은 Qwen3.8에 대한 법률 의견이 아닙니다. 개발, 법무, 조달이 같은 사실을 보고 같은 결론을 내리도록 만드는 출시 통제 절차입니다.

에이전트 운영 구조를 정리할 때는 MacHTML 도움말의 접속과 운영 안내도 함께 확인할 수 있습니다. 클라우드 맥을 검증 환경으로 사용할 때도 API 증거와 자체 호스팅 증거를 같은 환경 기록에 섞지 않는 것이 핵심입니다.

자주 묻는 실무 질문

Qwen3.8 API를 상용 제품에 연결해도 되나요?

API 제품에 적용되는 서비스 계약과 사용 정책을 먼저 확인해야 합니다. 공개된 고객 계약에는 지역별 제공 조건과 모델 서비스 부속 문서가 포함될 수 있습니다. API를 통해 기능을 제공하는 것과 가중치를 고객에게 전달하는 것은 별도 행위입니다. 전자는 API 계약 트랙으로, 후자는 모델 라이선스 트랙으로 승인 기록을 나누세요.

API를 사용한 뒤 같은 모델의 가중치를 자체 서버에 배포할 수 있나요?

API 사용 권한만으로 자체 서버 배포를 승인할 수 없습니다. 모델 저장소에 해당 버전의 라이선스, 고지 파일, 모델 카드가 연결되어 있는지 확인해야 합니다. Qwen3-8B에 아파치 2.0 문서가 있다는 사실은 Qwen3.8의 결론이 아닙니다. 모델 식별자와 파일 해시가 일치하지 않으면 자체 배포는 보류하세요.

Qwen3.8의 revenue-share는 API와 오픈 웨이트 중 어디에 적용되나요?

현재 공개된 내용은 오픈 웨이트와 관련된 계획 또는 보도로 다뤄지고 있습니다. 그러나 최종 라이선스가 공개되지 않았다면 적용 대상, 매출 정의, 발동 기준, 지역 범위를 확정할 수 없습니다. API의 호출 비용과 revenue-share 의무를 같은 비용 항목으로 합치지 말고, 공식 문서가 나올 때까지 별도 위험 항목으로 기록하세요.

회사 등록지와 사용자 지역, 배포 지역은 무엇을 따로 확인해야 하나요?

회사 등록지와 청구 주소는 계약 주체와 지역 서비스 조건에 연결될 수 있습니다. 사용자의 위치는 입력 데이터와 개인정보 처리 검토에 영향을 줍니다. 실제 가중치가 실행되는 서버 위치는 모델 라이선스의 지역 제한과 별도로 확인해야 합니다. 세 지역이 다르면 하나의 사용 국가로 축약하지 말고 계약, 데이터, 배포 항목으로 나누어 기록하세요.

미세 조정한 Qwen3.8 모델을 고객에게 전달할 때 추가 승인이 필요한가요?

고객에게 전체 가중치를 주는지, 어댑터만 주는지, 원격 추론 기능만 제공하는지에 따라 검토 대상이 달라집니다. 원본 모델 라이선스와 어댑터의 조건이 모두 확인되어야 합니다. 고객 계약에는 재배포, 사용 지역, 책임 범위를 별도로 넣어야 할 수 있으므로, 공식 문서가 부족한 상태에서는 법률 자문 없이 전달을 확정하지 마세요.

현재 방식이 단순 API 연결이라면 빠르게 시작할 수 있지만, 공급자 약관 변경, 지역별 기능 차이, 서비스 중단, 호출 로그와 고객 데이터의 외부 전송이라는 약점이 남습니다. 반대로 직접 서버를 운영하면 통제력은 높아지지만 가중치 라이선스, 인프라 유지, 버전 고정, 재배포 책임을 직접 떠안아야 합니다.

그래서 공식 라이선스가 아직 생산 승인을 뒷받침하지 못한다면, 처음부터 자체 서버를 고정하기보다 클라우드 맥 기반의 격리 검증 환경에서 버전 보관, 호환성 확인, API와 자체 추론의 전환 실험을 먼저 끝내는 편이 안전합니다. MacHTML의 클라우드 맥 운영 경로를 활용하면 모델 검증 환경을 별도 운영하고, 최종 문서가 확정된 뒤 자체 호스팅으로 갈지 API 경로를 유지할지 다시 선택할 수 있습니다.