# 임시 다운로드 링크가 만료되기 전에 AI 생성 영상을 저장하는 방법은? > 공급자 URL을 자산 위치가 아니라 단기 전송 자격 증명으로 취급하세요. 작업 완료 즉시 다운로드를 큐에 넣고 영구 객체 스토리지로 스트리밍하며 크기, 형식, 체크섬을 검증한 뒤 제작 작업을 완료하기 전에 영구 URI를 기록합니다. # 임시 다운로드 링크가 만료되기 전에 AI 생성 영상을 저장하는 방법은? 생성이 완료되었다고 영구 자산이 되는 것은 아닙니다. 바이트가 직접 관리하는 스토리지에 있어야 합니다. 많은 영상 API의 서명 또는 임시 URL은 전송용이지 장기 재생용이 아닙니다. URL만 저장하면 승인된 영상이 몇 시간이나 며칠 뒤 애플리케이션에서 사라질 수 있습니다. 생성 완료 시 시작하는 별도 수집 단계를 만드세요. 다운로드 작업을 가져오고 현재 URL을 얻어 임시 객체로 스트리밍하며 검증한 뒤 결정적인 영구 키로 승격합니다. 그때만 제작 작업을 완료로 표시합니다. ## URL을 자격 증명으로 취급하세요 서명 URL은 추가 인증 header 없이 임시 접근을 허용할 수 있으므로 민감합니다. 접근이 엄격히 통제되지 않는 분석, 고객 로그, 티켓, 영구 DB 필드에 노출하지 마세요. 대신 다음을 저장하세요. * 공급자 작업 ID * 가능한 경우 공급자 출력 ID * URL 발급 시각과 관측된 만료 시각 * 다운로드 시도 기록 * 최종 객체 키 * 검증 메타데이터와 체크섬 명시적인 만료가 있으면 충분한 여유를 두고 첫 다운로드를 예약하세요. 수명이 공개되지 않았으면 일시적이라고 보고 즉시 큐에 넣습니다. ## 생성과 자산 수집을 분리하세요 원격 생성 완료와 영구 저장은 서로 다른 상태입니다. | 상태 | 의미 | 다음 단계 | |---|---|---| | `generating` | 공급자가 영상 생성 중 | 조회 또는 webhook 대기 | | `output_ready` | 출력 완료 | 다운로드 큐에 넣기 | | `downloading` | worker가 전송 소유 | 임시 저장소로 스트리밍 | | `verifying` | 바이트 도착 | 검사 및 체크섬 | | `stored` | 영구 객체 확인 | 영구 URI 저장 | | `complete` | 자산과 메타데이터 확정 | 납품 | | `download_retry` | 일시적 전송 오류 | URL 갱신 후 재시도 | | `needs_attention` | 자동 복구 불가 | 증거와 함께 에스컬레이션 | `output_ready`에서 완료로 표시하지 마세요. 이 지름길 때문에 DB가 만료 링크를 가리키게 됩니다. ## 다운로드 전에 webhook에 응답하세요 webhook 핸들러는 이벤트를 검증하고 저장하며 출력을 큐에 넣은 뒤 빠르게 응답해야 합니다. webhook 안에서 큰 영상을 받으면 타임아웃과 반복 전달이 생길 수 있습니다. 이벤트 ID 또는 공급자 작업 ID와 출력 ID 조합으로 중복 제거하세요. ```text download_key = provider + provider_job_id + output_id ``` 반복 webhook은 하나의 작업으로 수렴합니다. 조회와 webhook 모두 같은 `ensure_download_task`를 호출할 수 있습니다. ## 임시 객체로 스트리밍하세요 응답 전체를 메모리에 읽지 마세요. 암호학적 체크섬을 계산하면서 청크를 임시 파일이나 멀티파트 업로드로 전송합니다. 1. 만료 lease로 다운로드 작업을 가져옵니다. 2. API가 지원하면 새 URL을 얻습니다. 3. 연결 및 읽기 타임아웃을 제한합니다. 4. 예상하지 않은 호스트로의 리디렉션을 거부합니다. 5. 바이트 수와 SHA-256을 계산하며 스트리밍합니다. 6. 임시 객체를 종료합니다. 7. 미디어를 검증합니다. 8. 최종 키로 승격하거나 복사합니다. 9. 영구 URI와 메타데이터를 확정합니다. 백프레셔를 사용하고, 동시 전송 수는 작업 수뿐 아니라 대역폭, 파일 크기, 저장소 용량으로 제한하세요. ## header만이 아니라 실제 바이트를 검증하세요 HTTP `200`도 HTML 오류, JSON 메시지, 잘린 파일일 수 있습니다. `Content-Type: video/mp4`는 유용하지만 증명은 아닙니다. | 검증 | 발견하는 실패 | |---|---| | 0보다 큰 바이트 수 | 빈 응답 | | 예상 또는 타당한 길이 | 잘린 전송 | | 파일 시그니처 | HTML 또는 JSON 오저장 | | 컨테이너 분석 | 손상된 구조 | | 0보다 긴 재생 시간 | 불완전 영상 | | 해상도와 코덱 | 납품 계약 위반 | | SHA-256 | 변경 또는 중복 바이트 | | 필요한 경우 디코드 샘플 | 분석되지만 재생 불가 | 관측 메타데이터를 객체와 함께 저장하세요. 모델과 컨테이너에 맞는 허용 범위로 요청 길이와 해상도와 비교합니다. 정확한 시간이 계약 요구가 아니라면 몇 프레임 차이로 유효 영상을 거부하지 마세요. ## 결정적인 영구 키를 사용하세요 예측 가능한 키는 재시도를 멱등하게 하고 자산을 추적 가능하게 합니다. ```text videos/{account}/{operation_id}/{attempt_id}/{output_id}-{sha256_prefix}.mp4 ``` 먼저 임시 네임스페이스에 쓰세요. 검증 후 객체를 승격하거나 검증된 키에 대한 DB 포인터를 확정합니다. 다른 worker가 같은 체크섬을 저장했다면 재사용하세요. 정리하지 않은 사용자 파일명을 경로에 넣지 마세요. 원래 표시 이름은 메타데이터로 저장합니다. ## 만료와 중단에서 복구하세요 오류를 분류해 재시도의 목적을 분명히 합니다. * 연결 재설정과 일시 저장 오류는 보통 백오프 후 재시도 가능 * 인증 또는 만료 응답은 새 URL 필요 * Not Found는 공급자 삭제 가능성 * 체크섬 또는 검증 반복 실패는 자동 재시도 중단 * 로컬 용량 또는 권한 오류는 운영 대응 필요 원격 작업 ID를 유지하세요. 많은 API가 완료 작업에 새 서명 URL을 발급할 수 있지만 현재 엔드포인트에서 확인해야 합니다. 부분 재개는 원본과 대상이 검증된 Range를 지원하고 객체 식별자가 변하지 않았을 때만 수행합니다. 그 외에는 새 임시 객체로 처음부터 받습니다. ## 만료를 고려한 재시도 일정을 사용하세요 일반 지수 백오프는 URL의 남은 수명을 넘을 수 있습니다. ```text next_delay = min(exponential_backoff, time_until_expiry - safety_margin) ``` 만료가 가까우면 재시도 전에 갱신하세요. 지터로 동시 재연결을 막고, 전송 시도와 URL 갱신 시도에 별도 한도를 둡니다. ## 저장 경로를 보호하세요 기본적으로 비공개 bucket을 사용하고 필요한 경우 서버 측 암호화, 최소 권한 worker 자격 증명, 시청자용 단기 URL을 사용하세요. 서명이 포함될 수 있으므로 원본 URL 쿼리를 메타데이터에 복사하지 마세요. 로그에서는 제거하거나 호스트, 경로 해시, 발급과 만료 시각만 저장합니다. 필요하면 멀웨어 검사나 콘텐츠 검토를 적용하세요. 객체 키와 권한에서 테넌트 경계를 유지하되 경로명만 신뢰하지 마세요. ## 보존과 파생 자산 정책을 만드세요 영구적이라는 말이 영원히 보존한다는 뜻은 아닙니다. | 자산 유형 | 정책 고려 사항 | |---|---| | 승인 마스터 | 고객 계약과 재생성 비용 | | 납품 파생물 | 마스터에서 재생성 가능 | | 거부된 생성 | 짧은 감사 또는 이의 기간 | | 임시 업로드 | 검증 후 자동 삭제 | | 검토 프록시 | 승인까지 보존 | 삭제 상태와 이유를 기록하세요. 재현성이 필요하면 프롬프트, 원본 해시, 모델, 파라미터, 권리를 보존하되 비결정적 생성이 같은 바이트를 만들지는 않을 수 있습니다. ## 영구 저장까지 걸리는 시간을 모니터링하세요 공급자 완료부터 검증된 저장까지의 간격을 측정하세요. 임시 링크가 유일한 사본인 위험 구간입니다. 다음을 모니터링하세요. * 다운로드 대기 출력 * 가장 오래된 output-ready 경과 시간 * 완료에서 저장까지의 백분위수 * URL 만료 응답 * 전송 재시도와 URL 갱신 * 체크섬 또는 검증 실패 * 다운로드 및 저장 바이트 * 영구 URI 없이 완료된 작업 마지막 값은 항상 0이어야 합니다. 적체 시간이 관측된 최소 URL 수명에 가까워지기 전에 경고하세요. ## 모델 접근과 저장 책임을 명확히 하세요 [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=save-ai-videos-before-download-links-expire)는 텍스트, 이미지, 영상 모델에 접근하는 OpenAI 호환 플랫폼을 제공할 수 있습니다. 통합 플랫폼은 메타데이터와 청구를 단순화하지만 요구에 맞는 저장소로 출력을 복사하는 책임은 애플리케이션에 있습니다. 정확한 모델 엔드포인트의 출력과 URL 갱신 동작을 확인하세요. 만료 시간을 만들어 내거나 모든 모델이 같은 방식이라고 가정하지 말고 설정과 기능 검사로 차이를 처리합니다. ## 결론 임시 URL을 만료되는 전송 자격 증명으로 취급하세요. 생성 완료 즉시 다운로드를 큐에 넣고 임시 객체로 스트리밍하며 실제 미디어를 검증한 뒤 영구 키로 승격합니다. 영구 URI와 체크섬을 기록한 뒤에만 작업을 완료하고, 링크가 만료되어도 유일한 사본을 잃지 않도록 갱신, 재시도, 보존, 모니터링을 설계하세요. ## FAQ ### 공급자의 다운로드 URL을 최종 영상 위치로 저장해도 되나요? 안 됩니다. 서명된 URL이나 임시 URL은 만료, 취소 또는 변경될 수 있습니다. 영구 객체 키와 공급자 작업 ID를 저장하고 필요할 때만 새 전송 URL을 사용하세요. ### 다운로드 worker가 영상 전체를 메모리에 로드해야 하나요? 보통은 아닙니다. 큰 파일이 메모리를 고갈시키지 않도록 체크섬을 계산하면서 임시 파일이나 멀티파트 업로드로 스트리밍하세요. ### 영상을 저장 완료로 표시하기 전에 무엇을 검증해야 하나요? HTTP 응답, 가능한 경우 콘텐츠 길이, 파일 시그니처, 예상 컨테이너, 0보다 큰 재생 시간, 해상도 또는 코덱 요구, 체크섬, 영구 저장 성공을 확인하세요. ### 다운로드 중 임시 URL이 만료되면 어떻게 하나요? 제작 작업과 원격 작업 ID를 유지하고 불완전 객체를 삭제하거나 격리하세요. API가 지원하면 새 URL을 요청하고 검증된 Range 지원 여부에 따라 재개하거나 처음부터 다시 받습니다. ### 원본 생성 영상은 얼마나 오래 보관해야 하나요? 고객 요구, 법률과 개인정보 요구, 재생성 비용, 저장 예산에 따라 정하세요. 공급자 URL에 우연히 의존하지 말고 수명 주기 정책을 사용합니다. ### webhook에서 영상을 직접 다운로드해도 되나요? webhook 핸들러는 빠르게 응답하고 다운로드를 큐에 넣어야 합니다. 별도 worker가 안전한 재시도와 검증을 수행하면 긴 전송 때문에 이벤트를 잃지 않습니다.