Veo 3 텍스트 투 비디오: 좋은 클립을 망치는 여섯 가지 실수

Veo 3는 좀처럼 무작위로 실패하지 않습니다. 클립을 받아 보니 카메라가 피사체를 지나쳐 흘러가거나, 손이 카운터 속으로 녹아들거나, 대사가 입이 멈춘 뒤 반 초 늦게 떨어지는 경우, 원인은 대개 프롬프트의 빈틈입니다. 모델이 그 빈틈을 대신 메웠고, 그 메움은 모델 나름의 추측이었습니다.

아래에 정리한 실수들은 Veo 3로 텍스트 투 비디오 작업을 할 때 렌더를 가장 많이 낭비하는 것들이며, 대략 클립을 얼마나 크게 망가뜨리는지의 순서로 배열했습니다. 각 항목에는 재렌더 예산이 아니라 문구 하나로 해결되는 수정법이 있고, 생성 버튼을 누르기 전에 확인할 수 있습니다.

실수 1: 짧은 클립 하나에 장면 전체를 담으라고 요구하기

한 번의 생성은 장면이 아니라 숏입니다. Google DeepMind의 Veo 샘플들도 각각 하나의 피사체, 하나의 카메라 동작, 하나의 오디오 베드를 설명하며, Magic Hour가 공개한 Veo 3.1 예시 역시 각각 8초짜리 생성 한 건이고, 결과는 완성된 시퀀스가 아니라 인서트 숏 하나라는 검토 노트가 붙어 있습니다.

실패는 무심코 쓰기 쉽습니다. “그녀가 카페로 걸어 들어와 플랫 화이트를 주문하고, 창가에 앉아 휴대폰을 확인한다.” 이는 8초를 두고 네 가지 행동이 경쟁하는 문장입니다. 돌아오는 결과는 보통 중간 행동이 어렴풋하게 수행된 장면이고, 손이 주머니에 닿기도 전에 휴대폰이 나타납니다.

숏을 이끄는 행동 하나를 고르는 것으로 고칩니다. 입장과 휴대폰은 따로 생성한 뒤 편집기에서 이어 붙이십시오. 어떤 행동이 가장 중요한지 결정할 수 없다면, 그 숏은 아직 프롬프트로 쓸 준비가 되지 않은 것입니다.

실수 2: 서로 충돌하는 카메라 무브를 겹쳐 쓰기

“느린 팬, 오빗, 푸시 인”은 촬영 용어처럼 읽히지만 실제로는 상충하는 세 가지 지시처럼 작동합니다. Magic Hour의 문제 해결 목록이 바로 이 점을 지적합니다. 카메라가 계획을 무시하며, 해결책은 카메라 동작 하나를 골라 방향과 속도를 명시하고 그와 싸우는 움직임을 없애는 것입니다.

출력에서 징후를 살피십시오. 동작을 절반만 완수한 클립, 예컨대 앞으로 밀고 나가면서도 올라가지는 못하거나, 프레임 밖으로 미끄러져 나가는 피사체를 계속 오빗하는 클립은 대개 카메라를 움직이지 못하는 모델의 결과가 아니라 무브 두 개가 들어간 프롬프트의 결과입니다.

무브 하나, 방향 하나, 속도 하나만 쓰십시오. “카메라가 천천히 한 번 푸시 인하며, 손의 미디엄 클로즈업에서 멈춘다.” 첫 무브가 단독으로 제대로 나온 뒤에야 두 번째 무브를 더하십시오.

실수 3: 보이는 행동 대신 분위기를 설명하기

시네마틱, 프리미엄, 감성적, 역동적 같은 단어는 픽셀로 변환되지 않습니다. 그것들은 완성된 숏에 대한 판단이고, 모델은 판단을 렌더링할 방법이 없습니다. 모델이 렌더링할 수 있는 것은 표면, 빛의 방향, 움직임입니다.

Higgsfield의 실수 목록은 반대편에서 같은 이야기를 합니다. 감정을 이름 붙이는 대신 브레이크 위의 망설이는 손이나 오래 머무는 시선처럼 카메라가 볼 수 있는 것에 감정을 묶으라는 것입니다. Magic Hour의 수정법은 치환 연습입니다. 프리미엄은 브러시드 메탈, 매트한 표면, 절제된 림 라이트가 되고, 시네마틱은 특정한 카메라 높이와 렌즈 느낌이 됩니다.

“프리미엄한 커피의 순간”과 “긁힌 오크 테이블 위 흰 컵에서 피어오르는 김, 왼쪽에서 들어오는 낮은 아침 빛, 고정된 카메라, 컵과 받침은 그대로”를 비교해 보십시오. 두 번째 문장은 모델이 실제로 그릴 수 있는 네 가지와 바꾸면 안 되는 한 가지를 제시합니다.

실수 4: 배제 사항을 명령문으로 쓰기

대부분의 프롬프트 작성자는 “텍스트 없음, 워터마크 없음, 추가 인물 없음” 같은 문장으로 끝냅니다. Google의 비디오 생성 프롬프트 가이드는 정반대 형태를 요구합니다. “벽 없음”, “벽을 보여주지 마” 같은 지시적 표현을 피하고, 원하지 않는 요소는 목록으로 제시해 보고 싶지 않은 사물의 이름을 나열하라는 것입니다.

여기서 실무적인 결과 두 가지가 따라옵니다. 첫째, 배제 사항은 모델이 읽도록 학습된 형태로 유지하십시오. 즉 사물과 논쟁하는 대신 사물의 이름을 부르는 것입니다. 둘째, 어떤 배제 사항이든 보장이 아니라 요청으로 취급하십시오. Magic Hour는 자막에 대해 이를 분명히 말합니다. 텍스트를 배제하라는 지시는 여전히 요청이며, 최종 프레임에 남은 글자가 없는지 여전히 확인해야 합니다.

그래서 문장은 “텍스트, 워터마크, 추가 인물”이 되고, 검토 단계는 텍스트가 흔히 나타나는 두세 프레임, 즉 간판, 화면, 포장, 카메라를 향한 모든 표면을 확인하는 일이 됩니다.

실수 5: 오디오를 트랙이 아니라 자막처럼 다루기

Veo 3는 효과음, 환경음, 대사를 화면과 같은 패스에서 함께 내보내며 오디오를 기본으로 생성합니다. 이는 무음 비디오 생성기에 비해 이 모델이 가진 가장 큰 강점이며, 이를 낭비하는 가장 빠른 방법은 사운드를 시각 묘사에 덧붙인 부수적인 요소로 취급하는 것입니다.

실패 양상은 두 가지가 두드러집니다. 첫째는 숏 길이에 비해 너무 긴 대사입니다. 문장이 끝날 즈음 입은 이미 움직임을 멈췄거나 대사가 잘립니다. 둘째는 음악, 룸 톤, 효과음, 말소리를 한 절에 몰아넣은 단일하고 뭉뚱그려진 오디오 요청으로, 모델이 하나만 골라 나머지를 버리게 됩니다.

레이어를 분리하고 화자를 명시하십시오. “조용한 스튜디오 룸 톤, 열쇠가 테이블에 닿는 금속성 소리 한 번, 음악 없음”은 믹스 지시입니다. “그녀가 편안한 목소리로 이것들이 첫 저녁 파티에 준비되었다고 말한다”는 연기 지시입니다. 대사는 실제로 요청한 길이에 들어갈 만큼 짧게 유지하고, 단어 수를 대본이 아니라 초 단위와 견주어 세십시오.

실수 6: 접점과 물리 법칙을 열어 두기

프롬프트가 명시하지 않은 것은 무엇이든 모델이 결정합니다. Higgsfield의 체크리스트는 이를 구체적인 사전 점검 절차로 바꿉니다. 접점, 즉 손과 손가락, 그리고 무엇이 무엇에 닿는지를 명시하고, 광원 하나를 이름으로 지정하며, 움직임의 방향을 밝히라는 것입니다.

손이 고전적인 희생양인 이유입니다. “그녀가 열쇠를 집어 든다”는 프롬프트는 그립, 손가락 개수, 각도를 미결로 남기고, 렌더는 이를 그럴듯함과 틀림 사이 어딘가에서 결정합니다. “그녀의 엄지와 검지가 열쇠의 고리 부분을 집어 테이블에서 들어 올린다”는 프롬프트는 남는 여지를 훨씬 줄입니다.

물리도 마찬가지입니다. 옷감, 액체, 머리카락은 모델이 가장 많이 즉흥적으로 처리하는 영역이므로, 고정되어야 할 것을 명시하십시오. 재킷은 움직이지 않는다, 액체는 잔 안에서 수평을 유지한다, 시계 문자판과 스트랩은 내내 그대로다. 이런 문장은 비용이 적게 들고, 쓸 만한 제품 숏과 재촬영 사이를 가르는 차이입니다.

고칠 것은 지시 하나이지 프롬프트 전체가 아니다

나쁜 클립을 받은 뒤의 본능은 전부 다시 쓰는 것이지만, 그러면 증거가 사라집니다. 재시도마다 지시 하나만 바꾸면 어떤 문장이 책임이 있었는지 알 수 있습니다.

기준 생성 결과를 남겨 두십시오. 같은 피사체, 같은 오디오로 고정해 둔, 잘 작동한다고 아는 숏입니다. 새 시도가 실패하면 둘을 비교해 차이를 명명하십시오. 동일한 텍스트를 다시 돌릴 때마다 실패 지점이 달라지면 프롬프트 문제입니다. 매번 정확히 같은 방식으로 틀린다면 설정 문제이며, 형용사를 더 붙여도 도움이 되지 않습니다.

다시 쓰기 전에 증상을 이 순서로 점검하십시오. 피사체의 구체성, 행동 개수, 카메라 무브 개수, 광원, 접점, 오디오 레이어, 그다음 불변 조건. 텍스트에서 실제로 가장 먼저 불충분하게 명시된 항목이 고칠 대상이며, 대개 그것 하나가 전부입니다.

생성 전에 대부분을 걸러내는 점검표

프롬프트를 한 번 읽고 각 줄에 표시하십시오. 답이 없는 줄은 모델이 답을 채웁니다.

• 피사체 하나, 텍스트만으로 알아볼 수 있을 만큼 구체적으로 묘사되었는가.
• 행동 하나, 눈에 보이는 결과가 있는 동사로 서술되었는가.
• 카메라 동작 하나, 방향과 속도가 명시되었는가.
• 이름이 붙은 광원 하나, 방향이 있는가.
• 모든 접점이 명시되었는가. 손, 발, 표면에 놓인 사물.
• 오디오가 말소리, 환경음, 효과음, 음악으로 분리되고 화자가 명시되었는가.
• 불변 조건 줄이 있는가. 숏 동안 바뀌면 안 되는 것.
• 길이, 해상도, 화면비는 문장이 아니라 인터페이스에서 설정했는가.

마지막 항목은 보기보다 중요합니다. 세로 프레이밍을 요구하는 프롬프트는 세로 설정처럼 출력 캔버스를 바꾸지 않으며, 가로로 렌더한 결과를 세로로 크롭하면 신경 쓴 행동이 잘려 나갑니다. 도구가 해당 컨트롤을 제공한다면 그 컨트롤을 쓰십시오.

이 모든 것이 Veo 3를 스토리보드처럼 예측 가능하게 만들지는 않습니다. 대신 실패를 읽을 수 있게 만듭니다. 그것이 다룰 수 있는 부분입니다. 이름 붙은 한 가지를 놓친 클립은 이름 붙은 변경 하나로 고칠 수 있지만, 모든 것을 놓친 클립은 보통 프롬프트가 모든 것을 한꺼번에 요구했다는 뜻입니다. 어떤 숏에 렌더를 쓸 가치가 있는지 아직 고민 중이라면 짧은 클립에 맞는 Veo 3 활용 사례에서 그 선택을 다루고, 수정한 프롬프트는 Veo 3 비디오 생성기에 넣으면 됩니다.