Google Photos에 몇 년치 사진이 쌓여 있고, 요즘 들어 그게 자꾸 마음에 걸립니다. Google이 딱히 뭘 잘못해서가 아닙니다. 모든 얼굴, 모든 위치, 모든 “몇 년 전 오늘”을 색인하는 주체가 Google이라는 사실 때문입니다. 그 전부를 내 서버에서 가질 수 있다고 말할 때 사람들이 늘 가리키는 도구가 Immich입니다. 얼굴 인식, 자연어 검색, 휴대폰 자동 백업, 추억(Memories) 피드. 이 모든 것이 내가 직접 관리하는 서버에서 돌아갑니다.
그 약속이 실제로 성립하는지 확인하려고 Immich를 직접 돌려 봤습니다. 기능 목록 요약이 아니라, 써 보고 내린 판정입니다. 그리고 시점이 중요합니다. Immich는 v3.0.0 버전을 2026년 7월 1일에 출시했는데, 이 릴리스로 제품이 크게 달라져서 예전 리뷰들은 이제 더 이상 존재하지 않는 모습을 설명하고 있는 셈입니다. 이 글은 v3를 다룹니다. 가족사진의 최종 보관처로 믿고 맡길 수 있는지를 가르는 항목들, 그리고 여전히 Google에 밀리는 지점까지 기준으로 평가했습니다.
요약
라이브러리를 직접 통제하고 싶고 유지 관리까지 떠맡을 각오가 된 사람이라면, Immich v3는 Google Photos를 대체할 준비가 되어 있습니다. 일상적인 사용에서 모바일 백업, 검색, 얼굴 인식은 Google 수준에 충분히 근접해서 아쉬움이 크지 않을 겁니다. 기본 로컬 머신러닝 구성에서는 사진 분석이 내 배포 환경 안에서만 이루어집니다. 단, 조건이 있습니다. 라이브러리를 잃지 않을 책임이 온전히 내 몫이 되고, 특히 오래됐거나 커스터마이징된 배포에서는 업그레이드가 실패한 사례가 있으며, 제대로 된 백업은 선택이 아니라 필수입니다. 유지 관리 없이 그냥 알아서 돌아가는 사진 서비스를 원한다면 Google Photos에 남으세요.
항목별로 제게 와닿은 결과는 이렇습니다:
- 모바일 백업: 강점입니다. Immich는 iOS와 Android에서 백그라운드 자동 백업을 지원하며, 바로 이 기능이 Immich를 단순한 사진 아카이브가 아니라 Google Photos의 대체재로 만들어 줍니다.
- 검색과 얼굴 인식: 탄탄합니다. 시맨틱 검색(“해변에서 노는 강아지 사진”)이 실제로 작동하고, Immich는 얼굴을 자동으로 그룹화합니다; 이름을 지정하면 그 그룹을 검색할 수 있게 됩니다. 제 테스트에서는 닮은 사람들을 구분하는 것이 약점이었고, 가끔 그룹을 직접 수정해야 했습니다.
- 리소스 사용량: 예상보다 무겁습니다. Immich, Postgres, Redis, 머신러닝 서비스를 포함한 전체 스택은 최소 6GB RAM이 필요하고, 8GB가 권장됩니다. 전체 머신러닝 스택은 메모리가 적은 Raspberry Pi에는 맞지 않습니다. 머신러닝을 끄거나 다른 곳으로 옮기면 사양이 낮은 하드웨어에서도 돌릴 수 있지만, 그러면 Immich를 매력적인 Google Photos 대체재로 만들어 주는 기능 일부를 포기하거나 구성이 복잡해집니다.
- 유지 관리와 업그레이드 리스크: 약점이자, 결론에 “조건”이 붙는 이유입니다. 오래됐거나 커스터마이징된 배포에서 마이그레이션 실패를 겪은 사용자들이 있습니다. 어떤 경우든 3-2-1 백업은 필수입니다.
- 데이터 주권: 갈아탈 가장 강력한 이유입니다. Immich의 기본 내장 머신러닝 컨테이너를 쓰면 사진 분석, 얼굴 임베딩, 시맨틱 검색 처리가 모두 내 배포 환경 안에 머뭅니다. 원격 머신러닝을 구성하면 이미지 미리보기가 해당 호스트로 전송되므로, 프라이버시 경계는 배포 방식에 따라 달라집니다. Google Photos에 있던 사본을 영구 삭제하거나 Google Photos의 휴지통을 비운 뒤에도, Google에 따르면 활성 시스템에서 완전히 삭제되기까지 보통 두 달 정도 걸리고, 암호화된 백업 사본은 최대 여섯 달까지 남아 있을 수 있습니다.
추천 대상: Docker Compose 유지 관리가 익숙한 프라이버시 중시 셀프 호스터, 다른 사람들을 대신해 백업과 업그레이드를 책임질 가정용 또는 소규모 조직의 시스템 관리자, 활발한 개발과 믿을 만한 모바일 백업 경험을 원하는 기술 평가자. 비추천 대상: 유지 관리는 전혀 없이 “그냥 가족끼리 사진만 공유하고 싶은” 사람, 또는 업그레이드를 맡아 줄 사람이 없는 비기술 사용자.
이 리뷰가 다루는 것과 다루지 않는 것
Immich v3를 약 10일간 테스트했고, 리뷰가 끝날 무렵에는 v3.0.2를 돌리고 있었습니다. 8GB Ubuntu VPS에 공식 Docker Compose 구성으로 배포했고, 약 9,000장의 개인 사진 라이브러리를 사용했습니다. Immich는 무료 오픈소스입니다. 이 글에 협찬은 없고, 리뷰 대가로 받은 것도 없습니다.
본격적으로 들어가기 전에, 기대치를 맞춰 둘 몇 가지:
- 이 글은 리뷰이지 설치 가이드가 아닙니다. 설치 과정이나 docker-compose.yml을 하나하나 짚지 않습니다. 그건 별도의 글감입니다. 여기서 다루는 질문은 “어떻게 설치하나”가 아니라 “써야 하나”입니다.
- 그 기간 동안 전체 배포 한 번과 포인트 업그레이드 한 번을 완료했습니다. 10일이라는 기간으로는 여러 업그레이드 주기에 걸친 장기 안정성을 증명할 수 없으므로, 장기적인 근거가 필요한 항목에는 그렇다고 명시했습니다.
- 대안(PhotoPrism, Ente)은 특정 독자에게 더 잘 맞는 지점에서만 언급합니다. 셋을 나란히 놓고 비교하는 글이 아닙니다. 그게 필요하다면 별도의 글이 맞습니다.
Immich는 Google Photos를 대체할 준비가 됐을까?
짧게 답하면, 맞는 사람에게는 그렇습니다. 그리고 “맞는 사람”인지 가르는 기준은 소프트웨어가 충분히 좋은지가 아니라, 유지 관리를 직접 떠맡고 싶은지입니다. 소프트웨어는 이미 충분히 좋습니다. Immich v3는 Google Photos의 핵심 역할(모바일 자동 백업, 얼굴 및 시맨틱 검색, 추억 피드)을 충분히 잘 해내서, 일주일쯤 쓰고 나니 습관적으로 Google Photos를 열던 손이 멈췄습니다. 진짜 결정할 것은 이걸 계속 돌아가게 하는 사람이 될 것인지 여부입니다.
이 구분이 중요한 이유는, 대부분의 사람들이 전환을 그렇게 접근하지 않기 때문입니다. 기능 체크리스트를 비교하고, Immich가 90%까지 왔다고 판단하고, 갈아탑니다. 그런데 여섯 달 뒤의 만족도를 결정하는 건 빠져 있는 10%의 기능이 아니라, 백업을 마련해 뒀는지, 그리고 첫 대형 업그레이드에서 살아남았는지입니다. 그래서 이 리뷰의 비중도 그에 맞췄습니다. 제 결론에서 가장 무게가 실리는 두 축은 기능 개수가 아니라 유지 관리 리스크와 데이터 주권입니다. 모바일 업로드와 검색을 완벽하게 해내도 업그레이드 한 번에 라이브러리를 날리는 도구라면, 가장 중요한 단 하나의 역할에 실패한 겁니다.
갈아탈 가장 큰 이유는 주권입니다. 내 사진, 내 서버. 기본 로컬 머신러닝 구성에서는 어떤 외부 사진 서비스도 가족 라이브러리를 색인하지 않습니다. 갈아타지 말아야 할 가장 큰 이유는, 내가 가진 것 중 가장 대체 불가능한 데이터를 위한 1인 IT 부서가 되겠다고 서명하는 셈이라는 점입니다. 이 둘은 동시에 참이고, 어느 쪽이 이기느냐는 Immich가 아니라 당신에게 달려 있습니다.
올해 초의 리뷰를 읽고 발길을 돌렸던 분들께 먼저 말해 둘 것이 하나 있습니다. v3는 예전에 결정적 결격 사유였던 공백을 메웠습니다. 이제 모바일에서 비파괴 사진 편집이 작동하므로, 원본 파일을 건드리지 않고 자르고, 회전하고, 보정할 수 있습니다. “폰에서 사진 편집도 못 하잖아”가 기다려 온 이유였다면, 그 이유는 사라졌습니다.
섹션 요약: 결론은 Immich가 충분히 좋은지에 대한 것이 아닙니다. 충분히 좋습니다. 관건은 그에 딸려 오는 일을 맡고 싶은지입니다.
Immich가 잘하는 것
Immich는 세 가지를 잘합니다. 테스트 기간 내내 일상용으로 버텨 준 모바일 자동 백업, 일상적인 사용에서 Google에 근접한 머신러닝 검색과 얼굴 그룹화, 그리고 머신러닝 처리를 내가 통제하는 인프라 안에 두는 기본 배포 모델입니다. 이 기능들이 Immich를 그럴싸한 이미지 폴더가 아니라 Google Photos의 대체재로 만들어 주며, 셋 모두 테스트에서 제 몫을 해냈습니다.
결국 마음을 사로잡는 건 모바일 백업입니다. 폰에 앱을 설치하고 내 서버를 지정하자, 새 사진이 따로 신경 쓰지 않아도 백그라운드에서 올라갔습니다. v3는 Android 백업을 새 주기적 작업 스케줄러 중심으로 다시 만들기도 했습니다. 10일간의 테스트 동안 백그라운드 업로드는 믿음직했습니다. 이 기능은 지루할 만큼 안정적이어야 하고 그렇지 않으면 전체가 무너지는데, 실제로 그만큼 안정적이었습니다.
검색은 처음 써 보면 마법처럼 느껴지는 부분입니다. Immich는 CLIP 계열 모델을 사용해 시맨틱 검색용 임베딩을 생성합니다. 그래서 “눈밭의 빨간 자동차”라고 입력하면 태그 한 번 안 달고도 그 사진을 찾을 수 있습니다. 얼굴 인식은 InsightFace의 감지 및 인식 모델로 동작합니다. Immich는 라이브러리 전체의 얼굴을 자동으로 그룹화했고, 몇 명에게 이름을 붙이고 나니 사람 보기 화면이 특정 인물을 빠르게 찾는 데 쓸모 있어졌습니다. 두 기능 모두 서버에서 백그라운드 작업으로 실행되며, Postgres의 시맨틱 검색 인덱스는 VectorChord가 담당합니다.
검색 품질에 대한 단서는 구체적으로 짚을 가치가 있습니다. 제 라이브러리에서 범주 인식은 강력했지만(고양이는 어김없이 고양이로 알아봤습니다), 이목구비가 비슷한 사람들을 구분하는 건 더 어려워했습니다. 얼굴 그룹화 결과는 선택한 모델, 클러스터링 설정, 그리고 라이브러리 구성에 따라서도 달라질 수 있습니다. 제 사용에서는 특정 인물을 찾기에 충분했고, 이따금 잘못 묶인 그룹을 직접 고쳐야 했습니다.
그리고 프라이버시 때문에 갈아타는 사람에게 가장 중요한 부분이 있습니다. Immich의 내장 머신러닝 워커는 서드파티 이미지 분석 서비스를 호출하는 대신 배포 환경 안에서 별도 컨테이너로 실행됩니다. 이 기본 구성에서는 사진 미리보기, 얼굴 임베딩, 시맨틱 검색 처리가 모두 내가 통제하는 인프라 안에 남습니다. Immich는 원격 머신러닝 호스트를 사용할 수도 있는데, 이 경우 서버가 이미지 미리보기를 해당 호스트로 보내 처리하므로 그 호스트도 신뢰 환경의 일부로 취급해야 합니다. Google Photos 라이브러리를 영구 삭제하거나 Google Photos의 휴지통을 비운 뒤에는, Google에 따르면 활성 시스템에서 완전히 삭제되기까지 보통 두 달 정도 걸리고, 암호화된 백업 사본은 최대 여섯 달까지 남아 있을 수 있다고 합니다.
Immich가 아쉬운 부분
Immich가 Google Photos에 아직 밀리는 지점은 대부분 완성도입니다: 자동 하이라이트 영상과 시네마틱 사진, 생성형 편집 도구, 그리고 더 깊은 생태계 통합(백업된 사진을 지원되는 모바일 사진 선택기로 불러오는 것 등)입니다. 하드웨어에 요구하는 것도 훨씬 많고, 홈 네트워크 밖에서 라이브러리에 접근하려면 추가 구성이 필요합니다.
Immich는 실험적인 옵트인 방식의 Google Cast 기능을 웹 클라이언트에서 제공하여 Chromecast, Nest Hub 같은 기기로 보낼 수 있습니다. 다만 캐스팅에는 Google의 DNS 서버에서 조회 가능한 DNS 레코드를 가진, 공개적으로 접근 가능한 HTTPS 인스턴스가 필요합니다. Android와 iOS 캐스팅은 아직 향후 계획으로 남아 있고, Immich에는 전용 TV 앱이 없습니다.
리소스 사용량은 사람들이 허를 찔리는 대목입니다. Immich는 프로세스 하나가 아닙니다. 일반적인 배포에는 Immich 애플리케이션 서비스, Postgres, Redis, 그리고 별도의 머신러닝 서비스가 포함됩니다. 공식 요구 사항은 최소 6GB RAM, 머신러닝을 완전히 끄면 4GB(다만 그러면 이걸 돌리는 이유의 절반인 검색과 얼굴 기능을 잃습니다), 권장 8GB입니다. CPU는 최소 2코어, 권장 4코어. 데이터베이스는 로컬 SSD 스토리지를 요구하며, 네트워크 공유는 명시적으로 피하라고 합니다. 첫 임포트 동안에는 ML 파이프라인이 전부 색인하느라 CPU를 꽉 채우고 RAM을 집어삼키다가(제 서버는 이틀쯤 뜨겁게 돌았습니다) 그 뒤에는 잠잠해집니다. 요점은 이겁니다. 서랍 속 Raspberry Pi를 그리고 있었다면 그 그림은 지우세요. 이건 소형 서버급 워크로드입니다.
참고: v3에서는 CPU 최소 사양이 약간 올라갔습니다. amd64 머신러닝 컨테이너는 이제 x86-64-v2 마이크로아키텍처 수준을 요구하는데, 이는 대략 2012년 이후 출시된 대부분의 프로세서가 지원합니다. 아주 오래된 하드웨어를 쓰고 있다면 결정하기 전에 이것부터 확인하세요. ML 컨테이너가 시작되지 않고 나서야 알아차리기 쉬운 부분입니다.
마지막 하나, 특히 가정에는 현실적인 고려 사항입니다. 원격 접근은 Immich를 어디에 호스팅하느냐에 달려 있습니다. 홈 서버라면 로컬 접근은 간단하지만, 집 밖에서 라이브러리에 접근하려면 VPN, 리버스 프록시, 또는 보안 터널이 필요합니다. VPS라면 호스트가 인터넷에 연결되어 있지만, Immich를 직접 노출해야만 외부에서 접근할 수 있습니다. 노출한다면 HTTPS와 적절한 접근 제어를 초기 배포 단계부터 갖춰야 합니다. Immich는 특히 애플리케이션 포트를 공용 인터넷에 직접 포워딩하는 것을 명시적으로 경고합니다. 어느 쪽을 택하든, Google Photos에서는 이 인프라를 Google이 대신 처리해 줍니다.
섹션 요약: Immich는 매일 쓰는 핵심 기능에서는 Google과 대등하고, 완성도와 생태계에서는 밀립니다. 주권이 동기인 사용자에게는 남는 거래지만, Google의 자동 하이라이트 영상, 모바일 캐스팅, 자체 TV 통합에 기대는 사람에게는 실질적인 손실입니다.
업그레이드와 유지 관리의 현실
사진이 내 서버에 사는 순간부터 그것을 잃지 않는 일은 내 몫이 되고, Immich 업그레이드는 특히 오래됐거나 커스터마이징된 배포에서 이따금 사용자들에게 문제를 일으켰습니다. 제 결론을 무조건적인 “예”에서 조건부로 바꿔 놓는 축이 바로 이것이므로, 리스크가 무엇이고 무엇이 아닌지 정확히 짚을 가치가 있습니다.
먼저 유지 관리의 현실부터. Immich 운영은 부담이 적지만 0은 아닌, 계속되는 일입니다. 주기적인 업데이트가 있고, 가끔 메이저 버전이 릴리스 노트를 꼭 읽어야 하는 호환성 파괴 변경을 들고 옵니다. 매일 돌봐야 하는 건 아니지만(대부분의 시간에는 그냥 돌아갑니다) 분명한 책무이고, 그 책무는 전부 내게 떨어집니다. Hacker News에서 한 댓글 작성자는 이 반감을 직설적으로 요약했습니다:
“저걸 다루려면 웹 개발자나 시스템 관리자쯤은 되어야 해요. 악몽 같은 업그레이드에, 동기화 관련 이상한 버그가 산더미고요.”
제 경험보다는 가혹한 평가지만, 실제 운영 리스크를 가리키고 있습니다. 한 사용자의 보고에 따르면 업그레이드 후 라이브러리가 사라졌다고 합니다. 나중에 보니 PostgreSQL 데이터 볼륨이 부팅 시 마운트되지 않은 것이었고, 마운트를 고치자 라이브러리는 돌아왔습니다. 별개의 이슈에서는 마이그레이션이 실패했는데 외부 PostgreSQL 배포에서 데이터베이스 역할 식별자가 제대로 따옴표 처리되지 않은 것이 원인이었습니다. 이 사례들은 커스터마이징된 스토리지와 데이터베이스 구성이 업그레이드 전후로 어떻게 어긋날 수 있는지 보여 줄 뿐, Immich가 사진을 상습적으로 지운다는 것을 보여 주지는 않습니다.
v3의 데이터베이스 경고는 주로 유난히 오래됐거나 커스터마이징된 설치에 해당합니다. Immich는 pgvecto.rs에서 VectorChord로의 사용자 이전을 v1.133.0에서 시작했습니다. v2가 나오기 전의 일이며, v3는 남아 있던 pgvecto.rs 호환성을 제거했습니다. 표준적인 v2 배포라면 이미 VectorChord를 쓰고 있을 것이므로, 일반적인 v2에서 v3로의 업데이트는 보통 버전 태그 변경에 이어 늘 하던 Docker Compose pull과 재시작을 하면 끝납니다. 아직 pgvecto.rs를 쓰는 배포라면 v3로 넘어가기 전에 Immich의 VectorChord 마이그레이션을 먼저 완료해야 합니다.
그리고 이 지점에서 타협 불가능한 규칙이 나옵니다. 제가 아니라 Immich 스스로가 말하는 규칙입니다:
참고: Immich는 백업이 아닙니다. 팀이 직접 그렇게 말합니다. v2.0.0 릴리스 노트에서 팀은 이렇게 썼습니다: “3-2-1 백업 전략은 여전히 매우 중요합니다. 애플리케이션이 여러분의 소중한 추억을 잃게 만들지 않도록 하는 것은 팀의 책임입니다. 하지만 하드 드라이브가 고장 나지 않는다거나, 전기 사고로 서버/시스템이 예기치 않게 꺼져 데이터 손실로 이어지지 않는다고는 보장할 수 없습니다.” Immich 하나만으로는 완전한 백업 전략이 아닙니다. 그 서버가 파일의 유일한 영속적 사본이라면, 그것은 기본 사본이지 백업이 아닙니다. 사본 세 개를 두 종류의 미디어에 두고, 하나는 오프사이트에 두어야 합니다. 이 리뷰에서 단 하나만 기억한다면 이것을 기억하세요.
회의적인 독자라면 제기할 만한, 연관된 신뢰 문제가 하나 있습니다. 코드베이스를 감사하는 건 아니니 배포자의 관점으로만 좁혀 보겠습니다. 이 프로젝트는 건강한가? 증거로 보면, 그렇습니다. 프로젝트는 활발히 개발되고 있고, 이슈에는 응답이 달립니다. 2025년 말, Google Safe Browsing이 Immich 도메인 하나를 위험 사이트로 표시했습니다. Immich는 이 경고가 사용자들의 사진 라이브러리가 아니라 자사의 프리뷰 인프라에 영향을 주는 오탐이라고 설명했습니다. 프로젝트 측에 따르면 Google은 검토 후 경고를 해제했지만, 새 프리뷰 환경이 만들어지자 경고가 다시 나타났습니다. Immich는 해당 환경들을 전용 도메인으로 옮기겠다고 밝혔습니다. 문제를 공개적으로 처리하는 프로젝트의 모습이며, 라이브러리를 맡길 대상에게 바라는 바로 그 태도입니다.
섹션 요약: 사진이 내 서버에 사는 순간, 그것을 잃지 않는 일은 내 몫이 됩니다. Immich는 어려운 부분들을 잘 해내지만, 그 부분만큼은 대신해 줄 수 없습니다.
Immich를 써야 하는 사람, 쓰지 말아야 하는 사람
Immich는 라이브러리를 Google 서버에 두지 않고 Google Photos 스타일의 기능을 원하며, 그 대가로 작은 서버 하나쯤은 기꺼이 운영할 사람을 위한 것입니다. 유지 관리는 전혀 하기 싫고 그저 가족끼리 사진만 공유하면 되는 사람을 위한 것이 아닙니다. 결정은 그게 전부입니다.
다음 중 하나에 해당한다면 Immich를 돌리세요:
- 프라이버시 또는 주권이 동기인 셀프 호스터. 얼굴 인식, 검색, 모바일 백업을 원하면서, 기본 머신러닝 처리가 내가 통제하는 인프라 안에 머물기를 바라는 경우입니다. 여기가 Immich의 홈그라운드이고, 이 영역에서는 탁월합니다. 당신의 동기는 통제이고, Immich가 내놓는 것이 바로 통제입니다.
- 가정 또는 소규모 조직의 시스템 관리자. 백업과 업그레이드 규율을 직접 떠안는 것이 편하고, 그냥 잘 돌아가는 사진을 원하는 가족이나 작은 팀을 대신해 그 일을 하는 경우입니다. 그들이 지지 않아도 되도록 운영 부담을 당신이 짊어집니다. Immich는 잘 맞습니다. 단, 당신 스스로 업그레이드 흐름을 계속 챙긴다는 전제에서요.
- 프로젝트의 추진력을 중시하는 기술 평가자. 꾸준히 릴리스를 내고, 제 테스트에서 버텨 준 모바일 백업 경험을 갖췄으며, 여전히 활발하게 개발 중인 프로젝트를 원하는 경우입니다. Immich의 릴리스 주기와 커뮤니티 활동은 그 조건을 충족합니다.
다음 중 하나에 해당한다면 (적어도 아직은) Immich를 돌리지 마세요:
- 유지 관리에는 전혀 뜻이 없는 “그냥 우리끼리 사진만 공유하고 싶다”는 사람. 이 글을 조사하며 본 가장 날카로운 댓글 중 하나는, Immich가 자신에게는 엉뚱한 문제를 풀고 있다는 지적이었습니다. 그들은 그냥 가족끼리 사진을 공유하고 싶었을 뿐이고, 셀프 호스팅은 그 필요에 맞지 않았습니다. 맞는 말입니다. 당신이 그렇다면, 답은 Google Photos(또는 관리형 옵션)가 실제 문제에 더 잘 맞는다는 것이고, 그건 부끄러운 일이 아닙니다.
- 맡아 줄 사람이 없는 비기술 사용자. 백업과 업데이트를 처리할 사람이 아무도 없다면, 그 배포는 라이브러리를 위험에 빠뜨립니다. 애초에 원했던 것과 정반대의 결과입니다.
“아직은 아니다” 쪽에 속하지만 그래도 Google에서 벗어나고 싶다면, 서로 다른 이유로 살펴볼 만한 대안이 둘 있습니다. PhotoPrism 쪽은 드라이브나 NAS에 있는 기존 아카이브를 색인하는 것이 진짜 목적이고 자체 모바일 백업 앱이 필요 없을 때 맞는 아카이브 우선 옵션입니다. 전용 네이티브 앱 대신 브라우저와 PWA 접근에 기댑니다. Ente Photos 쪽은 종단 간 암호화가 다른 무엇보다 최우선일 때 살펴볼 선택지입니다. 업로드 전에 사진을 암호화하고, ML을 기기 내에서 실행하며, 그 결과로 만들어지는 인덱스도 암호화한 뒤 동기화합니다. 또한 여러 차례 독립적인 보안 감사를 거쳤는데, 여기에는 CERN이 후원한 Cure53 평가도 포함됩니다. 둘 다 훌륭한 선택지입니다. 다만 Immich와는 다른 독자에게 최적화되어 있을 뿐입니다. (셋을 정면으로 비교한 완전판을 원한다면, 그건 여기 욱여넣을 것이 아니라 그 자체로 별도의 비교 글감입니다.)
마지막으로 비용 이야기. 끊임없이 나오는 주제이기 때문입니다. Immich 자체는 무료지만, 셀프 호스팅이 자동으로 더 싼 건 아닙니다. 서버, 전기 요금, 오프사이트 백업 스토리지, 그리고 내 시간까지 계산하면 총액이 Google One 구독료를 넘어설 수 있습니다. 요금제와 프로모션은 지역마다 다르고 수시로 바뀌니, 자신의 국가에 표시되는 현재 Google One 가격과 비교해 보세요. 갈아타는 이유는 통제권이어야지, 셀프 호스팅이 돈을 아껴 줄 거라는 가정이어서는 안 됩니다.
마음을 굳혔고 기초 작업(서버, Docker, 셀프 호스팅 서비스 운영의 기본)이 필요한 독자에게, 그 준비 과정은 별도의 주제입니다. 그리고 자체 파일 스토리지 같은 것들과 함께 더 넓은 프라이버시 우선 구성 안에서 Immich가 차지하는 자리가 궁금하다면 저희 가이드를 참고하세요: 최고의 셀프 호스팅 프라이버시 스택.
자주 묻는 질문
Immich는 가족사진의 유일한 사본을 맡길 만큼 안정적인가요?
아니요, 유일한 사본으로는 안 됩니다. Immich v3는 기본 사진 라이브러리 역할은 할 수 있지만, 같은 파일이 독립적인 백업 시스템에도 존재해야 합니다. Immich 팀 스스로 3-2-1 전략을 권장합니다. 사본 세 개를 두 종류의 미디어에 나눠 저장하고, 그중 하나는 오프사이트에 보관하는 것입니다. Immich는 기본 라이브러리를 정리하고 제공할 수는 있어도, 대체 불가능한 사진이 존재하는 유일한 장소가 되어서는 절대 안 됩니다.
Google Photos는 되는데 Immich는 안 되는 것은?
Google이 여전히 앞서는 분야는 자동 하이라이트 영상과 시네마틱 사진, 생성형 편집, 그리고 더 넓은 소비자 생태계입니다. Immich에는 추억 피드와 비파괴 사진 편집이 있습니다. 또한 실험적인 옵트인 방식의 캐스팅 기능을 웹 클라이언트에서 Chromecast와 Nest Hub로 제공하지만, 공개적으로 접근 가능한 HTTPS 배포가 필요합니다. 모바일 캐스팅과 전용 TV 앱은 아직 없습니다.
Immich의 얼굴 인식은 Google Photos만큼 좋은가요?
아는 사람을 그룹으로 묶는 일상적인 용도라면 근접합니다. Immich는 얼굴 그룹을 자동으로 생성하고, 이름을 지정하면 그 그룹을 검색할 수 있게 됩니다. 약점은 닮은 사람들을 구분하는 것입니다. 결과가 라이브러리, 모델, 클러스터링 설정에 따라 달라지기 때문에 쓸모 있는 보편적 정확도 수치는 없습니다. 제 테스트에서는 일상적인 검색에 충분할 만큼 믿을 만했지만, 특히 이목구비가 비슷한 사람들에 대해서는 가끔 수동 교정이 필요했습니다. “제 테스트에서 일상 검색에는 충분했고, 가끔 손을 봐야 했다” 정도로 받아들이시고, 측정된 수치로 여기지는 마세요.
Immich 유지 관리는 얼마나 어렵나요?
부담은 적지만 실재하는, 계속되는 일입니다. 대부분의 시간에는 그냥 돌아가지만, 주기적으로 업데이트를 적용해야 하고, 가끔 메이저 버전이 호환성 파괴 변경을 들고 오므로 적용 전에 릴리스 노트를 읽고 백업을 검증해야 합니다. 백업 규율은 영구히 당신 몫입니다. Docker Compose와 릴리스 노트 읽기가 익숙하다면 충분히 감당할 만하고, 그렇지 않다면 학습 곡선을 감안해 두세요.
Immich가 정말 Google Photos보다 저렴한가요?
그렇지 않은 경우가 많습니다. 서버, 전기 요금, 백업 스토리지, 그리고 내 시간까지 전부 계산하면 총액이 Google One 구독료를 넘어설 수 있습니다. Google One 가격과 프로모션은 나라마다, 시기마다 다르니 자신의 지역에서 제공되는 현재 가격과 비교하세요. 갈아탈 이유는 데이터에 대한 통제권이지 돈 절약이 아닙니다. 비용이 유일한 동기라면 먼저 총비용을 끝까지 계산해 보세요. 셀프 호스팅에 유리하지 않을 수 있습니다.
