로컬 AI로 2분 40초 뮤직비디오를 만들었습니다: 영상 클립 41개 생성에 194분

핵심 요약

무엇을 만들었나

• 대상: yesoppa.com — 한국을 찾은 외국인 여행자가 현지 친구(크루)와 하루를 보내는 서비스입니다. 지인이 운영하며, 이 영상과 글로 대가를 받지는 않았습니다
• 결과물: 영어 가사 K-pop 여행송 「YES! OPPA」(118 BPM, A장조)와 41개 장면 뮤직비디오
• 버전: v1~v4는 2026-10-11, 장면 전환을 고친 v5는 다음 날 만들었습니다. 최신 편집본 v5와 이전 편집본 v4 모두 YouTube에 공개돼 있습니다
• 작업 방식: 이 블로그 운영자의 요청에 따라 코딩 에이전트가 도구 설치부터 생성·편집·검수 스크립트 작성과 실행까지 맡았습니다. 결정과 수치는 모두 작업 폴더의 README에 남겼고, 이 글에서는 이를 "작업 기록"이라고 부릅니다

1. 다섯 단계 중 클라우드를 쓴 단계는 첫 프레임 생성뿐입니다

노래를 먼저 만들고, 가사가 나오는 시각에 맞춰 장면 목록을 짰습니다. 장면마다 첫 프레임 이미지를 만든 뒤 영상 모델로 그 이미지를 움직였고, 마지막에 클립을 자르고 이어 붙여 자막과 로고를 얹었습니다. 표의 시간은 이 작업에서 측정한 값입니다.

v1은 다섯 단계를 모두 로컬에서 처리했고, 제작 시간의 대부분이 영상 클립 생성에 들었습니다.

2. 노래: "오빠"가 "오삐"로 들려 곡 전체를 다시 만들었습니다

ACE-Step 1.5는 스타일 설명과 가사를 넣으면 보컬이 있는 노래를 만드는 오픈 모델입니다. 곡 구성을 먼저 잡는 보조 언어모델은 기본 실행 엔진(vllm)이 Mac에서 동작하지 않습니다. 그래서 Apple이 만든 머신러닝 프레임워크 MLX로 바꿔 실행했습니다. 표의 "로컬(MLX)"은 이 방식으로 Mac에서 실행했다는 뜻입니다. 스타일 설명은 "밝은 K-pop 댄스팝 여행송, 펑키한 베이스, 따뜻한 남성 리드 보컬, 따라 부르기 쉬운 후렴"이었고, 사이트 문구("Korea, with a Local Oppa")를 후렴에 넣었습니다.

처음 만든 세 곡(노래 v1~v3)에서는 후렴의 "Yes! Oppa"가 "오삐"에 가깝게 들렸고, 운영자가 이를 듣고 지적했습니다. 음성 인식 모델 Whisper가 받아 적은 가사와 원래 가사가 일치한 비율은 세 곡에서 각각 36%, 64%, 67%였습니다.

처음에는 곡을 그대로 두고 그 구간만 다시 부르게 하는 Repaint 기능을 30회 넘게 써 봤습니다. 가사 철자를 OH-PAH, OPPAH, 오빠로 바꾸고 후렴 전체를 다시 생성해도 "오삐"가 남았습니다. 작업 기록은 Repaint가 해당 구간의 리듬을 앞뒤 오디오에서 이어받기 때문이라고 추정했습니다. 결국 같은 설정으로 곡을 처음부터 12곡 새로 만들었고, 사람이 듣기 전에 두 가지 자동 채점으로 후보를 좁혔습니다.

• 가사 일치율: Whisper가 받아 적은 가사와 원래 가사를 비교한 값입니다
• 발음 점수: Demucs로 보컬만 분리한 뒤, 소리를 음소 단위로 받아 적는 wav2vec2 모델에 넣어 "Yes" 다음 /p/ 소리 뒤의 모음을 읽었습니다. /a/ 계열이면 "오빠", /i/·/e/ 계열이면 "오삐"로 판정했습니다

Whisper는 발음 판정에 쓰지 못했습니다. "oppa"를 영어 단어로 추측해 적고, 짧은 구간에서는 "We'll be right back" 같은 없는 문장을 만들어 냈습니다. 아래 표는 채점 파일(ratings.jsonl)에 남은 12곡 가운데 "오삐" 판정이 한 곳도 없는 3곡과, "오빠" 판정이 가장 많았던 1곡입니다.

"Yes" 위치는 후렴 밖까지 포함해 곡 전체에서 "Yes"가 들린 곳의 수이고, "판정 보류"는 /p/ 뒤 모음을 찾지 못한 곳의 수입니다. 선택한 곡은 "오삐" 판정이 없는 후보 중 "오빠" 판정이 가장 많았습니다. 작업 기록에는 후렴만 따로 검사했더니 9곳 모두 "오빠"였다고 적혀 있지만, 남아 있는 채점 파일로는 이 결과를 재현하지 못했습니다. 최종 판단은 운영자가 들어 보고 내렸습니다. 선택한 곡은 편집을 옮기기에도 유리했습니다. 가사 각 줄이 시작되는 시각이 노래 v3과 0~4초밖에 다르지 않아, 기존 편집을 거의 그대로 쓸 수 있었습니다. 150초 이후는 보컬 없이 연주만 나옵니다.

노래를 바꿨지만 영상 클립은 다시 만들지 않았습니다. 새 곡과 옛 곡에서 같은 가사 줄이 시작되는 시각을 짝지은 기준점 38개(timing.json)로 컷과 자막 위치를 옮겼고, 길이가 모자란 클립은 재생 속도를 조금 늦춰 맞췄습니다.

3. 첫 프레임: 로컬 이미지 모델은 한글을 틀리고 장면마다 인물이 달라졌습니다

이미지→영상 모델은 첫 프레임 이미지를 받아 그 뒤 프레임을 이어서 생성합니다. 그래서 영상에 보이는 인물·장소·글자는 대부분 첫 프레임에서 정해졌습니다. v1의 첫 프레임은 Z-Image Turbo로 만들었습니다. 시험한 모델 중 가장 빨랐지만, 인물 얼굴이 매끈한 이른바 "AI 얼굴"로 나왔고 컵라면 포장에는 중국어처럼 보이는 가짜 글자가 찍혔습니다. 컵라면 장면(shot30)은 포장에 글자가 없는 노란 양은냄비 라면으로 바꿨습니다.

한글을 더 정확히 쓰는 로컬 모델을 찾으려고 같은 지시문 네 개로 일곱 가지 모델을 비교했습니다. 글자 정확도는 macOS에 들어 있는 문자 인식 기능(Vision OCR)으로 측정했습니다.

• 직접 실행한 3개: 아래 표의 Z-Image Turbo, Boogu-Image, HiDream-O1 Dev
• 데모로만 본 4개: HiDream-O1 정식판, Ming-Image Design, Qwen-Image-2512, Ideogram 4. 다운로드 속도가 초당 약 2~6MB로 느려 Hugging Face 공식 데모의 무료 할당량 안에서만 시험했습니다. 이 중 HiDream-O1 정식판의 OCR 점수가 96으로 가장 높았지만, 간판의 "커피"를 "커파"로 썼습니다

표 마지막 줄의 모델들은 순위는 높지만 상업 이용이 안 돼 처음부터 비교에서 뺐습니다. Ideogram 4만 데모에서 한 장을 시험했습니다.

맞음·틀림은 OCR 결과와 눈으로 본 것을 함께 보고 작업 기록에 남긴 판정입니다. OCR 평균 점수는 지시한 문구 다섯 개(영문 "AlarmK"·"YES! OPPA" 포함)마다, OCR이 읽은 글자 중 가장 비슷한 부분과의 글자 유사도(0~100)를 구해 평균 낸 값이고 높을수록 정확합니다(작업 폴더 scores.md). 로컬 모델 중 점수가 가장 높은 Boogu도 쌍자음이 들어간 "떡볶이"는 "덕복이"로 썼습니다. 간판 문구는 한 글자만 틀려도 광고에 쓸 수 없습니다. 둘째 지시문은 이즐러가 만든 알람 앱 AlarmK의 광고 문구입니다.

로컬 모델 비교와 별도로, 같은 날 Codex CLI(0.160.1, ChatGPT 계정)의 이미지 생성 기능을 시험했더니 "떡볶이" 간판은 물론 메뉴판 가격까지 맞게 썼고, 피부와 조명도 실제 사진에 가까웠습니다. 참조 이미지(--ref)를 붙이면 장면이 바뀌어도 같은 인물과 방이 유지됐습니다. 그래서 v2에서는 장면 목록과 노래, 편집을 그대로 두고 첫 프레임 41장만 Codex로 다시 만들었습니다.

• 여행자와 크루가 처음 만나는 장면(shot06)을 먼저 만들고, 두 인물이 나오는 모든 장면에 참조 이미지로 붙였습니다. 그 덕에 장면이 바뀌어도 얼굴·옷·가방이 이어졌습니다
• 41장 모두 한 번에 생성됐고, 내용이 맞지 않아 다시 만든 이미지는 2장입니다. 하나는 야시장 배경에 동남아식 금색 불탑이 나온 장면(shot36)으로, 지시문을 "광장시장 같은 한국 야시장, 사원·탑 없음"으로 고쳤습니다
• 다른 하나는 여행자와 크루의 셀카가 연인처럼 보인 장면(shot14)입니다. "데이트가 아니라 친구"라는 브랜드 원칙에 맞춰, 넷이 함께 찍는 단체 셀카로 바꿨습니다
• "다양한 국적의 여행자"라고만 쓰면 모두 한국인으로 나와서, "금발의 유럽 여성, 흑인 남성"처럼 외모를 구체적으로 적고 단체 장면 3개(11·16·26)를 다시 만들었습니다
• v3·v4에서 고친 장면 3개(shot29·31·17)의 첫 프레임은 코딩 에이전트에 내장된 이미지 생성 도구(기록상 "built-in image_gen")로 기존 이미지를 고쳐 만들었습니다

작업 기록에 따르면 Codex를 한 번 호출할 때마다 에이전트 입력으로 약 10만 토큰이 들었습니다. 다시 만든 2장은 빼고 최종 41장만 계산해도 약 410만 토큰이고, 이만큼이 ChatGPT 요금제의 Codex 사용량에서 차감됩니다. 곱해서 낸 추정값이고 금액으로 환산하지는 않았습니다. Codex는 요청하지 않은 문구를 덧붙이기도 해서, 광고용 이미지에는 "이 문구만, 다른 글자 없이"를 지시문에 넣었습니다.

4. 영상 클립: 하나에 2분 31초~12분 29초가 걸렸고, 글자는 2초 안에 깨졌습니다

영상은 Lightricks의 LTX-2.5를 MLX용으로 옮긴 오픈소스 프로젝트 ltx-2-mlx로 만들었습니다. LTX-2.5는 2026년 8월 공개된(라이선스 문서 날짜 2026-08-11) 영상·오디오 생성 모델로, 가중치를 내려받아 직접 실행할 수 있는 오픈 웨이트 모델입니다. 가중치를 8비트로 줄인 판도 42GB입니다. 작업 기록에 따르면, 조사한 다른 방법은 이 노트북에서 쓰기 어려웠습니다.

• ComfyUI + Wan 2.2는 같은 M1 Max 64GB에서 2초 영상을 만드는 데 82분이 걸렸다는 측정 글이 있었습니다(2차 자료)
• ComfyUI + LTX-2 조합은 FP8 형식이 Mac의 GPU(Metal)에서 동작하지 않았고, GGUF 형식은 결과가 깨지거나 정지 화면만 나왔습니다

클립마다 첫 프레임 이미지와 움직임 지시문("그녀가 휴대폰을 보며 걸어오다 고개를 들고 웃는다, 부드러운 트래킹 숏")을 넣고, 오디오 생성은 끈 채 1024×576으로 만들었습니다. 연산 정밀도를 LTX2_COMPUTE_DTYPE=float16으로 지정하면 약 20% 빨라졌습니다. M1 칩에는 bf16 연산을 처리하는 하드웨어가 없어 float16이 더 빠릅니다.

같은 모델이라도 실행 조건에 따라 속도가 크게 달라졌습니다. 출력이 낮은 충전기를 쓰면 GPU 성능이 제한돼 클립당 2.5~5분이던 시간이 9~12분으로 늘었습니다. 한 프로세스에서 클립을 연달아 만들면 점점 느려져서, 클립마다 새 프로세스로 실행했습니다. 작업 기록에는 오래 걸리는 생성에 96W 이상 충전기를 쓰라는 메모가 있습니다. 클립 길이(57~129프레임)도 생성 시간에 영향을 주기 때문에, 194분 중 전원 제한 때문에 늘어난 시간은 로그만으로 가려내지 못했습니다.

LTX는 첫 프레임만 그대로 두고 나머지 프레임을 새로 그립니다. 첫 프레임에서 정확했던 작은 글자도 카메라가 움직이면 약 2초 안에 다시 깨졌습니다(떡볶이 메뉴판이 "떡뭐이"가 됨). 그래서 정확해야 하는 문구는 전부 편집 단계에서 실제 글꼴로 얹었습니다. 클립 뒷부분에서 물건이 하나 더 생기는 식으로 화면이 깨지면 앞부분만 잘라 느리게 재생했고, 움직임 방향이 반대로 나오면 거꾸로 재생해 썼습니다.

5. v1에서 v5까지 바꾼 것과 그 이유

v1~v4는 2026-10-11 하루에, v5는 다음 날 만들었고, 이전 버전은 덮어쓰지 않고 보존했습니다. 영상의 버전 번호(v1~v4)는 노래의 버전 번호와 따로 셉니다. 영상 v1은 노래 v3으로 처음 만들었다가 노래 v4로 다시 편집했고, 영상 v2부터는 처음부터 노래 v4를 썼습니다.

v3에서는 v2 전체를 0.25초 간격으로 뽑은 640프레임과, 장면마다 다섯 시점을 모은 이미지를 보며 검토했습니다. 표의 v3 행에 있는 "장면 2개"는 다음 두 장면입니다.

• shot29: 미래형 건물이 선 광장과 클럽 같은 분위기가 앞뒤의 한국 여행 장면과 어울리지 않아, 한국 거리의 보행자 도로로 바꿨습니다
• shot31: 고맙다고 인사하면서 가슴 앞에 두 손을 모으는 동작을, 손을 내리고 가볍게 고개를 숙이는 인사로 바꿨습니다

음량은 원본(-13.16 LUFS)을 0.84dB 낮춰 -14.00 LUFS로 맞췄고, 순간 최대 음량(트루 피크)은 -1.84dBTP입니다. LUFS는 사람이 느끼는 평균 음량 단위이고, 동영상 플랫폼은 대체로 -14 LUFS 안팎으로 맞춰 재생합니다. 검수 중에는 "무료 채팅" 안내 문구가 한 구간 통째로 빠진 것을 발견했습니다. 초 단위 소수와 24fps 프레임 번호를 섞어 계산한 것이 원인이어서, 화면 표시 시각을 모두 정수 프레임 단위로 바꾼 뒤 다시 인코딩했습니다.

떡볶이 장면의 문제는 640프레임 검토에서 놓쳤습니다. 원본 89프레임을 확대해 보니 입을 크게 벌리고 웃는 표정이 계속 이어졌고, 긴 떡이 젓가락과 입에 겹쳐 무엇을 하는 동작인지 알아보기 어려웠습니다. 수정 버전에서는 떡을 2cm 크기 한 조각으로 줄인 첫 프레임을 새로 만들고, 동작을 "한 조각 넣기 → 입 다물기 → 빈 젓가락 빼기 → 다문 입으로 씹기" 순서로 단순하게 지시했으며, 카메라는 고정했습니다. 새 클립 89프레임은 전부 확대해 검토했습니다. 나머지 40개 장면의 중간 파일과 자막·오디오는 파일 해시(SHA-256)를 v3과 비교했고, 바뀐 곳은 이 장면 하나뿐이었습니다.

v5는 공개 뒤 받은 의견에서 시작했습니다. v4는 가사 줄마다 클립 하나를 붙여, 장면이 평균 3.9초마다 전환 효과 없이 바뀌었고 후렴 앞에서는 1.7~2.3초 간격으로 끊겼습니다. v5에서는 장면이 바뀔 때 두 장면이 0.4~0.7초 동안 겹쳐 지나가게 했습니다. 후렴 앞의 짧은 컷 묶음은 세 장면으로 정리했고, 점프하는 댄서처럼 동작이 큰 장면은 움직임이 작은 밤거리·야경·해변 장면으로 바꿨습니다. 카메라가 크게 도는 지하철 장면은 같은 첫 프레임에서 움직임을 줄여 다시 생성했습니다. 노래와 자막, 길이(160초)는 v4와 같습니다.

화면 변화량도 비교했습니다. 화면 중심부를 흑백으로 바꿔 이웃 프레임 사이의 밝기 차이(0~255)를 구하면, v4의 하드컷 지점은 중앙값 54.1이었고 v5의 디졸브 구간 최댓값은 중앙값 8.0이었습니다. 다시 만든 지하철 장면의 평균 변화량은 11.2에서 4.7로 줄었습니다. 이 값은 화면이 얼마나 급하게 바뀌는지를 잰 것이고, 보는 사람이 편하다는 보장은 아닙니다. 검수는 전편 디코딩과 전환 앞뒤 238프레임을 확인하는 방식으로 했습니다.

세로 9:16 버전(1080×1920)은 새로 생성하지 않고 편집만으로 만들었습니다. 자막을 얹기 전의 클립에서 장면마다 잘라 낼 위치를 정했고, 가로로 넓게 퍼진 단체 장면은 흐리게 처리한 영상을 배경으로 깔고 그 위에 장면 전체를 놓았습니다.

6. 장점과 단점

아래 표는 도구마다 이 작업에서 얻은 것과 잃은 것입니다. 시간과 성능은 이 작업의 조건(M1 Max 64GB, 2026-10-11 시점 버전)에서 나온 값입니다.

로컬에서 만들기로 한 선택을 전체로 보면 이렇습니다.

• 반복 비용 대신 시간이 들었습니다. 곡 후보 12개, Repaint 30여 회, 클립 재생성을 횟수 걱정 없이 실행했습니다. 대신 버전 하나를 처음부터 다시 만들면 몇 시간이 걸렸습니다
• 디스크 공간과 설치 시간도 들었습니다. 모델과 캐시가 약 201GB를 차지했고, 첫 이미지 모델 다운로드에만 약 20분이 걸렸습니다
• 에이전트 환경의 제약도 있었습니다. 코딩 에이전트의 격리 실행 환경(샌드박스)에서는 MLX가 "No Metal device available"로 실패해, GPU를 쓰는 작업만 따로 허가를 받아 실행했습니다
• "로컬로 만들었다"는 말에는 조건이 붙습니다. 노래와 움직임은 로컬이지만, 화면에 보이는 장면의 출발점은 클라우드 이미지입니다. YouTube 설명에도 단계별 도구를 나눠 적었습니다

7. 라이선스와 AI 생성 표시

실제 사람처럼 보이는 AI 생성 인물이 나오는 홍보 영상이어서, 라이선스 원문을 직접 읽고 대조했습니다.

Boogu(Apache-2.0)·HiDream-O1(MIT)의 라이선스와 상업 이용 불가 모델 목록은 작업 기록의 조사를 옮긴 것으로, 이 글을 쓰면서 각 라이선스 원문을 다시 열어 보지는 않았습니다. OpenAI 이용약관은 2026-10-12 조회 때 페이지 접근이 거부돼, 생성 이미지의 권리 조항을 원문과 대조하지 못했습니다.

8. 같은 순서로 만들어 보려면

작업 폴더는 공개하지 않았습니다. 대신 작업 기록에 남은 설치 명령과, 공개 저장소의 Python API로 장면 하나를 만드는 코드를 옮깁니다. ltx-2-mlx에 넣는 가로·세로 크기는 64의 배수, 프레임 수는 8n+1(57, 97, 129 등)이어야 합니다. 24fps에서 97프레임이면 약 4초입니다.

# 설치(2026-10-11 기준). 노래는 웹 UI에서 스타일 설명·가사·시드를 넣어 생성
git clone https://github.com/ACE-Step/ACE-Step-1.5 && cd ACE-Step-1.5
cp .env.example .env   # ACESTEP_LM_BACKEND=mlx 로 바꿔야 Mac에서 보조 모델이 동작
uv run acestep-download
./start_gradio_ui_macos.sh   # http://127.0.0.1:7860, 첫 실행 약 50초
cd ..
uv tool install --upgrade mflux --with hf_transfer
git clone https://github.com/dgrauet/ltx-2-mlx
(cd ltx-2-mlx && uv sync --all-extras)

# 첫 프레임: $(uv tool dir)/mflux/bin/python 으로 실행
import mlx.core as mx
from mflux.models.z_image import ZImageTurbo
model = ZImageTurbo(quantize=8, compute_precision=mx.float16)
img = model.generate_image(seed=1, prompt="cinematic travel commercial photograph, ..., no text",
                           width=1024, height=576, num_inference_steps=9)
img.save(path="shot01.png")   # 같은 이름이 있으면 shot01_1.png로 저장되므로 먼저 지움

# 영상 클립: ltx-2-mlx/.venv/bin/python 으로, 클립마다 새 프로세스로 실행
import os; os.environ.setdefault("LTX2_COMPUTE_DTYPE", "float16")
from ltx_pipelines_mlx import DistilledPipeline
pipe = DistilledPipeline(model_dir="models/ltx-2.5-mlx-q8")   # 8비트 모델 폴더(약 42GB)
pipe.generate_audio = False
pipe.generate_and_save(prompt="She walks toward the camera, smiles, smooth tracking shot.",
                       output_path="shot01.mp4", height=576, width=1024,
                       num_frames=97, frame_rate=24.0, seed=1, image="shot01.png")

# 검수: 프레임 수, 음량, 1초 간격 프레임 모음
ffprobe -v error -count_frames -show_entries stream=nb_read_frames out.mp4
ffmpeg -i out.mp4 -af ebur128 -f null - 2>&1 | tail -12
ffmpeg -i out.mp4 -vf "fps=1,scale=320:-1,tile=8x5" -frames:v 1 sheet.png

클립을 셸 반복문으로 하나씩 실행하되 이미 만든 파일은 건너뛰게 하면, 중간에 멈춰도 이어서 만들 수 있습니다. 프레임 모음은 가짜 글자, 물건 위치, 인물 구성처럼 수치로 잡히지 않는 문제를 찾는 용도입니다. 손과 음식이 닿는 동작은 모든 프레임을 확대해 봐야 했습니다.

9. 체크리스트

1. 모델을 고르기 전에 라이선스부터 봅니다. 오픈 웨이트 이미지 순위 상위 모델 중 셋이 상업 이용 불가였습니다. 영상 모델은 연 매출 기준과 AI 표시 조건까지 읽습니다
2. 소리와 움직임은 사람이 끝까지 듣고 봅니다. 자동 검사(프레임 수, 음량, 검은 화면, 프레임 모음)는 통과했지만 발음과 먹는 동작의 문제는 사람이 찾았습니다
3. 노래의 외국어 단어 발음은 후보를 여러 개 만들어 고릅니다. Repaint(구간 다시 부르기)로는 고쳐지지 않았습니다. 음소 인식으로 먼저 거르면 사람이 들을 후보가 줄어듭니다
4. 화면에 정확한 한글이 필요하면 편집 단계에서 실제 글꼴로 얹습니다. 이미지 단계에서 맞게 나왔어도, 영상으로 움직이면 글자가 다시 깨집니다
5. 오래 걸리는 생성은 충전기 출력부터 봅니다. 96W 이상 충전기를 쓰고, 클립마다 새 프로세스로 실행하고, 이미 만든 것은 건너뛰게 짭니다
6. 장면 전환을 따로 설계합니다. 가사 줄마다 클립을 바로 이어 붙인 v4는 "전부 점프컷이라 눈이 아프다"는 의견을 받았습니다. 생성 영상은 장면마다 장소와 카메라 움직임이 달라, 짧은 디졸브와 4초 넘는 장면 길이로 숨을 돌릴 틈을 줍니다
7. 디스크 200GB 안팎을 비워 둡니다. 영상 모델 하나가 42GB였습니다
8. 시드·지시문·명령을 파일로 남깁니다. 가사 줄 시각의 기준점만 있으면, 노래를 바꿔도 클립을 다시 만들지 않고 편집을 옮길 수 있었습니다
9. 사람처럼 보이는 생성 인물이 나오면 AI 생성 사실을 분명히 알립니다. 법과 라이선스가 정한 것은 "명확히 인식할 수 있는" 고지·표시까지입니다. 영상 파일만 따로 퍼져도 알 수 있도록 화면 안에도 넣는 편이 안전하다고 봅니다. 이번 영상에는 아직 넣지 못했습니다

10. 아직 결론이 아닌 것

• 노트북 한 대(M1 Max 64GB)로 하루 동안 작업한 기록입니다. 다른 Mac이나 GPU에서는 시간을 측정하지 않았습니다
• v1과 v2는 같은 조건에서 반복 측정하지 않았습니다. v1의 시간은 작업 기록의 대략값이고, v2의 194분에는 전원 제한 구간이 섞여 있습니다
• 로컬 이미지 모델 비교는 지시문 네 개, 모델마다 한두 장입니다. 일부 모델은 공식 데모로만 시험했고 무료 할당량 때문에 한 장만 봤습니다
• 같은 시드로 곡을 다시 만들었을 때 같은 결과가 나오는지는 시험하지 않았습니다
• "오빠" 발음 판정에서 후렴 9곳 결과는 남아 있는 파일로 재현하지 못했습니다. 최종 판단은 사람이 들어 보고 내렸습니다
• Codex 사용량은 작업 기록의 "호출당 약 10만 토큰"을 곱한 추정이고, 요금이나 사용 한도에 미친 영향은 측정하지 않았습니다
• 영상의 도시 풍경과 명소는 생성 이미지입니다. 실제 장소와 같은지는 검증하지 않았습니다
• OpenAI 이용약관 원문과 자막 글꼴의 상업 사용 조건은 대조하지 못했습니다
• v5의 전환 개선은 프레임 변화량으로만 비교했고, 시청자 반응은 아직 받지 않았습니다. 세로 9:16 버전은 아직 v4 편집 그대로입니다
• 영상 화면 안의 AI 생성 표시는 v5에도 아직 넣지 않았습니다

참고자료

yesoppa.com은 지인이 운영하는 서비스이고, 영상 제작과 이 글에 대가를 받지 않았습니다. AlarmK는 이즐러가 만든 앱입니다. 글에 나온 도구의 개발사(Lightricks, ACE Studio·StepFun, OpenAI 등)와는 광고·협찬·제공 관계가 없습니다.