Claude Opus 5.5로 도트 애니메이션 영상 만들기 — 파이썬 한 파일로 직접 돌려본 결과와 첫 시도 결함 3개

Posted on by

Claude Opus 5.5는 2026년 9월 22일 공개된 Anthropic의 새 모델로, 입력 100만 토큰당 4달러·출력 20달러이고, 일반적인 작업 기준 운영 비용이 Opus 5보다 40% 낮다고 발표됐다. 공개 직후 “프롬프트 한 줄로 도트 애니메이션 영상 끝”이라는 유튜브 영상이 돌았고, 이 글은 그 주장을 파이썬 파일 하나로 실제로 재현해 본 기록이다.

솔직히 제목부터 의심이 갔다. “한 줄로 끝”이라는 말은 AI 업계에서 “설치는 3분, 디버깅은 3시간”이랑 거의 같은 뜻으로 쓰이기 때문이다. 그래서 영상을 보고 감탄만 하는 대신, 같은 종류의 결과물을 편집 툴 없이 코드로만 뽑아 보고 어디서 막히는지 확인하기로 했다.

미리 선을 그어 두면, 아래 실행은 이 블로그 파이프라인의 작성 에이전트(Claude Opus 5.5)가 스크립트를 짜고 로컬 맥에서 1회 돌린 기록이다. 몇 주 써 본 사람의 장기 후기가 아니고, 6초짜리 저해상도 결과만 확인했다. 그 범위 안에서 본 것만 적는다.

영상이 실제로 주장한 것: “한 줄”이 아니라 “씬 계획표”

원본 영상은 스위스 케이블카 역사를 담은 도트 게임 프로모와 6개국을 자전거로 달리는 로파이 영상을 보여 준다. 프리미어나 애프터이펙트를 켜지 않고, 이미지도 따로 그리지 않고, 효과음까지 파이썬 스크립트가 합성했다는 것이 핵심 주장이다.

그런데 요약을 뜯어 보면 프롬프트는 한 줄이 아니다. 도입·전개·결말을 씬 단위로 나누고, 씬마다 배경·색·타이포·도장 애니메이션·효과음을 따로 적은 구조화된 텍스트 블록이다. 제목의 “한 줄”은 “사람이 그림을 한 장도 안 그렸다”에 가깝고, “글자를 한 줄만 썼다”는 뜻은 아니었다.

여기서 업계어 하나를 사람말로 바꿔 두자. 구조화 프롬프트는 쉽게 말해 영화 콘티를 글로 쓴 것이다. 감독이 “멋있게 찍어 줘”라고만 하면 촬영팀이 알아서 해 주지 않는 것처럼, 모델도 “도트 영상 만들어 줘”보다 “0~2초 밤하늘, 먼 산은 느리게, 가까운 산은 빠르게”를 받았을 때 훨씬 덜 헤맨다.

Anthropic도 공식 발표 페이지에 비슷한 사례를 실었다. 한 얼리 테스터가 여러 Claude 모델에게 단일 프롬프트로 게임을 만들게 했더니, Opus 5.5가 그래픽과 완성도에서 가장 높은 점수를 받았다는 내용이다. 다만 Claude 모델끼리의 비교이고 테스터 이름도 공개되지 않았으니, 내 환경에서도 그런지는 따로 돌려 봐야 안다.

직접 돌려본 조건: Pillow와 numpy만 허용

재현 조건은 일부러 빡빡하게 잡았다. 영상 편집 툴 금지, 이미지 생성 AI 금지, 설치된 라이브러리는 Pillow 11.2와 numpy 2.3뿐이다. 맥에 ffmpeg가 없다는 사실은 이때 처음 알았는데, 이게 나중에 벽이 된다.

씬 계획표는 원본 영상의 케이블카 프로모를 6초로 줄인 형태로 짰다. 에이전트에게 넘긴 계획은 아래 표와 같다.

구간 장면 모션 소리
0~2초 밤하늘, 산 두 겹, 케이블카 먼 산 느리게·가까운 산 빠르게(시차 스크롤), 케이블카가 줄 타고 이동 스퀘어파 멜로디
2~4초 “SWISS CABLE CAR” 타이틀 글자 타자 효과, “1908” 도장이 3배 크기에서 쾅 도장 착지에 맞춘 저음
4~6초 일출 도시 8×8 픽셀 블록(출력 화면에서는 32×32)이 뒤집히며 전환 멜로디 유지

에이전트는 이 표를 받아 주석 포함 122줄, 함수 일곱 개짜리 스크립트 하나를 한 번에 작성했다. 씬별 그리기 함수, 블록 전환 함수, 그리고 numpy로 스퀘어파를 만들어 WAV로 쓰는 효과음 함수다. 외부 에셋 파일은 하나도 없다.

결과: 1초 안에 나왔고, 결함도 같이 나왔다

실행 결과는 생각보다 빨랐다. 72프레임, 640×360 GIF가 렌더링 0.26초와 GIF 인코딩 0.61초 만에 나왔고 용량은 171KB였다. 6초짜리 효과음 WAV는 265KB로 거의 즉시 생성됐다. 사람이 도트를 찍었다면 케이블카 하나 그리는 사이에 끝났을 시간이다.

숫자에서 하나 눈에 띈 건 그림을 그리는 시간보다 GIF로 저장하는 시간이 두 배 넘게 걸렸다는 점이다. 적어도 이번 6초짜리 실행에서는 픽셀을 찍는 계산보다 프레임마다 색상표를 만들고 압축하는 인코딩 쪽이 더 무거웠다. 길이를 늘리거나 해상도를 올릴 계획이라면, 그리기 코드보다 출력 형식과 인코더를 먼저 고르는 편이 시간을 아낀다.

문제는 결과물을 뜯어볼 때 나왔다. 첫째, 타이틀 씬에서 케이블카가 사라졌다. 타이틀 배경을 만들 때 첫 씬의 “2초 시점” 그림을 재사용했는데, 그 시점에는 케이블카가 이미 화면 오른쪽 밖으로 나가 있었기 때문이다. 코드는 에러 없이 돌았고, 논리적으로도 틀린 데가 없었다.

둘째, 블록 전환이 끝난 뒤에도 일출 하늘이 한동안 탁한 갈색으로 보였다. 5.17초(62번째) 프레임의 하늘은 RGB(153, 107, 72)였고, 마지막 프레임에 가서야 주황에 가까운 (240, 163, 88)이 됐다. 남색과 주황을 RGB 값 그대로 직선으로 섞으면 중간에 채도가 빠진 갈색을 지나가기 때문이다. 이것도 에러 메시지는 없고 눈으로 봐야만 잡힌다.

셋째는 독립 검수 단계에서 잡혔다. 계획표에는 “도장 착지 저음”이라고 적었는데, 코드를 다시 계산해 보니 도장은 3.25초에 착지하고 저음은 3.0초에 먼저 울린다. 12fps 기준 3프레임 차이라 프레임 캡처만 봐서는 절대 안 보이고, 소리와 그림 타이밍을 따로 대조해야 잡히는 종류다.

넷째는 결함이라기보다 환경의 벽이다. Pillow의 GIF는 소리를 담을 수 없어서, 결과물이 “소리 없는 GIF”와 “그림 없는 WAV” 두 파일로 나뉘었다. 이 둘을 mp4 하나로 합치려면 ffmpeg 같은 인코더가 필요하고, 원본 영상처럼 소리 있는 영상을 원한다면 이 설치 단계가 사실상 필수다.

이해가 바뀐 지점: 병목은 생성이 아니라 검수

돌리기 전에는 “프롬프트를 잘 쓰면 한 번에 끝난다”가 핵심일 줄 알았다. 돌려 보니 생성 자체는 1초 안에 끝나는 쉬운 단계였고, 시간이 드는 건 프레임을 열어 보고 “케이블카 어디 갔지?”를 찾아내는 쪽이었다.

AI 에이전트를 신입 인턴에 비유하면 이 상황이 딱 맞다. 인턴이 “영상 다 만들었습니다!”라고 보고한 파일을 열었더니 주인공이 2초부터 퇴근해 있는 느낌이다. 일을 못 한 게 아니라, “주인공은 끝까지 화면에 있어야 한다”는 조건을 아무도 말해 주지 않았던 것이다.

그래서 실제로 쓸 결론은 프롬프트 한 줄이 아니라 세 단계다. 씬 계획표로 조건을 명시하고, 대표 프레임 몇 장을 열어서 눈으로 검수하고, 소리까지 필요하면 인코딩 환경을 먼저 준비한다. 생성이 싸진 만큼 검수가 결과 품질을 결정한다.

반대로 이 방식이 맞지 않는 경우도 분명하다. 4K 장편, 정밀한 오디오 싱크, 브랜드 가이드를 지켜야 하는 디자인이라면 코드 렌더링보다 전용 툴이 여전히 빠를 가능성이 높다. 이번 실행은 6초·저해상도만 봤기 때문에 그 영역은 확인하지 못했다.

따라 할 때 쓰는 체크리스트와 결정표

첫 시도에서 나온 결함을 기준으로, 다음에 같은 걸 만들 때 프롬프트와 검수에 넣을 항목을 정리했다. 씬 계획표에는 “모든 씬에서 계속 보여야 하는 오브젝트”를 따로 적는다. 이번 케이블카 실종은 이 한 줄이 없어서 생긴 문제다.

  • 씬 계획표에 구간·장면·모션·소리 네 칸을 채웠는가
  • 씬 사이에 계속 보여야 하는 오브젝트를 명시했는가
  • 색 전환이 있는 씬은 시작색·끝색과 중간 경유색(예: 남색→보라→주황)을 직접 적었는가
  • 씬마다 대표 프레임 1장씩, 최소 3장을 열어 봤는가
  • 효과음 시작 시각이 해당 모션 프레임 시각과 맞는지 숫자로 대조했는가
  • 결과물을 소리 포함 영상으로 낼지, GIF+효과음 분리로 낼지 정했는가

출력 형식은 환경에 따라 갈린다. 아래 결정표 기준으로 먼저 고르고 시작하면 마지막에 “소리가 왜 없지?”로 헤매는 시간을 줄일 수 있다.

상황 추천 출력 필요한 것
블로그·노션에 움짤로 넣기 GIF Pillow만으로 충분
숏폼 업로드, 소리 필요 mp4 ffmpeg 설치 후 GIF 대신 프레임→mp4 인코딩
게임 트레일러 초안 공유 GIF + WAV 분리 검수용으로는 충분, 공개용은 mp4 권장
4K·장편·정밀 싱크 전용 편집 툴 코드 렌더링은 초안 단계까지만

아직 남은 질문

원본 영상 설명란의 프롬프트 원문은 이번에 확인하지 못했다. 그래서 “원본 프롬프트를 그대로 넣으면 첫 시도에 결함이 없나”는 아직 모른다. 이번 결과는 같은 방식의 축소 재현이지, 원본의 정확한 재현은 아니다.

또 하나는 규모다. 6초에 0.26초였다고 해서 1분 4K가 비례해서 빠를 거라고 보장할 수는 없다. 다음 확인 거리는 ffmpeg를 설치한 뒤 같은 스크립트를 1080p·30초 mp4로 늘렸을 때 렌더링 시간과 오디오 싱크가 어떻게 되는지다.

FAQ

Claude Opus 5.5로 도트 애니메이션 영상을 만들 때 편집 툴이 정말 필요 없나요?

그림과 모션, 효과음 생성까지는 파이썬 스크립트만으로 가능했다. 다만 소리를 포함한 mp4로 합치려면 ffmpeg 같은 인코더가 필요하다. Pillow만 쓰면 GIF와 WAV가 따로 나온다.

프롬프트는 정말 한 줄이면 되나요?

원본 영상도 실제로는 씬별 배경·색·모션·효과음을 나눈 구조화된 블록을 썼다. 이번 재현에서도 씬 계획표를 넘겼는데 결함 3개가 나왔으므로, 한 줄보다는 조건을 명시한 계획표를 권한다.

첫 결과물에서 가장 흔한 문제는 뭔가요?

이번 실행에서는 씬을 재사용하면서 움직이던 오브젝트가 화면 밖으로 사라진 문제, RGB 직선 보간 때문에 하늘이 탁한 갈색을 지나간 문제, 효과음이 도장 착지보다 0.25초 먼저 울린 문제가 나왔다. 셋 다 에러 없이 돌아가서 프레임과 타이밍을 직접 대조해야만 잡혔다.

관련 글

공식 출처