카메라 모션 랩: 147개의 동영상이 알려 준 카메라 움직이는 법

카메라 움직임 64가지를 테스트한 결과, 영화 용어가 동영상 모델이 가장 잘 이해하는 언어는 아닐 수도 있다는 사실을 알게 되었습니다.

처음에는 문제가 단순해 보였습니다.

Nodaro에는 카메라 모션 피커가 있습니다. 사용자가 오비트, 트럭, 돌리 인, 휩 팬 같은 움직임을 선택하면, 우리는 그 움직임을 짧게 설명하는 문구를 동영상 프롬프트 끝에 덧붙입니다.

가장 평범한 전문가식 지시로 시작했습니다.

촬영감독이나 영화감독이라면 누구나 바로 이해할 지시입니다. 모델은 거의 움직이지 않았습니다.

이번에는 오비트를 시도했습니다.

이번에도 결과는 불안정했습니다. 방향이 맞게 나온 것은 절반 정도뿐이었습니다.

설명을 더 늘려 보기도 했습니다. 방향을 나타내는 다른 문구, 각도, 더 강한 표현, 제외 지시, 다양한 클립 길이를 테스트했습니다. 결과가 나아질 때도 있었습니다. 더 나빠질 때도 있었습니다. 그리고 모델이 완전히 다른 동작을 할 때도 있었습니다.

그래서 움직임의 이름을 모델에 알려 주는 것을 그만두었습니다. 대신 카메라가 물리적으로 무엇을 하는지 설명하기 시작했습니다. 그것이 거의 모든 것을 바꿨습니다.

연구의 방향을 바꾼 두 가지 발견

실험이 끝날 무렵, 우리는 두 가지 핵심 발견에 도달했습니다.

실제로 테스트한 내용

연구는 25일 동안 진행되었습니다. 동영상 147개와 베이스 이미지 13장을 생성했고, 총 72,118크레딧을 사용했습니다. 연구 기간에 공개된 충전 가격으로 약 $200~220에 해당합니다.

98개는 Seedance 2.5로 480p에서, 47개는 Seedance 2 Fast로 생성했습니다. 나머지 2개는 초기에 공급자를 비교할 때 VEO 3.1로 생성했습니다.

Seedance 2.5 · 98Seedance 2 Fast · 47VEO 3.1 · 2

최종적으로 대상으로 삼은 카메라 모션 옵션 64개가 모두 승인되었습니다. Seedance 2.5에서 61개, Seedance 2 Fast에서 3개입니다.

이 구분은 실제로는 존재하지 않았던 편향을 하마터면 모델 탓으로 돌릴 뻔했을 때 특히 중요해졌습니다.

존재하지 않았던 “왼쪽 편향”

연구 초기에 같은 움직임을 반대 방향으로 테스트했습니다. 이미지도, 프롬프트 구조도, 길이도 같았습니다.

왼쪽3 / 3

오른쪽1 / 3

왼쪽은 3번 중 3번 성공했습니다. 오른쪽은 3번 중 1번만 성공했습니다. 이 패턴은 네 가지 다른 표현으로 시도한 오른쪽 방향 12번의 시도에서도 계속되었습니다.

결론은 뻔해 보였습니다. 모델에 왼쪽 편향이 있다는 것이었습니다. 이를 위해 240크레딧의 추가 예산까지 잡았습니다. 우리가 틀렸습니다.

문제는 방향을 설명하는 방식이었습니다. 방향을 피사체를 기준으로 한 쪽이 아니라 카메라가 이동하는 방향으로 표현하자 이 패턴이 사라졌습니다. 그 뒤로 이 표현으로 테스트한 오른쪽 방향 움직임은 첫 테이크에 통과했습니다.

이는 이 프로젝트에서 가장 중요한 교훈 중 하나가 되었습니다.

교훈

일관된 실패 패턴이 반드시 모델의 특성을 드러내는 것은 아닙니다. 때로는 내 문구의 문제를 드러냅니다.

돌파구: 움직임은 기하학

전환점은 아크 오른쪽이었습니다. 모델에 움직임의 이름만 주는 대신, 다음 다섯 가지를 설명했습니다.

1. 카메라가 물리적으로 무엇을 하는지.
2. 무엇이 일정하게 유지되는지.
3. 가까운 요소와 먼 요소가 서로에 대해 어떻게 움직여야 하는지.
4. 마지막 시점이 어떻게 보여야 하는지.
5. 어떤 원치 않는 움직임이 일어나면 안 되는지.

승인된 프롬프트는 다음과 같았습니다. 다섯 가지 항목마다 한 문장씩입니다.

parallax(시차)라는 단어가 그대로 남아 있는 것은 이것이 실제로 테스트한 프롬프트이기 때문입니다. 개념은 간단합니다. 카메라가 공간을 물리적으로 이동하면 가까운 물체와 먼 물체는 같은 속도로 프레임을 가로지르지 않습니다.

이 프롬프트의 중요한 차이는 길이가 아닙니다. 우리가 Arc(아크)로 무엇을 뜻하는지 모델이 이해해 주기를 더 이상 기대지 않는다는 점입니다. 이 프롬프트는 움직임 자체를 설명합니다. 카메라는 피사체 주위를 곡선으로 돌며 옆으로 이동하고, 구도를 유지하도록 계속 피사체 쪽으로 방향을 돌리고, 거리를 유지하며, 가까운 요소가 먼 요소보다 더 많이 이동하는 모습을 보고, 약간 다른 시점에서 끝납니다.

이 변경 전에는 아크 오른쪽에 12테이크를 쓰고도 결과가 약했습니다. 기하학적 설명으로 바꾸자 3번 중 3번 성공했습니다.

편집 전

실패이름에 기댄 문구, 12테이크 중 1테이크째. 오른쪽으로 호를 그리라고 했는데 왼쪽으로 갔습니다.

편집 후

승인됨기하학적 문구, 첫 테이크.

카메라가 실제로 움직였는지 판별하는 방법

가까운 물체와 먼 물체의 움직임 차이는 가장 유용한 진단 도구 중 하나가 되었습니다.

카메라가 공간을 물리적으로 이동하면 깊이 레이어 사이의 관계가 바뀝니다. 카메라에 가까운 물체는 보통 먼 물체보다 빠르게 프레임을 가로지릅니다. 카메라가 제자리에서 회전만 하면 프레임은 움직이지만, 그런 깊이 변화는 같은 방식으로 일어나지 않습니다. 그리고 순수한 줌이라면 카메라는 전혀 움직이지 않고 원근감도 거의 그대로입니다.

여기서 유용한 분류를 얻었습니다.

돌리 줌에서 프롬프트에 적어 넣은 테스트는 다음과 같습니다.

영어 원문의 대문자는 승인된 프롬프트에 적힌 그대로입니다.

다섯 번 실패한 360도

피사체 주위를 한 바퀴 완전히 도는 움직임은 연구 초기에 가장 어려운 사례 중 하나였습니다. 원래 문구로는 근처에도 가지 못했습니다.

180 degrees(180도)를 시도하자 한 바퀴에 더 가까운 움직임이 나왔지만, 방향이 반대였습니다. 다음으로 이것을 시도했습니다.

결과는 더 나빴습니다. 카메라는 시작 지점에서 조금 벗어났다가 다시 돌아왔습니다. 한때는 동영상 레퍼런스 없이는 안정적인 360도가 불가능할지도 모른다고 메모에 적어 두기까지 했습니다. 우리는 또 틀렸습니다.

해결책은 “360”을 요청하는 대신 경로를 상태의 연속으로 설명하는 것이었습니다. 피사체의 한쪽, 피사체의 뒤, 반대쪽, 그리고 다시 시작 지점입니다. 속이기 어려운 테스트도 추가했습니다.

카메라가 실제로 피사체 주위를 돌고 있지 않다면 이 조건을 그럴듯하게 충족하기는 어렵습니다. 마지막으로 다음을 추가했습니다.

새 문구는 바로 첫 테이크에 통과했습니다.

편집 전

실패원래 카탈로그 문구. 한 바퀴에 한참 못 미칩니다.

편집 후

승인됨경로를 상태의 연속으로 설명하고 속이기 어려운 테스트를 추가. 첫 테이크.

“더”를 요청하면 오히려 덜 나올 때

또 다른 시점에는 다음 문구로 경로를 늘려 보려고 했습니다.

결과는 예상과 정반대였습니다. 피사체 주위에 가상의 시계를 그리면, 카메라는 6시 위치에서 출발했습니다. 이 문구가 있으면 5시 근처까지만 갔고, 없으면 4시 근처까지 갔습니다.

“travelling a long way around”(먼 길을 빙 돌아 이동하며) 포함: 5시 근처에서 멈췄습니다.이 문구 없음: 4시 근처까지 갔습니다.두 실행 모두 피사체 정면인 6시에서 출발했습니다.

즉, 더 긴 경로를 요청하자 움직임이 짧아졌습니다.

숫자도 기대한 만큼의 정밀도를 주지 못했습니다. 예를 들어 180 degrees(180도)는 180도 움직임을 안정적으로 만들어 내지 못했습니다. 숫자가 항상 틀렸다는 것이 우리의 결론은 아닙니다. 프롬프트 안에 숫자로 적은 각도나 이동량이 이 목적에는 충분히 신뢰할 수 없었다는 것입니다. 하지만 다른 숫자 하나가 매우 중요하다는 사실이 드러났습니다. 바로 클립 길이입니다.

움직임의 일부인 클립 길이

같은 프롬프트가 5초에서는 원의 약 6분의 1을, 15초에서는 약 150도를 이동했습니다. 하지만 한계가 있었습니다. 15초로 시도한 한 번에서는 카메라가 끝 지점에 도달한 뒤 남은 시간을 채우려고 방향을 거꾸로 바꿨습니다.

중요한 예외가 있습니다. 브리딩과 푸시 풀입니다. 두 움직임 모두 다가갔다 물러나기를 반복하는 것 자체가 움직임입니다. 그래서 이 둘은 반복이 제대로 보일 시간을 주려고 클립을 10초로 늘렸습니다.

속도가 어떻게 보이는지로 요청하기

“fast”(빠르게)나 “slow”(느리게) 같은 단어만으로도 충분히 제어할 수 없었습니다. 더 효과가 있었던 것은 속도의 결과로 눈에 보이는 것을 설명하는 방법이었습니다. 예를 들어 휩 팬에는 다음 문구를 사용했습니다.

크리프 인에서는 거의 반대로 했습니다.

적절한 길이와 결합하자 차이가 훨씬 뚜렷해졌습니다. 돌리 계열 안에서는 이것이 사실상 속도의 사다리를 만들었습니다.

크리프 인가장 느림

10초

돌리 인일정한 속도

7초

푸시 인가장 빠름

4초

바탕이 되는 기하학적 설명은 대부분 거의 그대로 둘 수 있습니다. 그래서 모델에 얼마나 빨리 움직일지만 알려 주기보다, 그 속도가 화면에서 어떻게 보여야 하는지 설명하는 편이 더 효과적일 수 있습니다.

엔진이 아닌 가드레일인 부정 지시

처음에는 부정 지시가 아예 효과가 없다고 생각했습니다. 그 결론은 지나쳤습니다.

다음 지시로 3테이크를 실행했습니다.

그래도 카메라는 안쪽으로 밀고 들어갔습니다. 더 효과가 있었던 것은 원하는 동작을 먼저 긍정형으로 정의하는 것이었습니다.

그런 다음에야 다음을 추가했습니다.

승인된 프롬프트를 제외 문장이 있을 때와 없을 때로 나눠 비교하는 통제 실험은 하지 않았습니다. 그래서 성공 중 얼마만큼이 그 문장 덕분인지는 측정할 수 없습니다. 더 신중한 결론은 긍정형 지시가 주된 엔진이고, 제외 지시는 우리의 작업 방식에서 추가 가드레일 역할을 한다는 것입니다. 스크린 탭과 폰 플립도 같은 패턴을 뒷받침합니다. 성공한 수정은 일어나야 할 일에 대한 긍정적인 설명과 나타나면 안 되는 것에 대한 명시적인 제외를 함께 사용했습니다.

동영상으로 새어 나오는 단어

연구 후반에는 문제가 물리가 아닐 때도 있다는 사실을 발견했습니다. 원인은 단어 하나였습니다. 동영상 모델은 느낌을 표현하려고 고른 단어를 문자 그대로의 시각적 동작으로 바꿔 버릴 수 있습니다.

• 페데스탈 업. rock strata ... descend into view(암석층이… 시야로 내려옵니다)라고 적었습니다. 모델은 시점만 바꾼 것이 아니라 바위 자체를 떨어뜨렸고, 클립 끝에서는 바위가 쌓였습니다. 이 문장은 장면 속 특정 물체를 지목하고, 아래로 향하는 동작을 카메라가 아니라 그 물체에 붙였습니다.
• 돌리 줌. bend(휘다)와 dizzying(어지러운) 같은 단어를 사용했습니다. 깊이가 늘어나는 대신 프레임이 약 90도 롤했습니다. 느낌을 표현하려고 고른 단어가 롤 요청으로 읽힌 것입니다.
• 스크린 탭. finger tap(손가락 탭)이라는 문구 때문에 모델은 장면에 실제 손가락을 그려 넣었고, 클릭 소리까지 넣었습니다.
• 폰 플립. rotates(회전합니다)라는 단어는 한 번의 빠른 뒤집기가 아니라 회전목마처럼 부드럽게 계속 도는 회전이 되었습니다.

예를 들어 돌리 줌에서는 다음과 같이 적습니다.

편집 전

실패1테이크째, “bend”(휘다)와 “dizzying”(어지러운) 사용. 프레임이 약 90도 롤했습니다.

편집 후

승인됨2테이크째. 깊이만 설명하는 문구, 프레임은 수평 유지.

그 안의 세계가 아닌 프레임을 설명하기

카메라 모션 지시는 사용자가 움직이게 만들 수 있는 모든 것에 통해야 합니다. 배, 자동차, 실내, 거리, 사람, 수중 장면 등입니다. 그래서 장면에 하늘, 바닥, 산, 벽, 특정 램프가 있다는 것을 전제할 수 없습니다.

연구 초기에 the turquoise lamp post(청록색 가로등)를 언급한 문구를 탈락시켰습니다. 장면에 특화된 설명은 테스트 이미지에서는 실제로 도움이 될 수 있어서 이 함정에 빠지기 쉽습니다. 하지만 이미지에 청록색 가로등이 있어서 작동하는 프롬프트라면, 우리는 범용 카메라 움직임을 만든 것이 아닙니다. 이미지 한 장용 프롬프트를 만든 것입니다.

한편 지나친 추상화도 해가 될 수 있습니다. 트럭에서 new elements keep entering from the left edge(새로운 요소가 왼쪽 가장자리에서 계속 들어옵니다)를 더 추상적인 표현으로 바꿔 보았습니다. 실패했습니다. elements(요소)라는 단어는 장면의 특정 내용을 가리키지 않으므로 원래 문구로 되돌렸습니다.

샷에 들어오는 촬영 장비

촬영 장비가 물리적 제약을 설명하는 데 도움이 될 때도 있었습니다. 삼각대는 회전은 허용하지만 카메라 이동은 막습니다. 수직 지지대로는 회전 없이 올라가는 움직임을 설명할 수 있습니다. 지브로는 수직 움직임과 각도 변화의 조합을 설명할 수 있습니다.

하지만 여기에는 또 다른 함정이 있었습니다. 우리는 이렇게 적었습니다.

모델은 그냥 샷 안에 트랙을 그려 넣었습니다.

편집 전

실패프롬프트에 장비 이름을 적음. 트랙이 샷 안에 그려졌습니다.

편집 후

승인됨장비 이름을 적지 않은 돌리 인.

두 번째 발견: 시작 프레임도 프롬프트

연구 후반에 새로운 패턴이 나타나기 시작했습니다. 문구는 맞아 보였습니다. 고쳤습니다. 다시 고쳤습니다. 같은 실패가 남았습니다. 이런 경우 우리는 엉뚱한 것을 고치고 있었습니다. 문제는 시작 이미지였습니다.

이미지로 동영상을 만들 때 첫 프레임은 단순한 소스가 아닙니다. 카메라가 어디에 있는지, 어느 방향을 보고 있는지, 어떤 이어짐이 시각적으로 그럴듯한지를 이미 모델에 알려 줍니다. 때로는 그 지시가 텍스트보다 강합니다.

POV가 될 수 없었던 POV

숲속을 걷는 사람이 담긴 이미지로 POV 워크를 테스트하면서, 카메라가 그 사람의 시점이 되도록 요청했습니다. 그 사람은 프레임 안에 그대로 남았습니다.

돌이켜 보면 당연한 일입니다. 첫 이미지가 이미 카메라는 사람의 바깥에서 그 사람을 보고 있다는 것을 정해 둡니다. 모델은 그 프레임에서 이어 가야 하며, 갑자기 주요 피사체를 지우고 그 사람의 눈 안쪽에서 시점을 다시 만들 수는 없습니다. 사람도, 보이는 신체 부위도 없는 얼음 터널로 새 베이스 이미지를 만들자 같은 기본 지시가 바로 통과했습니다.

스노리캠은 반대의 교훈을 주었습니다. 스노리캠에서는 카메라에 대해 고정된 채 보이는 피사체가 실제로 필요하고, 그 주위로 세상이 움직여야 합니다. 걷는 사람이 담긴 베이스 이미지에서 첫 테이크에 통과했습니다. 시작 이미지의 같은 성질이 어떤 움직임에는 버그가 되고, 다른 움직임에는 필수 조건이 될 수 있습니다.

끝내 하강하려던 플라이 오버

플라이 오버는 처음에 카메라가 이미 바깥쪽 아래를 내려다보고 있는 도시 항공 이미지로 테스트했습니다. 일정한 고도로 전진하도록 요청했습니다. 카메라는 하강했습니다. 문구를 강화했습니다. 또 하강했습니다. 같은 무렵, 같은 베이스로 시도한 에어리얼 3번도 모두 깔끔한 수직 하강 대신 아래로 기울어졌습니다.

지시를 더 추가하는 대신 순항 고도의 새 베이스를 만들었습니다. 수평으로 앞을 향한 시점, 넉넉한 하늘, 그리고 카메라와 거의 같은 높이의 산봉우리입니다. 이 베이스에서 플라이 오버는 첫 테이크에 통과했습니다.

이전 베이스

실패바깥쪽 아래를 보는 도시 베이스, 강화한 문구. 그래도 가라앉았습니다.

새 베이스

승인됨순항 고도의 수평 베이스. 첫 테이크.

측정 도구가 된 베이스 이미지

모두 13장의 베이스 이미지를 만들었습니다. 아름다워 보이는 것을 우선으로 고르지 않았습니다. 카메라 움직임이 맞는지 드러나도록 설계했습니다.

좋은 베이스 이미지는 올바른 움직임을 보이게 하는 데서 그치지 않습니다. 잘못된 움직임이 숨을 곳이 없도록 설계됩니다.

오버 더 숄더: 한 테이크에 세 가지 실패

카탈로그를 마무리한 마지막 옵션은 첫눈에 인상적이라는 이유로 클립을 승인하면 안 되는 이유를 잘 보여 줍니다. 오버 더 숄더의 첫 테이크에는 별개의 문제가 세 가지 있었습니다.

• 아무도 요청하지 않은 외국어 대화를 모델이 만들어 냈습니다.
• 카메라가 너무 먼 곳에서 시작해, 처음부터 올바른 구도로 잡혀 있는 대신 푸시 인을 했습니다.
• 두 번째 인물이 자연스럽게 대화에 몰입한 것처럼 보이는 대신 카메라를 향해 미소 지었습니다.

각 문제를 따로 고쳤습니다. 대화하는 몸짓이 더 그럴듯한 베이스를 만들고, 구도를 고정하는 지시와 푸시 인을 하지 않는 지시를 명시적으로 추가했으며, 대화 없는 무음을 지정하는 동시에 생성 자체에서도 사운드를 껐습니다.

카메라 움직임이 아닌 옵션

이 연구에서는 분류의 문제도 드러났습니다. 매치 컷 줌, 벨로시티 에디트, 스크린 탭, 폰 플립은 전통적인 카메라 움직임이 아닙니다. 편집 효과나 트랜지션 효과에 더 가깝습니다.

예를 들어 스크린 탭에서는 효과를 일으키는 물리적 동작을 설명하자마자 모델이 그 동작을 그렸습니다. 성공한 문구는 대신 트랜지션의 결과로 프레임에 무슨 일이 일어나는지를 설명했습니다. 이로 미루어 이 네 가지 옵션은 카메라 움직임보다 트랜지션에 속하는 편이 맞을 수 있습니다. 전환 피커를 참고하세요.

편집 전

실패“finger tap”(손가락 탭)이 들어간 문구. 실제 손가락이 나타났습니다. 음소거를 해제하면 클릭 소리가 들립니다.

편집 후

승인됨프레임만 설명한 문구, 사람이 없는 베이스.

방법을 찾은 뒤 달라진 점

수업료를 가장 많이 치른 곳은 오비트와 아크 계열이었습니다. 147개의 동영상 중 51개가 이 계열의 옵션 5개만을 위해 생성되었고, 옵션당 평균 10테이크가 넘습니다. 전문 용어만으로는 충분히 신뢰할 수 없다는 것을 배우고, 하마터면 “왼쪽 편향”을 지어낼 뻔하고, 기하학적 템플릿이 탄생한 곳도 이 계열이었습니다.

나머지 59개 옵션에는 모두 91테이크가 들었고, 옵션당 약 1.5테이크입니다. 트럭과 틸트도 비교적 일찍 테스트했기 때문에 이 구분이 완벽하게 시간순은 아니지만, 배움이 첫 계열에 얼마나 집중되었는지는 잘 보여 줍니다.

오비트와 아크옵션 5개 · 51테이크

10.2

나머지 59개 옵션91테이크

1.5

모든 것을 고쳐 쓸 필요는 없었습니다. 14개 옵션은 원래 카탈로그 문구 그대로 통과했습니다. 그 무렵 우리는 또 하나의 프로세스 규칙을 채택했습니다.

교훈은 “프롬프트는 길수록 좋다”가 아닙니다. 움직임을 안정적으로 정의하는 데 필요한 것만 적으라는 것이 교훈입니다.

우리가 남긴 13가지 규칙

1. 모션 프롬프트 안에서 각도, 이동량, 속도를 숫자로 설명하지 마세요. 클립 길이는 별도의 파라미터입니다.
2. 카메라 이동 방향은 하나로 명확하게 정하세요. 같은 경로 위의 여러 경유 지점을 설명할 수는 있지만, 서로 충돌하는 방향 지시는 주지 마세요.
3. 피사체는 기하학적 기준점이 될 수 있습니다. 거리, 피사체 크기, 구도는 유효한 기준이지만, 모션 프롬프트가 피사체의 행동이나 동작을 지시해서는 안 됩니다.
4. 장면의 구체적인 내용을 언급하지 마세요. 이미지가 바뀌어도 쓸 수 있는 지시여야 합니다.
5. 의도한 움직임에 속하는 어휘를 사용하고, 바뀌면 안 되는 축은 명시적으로 지키세요.
6. 먼저 카메라가 해야 할 일을 긍정형으로 정의하세요. 부정형 제외는 추가 가드레일이며, 원하는 움직임을 설명하는 일을 대신하지 않습니다.
7. 어떤 깊이 레이어를 거의 움직이지 않는다고 설명하지 마세요. 깊이를 전달하려면 가까운 요소와 먼 요소 사이의 점진적인 움직임 차이를 설명하세요.
8. 핸드헬드, 스테디캠, 브이로그, 드리프트는 카메라가 제자리에 머무는지 밝혀야 합니다. 그렇지 않으면 흔들림이나 일렁임이 원치 않는 이동으로 바뀔 수 있습니다.
9. 올바른 움직임이 끝난 뒤 되돌아가면 먼저 클립 길이를 확인하세요. 예외는 브리딩과 푸시 풀처럼 되돌아가는 것이 움직임의 일부인 경우입니다.
10. 두 옵션이 같은 기하학을 공유하면, 움직임의 성격이나 속이기 어려운 시각적 테스트로 구별하세요.
11. 편집 효과에서는 효과를 일으키는 물리적 동작이 아니라 프레임에 무슨 일이 일어나는지를 설명하세요.
12. 항상 기존 문구부터 테스트하세요. 고쳐 써야 한다면, 테스트 이미지의 내용에 맞추지 말고 범용으로 유지하세요.
13. 프롬프트를 두 번 고쳐도 같은 실패가 계속되면, 고쳐 쓰기를 멈추고 시작 프레임을 살펴보세요.

모든 테이크에 쓰는 체크리스트

결과를 검토할 때는 보기 좋은지만 묻지 않습니다. 다음 항목을 하나씩 따로 확인합니다.

• 방향이 맞나요?
• 카메라가 실제로 이동하고 있나요, 아니면 제자리에서 회전만 하고 있나요?
• 피사체까지의 거리가 그 움직임이 요구하는 대로 바뀌고 있나요?
• 모델이 추가 카메라 움직임을 지어내거나 샷 안에 촬영 장비를 그려 넣지 않았나요?
• 무언가가 떨어지거나 갑자기 나타나는 것처럼 장면 속 사건을 지어내지 않았나요?
• 피사체가 세계의 일부로 남아 있나요, 아니면 카메라에 붙은 것처럼 움직이나요?
• 그리고 하나 더: 움직임이 일찍 끝나고, 그래서는 안 되는데 되돌아가기 시작하지 않나요?

이 확인을 따로따로 하는 것이 중요합니다. 오버 더 숄더는 한 테이크가 동시에 세 가지 방식으로 실패할 수 있음을 보여 주었습니다.

제품에서 달라진 점

이제 카메라 모션 피커에서 테스트한 옵션 64개는 모두 랩에서 승인된 문구를 사용합니다. 그중 14개는 이미 잘 작동했기 때문에 원래 문구를 유지했습니다. 또한 회귀 테스트가 승인된 문구가 실수로 바뀌지 않도록 지킵니다.

이 연구는 몇 가지 열린 질문도 남겼습니다.

• 에어리얼은 아직 수직 하강과 시점을 아래로 기울이는 움직임을 완벽하게 구분하지 못합니다.
• 붐 업과 붐 다운은 페데스탈, 크레인과 크게 겹칩니다.
• 편집 유형의 옵션 4개는 트랜지션으로 분류하는 편이 더 맞을 수 있습니다.
• 클립 길이가 움직임의 중요한 부분으로 밝혀졌지만, 피커는 아직 유형별로 길이를 제안하지 않습니다.

우리가 배운 것

처음에는 모델이 촬영 언어를 더 잘 이해하게 만들려고 했습니다. 끝날 무렵에는 그것이 진짜 문제가 아니었다는 것을 깨달았습니다.

돌리, 오비트, 크레인 같은 용어는 사람이 일련의 물리 규칙을 한 단어로 압축하려고 쓰는 약어입니다. 모델이 그 단어를 항상 우리와 같은 방식으로 풀어내지는 않습니다. 이름에 덜 기대고 물리를 더 명시적으로 설명할수록 결과는 더 예측 가능해졌습니다. 무엇이 움직이는지, 무엇이 일정하게 유지되는지, 깊이가 어떻게 바뀌는지, 가까운 요소와 먼 요소가 서로에 대해 어떻게 움직이는지, 카메라가 어디에서 끝나야 하는지를 설명했습니다.

그리고 두 번째 발견이 있었습니다. 이미지로 동영상을 만들 때는 프롬프트만이 지시가 아닙니다. 첫 프레임도 지시이며, 때로는 그쪽이 더 강합니다.

그래서 지금은 카메라 움직임이 실패하면 “단어의 어디가 잘못되었을까?”라고만 묻지 않습니다. 이렇게도 묻습니다. “단어가 시작되기도 전에 이미지는 이미 모델에 무엇을 말하고 있었을까?”

한 줄 요약

물리를 더 잘 설명할수록 영화 용어로 설명할 필요는 줄어들었습니다.

카메라 모션 랩, 연구 노트, 2026년 9월. 이 페이지의 모든 클립은 연구에서 실제로 생성한 테이크입니다. 480p로 이미지에서 생성한 동영상이며, 그것을 대체한 테이크와 나란히 보여 줍니다.

자주 묻는 질문

AI 동영상 모델이 원하는 대로 카메라를 움직이게 하려면 어떻게 해야 하나요?

움직임의 이름을 말하는 대신 기하학으로 설명하세요. 카메라가 물리적으로 무엇을 하는지, 무엇이 일정하게 유지되는지, 가까운 요소와 먼 요소가 서로에 대해 어떻게 움직이는지, 샷이 어디에서 끝나는지, 어떤 원치 않는 움직임이 일어나면 안 되는지를 적습니다.

AI 동영상의 카메라가 엉뚱한 방향으로 움직이는 이유는 무엇인가요?

모델보다 문구가 원인인 경우가 많습니다. 방향은 피사체를 기준으로 한 쪽이 아니라 카메라가 이동하는 방향으로 적으세요. 두 번 고쳐 써도 같은 실패가 계속되면 시작 이미지가 카메라를 다른 방향으로 끌고 있지 않은지 확인하세요.

카메라 모션 프롬프트에서 “180 degrees”(180도) 같은 숫자가 효과가 있나요?

안정적으로 효과가 있지는 않습니다. 우리의 테스트에서는 숫자로 지정한 각도와 이동량대로 움직임이 나오지 않았습니다. 따로 설정하는 클립 길이가 카메라의 이동 거리에 훨씬 큰 영향을 주었습니다.

네거티브 프롬프트로 원치 않는 카메라 움직임을 막을 수 있나요?

가드레일로만 도움이 됩니다. “No zoom, no push-in”(줌 없음, 푸시 인 없음)만으로는 푸시 인을 막지 못했습니다. 먼저 “the camera maintains constant distance from the subject”(카메라는 피사체와 일정한 거리를 유지합니다)처럼 원하는 동작을 정의하고, 그 뒤에 제외 지시를 덧붙이는 편이 더 효과가 있었습니다.

이미지로 동영상을 만들 때 시작 이미지가 카메라 움직임에 영향을 주나요?

네, 크게 영향을 줍니다. 첫 프레임은 카메라가 어디에 있고 어떤 이어짐이 그럴듯한지를 이미 모델에 알려 줍니다. 걷는 사람이 담긴 이미지에서는 POV 움직임이 실패했고, 사람이 없는 이미지에서는 바로 통과했습니다.

관련 문서

카메라 모션

AI 동영상 모델에 카메라의 움직임을 알려 주세요. 돌리 인, 오비트 왼쪽, 크레인 업 같은 카메라 모션 66개 중 하나를 고르면 Nodaro가 검증된 문구를 추가합니다.

동영상 생성

Seedance, VEO, Kling, Wan 등으로 프롬프트, 시작 프레임, 레퍼런스를 동영상 클립으로 만드세요. 사운드, 종료 프레임, 모델별 크레딧 규칙도 정리했습니다.

Seedance 2.5

Seedance 2.5: Nodaro에서 실행할 수 있는 Bytedance의 동영상 모델입니다. 지원 모드는 이미지로 동영상 만들기, 텍스트로 동영상 만들기입니다. 실행 1회에 374크레딧부터 듭니다.

모델 선택

Nodaro에서 작업마다 알맞은 이미지, 동영상, 오디오, 텍스트 모델을 고르세요. 저렴한 초안용 모델부터 프리미엄 최종 렌더까지 최신 크레딧 가격과 함께 안내합니다.