모션 캡처 슈트 없이,
AI가 영상만 보고 캐릭터에게 한 곡을 끝까지 춤추게 했습니다
2주 동안 제가 만든 3D 캐릭터 히나는 두 가지 동작으로 춤췄습니다. 커뮤니티에서 배포한 MMD 모션과 휴대전화로 찍은 실제 댄스 영상입니다. 두 번째는 모션 캡처 슈트 없이 AI가 영상에서 뼈대를 추정했고, 60초짜리 곡 전체를 춤출 수 있었습니다.
시작은 MMD Short 한 편이었습니다
실험 기간은 2026년 10월 4일부터 16일까지입니다. 360° 영상과 인터랙티브 무대는 10월 17일부터 19일까지 추가했습니다. 소재를 고르고 댄서에게 연락하고 영상을 검토해 결정한 사람은 저입니다. 변환, 측정, 카메라 배치 코드는 AI(Claude Opus 5.5)가 작성했습니다. 모델은 빨리 바뀌므로 결론은 그 며칠 동안 사용한 버전에 한정됩니다.
2026년 10월 4일, hololive의 〈Go Wild〉 MMD Short를 봤습니다. 커뮤니티 제작자 Taro²가 모션 파일을 만들어 공개 배포했고, 제게는 마침 3D 캐릭터 히나가 있었습니다.
히나가 춤추는 걸 보고 이전 글 〈멋진 춤이 엉망이 됐을 때, AI로 고칠 수 있을까?〉의 결론이 떠올랐습니다. 고치려면 모션 데이터를 고쳐야 합니다. 그렇다면 실제 사람이 춤춘 영상에서 데이터를 바로 읽어 오면 어떨까요?

YouTube에서 〈くじら〉 영상 세 편을 찾아 시험했습니다. 결과가 안정된 다음에야 댄서에게 연락했습니다. 놀라웠던 점은 모션 캡처 슈트 없이 휴대전화 영상 한 편을 AI에 보여 주는 것만으로 쓸 만한 춤 동작을 얻었다는 것입니다.
두 방법을 한 표로 비교

| 배포된 MMD 모션 | 실제 영상+AI | |
|---|---|---|
| 동작의 출처 | 커뮤니티 제작자가 만든 모션 파일 | 댄스 영상 한 편에서 AI가 프레임마다 뼈대를 추정 |
| 허락 | Readme를 읽고 세 주체를 크레딧에 표기 | 공개 전에 댄서에게 묻기 |
| 무엇이 망가지는가 | 다리 IK, 플레이어가 모션을 덮어씀 | 뼈대 불일치, 캐릭터 변형, 발 미끄러짐, 떨림 |
| 표정과 입 모양 | 제작자가 손으로 입력한 7개 | 없어서 직접 만들어야 합니다 |
| 이번 작업 규모 | 하룻밤에 14곡 | 60초짜리 한 편을 다섯 차례 수정 |
MMD는 빠르지만 규칙이 Readme에 적혀 있습니다. 영상 모션 캡처는 자유롭지만 수정도 필요하고 사람에게 먼저 물어야 합니다.
MMD: 하룻밤에 14곡, 변환 전후에서 문제가 생겼습니다

동작은 이미 만들어져 있습니다. 신경 쓸 곳은 변환 전의 이용 규약과 변환 후의 플레이어였습니다.
| 단계 | 일어나는 일 | 처리 방법 |
|---|---|---|
| 이용 규약 | 변환한 VRM 모션 파일도 재배포에 해당합니다. 모션 제작자만 표기하면 다른 사람이 빠집니다 | 모션 파일은 공개하지 않습니다. 인터랙티브 무대는 암호화한 모션을 나눠 전송하고 다운로드는 제공하지 않습니다. 원곡, 원래 댄서, 모션 제작자 세 주체를 크레딧에 표기합니다 |
| 다리 IK | MMD 방식으로 40번 반복해도 발목 오차가 다리 길이의 약 3% 남았습니다 | 수렴할 때까지 계산하고 오차가 0.5%를 넘으면 다음 단계로 가지 않습니다 |
| 플레이어 | 매 프레임 표정을 쓰고 허리에 댄 손을 밀어내며 캐릭터를 원점으로 되돌립니다 | 다른 사람이 만든 춤을 재생할 때는 세 기능을 모두 끕니다 |
| 표정 | 맞는 것은 7개뿐입니다(깜박임, 웃음, 다섯 모음) | 입 모양은 제작자가 손으로 입력한 것을 따르며 노래 소리에는 맞추지 않습니다 |
변환과 재생은 별개 단계입니다. 둘 다 측정했습니다.
카메라: 형용사에는 단위가 없지만 샘플 영상에는 있습니다

| 버전 | 방법 | 알게 된 점 |
|---|---|---|
| v1 | 고정 카메라 | 동작은 괜찮지만 화면이 평면적이었습니다 |
| v2 | 따라가는 카메라, 글자 카드 배경 | ‘강렬하게’를 조사해서 찾은 안전한 상한 안으로 제한했습니다 |
| v3 | 동작을 따라 카메라가 움직임 | ‘각도를 바꿔 줘’라고 했더니 AI는 카메라가 밀려 기우는 것으로 해석했습니다 |
| v4 | 손을 흔들 때마다 카메라 전환 | 카메라 위치가 정면에 몰렸습니다 |
| v5 | 12개 샷의 멀티 카메라, 모든 샷에서 움직임 | 카메라를 뒤쪽과 바로 위까지 분산했습니다 |
v5가 글 앞의 〈Go Wild〉입니다. v1~v4는 일부 공개 영상입니다: v1, v2, v3, v4. 각 버전의 3D 카메라 배치도는 〈카메라 구성 다섯 버전〉 메모에 있습니다.
카메라 구성에서는 세 가지를 지정해야 했습니다. 움직임의 강도, 한 카메라 안에서 움직일지 카메라를 바꿀지, 카메라를 어디에 놓을지입니다. 명확히 말하기 어려우면 AI에 각각 3초짜리 샘플을 만들어 달라고 해서 골랐습니다.
카메라 구성을 데이터로: 용어집과 검사기

카메라 구성을 템플릿 모음으로 나눠 프로그램이 뽑고 검사한 뒤, 기준에 맞지 않으면 다른 것으로 바꾸게 했습니다. 컷이 동작 중간에 놓이는지, 인접한 두 샷의 각도 차가 충분한지, 주인공이 프레임을 벗어나지 않는지를 숫자로 검사합니다. 같은 규칙으로 MMD 14곡을 배치했습니다. 〈くじら〉 무대 버전에는 Melies 카메라 구성 색인에서 정리한 용어집을 써서 64가지 표준 카메라 움직임 중 31개 샷을 구성했습니다.
생성기는 자유롭게 뽑아도 됩니다. 렌더링 전에 나쁜 샷을 막는 것은 검사기입니다.
다른 방법: AI가 휴대전화 영상에서 동작을 읽습니다
요약하면 SAM 3D Body가 영상 속 사람의 3D 뼈대를 프레임마다 추정해 모션 파일로 변환하고 히나에게 적용합니다. 다섯 차례 수정했고 매번 영상을 남겼습니다.
| 회차 | 수정한 것 | 측정한 변화 |
|---|---|---|
| 직접 캡처 | 수정 전: 굽은 등, 들린 발끝, 비틀린 골반 | 곡 전체의 뼈대 추정에 806초(RTX 3090 한 장) |
| 1·2차 수정 | 두 뼈대의 기준 자세와 히나의 관절 한계 | 발이 바닥을 뚫은 프레임 651 → 0, 관절 한계를 넘은 프레임 0 |
| 3차 수정 | 발 위치 이동: 닿은 발을 착지점에 고정 | 닿은 발의 미끄러짐 0.82 → 0 cm/프레임, 공중에 뜬 프레임 13 → 0 |
| 4차 수정 | 떨림: 뼈마다 시간축으로 부드럽게 처리 | 발 가속도 p99 27.8 → 6.1 cm/프레임² |
| 5차 수정 | 다리 모양, 페이드인·페이드아웃 때문에 추정이 불확실한 프레임 건너뛰기 | 처음 28프레임과 마지막 10프레임을 건너뜀 |
‘직접 캡처’ 영상을 처음 봤을 때 놀랐습니다. 고치기 전인데도 같은 춤이라는 걸 알 수 있었습니다.
영상 고르기: 가장 비용이 적게 드는 수정
시험한 영상 세 편의 조건은 크게 달랐습니다:
| 영상 | 해상도 | 비트레이트 | 평균 밝기(0~255) | 추정된 팔뚝 떨림(중앙값) |
|---|---|---|---|---|
| A(美弦) | 1440×1440 | 1.2 Mbps | 62 | 3.4°/프레임² |
| B | 1080×1920 | 5.4 Mbps | 122 | 2.5°/프레임² |
| C | 720×1264 | 1.0 Mbps | 116 | 10.4°/프레임² |
해상도가 가장 낮은 C는 팔 떨림이 다른 두 편의 3~4배였습니다. 가장 어두운 A는 오히려 떨리지 않았고, 어둠은 페이드인 프레임 몇 개에만 영향을 줬습니다.
| 조건 | 이유 |
|---|---|
| 고정 카메라 | 카메라가 흔들리면 발도 따라 미끄러집니다 |
| 한 사람이 전신으로 화면에 들어옴 | 발이 프레임 밖으로 나가면 바닥에 닿는지 추정할 수 없습니다 |
| 1080p 안팎, 충분한 비트레이트 | 해상도가 낮으면 팔이 떨립니다 |
| 시작 부분에 페이드인이 없음 | 가장 어두운 첫 28프레임은 건너뛸 수밖에 없었습니다 |
조건이 맞지 않는 영상은 뒤에서 아무리 고쳐도 메울 수 없었습니다.
뼈대와 관절: 기준 자세가 다르고 캐릭터가 버티지 못합니다

뼈의 방향을 그대로 맞추면 두 뼈대의 서 있는 자세 차이를 히나에게 억지로 떠넘깁니다. 대신 ‘기준 자세에서 얼마나 회전했는지’를 복사하니 똑바로 섰습니다. 다리는 예외여서 다시 방향을 맞췄습니다.

다른 문제는 캐릭터가 버틸 수 있는 범위였습니다. 관절을 하나씩 움직여 메시가 망가지기 시작하는 각도를 찾고 동작을 그 안에 묶었습니다. 대신 쪼그려 앉거나 다리를 드는 폭은 댄서보다 작아졌습니다.
한계표는 캐릭터의 사양이지 동작의 오류가 아닙니다.
작동하는 실험에서 작품으로

| 보충할 것 | 방법 |
|---|---|
| 곡 전체 | 검증할 때는 처음 20초만 렌더링했습니다. 모션 파일은 처음부터 곡 전체를 변환했으므로 길이를 늘릴 때는 다시 렌더링하면 됐습니다 |
| 립싱크 | 노래에서 보컬을 분리해 입 모양을 닫힘·반쯤 열림·열림에 각각 약 3분의 1씩 배정했습니다(554/611/629프레임) |
| 눈 깜박임 | 영상 시간 기준으로 2.5~5.5초마다 한 번씩 깜박입니다. 컴퓨터 시간을 쓰면 계속 깜박입니다 |
| 카메라 | 카메라 높이는 1 m 이상으로 하고 뒤에서는 전신만 찍습니다. 첫 버전은 7개 샷의 각도가 너무 낮아서 검사로 걸러냈습니다 |
| 360° | 관객은 뒤를 돌아볼 수 있으므로 뒤쪽과 양옆의 관객, 트러스, 후광을 추가하고 정면과 측면에서 8K(7680×4096) 영상 두 편을 렌더링했습니다 |
표 마지막 줄의 360° 영상은 히나 앞과 옆에 카메라를 놓은 8K 영상 두 편이 됐습니다. 컴퓨터에서는 플레이어를 드래그해 무대 전체를 둘러볼 수 있습니다. 휴대전화 YouTube App에서는 기기를 움직여 볼 수 있고 VR 헤드셋에서도 볼 수 있습니다.
렌더링이 재생보다 느릴 때 시간에 맞춰 움직이는 것은 모두 영상 시간을 기준으로 해야 합니다. 카메라 문제는 렌더링 전에 걸러야 합니다.
직접 둘러보기: MMD 14곡을 바꿔 가며 볼 수 있습니다
영상에서는 제가 정한 카메라 구도로만 볼 수 있습니다. 〈Go Wild〉와 같은 묶음의 MMD 춤 14곡을 직접 조작하는 무대로도 만들었습니다. 오른쪽 아래에서 YouTube Short가 재생되고, 무대 위의 히나는 영상 시간에 맞춰 같은 동작을 춥니다. 언제든 멈추고 왼쪽 아래 메뉴에서 곡을 바꾸며, 화면을 드래그해 히나 주위를 돌거나 확대·축소할 수 있습니다.
Taro²의 규약상 모션 파일을 재배포할 수 없어서 무대의 모션은 암호화해 나눠 전송하고 다운로드를 제공하지 않습니다. 노래는 YouTube 플레이어로 재생하며 페이지 자체에는 오디오가 없습니다.
새 탭에서 무대 열기 ↗(휴대전화에서는 전체 페이지로 열면 조작하기 편합니다)
휴대전화에서는 오른쪽 아래 YouTube 플레이어가 히나의 다리를 가립니다. 컴퓨터에서 보면 더 온전합니다.
함께 시험한 것
| 시험한 것 | 이유 | 결과 |
|---|---|---|
| JIZURA 글자 카드 배경 | MMD 배경이 너무 단조로웠습니다 | 글자 카드를 히나 뒤에 놓고 카메라와 같은 원근감을 적용해야 카메라 움직임이 보입니다 |
| AI가 만든 무대 | 콘서트 같은 느낌을 원했습니다 | 조명, LED 벽, 콜드 스파크를 모두 코드로 만들었습니다. 위에 나온 무대 버전입니다 |
| 음악에서 춤을 만드는 FlowerDance | AI가 스스로 안무를 할 수 있는지 보고 싶었습니다 | 트레이스한 춤과 나란히 놓으면 아직 차이가 큽니다. 모델에 라이선스 조항이 없어서 로컬에만 남겼습니다 |
| 동작 과장 | 모션 캡처 연기자가 동작을 더 크게 하라고 제안했습니다 | 과장이 심해서 보기 불편해 보류했습니다 |
곁가지도 한 번씩 시험했습니다. 본 작업에 남은 질문은 동작을 어디서 얻고 카메라를 어떻게 배치하느냐 두 가지였습니다.
해낸 것과 아직 남은 것
| 해낸 것 | 아직 못 한 것 |
|---|---|
| 하룻밤에 MMD 14곡 | 점프: 엉덩이 높이가 아직 낮은 쪽 발을 따라갑니다 |
| 영상 모션 캡처로 60초 곡 전체 | 손가락은 움직이지 않고 고정됩니다 |
| 발 고정, 립싱크, 눈 깜박임 | あいうえお 입 모양은 없습니다 |
| 구도 규칙을 검사로 구현 | 허벅지를 앞과 바깥으로 동시에 들면 치마에 구멍이 생깁니다 |
| 인터랙티브 무대에서 14곡을 선택할 수 있습니다 | 휴대전화에서는 YouTube 플레이어가 다리를 가립니다 |
2026년 10월에는 조건이 좋은 휴대전화 댄스 영상 한 편과 AI만으로 3D 캐릭터가 한 곡을 끝까지 춤출 수 있었습니다.
AI 에이전트에게 복사하기
캐릭터가 따라 추게 하고 싶은 댄스 영상이 있다면 아래 내용을 AI에게 붙여 넣으세요.
더 읽을거리
| 자료 | 중요한 이유 |
|---|---|
| dekopon 〈Go Wild〉 MMD Short | 모든 일의 출발점입니다. 이걸 보고 히나를 춤추게 하고 싶었습니다 |
| Taro²(BowlRoll) | 14곡 모션의 제작자입니다. 그의 Readme는 이용 규약을 읽고 세 주체를 크레딧에 표기하는 본보기가 됐습니다 |
| JIZURA | 가사 시간에 맞춰 글자 카드를 생성합니다(MIT 라이선스). 평평한 배경에서는 카메라 움직임이 보이지 않는다는 걸 알았습니다 |
| Melies: Cinematic Techniques | 카메라 용어집의 출처입니다. ‘강렬한 카메라 움직임’을 이름과 정의가 있는 움직임으로 바꿨습니다 |
| SAM 3D Body | 영상 한 편에서 3D 뼈대를 추정하는 두 번째 방법의 출발점입니다. Meta의 SAM License(2025-11-19 버전)는 무료 사용, 수정, 재배포를 허용하며 SAM으로 만든 결과를 공개할 때 사용 사실을 밝혀야 합니다 |
| FlowerDance | 음악에서 춤을 만드는 모델(ECCV 2026)입니다. 시험해 보니 음악에서 만든 춤과 트레이스한 춤의 차이가 얼마나 큰지 알 수 있었습니다 |
| 〈멋진 춤이 엉망이 됐을 때, AI로 고칠 수 있을까?〉 | 그 글의 ‘고치려면 모션 데이터를 고친다’는 결론 때문에 실제 영상을 시험했습니다 |
| 〈직접 만든 옷 갈아입는 인형 공유: 디자인 한 장에서 3D까지〉 | 히나를 만든 과정입니다 |
| 메모 세 편: 카메라 구성 다섯 버전, 하룻밤에 MMD 14곡, 모션 캡처 | 각 버전의 영상과 측정 세부 사항이 있습니다 |
음악, 춤, 모션의 권리
이 글에 나오는 곡, 춤, 모션은 각각 원 권리자의 것입니다. 여기서는 실험 결과를 설명하기 위해서만 인용합니다. 권리자께서 삭제를 원하시면 댓글로 알려 주세요.
| 유형 | 작품과 권리자 | 사용한 곳 |
|---|---|---|
| 음악 | Yaffle 〈くじら (feat. Sahnya)〉 | 〈くじら〉 비교판, 무대판, 360° 영상 두 편과 과정 영상 다섯 편의 오디오는 모두 YouTube에서 재생됩니다 |
| 안무와 원본 영상 | 美弦(@mitsuru_SelfChoreograph) | 영상 모션 캡처의 동작 원본과 나란히 놓은 스크린샷입니다. 공개 전에 동의를 받았습니다 |
| 음악과 안무 | 轟はじめ 〈Go Wild〉(hololive) | 〈Go Wild〉 카메라 구성 다섯 버전의 오디오와 춤입니다. MMD 모션은 Taro²가 轟はじめ 본인의 Short를 트레이스했습니다 |
| MMD 모션 | Taro²(BowlRoll에서 배포) | MMD 춤 14곡입니다. 인터랙티브 무대의 모션은 암호화해 나눠 전송하며 다운로드는 제공하지 않습니다 |
| 인터랙티브 무대의 노래 | 14곡은 각각 원 권리자에게 속합니다 | 제가 올린 Short만 YouTube 플레이어로 재생하며 무대 페이지 자체에는 오디오가 없습니다 |
