DramaFork 비디오 실패 후 재시도 방법: 먼저 프롬프트, 소재, 작업 상태를 판단
비디오 작업이 실패하면 먼저 작업과 원본 프롬프트를 기록하고, 입력 버전을 확인한 뒤 관련 스토리보드나 참조를 수정할지 결정하고 개별적으로 재시도합니다. 먼저 두 가지 상황을 구분해야 합니다: 작업이 사용 가능한 비디오를 반환하지 않은 경우와, 이미 비디오를 반환했지만 내용이 맞지 않는 경우입니다. 전자는 실제 오류와 상태를 확인하고, 후자는 화면과 입력이 일치하는지 봅니다. 이 글은 DramaFork에서 정리했으며, 아래에서는 가상의 장면으로 점검 방법을 시연하고, 구성된 현상을 플랫폼의 실제 오류나 성공률 기록으로 간주하지 않습니다.
개요
비디오 작업이 실패하면 먼저 작업과 원본 프롬프트를 기록하고, 입력 버전을 확인한 뒤 관련 스토리보드나 참조를 수정할지 결정하고 개별적으로 재시도합니다. 먼저 두 가지 상황을 구분해야 합니다: 작업이 사용 가능한 비디오를 반환하지 않은 경우와, 이미 비디오를 반환했지만 내용이 맞지 않는 경우입니다. 전자는 실제 오류와 상태를 확인하고, 후자는 화면과 입력이 일치하는지 봅니다. 이 글은 DramaFork에서 정리했으며, 아래에서는 가상의 장면으로 점검 방법을 시연하고, 구성된 현상을 플랫폼의 실제 오류나 성공률 기록으로 간주하지 않습니다.
첫 번째 단계: 실패 대상을 한 줄로 기록하기
재시도 전에 실패한 것이 어떤 소재 작업인지 명확히 쓰고, "비디오가 실패했다"라고만 쓰지 않습니다. 네 가지를 기록하는 것이 좋습니다: 작업 이름, 그것이 의존하는 스토리보드나 캐릭터, 이번에 사용한 입력 버전, 인터페이스에서 제시된 오류 메시지 원문. 오류 메시지는 원문 그대로 옮겨 적고, 자신의 이해로 바꿔 쓰지 않아야 합니다. 바꿔 쓰면 그것이 가리키는 단계를 잃게 되기 때문입니다.
가상 프로젝트 《안개 항구 야화》의 "부두 회망_03"은 스토리보드 v4와 캐릭터 참조 v2를 사용합니다. 기록할 때는 실제 인터페이스 메시지를 옮겨 적어야 하며, 여기서 플랫폼 오류 코드를 만들지 않습니다. 작업이 완료되었지만 화면이 잘못된 경우에는 "클립이 반환되었으나, 뒤돌아보는 동작이 예상과 다름"이라고 쓰고, 기대 동작을 별도로 나열합니다. 이렇게 하면 내용 품질 문제를 서비스가 요청을 거부한 것으로 잘못 기록하지 않습니다.
두 번째 단계: 오류 메시지에 따라 세 가지로 분류하기
메시지마다 가리키는 단계가 다르므로, 먼저 분류한 뒤 움직이면 잘못된 곳을 고치는 것을 피할 수 있습니다.
| 점검 단서 | 확인할 가능한 원인 | 먼저 확인할 곳 |
|---|---|---|
| 클립 내용이 맞지 않거나, 실제 메시지가 입력과 관련됨 | 동작 텍스트가 모호하거나 자기모순됨 | 스토리보드 설명과 이번 작업 입력 |
| 인물 정체성, 의상이 예상과 다름 | 참조가 적용되지 않는 버전을 사용함 | 해당 캐릭터 또는 스타일 참조 |
| 결과가 반환되지 않았고, 실제 메시지가 시간 초과나 서비스와 관련됨 | 서비스와 작업 상태 문제 | 원본 프롬프트, 현재 작업이 아직 실행 중인지 |
분류는 범위를 좁힐 뿐이며, 메시지가 반드시 정확하다는 뜻은 아닙니다. 프롬프트 제약이 매번 올바른 출력을 보장하지 않으므로, 분류 후에도 한 번 수동으로 확인해야 합니다.
세 번째 단계: 구성 사례의 충돌 점검
"부두 회망_03"으로 돌아갑니다. 이미 클립이 반환되었고 동작이 맞지 않는다고 가정할 때, 작성자는 스토리보드의 같은 문장이 인물이 바다를 마주하고 동시에 카메라를 정면으로 바라보라고 요구한다는 것을 발견했습니다. 이것은 입력 자체의 모순이므로, 먼저 텍스트를 고칠 수 있습니다. 정면 캐릭터 참조가 배면 장면과 자동으로 충돌하는 것은 아니므로, 참조 방향만으로 결론을 내릴 수 없습니다.
| 점검 항목 | 현재 내용 | 충돌 여부 |
|---|---|---|
| 스토리보드 동작 | 동시에 바다를 마주하고, 카메라를 정면으로 바라봄 | 카메라 위치가 정의되지 않아 동작 요구가 모호함 |
| 캐릭터 참조 이미지 | 심옌_기본v2, 정면 서 있음 | 먼저 정체성과 의상을 확인하고, 방향만으로 오류를 판단할 수 없음 |
| 스타일 참조 | 차가운 색 야경 | 동작과 무관하므로 일단 건드리지 않음 |
| 입력 버전 | 스토리보드v4 + 심옌_기본v2 | 기록 일치 |
이 예에서는 먼저 동작을 "인물이 바다를 향해 서 있다가, 다시 뒤돌아 해안의 오는 사람을 본다"로 바꾸어 카메라의 상대 위치와 종료 방향을 명확히 합니다. 캐릭터 참조는 유지하고, 모든 입력을 한 번에 바꾸지 않습니다. 실제 실패 메시지가 동작과 무관하다면, 이 표로 원인을 증명할 수 없으며, 메시지가 가리키는 단계를 계속 확인해야 합니다. 점검 기록에 저장되는 것은 현상, 가설, 이번 변경이며, 가설을 검증된 원인으로 쓰지 않습니다.
네 번째 단계: 관련 입력만 수정하고, 해당 소재를 재시도하기
충돌을 확인한 후에는 변경이 관련 입력에 적용되어야 합니다. 이 예에서는 스토리보드 동작을 고쳐 "카메라를 등지고 뒤돌아봄"을 더 명확히 쓸 수 있고, 방향이 맞는 캐릭터 참조 이미지로 바꿀 수도 있습니다. 수정 후 새 버전을 기록합니다. 예를 들어 "스토리보드v5 + 심옌_기본v2"라고 쓰고, "부두 회망_03"이라는 작업 하나만 재시도합니다.
여기에는 워크플로의 실제 다운스트림 관계가 관련됩니다: 스토리보드를 바꾸면 노드, 비디오, 미리보기, 내보내기에 영향을 줍니다. 캐릭터를 바꾸면 비디오, 미리보기, 내보내기에 영향을 줍니다. 따라서 스토리보드를 수정한 후에는 관련된 완료 단계만 업데이트 필요로 표시하고, 이전 데이터는 보존합니다. 의미적으로 정확한 자동 차분도, 원클릭 확인 재사용도 없으므로, 창작자는 이번 수정이 이전 소재의 표현을 바꾸었는지 수동으로 확인해야 합니다. 스토리보드 하나를 바꿨다고 해서 프로젝트 전체의 비디오를 모두 다시 실행하지 않습니다.
다섯 번째 단계: 어떤 경우에 반복 재시도를 중단할지
재시도는 무한 루프가 아닙니다. 아래 중 하나라도 나타나면 멈추고, 계속 재시도 버튼을 누르기보다 먼저 입력 계층으로 돌아가 점검하는 것이 좋습니다:
- 같은 오류 메시지가 두 번 이상 연속 나타나고, 입력 버전이 변하지 않았을 때.
- 점검표의 모든 항목이 "충돌 없음"으로 표시되었지만, 메시지가 여전히 소재 충돌을 가리킬 때.
- 프롬프트나 소재를 고치는 대신, 실패를 설명하기 위해 캐릭터 동기를 지어내기 시작할 때.
- 작업 상태가 비정상으로 표시되지만, 상태를 먼저 확인하지 않고 반복 재시도할 때.
반복 재시도를 중단하는 것은 포기가 아니라, 행동을 "한 번 더 누르기"에서 "입력을 한 번 더 확인하기"로 바꾸는 것입니다. 이 단계에서 절약할 수 있는 것은 프로젝트 전체를 반복 재실행하면서 생기는 혼란입니다.
완료 점검
한轮 끝낸 후, 다음 항목으로 실제로 해결되었는지 확인합니다:
- 실패 대상이 한 줄로 기록되었고, 작업 이름, 의존성, 입력 버전, 오류 원문을 포함합니다.
- 오류가 프롬프트, 소재, 작업 상태 세 가지 중 하나로 분류되었습니다.
- 충돌 점검표를 항목별로 작성했고, 설정을 지어내 설명하지 않았습니다.
- 관련 입력만 수정했고, 새 버전 번호를 기록했습니다.
- 해당 소재 작업만 재시도했고, 프로젝트 전체를 무조건 재실행하지 않았습니다.
- 관련 다운스트림 단계를 업데이트 필요로 표시했고, 이전 데이터는 여전히 보존합니다.
이 여섯 가지를 모두 충족하면, 이번 재시도는 근거가 있는 것입니다. 다음에 비디오 실패를 다시 만나면, 먼저 그 한 줄 기록을 쓰고, 어디를 고칠지 결정하세요.
