PhotoPrism vs Immich, 어떤 사진 서버가 맞을까

PhotoPrism과 Immich: 간단한 답

PhotoPrism과 Immich의 차이는 같은 제품의 두 버전 중 하나를 선택하는 것이 아닙니다. 서로 다른 용도에 맞는 두 제품 중 하나를 선택하는 것입니다. Immich는 Google Photos를 대체합니다. 휴대폰 앱이 카메라 롤을 자동으로 백업하며, 제공되는 타임라인은 휴대폰 갤러리에서 벗어나려는 사용자에게 익숙하게 보입니다. PhotoPrism은 이미 보유한 사진 라이브러리를 정리합니다. 디스크의 파일이 있는 폴더를 인덱싱하고, 메타데이터를 읽고, 사진을 지도에 표시하며, 파일은 원래 위치에 그대로 둡니다.

문제가 "휴대폰 저장 공간이 가득 찼고 Google Photos를 더 이상 사용하고 싶다"라면 Immich를 선택합니다. 문제가 "드라이브에 사진이 400 GB 있고 그중 아무것도 찾을 수 없다"라면 PhotoPrism을 선택합니다. 두 제품 모두 오픈 소스이며, 일반적인 VPS에서 Docker 컨테이너로 실행할 수 있습니다. 또한 두 제품 모두 라이브러리를 인덱싱하고 검색하며, 어떤 제3자에게도 데이터를 전송하지 않습니다.

철학의 차이와 이것이 모든 것을 결정하는 이유

Immich가 파일을 관리합니다. 업로드 위치를 지정하면 휴대폰 앱 또는 웹 업로더가 원본을 업로드하고, Immich는 자체 경로와 자체 파일 이름으로 파일을 저장합니다. 데이터베이스에는 앨범, 얼굴, 검색에 관한 기준 정보가 저장됩니다. 서버가 모든 파일의 전체 상태를 항상 알고 있으므로 이러한 설계가 휴대폰 사용 환경을 개선합니다.

PhotoPrism은 파일을 읽습니다. 이미 직접 관리하는 originals 폴더를 마운트하면 PhotoPrism이 해당 폴더를 색인화합니다. 디렉터리 트리는 계속 사용자가 관리합니다. 다음 날 PhotoPrism을 제거해도 사진은 동일한 폴더에 동일한 이름으로 남아 있으며, PhotoPrism은 분석한 내용을 설명하는 YAML 사이드카 파일을 사진 옆에 기록합니다.

이 한 가지 차이가 나머지 차이 대부분을 설명합니다. Immich는 파일 수집을 직접 관리하므로 모바일 지원이 강력합니다. PhotoPrism은 기존 구조를 변경하지 않으므로 라이브러리 관리에 적합합니다. 사진이 휴대폰에 저장되는 가족에게는 Immich가 더 적합합니다. 디스크에 보관된 아카이브에는 PhotoPrism이 더 적합합니다.

하드웨어 요구 사항: Immich는 더 많은 리소스를 요구한다

문서에 명시된 메모리 최소 요구 사항은 큰 차이가 있으며, 소형 VPS에서는 보통 이 차이가 선택을 결정한다.

[
  {
    "label": "Immich",
    "min_ram_gb": 6,
    "recommended_ram_gb": 8
  },
  {
    "label": "PhotoPrism",
    "min_ram_gb": 3,
    "recommended_ram_gb": 4
  }
]

Immich는 최소 6 GB RAM을 요구하고 8 GB를 권장한다. 또한 machine learning을 끄면 4 GB 시스템에서만 실행할 수 있다고 설명한다. PhotoPrism은 3 GB의 물리 메모리와 CPU 코어 2개를 요구하며, RAM 용량은 코어 수에 맞춰야 한다고 설명한다.

이 차이는 실제로 존재하며, machine learning container에서 발생한다. Immich는 별도의 immich-machine-learning service에서 모델을 실행한다. 이 service는 CLIP(contrastive language image pretraining) 및 얼굴 감지 모델을 메모리에 로드한다. 2 GB 시스템에서는 kernel이 해당 container를 종료한다. Docker에서는 이 상황이 code 137로 종료되는 것으로 표시되며, 이는 out of memory 종료의 일반적인 형태다. PhotoPrism의 TensorFlow 모델은 더 작으므로 프로세스를 종료하는 대신 기능을 축소한다. 1 GB 이하의 시스템에서는 충돌하지 않고 RAW 변환과 TensorFlow를 비활성화한다.

두 프로젝트 모두 swap을 요구한다. PhotoPrism 문서에는 server에 최소 4 GB의 swap이 필요하다고 명시되어 있다. 어느 쪽이든 설치하기 전에 swap을 추가한다.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

free -h은 이제 4.0Gi를 표시하는 Swap: 줄을 출력해야 한다. 0B을 출력한다면 swapon에 실패한 것이다. 일반적으로 filesystem이 fallocate를 지원하지 않기 때문이며, 이 경우 sudo dd if=/dev/zero of=/swapfile bs=1M count=4096이 대체 수단으로 사용된다. 여기서는 container memory ceiling도 중요하다. Docker Compose에서 memory limit 설정을 사용하면 하나의 메모리 사용량이 큰 service가 전체 시스템을 중단시키는 것을 막을 수 있다.

사람들이 자주 놓치는 요구 사항이 하나 더 있다. Immich의 Postgres database는 실제 소유권과 권한을 지원하는 일반 Unix filesystem에 있어야 하며, local storage를 사용해야 한다. network share에는 둘 수 없다. PhotoPrism도 database file에 대해 같은 요구 사항을 제시한다. 어느 애플리케이션도 database를 mounted object store에 둔 상태로 안전하게 실행할 수 없다.

각각 설치하는 방법

두 설치 모두 공급업체가 제공하는 compose 파일과 하나의 명령으로 구성됩니다. 먼저 Docker Engine과 Compose plugin을 설정합니다. 자세한 내용은 VPS에서 Docker Compose를 사용하는 가이드를 참조합니다.

Immich는 각 릴리스와 함께 compose 파일과 예제 환경 파일을 제공합니다.

sudo mkdir -p /opt/immich && cd /opt/immich
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env

무엇이든 시작하기 전에 .env을 편집합니다. UPLOAD_LOCATION은 원본 사진이 저장될 위치입니다. DB_PASSWORD은 연결 문자열이 손상되지 않도록 A-Za-z0-9의 문자만 사용하여 기본값에서 변경해야 합니다. 그런 다음 시작합니다.

docker compose up -d
docker compose ps

웹 인터페이스는 port 2283에서 응답합니다. 해당 페이지를 통해 처음 등록한 계정이 administrator가 됩니다. 인터넷에 공개된 인스턴스를 방치하지 말고 즉시 접속하여 등록합니다.

PhotoPrism은 MariaDB가 이미 포함된 compose 파일 하나를 제공합니다.

sudo mkdir -p /opt/photoprism && cd /opt/photoprism
wget https://dl.photoprism.app/docker/compose.yaml

첫 번째 시작 전에 compose.yaml을 열고 PHOTOPRISM_ADMIN_PASSWORD을 변경합니다. 문서에는 이 내용이 명확히 설명되어 있습니다. 앱은 해당 파일에 있는 초기 password로 시작하고, 최소 길이는 8 characters이며, public server에서는 기본값을 절대 사용하면 안 됩니다. 동시에 originals volume을 사진이 저장된 folder로 설정합니다.

docker compose up -d
docker compose logs -f photoprism

PhotoPrism은 user admin로 port 2342에서 응답합니다. 두 앱 모두 직접 노출해서는 안 됩니다. Docker, TLS 및 백업을 사용하는 self-hosted Nextcloud와 같은 방식으로 TLS (transport layer security)가 적용된 reverse proxy를 앞에 배치합니다.

휴대폰 앱이 더 나은 것은 무엇인가

두 프로젝트가 가장 크게 다른 부분입니다. 대부분의 사용자가 결국 Immich를 선택하는 이유이기도 합니다.

Immich는 Android와 iOS용 공식 앱을 제공합니다. 이 앱은 카메라 롤을 백그라운드에서 백업합니다. 따라서 사용자가 아무것도 열지 않아도 새 사진이 휴대폰에서 전송됩니다. 앱에는 HTTPS 엔드포인트가 필요합니다. 따라서 외부에서 사용할 계획이라면 reverse proxy가 필수입니다.

PhotoPrism에는 공식 네이티브 앱이 없습니다. 대신 브라우저에서 홈 화면에 추가하는 progressive web app을 제공합니다. 휴대폰에서 동기화하는 방법으로 WebDAV(web distributed authoring and versioning)를 문서화하고 있습니다. 프로젝트에서는 이 용도로 PhotoSync라는 타사 앱을 사용할 것을 권장합니다. PhotoSync를 WebDAV를 통해 /import/ 또는 /originals/ 디렉터리에 연결하면 됩니다. 이 방식은 작동하지만, Immich가 자체 클라이언트에서 처리하는 작업을 유료 타사 앱이 대신 수행합니다.

여러 가족 구성원의 휴대폰을 자동으로 백업해야 한다면 선택은 명확합니다. Immich입니다.

머신 러닝이 실제로 제공하는 기능

Immich는 CLIP을 사용해 라이브러리에서 의미 기반 검색을 수행합니다. 따라서 "눈 속의 빨간 자전거"와 같은 검색어로 아무도 태그하지 않은 사진을 찾을 수 있습니다. 또한 얼굴 감지 및 그룹화와 중복 감지도 수행합니다. 대규모 가져오기를 CPU에서 색인화하면 백그라운드에서 몇 시간 동안 실행됩니다. 이는 정상이며 GPU(graphics processing unit)가 필요하지 않습니다.

PhotoPrism은 TensorFlow를 사용해 이미지를 레이블로 분류하고, 얼굴을 감지해 사람별로 그룹화하며, 위치 메타데이터를 읽어 장소 지도를 생성합니다. 사람들이 계속 사용하는 핵심 기능은 지도입니다. 촬영 장소를 기준으로 색인화된 라이브러리는 20년 동안의 사진을 탐색하는 완전히 다른 방식입니다. 얼굴 인식은 무료 Community edition에 포함되어 있습니다. 유료 Essentials 및 Plus 멤버십은 더 다양한 지도 레이어, 추가 사용자 역할, 사용자 관리 인터페이스 등의 기능을 제공하며, 2026년 7월 기준 월 몇 유로부터 시작합니다.

Immich는 유료 등급 없이 완전히 무료입니다. PhotoPrism의 핵심 기능은 무료이며, 선택적으로 유료 추가 기능을 사용할 수 있습니다.

백업이 데이터를 보존할지 결정합니다

백업이 없는 사진 서버는 디스크 하나만 고장 나도 가족의 모든 사진을 잃을 수 있습니다. 두 애플리케이션 모두 데이터베이스와 파일이라는 2가지 백업이 필요합니다.

Immich의 경우 Postgres 컨테이너에서 데이터베이스를 덤프하고 업로드 위치를 복사합니다.

docker exec -t immich_postgres pg_dump --clean --if-exists --dbname=immich --username=postgres | gzip > /backup/immich-db.sql.gz

그런 다음 UPLOAD_LOCATION을 백업합니다. 대체할 수 없는 데이터가 저장된 폴더는 upload, library 및 profile입니다. thumbs 및 encoded-video 폴더는 CPU 시간을 수 시간 사용하면 다시 생성할 수 있습니다. 데이터베이스 덤프에는 메타데이터만 포함되므로, 데이터베이스 덤프만으로는 아무것도 복원할 수 없습니다.

PhotoPrism의 경우 인덱스에 전용 명령이 있습니다.

docker compose exec photoprism photoprism backup -i -f

이 명령은 storage/backup/ 아래에 SQL 덤프를 기록합니다. 그런 다음 originals 폴더와 storage 폴더를 복사합니다. PhotoPrism은 각 사진을 설명하는 sidecar YAML 파일도 기록합니다. 따라서 인덱스를 잃어도 파일만으로 인덱스를 다시 만들 수 있습니다. 이는 수십 년 동안 보관할 아카이브에 중요한 장점입니다.

어떤 애플리케이션을 선택하든 암호화되고 중복 제거되는 restic 원격 저장소 백업을 사용하여 일정에 따라 백업을 서버 외부로 전송합니다. 라이브러리와 같은 디스크에 저장된 백업은 백업이 아닙니다.

어떤 것을 실행해야 하는가

사진이 휴대폰에 있고, 둘 이상의 사용자가 카메라 롤을 백업해야 하며, 서버에 6 GB 이상의 RAM을 할당할 수 있다면 Immich를 실행합니다. 직접 호스팅할 수 있는 Google Photos와 가장 유사한 서비스이며, 핵심은 모바일 사용 환경입니다. 단계별 Immich 설치 가이드에서 메모리 부족으로 인한 프로세스 종료와 업그레이드 관련 문제를 자세히 설명합니다.

디스크에 이미 사진 아카이브가 있고, 지도와 메타데이터를 중요하게 생각하며, 직접 관리하는 폴더 구조를 유지하려 하거나, VPS의 RAM이 4 GB이고 스와핑이 발생하는 라이브러리보다 정상적으로 작동하는 라이브러리를 원한다면 PhotoPrism을 실행합니다. PhotoPrism은 사진을 선별하고 정리하는 데 더 적합하며, 소형 하드웨어에 부담을 덜 줍니다.

두 서비스를 함께 실행해도 됩니다. Immich는 매일 휴대폰에서 사진을 가져오는 작업을 처리하고, 1년에 한 번 보관할 사진을 아카이브로 정리한 다음 PhotoPrism이 해당 아카이브를 인덱싱하도록 할 수 있습니다. 두 서비스는 충돌하지 않습니다. PhotoPrism은 폴더를 읽고, Immich는 자체 데이터를 관리하기 때문입니다.

FAQ

PhotoPrism과 Immich가 같은 사진 폴더를 공유해도 됩니까?

양방향으로 안전하게 공유할 수는 없습니다. PhotoPrism은 originals 폴더를 읽고 이미지 옆에 사이드카 YAML 파일을 작성합니다. 반면 Immich는 업로드 위치의 콘텐츠를 직접 관리한다고 가정합니다. PhotoPrism이 Immich의 library 폴더를 읽기 전용 복사본으로 가리키면 사진을 탐색할 수 있습니다. 그러나 두 애플리케이션이 같은 파일을 관리하도록 설정하지 마십시오. Immich가 인덱싱하는 동안 스토리지 템플릿에 따라 PhotoPrism이 사용하는 자산을 이동하거나 이름을 변경할 수 있기 때문입니다.

Immich를 사진의 유일한 복사본을 보관할 만큼 안정적으로 사용할 수 있습니까?

어떤 self-hosted 애플리케이션도 무엇이든 유일한 복사본을 보관해서는 안 됩니다. Immich는 호환성이 깨지는 변경 사항을 자주 릴리스합니다. 또한 부주의한 docker compose pull로 인해 데이터베이스가 시작되지 않을 수 있습니다. 따라서 버전을 고정하고 업그레이드하기 전에 릴리스 노트를 읽으십시오. 원본 파일은 서버 외부에 백업해 두십시오. 그러면 위험을 낮게 유지할 수 있습니다.

Immich machine learning 컨테이너가 계속 다시 시작되는 이유는 무엇입니까?

메모리를 과도하게 사용해서 종료되고 있습니다. docker compose ps를 실행하고 machine learning 서비스가 코드 137로 종료되는지 확인하십시오. 코드 137은 커널의 out of memory killer가 프로세스를 종료했다는 의미입니다. swap을 추가하거나 컨테이너에 메모리 제한을 설정하여 종료되는 대신 메모리 사용을 제한하십시오. 또는 4 GB 시스템에서는 machine learning을 완전히 비활성화하십시오. machine learning이 없으면 검색이 작동하지 않지만 Immich의 나머지 기능은 정상적으로 실행됩니다.

PhotoPrism에 MariaDB가 필요합니까, 아니면 SQLite를 사용해도 됩니까?

SQLite도 작동하며 개인 라이브러리에는 적합합니다. 그러나 PhotoPrism은 SQLite를 사용할 때 worker를 4개로 제한합니다. 문서에서는 높은 동시성을 더 잘 처리하는 MariaDB로 전환할 것을 권장합니다. 프로젝트가 제공하는 compose 파일에는 이미 MariaDB가 포함되어 있습니다. 따라서 권장 방식이 기본 설정이기도 합니다.

라이브러리 크기보다 디스크 공간을 얼마나 더 확보해야 합니까?

두 애플리케이션 모두 원본 파일 크기에 10~20%를 추가하십시오. 이 공간은 생성되는 썸네일과 트랜스코딩된 동영상 미리보기에 사용됩니다. 200 GB 컬렉션이라면 데이터베이스, 로컬 백업 복사본 및 증가 여유 공간을 고려하여 대략 300 GB 볼륨이 필요합니다.