“Opus로 만들었다”는 말에서 한 단계 더 들어가기
Claude Opus 5.5로 만든 영상이 인상적일 때, 바로 같은 프롬프트를 찾고 싶어집니다. 그런데 완성된 영상만으로는 모델이 무엇을 했고, 어떤 프로그램이 화면을 그렸으며, 사람이 무엇을 제공했는지 알기 어렵습니다. 짧은 요청 하나 뒤에 이미 완성된 애니메이션 엔진과 브랜드 자산이 있을 수도 있고, 다른 영상 생성 모델이 장면을 만들었을 수도 있습니다.
athemeroy/awesome-opus-5-5-videos는 이 차이를 조사한 영상 사례·제작 경로·근거의 큐레이션 저장소입니다. 직접 영상을 생성하는 엔진이나 Claude Code에 설치하는 영상 제작 플러그인은 아닙니다. 공개 사례를 읽고 제작 방식을 선택하는 데 쓰는 자료집이며, CSV에서 사례 페이지와 통계 도표를 만드는 Python 스크립트가 함께 있습니다.
이 글에서는 먼저 저장소의 데이터 흐름을 살펴보고, 서로 다른 제작 경로의 사례 일곱 개를 읽습니다. 그다음 처음 시도할 작업을 정하는 법, 한국어 프롬프트 템플릿, 결과를 검수하는 기준을 연결합니다. 분석 버전은 f0728e6f로 시작하는 고정 커밋이며, 대상 코드를 설치하거나 실행하지 않고 문서·데이터·스크립트를 정적으로 읽었습니다. 영상 전체의 재생·청취와 실제 제작 실험은 수행하지 않았습니다.
1. 먼저 구분할 것: 모델, 렌더러, 제작 환경
Anthropic의 공식 Opus 5.5 사양은 입력을 텍스트·이미지, 출력을 텍스트로 설명합니다. 따라서 이 저장소에서 말하는 “Opus 영상”은 모델의 응답이 곧바로 영상 파일이라는 뜻이 아닙니다. 모델이 코드나 제작 지시를 작성하고, 도구가 프레임과 음성을 만들며, 렌더링·인코딩 과정을 거쳐 MP4가 나오는 구조로 이해해야 합니다. 공식 모델 사양
여기서 렌더러(renderer)는 장면·도형·시간 정보를 실제 화면으로 계산하는 프로그램입니다. Canvas는 브라우저에서 그림을 그리는 인터페이스이고, Manim은 수학·설명용 애니메이션, Remotion은 코드로 영상 장면을 구성하는 경로에 등장합니다. Blender는 3D 장면을 구성하고 렌더링하는 도구입니다. 이들은 Opus 자체의 기능 이름이 아니라, Opus가 코드를 작성하거나 조작할 수 있는 별도 도구입니다. 저장소의 제작 경로 가이드는 작업별로 이러한 역할을 구분합니다.
| 구성 요소 | 맡는 일 | 결과를 판단할 때 볼 것 |
|---|---|---|
| Opus 5.5 | 기획, 분해, 코드 작성, 도구 호출 계획, 수정 | 실제로 수행한 역할과 대화·작업 기록 |
| 코드 기반 렌더러 | 시간에 따른 도형·텍스트·3D 장면 계산 | 소스, 자산, 렌더 명령, 반복 재현성 |
| 외부 이미지·영상 모델 | 이미지나 움직이는 장면 생성 | 모델·버전, 참고 이미지, 생성 시도와 선택 과정 |
| 음성·음악·편집 도구 | 내레이션, 음악, 합성, 인코딩 | 실제 사용한 서비스, 음원, 편집 프로젝트 |
| 사람 | 사실·자산 제공, 미적 판단, 오류 수정, 최종 승인 | 어느 단계에서 무엇을 고쳤는지 |
API 호출만으로 완성 MP4가 반환되는 저장소도 아닙니다. Claude Code 같은 파일·명령 실행 환경에서 제작용 프로젝트를 다루거나, 별도 애플리케이션이 모델과 렌더러를 연결해야 합니다. 이 레포를 읽는 단계에는 모델 API 키가 필요하지 않습니다. 제작 단계의 실행 환경과 렌더러 설치는 선택한 외부 프로젝트의 문서를 따라야 하며, 이 저장소 전체에 통용되는 하나의 설치 명령은 없습니다.
2. 저장소는 어떻게 근거를 정리하나요?
2.1 숫자의 단위부터 다릅니다
README와 고정 스냅샷에는 후보 게시물 1,511개, MP4가 있는 게시물 1,419개, 첨부 MP4 1,449개, SHA-256 기준 서로 다른 파일 1,401개, 선별해 검토한 사례 168개가 기록되어 있습니다. 이 수들은 같은 것을 세지 않습니다. 한 게시물에 여러 영상이 있을 수 있고, 여러 게시물이 동일한 영상 파일을 재게시할 수도 있습니다. 스냅샷 데이터
또한 1,401개 파일 중 yes 980개와 likely 139개를 합한 1,119개는 분류기가 Opus 관여 가능성을 부여한 표본입니다. 1,119개의 독립 제작 사례가 검증되었다는 뜻이 아닙니다. 168개 사례는 별도로 선정한 검토 집합입니다. 전체 X 게시물의 빈도나 특정 모델의 성공률을 추정하는 무작위 표본도 아닙니다.
수집 마감은 2026년 9월 26일 중국 표준시 21:05, 한국 시간 22:05입니다. 이후 추가된 일곱 사례는 별도 문서에 있고, 기존 1,401파일·168사례의 분모에는 합산되지 않습니다. 관심도 수치도 관측 시점이 있는 좋아요·조회수이며 품질 점수가 아닙니다. README의 수집 범위와 추가 사례 구분
2.2 입력에서 출력까지의 실제 흐름
리뷰어 작성, 분석 커밋 기준입니다. 위 행은 사례 목록 생성, 아래 행은 통계·차트 생성 경로입니다. 원본 영상 수집·아홉 프레임 추출은 공개 데이터의 상류 작업이며 이 그림의 생성 스크립트가 영상 제작을 수행하는 것은 아닙니다. 근거: 사례 생성기, 통계 집계, 차트 입력과 출력.
첫 번째 진입점은 scripts/generate_cases.py입니다. 이 스크립트는 data/cases.csv를 읽고 사례별 제작 경로, 제작자의 설명, 저장소 측 관찰, 검토 메모, 길이, 원본 게시물 주소를 사용합니다. 특히 creator_disclosure와 hypit_observation, review_note가 분리되어 있어 “제작자가 말한 것”과 “조사자가 본 것”을 한 문장으로 합치지 않을 수 있습니다.
read_cases()는 CSV 열의 이름과 순서까지 검사합니다. 필수 값이 비어 있거나, X 원문 URL 형식이 다르거나, 같은 게시물 ID가 반복되거나, 미정의 제작 경로가 나오면 오류를 냅니다. hypit_status가 tile_ok인지, 대응 썸네일이 있는지, 길이가 양의 유한 수인지도 확인합니다. 이 검사는 데이터 입력의 일관성을 보호합니다. tile_ok라는 문자열이나 썸네일의 존재를 검사하는 것이 영상의 품질·제작자 주장을 다시 검증하는 것은 아닙니다. 입력 검증 구현
이후 render()가 제작 경로별 사례 수와 표를 만들고 docs/cases-index.zh-CN.md에 대응하는 문자열을 구성합니다. 각 행에는 원문 링크, 미리보기 길이, 아홉 프레임 관찰 메모가 들어갑니다. 관찰 문장의 오래된 길이 표기가 duration_s와 다를 수 있다는 문제도 코드에 반영되어 있습니다. 다만 앞부분의 독립된 길이 표현을 제거하는 정리일 뿐, 왜 두 값이 달랐는지를 자동으로 규명하는 기능은 아닙니다. 문장 정리와 페이지 구성
--check를 받으면 디스크에 문서를 쓰지 않고, CSV로부터 만든 예상 문자열과 커밋된 문서의 문자열을 비교합니다. 차이가 있으면 diff와 실패 코드를 반환합니다. 입력을 바꿨는데 생성 문서를 갱신하지 않은 상황을 잡는 장치입니다. 이 옵션 없이 실행하면 생성된 문서를 기록합니다. 진입점과 분기
두 번째 경로인 generate_statistics.py는 사례 CSV에 corpus-snapshot.json과 domain-style.csv를 더합니다. 후보·첨부·중복 파일 수 사이의 등식, 사례 수, 분류 결과의 개수가 맞는지 먼저 검사합니다. 사례와 분류 파일을 연결할 때는 게시물 ID와 길이 차이 0.05초 이내라는 조건을 사용하고, 대응 행이 정확히 하나인지 확인합니다. 공개 데이터끼리의 일관성을 강하게 요구하는 구조이지만, 이 조건도 원본 미디어의 SHA를 다시 계산하는 절차는 아닙니다. 집계와 연결 조건
그다음 yes만 포함한 집합과 yes·likely를 포함한 집합을 나누고, 도메인·스타일별 개수와 교차표를 만듭니다. 이렇게 하면 “가능성이 있다”는 판단을 포함했을 때 결과가 달라지는지 비교할 수 있습니다. generate_stat_charts.py는 별도의 독립 집계를 만들지 않고 이 summary()를 가져와 스타일 도표, 미리보기 길이 도표, 도메인×스타일 히트맵을 SVG로 출력합니다. 문서와 도표가 같은 검증 함수를 공유하는 점이 유지보수상 장점입니다. 집합 분리 · SVG 생성 진입점
2.3 이 구현이 재현하는 것과 재현하지 못하는 것
공개 CSV를 기준으로 사례 목록과 통계를 다시 계산하는 경로는 확인할 수 있습니다. 반면 원본 MP4, 원시 검색 응답, 전체 아홉 프레임 접촉 시트는 배포하지 않습니다. 따라서 공개 clone만으로 수집 결과, 원본 바이트 중복 제거, 각 모델의 실제 호출 기록까지 재현할 수는 없습니다. 통계 스크립트 자체도 이 경계를 명시합니다. 스크립트의 재현 범위
초보 독자에게는 스크립트를 실행하는 것보다, 먼저 사례 목록에서 원하는 결과를 고르고 근거 비교 문서를 읽는 사용법이 적합합니다. 생성 스크립트는 자료집을 유지하는 도구이며, 영상을 제작하기 위한 필수 준비 단계가 아닙니다.
3. 사례 일곱 개에서 읽어낼 제작 방식
아래의 제작자 설명과 저장소 관찰은 해당 저장소가 기록한 내용입니다. 이번 리뷰에서 직접 확인한 것은 그 문서·데이터의 구분과 코드 구조이며, 원본 X 영상을 새로 재생·청취하거나 연결된 외부 제작 엔진을 실행한 것이 아닙니다. 사례의 장면 설명은 저장소 측 아홉 프레임 관찰에 한정합니다. 링크는 제작자 원문으로 연결하며, 외부 영상과 썸네일을 이 글에 복제하지 않았습니다.
사례 1. 개미 군집: 완성 영상과 대응하는 프로젝트
제작자 설명: Node Canvas 애니메이션에 개미의 관절·표현 규칙, 장면 규칙, 소리 스크립트와 FFmpeg 렌더링을 사용했습니다. 저장소는 완성 작품에 대응하는 파일과 프레임 점검 규칙이 있는 공개 프로젝트를 근거로 연결합니다.
저장소 관찰: 샘플 프레임은 개미 스케치에서 색이 있는 개미, 잎 운반, 지하 군집과 코드 테마의 끝 장면으로 이어집니다. 프로젝트와 영상의 시간·장면이 대응한다고 기록되어 있습니다. 그러나 전체 Claude 대화나 코드 각 줄의 작성 주체, 음성 품질은 입증하지 못합니다. 사례 기록
배울 점: 캐릭터 모양과 동작 규칙을 재사용할 수 있으면 다음 요청은 짧아집니다. 그때 짧은 프롬프트의 성과에는 기존 엔진이 포함됩니다. 처음 시도하는 사람에게 필요한 것은 문장 하나의 복사보다, 캐릭터·장면·소리·출력 규칙이 어디에 준비되어 있는지 파악하는 일입니다.
사례 2. 브라우저 내부 설명: 도식이 움직일 때 생기는 검수 책임
제작자 설명: JavaScript로 프레임을 그렸으며 이런 데모의 상당수가 한 번의 요청으로 만들어졌다고 설명합니다. 검토 기록에는 이 영상과 대응하는 소스 저장소가 없습니다.
저장소 관찰: DNS/HTTP, DOM, 페이지 그리기와 레이아웃을 나타내는 도식들이 보입니다. 모든 기술 설명의 정확성, 해당 영상의 실제 요청 횟수, 샘플 사이 움직임의 품질은 검증 범위 밖입니다. 사례 기록
배울 점: 논문이나 기술 문서를 영상으로 바꿀 때 핵심 입력은 검증된 사실 목록과 설명 순서입니다. 화살표가 자연스럽게 움직여도 원인과 결과가 뒤바뀔 수 있습니다. 장면마다 “무엇이 입력되고 무엇이 바뀌는가”를 원문과 대조해야 합니다.
사례 3. Clearwater: 그럴듯한 물과 검증된 물리의 차이
제작자 설명: 참고 영상을 제공해 Opus가 WebGL2 얕은 물 데모를 만들었다고 설명합니다. 저장소는 셰이더, FFT 파도, 물결과 페이지에 포함된 생성 자갈 텍스처를 설명하는 공개 프로젝트를 근거로 듭니다.
저장소 관찰: 샘플에는 얕은 물 주변을 이동하는 카메라와 물결 변화가 있습니다. 이 화면만으로 물리 정확성이나 한 번에 제작했다는 주장을 입증할 수는 없습니다. 특히 실행 중 외부 파일을 받지 않는다는 것과 텍스처·시각 자산이 없다는 것은 다릅니다. 사례 기록
배울 점: 데이터과학 설명 영상에서도 시각 효과와 과학적 주장에 서로 다른 검수가 필요합니다. 물결·입자·확산을 멋있게 표현하는 작업과 방정식·단위·경계조건을 만족하는 시뮬레이션은 다른 납품물입니다. 후자를 요구한다면 참고 데이터와 허용 오차를 함께 지정해야 합니다.
사례 4. Social SDK 홍보 영상: 준비된 제품 자산의 가치
제작자 설명: 후속 설명에는 제품 코드, 애니메이션 컴포넌트, 랜딩 페이지, 브랜드 디자인과 장면 연출이 입력으로 있었다고 나옵니다. 주로 Opus를 사용하되 어려운 부분에는 Fable 5.1을 사용했고, Remotion에서 HyperFrames로 바꾸며 반복 수정했다는 설명도 있습니다.
저장소 관찰: 채팅, 문서, 앱 화면과 Social SDK 브랜드가 샘플에 등장합니다. 영상의 첫 게시물만 읽으면 드러나지 않는 제작 과정이며, 어느 모델·렌더러가 어떤 장면을 만들었는지는 전체 로그 없이는 확정할 수 없습니다. 사례 기록
배울 점: 제품 홍보 프롬프트에는 실제 화면과 브랜드 규칙을 넣는 편이 구체적인 검수에 유리합니다. “혁신적인 서비스를 보여줘”보다 실제 기능 세 가지와 해당 화면을 연결하는 요청이 납품 기준을 명확하게 만듭니다. 매력적인 문구와 실제 지원 기능이 다르지 않은지도 사람이 확인해야 합니다.
사례 5. 뮤직비디오: 작곡·영상·편집을 나눈 파이프라인
제작자 설명: Opus가 곡과 영상의 작성·연출을 맡고, 음악은 Suno v6, 영상 클립은 Seedance 2.5, 편집은 Tesseract가 담당했다고 밝힙니다. 서비스 호출 기록이나 편집 가능한 프로젝트는 검토 자료에 없습니다.
저장소 관찰: 복고풍 TV·콜라주, 공연자, 타이포그래피와 반복되는 “SLOP-TV” 오버레이가 나타납니다. 개별 서비스 호출이나 픽셀의 생성 주체를 샘플 프레임만으로 확인할 수는 없습니다. 사례 기록
배울 점: Opus의 기여를 연출과 조율로 설명해도 충분히 의미가 있습니다. 작업 요청에는 장면별 참고 이미지, 생성 모델, 시도 횟수, 선택 이유를 남기도록 해야 이후 수정할 장면과 비용의 원인을 추적할 수 있습니다.
사례 6. 말하는 사람을 선화로 재구성: 보존해야 할 조건
실사 설명 영상의 선화 재구성 원문 — @AxtonLiu
제작자 설명: 기존 83초 발화 영상을 제공하고 원래 오디오·자막·길이를 유지하면서, 원형 화자 화면과 설명용 선화 장면을 넣도록 요청했습니다.
저장소 관찰: 반복되는 화자 화면, 손으로 그린 듯한 도식과 자막을 기록합니다. 편집 가능한 프로젝트는 제공되지 않았고, 모든 구간의 동기화나 사람의 개입이 없었다는 주장은 확인되지 않았습니다. 사례 기록
배울 점: 프롬프트에는 원하는 스타일만큼 바꾸지 않을 요소가 중요합니다. 기존 강의에 도식을 더한다면 음성·정보 순서·정확한 용어를 고정하고 화면만 수정하는 편집 계약을 먼저 정의할 수 있습니다. 원래 사람의 설명과 음성을 생성 모델의 성과로 다시 표시해서는 안 됩니다.
사례 7. Canvas 게임: 영상이 결과물의 전부가 아닌 경우
제작자 설명: 조작, 문, 전투와 조명을 포함하는 단일 HTML/JavaScript Canvas 게임을 요청했습니다. 상세 프롬프트는 공개되어 있으나 한 번의 요청과 35분이라는 제작 설명을 확인할 실행 로그는 검토 자료에 없습니다.
저장소 관찰: 횡스크롤 게임, HUD, 전투, 문 퍼즐과 메뉴가 보입니다. 녹화만으로 모든 레벨·적 동작·플레이 가능성을 검증할 수는 없습니다. 사례 기록
배울 점: 모델이 만든 앱을 녹화한 영상과 고정 타임라인의 영상은 검수 대상이 다릅니다. 전자는 실제 입력에 반응하는 프로그램을 테스트해야 합니다. 논문 인터랙티브 데모를 만들더라도 보기 좋은 녹화 한 번만으로 전체 동작을 확인했다고 판단할 수 없습니다.
4. 처음 시도한다면 무엇부터 정해야 하나요?
이 레포의 가이드는 “가능한 최고 효과”보다 지정하고 검사할 수 있는 결과에서 시작합니다. 아래는 그 제작 경로 구분을 초보자의 선택 순서로 재구성한 것입니다. 성공률 순위나 이 리뷰에서 실험해 얻은 비교 결과는 아닙니다. 제작 가이드
| 만들고 싶은 것 | 먼저 준비할 입력 | 출발점으로 검토할 경로 |
|---|---|---|
| 데이터·알고리즘 설명 | 검증된 값, 단위, 원문, 핵심 메시지 | Manim·SVG·Remotion 기반 도식 |
| 서비스 기능 소개 | 실제 화면, 브랜드 자산, 정확한 제품 문구 | Canvas·Remotion 기반 UI·모션 |
| 반복되는 추상 그래픽 | 색상, 움직임 규칙, 박자, 반복 구간 | Canvas·p5.js·WebGL |
| 제품·공간 3D 투어 | 모델·텍스처, 카메라 동선, 성능 목표 | Three.js·Blender |
| 실사 분위기의 짧은 장면 | 인물·제품 참고 이미지, 장면 연속성 | 외부 영상 모델과 편집 도구 |
| 기존 발표 영상 재편집 | 원본 영상, 보존할 오디오·자막·정보 순서 | 타임라인 분석과 후반 편집 |
예를 들어 시계열 예측을 설명한다면 첫 목표를 “긴 미래지향적 영상”으로 잡기보다, 관측값·예측값·불확실성 구간을 짧은 도식으로 구분하는 것으로 정할 수 있습니다. 이 주제 선택은 데이터과학 독자를 위한 리뷰어의 적용 예입니다. 숫자를 모델이 만들어내지 않도록 자료 파일을 주고, 축·단위·시간 분할의 정확성을 검수 조건에 넣는 방식입니다.
실제 작업 순서는 다음처럼 구성할 수 있습니다.
- 신뢰할 사실·표·스크린샷과 사용할 수 있는 자산을 한 작업 폴더에 준비합니다. 비어 있는 부분을 모델이 알아서 채우기 전에 무엇이 누락됐는지 먼저 받습니다.
- 위 표에서 제작 경로 하나를 고릅니다. 렌더러나 제작 엔진을 정했다면 그 프로젝트의 설치 문서와 지원 환경을 확인합니다. 이 레포 자체는 렌더러를 설치하지 않습니다.
- Claude Code 등 파일을 읽고 제작 도구를 다룰 수 있는 환경에서 브리프와 아래 템플릿을 전달합니다. 채팅에서 텍스트만 받는 환경이라면 스토리보드와 코드가 있어도 렌더링은 별도로 수행해야 합니다.
- 전체 렌더링 전에 장면 계획과 가장 어려운 짧은 구간을 확인합니다. 오류가 있다면 “더 좋게”가 아니라 해당 시간·객체·문구·허용 상태로 피드백합니다.
- 최종 MP4와 함께 소스, 실행 방법, 자막, 자산·비용 목록을 받습니다. 이후 같은 내용을 수정할 수 있어야 일회성 시연을 작업 흐름으로 재사용할 수 있습니다.
공식 Opus 5.5 프롬프팅 가이드도 effort를 무조건 최대로 올리기보다 기본 medium에서 자기 작업으로 측정하는 접근을 설명합니다. 장시간 작업에서는 모델의 종료 메시지만으로 완료를 판정하지 말고 요구한 산출물이 실제로 존재하는지 확인해야 합니다. 영상 작업에 적용하면 “완료했습니다”보다 파일·렌더 기록·검수 결과가 완료 조건이 됩니다. 공식 프롬프팅 가이드
5. 한국어 프롬프트 샘플 세 가지
다음은 athemeroy 저장소의 프롬프트 플레이북과 제작 브리프를 한국어로 번역·축약하고 주제와 검수 항목을 조정한 템플릿입니다. 원문 자체도 X 제작자의 실제 프롬프트를 복사한 것이 아니라 조사자가 작성한 실험 템플릿입니다. 아래 샘플 역시 이 리뷰에서 실행한 성공 사례가 아니며, 대괄호를 실제 입력·설치된 도구로 바꿔야 합니다. 원문 저작자는 athemeroy 저장소의 기여자이며, 원문 문서와 아래 각색에는 CC BY 4.0 및 원문의 보증 부인이 적용됩니다.
샘플 A. 외부 이미지 없이 만드는 짧은 코드 애니메이션
플레이북 1번을 바탕으로 한 기본형입니다. 그림과 움직임을 코드로 통제하는 것이 목표입니다. “외부 자산 없음”이라는 조건은 글꼴·음원까지 명확히 해야 합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
JavaScript와 Canvas 2D로 [주제]를 설명하는 30초, 16:9 영상을 만드세요.
대상은 [독자 배경]이며 전달할 핵심은 [한 문장]입니다.
외부 이미지·영상·글꼴·영상 생성 모델은 사용하지 마세요.
음성은 넣지 않고, 소리는 [없음 / 직접 생성한 Web Audio]만 사용하세요.
먼저 6개 장면의 시작·종료 시간, 주체, 동작, 정확한 자막과 전환을 제안하세요.
제한된 색상과 일관된 도형 규칙을 정하세요.
각 프레임을 같은 시간 값에서 반복해 그릴 수 있는 방식으로 구성하세요.
전체 영상보다 먼저 가장 어려운 2~4초 구간을 렌더링하세요.
인접 프레임에서 겹침·속도·텍스트 잘림을 확인하고,
시간을 다른 순서로 이동해도 같은 장면이 나오는지 검사하세요.
수정 후 MP4, 소스, 렌더 명령, 실제 사용한 자산·소리와 미해결 문제를 주세요.
짧은 도형 애니메이션에서도 난수가 누적되거나 이전 프레임 상태에 의존하면, 같은 시점으로 이동했는데 다른 화면이 나올 수 있습니다. 템플릿의 반복 렌더 조건은 이런 종류의 문제를 확인하려는 요구입니다. 시뮬레이션이라면 시간별 상태를 미리 계산해 저장하는 별도 접근이 필요할 수 있습니다.
샘플 B. 데이터과학 개념을 설명하는 교육 영상
플레이북 2번을 시계열 예측 주제로 바꾼 예입니다. 제작 전에 입력 자료가 필요합니다. 모델이 만든 수치나 설명을 시각적 완성도만 보고 채택하지 않는 구조입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
제공한 [검증된 노트·데이터·참고 문서 경로]를 바탕으로
시계열 예측의 관측값, 예측값, 불확실성 구간을 설명하는 90초 영상을 만드세요.
대상은 예측 모델을 처음 배우는 데이터 분석가입니다.
새로운 실험 수치나 성능 비교는 만들지 마세요.
먼저 사실 주장과 출처를 연결하고, 내가 확인할 항목을 따로 표시하세요.
장면별 설명 대본과 그림 계획을 작성하세요.
화면은 [설치된 Manim 또는 Remotion], 음성은 [사용 가능한 TTS 또는 없음]으로 구성하고,
자막과 화면을 같은 시간표에서 생성하세요.
시간축, 값의 단위, 학습·예측 구간, 범례와 수치가 원자료와 일치하는지 확인하세요.
수식·차트가 자막에 가려지지 않도록 하고, 짧은 샘플부터 보여주세요.
오디오가 있다면 파일 존재·레벨·자막 동기화를 점검하세요.
발음과 설명을 실제로 청취해 확인하지 못했다면 그 사실을 명시하세요.
MP4, 소스, 대본, 자막, 출처 목록과 미검증 항목을 제출하세요.
이 요청의 핵심은 영상 길이보다 출처와 장면의 대응입니다. 예측구간의 음영이 무엇을 의미하는지, 실제로 계산된 값인지, 설명용 도식인지가 명시되어야 합니다. 음성이 없다면 음성 생성 성공이나 검수를 했다는 기록도 남겨서는 안 됩니다.
샘플 C. 기존 제품을 소개하는 홍보 영상
플레이북 3번의 각색입니다. 여기서는 이미 존재하는 제품 화면이 가장 중요한 근거입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
제품 저장소 [경로], 실제 화면 [경로], 브랜드 규칙 [경로]로
[대상 사용자]에게 보여줄 20초, 16:9 소개 영상을 만드세요.
제공된 자산 중 사용 권한이 확인된 것만 쓰세요.
없는 기능, 사용자 수, 성능 수치, 고객 평가를 만들지 마세요.
문서와 코드를 읽고 실제로 보여줄 수 있는 기능 3개를 먼저 제안하세요.
5개 장면으로 나누어 각 장면의 한 문장 메시지와 실제 화면 근거를 연결하세요.
[설치된 Remotion 프로젝트]에서 편집 가능한 형태로 제작하세요.
먼저 저해상도 미리보기를 제출하고 내용 확인 후 최종 MP4를 렌더링하세요.
기존 제품 자산, 새로 작성한 그래픽·애니메이션, 외부 음원,
사람이 고치거나 확인해야 할 주장을 구분해 기록하세요.
소스 프로젝트, 렌더 명령, 자막과 실제 사용 비용·자산 목록도 함께 주세요.
샘플 A와 C의 차이는 모델의 성능 설정이 아니라 입력의 성격입니다. A는 외부 시각 자산을 제한하고, C는 실제 제품 자산을 적극적으로 사용합니다. 동일한 “Opus로 제작”이라는 설명 아래 이 두 조건을 구분해야 다른 사람이 결과를 이해하고 재현할 수 있습니다.
6. Lessons learned: 잘 쓰는 프롬프트는 검수 조건까지 포함합니다
6.1 “한 번의 요청”을 네 가지 질문으로 나눕니다
플레이북의 마지막 주의사항은 특히 유용합니다. 처음 사람의 요청이 한 번이었는지, 프레임을 코드로 그렸는지, 외부 자산이 없었는지, 사람이 수정하지 않았는지는 서로 다른 주장입니다. 하나가 참이어도 나머지가 자동으로 따라오지 않습니다. 플레이북의 공개 설명 원칙
가령 짧은 요청이 제작 skill을 호출했다면 긴 지침은 이미 skill 안에 있을 수 있습니다. 코드를 통해 화면을 그렸더라도 텍스처는 생성 이미지일 수 있고, 결과 MP4가 있다고 해도 사람이 여러 번 장면을 수정했을 수 있습니다. 사례를 공유할 때는 이 네 항목을 각각 설명하는 편이 학습 가치가 높습니다.
6.2 스타일보다 상태 변화와 보존 조건을 구체화합니다
“영화처럼”, “고급스럽게” 같은 표현은 방향을 알려주지만 성공 여부를 판단하기 어렵습니다. 제작 브리프는 장면마다 시작 상태, 눈에 보이는 변화, 끝 상태, 정확히 유지할 글자·사실·자산을 쓰도록 합니다. 이 정보를 주면 어떤 장면에서 무엇이 잘못됐는지 지적할 수 있습니다. 장면 상태 브리프
예컨대 차트에서 점이 이동해야 한다면 시작 값과 끝 값, 이동 시간, 축의 고정 여부를 정합니다. 제품 로고가 바뀌면 안 된다면 변형 금지 대상으로 둡니다. 이것은 표현력을 없애는 제약이 아니라, 모델이 자유롭게 결정할 부분과 사실을 보존해야 할 부분을 나누는 과정입니다.
6.3 가장 어려운 구간을 먼저 확인합니다
저장소 가이드는 장면 계획·키프레임, 어려운 2~4초 구간, 전체 영상이라는 세 단계의 검수를 제안합니다. 짧은 샘플에서는 인접한 12~24개 프레임을 보며 가림, 접촉, 속도, 반복 경계와 자막 영역을 확인합니다. 다수 장면을 듬성듬성 보는 아홉 프레임 방식과 목적이 다릅니다. 세 단계 검수
최종 단계에서는 처음부터 끝까지 보고 들어야 합니다. 정지 화면에서 손과 물체가 잘 맞아도 움직이는 동안 관통할 수 있고, 자막 파일이 존재해도 발화와 어긋날 수 있습니다. 소리의 파일 존재·레벨 검사와 언어 내용·발음의 청취 검수도 별도입니다. 모델이나 도구가 하지 못한 검사를 했다고 기재하지 않는 것이 중요합니다.
6.4 비용은 동일한 납품물을 기준으로 비교합니다
같은 길이·해상도·내용·품질 조건에서 모델 호출, 영상·음성 서비스, 렌더링 컴퓨팅, 자산 구입, 사람의 검수와 재작업을 나누어 기록해야 합니다. “토큰이 저렴하다”, “구독 안에서 했다”, “한 번 요청했다”는 말만으로 완성품 비용을 비교할 수 없습니다. 최초 시안까지의 시간과 사람이 승인한 결과까지의 시간도 다릅니다. 이는 저장소가 제안한 비교 원칙이며, 이 글에서 측정한 비용 결과는 없습니다. 비용 기록 기준
6.5 전달할 파일을 처음부터 정합니다
MP4만 받으면 제목이나 숫자 하나를 수정할 때 제작 경로부터 다시 찾아야 할 수 있습니다. 브리프의 납품 항목에는 편집 가능한 프로젝트, 렌더 명령, 자막·오디오, 자산·비용 기록이 함께 들어갑니다. 재사용이 목적이라면 이 항목들은 부록이 아니라 결과물의 일부입니다. 납품물과 실제 작업 기록
7. 한계, 권리, 이번 리뷰의 범위
이 저장소의 강점은 다양한 제작 경로를 같은 “영상”으로 묶어 비교하되, 제작자 설명과 관찰 가능한 근거를 분리하려는 구조입니다. 하지만 공개 자료의 한계가 사라지는 것은 아닙니다. 검색된 표본은 전체 시장을 대표하지 않고, 분류기 레이블에는 오류 가능성이 있으며, 공개 대화·로그가 없는 사례의 제작 과정을 완전히 확인할 수 없습니다. 파일 SHA가 같으면 동일 바이트 중복은 잡을 수 있지만, 다시 인코딩한 유사 영상까지 같은 것으로 판별했다는 뜻은 아닙니다.
공개 CSV와 생성 문서는 일관성을 확인할 수 있는 형태지만, 원본 MP4가 없으므로 clone만으로 상류의 미디어 관찰을 처음부터 재현하기는 어렵습니다. 사례 생성기의 tile_ok 검사와 통계의 분모 검사는 유용한 데이터 품질 장치이고, 모델의 영상 제작 능력이나 완성품 품질에 대한 테스트를 대신하지는 않습니다.
라이선스도 층위가 나뉩니다. 저장소가 직접 작성한 해설·표·도식은 CC BY 4.0이지만, 링크된 영상·음악·제작자 프롬프트·제품 화면·외부 코드에는 각각의 권리가 적용됩니다. 이 글의 사례 해설과 템플릿은 athemeroy 및 저장소 기여자의 문서를 번역·요약·재구성했으며 원문 링크와 변경 사실을 표시했습니다. 외부 영상·썸네일은 복사하지 않고 제작자 게시물로 연결했습니다. 라이선스 · 제3자 자료 범위
이번에 다루지 못한 부분: 색상 모드 분석과 각종 관심도 갱신기의 전체 알고리즘, 썸네일 추출의 실제 실행, 168개 전체 사례의 독립 재검증, 연결된 제작 엔진들의 코드 감사는 수행하지 않았습니다. 대상 저장소의 설치·빌드·테스트·영상 제작도 실행하지 않았으므로, 본문의 사용 방향과 템플릿을 실제 성공 결과로 해석해서는 안 됩니다.
마치며
awesome-opus-5-5-videos의 가치는 인상적인 결과를 모은 데서 한 걸음 더 나아갑니다. 같은 영상이라도 코드 렌더링, 기존 영상 편집, 외부 모델 연출, 앱 녹화라는 서로 다른 경로가 있고, 각 경로의 입력·검수·재현 조건이 다름을 보여줍니다.
이 관점에서 영상 프롬프트는 멋진 문구보다 작은 제작 계약에 가깝습니다. 사실과 자산, 모델과 렌더러의 역할, 장면별 상태 변화, 짧은 샘플의 통과 조건, 최종 파일과 수정 가능한 소스를 함께 정의합니다. 그 구분이 있어야 완성 영상에서 무엇을 배웠는지 설명할 수 있고, 다음 작업에서도 같은 과정을 다시 사용할 수 있습니다.