# 기존 앱에서 Replicate 예측 폴링과 웹훅을 어떻게 대체하나요? > 제품과 모델 API 사이에 공급자 중립적인 비동기 작업 레코드를 둡니다. 검증된 웹훅이나 제한된 폴링 워커가 동일한 멱등 종료 처리기를 갱신하도록 하고 상태를 정규화하며 완료 파일을 영구 저장소로 복사합니다. 애플리케이션과 추론 API 사이에 공급자 중립 작업 계층을 두어 Replicate 폴링과 웹훅을 대체합니다. 생성, 상태, 취소, 완료 이벤트, 출력 보존을 정규화해 제품이 Replicate 예측 객체나 URL에 의존하지 않도록 합니다. 제품 코드에서 callback URL만 교체하지 말고 먼저 필요한 비동기 계약을 정의합니다. ## 현재 동작을 기록합니다 Replicate 비동기 생성은 예측 ID, 상태, 보조 URL을 반환합니다. 앱은 `urls.get`을 폴링하거나 웹훅 POST를 받거나 지원되는 서버 전송 이벤트를 사용할 수 있습니다. 각 흐름의 경로와 상태 변화 시 동작을 기록합니다. | Replicate 개념 | 애플리케이션 대체 항목 | |---|---| | 예측 ID | 공급자 작업 ID와 내부 작업 ID | | `starting`, `processing` | `queued`, `running` | | `succeeded` | `completed` | | `failed`, `canceled` | `failed`, `canceled` | | `urls.get` | 어댑터 상태 메서드 | | 웹훅 페이로드 | 정규화된 완료 이벤트 | | 출력 URL | 애플리케이션 소유 영구 자산 | 공급자 원시 상태를 정규화 상태와 별도로 저장해 수명 주기 차이를 디버깅할 수 있게 합니다. ## 내부 작업 레코드를 도입합니다 새 공급자를 호출하기 전에 데이터베이스 행을 생성합니다. ```json { "job_id": "job_01J...", "provider": "target", "provider_job_id": null, "state": "creating", "attempt": 1, "output_assets": [] } ``` UI, 큐, 알림에는 내부 `job_id`를 사용하고 생성 성공 후 외부 ID를 연결합니다. 멱등 키로 네트워크 재시도가 유료 작업을 두 번 시작하지 않게 합니다. ## 제한된 워커로 폴링을 대체합니다 대상에 작업 조회 API는 있지만 웹훅이 없다면 폴링을 백그라운드 워커로 옮깁니다. 지터가 있는 지수 백오프, 마감 시간, 최대 간격을 사용하고 취소를 포함한 모든 최종 상태에서 중지합니다. 브라우저에서 폴링하지 않습니다. 서버 워커는 탭이 닫혀도 실행되고 속도 제한을 중앙 관리하며 상태 변경을 트랜잭션으로 저장합니다. ## 검증된 이벤트로 웹훅을 대체합니다 대상에서 웹훅을 제공한다면 처리기를 작게 유지합니다. * 파싱 전에 서명이나 공유 비밀을 검증합니다. * 이벤트 ID 또는 작업과 상태로 중복 제거합니다. * 빠르게 응답하고 처리를 큐에 넣습니다. * 페이로드가 일부라면 권위 있는 작업을 조회합니다. * 순서가 바뀌거나 반복된 전달을 허용합니다. Replicate는 start, output, logs, completed 이벤트 필터를 지원합니다. 대상이 최종 이벤트만 보낸다면 희소한 상태로 정밀한 진행률을 만들지 않습니다. ## 단일 완료 경로를 사용합니다 폴링과 웹훅은 동일한 멱등 종료 처리기를 호출합니다. 내부 작업을 잠그고 외부 ID를 확인하며 최종 상태를 저장하고 파일을 영구 저장소로 복사한 뒤 애플리케이션 이벤트를 한 번만 발행합니다. 웹훅과 마지막 폴링이 동시에 도착해도 알림이 중복되지 않습니다. ## 파일이 사라지기 전에 보존합니다 Replicate는 API 예측의 입력 및 출력 파일이 제한된 기간 뒤 삭제된다고 설명합니다. 대상은 다른 보존 기간이나 서명 URL 유효 기간을 사용할 수 있습니다. 외부 URL을 영구 저장소가 아니라 전달 수단으로 취급합니다. 출력을 즉시 내려받고 유형과 크기를 검증하며 필요하면 검사한 뒤 자체 키로 저장하고 체크섬을 기록합니다. 클라이언트에는 자체 안정 URL을 제공합니다. ## 장애와 복구를 테스트합니다 지연된 생성 응답, 중복 또는 누락 웹훅, 429와 5xx, 취소 경쟁, 만료 URL, 잘못된 페이로드, 처리 중 워커 재시작을 테스트합니다. 안전한 입력으로 두 어댑터를 섀도 실행하고 최종 상태와 자산 수를 비교한 뒤 소량의 운영 트래픽을 이전합니다. ## 핵심 정리 지속 가능한 대체 방식은 제품 곳곳의 callback이 아니라 내부 비동기 작업 계약입니다. 상태를 정규화하고 완료 처리를 멱등으로 만들며 파일을 즉시 보존하고 검증된 웹훅이나 제한된 워커가 동일한 완료 경로를 구동하게 합니다. ## FAQ ### 브라우저에서 대체 API를 직접 폴링해야 하나요? 서버 측 워커를 권장합니다. 브라우저가 닫혀도 실행되고 속도 제한과 재시도를 중앙 관리하며 내부 상태를 일관되게 갱신할 수 있습니다. ### Replicate 예측 상태는 어떻게 매핑하나요? creating, queued, running, completed, failed, canceled 같은 작은 내부 수명 주기로 매핑하고 디버깅을 위해 원래 공급자 상태도 보관합니다. ### 웹훅 중복 처리는 어떻게 방지하나요? 진위를 확인하고 이벤트 ID 또는 작업과 상태로 중복 제거한 뒤 웹훅과 폴링을 동일한 트랜잭션형 멱등 종료 처리기로 전달합니다. ### 새 공급자에 웹훅이 없으면 어떻게 하나요? 지수 백오프, 지터, 마감 시간, 모든 최종 상태 처리를 갖춘 백그라운드 워커를 사용합니다. ### 공급자 출력 URL을 영구적으로 공개해도 되나요? 영구성을 가정하면 안 됩니다. 출력을 즉시 내려받고 자체 접근 제어가 적용된 애플리케이션 자산 URL을 제공해야 합니다. ### 어떤 장애를 테스트해야 하나요? 중복 또는 누락 이벤트, 속도 제한, 일시적 오류, 취소 경쟁, 만료된 출력, 잘못된 페이로드, 처리 중 워커 재시작을 포함합니다.