새로 가져온 Immich 사진은 왜 검색 가능해지는 데 시간이 오래 걸리나요?

새 사진은 일반적으로 백그라운드 처리가 따라잡은 후 검색할 수 있게 되지만, 작업이 멈추거나 검색 필터가 적용되면 비슷한 검색 결과 누락 증상이 나타날 수 있습니다.

휴대폰에서 가족 서버로 휴가 앨범 업로드를 완료했지만, 해변을 검색하면 오래된 사진만 표시됩니다. 누락된 결과는 분석을 기다리는 중일 수도 있고, 이전 처리 단계에서 실패했을 수도 있으며, 현재 쿼리에서 제외되었을 수도 있습니다. 아무 결과도 반환하지 않은 검색 하나만으로 전체 가져오기를 판단하기보다 이러한 상태를 구분하는 것이 중요합니다.

업로드된 사진도 아직 검색을 기다릴 수 있습니다

업로드가 승인된 상태, 타임라인 타일이 표시되는 상태, 의미 검색 레코드가 완료된 상태는 서로 다른 단계입니다. 백그라운드 작업을 사용하면 서버가 모든 분석 단계를 동기적으로 완료하지 않고도 요청을 처리할 수 있습니다. 이러한 분리는 유연성을 높이지만, 업로드 카운터만으로는 새 이미지가 언제 자연어 쿼리에 모두 대응하게 될지 가족 구성원이 알 수 없다는 의미이기도 합니다.

별도의 작업 대기열을 사용하면 이러한 차이를 확인할 수 있습니다. Immich 대기열 시각화 도구를 만든 개발자는 처리율 그래프와 함께 대기 중, 활성, 완료된 작업을 보여 줍니다. 여기서 중요한 점은 추가 도구 자체가 아니라, 여러 처리 활동이 독립적으로 진행된다는 사실입니다. 따라서 전송이 잠잠한 시간이 곧 라이브러리 처리가 끝났다는 뜻은 아닙니다.

예시로 대기 중인 처리 대상 작업이 12,000개이고 분당 100개씩 일정하게 처리된다면, 새 작업 유입이 멈춘 뒤 약 120분이 걸립니다. 매분 80개가 추가로 유입되면 순감소량은 분당 20개에 불과합니다. 실제 작업마다 비용이 다르므로, 이 계산은 Immich 완료 시간을 예측하기보다 대기열이 쌓이고 줄어드는 방식을 설명합니다.

서로 다른 세 가지 상태가 같은 지연처럼 보일 수 있습니다

대기열이 의도적으로 대기 중인 상태, 대기열이 느리게 진행되는 상태, 필요한 출력이 생성되기 전에 작업이 반복적으로 실패하는 상태를 구분해야 합니다. 첫 번째는 실행 권한이 없는 상태이고, 두 번째는 유입 속도를 감당하기에 처리량이 부족한 상태이며, 세 번째는 특정 오류로 시간을 소모하는 상태입니다. 세 상태 모두에서 대기 중인 작업 수가 많을 수 있습니다.

메타데이터 시간 초과 보고 사례는 일반적인 하드웨어 한계를 입증하는 것이 아니라 세 번째 상태를 보여 줍니다. 제보자는 NFS 기반 라이브러리의 동영상에서 120초 후 실패가 발생했지만, 동일한 파일을 호스트에서 추출할 때는 빨랐다고 설명했습니다. 이러한 대비는 처리 경로의 불일치를 보여 줄 뿐, 모든 NAS 저장소나 모든 대규모 가져오기가 같은 방식으로 동작한다는 의미는 아닙니다.

대기 중인 작업이 줄어들고 실패 건수가 안정적으로 유지된다면, 대기열이 소진되는 동안 검색 범위가 지연되는 상황과 일치합니다. 대기 중인 작업이 줄어들지 않는다면 시스템이 과부하되었다고 판단하기 전에 작업이 일시 중지된 것인지 활성 오류가 발생한 것인지부터 구분해야 합니다. 이는 분류의 기준이지, 대기열을 지우거나 모든 서비스를 재시작하거나 가족 전체 사진을 다시 처리하라는 권고가 아닙니다.

검색 범위가 색인 미완료처럼 보일 수 있습니다

처리 상태를 확인한 뒤에는 계정, 앨범 범위, 날짜 필터, 쿼리를 고정하세요. 같은 서버라도 다른 가족 계정에서 검색하면 검색 가능한 결과가 달라질 수 있습니다. 또한 의미 검색 쿼리는 정확한 목록을 보장하기보다 유사도를 기준으로 순위를 매기므로, 시각적으로 일치하는 결과 하나가 누락되었다는 사실만으로 색인이 완료되지 않았다고 단정할 수 없습니다.

HEIC 미리보기 누락은 또 다른 혼동을 만듭니다. 원본은 존재하지만 표시용 파생 파일을 사용할 수 없을 수 있습니다. 형식, 디코더 동작, 특정 이미지 프로필이 이 경로에 영향을 줄 수 있습니다. 타일 누락과 검색 벡터 누락은 서로 다른 관찰 결과이며, 같은 사진에서 두 문제가 모두 발생하더라도 마찬가지입니다.

나머지 파일 그룹이 완료된 뒤에도 동일한 소수 파일만 계속 실패한다면 정상적인 대기열 지연이라는 설명은 더 이상 적용되지 않습니다. 반대로 알려진 자산을 직접 조회했을 때는 성공하지만 의미 검색 결과의 일치도가 낮다면 쿼리의 관련성이나 모델 동작을 의심할 수 있습니다. 검색어를 처음 사용했을 때 결과가 나오지 않았다는 이유만으로 원본을 다시 가져오지는 마세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

소규모 그룹으로 대기와 정체를 구분하세요

식별 가능한 날짜와 다양한 콘텐츠를 가진 새로 가져온 자산을 소규모로 선택하고, 이미 정상적으로 작동하는 것으로 확인된 오래된 자산 그룹도 준비하세요. 각 원본이 승인된 시점, 미리보기가 열린 시점, 관련 작업이 완료된 시점, 고정된 쿼리로 검색되는지를 기록하세요. 모델을 변경하거나 전체 라이브러리 재처리 작업을 시작하지 말고, 기록한 간격으로 반복해서 확인하세요.

가져오기 일정은 백그라운드 작업을 의도적으로 미룰 수 있습니다. immich-go 릴리스에는 업로드 중 동시 메타데이터 업데이트 충돌을 피하기 위해 작업 일시 중지 기능이 도입되었습니다. 이는 특정 대량 가져오기 정책의 증거일 뿐, 네이티브 모바일 앱도 같은 방식으로 작업을 일시 중지한다는 증거는 아닙니다. 실제로 해당 그룹을 생성한 가져오기 도구와 버전을 기록하세요.

완료 건수는 증가하고 오래된 결과는 안정적이라면 따라잡기 과정으로 해석하고, 동일한 파일에서 반복적으로 실패한다면 처리 문제로 해석하세요. 계정마다 결과가 다르면 범위 문제일 수 있습니다. 진행이 멈추면 이러한 관찰 결과와 버전 정보를 함께 제시해 문제를 보고하세요. 유용한 진단은 여러 변수를 한꺼번에 변경하거나 증거를 삭제하지 않고, 실패한 처리 단계를 좁혀 나갑니다.