조회수 500만 PPT 모션 그래픽을 클로드 디자인에 시켜봤습니다 (6개 중 5개 성공)

시도하고자 했던 것과 그 이유

이런 영상 보신 적 있으신가요?

• https://www.youtube.com/watch?v=bsnDyMHrYOU

• https://www.youtube.com/watch?v=XtW3Rm3Klkw

• https://www.youtube.com/shorts/ZotoANMTxRg

• https://www.youtube.com/shorts/I7k6JmjjWGU

• https://www.youtube.com/shorts/dQc-TS6nNuc

• https://www.youtube.com/watch?v=6bLNJB-f0Ek

• https://www.youtube.com/shorts/6mGhpPTn4Fs

예전에 제 쇼츠에 꽤 자주 나왔던, PPT 모핑 기능으로 슬라이드에 애니메이션 효과를 주는 영상들이 최근에 갑자기 생각나더라구요.

이 7편을 합치면 조회수가 500만입니다 (정확히는 5,008,792회, 7월 29일 기준). 한 편은 264만, 다른 한 편은 150만이고요. 사람들이 이런 걸 보고 싶어 한다는 뜻이겠죠. 그런데 막상 따라 만들려면 PPT를 켜야 합니다.

그래서 클로드 디자인으로 HTML 코드를 만들면 PPT보다 훨씬 쉽게, 자연어만으로도 이런 후킹한 모션을 넣을 수 있지 않을까 생각이 들었고 시도해보았습니다.

결과부터 말씀드리면 6개 패턴 중 5개를 재현했습니다. 그런데 이 글에서 정작 쓸모 있는 이야기는 나머지 하나와, 처음에 실패한 것들에서 나왔습니다. 심지어 중간에 세운 결론이 마지막 패턴에서 뒤집혔습니다.

우선 결과를 보여드리고 → 만든 과정을 설명드린 후 → 안 된 것들을 이야기하고 → 마지막에 제작한 스킬을 공유드리겠습니다.

위 목록의 두 번째(XtW3Rm3Klkw, 150만)는 작업하지 않았습니다. 첫 번째 패턴(년도 오도미터)과 같은 모션이라 새로 얻을 게 없어서요. 링크만 걸어둡니다.

결과 — 6개 중 5개

여섯 개를 다 해보고 나니 모션이 세 가지로 환원됐습니다.

이게 이번 실험에서 제일 크게 남은 겁니다. 모션은 예쁨이 아니라 콘텐츠의 관계 구조에서 나옵니다. 불릿 목록에 모션을 넣을 자리가 없는 이유도 이걸로 설명됩니다 — 불릿은 관계가 아니라 나열이라서, 모션을 얹는 게 아니라 내용을 셋 중 하나로 다시 써야 합니다.

실측 수치 (첨부 1)

「부드럽게」 같은 말로는 재현이 안 돼서, 영상을 받아 프레임 단위로 쟀습니다.

공통 이징 cubic-bezier(0.25, 0.1, 0.35, 0.95) — 오도미터 22점 + 하이라이팅 51점, 합동 73점 최소제곱 피팅입니다.

ease-in-out이 최악입니다. "모핑은 부드럽게 시작해서 부드럽게 끝난다"는 통념이 실측과 정반대였습니다. 실제로는 거의 곧바로 최고속에 올라가 길게 감속합니다.

전환 시간은 패턴마다 다릅니다. 0.30 / 0.37 / 0.71 / 0.96초 — 움직이는 거리가 멀수록 깁니다. 「모핑은 0.5초」 같은 공통 상수는 없었습니다. (여섯 중 넷입니다. 나머지 둘은 아예 못 쟀는데, 그 이야기가 아래 ③입니다.)

그리고 웹 기본값과 실제로 달랐습니다.

"PPT에서 잰 값을 웹에 옮길 가치가 있나"에 대한 답이 여기서 나왔습니다 — 있습니다. 기본값을 그대로 쓰면 PPT 모핑보다 느리고 곡선도 다릅니다.

어떻게 만들었나

1. 웹(클로드)에서 가능성부터 확인했습니다.

2. 가능성이 보이길래 클로드 코드로 옮겼습니다.
유튜브 영상을 받아 프레임 단위로 분석해야 하는데, 웹에서는 그게 안 되기 때문입니다. yt-dlp로 영상을 받고 ffmpeg로 프레임을 뽑아, 프레임마다 카드 경계·변위·회전각을 재는 도구를 7개 만들었습니다.

3. 코드와 디자인을 왔다 갔다 했습니다.
클로드 코드에서 프롬프트를 만들고, 클로드 디자인에서 실제로 구현했습니다.

이 분업은 처음부터 안 게 아니라 한 번 실패하고 나서 알았습니다.

클로드 코드는 모션의 수치와 규칙을, 클로드 디자인은 디자인과 콘텐츠를 맡습니다. 디자인은 대화로 방향을 잡기보다 명령을 정확히 수행하는 데 최적화된 외주 업체에 가까워서, 프롬프트를 어떻게 짤지 고민하는 과정에는 적합하지 않았습니다.

4. 그래서 작업 순서를 고정했습니다.

① 완성본 재생 구간 찾기 → ② 기하 실측 → ③ 시간·이징 실측

→ ④ 프로토타입으로 메커니즘 검증 → ⑤ 프롬프트 작성

이 순서는 제가 정한 게 아니라 어겼다가 얻어맞고 나서 생긴 것입니다.

안 된 것들 — 규칙은 전부 여기서 나왔습니다

① 프롬프트 3개를 한 번에 썼다가 3개 다 실패했습니다

처음엔 실측만 하면 될 줄 알고 프롬프트 3종을 한 번에 써서 돌렸는데 전부 레퍼런스처럼 안 나왔습니다. 원인은 문장이 아니라 ④ 프로토타입 단계를 건너뛴 것이었습니다.

성공한 하이라이팅은 프로토타입을 만들다 함정을 직접 밟았습니다 — grid-template-columns를 fr로 쓰면 이징이 어긋납니다. fr은 트랙 합에 대한 비율이라, 합이 같이 커지면 같은 이징을 걸어도 픽셀 폭이 더 빨리 벌어집니다 (t=0.1에서 0.072여야 하는데 0.119가 나옵니다). 눈으로는 거의 안 보이는 차이입니다.

프로토타입을 안 만들면 함정을 모르는 채로 프롬프트를 쓰게 됩니다. "프로토타입은 제품이 아니라 검증 도구"라고 정리해 둔 게 화근이었습니다 — 맞는 말이지만 건너뛰어도 된다는 뜻은 아니었습니다.

② 줌스루 v1 — 회전각을 −30°로 적었는데 실제는 −122°였습니다

"살짝 기우는" 정도로 봤는데, 프레임을 재보니 거의 한 바퀴 가까이 돌아 나갑니다. 게다가 회전 궤적이 가속형이라 감속 곡선인 공통 이징과 반대였습니다. 단일 각도 + easing으로는 어떤 값을 넣어도 안 나옵니다 — 실측 궤적을 키프레임으로 그대로 재생해야 했습니다.

③ 하나는 아예 못 쟀습니다 — 그리고 그 결론이 마지막에 뒤집혔습니다

「사진이 쏙」은 완성본이 물리 모니터를 카메라로 찍은 화면이었습니다. 프레임 실측이 원천적으로 불가능해서 시간·이징을 다른 패턴에서 빌려 썼고, 다섯 중 유일하게 재현에 실패했습니다.

그래서 이렇게 정리했습니다.

측정 가능성이 곧 재현 가능성이다. 못 재면 못 만든다.

깔끔한 결론이라 좋아했는데, 여섯 번째 패턴이 이걸 깼습니다.

조회수가 제일 큰 264만짜리 영상(「텍스트 녹아웃 줌」 — 검정 판에 글자 모양으로 구멍이 뚫려 있고, 판이 확대되면서 그 구멍 안으로 화면이 들어가는 연출)도 완성본이 촬영본이라 시간을 못 쟀습니다. 똑같이 빌렸죠. 그런데 재현에 성공했습니다.

둘의 차이는 빌린 시간이 아니라 기하의 정확도와 메커니즘 검증 여부였습니다. 그래서 결론을 이렇게 고쳤습니다.

못 재도 되는 것과, 못 재면 안 되는 것이 갈린다.
시간·이징은 다른 패턴에서 빌려와도 어지간히 굴러갑니다.
기하와 메커니즘은 빌릴 수 없습니다.

다만 표본이 둘뿐입니다. 단정하기엔 이르고, 다음 패턴에서 또 깨질 수 있습니다. 그래도 실무적으로는 방향이 생겼습니다 — 시간을 못 재게 되면 시간에 매달리지 말고 기하와 메커니즘에 시간을 쓴다.

레퍼런스를 고르는 1순위 기준(완성본이 화면 캡처로 재생되는가)은 그대로 두되, "촬영본이면 버린다"에서 "촬영본이면 기하만이라도 편집 화면에서 정확히 뜬다" 로 한 단계 물러섰습니다.

④ 눈으로 잰 0.68초가 실제로는 0.96초였습니다

처음엔 "숫자가 몇 프레임에 가운데 왔나"를 눈으로 세어 3점으로 쟀습니다. 680ms. 나중에 변위 추적으로 22점을 다시 재니 960ms였습니다. 30% 차이입니다.

왜 그랬는지가 곡선으로 설명됩니다. 이 이징은 전체의 69%(664ms) 지점에서 이미 진행률 90%를 지납니다. 눈에는 그때 "도착했다"로 보이고, 남은 10%가 나머지 시간에 걸쳐 천천히 안착합니다. 그 안착이 무게감을 만드는 부분인데 눈으로는 안 세집니다.

재밌는 건 초판과 정정판이 같은 1.71초를 다르게 쪼갠 것이었다는 점입니다.

초판이 틀린 게 아니라, 눈이 본 것을 적은 것이었습니다.

⑤ 마지막에 실측과 취향이 갈렸습니다

오도미터를 v2로 고치면서, 저는 "들어오는 이미지가 지금 정지해 있는데 이게 가장 큰 문제" 라고 적고 슬라이드인을 넣게 했습니다.

그런데 실측은 "들어오는 이미지는 움직이지 않는다"입니다. 세 프레임에서 얼굴 좌표가 동일한 것으로 확인한 값이고, 원본은 정말로 안 움직입니다.

즉 원본에 충실한 쪽을 제가 결함으로 판정한 겁니다.

이게 이 실험의 마지막 발견이었습니다. 측정은 "원본이 어떻게 움직이는가"에 답하지, "무엇이 좋은가"에는 답하지 않습니다. 그래서 스킬에는 실측값과 연출 대안을 한 칸에 섞지 않고 나란히 적었습니다.

(첨부 2) 프레임을 직접 넘겨볼 수 있는 뷰어

말로만 하면 안 믿기실 것 같아 줌스루 구간의 프레임을 한 장씩 넘겨볼 수 있게 만들어 두었습니다. 프레임뷰어_줌스루.html

결과와 배운 점

토큰이 있으면 상상해본 것을 대화를 통해 구현해볼 수 있는 세상이 된 것 같습니다. 다만 이번에 해보고 나서 한 가지를 덧붙이게 됐습니다.

대화로 되긴 되는데, 대화가 답을 주지 않는 지점이 따로 있었습니다.

• 「부드럽게」는 지시가 아니었습니다. 대상 / A→B / 시간 / 이징 / 순서 다섯 칸을 다 채워야 재현됐고, 빈 칸은 모델이 기본값(0.3s ease)으로 채웠습니다

• 기능 이름만 적으면 기본값도 모델이 정했습니다. "자동재생 토글"이라고만 썼더니 토글을 만들고 기본값을 켜 뒀습니다. 발표용 슬라이드가 저절로 굴러갔습니다. 원하는 기본 상태는 문장으로 적어야 했습니다

• 그리고 그 다섯 칸을 채우는 값은 상상이 아니라 측정에서 나왔습니다. (target - cur + 10) % 10 — 오도미터의 인상 전체가 이 한 줄에서 나오는데, 이건 아무리 상상해도 안 나오고 프레임을 세야 나옵니다

• 반대로 값을 주면 안 되는 자리도 있었습니다. 텍스트 녹아웃 줌은 "검정 판이 완전히 사라질 때까지 몇 배로 키우나"가 핵심인데, 원본에서 잰 17배를 그대로 주면 안 됩니다. 필요한 배율이 폰트와 글자마다 19배에서 71배까지 달라지거든요. 디자인은 모델의 자유 영역이라 모델은 반드시 다른 폰트를 고릅니다. → 폰트에 따라 달라지는 값은 상수로 주지 말고, 「푸는 방법」을 줘야 했습니다. (덤으로 얻은 함정 하나 — O나 A처럼 안이 막힌 글자를 고르면 화면이 영원히 안 열립니다. 확대의 고정점이 뚫린 데가 아니라 판 위라서요.)

정리하면 이렇습니다.
모델은 "어떻게 만들지"는 알아서 하는데, "무엇을 만들지"는 여전히 제가 재야 했습니다.

스킬 공유

위 내용을 전부 스킬 하나로 묶었습니다. 패턴 6개 + 공통 이징 + 구현 규칙 + 함정 + 증상별 수정법이 통째로 들어 있어서, 여러분은 측정하실 필요가 없습니다.

쓰는 법은 간단합니다. 슬라이드 내용을 그대로 주시면
→ 콘텐츠의 관계 구조(순서/병렬/포함)를 읽고
→ 어울리는 모션 후보를 2~3개 제시하고 멈춥니다
→ 고르시면 1920×1080 단일 HTML로 만들어 줍니다
→ 이상하면 증상을 말씀하시면 원인을 찾아 고칩니다

깃헙에 공개해 두었습니다. 마음대로 고쳐 쓰셔도 됩니다.

https://github.com/mincheol10007/slide-motion-skill

쓰시는 방법은 세 가지입니다.

1. claude.ai 스킬로 올리기
릴리스에서 slide-motion-skill.zip 을 받아 설정 > 사용자 지정 > 스킬 > 업로드에 그대로 올리시면 됩니다. 그 다음 "슬라이드에 모션 넣어줘"라고 하시면 발동합니다. (코드 실행을 켜두셔야 합니다.)

저장소의 초록색 Code > Download ZIP 버튼으로 받은 파일은 안 됩니다. 폴더가 한 겹 더 깊어져서 스킬로 인식되지 않아요. 위 링크로 받으세요.

2. 클로드 코드에 넣기
slide-motion 폴더를 ~/.claude/skills/ 에 복사하시면 됩니다.

3. 그냥 붙여넣기 — 업로드가 안 되는 어디서든
릴리스의 slide-motion-full.md 를 통째로 복사해서 대화창에 붙여넣으셔도 똑같이 동작합니다. 애초에 그렇게 쓰실 걸 감안해서 쓴 문서입니다. 맨 뒤에 이 한 줄만 붙이시면 됩니다.

위 문서를 따라라. 내 슬라이드 내용은 아래와 같다. 먼저 관계 구조를 판별하고

후보를 제시한 다음 멈춰라 — 내가 고르기 전에 만들지 마라.

[여기에 슬라이드 내용]