# 제품 CSV를 복구 가능한 영상 제작 큐로 전환하는 방법은? > 각 제품 행을 안정적인 ID, 검증된 입력, 명시적 상태, 시도 기록, 영구 출력 위치를 가진 버전 관리 작업으로 변환하세요. 장애 후 worker가 작업을 잃거나 같은 영상을 두 번 생성하지 않고 안전하게 재개할 수 있어야 큐가 복구 가능합니다. # 제품 CSV를 복구 가능한 영상 제작 큐로 전환하는 방법은? 카탈로그 파일은 입력 데이터이지 제작 큐가 아닙니다. 스크립트가 17번째 행을 읽고 영상 API를 호출한 뒤 다음 열에 URL만 기록한다면, 노트북 장애나 타임아웃 후 무엇을 요청했는지, 공급자가 수락했는지, 완성 자산을 저장했는지 확실히 알 수 없습니다. 실용적인 해결책은 CSV를 변경 불가능한 가져오기로 보존하고, 영구 작업 레코드로 확장하며, worker의 각 단계를 안전하게 반복할 수 있게 하는 것입니다. 그러면 어느 단계에서 멈춰도 전체 배치를 처음부터 다시 시작하지 않고 마지막 확인 상태에서 재개할 수 있습니다. ## 카탈로그 데이터와 제작 작업을 분리하세요 제품 행은 상품을 설명하고, 영상 작업은 요청된 하나의 크리에이티브 출력을 설명합니다. 한 제품에서 여러 납품물이 나올 수 있으므로 서로 다른 레코드여야 합니다. 한 행에 제품 ID, 이름, 이미지 URL, 가격, 카테고리, 설명이 있고 제작 계획에 두 개의 훅, 세 개의 locale, 두 개의 화면 비율이 있다고 가정합니다. 이 행은 12개의 영상 작업으로 확장됩니다. 나중에 제품 설명을 수정해도 이미 실행 중인 요청이 조용히 바뀌면 안 됩니다. 세 계층을 저장하세요. * 파일 해시와 가져오기 시간을 포함한 원본 가져오기 * 이번 실행에 사용한 정규화 제품 스냅샷 * 템플릿, locale, 비율, 변형 조합별 작업 이 분리 덕분에 재실행이 의도적인 작업이 됩니다. 새 카탈로그는 새 가져오기 버전을 만들고, 전체 입력 지문이 같으면 변경되지 않은 작업을 재사용할 수 있습니다. ## 확장하기 전에 CSV를 검증하세요 API 호출 전 잘못된 입력을 거부하는 편이 수백 작업을 시작한 뒤 혼합 오류를 진단하는 것보다 저렴합니다. 인코딩, 필수 열, 제품 ID의 고유성, URL 문법, 템플릿 제한을 검증하세요. | 검사 | 실패 예시 | 큐 처리 | |---|---|---| | 안정적인 제품 ID | 비어 있거나 중복된 SKU | 가져오기 중단 | | 필수 원본 미디어 | 대표 이미지 없음 | 행을 잘못됨으로 표시 | | 텍스트 길이 | 설명이 템플릿 제한 초과 | 카피 검토로 이동 | | Locale 출처 | 지원하지 않는 코드 | 확장 결과를 잘못됨으로 표시 | | 숫자 데이터 | 가격에 해석 불가 텍스트 | 정규화 또는 거부 | | URL 접근성 | 이미지 오류 응답 | 검증 재시도 후 검토 | 행, 필드, 값, 이유를 포함한 검증 보고서를 만드세요. 문제를 숨기려고 원본 CSV를 수정하지 마세요. 수정 파일은 새 해시를 가져야 하며 거부된 가져오기와의 관계를 추적할 수 있어야 합니다. ## 각 작업에 결정적 식별자를 부여하세요 복구 가능한 큐에는 정렬, worker 재시작, 반복 가져오기 후에도 유지되는 식별자가 필요합니다. 데이터 삽입이나 재정렬로 바뀌는 CSV 행 번호는 적합하지 않습니다. 요청 출력을 정의하는 필드로 표준 입력 객체를 만드세요. ```json { "catalog": "spring-2027", "product_id": "SKU-1042", "template_version": "ugc-demo-v3", "locale": "en-US", "aspect_ratio": "9:16", "variant": "hook-b" } ``` 키 순서를 고정해 직렬화하고 해시를 계산합니다. 읽기 쉬운 필드와 해시를 함께 저장하고 작업 키에 고유 제약을 둡니다. 같은 확장이 두 번 실행되어도 새 작업이 아니라 기존 작업을 반환합니다. 출력에 영향을 주는 콘텐츠는 식별자에 포함해야 합니다. 프롬프트나 원본 이미지가 바뀌는데 템플릿 버전이 같다면 해당 해시를 포함하지 않을 경우 오래된 결과를 잘못 재사용할 수 있습니다. ## 큐를 명시적 상태로 모델링하세요 하나의 `done` 플래그는 작업이 어디서 멈췄는지 설명하지 못합니다. 복구 가능한 경계에 대응하는 상태를 사용하세요. | 상태 | 의미 | 안전한 다음 단계 | |---|---|---| | `ready` | 입력 검증 통과 | 작업 가져오기 | | `leased` | worker가 임시 소유 | 요청 구성 | | `submitting` | 요청 준비 완료 | 지원 시 멱등 키로 전송 | | `accepted` | 원격 작업 ID 수신 | 상태 조회 | | `downloading` | 출력 사용 가능 | 영구 저장소로 복사 | | `review` | 자산 검토 필요 | 검토 규칙 적용 | | `complete` | 자산과 메타데이터 기록 완료 | 납품 또는 내보내기 | | `retry_wait` | 일시적 장애 | 백오프 후 재개 | | `needs_attention` | 사람의 판단 필요 | 운영자에게 맥락 표시 | 수락이 확인되면 공급자 작업 ID를 즉시 영구 저장합니다. 제출 중 타임아웃은 모호하므로 아무 일도 없었다고 가정하지 말고 조정 가능한 상태에 둡니다. ## 영구 잠금 대신 lease를 사용하세요 worker는 제한된 기간 동안 작업을 가져와야 합니다. `ready`를 `leased`로 바꾸는 원자적 업데이트에서 소유자와 만료 시간을 함께 저장합니다. 다른 worker는 만료 후에만 가져옵니다. 활성 처리 중에는 lease를 연장합니다. 프로세스가 중단되면 lease가 만료되고 다른 worker가 시도를 조사합니다. 새 worker는 무조건 다시 제출하지 말고 저장된 원격 ID, 요청 키, 완료 출력을 먼저 확인합니다. lease는 일반 로컬 단계보다 길고 허용 가능한 장애 복구 대기보다 짧게 설정합니다. 오래 걸리는 원격 생성 동안 worker가 계속 보유할 필요는 없습니다. 원격 ID를 저장하고 worker를 해제한 뒤 나중에 조회를 예약합니다. ## 시도를 작업과 별도로 기록하세요 작업은 의도를, 시도는 한 번의 실행에서 발생한 일을 나타냅니다. 분리하면 메인 행이 최신 오류로 덮이지 않습니다. 각 시도에 기록할 항목은 다음과 같습니다. * 시도 번호와 타임스탬프 * worker 식별자와 소프트웨어 버전 * 정규화 요청 해시 * 공급자와 모델 경로 * 공급자 요청 또는 작업 ID * HTTP 상태와 오류 범주 * 조회 이력 또는 최종 상태 * 출력 체크섬, 크기, 길이, 저장 키 * 가능한 경우 입력 및 출력 사용량 로그에 비밀이나 제한되지 않은 고객 데이터를 저장하지 마세요. 타임아웃, 재시도, 청구를 나중에 조정할 수 있을 만큼의 마스킹된 증거만 보존합니다. ## 제출과 다운로드를 반복 가능하게 만드세요 멱등성은 여러 경계에 필요합니다. DB 고유 제약은 로컬 중복을 막고, 문서화된 공급자 멱등 키는 원격 중복을 막으며, 결정적 저장 키는 서로 무관한 복사본 생성을 막습니다. 공급자가 멱등성을 문서화하지 않으면 제출 타임아웃을 알 수 없음으로 취급합니다. 다시 보내기 전에 내부 시도 기록과 공급자의 작업 목록 또는 검색 기능을 확인하세요. 조정이 불가능하면 대기, 수동 검토, 잠재 중복 비용을 기록한 재제출 같은 명시적 정책을 사용합니다. 저장 시 임시 객체에 먼저 쓰고 체크섬과 미디어 속성을 검증한 뒤 최종 키로 승격합니다. 검증 성공 후에만 영구 URI를 기록합니다. 반복 다운로드는 같은 체크섬을 확인하거나 확실히 손상된 임시 객체만 교체해야 합니다. ## 관찰 가능한 체크포인트로 복구를 설계하세요 각 상태 경계에서 worker를 중단해 복구를 시험합니다. 제출 직전, 수락 직후, 조회 중, 다운로드 중, 자산 저장 후 DB 업데이트 전을 포함하세요. | 중단 지점 | 복구 증거 | 예상 동작 | |---|---|---| | API 호출 전 | 원격 ID 없음, 미전송 | 한 번 제출 | | 수락 후 | 원격 ID 저장됨 | 조회 재개 | | 제출 타임아웃 | 요청 지문, 결과 불확실 | 재시도 전 조정 | | 다운로드 중 | 임시 객체와 예상 메타데이터 | 재개 또는 다시 시작 | | 영구 쓰기 후 | 체크섬 존재, 상태 미완료 | 객체 확인 후 완료 처리 | 큐 대기 시간, 상태 체류 시간, 작업별 시도, 만료 lease, 알 수 없는 제출, 잘못된 행, 검토 적체를 모니터링하세요. 단일 성공률보다 운영 상태를 더 잘 보여 줍니다. ## 모델 계층을 교체 가능하게 유지하세요 큐는 코드 전체에 흩어진 공급자 응답이 아니라 정규화된 어댑터에 의존해야 합니다. 어댑터는 공통 요청을 각 모델 schema로 변환하고 수락, 상태, 사용량, 오류, 출력을 정규화합니다. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=product-csv-recoverable-video-production-queue)는 텍스트, 이미지, 영상 모델을 사용하면서 하나의 OpenAI 호환 플랫폼과 청구 관계를 원하는 제작에 유용할 수 있습니다. 그러나 작업 식별자, 시도 로그, 영구 저장소, 모델별 기능 검사는 계속 필요합니다. 각 시도에 공급자, 정확한 모델 ID, 어댑터 버전, 요청 파라미터를 저장하세요. 경로 변경 때문에 과거 출력을 설명할 수 없게 되어서는 안 됩니다. ## 결론 CSV를 버전 관리된 가져오기로 취급하고, 제품을 결정적 작업으로 확장하며, 명시적 상태와 시도를 영구 저장하세요. 만료 lease를 사용하고 모호한 제출을 조정하며 검증된 출력을 영구 저장소에 복사하세요. 어떤 worker든 장애 후 저장된 증거만으로 다음 안전한 단계를 판단할 수 있어야 합니다. ## FAQ ### CSV에서 만든 영상 작업의 고유 ID는 무엇을 사용해야 하나요? 카탈로그, 제품 식별자, 크리에이티브 템플릿 버전, locale, 출력 변형에서 결정적으로 생성한 ID를 사용하세요. 정렬하거나 행을 삽입하면 바뀌는 행 번호는 사용하지 마세요. ### CSV 한 행이 영상 작업 하나가 되어야 하나요? 항상 그렇지는 않습니다. 여러 locale, 화면 비율, 훅, 템플릿이 있으면 한 제품 행이 여러 작업으로 확장됩니다. 원본 행과 확장된 작업 기록을 분리하세요. ### 실패한 생성은 몇 번 재시도해야 하나요? 실패 유형별로 작고 제한된 재시도 정책을 정하세요. 일시적인 네트워크 및 공급자 오류는 백오프로 재시도하고, 잘못된 입력과 횟수를 소진한 작업은 검토 또는 데드레터 상태로 보냅니다. ### 생성된 영상은 어디에 저장해야 하나요? 성공한 출력을 예측 가능한 키로 영구 객체 스토리지에 복사하세요. 공급자의 임시 다운로드 URL을 최종 자산 위치로 취급하지 마세요. ### 프로세스 장애 후 큐를 어떻게 재개하나요? 모든 상태 전환을 영구 저장하고 만료 시간이 있는 lease를 사용하세요. 재시작 후 만료된 작업을 회수하고 최신 시도를 확인한 뒤 미완료 단계만 계속합니다. ### Atlas Cloud를 다중 모델 제작 큐에서 사용할 수 있나요? 예. 하나의 OpenAI 호환 플랫폼에서 텍스트, 이미지, 영상 모델을 사용하는 큐라면 Atlas Cloud가 통합 작업을 줄일 수 있습니다. 다만 공급자별 작업 상태와 출력은 큐에서 정규화해야 합니다.