무료로 받을 수 있는 모델이라고 해서 상업 서비스에 자유롭게 넣어도 되는 건 아니다. 2026년 기준으로 코드·가중치·데이터셋·출력물·파생 모델(LoRA 포함)은 각각 다른 라이선스 조건을 가질 수 있고, 이 조건은 모델명이 아니라 "실제로 어떻게 배포하는지" 단위로 확인해야 정확해진다. 이번 실험은 그 확인 절차를 코딩 도구와 이미지 생성 모델 두 영역에서 직접 재현해본 기록이다.

모델 카드에 '오픈소스'라고 적혀 있으면 그대로 믿어도 될까?

믿기 어렵다. OSI의 2025년 Open Source AI Definition 1.0은 오픈소스 AI로 인정받으려면 사용·연구·수정·재배포의 자유뿐 아니라, 수정에 필요한 형태의 학습 데이터 정보·학습 및 실행 소스 코드·모델 파라미터까지 공개해야 한다고 명시한다. 가중치만 공개된 모델은 실무상 "오픈 웨이트"에 가깝고, OSI 기준의 오픈소스 AI와는 다른 범주일 수 있다 출처: OSI Open Source 201 ATO 2025.

실험 전 가설은 "허깅페이스에서 다운로드 가능 = 오픈소스"였는데, 이 가설은 틀렸다. 학습 데이터 출처를 공개하지 않은 채 가중치만 올라온 모델이 다수였고, 이런 경우 "오픈소스"라는 표현을 쓰는 것 자체가 OSI 정의와는 어긋난다. 그래서 이후 검증에서는 모델명 옆에 "오픈 웨이트"인지 "OSI 기준 오픈소스"인지를 별도로 적는 방식으로 바꿨다.

라이선스 하나로 모델 전체를 판단해도 될까?

안 된다. 실제 배포 시에는 학습·추론 코드, 가중치, 데이터셋, 파인튜닝 결과물, LoRA·어댑터, 생성물 조건을 각각 따로 확인해야 한다. 코드가 Apache 2.0이라도 가중치나 데이터셋에 별도 상업 제한이 걸려 있으면 제품 전체를 자유롭게 상업화할 수 없다 출처: Knobbe Legaltech News.

검증 절차는 다음 순서로 재현했다. (1) 모델 카드의 라이선스명과 버전을 캡처, (2) commercial use, redistribution, derivative, fine-tune, LoRA, API, SaaS, output 키워드 검색, (3) 가중치 파일과 추론 코드의 라이선스가 같은 조건인지 대조, (4) 생성물 사용권과 모델 배포권을 따로 표로 작성, (5) 유료 서비스일 경우 매출 기준·최종 사용자 직접 제공 제한·별도 계약 필요 여부 기록. 이 다섯 단계를 거치지 않고 라이선스명만 보고 판단했던 초기 메모는 실제로 세 건 모두 재검토가 필요했다.

코딩 도구에 모델을 직접 넣어보니 뭐가 먼저 걸렸나?

모델 사용권보다 서비스 구조가 먼저 걸렸다. 사내 서버에서 모델을 실행하는 경우와 API·SaaS 형태로 제공하는 경우의 라이선스 조건이 다를 수 있기 때문이다. 특히 라이선스가 "모델을 이용해 매출을 발생시키는 활동" 또는 "최종 사용자와 직접 상호작용하는 서비스"를 비상업적 사용에서 제외하면, 개인 실험은 가능해도 유료 코딩 에이전트·API 배포는 별도 허가가 필요하다 출처: note.com 라이선스 정리.

실제 평가 항목으로는 모델을 로컬 실행했는지 외부 API를 썼는지, 사용 모델명·체크포인트·양자화 형식, GPU와 VRAM·컨텍스트 길이·생성 속도, 동일 프롬프트에서의 코드 정확도·테스트 통과율·수정 횟수, 사내 코드가 외부 서버로 전송되는지, 생성 코드에 저작권 고지 의무가 있는지, 모델 자체를 제품에 포함하는지 아니면 내부 개발 보조로만 쓰는지를 기록했다. 이 중 "사내 코드 외부 전송 여부"는 라이선스 문서만 봐서는 알 수 없고, 실제 네트워크 트래픽을 확인해야 했다는 점이 마찰이었다.

이미지 모델 세 개를 같은 기준으로 비교하니 어떤 차이가 났나?

같은 "오픈"이라는 표현을 써도 모델 배포권과 생성물 사용권이 다르게 갈렸다. FLUX.1 [schnell]은 모델 카드 기준 Apache 2.0으로 배포되며, 모델 자체와 파생물의 상업적 사용을 허용하는 조건으로 소개된다 출처: pixmind.io FLUX 리뷰. 반면 FLUX.1 [dev]는 생성물 상업 이용과 모델 상업 배포를 분리해서 읽어야 한다. 라이선스상 생성물은 상업적으로 사용할 수 있지만, 모델·파생 모델·LoRA를 상업 서비스나 유료 API의 엔진으로 쓰는 것은 비상업 조건에 걸릴 수 있어 별도 상업 라이선스가 필요하다 출처: note.com.

항목 FLUX.1 [schnell] FLUX.1 [dev] Stable Diffusion 3.5
라이선스 Apache 2.0 커뮤니티 라이선스(비상업 요소 포함) Stability AI Community License
모델 상업 배포 허용 별도 상업 라이선스 필요 가능 매출 기준 이하 허용
생성물 상업 사용 허용 허용(조항 분리 확인 필요) 매출 기준 이하 허용

Stable Diffusion 3.5 계열은 Stability AI Community License를 따로 확인해야 하는데, 공개 자료는 연간 매출 100만 달러 미만 기업에 무료 상업 이용을 허용하고 그 이상에서는 별도 라이선스가 필요할 수 있다고 설명한다. 이 수치는 모델 버전·라이선스 개정에 따라 바뀔 수 있어 출시 시점의 공식 문서를 보관해 두는 게 안전하다 출처: Thunder Compute 오픈소스 이미지 모델 비교.

실사용 판정 예시로 정리하면, 광고 시안이나 상품 이미지를 FLUX.1 [dev]로 생성해 판매하는 경우는 생성물 조항상 허용될 가능성이 있으나, FLUX.1 [dev]를 백엔드에 탑재한 유료 이미지 생성 SaaS는 모델 자체의 상업적 사용 제한에 걸릴 수 있다. 같은 모델을 파인튜닝해 유료 모델로 배포하는 경우는 LoRA·가중치·파생 모델의 비상업 조건을 별도로 검토해야 한다 출처: note.com.

이 검증은 어디까지 되고 어디서 막혔나?

이번 검증으로 할 수 있었던 것은 모델 카드·라이선스 문서·공개 비교 자료를 대조해 "모델 배포권"과 "생성물 사용권"을 분리해 표로 정리하는 것까지였다. 막힌 지점은 실제 계약 체결이 필요한 경우였다. 예를 들어 FLUX.1 [dev]를 유료 API 엔진으로 쓸 수 있는지 여부는 공개 문서만으로는 "가능성이 있다" 수준까지만 확인되고, 최종 판단은 라이선스 보유사와의 별도 계약·문의를 거쳐야 하는 영역이었다. 또한 라이선스 문구는 버전 개정에 따라 바뀔 수 있어, 이번에 기록한 매출 기준이나 허용 범위가 다음 리뷰 시점에는 달라질 수 있다는 점도 한계로 남겨둔다. 테스트 날짜와 모델 버전을 함께 기록해두지 않으면 이 한계가 더 크게 작동한다.

이번 실험을 다시 돌아보면 뭘 바꿀까?

다음에는 "모델명을 먼저 적고 라이선스를 찾는" 순서를 뒤집어, 배포 시나리오를 먼저 적고 그에 맞는 라이선스 조건을 찾는 순서로 바꿀 계획이다. 코딩 도구든 이미지 도구든 "무료 다운로드 가능"이라는 문구는 "상업적으로 자유로운 오픈소스"와 동의어가 아니었고, 코드·가중치·출력물·파생 모델·SaaS 배포권이 서로 다른 조건을 갖는 사례가 반복해서 나왔다 출처: OSI 출처: Knobbe.

핵심 정리

  • "오픈소스"와 "오픈 웨이트"는 다른 개념이며, OSI 기준은 데이터·코드·파라미터 전부의 공개를 요구한다.
  • 라이선스는 모델 하나에 하나가 아니라, 코드·가중치·데이터셋·출력물·파생 모델별로 따로 확인해야 한다.
  • 코딩 도구는 "모델 사용권"보다 "사내 실행 vs API·SaaS 제공"이라는 서비스 구조가 먼저 조건을 가른다.
  • FLUX.1 [schnell]은 모델·파생물 상업 사용이 비교적 명확하지만, FLUX.1 [dev]는 생성물 사용권과 모델 배포권을 분리해 읽어야 한다.
  • Stable Diffusion 3.5는 매출 기준(공개 자료상 100만 달러 미만)이 상업 이용 여부를 가르는 기준으로 제시된다.