longtake
onetake(Patrick 제작) 기반, 수직(9:16) 숏폼 플랫폼용으로 수정됨. 변경 사항 및 이유:
CHANGES.md. 수직 방식:references/vertical.md.
제품에 대한 짧은 모션 필름을 제품 자체로부터 만듭니다. 비디오 편집기, 슬라이드쇼 생성기가 아닌 컴포지션(하나의 HTML 파일, window.__seek(t)), 모션 라이브러리(lib/motion.js), 실제 제품에서 녹화된 푸티지, 같은 공간을 공유하는 사운드 팔레트, 그리고 사람이 보기 전에 컷의 리듬과 전달력(carry)을 판단하는 **오라클(oracle)**입니다.
여섯 편의 필름이 이를 가르쳤습니다. motion-web은 세 번의 컷을 거쳤습니다. 첫 번째와 두 번째는 균일한 운율로 인해 'PPT식 하나하나 나열'이라 거부되었습니다(리듬의 절반). Pocket Weather Club은 리듬은 있었지만 여전히 PPT였습니다. v1은 모든 리듬 검사를 통과했으나 각 비트가 이전 비트를 대체했기 때문에 거부되었습니다. v3는 모든 비트가 이전 비트에서 성장할 때 승인되었습니다. 즉, 캐릭터가 헤드라인에 착지하고, 페이지가 카드에서 성장하며, 캐릭터로부터 무대가 열리는 것입니다. 이것이 캐리의 절반입니다. One dot은 조작자(operator)를 추가했습니다. 고정 카메라에서는 '역동적인 추적 운鏡(운동)이 부족하다'는 평가를 받았으나, 각 비트가 프레임하는 대상을 쫓는(지연, 기울임, 안정) 카메라에서는 '운鏡, 렌즈, 물리 모두 문제없음'을 받았습니다. knockon은 인과 관계로 캐리했습니다. 각 비트가 다음 비트를 시작하는 충돌인 가벼운 탁상용 기계입니다. clearing은 규모(scale)로 캐리했습니다. 1년에서 30분, 다시 돌아오는 한 번의 테이크로, 카메라는 화면상의 앵커를 쫓아 1배속과 300배속에서 동일하게 착지하도록 합니다. overlap은 의미의 교훈을 주었습니다. 첫 번째 컷은 '아트는 좋은데 의미가 뭔지 모르겠다'는 평가를 받았고, 레이블이 있는 커서를 추가하면 더 나빠졌습니다. 아이디어가 아트워크에 내장된 후에야 이해되었습니다. 두 개의 노이즈 플레이트에 숨겨진 & 기호가 패스가 일치하는 순간 나타나는 것입니다. 여기 있는 모든 것은 다음 필름이 이 필름들이 끝난 지점에서 시작되도록 하기 위해 존재합니다.
프로토콜이 제공할 수 없는 것 (먼저 읽기)
아래 규칙은 대부분 기록된 거부 사유입니다. 필름이 슬라이드쇼가 되는 것을 막아줍니다. 이것은 최소 기준입니다. 필름이 모든 규칙과 모든 오라클 조건을 통과해도 죽을 수 있습니다. W1(수직 프로모션, 2026-11)이 그랬습니다. carry 1.00, VERDICT PASS였지만, 평가는 '매우 딱딱하고, 참고 영상의 70%도 못 미친다'였습니다. 부족했던 것은 승인된 필름들이 가졌던 바로 그것입니다.
- 모든 비트에서 볼 가치가 있는 소재. onetake 런칭 필름(일반적인 참고 자료)은 v8입니다. 세 개의 프롬프트가 각각 고유한 팔레트와 모션 언어를 가진 완전한 디자인 미니 필름이 됩니다. 시청자는 작업에 대한 레이블이 아닌 작업 그 자체를 봅니다. 먼저 질문하세요: 우리가 가진 가장 아름다운 것은 무엇인가(푸티지, 완성된 필름, 실제 UI)? 그 재료로 필름을 전체 프레임으로 만드세요. 카드와 칩으로 프로세스를 설명하는 콘셉트는 다이어그램이며, 잘 움직이는 다이어그램은 여전히 다이어그램입니다.
- 시계(clock). 모든 강력한 케이스는 음악 그리드에 맞춰 컷합니다. 다운비트에 전송하고, 드롭에서 가장 빠른 스트레치를 배치하며, 침묵 비트에서 멈춥니다. 나레이션이 없으면 음악은 타임라인이지 장식이 아닙니다. '읽을 수 있을 만큼 길게' 타이밍을 맞추면 고른 박자가 되어 딱딱하게 읽힙니다. 사용자의 프로젝트가 음악을 금지한다면, 그 비용이 무엇인지 설명하고 물어보세요.
- 호(arc). 밀도와 속도는 하나의 정점을 향해 쌓이고, 그 후에 해방됩니다. 다섯 개의 동일한 정거장은 리스트입니다.
- 변화 그 자체가 콘텐츠. 참고 자료에서 사물 자체가 변형됩니다(창이 휴대폰으로 리플로우되고, 막대가 필름으로 열림). 정적 비트 사이를 이동하는 모션은 슬라이드 주위의 전환에 불과합니다.
- 여러 번의 검토. 참고 자료는 여덟 번의 검토된 컷을 거쳤습니다. 첫 번째 렌더 전에 훅과 피크의 스틸을 보여주고, 다듬기 전에 드래프트를 보여주세요. 검토되지 않은 패스를 최종본으로 제시하지 마세요.
이 스킬을 사용해야 하는 경우와 사용하지 말아야 하는 경우
- 앱, 페이지, 스킬, 기능의 런칭/티저/소개 클립 — 예.
- 나레이션이 포함된 기능 데모(30~60초)로 제품 사용 모습을 보여주고, 여러 언어일 수 있음 — 예: UI를 녹화하는 대신 재구축합니다(§4,
references/product-demo.md). - 사용자가 참고 클립의 느낌을 원할 때 — 예, §1부터 시작.
- 장편, 토크쇼, 기존 영상 편집 및 전환 — 아니요.
- 사용자가 HyperFrames 또는 Remotion을 명시적으로 언급할 때 — 사용자가 언급한 도구를 사용하세요. 그 외에는 이 파이프라인을 사용합니다.
프로토콜 — 이 순서대로, 건너뛰지 않음
1 · 아무것도 건드리기 전에 참고 영상 분석 (硬规则/엄격 규칙)
python3 scripts/analyze_ref.py ref.mp4 --out ana/ # 에너지 맵, 컷, 정지 상태, 콘택트 시트, 모션 라인
에너지 맵과 시트를 읽고 필름이 일치해야 하는 수치를 기록하세요. 에너지 맵은 필름이 언제 움직이는지 알려줍니다. motion: 라인은 어떻게 움직이는지 알려줍니다. 중간 t80(스냅 또는 S-커브)과 스미어(smear, 모션 블러로 렌더링되었는지 여부)입니다. motion-web 필름을 결정한 요소: 참고 영상은 34%가 완전히 정지, 두 번의 버스트에 7개의 하드 컷이 있었으며, 모든 요소를 작게 유지하고 많은 여백을 사용했습니다. 한 번 보는 것만으로는 명확하지 않으며, 측정하지 않고 만든 필름은 두 번이나 균일한 운율로 나왔습니다. references/reference-deconstruction.md.
참고 영상의 수치는 아래 장르 규칙보다 우선합니다. '작은 요소, 큰 배경'과 '시간의 1/3은 정지'는 motion-web에서 측정되었습니다. onetake 런칭 필름은 약 10% 정지 상태이며 대부분 전체 프레임입니다. W1은 이에 반해 장르 규칙을 따랐고(정지 0.50, 빈 배경), 결과는 비어 있고 느렸습니다. 정지 비율, 프레임 채움 정도, 컷 수와 가장 밀집된 구간 위치를 기록하고, 그것들과 일치시키세요. 또한 참고 영상의 비트가 무엇으로 구성되어 있는지(완성된 디자인 조각? 실제 UI? 타입?)와 음악에 맞춰 컷하는지도 기록하세요. 이것이 §2의 입력입니다.
2 · 콘셉트 — 비트 시트 전에 세 가지 중심 아이디어 (硬规则/엄격 규칙)
콘셉트는 제품이 아닌 그림에 대한 한 문장입니다. 필름을 구성하는 단일 아이디어입니다. 아이디어가 다른 세 가지를 쓰세요. 같은 카드로 구성된 세 가지 이야기가 아닙니다.
- 하나의 요소가 모든 것을 통해 변형 — 점이 커서가 되고, 스킬 리스트로 분할되며, 로딩 링으로 속이 비고, 스프링 곡선으로 펼쳐져, 워드마크의 i 위에 점으로 착지합니다.
- 하나의 카메라 움직임이 규모를 관통 — 커서 안에서 시작하여 입력 필드로 나오고, 전송 버튼을 통해 작업 속으로 다이빙하여, 완성된 필름을 통해 나옵니다. (
cases/clearing-15s: 1년 → 하루 → 30분 → 다시) - 이전/이후 분할 — 왼쪽에는 슬라이드쇼로, 오른쪽에는 캐리된 동일한 비트를 보여주다가, 오른쪽이 왼쪽으로 침입합니다.
- 연쇄 반응 — 모든 비트는 다음 비트를 시작하는 충돌입니다. (
cases/knockon-15s) - 또는 물리적 은유, 하나의 연속적인 표면, 타이포그래피 시스템…
각 콘셉트에 대해: 훅 프레임, 모든 경계를 전달하는 것, 배제하는 것(카드 없음? 컷 없음?), 그리고 룩(look) — looks/의 프리셋(python3 scripts/look.py sheet → gallery/sheets/looks.png: paper, dusk, tabletop, ultramarine, riso, ember, 각각 승인된 필름에서 측정됨), 제품 자체의 색상(look.py from-shot shots/*.png --out look.json), 또는 이 필름을 위해 새로 만든 것. 세 가지를 보여주고 사용자가 선택하게 하세요. 템플릿의 이야기(운율적 단어 → 입력된 프롬프트 → 체크리스트 → 결과 → 스타카토 히트 → 검은색 워드마크)는 하나의 콘셉트이며, 절대 기본값이 될 수 없습니다. 이 템플릿으로 만든 운영 데모는 모든 오라클 조건을 통과했지만(carry 1.00), 'motion web과 매우 비슷하다… 창의성이 없다'며 반송되었습니다. 위 목록의 예시와 모든 케이스에도 동일하게 적용됩니다. 'one dot'을 첫 번째 예시이기 때문에 선택하는 것은 콘셉트가 아니라 모방입니다(W1이 그렇게 했고, 다이어그램으로 읽혔습니다). 각 콘셉트를 두 가지 질문으로 테스트하세요: 가장 바쁜 1초에 시청자는 무엇을 보고 있는가? (레이블이 아닌 아름다운 것이어야 함)와 그것 자체가 무엇으로 변하는가?
수직(9:16) 필름은 가로 필름을 회전한 것이 아닙니다. 프레임은 높은 기둥이므로 위에서 아래로 채우고, 재료가 가장자리 밖으로 나가도록 하며, 플랫폼의 안전 영역(캡션과 버튼이 하단 약 20%와 오른쪽 가장자리를 덮음)을 유지하세요. stills.py --width 1080 --height 1920는 시트에서 종횡비를 유지합니다. 중첩 포털 다이브(nested-portal dive)와 그 수치를 포함한 방법: references/vertical.md, 케이스 cases/huazhong-dongtian-22s/.
3 · 리듬 그리고 캐리로 스토리보드 작성
선택한 콘셉트를 비트 시트로 작성하세요: t · 비트 · 움직이는 것 · 정지한 것 · 다음 비트로 전달되는 것.
리듬. 샷 길이를 4배 이상 변화시키세요(0.25초 단어 옆에 2.5초 홀드). 그림과 소리에서 거의 침묵에 가까운 구간이 적어도 한 곳 이상 있어야 합니다. 하나의 이야기(콘셉트의 이야기)여야 하며, 카탈로그가 아니어야 합니다. 요소 크기와 배경은 참고 영상을 따릅니다(§1).
호와 시계. 비트 시트 전에 음악을 선택하고, 다운비트, 침묵 간격, 드롭을 찾아(scripts/beat_grid.py), 시트의 모든 t를 해당 트랙의 비트로 작성하세요. 그림의 정점은 드롭에 위치해야 합니다.
캐리. 모든 섹션 경계에서, 섹션을 살아남아 이동하는 것이 무엇인지 이름을 지정하세요. 손, 대상, 다음 장면이 되는 컨테이너(morphRect), 대상에서 열리는 무대(iris), 카드 안으로 밀어 넣어 카드가 장면이 될 때까지 밀어 넣는 카메라(zoomThrough), 잠금 장치로 접히는 캐스트(gather → seal). 아무것도 살아남지 못하면 리듬에 관계없이 슬라이드 변경입니다. 베어 컷은 히트 버스트와 엔드 카드에 속하며, 콘셉트가 이를 포함할 때만 사용합니다. references/rhythm.md.
4 · 실제 제품에서 푸티지 녹화 — 또는 스크린샷에서 UI 재구축
python3 scripts/record_footage.py footage.json --out footage/
Playwright로 실시간으로 구동되는 실제 페이지(벽시계 속도의 스윕, 휠 스텝, 클릭)를 표시할 크기로 녹화하고, 입력이 시작되는 순간 마젠타 마커를 주입하여 나중에 액션 프레임을 찾을 수 있게 합니다. 프레임은 30fps JPEG로 출력됩니다. 포인터 경로는 저장되어 컴포지션이 손을 다시 그릴 수 있습니다. 시청자는 결과뿐만 아니라 원인도 볼 수 있어야 합니다. 구성 형식은 스크립트의 독스트링에 있습니다.
또는 재구축하세요. 필름이 앱의 기능을 설명할 때(특히 음성이나 다른 언어가 포함될 때), 사용자는 참고 촬영만 스크린샷이나 녹화하고 UI는 참고 영상의 자체 픽셀 프레임으로 HTML로 재구축됩니다. 모든 문자열은 테이블에 저장되고, 모든 상태는 순수 set(state)로 작성되며, 복제본은 카메라가 어떤 줌에서든 근접할 수 있는 평면에 위치합니다. 하이라이트는 DOM에서 측정됩니다(lib/ui_kit.js). 나레이션은 scripts/vo_tools.py를 통해 제공됩니다. 오디션, 대사, 단어 시간, 자막. 두 번째 언어는 동일한 컴포지션에 ?lang=으로 제공되며, VO는 동일한 의미의 단어에 대한 UIK.timeWarp 노트로 저작된 타임라인에 매핑되고, 소스 언어와 픽셀 단위로 동일한지 scripts/frame_diff.py로 확인됩니다. 콘텐츠는 제품의 실제 출력물이어야 합니다. 방법, 수치, 세부 사항: references/product-demo.md. 이것은 기술이지 룩이 아닙니다. 팔레트, 무대, 카메라 문법, 전환은 매번 §2에서 새롭게 선택됩니다.
5 · 컴포지션 — 하나의 파일, 시간의 순수 함수, 라이브러리의 모션
mkdir -p cases/my-film && cp templates/comp.html lib/motion.js cases/my-film/ # 템플릿은 motion.js → window.OM 로드
python3 scripts/probe.py my-film/comp.html # 처음부터 끝까지 재생되는 즉시: 각 경계를 전달하는 것, 각 모션의 곡선
움직임의 속도 곡선에 따른 6개의 프레임을 보여주는 gallery/sheets/<move>.png를 보고 모션을 선택하세요. 라이브러리에는 39개의 모션이 있습니다. 입장(entrances), 캐리(carries), 접촉 및 라이브 시뮬레이션(contact and live sims), 카메라 및 프로젝션 도우미, 유체 세트(빛의 장, 잔물결, 실크, 벨트, SwiftUI 스프링). 각각은 시간의 함수로, DOM 변환 또는 캔버스 호출을 위한 숫자를 반환합니다. 고정 상수로 스프링이나 이즈(ease)를 다시 유도하지 마세요. 템플릿은 motion-web 필름입니다(운율적 단어, 입력된 프롬프트, 체크리스트, 플라이스루, 라이브 시뮬레이션, 홀드, 스타카토 히트, 모든 시뮬레이션이 읽는 하나의 연속적인 손 경로). §2에서 선택한 콘셉트가 바로 그 콘셉트일 때만 템플릿의 비트를 복사하세요. 그렇지 않으면 템플릿의 계약과 도우미를 유지하고 콘셉트의 자체 비트를 작성하세요. 모든 것은 f(t)입니다. 시뮬레이션은 240Hz로 한 번 사전 시뮬레이션되고 샘플링됩니다. Preview ?play, pin ?t=6.4&hud. references/motion-library.md, references/composition.md.
룩은 컴포지션과 함께 제공됩니다. python3 scripts/look.py apply ember cases/my-film/comp.html(또는 look.json)은 look.js를 그 옆에 작성합니다. 8가지 색상을 CSS 변수와 LOOK.color로 제공하고, 컴포지션이 설정하는 글리프로 서브셋되고 인라인된 3개의 OFL 폰트를 제공하여 file:// 렌더가 실제 타입을 얻도록 합니다. 컴포지션의 스크립트 전에 로드하고, var(--ink) / var(--display) 또는 LOOK.font('display', 96)을 사용하여 작성하며, LOOK.ready에 window.__ready를 체인하세요. 복사 변경 후 다시 실행하세요. 폰트에 없는 문자를 알려줍니다(--cjk <font> for Chinese / Japanese / Korean).
카메라: 키프레임으로 설정하지만, 운영하듯이. OM.camera(t, keys)는 각 비트가 필요로 하는 곳에 카메라를 배치합니다. 운영자의 느낌은 키가 어떻게 배치되는지에서 옵니다. 대상을 따라잡기 위해 sineInOut으로 대상보다 약 0.1초 앞서 키를 설정하고, expoInOut으로 스냅 전에 착지 지점을 키설정하여 휘두르며, 손(느린 2-사인 플로트, 홀드에서는 0)과 OM.shake를 모든 착지에 추가합니다. 더 뒤쪽에 희미한 OM.lattice를 그립니다. 빈 배경에서는 움직임이 읽히지 않습니다. 카메라를 사용하면 __track은 화면 박스(OM.projectBox)를 반환하고, __motion은 이동을 렌더러에 전달하며, __meta.inFrame은 절대 프레임 밖으로 나가서는 안 되는 요소를 지정합니다. 코드가 포함된 방법: references/composition.md → A camera.
6 · 렌더링 — 승인 전까지 1080p30 드래프트, 4K60은 승인 후에만
python3 scripts/stills.py comp.html --times 0.7,2.4,3.8,6.2,9.9,12.7 --out stills.png # 렌더 전에 확인
python3 scripts/render.py comp.html --out draft.mp4 --sfx sfx.wav # 1920×1080 · 30 fps · 180° 셔터
python3 scripts/render.py comp.html --out film.mp4 --final --sfx sfx.wav # 3840×2160 · 60 fps, 컷이 승인된 후에만
셔터는 실제 모션 블러입니다. 각 움직이는 프레임은 열린 셔터를 가로질러 여러 번 탐색하고 선형 광으로 평균화됩니다. 정적인 홀드는 감지되어 이를 건너<0xEB><0x9B><0x80>니다. 캡처는 Chrome 스크린샷(약 150ms, 페이지 자체는 1ms 이내에 그려짐)이므로 render.py는 --workers 브라우저를 병렬 프로세스로 실행합니다(기본값 코어 − 2, 최대 16). 파이프의 속도는 메인 머신과 같은 존에서 하나의 병목입니다. references/rendering.md.
7 · 리듬과 캐리에 대해 검증
python3 scripts/oracle.py draft.mp4 ref.mp4 --ana ana/
오라클은 하나의 질문에 답합니다: 이 컷이 리듬을 가지고 있으며 전달되는가? 8개의 다리(leg)를 측정합니다. 리듬(펄스 규칙성, 사일런스, 스냅 프로필, 컷 타이밍 대 그리드)과 캐리(경계 생존자, 연속적인 손 경로, 프레임 내 액션 중심, 막간 저크). 각각은 단일 스코어를 생성하며, 종합 판결은 PASS 또는 REVIEW입니다. 점수는 카테고리로나 상대적입니다. 수치: 리듬(참고 영상 대비 RMS) ≤ 0.30을 통과, 캐리(참고 영상 대비 상관 관계) ≥ 0.70을 통과. REVIEW는 컷이 거부되었다는 의미가 아니라, 오라클이 수치로 판단할 수 없는 무언가를 보고 있음을 의미합니다. 스틸을 보여주고, 타이밍(1/4프레임 또는 1/8프레임 단위로)을 조정하고, 화면에서 요소를 더 크거나 작게 만들고, 다시 시도하세요. references/oracle.md.
8 · 전달
python3 scripts/teleport.py film.mp4 --title "My Film" --meta meta.json --out dist/
하나의 파일을 내보냅니다. 그 파일은 태그가 지정된 출력물입니다. 준비가 되면 폴더를 정리하는 scripts/clean.sh가 있습니다.
참고 자료(레퍼런스)
references/rhythm.md— 비트 길이가 다른 이유, 특별한 것이 잘린 방법, 그리고 침묵.references/composition.md— comp.html이 작동하는 방식,__seek(t), 카메라, 그리드,lib/.references/motion-library.md— 39개의 모션과 사용 시기.references/rendering.md— 셔터, 색상, 통과 기준.references/oracle.md— 오라클의 각 다리와 점수가 의미하는 것.references/vertical.md— 수직 9:16 방법, 중첩 포털 다이브.references/product-demo.md— UI 재구축 방법과 나레이션.
프로젝트 구조
longtake/
├── libraries/
│ ├── motion.js # 39개의 모션 (OM)
│ └── ui_kit.js # DOM에서 UI 측정
├── scripts/
│ ├── analyze_ref.py # 참고 영상 수치화
│ ├── record_footage.py # Playwright 푸티지
│ ├── look.py # 룩 시스템
│ ├── beat_grid.py # 음악 비트 그리드
│ ├── stills.py # 스틸 추출
│ ├── render.py # 렌더러
│ ├── oracle.py # 검증 오라클
│ ├── probe.py # 컴포지션 분석
│ ├── teleport.py # 전달
│ ├── vo_tools.py # 나레이션 도구
│ ├── frame_diff.py # 프레임 차이
│ └── clean.sh # 정리
├── templates/
│ ├── comp.html # 컴포지션 템플릿
│ └── look.json # 룩 템플릿
├── looks/ # 룩 프리셋
├── gallery/sheets/ # 모션 시트, 룩 시트
├── references/ # 마크다운 참고 자료
├── cases/ # 예제 케이스
│ ├── clearing-15s/
│ ├── knockon-15s/
│ └── huazhong-dongtian-22s/
├── CHANGES.md # onetake 대비 변경 사항
└── README.md
파이프라인 (긴 버전)
이 스킬의 파이프라인은 8단계로 진행됩니다. 각 단계는 엄격히 순서대로 완료되어야 합니다.
- 참고 영상 분석 (
scripts/analyze_ref.py) — 참고 영상의 정적 비율, 컷 수, 요소 크기 등 수치를 측정하여 필름의 기준을 정합니다. - 콘셉트 개발 — 세 가지 다른 시각적 아이디어를 제시하고, 사용자가 선택하게 합니다.
- 비트 시트 스토리보드 — 리듬(다양한 샷 길이), 호(정점), 캐리(경계 전달)를 명시합니다.
- 푸티지 녹화 또는 UI 재구축 — 실제 앱 페이지를 녹화하거나, HTML로 UI를 재구축합니다.
- 컴포지션 — 템플릿, 모션 라이브러리, 룩을 사용하여 하나의 HTML 파일을 만듭니다.
- 렌더링 — 드래프트는 1080p30, 최종본은 4K60으로 렌더링합니다.
- 검증 — 오라클로 리듬과 캐리를 확인합니다.
- 전달 — 최종 파일을 내보냅니다.