Higgsfield 시간 초과 이미지 복구기
Higgsfield에서 시간 초과가 떴지만 서버에는 유료 이미지가 완성돼 있었습니다. 추가 크레딧 없이 결과물을 찾아 복구한 과정을 설명합니다.
Timeout after 6m0s; last status "in_progress"라는 메시지가 화면에 떴습니다.
실행기는 이 이미지를 실패로 집계했습니다. 다운로드된 파일은 없었습니다. 제 쪽에서 보면 작업이 멈춘 상태였습니다.
이 조합은 위험합니다. 다시 생성하는 것이 당연한 다음 단계처럼 느껴지기 때문입니다. 명령은 실패했고, 디스크에는 이미지가 없고, 대기열에서 이미 6분이 지났습니다. Higgsfield가 작업을 끝내지 못했다고 생각하기 쉽습니다.
그렇게 판단했다면 크레딧을 한 번 더 썼을 겁니다.
작업은 사라지지 않았습니다. Higgsfield는 서버에서 계속 처리하고 있었습니다. 나중에 작업이 끝났고, 완성된 이미지는 서버에 있었으며, 최초 크레딧도 이미 차감된 상태였습니다.
실패한 것은 결과를 기다리던 클라이언트였습니다. 생성 자체가 아니었습니다.
하나의 단어에 서로 다른 상태가 가려져 있었습니다
제 실행기는 결과를 FAIL로 표시했습니다.
기술적으로는 유용한 표시였지만 범위가 너무 넓었습니다. 명령이 로컬에서 예정된 절차를 끝내지 못했다는 사실만 알려줄 뿐, 이유는 알려주지 않았습니다.
이 명령은 Higgsfield의 처리를 기다리고, 완성된 결과를 받아 이미지를 다운로드해야 했습니다. 원격 상태가 여전히 in_progress인 동안 6분의 대기 제한이 끝났습니다. 다운로드 단계에 도달하지 못했으므로 실행기는 실패로 기록했습니다.
하지만 시간 초과가 서버 작업을 취소한 것은 아닙니다. Higgsfield는 계속 작업했습니다.
그러면 로컬과 원격의 상태가 어긋납니다. 제 폴더에는 이미지가 없지만, 서버에서는 결국 작업이 완료됐습니다. 과금 기록은 제 폴더의 빈자리가 아니라 서버 상태를 따릅니다.
로컬의 모든 실패를 생성 실패로 취급하면 이미 끝난 작업에 다시 돈을 내게 됩니다.
다시 생성하기 전에 서버부터 확인했습니다
복구는 한 가지 원칙에서 시작했습니다. 아직 아무것도 다시 실행하지 않는 것입니다.
최근 생성 작업 20개를 조회했습니다:
generate list --size 20
시간이 초과된 작업이 그 최근 기록 안에 있었습니다. 로컬 실행기 입장에서는 추적이 끊긴 작업이었습니다. 작업을 만든 명령은 기다리기를 멈췄지만, 원격 작업은 완료까지 지켜보는 로컬 프로세스 없이 계속 진행됐습니다.
최근 목록에서 완료된 작업을 찾았다고 해서 어떤 다운로드 파일이 누락된 결과물인지 바로 알 수는 없었습니다. 서버 결과를 디스크에 이미 있는 이미지와 비교해야 했습니다.
그래서 최근 작업에서 다운로드할 수 있는 각 URL의 파일을 받아 MD5 해시를 계산했습니다. 그런 다음 프로젝트 폴더에 이미 있는 이미지의 해시와 비교했습니다.
일치하는 것은 이미 가지고 있는 이미지였습니다.
로컬 이미지 어느 것과도 일치하지 않는 파일이 누락된 생성 결과였습니다.
복구 과정은 그게 전부였습니다. 프롬프트를 다시 쓰지도, 생성을 다시 실행하지도, 크레딧을 추가로 쓰지도 않았습니다. 디스크에 이미 있는 결과를 하나씩 제외해 원격에서 완성된 결과물을 찾아냈습니다.
복구에 든 비용은 0크레딧이었습니다.
상태에 따라 해결 방법이 달라집니다
시간 초과와 콘텐츠 검수 거부가 같은 실패 건수에 포함될 수 있지만, 대응은 달라야 합니다.
마지막 상태가 여전히 in_progress인 시간 초과는 클라이언트가 기다리기를 멈췄다는 뜻입니다. 서버가 생성을 멈췄다는 증거는 아닙니다. 다음 단계는 최근 작업을 확인하고 이미 다운로드한 파일과 대조하는 것입니다.
status: nsfw로 표시되는 콘텐츠 검수 거부는 다릅니다. 이 작업은 프롬프트를 바꿔 다시 시도해야 합니다. 최근 작업 목록에서 복구할 완성 이미지가 기다리고 있는 것이 아닙니다.
두 결과를 구분 없이 하나의 FAIL로 묶으면 잘못된 대응을 유도합니다. 복구할 수 있는 다운로드 문제를 두 번째 유료 생성으로 바꾸게 됩니다.
필요한 질문은 “명령이 실패했는가?”가 아니라 “원격 작업은 어떤 상태까지 진행됐는가?”입니다.
둘은 같은 질문이 아닙니다.
파일 이름만 확인해서는 부족했던 이유
복구의 핵심은 내용 비교였습니다.
최근 작업 목록에는 여러 결과가 있었고, 로컬 폴더에도 여러 이미지가 있었습니다. 목록만 보면 작업이 완료됐다는 사실은 알 수 있었지만, 추적이 끊긴 결과물을 확실히 특정할 수는 없었습니다.
MD5 비교로 기계적으로 답을 얻었습니다. 해시가 로컬 파일과 일치하는 서버 이미지는 모두 이미 확보된 결과였습니다. 일치하지 않는 해시가 완료됐지만 시간 초과된 명령에서 다운로드되지 않은 이미지를 가리켰습니다.
여러 생성 작업을 짧은 간격으로 실행할 때 특히 중요합니다. 유용한 증거는 실행기의 최종 표시가 아닙니다. 최근 서버 결과와 디스크의 실제 파일 사이의 관계입니다.
서버 기록은 Higgsfield가 무엇을 완성했는지 보여줍니다. 해시는 제가 무엇을 이미 가지고 있는지 보여줍니다. 두 집합의 차이가 복구해야 할 대상입니다.
지금 제가 적용하는 원칙
생성 실패였다는 사실을 확인하기 전까지 시간 초과는 대기 실패로 봅니다.
Timeout after ...; last status "in_progress"가 보이면 재실행하기 전에 멈춥니다. 최근 작업을 확인하고, 결과 URL에서 파일을 다운로드하고, 디스크에 있는 이미지와 MD5 해시를 비교해 일치하지 않는 파일을 복구합니다.
status: nsfw처럼 거부가 확인된 경우에만 프롬프트로 돌아갑니다.
오늘 여러분의 실행기나 기록에서 시간 초과와 콘텐츠 검수 거부가 같은 FAIL 처리 경로를 공유하는 곳을 찾아보세요. 다음 시간 초과 이미지에 두 번 돈을 내기 전에 둘을 분리해 두세요.
이 글의 해결책은 모두 제가 먼저 실수의 대가를 치르고 얻은 것입니다. 여러분의 브랜드보다 제 영화에서 겪는 편이 낫습니다.
