24장. 라이선스와 상업적 사용

좋은 결과물이 곧바로 안전한 결과물은 아니다. 프롬프트가 훌륭하고, 영상의 모션이 자연스럽고, 광고 성과가 잘 나와도 마지막 관문에서 발목을 잡는 것은 종종 법과 계약이다. 프로덕션 관점에서 보면 품질은 출발선이고, 실제 납품과 배포를 가능하게 만드는 기준은 권리 정리다.

ComfyUI는 특히 이 문제가 더 중요하다. 이유는 간단하다. ComfyUI 자체는 하나의 도구이지만, 실제 결과물은 체크포인트, LoRA, ControlNet, 업스케일러, 폰트, 입력 이미지, 음악, API 서비스 약관이 층층이 쌓여 만들어지기 때문이다. 멋진 그래프 한 장 뒤에는 작은 계약서 여러 장이 숨어 있다고 생각하면 이해가 쉽다.¹²

이 장에서는 세 가지를 정리한다. 먼저 ComfyUI와 대표 모델의 라이선스를 어떻게 읽어야 하는지 살펴본다. 다음으로 한국에서 AI 생성물이 어떤 법적 위치에 놓여 있는지 이해한다. 마지막으로 실제 클라이언트 작업에서 바로 적용할 수 있는 체크리스트를 제시한다.

24.1 모델별 라이선스 비교: 도구 라이선스와 결과물 라이선스는 다르다

가장 먼저 분리해서 봐야 할 것은 ComfyUI 자체의 라이선스와 ComfyUI 안에서 쓰는 모델의 라이선스다. 이 둘을 섞어 생각하면 거의 반드시 사고가 난다.

ComfyUI 소프트웨어 자체는 오픈소스이며, 공식 저장소 기준으로 GPL-3.0 라이선스를 사용한다.³ 서비스 약관에서는 별도로 클라우드나 API 노드 같은 유료 서비스 조건을 다룬다.² 즉, ComfyUI를 사용한다고 해서 자동으로 상업 이용이 금지되지는 않는다. 문제는 그 안에 올려 쓰는 모델과 노드다.

현업에서는 다음 네 층을 따로 확인해야 한다.

• 앱/플랫폼: ComfyUI 본체, Comfy Cloud, 외부 API 서비스 약관

• 모델: 체크포인트, 비디오 모델, 오디오 모델, 업스케일러

• 부속 모델: LoRA, ControlNet, IP-Adapter, 임베딩, VAE

• 입력 자산: 참조 이미지, 인물 사진, 로고, 폰트, 음원, 제품 사진

같은 그래프라도 어떤 모델을 꽂느냐에 따라 법적 성격이 완전히 달라질 수 있다. 그래서 프로덕션에서는 "이 워크플로우가 돌아가느냐"보다 "이 워크플로우가 상업적으로 돌려도 되느냐"를 먼저 물어야 한다.

ComfyUI 자체는 상업 사용이 가능한가

원칙적으로는 가능하다. ComfyUI는 오픈소스 소프트웨어이고, 이를 내부 도구로 사용해 결과물을 만드는 행위 자체가 곧바로 금지되는 것은 아니다.²³ 다만 GPL 계열 소프트웨어를 수정해 배포하거나, 제품에 포함해 재배포하는 방식까지 들어가면 별도 의무가 생길 수 있다. 다시 말해, ComfyUI를 사용해 결과물을 만드는 것과 ComfyUI 자체를 수정해 제품처럼 재배포하는 것은 다른 문제다.³

여기서 실무적으로 중요한 결론은 단순하다. 대부분의 스튜디오와 에이전시는 ComfyUI를 내부 도구로 사용한다. 이 경우 핵심 리스크는 ComfyUI 본체보다, 함께 사용하는 모델과 노드의 라이선스 쪽에 있다.

대표 라이선스 1: Apache 2.0 계열

Apache 2.0은 생성 AI 실무자에게 비교적 다루기 쉬운 라이선스다. 상업적 사용이 가능한 경우가 많고, 수정과 배포도 허용되는 편이다. 예를 들어 ComfyUI 공식 문서에서 소개하는 Wan 2.2 시리즈는 Apache 2.0 기반으로 제공되며 상업 사용이 가능하다고 안내된다.⁴ ACE-Step 역시 Apache-2.0 기반으로 소개된다.⁵

이런 라이선스는 보통 다음과 같은 성격을 가진다.

• 상업 이용이 가능하다.

• 수정과 배포가 가능하다.

• 저작권 고지와 라이선스 문구 유지 의무가 붙는다.

여기서 많은 사람이 오해하는 지점이 있다. 상업 이용 가능은 아무 표시도 필요 없다와 같은 뜻이 아니다. Apache 2.0은 비교적 관대한 라이선스지만, 고지 유지 같은 기본 의무는 남아 있다. 내부 운영만 할 때와 외부 배포를 할 때의 부담도 다르다. 사내에서 조용히 쓰는 것보다, 모델을 재배포하거나 제품에 번들링하는 쪽이 더 엄격하게 본다.

대표 라이선스 2: FLUX.1 [dev] 계열

FLUX 계열은 실무에서 자주 쓰이지만, 라이선스는 이름만 보고 판단하면 위험하다. Black Forest Labs의 공식 문서 기준으로 FLUX.1 [dev]는 비상업 용도 중심 라이선스로 제공되며, 상업적 사용은 별도 라이선스 검토가 필요하다.⁶⁷

실무에서 중요한 것은 "모델이 좋다"보다 "내 프로젝트에 써도 되는가"다. 그래서 클라이언트 납품물이나 유료 캠페인에 FLUX.1 [dev]를 투입하려면, 모델 카드와 공식 라이선스를 다시 확인하고 필요하면 별도 상업 라이선스를 확보해야 한다.⁶⁷ 불명확하면 납품용 운영 풀에서는 제외하는 편이 안전하다.

쉽게 말해 이런 느낌이다. 성능은 훌륭하지만, 계약서가 따라오지 않으면 현업에서는 "테스트 전용 슈퍼카"가 될 수 있다.

대표 라이선스 3: Wan 2.2

Wan 2.2는 2026년 영상 워크플로우의 핵심 모델 가운데 하나인데, ComfyUI 공식 문서는 이 시리즈가 Apache 2.0 기반이며 상업 사용을 지원한다고 적고 있다.⁴ 그래서 영상 제작 파이프라인에서 비교적 다루기 편한 축에 속한다.

물론 여기에도 조건은 있다. 모델 라이선스가 열려 있다고 해서 입력 이미지의 초상권, 브랜드 로고, 배경 음악, 학습된 LoRA의 권리 문제까지 자동으로 해결되지는 않는다. Wan 2.2는 모델 층위의 허들을 낮춰 주는 것이지, 프로젝트 전체 권리 문제를 없애 주는 만능 열쇠는 아니다.

대표 라이선스 4: 커뮤니티 업스케일러와 부속 모델

진짜 사고는 오히려 이런 데서 자주 난다. 본체 모델은 상업 이용 가능인데, 마지막에 붙인 업스케일러 하나나 LoRA 하나가 비상업 조건인 경우다. 커뮤니티 배포물은 라이선스 표기가 불완전한 경우도 있어서 특히 주의해야 한다.⁸

이 함정이 무서운 이유는 아주 사소해 보이기 때문이다. 생성은 안전했는데, 후반에서 업스케일 한 번 눌렀다가 전체 납품물이 회색지대로 들어간다. 실무에서는 그래서 가장 마지막 노드까지 라이선스를 확인해야 한다.

실무용 비교표: 라이선스를 읽을 때 무엇을 보나

이 표에서 가장 중요한 행은 사실 마지막 두 줄이다. 현업에서 법적 분쟁은 "ComfyUI를 써서"보다 "권리 확인 안 된 자산을 섞어서" 발생하는 경우가 훨씬 많다.

라이선스 검토의 기본 원칙: 세 줄 요약

첫째, 모델 이름이 아니라 모델 카드와 LICENSE 파일을 본다.

둘째, 상업 가능 여부와 재배포 가능 여부를 구분한다. 내부 제작만 허용되는 것과 SaaS에 탑재해 외부 고객에게 제공하는 것은 완전히 다른 문제다.

셋째, 워크플로우 전체를 하나의 공급망으로 본다. 체크포인트가 안전해도 LoRA, 업스케일러, 폰트, API 한 군데에서 문제가 터질 수 있다.¹

24.2 한국 저작권법과 AI 생성물의 법적 위치

이제 모델 라이선스가 아니라 결과물 자체를 보자. 한국에서 가장 많이 나오는 질문은 이것이다.

"AI로 만든 이미지나 영상은 내 저작물인가?"

짧게 답하면, 항상 그렇다고 보기 어렵다이다.

한국의 정책 방향은 비교적 선명하다. 문화체육관광부와 한국저작권위원회는 생성형 AI 관련 가이드와 등록·분쟁 예방 자료를 내놓았고, 핵심은 인간의 창작적 개입 여부에 있다.⁹¹⁰

완전히 자율적으로 AI가 만든 산출물은 저작권 보호 대상이 되기 어렵고, 반대로 사람이 표현 선택과 수정, 배열, 반복적 편집, 인페인팅 같은 방식으로 창작적으로 개입했다면 저작권 등록 가능성을 검토할 수 있다는 방향으로 정리되고 있다.¹⁰

이 말은 실무에서 매우 중요하다. 버튼 한 번 눌러 나온 결과물을 그대로 납품하는 방식은 기술적으로는 빠르지만, 권리 설명은 오히려 약해질 수 있다. 반대로 다음과 같은 흔적이 있으면 훨씬 유리하다.

• 프롬프트를 여러 차례 수정하며 구도와 표현을 구체적으로 설계한 기록

• 마스크, 인페인트, 아웃페인트, 레이아웃 조정 등 창작적 편집 과정

• 여러 생성물을 선택·배열·합성해 최종 표현을 만든 과정

• 색보정, 타이포, 컷 편집, 사운드 디자인처럼 인간이 후반에서 결정한 요소

즉, 한국에서는 "AI를 썼다"보다 "사람이 어디서 창작했는가"가 더 중요하다.

저작권이 있다고 해도 침해 책임이 사라지는 것은 아니다

여기서 또 하나의 함정이 있다. 내 결과물에 저작권이 인정될 여지가 있다고 해서, 타인의 권리를 침해하지 않는다는 뜻은 아니다.

예를 들어 이런 경우는 여전히 위험하다.

• 특정 캐릭터나 작가의 고유 스타일을 노골적으로 모사한 경우

• 실존 인물의 얼굴을 허락 없이 광고 크리에이티브에 사용한 경우

• 타사 로고와 상표를 프롬프트나 합성 요소로 넣은 경우

• 참조 이미지를 사실상 복제 수준으로 변환한 경우

한국에서는 저작권만이 전부가 아니다. 상표, 퍼블리시티권, 초상권, 부정경쟁방지법, 계약 위반 문제가 함께 움직일 수 있다. 특히 광고, 커머스, 엔터테인먼트 분야에서는 저작권보다 브랜드·인물 권리가 먼저 문제 되는 일이 많다.

그래서 프로덕션 팀은 "이 결과물의 저작권자가 누구냐"를 묻기 전에, "이 결과물이 누구의 권리를 건드리느냐"를 먼저 봐야 한다.

한국 실무에서 기억할 기준: 인간 개입의 증거를 남겨라

정책과 판례가 계속 움직이는 시기에는, 정답을 외우는 것보다 증거를 남기는 습관이 더 중요하다.

프로젝트별로 남겨 두면 좋은 것은 다음과 같다.

• 사용한 모델과 버전, 다운로드 URL, 라이선스 스냅샷

• 주요 프롬프트와 수정 이력

• 원본 입력 자산의 출처와 사용 허락 범위

• 인페인트, 마스킹, 편집, 컷 편집 등 인간 개입 과정

• 최종 납품본이 확정된 시점의 워크플로우 JSON

이 기록은 나중에 두 가지 역할을 한다. 하나는 권리 분쟁이 생겼을 때 설명 자료가 되는 것이고, 다른 하나는 클라이언트가 "이거 진짜 우리만 써도 되나요?"라고 물었을 때 바로 답할 수 있게 해 주는 것이다. 법무 검토는 결국 문서 싸움이다. 기억보다 로그가 강하다.

24.3 클라이언트 작업 시 체크리스트

이제 가장 실전적인 부분으로 가보자. 아래 체크리스트는 이미지, 영상, 오디오를 모두 포함하는 ComfyUI 프로젝트를 전제로 한다.

1단계: 모델 사용 권한 확인

프로젝트 시작 전 가장 먼저 확인할 것은 모델 스택이다. 최소한 체크포인트, LoRA, ControlNet, 업스케일러, 오디오 모델의 라이선스를 표로 정리해야 한다. 이때 확인할 질문은 늘 같다.

이 모델은 상업 이용이 가능한가. 재배포가 가능한가. API 서비스에 내장해 고객에게 제공해도 되는가. 크레딧 표기가 필요한가. 사용량 기반 상업 라이선스를 추가로 구매해야 하는가.⁶⁷

한 항목이라도 답이 불명확하면, 그 모델은 "일단 보류"가 원칙이다. 생성 AI 실무에서는 모르겠으면 쓰지 않는 것이 대체로 가장 싸다.

2단계: 입력 자산 권리 확인

ComfyUI 프로젝트는 모델보다 입력물이 더 위험할 때가 많다. 특히 다음 자산은 반드시 별도 확인이 필요하다.

• 클라이언트가 제공한 상품 사진과 브랜드 로고

• 인물 사진, 직원 사진, 모델 촬영본

• 경쟁사 광고나 유명 작품을 참조한 무드보드

• 배경 음악, 폰트, 텍스처, 스톡 이미지

클라이언트가 줬다고 해서 자동으로 권리가 정리된 것은 아니다. "제공받았다"와 "상업적으로 변형·배포할 권리가 있다"는 다른 말이다. 프로덕션에서는 파일 전달과 함께 사용 범위를 문서로 남겨야 한다.

3단계: 워크플로우 로그 보존

실무에서는 최종 결과물만 보관하면 부족하다. 생성형 프로젝트는 과정 증빙이 중요하다. 최소한 아래 파일은 함께 묶어 두는 편이 좋다.

• 최종 JSON 또는 PNG 워크플로우

• 사용 모델 목록과 버전

• 생성 날짜, 담당자, 납품처

• 대표 시드와 주요 파라미터

• 결과물 검수 이력과 폐기본 구분

이 묶음은 나중에 재현성과 법적 설명 가능성을 동시에 올려 준다. 다시 말해, 기술 로그가 곧 권리 로그가 된다.

4단계: 계약서 문구 정리

상업 프로젝트에서는 결과물만큼 계약 문구가 중요하다. 최소한 다음 항목은 분명해야 한다.

• 결과물의 권리 귀속 주체는 누구인가

• 생성 과정에서 사용한 제3자 모델·서비스의 제한은 무엇인가

• 특정 플랫폼 배포, 광고 집행, 2차 편집 권한은 포함되는가

• AI 사용 사실의 고지 의무가 있는가

• 권리 분쟁 발생 시 책임 분담 구조는 어떻게 되는가

여기서 자주 생기는 실수가 있다. 제작사는 "산출물 납품"만 생각하고, 발주사는 "완전한 독점 양도"를 상상한다. 그런데 중간에 비독점 라이선스 모델이나 API 약관이 끼어 있으면 그 약속이 충돌할 수 있다. 그래서 생성 AI 프로젝트의 계약서는 일반 디자인 외주 계약서보다 조금 더 기술적이어야 한다.

5단계: 배포 채널별 위험 점검

같은 결과물이라도 어디에 쓰느냐에 따라 위험이 달라진다.

사내 시안 검토용은 상대적으로 부담이 적다. SNS 광고 집행은 브랜드, 초상, 플랫폼 정책 문제가 커진다. 앱 내 탑재나 SaaS 제공은 모델 재배포와 서비스형 이용 이슈가 붙는다. 방송 송출과 대형 캠페인은 분쟁 비용이 급격히 커진다. 영화제 출품이나 OTT 납품은 권리 체인을 더 꼼꼼히 요구받는다. 한국 콘텐츠 산업에서도 AI 기반 제작은 빠르게 늘고 있지만, 유통과 심사 체계는 훨씬 보수적으로 움직인다는 점을 기억해야 한다.¹¹

프로덕션의 관점에서는 "만들 수 있다"와 "배포할 수 있다" 사이에 항상 한 번 더 문이 있다.

현장에서 바로 쓰는 레드 플래그

다음 상황이 보이면 일단 멈추는 편이 좋다.

• LICENSE 파일이 없거나 링크가 죽어 있다.

• Hugging Face 모델 카드와 README에 상업 이용 문구가 다르다.

• Civitai 설명에는 가능하다고 쓰여 있지만 원저작자 저장소에는 제한이 있다.

• 팀원이 인터넷에서 받은 LoRA 파일의 출처를 설명하지 못한다.

• 업스케일러나 얼굴 보정 모델이 비상업 조건일 가능성이 있다.

• 클라이언트가 "유명 브랜드 광고 느낌 그대로"를 강하게 요구한다.

• 실존 인물 사진을 넣었는데 초상·퍼블리시티 동의가 없다.

이런 프로젝트는 속도를 내기 전에 브레이크부터 점검해야 한다. 브레이크 없는 스포츠카는 멋져 보여도 납품장에는 못 들어간다.

프로덕션 팀의 운영 원칙

실무에서는 법을 암기하는 팀보다, 운영 원칙이 있는 팀이 오래 버틴다. 다음 원칙이면 대부분의 사고를 꽤 줄일 수 있다.

첫째, 허용이 명확한 모델만 운영 풀에 넣는다.

둘째, 실험용 모델과 납품용 모델을 분리한다. FLUX.1 [dev] 같은 모델은 연구·탐색 트랙에서 성능 비교용으로 쓰고, 납품 트랙에는 상업 허용 모델만 남기는 식이다.⁶⁷

셋째, 모델 카드와 라이선스 사본을 프로젝트 폴더에 함께 저장한다. 웹페이지는 바뀌지만 폴더 안 문서는 남는다.

넷째, 사람의 창작 개입을 작업물 안팎으로 남긴다. 결과물뿐 아니라 편집 과정과 의사결정 기록도 보존한다.⁹¹⁰

다섯째, 법무 검토 시점을 마지막이 아니라 중간에 둔다. 다 만들어 놓고 못 쓰는 것보다, 중간에 모델을 교체하는 편이 훨씬 싸다.

결국 안전한 파이프라인이 좋은 파이프라인이다

ComfyUI의 강점은 무엇이든 연결할 수 있다는 데 있다. 하지만 프로덕션에서는 바로 그 자유가 리스크가 되기도 한다. 노드를 더 붙일수록 표현력은 커지지만, 권리 체인도 길어진다. 그래서 좋은 워크플로우는 단지 예쁜 결과물을 만드는 그래프가 아니다. 재현 가능하고, 설명 가능하고, 계약 가능한 그래프여야 한다.

한마디로 정리하면 이렇다.

이미지와 영상을 잘 만드는 팀은 많아질 것이다. 하지만 법적으로 안전하게 납품하는 팀은 생각보다 드물다. 2026년의 ComfyUI 실무에서 진짜 경쟁력은 속도나 품질만이 아니라, 권리 정리까지 포함한 운영 능력이다.

프로덕션의 마지막 기준은 품질이 아니라 안전성이다. 그리고 그 안전성은 감으로 생기지 않는다. 모델 카드 한 장, 라이선스 한 줄, 로그 파일 하나를 꼼꼼히 챙기는 습관에서 시작된다.

참고

¹Comfyui for full commercial use? · Comfy-Org/ComfyUI · Discussion #3804 · GitHub

²Terms of Service — Comfy

³ComfyUI · GitHub

⁴Wan2.2 Video Generation ComfyUI Official Native Workflow Example

⁵ComfyUI ACE-Step Native Example - ComfyUI

⁶LICENSE.md · black-forest-labs/FLUX.1-dev at main - Hugging Face

⁷GitHub - black-forest-labs/flux: Official inference repo for FLUX.1 models

⁸Kim2091 / UltraSharp like 56

⁹Welcome to the website of the Ministry of Culture, Sports and Tourism of the Republic of Korea

¹⁰South Korean Copyright Office Issues AI Guidance

¹¹AI Has Opened Production in Korea—But Distribution Still Decides What Gets Seen