Three.js 9:16 쇼츠 제작 파이프라인 | 5단계 공정과 외부 에셋 라이선스 스택

Three.js의 기술적 정의와 실시간 웹 3D 렌더링 구조

Three.js 공식 프로젝트의 기본 목적은 사용하기 쉽고 경량화된 범용 크로스 브라우저 3D 라이브러리를 제공하는 데 있습니다. 내부적으로는 크로노스 그룹(Khronos Group)의 낮은 수준 그래픽 표준인 WebGL과 최신 WebGPU API를 감싸고 있으며, 정점 셰이더와 프래그먼트 셰이더, 버퍼 지오메트리, 재질, 씬 그래프를 개발자가 직관적인 자바스크립트 객체 지향 문법으로 다룰 수 있도록 추상화합니다.

웹 브라우저에서 Three.js의 실시간 렌더링은 매 프레임 브라우저의 갱신 주기와 동기화되는 루프 구조 위에서 실행됩니다. 개발 브랜치 예제 코드에서 보듯 브라우저의 렌더 루프는 함수 호출을 통해 매 프레임마다 카메라의 시점에서 장면을 화면에 다시 그립니다.

다음 코드는 Three.js 씬을 브라우저에 초기화하고 애니메이션 루프를 등록하여 지속적으로 장면을 렌더링하는 기본 구성 방식입니다.

import * as THREE from 'three';

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(75, 9 / 16, 0.1, 1000);
const renderer = new THREE.WebGLRenderer({ antialias: true, preserveDrawingBuffer: true });

renderer.setSize(1080, 1920);
document.body.appendChild(renderer.domElement);

function animate() {
  renderer.render(scene, camera);
}

renderer.setAnimationLoop(animate);

3D 영상 제작자들 사이에서는 블렌더와 같은 전통적인 3D 툴과 Three.js의 렌더링 특성을 비교하는 논의가 자주 이루어집니다. 블렌더 공식 매뉴얼에 따르면 렌더링 엔진은 물리 기반 패스 트레이서인 사이클스(Cycles), 물리 기반 실시간 렌더러인 이비(EEVEE), 그리고 모델링과 레이아웃 프리뷰를 위한 워크벤치(Workbench)로 명확히 나뉩니다.

간혹 커뮤니티에서 블렌더는 무조건 몇십 분씩 걸리고 Three.js만 실시간이라는 주장이 나오기도 하지만 이는 사실과 다릅니다. 블렌더의 EEVEE 역시 물리 기반 실시간 렌더러이며, 렌더링에 걸리는 시간은 장면의 폴리곤 수, 조명 및 그림자 복잡도, 샘플 수, 출력 해상도, 작업 하드웨어에 따라 결정됩니다. Three.js의 실질적인 강점은 렌더링 속도의 절대적 우위가 아니라, 코드를 수정하는 즉시 웹 브라우저에서 즉각적으로 결과를 확인하고 웹 생태계의 다양한 도구와 결합할 수 있는 유연성에 있습니다.

9:16 세로형 쇼츠 제작을 위한 5단계 표준 공정

세로형 3D 쇼츠 제작은 사전에 확정된 대본과 음성 타이밍을 뼈대로 삼아 시각적 장면을 단계별로 얹어가는 체계적인 공정을 통해 완성됩니다. 특정 채널이나 유료 서비스에 종속되지 않는 일반적인 5단계 제작 공정은 다음과 같습니다.

첫째, 대본 및 메시지 기획 단계입니다. 사실 자료를 명확히 수집하고 시청자에게 전달할 핵심 메시지와 질문을 확정합니다. 이 단계에서 확정된 대본은 화면이 따라가야 할 기준선이 되며, 대본 없이 화려한 3D 비주얼만 먼저 구성하면 나중에 서사의 호흡이 무너지는 문제가 발생합니다.

둘째, 목소리 생성 및 타임코드 추출 단계입니다. 완성된 대본 텍스트를 음성 합성(TTS)이나 실제 내레이션 오디오 파일로 변환합니다. 이때 가장 중요한 작업은 음성 파일 전체의 길이뿐만 아니라 각 문장과 핵심 단어가 재생되는 시작 시각과 종료 시각 타임스탬프를 밀리초 단위로 기록하는 것입니다. 이 타임코드 데이터는 이후 자막과 화면 전환의 절대적인 싱크 기준선이 됩니다.

셋째, 3D 장면 구성 및 무자막 플레이트(Plate) 녹화 단계입니다. Three.js 코드로 지오메트리를 생성하고 조명, 머티리얼, 카메라 경로를 제어하여 웹 페이지에 9:16 비율의 3D 장면을 구성합니다. 그리고 이 화면을 비디오 파일로 캡처하여 자막이 없는 순수 비디오 소스인 플레이트 클립을 생성합니다.

넷째, 타임라인 레이어 합성 및 자막 배치 단계입니다. 3단계에서 렌더링된 무자막 플레이트 비디오 클립들을 순서대로 배치하고, 2단계에서 추출한 목소리 오디오 트랙을 얹습니다. 그리고 오디오 타임코드에 맞추어 텍스트 자막 레이어를 그 위에 적재합니다.

다섯째, 마무리 마스터링 단계입니다. 자막에 등장 및 퇴장 모션을 부여하고, 화면 상단이나 하단에 시청자의 체류를 돕는 진행 막대(프로그레스 바)를 배치하며, 배경 효과음과 잔잔한 음악을 조화롭게 믹싱하여 최종 9:16 쇼츠 MP4 파일로 완성합니다.

핵심 포인트: 3단계 플레이트 녹화 시 자막을 3D 장면에 직접 굽지 않고 무자막 클립으로 추출하는 이유는 제작 실무의 수정 효율성 때문입니다. 자막 오타나 문구 수정이 발생했을 때 3D 장면 전체를 다시 녹화할 필요 없이 4단계 타임라인에서 텍스트 레이어만 고쳐 즉시 마감할 수 있습니다.

브라우저 캔버스를 영상 파일로 추출하는 두 가지 기술 방식

Three.js 자체는 브라우저 뷰어 라이브러리이므로 공식 저장소나 API 명세에 쇼츠 MP4 파일을 원클릭으로 내보내는 기능은 존재하지 않습니다. 캔버스 위에 그려지는 실시간 3D 그래픽을 실제 비디오 파일로 변환하기 위해서는 웹 표준 API를 활용하거나 외부 자동화 도구를 연동해야 합니다.

가장 대표적인 첫 번째 방식은 웹 플랫폼 표준 API인 captureStream과 MediaRecorder의 조합입니다. 브라우저의 HTMLCanvasElement 객체는 캔버스의 실시간 렌더링 내용을 MediaStream 형태로 반환하는 captureStream 메소드를 제공합니다. 이 스트림을 MediaRecorder 객체에 전달하면 브라우저 내부에서 실시간으로 프레임을 인코딩하여 WebM 규격의 비디오 Blob 데이터를 생성할 수 있습니다.

다음 예제는 웹 브라우저 콘솔 또는 스크립트에서 Three.js 캔버스 요소를 감지하여 60fps 비디오 스트림을 녹화하는 전형적인 자바스크립트 구현입니다.

const canvas = renderer.domElement;
const stream = canvas.captureStream(60);
const recorder = new MediaRecorder(stream, { mimeType: 'video/webm; codecs=vp9' });
const chunks = [];

recorder.ondataavailable = (e) => {
  if (e.data.size > 0) chunks.push(e.data);
};

recorder.onstop = () => {
  const blob = new Blob(chunks, { type: 'video/webm' });
  const videoUrl = URL.createObjectURL(blob);
  console.log('녹화 완료:', videoUrl);
};

recorder.start();

이 방식은 별도의 서버 환경이나 추가 소프트웨어 설치 없이 순수 프론트엔드 코드만으로 동작한다는 장점이 있습니다. 그러나 실시간 렌더링 속도에 직접 의존하므로, 사용자의 하드웨어 사양이 부족하여 일시적인 프레임 드롭이 발생할 경우 영상 프레임 레이트가 요동치며 싱크 오차가 누적될 수 있는 구조적 한계가 존재합니다.

두 번째 방식은 플레이라이트(Playwright)와 같은 헤드리스 브라우저 자동화 프레임워크와 외부 인코더를 결합하는 파이프라인입니다. 이 방식에서는 브라우저의 내부 시계를 실시간 타이머에 맡기지 않고, 스크립트가 장면의 가상 시계를 1/60초 단위로 직접 전진시킵니다. 그리고 매 프레임 정지 상태에서 캔버스의 무손실 PNG 스크린샷을 저장한 뒤 인코더 바이너리로 프레임들을 결합하여 최종 비디오를 인코딩합니다.

헤드리스 프레임 캡처 방식은 렌더링에 소요되는 실제 시간과 무관하게 모든 단일 프레임을 완벽히 수집하므로, 복잡한 3D 연산 환경에서도 단 하나의 프레임 유실 없는 결정론적 60fps 비디오 출력을 보장합니다. 단, 플레이라이트의 기본 비디오 녹화 기능은 브라우저 컨텍스트가 닫힐 때 전체 테스트 세션을 기록하는 디버깅용 기능이므로, 프로덕션 캔버스 추출은 개별 프레임 캡처 루프로 정밀하게 제어해야 합니다.

Three.js MIT 라이선스의 실제 허용 범위와 영상 적용 경계

Three.js 공식 저장소의 dev 브랜치와 r170 등 과거 배포본의 LICENSE 파일은 모두 오픈소스 이니셔티브(OSI)가 승인한 표준 MIT 라이선스를 채택하고 있습니다. 저작권 고지문은 three.js 저작자들에게 귀속되며, 연도 표기 범위는 배포 시점에 따라 지속적으로 갱신됩니다.

MIT 라이선스 본문이 사용자에게 부여하는 법적 권리는 매우 광범위합니다. 소프트웨어와 부속 문서 파일을 취득한 모든 개인과 기업에게 무료로 소프트웨어의 사용, 복제, 수정, 병합, 발행, 배포, 서브라이선스 설정, 판매 권리를 조건 없이 허가합니다.

라이선스에서 요구하는 유일한 준수 조건은 소프트웨어의 모든 복제본 또는 상당 부분에 원본 저작권 고지와 허가 고지문을 함께 수록하는 것입니다. 아울러 소프트웨어가 있는 그대로 제공되며 상품성이나 특정 목적 적합성, 권리 비침해에 대해 어떠한 명시적, 묵시적 보증도 제공하지 않는다는 책임 한정 조항을 담고 있습니다.

여기서 영상 제작자가 정확하게 짚고 넘어가야 할 법적 경계는 라이브러리 소프트웨어 자체와 라이브러리를 사용해 만들어낸 영상 산출물의 차이입니다.

Three.js 코드로 브라우저에서 3D 장면을 렌더링하고 이를 영상으로 녹화하여 유튜브에 업로드하는 행위는 MIT 라이선스에서 허락한 소프트웨어의 사용에 해당합니다. 고지 의무가 발생하는 대상은 라이브러리 자바스크립트 소스 코드의 복제본이나 상당 부분입니다. 따라서 자바스크립트 코드 파일 자체를 시청자에게 직접 배포하지 않는 일반적인 영상 게시의 경우, 영상 화면 내부나 유튜브 더보기 설명란에 Three.js의 MIT 전문을 강제로 기재해야 할 법적 의무는 문언상 부과되지 않습니다.

반면, Three.js 씬이 포함된 웹 프로젝트 소스 코드나 번들링된 three.module.js 파일을 템플릿 형태로 깃허브나 웹사이트에 공개 배포하는 경우에는 해당 소스 파일 머리말이나 저장소 루트에 원본 저작권 고지와 MIT 허가 문서를 반드시 유지해야 합니다.

또한 Three.js 공식 깃허브 저장소의 예제 폴더(examples/models)에 포함된 수많은 3D 모델, 텍스처, 폰트 파일들은 Three.js 코어 라이브러리와 라이선스가 다를 수 있습니다. 일부 모델은 CC-BY나 비상업적 이용 조건이 붙어 있으므로, 코어 라이브러리가 MIT라는 이유만으로 예제 폴더 안의 3D 자산을 무단으로 쇼츠 영상에 차용해서는 안 되며 각 파일의 라이선스를 개별적으로 확인해야 합니다.

자막 서체 라이선스 분석: SIL OFL 1.1과 상용 무료 폰트의 한계

3D 쇼츠 제작에서 자막은 시청자의 정보 습득을 돕는 필수 시각 요소입니다. 많은 제작자가 인터넷에서 상업용 무료 폰트를 내려받아 영상 자막에 사용하지만, 서체 라이선스는 그 유형에 따라 허용 범위와 제약 사항이 극명하게 갈립니다.

첫째, 오픈소스 글꼴의 대표적인 표준인 SIL 오픈 폰트 라이선스(OFL 1.1)입니다. OFL 1.1은 글꼴 소프트웨어의 사용, 연구, 복제, 임베딩, 수정, 재배포를 전면 허용합니다. 다만 두 가지 핵심 제약이 따릅니다. 글꼴 파일 단독으로 유료 판매할 수 없으며, 서체를 수정하여 파생 저작물을 만들 경우 원본의 예약된 글꼴 이름(Reserved Font Name)을 사용할 수 없습니다.

특히 OFL 본문은 글꼴 파일 자체와 그 글꼴을 사용하여 생산된 문서나 이미지 산출물을 명확히 분리합니다. 글꼴이 OFL 라이선스를 따른다고 해서 그 글꼴로 렌더링된 비디오 화면의 자막이나 그래픽 문서까지 OFL로 공개해야 한다는 전염 조항은 존재하지 않습니다. 따라서 OFL 서체로 제작된 영상 자막은 자유롭게 상업 콘텐츠에 활용할 수 있습니다.

구글 폰트(Google Fonts) 컬렉션에 대해서도 흔히 모든 폰트가 OFL이라는 오해가 만연해 있습니다. 그러나 구글 폰트 공식 저장소 문서에 따르면 등록 서체의 대다수가 SIL OFL 1.1이지만, 일부 서체는 아파치(Apache 2.0) 라이선스를 따르며 우분투 서체의 경우 우분투 폰트 라이선스(UFL 1.0)를 적용받습니다. 따라서 구글 폰트라 할지라도 서체 패밀리별 개별 라이선스 문서를 확인하는 절차가 필요합니다.

둘째, 프레젠테이션 디자인 서체로 널리 알려진 페이퍼로지(Paperlogy) 서체의 메타데이터 상충 사례입니다. 실제 폰트 바이너리의 name 테이블을 정밀 분석해 보면 서로 상충되는 두 개의 정보가 공존하고 있습니다.

서체의 라이선스 정보를 담는 name 13 필드에는 공식적으로 SIL Open Font License 1.1이 지정되어 있는 반면, 서체 설명을 담는 name 10 필드에는 페이퍼로지 폰트는 프레젠테이션을 위한 파워포인트 전용 글꼴이라는 한글 및 영문 설명이 기재되어 있습니다.

국내 폰트 중개 플랫폼인 눈누에서는 페이퍼로지의 상업적 이용 가능 범위를 표시하면서 유튜브 영상 자막을 허용 항목으로 분류하고 있으나, 동시에 해당 표는 참고용이며 법적 효력이 없으므로 정확한 사용 범위는 저작권자에게 직접 확인하라는 안내를 덧붙이고 있습니다. 따라서 페이퍼로지 서체는 한 줄로 안전하다고 단정할 수 없으며 메타데이터 간의 해석 차이를 인지해야 합니다.

셋째, 넥슨 메이플스토리 서체와 같은 기업 제공 무료 서체입니다. 넥슨의 공식 사용 약관에 따르면 지적재산권을 포함한 모든 권리는 넥슨코리아에 귀속되며, 개인 및 기업 사용자 모두에게 무료 사용과 배포를 허용합니다.

그러나 메이플스토리 서체는 오픈소스 OFL 서체가 아닙니다. 약관상 서체의 임의 수정 및 편집이 엄격히 금지되어 있으며 오직 배포되는 형태 그대로만 사용해야 합니다. 따라서 웹 렌더링 최적화를 위해 서체 글리프를 잘라내거나 서브셋 폰트로 변형하여 재배포하는 행위는 허용되지 않습니다. 영상 자막으로 렌더링하여 사용하는 것은 자유로우나, 저작권 안내 문구 표기가 권장되며 인쇄물이나 광고물에 적용될 경우 넥슨의 프로모션에 활용될 수 있다는 조건이 붙어 있습니다.

스톡 음원과 효과음의 플랫폼 라이선스 규정 및 Content ID

쇼츠 영상의 청각적 완성도를 결정짓는 배경음악(BGM)과 효과음(SFX)은 대부분 전문 스톡 라이브러리를 통해 조달됩니다. 아트리스트(Artlist)와 같은 주요 스톡 오디오 플랫폼의 라이선스 구조는 일반 소프트웨어 라이선스와 완전히 다른 방식으로 작동합니다.

스톡 라이브러리 공식 도움말 문서에 따르면, 음악과 효과음 라이선스는 유료 구독이 활성화되어 있는 동안 생성되고 플랫폼에 공식 게시된 프로젝트에 한해 지속적인 권리를 부여합니다. 즉, 구독 기간 중에 제작하여 유튜브에 업로드한 영상은 추후 유료 구독을 해지하더라도 해당 영상에 대해서는 저작권 보호가 영구적으로 유지됩니다.

그러나 구독이 종료된 이후 과거에 다운로드해 두었던 오디오 파일을 새로운 쇼츠 영상 프로젝트에 재사용하는 것은 명백한 라이선스 위반입니다. 새 프로젝트마다 새로운 라이선스를 획득해야 하는 계약 구조를 갖추고 있기 때문입니다.

또한 요금제 등급에 따라 허용 범위가 구분됩니다. 개인 창작자를 위한 소셜(Social) 플랜의 경우 플랫폼별로 단 하나의 채널만 클리어리스트(등록 채널)에 연동할 수 있으며, 기업 브랜디드 콘텐츠나 외주 납품 프로젝트에는 활용할 수 없습니다. 상업 광고나 외주 클라이언트 작업을 수행하기 위해서는 복수 채널과 상업적 납품 권한이 포함된 프로(Pro) 라이선스를 확보해야 합니다.

무엇보다 Three.js 라이선스와 유튜브 플랫폼의 콘텐츠 아이디(Content ID) 시스템은 완전히 별개의 층위에서 동작합니다. 비주얼 소스가 Three.js 코어 라이브러리로 제작되어 100% 합법적인 사용권을 확보했더라도, 영상에 삽입된 배경음악이나 효과음이 Content ID 지문 인식 데이터베이스에 등록되어 있다면 유튜브 시스템은 음원 일치를 감지하여 광고 수익을 원저작자에게 귀속시키거나 영상을 차단하는 조치를 취할 수 있습니다. 스톡 플랫폼의 채널 화이트리스트 연동이 필수적인 이유가 여기에 있습니다.

자막 모션 라이브러리와 AI 생성 음성의 권리 귀속

쇼츠 후반 작업에서 자막의 화려한 등장 모션을 구현할 때 자주 쓰이는 자바스크립트 애니메이션 라이브러리인 GSAP(GreenSock) 역시 Three.js와 전혀 다른 라이선스를 갖고 있습니다.

GSAP 3.12.5 버전 소스 코드의 헤더는 GreenSock 저작권을 표시하며 표준 라이선스 웹페이지를 가리킵니다. 웹플로우(Webflow) 인수 이후 2025년 4월 30일부로 효력이 발생한 공식 GSAP 표준 라이선스에 따르면, GSAP는 일반 웹사이트, 웹 애플리케이션, 디지털 인터페이스에서의 구현 및 사용을 상업적 목적을 포함하여 전면 무료로 허용합니다.

그러나 GSAP는 결코 자유 오픈소스인 MIT 라이선스가 아닙니다. 약관에는 명확한 금지 조항(Prohibited Uses)이 포함되어 있습니다. 코딩 없이 시각적 애니메이션을 제작할 수 있게 해 주는 노코드 애니메이션 도구를 개발하여 Webflow의 핵심 서비스와 직접 경쟁하는 용도로 GSAP를 구현하는 행위는 엄격히 금지됩니다. 순수 영상 제작용 자막 모션 스크립트로 사용하는 것은 허용 범위 내에 있지만, 100% 무조건 무료라는 표어만 믿고 도구화하는 것은 주의해야 합니다.

마지막으로 내레이션을 담당하는 AI 음성 합성(TTS)의 법적 지위입니다. 최근 생성형 AI로 목소리를 합성하는 경우가 많아지면서 저작권 귀속에 대한 혼란이 빈번하게 발생하고 있습니다.

미국 저작권청(US Copyright Office)이 2025년 1월 발표한 인공지능과 저작권 2차 보고서 발표문에 따르면, 단순한 텍스트 프롬프트 입력만으로 생성된 AI 산출물은 저작권법의 보호 대상이 될 수 없습니다. 오직 인간이 결과물의 창작적 표현 요소를 충분히 결정하고 선별, 배열, 수정했거나, 인간이 창작한 원저작물과 결합한 경우에 한해 그 인간의 창작적 기여분만 저작권으로 인정받을 수 있습니다.

대한민국 저작권법 및 문화체육관광부 가이드라인 역시 같은 맥락을 유지합니다. 저작권법 제2조는 저작물을 인간의 사상 또는 감정을 표현한 창작물로 정의하고 있으므로, 인공지능이 자율적으로 생성한 음성 데이터 자체는 저작물로 인정되지 않습니다. 사람이 직접 창작한 대본 문장은 저작물로서 확고한 보호를 받지만, 이를 기계적으로 변환한 음성 파일 자체가 자동으로 저작권을 획득하는 것은 아닙니다.

따라서 AI 음성을 활용할 때는 저작권 유무에 기대기보다 해당 음성 생성 서비스의 이용 약관에서 상업적 이용 및 유튜브 수익 창출을 명시적으로 허용하고 있는지를 계약적으로 확인하는 것이 실무적으로 가장 안전한 접근법입니다.

마무리

앞에서 다룬 내용을 바탕으로 Three.js 9:16 쇼츠 제작 파이프라인과 라이선스 스택 관리의 핵심 원칙을 정리하면 다음과 같습니다.

• Three.js는 브라우저 기반 WebGL 및 WebGPU 3D 라이브러리로서, 자바스크립트 코드 제어를 통해 세로형 9:16 숏폼 영상을 고해상도로 렌더링하는 실시간 파이프라인을 구축할 수 있습니다.
• 쇼츠 제작 공정은 대본 기획, 목소리 및 타이밍 추출, 3D 무자막 플레이트 녹화, 타임라인 레이어 합성, 최종 모션 및 오디오 마스터링의 5단계를 거치며 자막을 3D 장면에 직접 굽지 않는 것이 핵심입니다.
• 브라우저 캔버스 추출 기술은 프론트엔드 표준인 captureStream과 결정론적 무손실 60fps를 보장하는 Playwright 프레임 캡처 결합 방식으로 나뉩니다.
• Three.js 코어 라이브러리는 MIT 라이선스로서 영상 산출물 자체에는 고지 의무가 발생하지 않으나, 프로젝트 소스 코드를 재배포할 때는 원본 저작권 고지를 반드시 유지해야 합니다.
• 자막 서체는 SIL OFL 1.1 서체를 우선 권장하며, 페이퍼로지의 메타데이터 상충이나 메이플스토리 서체의 수정 금지 조항처럼 서체별 개별 약관을 철저히 검토해야 합니다.
• 유료 스톡 음원과 효과음은 구독 활성 기간 내에 제작 및 게시된 프로젝트에 한해 권리가 보호되며, 유튜브 Content ID 클레임 방지를 위해 채널 클리어리스트 등록을 유지해야 합니다.
• 자막 모션용 GSAP 라이브러리는 Webflow 표준 약관을 따르며, AI 생성 내레이션 음성은 서비스 이용약관의 상업적 허용 조항을 계약적으로 확인하는 것이 안전합니다.

「Three.js 라이브러리의 MIT 소프트웨어 허가와 외부 에셋(서체, 음원, 음성, 모션)의 개별 라이선스는 완전히 분리된 독립 계약이다」

출처와 링크

조사 기준: 2026년 10월 27일

• Three.js 공식 홈페이지 - Three.js 자바스크립트 3D 라이브러리 r186 공식 릴리스 및 기술 문서
• Three.js GitHub 저장소 - Three.js dev 브랜치 소스 코드 및 공식 MIT 라이선스 전문
• Khronos Group WebGL 명세 - 크로스 플랫폼 저수준 3D 그래픽 웹 표준 API
• SIL Open Font License 공식 문서 - SIL OFL 1.1 글꼴 소프트웨어 라이선스 조건 및 전문
• 넥슨 메이플스토리 서체 라이선스 - 넥슨 무료 글꼴 사용 조건 및 배포 약관
• GSAP 공식 표준 라이선스 - Webflow의 GSAP 허용 범위 및 노코드 경쟁 도구 제한 규정
• Artlist 공식 라이선스 도움말 - 스톡 음원 구독 기간별 프로젝트 권리 및 소셜 플랜 클리어리스트 규정
• 미국 저작권청 생성형 AI 보고서 발표문 - AI 산출물과 인간 창작 표현 요소에 대한 저작권 등록 가이드라인
• 대한민국 정책브리핑 생성형 AI 저작권 안내 - 문화체육관광부 생성형 인공지능 저작물 등록 기준 해설
• MDN HTMLCanvasElement.captureStream 문서 - 웹 캔버스 엘리먼트 실시간 미디어 스트림 캡처 API 가이드