Immich는 보편적인 저장 공간 비율을 제시하지 않습니다. 오버헤드는 주로 자산 수, 동영상 구성, 파생 파일 설정, 데이터베이스 증가량, 보관 중인 백업에 따라 달라집니다.
사진이 대부분인 1테라바이트 가족 라이브러리는 긴 휴대폰 동영상이 대부분인 라이브러리와 같지 않습니다. 대표적인 파일을 먼저 가져온 뒤 생성된 각 항목의 크기를 측정해 저장 공간을 계획하고, 증가분과 임시 작업 공간, 복구용 사본을 위한 별도 여유 공간을 확보하세요.
파생 미디어는 일반적으로 눈에 보이는 오버헤드의 가장 큰 부분을 차지합니다
Immich는 타임라인과 뷰어에서 사용할 작은 이미지를 준비하며, 호환되는 재생을 위해 동영상의 인코딩 버전을 만들 수도 있습니다. 이러한 출력물의 크기는 자산 수, 해상도 선택, 품질 설정, 동영상 길이 또는 코덱 구성에 따라 달라집니다. 사용자가 직접 다운로드하지 않더라도 원본 파일에 추가로 저장됩니다.
772GiB 외부 라이브러리를 대상으로 한 커뮤니티 측정에서는 썸네일 약 18GiB와 인코딩된 동영상 65GiB가 보고되었습니다. 약 83GiB라는 관찰값은 실제 계산 예시로는 유용하지만 계획 비율로 사용해서는 안 됩니다. 다른 라이브러리에서는 사진과 동영상의 구성 및 설정에 따라 두 항목이 크게 달라질 수 있기 때문입니다.
가족이 실제로 보유한 사진, RAW 파일, 짧은 클립, 긴 동영상이 포함된 대표 샘플을 가져온 뒤 썸네일과 인코딩된 동영상 디렉터리의 크기를 기록하세요. 각 파생 파일 유형을 자산 수와 원본 바이트를 기준으로 각각 나누어 계산하세요. 자산 기준 비율과 바이트 기준 비율은 서로 다른 증가 전망을 보여줍니다.
데이터베이스와 검색 상태는 관계에 따라 증가합니다
데이터베이스 오버헤드는 자산 레코드, 사용자, 앨범, 메타데이터, 얼굴, 검색용 표현, 인덱스, 작업 상태에서 발생합니다. 작은 이미지와 대용량 동영상은 원본 크기가 크게 달라도 일부 레코드에서는 비슷한 수를 생성할 수 있습니다. 따라서 데이터베이스 증가는 원본 테라바이트보다 엔터티 수와 활성화된 기능의 영향을 더 크게 받습니다.
ZimaSpace의 Immich 백업 글은 필수 원본과 데이터베이스 상태를 다시 생성할 수 있는 파생 경로와 구분합니다. 용량을 예측할 때 이러한 구분은 중요합니다. 파생 파일을 삭제하면 일시적으로 공간을 확보할 수 있지만, 데이터베이스를 잃으면 썸네일만으로는 복구할 수 없는 관계 정보가 사라지기 때문입니다.
알려진 규모의 파일 묶음을 가져오기 전후에 데이터베이스 크기를 측정하고, 어떤 처리 기능이 완료되었는지 기록하세요. 얼굴 인식과 검색 처리가 끝난 뒤 다시 측정하세요. 아직 처리 대기열이 끝나지 않은 상태를 기준으로 extrapolate하지 마세요. 추가 표현과 관계가 기록되면서 자산당 오버헤드가 증가하기 때문입니다.
백업과 임시 작업은 필요한 최소 용량을 바꿉니다
현재 사용량의 합계에는 백업 생성, 데이터베이스 덤프, 가져오기 준비, 파생 파일 교체 중 필요한 공간이 포함되지 않습니다. 업그레이드나 재생성 중에는 기존 파일과 새 파일이 동시에 존재할 수 있습니다. 따라서 연간 미디어 증가량이 크지 않더라도 정상적인 유지 관리 중 디스크가 가득 찰 수 있습니다.
저장 공간 계획 글에서는 원본, 썸네일, 메타데이터, 머신러닝 작업으로 인해 Immich가 여유가 있던 SSD를 가득 채운 사례를 설명합니다. 이 사례가 주는 더 큰 교훈은 애플리케이션 증가분과 복구용 사본이 운영 여유 공간을 서로 차지한다는 점입니다. 따라서 여유 공간은 현재 유휴 상태가 아니라 유지 관리가 가장 많이 발생하는 조건을 감당할 수 있어야 합니다.
다른 장애를 대비하는 오프호스트 사본이므로 백업 보관분은 별도 항목으로 관리하세요. 또한 가장 큰 가져오기, 재인코딩 또는 업그레이드 테스트에서 관찰된 작업 여유 공간을 따로 확보하세요. 사용하지 않는 공간이 많다고 항상 더 좋은 것은 아니지만, 측정된 최대 여유 공간이 0이면 용량 부족은 예고된 문제입니다.
라이브러리에 맞는 오버헤드 워크시트를 작성하세요
원본, 썸네일 및 미리보기, 인코딩된 동영상, 데이터베이스, 머신러닝 파일, 로컬 백업 덤프, 임시 최대 사용 공간을 각각 행으로 만드세요. 빈 상태의 기준값을 측정한 다음 대표 파일 묶음을 가져오세요. 대기열이 모두 처리될 때까지 기다린 뒤 모든 항목을 다시 기록하고 차이를 계산하세요.
SSD와 HDD 배치에 관한 실무자 논의에서는 지연 시간에 민감한 생성 데이터를 대용량 원본과 구분합니다. 용량을 계획할 때 이러한 구분을 통해 원본이 다른 곳에 있더라도 고속 계층의 오버헤드를 확인할 수 있습니다. 그렇지 않으면 대형 NAS의 전체 용량에 가려 애플리케이션 SSD가 거의 가득 찬 상태를 놓칠 수 있습니다.
한 가지 비율이 아니라 범위를 얻을 수 있도록 같은 파일 묶음으로 한 번 더 측정하세요. 각 항목은 자산 수, 동영상 바이트 또는 재생 시간, 사용자 및 관계 증가, 보관 개수, 유지 관리 중 최대 작업량 등 적절한 기준으로 예측하세요. 파생 파일과 복구 요구 사항을 별도로 확인한 뒤에 계획된 원본 증가분을 더하세요.
기술 및 AI 허브
더 읽어보기

업그레이드 후 Immich가 기존 데이터를 다시 처리하는 이유는 무엇인가요?
업그레이드로 인해 이전 파생 파일, 메타데이터, 모델 또는 작업 상태가 무효화되면 Immich가 에셋을 다시 처리할 수 있습니다. 반복적으로 작업이 끝없이 실행되는 것은 별도의 문제입니다.

실제 Immich 성능의 한계를 가장 자주 결정하는 종속 요소는 무엇인가?
Immich는 측정된 각 경로에서 가장 느린 종속 요소에 의해 성능 상한이 결정되므로, 업로드·검색·탐색·재생의 성능 한계가 서로 다를 수 있습니다.

Immich 네트워킹: 검색, DNS, 라우팅이 연결 가능성을 만드는 방식
엔드포인트 선택, DNS, 라우팅, NAT 또는 프록시 처리, TLS, 애플리케이션 응답이 하나의 유효한 경로를 구성할 때만 Immich에 연결할 수 있습니다.

