lemo-opuscar 딥다이브
— 시간을 함수에 넣으면 영화가 나오는 코드 제작소

1프로젝트 한줄 요약

lemo-opuscar는 코딩 에이전트가 그림·소리·편집을 코드로 제작하도록 돕는 영상 스타일 라이브러리입니다. 사용자는 주제와 스타일을 고르고, 에이전트는 그 스타일의 규칙을 읽어 별도의 작품을 설계합니다. 화면은 주로 Canvas 2D나 Three.js로 그리며, 완성된 웹페이지를 프레임마다 촬영해 영상 파일로 바꿉니다.

이 저장소에서 가장 중요한 발상은 동영상을 녹화하는 대신, 원하는 시각의 화면을 함수로 계산한다는 것입니다. window.render(3.5)는 3.5초 시점의 한 장면을 그립니다. 이 함수를 1/24초 간격으로 호출하면, 연속된 정지 화면이 영상이 됩니다.

1-1. 세 층으로 나누어 보면 쉽다

1-2. “59종”은 무엇을 세는가

styleboard/catalog.json에는 59개 항목이 있고, 실제 스타일 디렉토리도 59개입니다. STYLE.md 파일 자체는 60개인데, 하나는 새 스타일용 styles/_template/입니다. styleboard/build.py의 load_styles()가 밑줄로 시작하는 디렉토리를 제외하므로 숫자가 일치합니다. 스타일은 편집·다큐멘터리, 실증 영상, 회화, 게임, 재질·3D 등을 포함한 11개 분류에 속합니다.

2왜 주목받는가

2-1. 코딩 에이전트가 영상 제작의 여러 역할을 맡는다

2026-10-23 GitHub 기준 스타 5,814개, 포크 653개입니다. 저장소 생성일은 2026-09-26으로, 생성 후 27일 시점의 수치입니다. TrendShift Weekly #21의 분석 대상으로서 눈에 띄는 규모이지만, 이 숫자만으로 사용자 만족도나 영상 품질을 입증할 수는 없습니다.

관심을 끄는 지점은 결과물에 그치지 않습니다. 스타일 설명, 구현 예제, 제작 도구가 함께 있어 “어떻게 만들었는가”를 코드까지 거슬러 올라갈 수 있습니다. 에이전트가 그림뿐 아니라 음악과 믹싱까지 작성한다는 소개는 README의 주장입니다. 실제 저장소에서도 장면 코드, 악보 데이터, 효과음 합성 함수, 믹서가 각각 확인됩니다.

2-2. 최근 확장은 “예쁜 효과”에서 “자료를 설명하는 영상”으로

README의 변경 안내는 2026-10-16에 실증 영상 8종, 2026-10-22에 편집·다큐멘터리 8종과 개인 스타일 제작 기능을 소개합니다. styles/caption-news/STYLE.md는 실제 영상·보고서·통계를 배치하는 규칙을, MY-STYLES.md는 기존 스타일을 변형해 자신의 스타일로 보관하는 절차를 설명합니다.

학습 관점에서는 확장 방향이 흥미롭습니다. 같은 렌더러 위에서 직접 그린 애니메이션도 만들고, 출처가 있는 문서·사진·영상을 조합할 수도 있습니다. 외부 자료를 쓰는 스타일은 FACTS.md, CREDITS, 자료 목록을 통해 근거와 권리를 관리하도록 설계되어 있습니다. 이것이 실제 인기의 원인이라는 통계는 없으며, 소스와 공개 소개에서 읽을 수 있는 매력 요인입니다.

2-3. 다른 제작 방식과 무엇이 다른가

2-4. 소개 문구를 읽을 때 구분할 세 가지

3기술 스택 전체 지도

3-1. 프론트엔드: 웹페이지를 영상의 무대로 쓴다

루트 의존성에는 React·Vue·웹 프레임워크가 없습니다. 영상의 화면은 일반적인 앱 UI보다 그림을 그리는 캔버스에 가깝습니다. 다만 스타일마다 구현이 독립적이므로, 특정 데모의 구성까지 루트 의존성만으로 판단해서는 안 됩니다.

3-2. 백엔드에 해당하는 부분: 로컬 제작용 Node.js와 Python

core/render/serve.mjs는 http.createServer()를 이용한 작은 정적 파일 서버입니다. 127.0.0.1의 빈 포트에 바인딩하고, 브라우저가 모듈·이미지·폰트를 읽을 수 있게 합니다. 계정·결제·데이터베이스를 제공하는 서비스 백엔드와 역할이 다릅니다.

재현 가능한 결과를 배우려면 그림 코드뿐 아니라 브라우저·패키지·폰트·원본 소재의 버전도 함께 보아야 합니다. 루트 package.json의 자체 버전은 0.1.0이며 private: true입니다. 이는 GitHub의 최신 릴리스 태그 thanks와 별개의 정보입니다.

3-3. 인프라·빌드: FFmpeg와 정적 사이트 배포

• FFmpeg / ffprobe: 프레임 인코딩, 영상 길이 측정, 오디오 검사, 최종 합성. 저장소에서 공통 최소 버전은 지정하지 않습니다.
• 셸 스크립트: 설치 구성은 plugin/skills/lemo-opuscar/scripts/setup.sh, 소재 다운로드는 tools/fetch.sh, 배포 보조는 tools/publish.sh에 있습니다.
• 정적 사이트 생성: styleboard/build.py가 스타일 메타데이터에서 갤러리를 생성합니다. 이것을 실행하면 문서나 카탈로그가 갱신될 수 있습니다.
• GitHub Actions: .github/workflows/pages.yml은 ubuntu-latest, Python 3.12, checkout @v7, setup-python @v7을 사용합니다.
• GitHub Pages: upload-pages-artifact @v5, deploy-pages @v5. 웹용 영상은 web 릴리스, 고화질 영상은 films 릴리스로 분리합니다.

Pages 워크플로는 갤러리를 만들고 영상을 다운로드한 뒤, 링크된 영상 파일이 모두 존재하는지 검사합니다. 스타일별 영화를 새로 렌더링하는 워크플로는 아닙니다. 커밋 3961ddb에는 Dockerfile, Cargo.toml, pyproject.toml, go.mod가 없으며, 공통 빌드 체계를 Docker·Rust·Go 프로젝트처럼 설명할 근거도 없습니다.

4아키텍처 심화 분석

4-1. 패턴 ① 작은 인터페이스로 여러 엔진을 연결한다

core/render/page.mjs의 openDemo()는 작품 내부의 그림 엔진을 알지 못합니다. index.html을 열고 window.READY === true를 기다릴 뿐입니다. requireDemo()는 진입 파일의 존재를 확인하고, takeSize()는 화면 크기를 검사합니다.

openDemo()는 페이지의 JavaScript 오류와 스크립트·문서의 HTTP 오류 응답을 만나면 중단합니다. 반면 이미지·폰트·선택 데이터의 HTTP 오류는 경고하고 계속합니다. 대체 처리가 없는 필수 이미지를 빠뜨리면 경고만으로는 완성도를 보장할 수 없으므로, 작품 자체의 준비 조건도 중요합니다.

styles/swiss-motion/demo/main.js는 이 계약의 실제 구현입니다. 폰트를 불러오고 악보·대사·발화 시간을 읽은 뒤, renderFilm()과 buildEvents()를 전역 인터페이스에 연결합니다. 아래는 해당 파일에서 화면 계약에 해당하는 부분입니다.

window.DUR = DUR;
window.EV = buildEvents();
window.SUBS = subs();
const Q = new URLSearchParams(location.search);
window.render = t => renderFilm(g, t, {
  nosub: Q.has('nosub'), poster: Q.has('poster')
});
window.READY = true;

4-2. 패턴 ② 화면을 시간으로 계산해 프레임을 나눠 처리한다

core/render/video.mjs는 전체 프레임 수를 Math.round(DUR * FPS)로, 작업자당 범위를 Math.ceil(TOTAL / WK)로 정합니다. 작업자마다 별도의 브라우저를 열고 f / FPS를 render()에 전달합니다.

// video.mjs의 핵심 흐름을 줄인 학습용 의사 코드
const TOTAL = Math.round(DUR * FPS);
const per = Math.ceil(TOTAL / WK);
await Promise.all(workers.map(async w => {
  const a = w * per;
  const b = Math.min(TOTAL, a + per);
  for (let f = a; f < b; f++) {
    await page.evaluate(t => window.render(t), f / FPS);
    const jpeg = await page.screenshot({ type: 'jpeg', quality: 95 });
    // 실제 코드는 쓰기 버퍼가 차면 drain 또는 종료를 기다린다.
    await sendToEncoder(jpeg);
  }
}));

Swiss Motion 데모의 styles/swiss-motion/demo/film.js는 DUR = 44입니다. 기본 24 fps라면 1,056프레임이고, 기본 작업자 3개는 각각 352프레임을 맡습니다. 첫 작업자는 0~351번, 다음은 352~703번, 마지막은 704~1,055번을 계산합니다. 마지막 프레임의 시각은 정확히 44초가 아니라 1055 / 24초입니다.

프레임을 병렬로 만들 수 있는 이유는 각 장면이 직전 프레임의 실행 결과에 의존하지 않아야 하기 때문입니다. 위치를 매번 조금씩 더하는 대신 시각에서 바로 계산해야 합니다. 다만 결정성은 제작 규칙이며, 렌더러가 모든 장면 코드의 결정성을 자동 증명해 주지는 않습니다.

4-3. 패턴 ③ 이벤트와 파일을 경계로 그림·소리를 분리한다

styles/swiss-motion/demo/film.js의 buildEvents()는 {t, type, ...} 형태의 이벤트를 생성하고 시간순으로 정렬합니다. add(T.land, 'thump', {g: 1.1})처럼 착지 시점과 충격음을 연결하며, 대사도 type: 'voice'와 대사 식별자로 기록합니다.

core/render/events.mjs는 이를 {dur, ev} 형태의 JSON으로 내보냅니다. styles/swiss-motion/demo/mix.py 같은 작품별 믹서가 읽으면 Python에서 JavaScript의 그림 코드를 직접 이해할 필요가 없습니다. core/audio/sfx.py의 add(buf, x, at, gain, pan)는 초 단위 시각을 샘플 위치로 바꿔 소리를 섞습니다.

// events.json의 형태를 설명하는 학습용 예시
{
  "dur": 6,
  "ev": [
    {"t": 1.5, "type": "thump", "g": 0.8},
    {"t": 2.0, "type": "voice", "id": "line1"}
  ]
}

파일은 느슨한 결합을 만듭니다. JSON·WAV·MP4가 정상적으로 생성되면 다른 언어의 도구로 바꾸기도 쉽습니다. 반대로 시간표를 여러 곳에 중복해서 적으면 화면과 소리가 어긋납니다. TECHNIQUE.md가 하나의 시간표를 공유하도록 권하는 이유입니다. 모든 데모가 똑같은 이름의 timeline.js를 쓰는 것은 아닙니다.

4-4. 패턴 ④ 흐름 제어와 잠금으로 자원을 보호한다

core/render/video.mjs는 JPEG를 FFmpeg의 표준 입력으로 보냅니다. 인코딩 옵션은 libx264, -preset medium, -crf 14, yuv420p입니다. 쓰기 버퍼가 차면 drain이나 인코더 종료를 기다리며, 작업자별 영상은 마지막에 concat과 -c copy로 이어 붙입니다.

core/render/slot.mjs의 withMutex()는 디렉토리 생성의 원자성을 이용해 자리 배정을 보호합니다. 추가 작업을 시작할 때 기본 여유 메모리 기준은 30%이지만, 실행 중인 작업이 없으면 하나는 허용합니다. 따라서 이것은 강제 메모리 상한이 아닌 시작 시점의 혼잡 조절입니다. 영상 작업자 수 --workers와 전체 렌더링 수 RENDER_SLOTS도 서로 다른 값입니다.

5디렉토리 구조 해부

STYLE.md는 유지할 스타일 규칙, DEMO.md는 특정 예제 작품의 설명입니다. style.json은 검색·전시용 메타데이터이며, 영상의 장면 전체를 선언하는 공통 설정 파일은 아닙니다. 예를 들어 제목과 분류를 바꾸는 일과, 이야기·그림·소리를 새로 만드는 일은 서로 다릅니다.

plugin/에는 실제 영상 엔진보다 라이브러리를 찾아 연결하는 진입점이 들어 있습니다. 설치 스크립트는 기본 안내·공용 도구를 가져오고, 필요할 때 특정 데모를 추가하는 희소 체크아웃을 사용합니다. 전체 소스를 받는 방식과 스킬의 첫 설치가 차지하는 용량이 다른 이유입니다.

5-1. 언어별 코드 규모

커밋 3961ddb의 파일에서 빈 줄·주석을 포함한 물리적 줄을 센 값입니다. .git, node_modules, .venv, 이름이 vendor인 디렉토리와 package-lock.json은 제외했습니다. HTML 안의 JavaScript는 HTML에 포함되고, 생성된 갤러리·중복 예제·폰트 데이터가 들어간 CSS도 포함됩니다. 따라서 사람이 작성한 고유 로직의 양이나 유지보수 난도를 그대로 나타내지는 않습니다.

같은 다섯 언어·형식 기준으로 core/는 21개 파일·2,278줄, styles/는 1,017개 파일·135,497줄입니다. 데모가 전체 코드 줄 수의 약 95%를 차지합니다. 큰 공용 프레임워크 하나를 공부하기보다, 작은 공용 도구와 다양한 개별 구현을 비교하는 학습에 적합합니다.

5-2. 추천하는 소스 읽기 순서

1. core/README.md → 도구의 입력과 출력을 정리합니다.
2. core/render/page.mjs → 웹페이지가 준비되는 조건을 찾습니다.
3. styles/swiss-motion/demo/main.js → 전역 함수가 실제 장면 함수에 연결되는 지점을 봅니다.
4. styles/swiss-motion/demo/film.js → renderFilm()과 buildEvents()를 비교합니다.
5. core/render/video.mjs → 프레임 분배·캡처·인코딩·정리 순서로 돌아옵니다.

6학습 포인트 (기술별)

6-1. JavaScript: 보간과 결정적인 화면

core/lib.js의 seg(t, a, b)는 시각을 0~1 진행률로 바꾸고, lerp(a, b, t)는 두 값 사이를 계산합니다. ss() 같은 이징 함수는 진행률의 속도감을 바꿉니다. 다음은 이 도우미로 작성한 학습용 장면 함수입니다.

import { seg, lerp, ss } from '/core/lib.js';

// g는 2D 문맥, w와 h는 출력 화면 크기다.
function draw(g, t, w, h) {
  const p = ss(seg(t, 1, 3));
  const x = lerp(w * 0.1, w * 0.8, p);
  g.setTransform(1, 0, 0, 1, 0, 0);
  g.clearRect(0, 0, w, h);
  g.fillStyle = '#a8452f';
  g.fillRect(x, h * 0.45, 80, 80);
}
// 1초 이전에는 시작점, 3초 이후에는 도착점에 머문다.
// draw(2초)를 여러 번 불러도 위치가 누적되지 않는다.

실습 아이디어: 시각을 2초 → 0초 → 2초 순서로 바꿔 그려 보세요. 두 번의 2초 화면이 같아야 합니다. x += speed로 위치를 누적하는 방식이 왜 이 조건을 깨는지 설명해 보세요.

mulberry(seed)는 같은 시드에서 같은 난수열을 만듭니다. 하지만 난수 생성기를 한 번만 만들고 매 프레임 소비하면 호출 순서에 따라 결과가 달라집니다. 입자 속성을 준비 단계에 고정하거나, 프레임·개체 식별자로 난수를 재구성해야 원하는 시각을 독립적으로 그릴 수 있습니다.

6-2. Canvas와 타이포그래피: 상태를 정리하는 습관

styles/swiss-motion/demo/film.js의 renderFilm()은 setTransform(1, 0, 0, 1, 0, 0)으로 좌표 변환을 초기화한 뒤 배경을 채웁니다. 장면 안에서는 save(), translate(), restore()로 변환 범위를 묶습니다. 앞선 장면의 확대·회전이 다음 장면에 남지 않게 하는 패턴입니다.

measureNumeral()은 measureText('4').actualBoundingBoxAscent로 숫자의 실제 높이를 측정합니다. 글꼴의 크기 값과 사람이 보는 글자 높이가 같지 않기 때문입니다. styles/swiss-motion/demo/main.js가 document.fonts.load()를 먼저 기다리는 것도 대체 글꼴로 측정해 배치가 달라지는 문제를 줄이기 위한 순서입니다.

실습 아이디어: 같은 100px 크기로 숫자·한글·영문을 나란히 그리고 실제 경계를 표시하세요. 한글에 필요한 글리프를 가진 폰트를 선택하고, 폰트 준비 전후의 측정값이 어떻게 다른지 비교해 보세요.

6-3. 리듬과 이징: 움직임을 음악의 단위로 바꾸기

styles/swiss-motion/demo/ease.js는 BPM = 120, BEAT = 60 / BPM, E8 = BEAT / 2, E16 = BEAT / 4를 정의합니다. 따라서 한 박은 0.5초, 8분음표는 0.25초입니다. snap(t, t1, d)는 도착 시각 t1을 기준으로 움직임이 미리 시작되게 만듭니다.

cubicBezier(.7, 0, .2, 1)은 입력 진행률에 해당하는 곡선 위치를 이분 탐색으로 구합니다. 전체 작품이 같은 곡선을 사용하면 빠르기와 도착감이 통일됩니다. 이는 웹 UI의 애니메이션 시간을 외우는 공부보다, 영상에서 리듬 규칙을 설계하는 공부에 가깝습니다.

실습 아이디어: 2초에 도착하는 도형 세 개를 각각 한 박, 반 박, 4분의 1박 전에 출발시키세요. 도착 시각을 고정한 채 출발 시각만 바꿔도 움직임의 인상이 달라지는지 관찰합니다.

6-4. WebGL·Three.js: 후처리는 여러 장의 계산이다

core/three/post.js의 makePost()는 DofScenePass → UnrealBloomPass → 색보정·비네팅 → OutputPass를 연결합니다. DofScenePass는 깊이 텍스처로 초점에서 얼마나 벗어났는지 계산하고, 선택적으로 GTAOPass의 주변 가림을 적용합니다.

여기서 ssaa: 2는 가로·세로를 각각 두 배로 처리하므로 픽셀 수는 네 배입니다. 또한 심도 셰이더는 perspectiveDepthToViewZ()를 사용합니다. TECHNIQUE.md는 직교 카메라에 적용하려면 깊이 변환을 바꾸어야 한다고 명시합니다.

실습 아이디어: 먼저 정지한 단순 3D 장면에서 심도·블룸·주변 가림을 하나씩 켠 결과를 비교하세요. 효과를 한꺼번에 켜면 어떤 단계가 화면과 처리량을 바꿨는지 알기 어렵습니다.

6-5. Python 오디오: 소리는 시간축을 가진 숫자 배열

core/audio/sfx.py의 SR = 48000은 1초를 48,000개 표본으로 표현한다는 뜻입니다. thump()는 감쇠하는 저음과 필터링한 잡음을 섞고, whoosh()는 주파수 대역을 움직입니다. add()는 음량과 좌우 위치를 적용해 스테레오 배열에 더합니다.

# 저장소 루트의 Python 대화형 환경에서 사용할 학습용 예시
import numpy as np
from core.audio.sfx import SR, thump, add

buf = np.zeros((int(4 * SR), 2), dtype=np.float32)
add(buf, thump(v=0.8), at=1.5, gain=0.4, pan=0.0)
# 충격음은 72,000번째 표본 위치에서 시작한다.
# 저장·재생 전에는 최대 진폭과 클리핑을 확인한다.

core/audio/sampler.py의 render(events)는 시각·악기·음높이·길이·세기·좌우 위치가 담긴 악보를 스테레오 음원으로 만듭니다. credits(names)는 사용한 샘플의 출처 표기에 필요한 문구를 반환합니다. 공용 도구가 음원뿐 아니라 출처 관리도 돕는다는 점을 볼 수 있습니다.

실습 아이디어: 같은 충격음을 0.5초 간격으로 세 번 배치한 뒤, 좌우 위치와 음량만 다르게 해 보세요. 샘플 라이브러리를 쓰는 실습은 실제 악기 이름을 확인하고 필요한 라이브러리만 준비하는 편이 좋습니다.

6-6. TTS·ASR: 출력물을 다른 관측 경로로 검사하기

core/tts/tts.py는 대사별 WAV와 dur.json을 생성합니다. 기본 음성은 af_bella, 속도는 0.92, 언어는 en-us입니다. core/tts/asr_check.py는 이 소리를 다시 글로 인식해 원문과 비교하고, 단어 시각을 words.json에 기록합니다.

compare()는 영어를 정규화한 단어열로 비교하고, zh·ja·ko는 문자 유사도를 비교합니다. 기본 기준 0.92는 모델의 확신도가 아니라 difflib.SequenceMatcher의 유사도입니다. 고유명사나 숫자는 대사의 asr 필드로 비교용 표기를 따로 둘 수 있습니다.

6-7. 품질 검사: 보기 좋다는 말을 계산 조건으로 바꾸기

core/render/readcheck.mjs의 need()는 화면 글자에 필요한 시간을 계산합니다.

필요 시간 = max(1.5,
               한중일 문자 수 / 4.5
               + 나머지 비공백 문자 수 / 15
               + 1.5)초

예: 공백을 뺀 한글 9글자만 있으면 9 / 4.5 + 1.5 = 3.5초
검사 간격 기본값: 0.04초, 글자 사각형이 화면 안에 있어야 함

같은 식별자라도 문구가 바뀌면 새 텍스트로 처리하며, 처음 완전히 보이는 연속 구간을 검사합니다. TEXTS()가 없거나 검사할 텍스트를 한 번도 반환하지 않으면 종료 코드 2입니다. 이것은 통과가 아니라 검사 불가를 의미합니다. 또한 화면 글자를 OCR로 발견하는 도구가 아니므로 페이지가 모든 대상 문구를 정확히 보고해야 합니다.

core/render/mux.sh는 별도로 오디오 손상과 길이를 검사하고, 두 차례의 loudnorm으로 통합 음량 −14 LUFS, 실제 피크 −1.2 dB를 목표로 최종 합성합니다. 짧은 오디오는 무음으로 채우고, 음량 목표를 벗어나면 경고합니다. 자동 검사가 통과해도 발음의 자연스러움·사실 정확성·미적 완성도는 사람이 확인해야 합니다.

좋은 자동 검사는 “아무 오류도 안 났다”와 “검사할 조건을 실제로 만족했다”를 구분합니다. 실습 아이디어: 일부러 짧게 노출한 문구, 화면 밖 문구, 검사 정보가 없는 장면을 나누어 각각 어떤 결과가 나와야 하는지 먼저 예상해 보세요.

7하드웨어 / 시스템 요구사항

7-1. 문서에 명시된 조건과 코드가 확인하는 조건

7-2. 해상도·작업자·후처리가 부담을 결정한다

기본 출력은 1920×1080, 24 fps, 작업자 3개입니다. takeSize()는 가로·세로 각각 16~8192 범위의 짝수만 허용합니다. 허용되는 최대 크기가 실용적으로 처리 가능한 크기를 보장하지는 않습니다.

1080p RGBA 화면 한 장은 단순 계산으로 약 7.9 MiB입니다. 가로·세로를 두 배로 그리면 한 장만 약 31.6 MiB가 됩니다. 실제 3D 처리에는 깊이·색상·중간 결과용 여러 버퍼와 브라우저 메모리가 더 필요합니다. 48 kHz 스테레오 float32 오디오 1분은 한 배열만 약 22 MiB이고, 믹싱은 여러 배열을 함께 유지합니다.

처리량은 영상 길이뿐 아니라 픽셀 수, 후처리 단계 수, 동시에 열린 브라우저 수에 함께 좌우됩니다. --workers 1은 브라우저 수를 줄이는 방법이고, --size 960x540은 출력 픽셀 수를 줄이는 방법입니다. 단, 작품 코드가 고정 좌표를 사용하면 크기 옵션만 바꿔도 자동으로 화면 구성이 맞춰지는 것은 아닙니다.

7-3. 다운로드 용량은 선택한 제작 단계에 따라 달라진다

용량 수치는 TECHNIQUE.md의 안내값이며, 패키지 변화나 작품별 원본 소재는 별도입니다. 중간 영상·음원·자료 캐시도 디스크를 사용합니다. README의 에이전트 제작 시간 30~60분 역시 안내치이며, 하드웨어별 렌더링 벤치마크는 아닙니다.

8직접 해볼 수 있는 실습 과제

아래 명령은 학습자가 도구와 의존성을 준비한 뒤 수행할 예시입니다. 데모는 완제품 재생성보다 구현 기법을 참고하는 용도로 제공됩니다. styles/와 core/를 직접 바꾸기보다 별도의 films/learn-01/ 같은 연습 프로젝트에 필요한 코드를 작성하세요.

# 저장소 루트에서, 본인이 만든 연습 프로젝트를 대상으로 실행
node core/render/still.mjs films/learn-01 0 1 2 3
node core/render/video.mjs films/learn-01 --fps 24 --workers 1

node core/render/readcheck.mjs films/learn-01
# 이 명령은 화면 글자 검사다. 자막 파일 검사를 대신하지 않는다.

node core/render/events.mjs films/learn-01
# events.json을 읽어 본인이 만든 믹서로 out/mix.wav를 생성한 다음
sh core/render/mux.sh films/learn-01/out/video.mp4 \
  films/learn-01/out/mix.wav films/learn-01/film.mp4 24 0

node core/render/video.mjs films/learn-01 --workers 1 \
  --out films/learn-01/out/one.mp4
node core/render/video.mjs films/learn-01 --workers 3 \
  --out films/learn-01/out/three.mp4

첫 실습의 성공 기준은 화려한 영화 한 편보다, 한 시각의 그림과 소리를 의도대로 재현하고 설명할 수 있는 것입니다.

9관련 기술 심화 학습 로드맵

각 주차는 일정의 예시이며, JavaScript·Python을 처음 배우면 1~2주차를 더 길게 잡아도 됩니다. Three.js와 셰이더는 2D 파이프라인을 이해한 뒤 별도 갈래로 공부하세요. 깊이 버퍼·색 공간·렌더 타깃을 동시에 배우면 문제의 원인을 분리하기 어렵습니다.

학습 순서는 결과를 더 화려하게 만드는 순서보다, 한 단계씩 원인을 설명할 수 있게 되는 순서가 좋습니다. “그림이 틀렸는가, 캡처가 틀렸는가, 인코딩이 틀렸는가”를 나누어 질문할 수 있으면 이 저장소 밖의 자동화·데이터 처리 작업에도 같은 사고방식을 적용할 수 있습니다.

10핵심 키워드 사전

11참고 링크

11-1. 프로젝트와 핵심 소스

• 공식 저장소 · 59종 스타일 갤러리 · 최신 릴리스 태그 thanks
• AGENTS.md — 에이전트의 진입점 · DIRECTOR.md — 연출 지침 · TECHNIQUE.md — 제작 원리
• 공용 도구와 페이지 계약 · video.mjs — 프레임 렌더링
• page.mjs — 브라우저 준비 · serve.mjs — 로컬 파일 제공 · slot.mjs — 동시 실행 제한
• 화면 글자 검사 · 음성 내용 검사 · 최종 합성·음량 검사
• 보간·난수 도우미 · 효과음 합성 · 3D 후처리
• Swiss Motion 데모 소스 · 실제 자료 기반 뉴스 스타일 · 외부 소재·음성의 출처 사례
• Node 의존성 선언 · Node 잠금 파일 · 음성 의존성
• 갤러리 생성기 · Pages 배포 설정 · 개인 스타일 관리

11-2. 관련 기술의 공식 학습 자료

• MDN Canvas 안내 · MDN JavaScript 모듈
• Playwright Page API · Node.js 스트림 · Node.js 하위 프로세스
• Three.js 문서 · FFmpeg 문서 · FFmpeg 필터 문서
• NumPy 문서 · SciPy 신호 처리 · uv 문서
• Kokoro ONNX · faster-whisper · edge-tts
• 프로젝트 LICENSE · CC BY 4.0 안내 · TrendShift

소스 링크는 커밋 3961ddb를 가리킵니다. 외부 기술 문서는 시간이 지나면 최신 버전으로 바뀔 수 있으므로, 예제의 동작은 이 글에 적힌 의존성 버전과 함께 비교하세요.

현재 상태 (2026-10-23 확인)