대규모 모바일 가져오기 중 Immich 썸네일 및 ML 저장 공간이 증가하는 이유

대규모 가져오기는 일반적으로 각 자산이 파생 파일과 데이터베이스 레코드를 생성하기 때문에 Immich 저장 공간을 늘립니다. 반면 다운로드한 모델은 별도의 캐시에 저장됩니다.

한 가족이 수년 치 휴대폰 사진을 홈 NAS로 옮긴 뒤, 업로드 카운터가 완료된 후에도 여유 공간이 계속 줄어드는 것을 확인할 수 있습니다. 이는 모든 원본이 한 번 더 복제된 것이 아니라 정상적인 백그라운드 처리 때문일 수 있습니다. 중요한 구분은 자산별로 생성되는 파일, 공유 모델 파일, 그리고 완료된 작업량 증가와 관계없이 계속 진행되는 증가입니다.

업로드 하나가 여러 종류의 상태를 만듭니다

업로드된 원본은 결과 라이브러리의 한 부분일 뿐입니다. Immich는 탐색을 위한 더 작은 표현을 준비하고, 자산과 소유자, 날짜, 앨범, 검색 기능을 연결하는 정보도 저장합니다. 이러한 출력은 서로 다른 요청에 사용되므로 네트워크 전송이 끝났다고 해서 모든 후속 기록 작업까지 완료된 것은 아닙니다.

여기서 미디어 파일과 데이터베이스 레코드를 구분하는 것이 중요합니다. 애플리케이션 메타데이터와 검색 임베딩은 추가적인 고해상도 사진이 아니라 PostgreSQL에 저장됩니다. 머신러닝 서비스는 애플리케이션에서 사용하는 결과를 계산합니다. 따라서 추가된 모든 바이트를 원본의 중복으로 간주하면 일반적인 가져오기 증가를 잘못 설명하게 됩니다.

휴대폰의 전송이 끝났지만 서버가 수락된 배치를 계속 처리하는 상황을 생각해 보세요. 원본은 이미 디스크에 안정적으로 저장되었더라도 미리보기와 검색 가능한 레코드는 계속 생성될 수 있습니다. 저장 공간을 동일한 처리 단계에서 측정하세요. 방금 업로드된 집합과 완전히 처리된 집합은 서로 동등한 표본이 아닙니다.

원본 용량보다 자산 수가 더 많은 것을 설명합니다

썸네일을 계획할 때는 전체 원본 용량보다 자산의 수와 유형이 더 많은 것을 설명하는 경우가 많습니다. 작은 사진 1,000장과 긴 동영상 몇 개는 원본 용량이 비슷할 수 있지만 필요한 이미지 파생 파일의 수는 크게 다릅니다. 미리보기 크기, 압축 설정, 이미지 내용에 따라서도 생성되는 바이트 수가 달라집니다.

공개된 썸네일 측정 결과에서도 이러한 차이를 확인할 수 있습니다. 한 사용자는 70GB 라이브러리에 6.3GB가 필요하다고 보고했고, 다른 사용자는 사진과 동영상 2TB에 약 370GB가 필요하다고 보고했습니다. 이는 개인별 설정에 따른 결과이며, 서로 비교 가능한 통제된 벤치마크가 아닙니다. 포럼에서 본 단일 비율을 그대로 적용하면 다른 가정의 상황을 잘못 나타낼 수 있다는 뜻입니다.

예시로 계산하면, 평균 250KB의 이미지 파생 파일이 생성되는 자산 100,000개에는 십진 단위로 약 25GB가 필요합니다. 자산당 500KB라면 같은 수에 약 50GB가 필요합니다. 두 수치 모두 원본, 인코딩된 동영상, 데이터베이스 증가분, 백업은 포함하지 않습니다. 이 예시는 보편적인 할당량을 권장하는 것이 아니라 자산당 관계만 보여 줍니다.

모델 파일과 검색 레코드는 서로 다르게 증가합니다

모델 캐시에는 재사용 가능한 모델 파일이 저장되는 반면, 검색 벡터는 개별 자산을 나타냅니다. 다운로드한 모델 집합이 고정되어 있다면 사진을 더 추가한다고 해서 이미지마다 완전히 새로운 모델을 다운로드할 필요는 없습니다. 반대로 모델을 추가하거나 변경하면 업로드된 사진 수와 관계없이 캐시 저장 공간이 단계적으로 늘어날 수 있습니다.

한 휴대 가능한 배포 구성에서는 라이브러리, 모델 캐시, PostgreSQL 데이터를 서로 다른 영속 디렉터리에 저장합니다. 이렇게 분리하면 하나로 합쳐진 Docker 크기가 머신러닝 출력이라고 가정하지 않고 각 저장 공간의 역할을 확인할 수 있습니다. 이는 이전 릴리스의 구성 예시이며, 현재 설치 방법이나 권장 컨테이너 태그 모음이 아닙니다.

디스크 사용량과 메모리에 로드된 상태도 구분해야 합니다. 모델은 디스크에 남아 있으면서 메모리에서는 언로드될 수 있고, 파일시스템 캐시로 인해 영속 파일이 더 생성되지 않았는데도 보고되는 메모리 사용량이 늘어날 수 있습니다. 급증 원인을 설명하려면 컨테이너 이름만 보고 결론을 내리지 말고 먼저 어떤 디렉터리가 사용량을 차지하는지와 어떤 설정이 변경되었는지 확인하세요.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

정상적인 증가로 설명할 수 없는 시점

정상적인 파생 파일 증가는 고정된 입력을 전제로 합니다. 즉, 고정된 원본 집합을 고정된 설정으로 처리하는 경우입니다. 이 과정에서 새로운 원본 자산이 끝없이 생성되지는 않아야 합니다. 예정된 가져오기가 모두 끝난 뒤에도 자산 수가 계속 증가한다면 검색 경로, 반복 수집 또는 새로운 작업을 만드는 다른 원인을 포함해 설명해야 합니다.

확인된 재귀적 스캔 사례에서는 Immich 업로드 위치가 외부 라이브러리 안에 포함되어 있었습니다. 그러자 생성된 썸네일이 새 이미지로 처리되어 파생 파일의 파생 파일이 더 생성되었습니다. 이는 대규모 모바일 업로드와는 다른 인과 메커니즘이므로, 규모가 큰 모든 라이브러리가 자연스럽게 무한 증식한다는 근거로 사용해서는 안 됩니다.

컨테이너 쓰기 가능 계층에서 비정상적인 증가가 나타나는 경우도 별도의 범주입니다. 2026년 보고에서는 이 영역에 수백 기가바이트가 누적되었다고 설명했지만, 해당 논의에서 보편적인 근본 원인이 확정된 것은 아닙니다. 그래프를 정상적으로 보이게 만들기 위해 데이터베이스 파일, 미디어 또는 Docker 내부 파일을 삭제하지 마세요. 먼저 어느 역할의 저장 공간이 증가하는지, 그리고 완료된 작업으로 이를 설명할 수 있는지 확인해야 합니다.

저장 공간의 역할별로 가져오기를 측정하세요

대표적인 가져오기를 시작하기 전에 원본 자산 수와 바이트 수, 썸네일 및 미리보기 용량, 인코딩된 동영상 용량, 데이터베이스 크기, 모델 캐시 크기, 임시 파일 또는 로그 증가량을 기록하세요. 그런 다음 동일한 집합에 대해 활성화된 처리 작업이 완료된 후 다시 측정합니다. 동시에 설정을 변경하지 않도록 미디어 설정을 그대로 유지해야 증가분을 가져오기 때문이라고 판단할 수 있습니다.

저장 공간 계산이 가족 백업 계획을 대신할 수는 없습니다. 사용 가능한 사진 서비스에는 보호된 원본과 라이브러리를 복구하는 데 필요한 애플리케이션 상태가 필요합니다. 썸네일 디렉터리만으로는 가족 컬렉션을 보존할 수 없습니다. 재생성 가능한 오버헤드를 측정하는 작업과 보호 작업을 분리하여, 공간 절약 실험이 추억의 유일한 사본을 없애는 일이 없도록 하세요.

측정된 역할별 합계로 추가된 바이트를 설명할 수 있고 예상하지 못한 원본 자산이 더 이상 나타나지 않는다면 결과를 받아들여도 됩니다. 모델 목록은 변하지 않았는데 캐시 또는 쓰기 가능 계층의 증가가 계속되거나, 파생 파일이 다시 검색 대상에 들어간다면 다른 메커니즘을 조사해야 합니다. 이 테스트는 저장 공간이 증가한 이유를 파악하기 위한 것이며, 설명을 파괴적인 정리 절차로 바꾸지 않습니다.