Immich 3.0

 (github.com/immich-app)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Immich v3.0.0은 수개월 작업 뒤 나온 다음 메이저 릴리스로, 모바일 비파괴 편집, 워크플로우 미리보기, 백그라운드 백업 개선, 무결성 검사, 실시간 비디오 트랜스코딩 미리보기 등을 포함함
  • 이번 릴리스에는 Breaking changes가 있지만 상당수는 Immich API 엔드포인트 변경이라 Immich API와 통합하는 서드파티 도구에 주로 영향을 주며, 대부분의 사용자는 기존 방식대로 업데이트 가능함
  • 업그레이드는 .env의 IMMICH_VERSION을 v2에서 v3로 바꾼 뒤 docker compose pull && docker compose up -d를 실행하며, v3.0.0은 pgvecto.rs 지원을 중단해 v1.133.0 이전 환경은 VectorChord 마이그레이션이 필요함
  • 모바일 앱은 웹과 같은 비파괴 편집 모델을 도입하고 Android 백그라운드 백업을 주기 작업 스케줄러로 개선했으며, iOS는 짧은 백그라운드 실행 시간 안에서 동기화와 업로드를 병렬 실행함
  • 실시간 비디오 트랜스코딩은 아직 실험적 기능이고 현재 웹 앱에만 구현되어 있으며, 모바일 앱은 구현 중이라 기존 오프라인 트랜스코딩 파일을 수동 삭제하는 것은 권장되지 않음

업데이트와 호환성 변경

  • Immich v3.0.0은 다음 메이저 버전으로 발표됐으며, 여러 Breaking changes를 포함함
  • Breaking changes 중 다수는 API 엔드포인트 업데이트라 Immich API와 통합하는 서드파티 도구에 주로 영향을 줌
  • 대부분의 사용자는 기존과 같은 방식으로 업데이트할 수 있음
  • 전체 마이그레이션 가이드는 릴리스 안내에서 별도 링크로 제공됨
  • v3.0.0은 pgvecto.rs 지원을 중단함
  • 업데이트 절차:
    • .env 파일에서 IMMICH_VERSION=v2를 IMMICH_VERSION=v3로 변경
    • docker compose pull && docker compose up -d 실행

릴리스 후보와 알림 채널

  • v3.0.0은 Immich가 release candidate를 처음 사용한 릴리스임
  • 릴리스 후보는 테스트됐지만 공식 릴리스는 아닌 프리릴리스이며, 최종 릴리스 전 남은 버그를 찾고 수정하는 데 사용됨
  • Immich 안에서 릴리스 후보 알림을 받고 싶으면 Admin settings > Version check에서 릴리스 채널을 Stable에서 Release candidate로 바꿀 수 있음

모바일 편집과 백업 개선

  • 모바일 비파괴 편집은 v2.5.0에 웹으로 먼저 추가된 이미지 편집 기능의 후속 작업임
  • 기존 모바일 편집기는 사진을 제자리에서 수정하지 않고 새 asset을 만드는 별도 시스템을 사용했음
  • v3.0.0의 모바일 편집기는 웹 버전과 같은 기능을 제공하며, 원본 파일을 건드리지 않고 자르기, 회전, 이미지 조정을 할 수 있음
  • 편집은 비파괴 방식이라 나중에 다시 수정하거나 되돌릴 수 있고, 모바일에서 편집한 뒤 웹에서 이어서 조정할 수 있음
  • 이전 모바일 편집 구현에서 제공되던 일부 기능은 제거됨
    • 사진 색상 변경
    • Live Photo 편집
    • 로컬 asset 편집
  • 일부 기능은 향후 릴리스에서 다시 제공할 계획이 있음
  • Android 백그라운드 백업은 주기 작업 스케줄러를 사용해 더 안정적으로 동작함
    • 이전에는 새로 촬영한 사진에 제한됐음
    • 이제 전체 라이브러리를 백그라운드에서 업로드할 수 있음
    • Android 백그라운드 실행 제한과 더 잘 맞고, 작업 정리와 배터리 최적화·알림 설정 경고를 처리함
  • iOS 백그라운드 새로고침 작업은 동기화와 업로드를 병렬 실행해, iOS가 허용하는 짧은 시간 안에 업로드가 시작되도록 바뀜

워크플로우 미리보기

  • Workflows는 라이브러리의 동작을 자동화하는 첫 미리보기 기능임
  • 트리거, 필터, 액션을 드래그 앤 드롭 빌더로 연결해 자동화를 만들 수 있음
  • 웹의 Utilities > Workflows에서 접근 가능함
  • 새 빈 워크플로우를 만들거나 미리 만들어진 템플릿을 둘러볼 수 있음
  • 편집기는 Visual editor와 JSON editor를 제공함
    • Visual editor는 워크플로우 구성에 적합함
    • JSON editor는 워크플로우 내용을 다른 사람과 공유하거나 받는 데 적합함
  • 각 워크플로우는 trigger와 일련의 steps로 구성됨
    • Trigger는 워크플로우의 진입점이며, 트리거가 발생하면 단계가 평가됨
    • Steps는 조건에 해당하는 Filters와 효과에 해당하는 Actions를 포함함
  • 공유 방식은 텍스트와 JSON 두 가지임
    • 텍스트는 포럼 공유나 시연용에 적합함
    • JSON은 워크플로우 설정을 정확히 복제하는 데 적합함
  • 새 트리거와 액션 아이디어는 별도 discussion thread에서 피드백을 받음

라이브러리 탐색과 무결성 검사

  • 웹과 모바일에 Recently Added 페이지가 추가됨
    • asset 촬영 시점이 아니라 Immich에 추가된 시점 기준으로 라이브러리를 볼 수 있음
    • 새로 가져온 묶음을 탐색할 때 무엇이 새로 들어왔는지 찾기 쉬움
    • 웹에서는 Explore 탭, 모바일에서는 Search 탭에서 찾을 수 있음
  • 유지보수 페이지에는 integrity reports가 추가됨
    • Immich가 파일 시스템의 디렉터리를 스캔하고 데이터베이스에 저장된 정보와 비교함
    • Immich가 모르는 파일이 디렉터리에 있으면 untracked로 표시됨
    • 데이터베이스에는 참조가 있지만 해당 위치에 파일이 없으면 missing으로 표시됨
    • 디스크 파일 체크섬이 Immich가 저장한 체크섬과 다르면 checksum mismatch로 표시됨
  • 체크섬 불일치는 일반적으로 파일 손상에서 발생할 수 있고, 잘못된 이름 변경의 결과일 수도 있음
  • 무결성 검사 작업은 매일 밤 언제, 얼마나 오래 실행할지 설정할 수 있음

비디오와 미디어 재생

  • 모바일 앱에 Slideshow 기능이 추가되어 웹처럼 사진과 비디오를 화면에서 자동 재생할 수 있음
  • HLS와 실시간 비디오 트랜스코딩은 미리보기 기능으로 추가됨
    • 오프라인 트랜스코드를 미리 만들지 않고 동영상이 재생되는 동안 변환할 수 있음
    • 수동·자동 품질 전환을 지원함
    • 클라이언트가 지원하는 최적 코덱으로 트랜스코딩할 수 있음
    • 오프라인 트랜스코딩을 비활성화하면 저장 공간 부담을 줄일 수 있음
  • 아직 구현되지 않은 항목도 명시됨
    • 호환 클라이언트용 HDR
    • 대역폭이 허용될 때 원본을 트랜스코딩하지 않고 remuxing
  • 실시간 트랜스코딩은 실험적이며 버전마다 동작이 바뀔 수 있음
  • 현재 웹 앱에만 구현되어 있고 모바일 앱 구현은 진행 중임
  • 활성화는 video transcoding settings에서 할 수 있음
  • 실시간 트랜스코딩을 켜도 오프라인 트랜스코딩은 직접 영향을 받지 않으므로, 오프라인 트랜스코딩을 끄려면 transcode policy도 조정해야 함
  • v3 이전에 가져온 asset은 작업 패널에서 Metadata Extraction을 다시 실행해야 재처리됨
  • 서버가 실시간 트랜스코딩을 처리할 만큼 충분히 강해야 하며, 하드웨어 가속은 권장되지만 필수는 아님
  • 웹 앱에는 Immich 디자인에 맞춘 새 커스텀 비디오 플레이어가 추가됨
    • 모든 기기에서 같은 컨트롤과 레이아웃을 제공함
    • 재생 속도 변경 같은 기본 기능을 제공함
    • iOS에서 OS 컨트롤이 Immich 내비게이션 바 뒤에 숨는 문제도 해결할 수 있음

Android, OCR, 공유와 앨범 흐름

  • Android에서 Immich를 갤러리/이미지 뷰어 앱처럼 사용할 수 있음
    • 다른 앱에서 사진이나 비디오를 탭하고 Immich를 선택하면 asset viewer에서 바로 열림
    • 파일 공유 또는 라이브러리 업로드 옵션을 제공함
    • 이미 라이브러리에 있는 파일을 인식하는 방식은 향후 개선될 예정임
  • 모바일 asset viewer에는 사진 속 인식된 텍스트를 강조하는 OCR 토글이 추가됨
    • 이미지에서 텍스트를 선택하고 복사할 수 있음
  • 모바일 앱에서 로컬 사진을 앨범에 직접 업로드할 수 있음
    • asset bottom sheet에서도 앨범에 바로 추가 가능함
    • 먼저 업로드한 뒤 나중에 정리하는 흐름의 마찰을 줄임
  • 모바일 공유 시 전송 전 이미지 크기를 선택할 수 있음
    • 메시징 앱용으로 파일을 작게 유지할 수 있음
    • 필요하면 전체 품질로 공유할 수도 있음
    • 기본 동작은 App Settings > Preferences에서 변경 가능함
    • 공유 버튼을 길게 눌러 즉석에서 옵션을 고를 수 있음
  • 한 달 안에 asset이 많은 경우의 타임라인 탐색 성능이 개선되어, 브라우저 탭이 잠기는 상황을 줄임

주요 변경 묶음

  • Breaking changes에는 class-validator에서 zod로의 마이그레이션, replace asset 제거, 오래된 timeline sync 엔드포인트 제거, pgvecto.rs 지원 중단, 오류 응답 구조 변경 등이 포함됨
  • Deprecated changes로는 PUT 라우트를 PATCH로 대체하는 방향의 deprecation이 포함됨
  • 보안 항목에는 프로필 사진을 thumbnail pipeline을 거치도록 하는 수정이 포함됨
  • 기능 추가에는 모바일 편집, Android periodic work manager task, 커스텀 웹 비디오 플레이어, recently added assets page, workflows & plugins, HLS 실시간 트랜스코딩, 모바일 OCR, 무결성 검사 작업 등이 포함됨
  • 버그 수정에는 OAuth 이메일 정규화, zip에 추가하기 전 파일명 정리, 잠긴 asset의 파트너 노출 방지, 무단 face 생성 수정, CLI 업로드 시 메모리 부족 방지 등이 포함됨

토론에서 확인된 제약과 답변

  • v2.0.1에서 v3.0.0으로 올리는 경우 별도 특별 지침은 없으며 릴리스 노트의 업데이트 절차를 따르면 된다는 답변이 있었음
  • 모바일 업데이트 뒤 앨범이 보이지 않는 사례는 모바일 쪽 마이그레이션 버그로 보였고, 로그아웃 후 재로그인 또는 서버를 v3로 업데이트하면 해결될 수 있음
  • iPhone 백업 복원 뒤 모바일 앱에서 서버에 있는 사진을 다시 로컬로 받는 흐름에 대해, 모바일 앱에는 아직 bulk download 옵션이 없고 개별 사진 다운로드만 가능함
  • 실시간 트랜스코딩을 켠 뒤 기존 트랜스코딩 비디오를 지우는 질문에는, 모바일 앱이 아직 실시간 트랜스코딩을 지원하지 않으므로 기존 트랜스코딩 비디오가 필요하며 수동 삭제는 권장되지 않는다는 답변이 있었음
  • HEIC 사진을 즉석에서 JPG로 변환하는 기능은 계획이 없고, 현재 생성되는 썸네일은 JPEG/WEBP라 모든 브라우저와 클라이언트에 호환된다는 답변이 있었음
  • Android 백그라운드 백업 개선은 100MB 이상 대형 이미지와 Cloudflare 제한 문제를 해결하는 변경이 아니라, 백그라운드 작업이 더 자주 주기적으로 실행되도록 하는 개선임
  • 실시간 트랜스코딩에서 코덱은 서버가 아니라 클라이언트가 선택하며, 서버가 AV1 변형을 광고하면 AV1 디코딩 가능한 클라이언트가 그쪽으로 갈 수 있음
    • 서버가 광고할 코덱과 해상도를 선택하는 설정을 추가할 계획이 있음
  • 캐스팅 개선은 할 일 목록에 있으며, cast 전체를 다시 작성하고 실시간 트랜스코딩도 추가해야 한다는 답변이 있었음
  • 업그레이드 뒤 No vector extension found. Available extensions: vchord, vector 오류를 올린 사용자는 이후 해결됐다고 남김
  • 새 체크섬 불일치 검사에 대해, 과거 Immich 외부에서 업로드된 이미지를 편집한 사용자는 수백 개 checksum mismatch가 생길 수 있어 체크섬 재계산으로 해결하는 기능이 유용하다는 의견이 있었음
  • VectorChord 마이그레이션과 관련해, v1.102 이전 사용자는 DB_DATA_LOCATION opt-in 변경을 놓쳤을 수 있으므로 경고가 있으면 좋겠다는 의견이 있었음

후원과 상품

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 학부생들에게 무료 소프트웨어 개발 수업을 가르치는데, 수업 과제로 만든 작업이 실제 프로젝트에서 발견돼서 정말 신남
    첫 번째로 나열된 버그 수정이 그 학생이 수업 중 Immich에 병합한 세 개의 풀 리퀘스트 중 마지막이라서 뿌듯함

  • 댓글에서 암호화 얘기가 많아 내 구성을 공유함. 약 1년 반 동안 Hetzner 경매 서버에서 가족과 친구용 Immich를 운영해왔음
    Hetzner 커뮤니티에는 공식 전체 디스크 암호화 문서가 있음: https://community.hetzner.com/tutorials/install-debian-with-...
    Letsencrypt로 무료 SSL을 쓰고, Immich는 SSL을 처리하는 Nginx 프록시 뒤에 쉽게 숨길 수 있음
    cron 기반 자동 백업으로 Immich 전체 데이터를 로컬 암호화 NAS에 저장하면 신뢰성 있고, 전송 구간과 저장 상태가 암호화된 구성이 됨. 지금까지 유지보수는 정확히 0번이었음
    IP 수준에서 3개 지역 외 트래픽을 버리기 때문에 더 안전하고, Nginx 프록시에 WAF도 추가할 수 있음
    Google/iCloud보다도 더 안전하다고 보는 이유는 “회사 직원” 공격 벡터가 훨씬 작기 때문임. Google이 사진을 들여다보고 허위 경찰 신고까지 기꺼이 한다는 사례도 문서화돼 있음: https://www.eff.org/deeplinks/2022/08/googles-scans-private-...
    물론 이론적으로 Hetzner 직원이 서버에 물리 접근해 RAM에서 암호화 키를 추출하거나 가짜 SSH 서버로 키를 훔칠 수는 있지만, 훨씬 복잡하고 아직 문서화된 적이 없는 공격이며 탐지될 위험도 있음

    • 언급한 구성은 종단 간 암호화가 아님. 종단 간 암호화는 클라이언트 간 암호화라서 서버는 암호화된 비트만 처리해야 함
      이 구성은 전송 중 암호화와 저장 상태 암호화임. 대형 클라우드 제공자에게 저장 상태 암호화는 상대적으로 덜 중요할 수 있는데, 이들은 대부분의 기업이나 개인보다 디스크 수명주기 관리를 더 잘할 가능성이 큼
      누군가 데이터센터를 물리적으로 털거나, 제대로 처리·삭제되지 않은 리퍼브 드라이브를 얻게 될 가능성은 낮음
      관리형 제공자보다 꼭 더 안전하다고 보기도 어려움. 보안 엔지니어가 아닐 가능성이 높고, 서버를 보호할 자원도 훨씬 적기 때문임
      Google/iCloud가 데이터를 긁어가는 것은 막지만, Hetzner가 데이터에 접근할 수 없다는 뜻은 아님. Hetzner는 서버/VM을 관리하는 상위 하이퍼바이저와 제어 평면을 통제하므로 어떤 기능이 구현돼 있는지 알 수 없음
      정보기관이 할 수 있는 일의 대부분은 유출되거나 공개 문서화되지 않았음
    • 이건 종단 간 암호화가 아님. 디스크가 호스트에 마운트되는 순간 복호화되어 사용 가능해지므로, 본인이나 Hetzner가 가족 데이터에 접근하는 것을 막는 장치가 없음
      진짜 종단 간 암호화라면 가족이 쓰는 클라이언트에서 디스크의 모든 데이터를 암호화해야 하고, 디스크 볼륨을 뒤져도 암호문만 보여야 함
    • 사진 갤러리에는 종단 간 암호화가 필수라고 봄. 서버 설정 오류, 미래의 취약점, 패치되지 않은 소프트웨어로부터 스스로를 보호하는 방법이기 때문임
    • Hetzner에서 저장공간은 얼마나 쓰고, 비용은 얼마나 내는지 궁금함

  • 정말 대단한 소프트웨어이고 Google Photos와 동급임. 홈랩을 시작한 뒤 몇 달 동안 Tailscale 뒤에 두고 써왔는데 아무 문제 없었음
    사실 Google Photos 100GB 저장공간 제한에 걸린 뒤 Immich로 옮긴 것이 셀프 호스팅을 시작한 계기였고, 그 과정이 정말 재미있었음
    이 정도 완성도의 셀프 호스팅 제품이 무료라는 게 믿기지 않음. 같은 이유로 HomeAssistant, PiHole, paperless-ngx, Dawarich와 수많은 프로젝트에도 큰 박수를 보냄
    개인적인 추억을 정리하는 데 도움을 준 팀에게 축하와 감사를 보냄

    • 프로젝트가 마음에 들면 라이선스 구매를 하면 좋겠음. 무료지만 절약한 금액 중 아주 일부로 라이선스를 살 수 있음
    • 지금은 Google Photos보다 낫다고 봄. 팀이 정말 훌륭하고, 범용 사진 앱 중 최고라고 생각하는 앱이 오픈소스라는 사실이 놀라움

  • 여기에는 종단 간 암호화가 없다는 댓글이 많지만, 진지하게 왜 필요한지 모르겠음
    도둑이 들어와 홈랩을 훔쳐 갔다고 해보자. 종단 간 암호화가 없어서 돌아가신 할머니 사진을 볼 수 있다니, 큰일 났네!
    더 가능성 높은 상황은 휴대폰에 문제가 생기는 쪽임. 종단 간 암호화가 없으면 키를 잃어버려도 할머니의 마지막 추억까지 잃는 게 아니라, .jpg 파일을 새 기기로 복사하면 됨

    • 가족이나 친구용 인스턴스를 호스팅할 수 있게 해줌
      다만 일반 사용자에게 종단 간 암호화가 주는 접근성 절충에는 고민이 됨. 이 경우 키나 비밀번호를 잃거나 잊으면 매우 중요한 사진 전체를 잃게 되고, 이는 꽤 치명적임
      Google Photos나 iPhotos는 사람들에게 사진이 안전하다는 느낌을 줌
      또한 원격 서버/VPS의 파일 시스템을 암호화하지 않고도 Immich용 클라우드 인스턴스를 호스팅하기 쉬워짐. 특히 소규모 판매자에게 서버를 빌릴 때는 직원 접근 통제를 얼마나 믿을 수 있는지 늘 조심스러움
      물리 접근이 있으면 어느 정도 신뢰가 불가피하다는 건 알지만, 유지보수 중 디스크를 어떻게 다루는지도 중요함
    • 종단 간 암호화의 핵심은 클라우드 제공자에게 호스팅하더라도 제공자가 데이터를 볼 수 없게 하는 것이라고 봄. Proton Drive가 어떤 파일을 갖고 있는지 모른다고 주장하는 것과 비슷함
      이렇게 되면 의미 기반 검색, 얼굴 인식, 비디오 트랜스코딩, 썸네일 생성 같은 기능은 클라이언트로 옮겨야 함
      Immich는 서버가 사진에 접근할 수 있다고 신뢰하는 전제를 둠. 셀프 호스팅에서는 항상 그런 구조임
      대부분의 사용자가 Google과 Apple에도 그런 신뢰를 주고 있으니 합리적이라고 봄
    • 모든 사진이 민감하지 않다고만 볼 수는 없음
      진짜 종단 간 암호화 아키텍처라면 클라우드 저장소, 관리형 호스팅, 오프사이트 백업을 더 유연하게 쓸 수 있을 것 같음
    • Immich에서는 애플리케이션 계층이 암호화에 맞는 계층이 아니라고 봄. 그냥 서버 전체 디스크를 암호화함
      셀프 호스팅이라면 운영자가 파일에 접근하지 못하게 막을 필요가 없음
    • 동의함. 예전에는 사진 앨범을 찬장에 보관했고, 집이 불타면 타버리고 보일러가 고장 나면 물에 젖고 심지어 도난당하기도 했음
      이제는 디지털로 보관하고 외부에 백업할 수 있음. Immich에서 필요한 변화는 그 정도면 충분함
      전부 완전 암호화하면 오히려 더 많은 문제를 초대하는 셈임

  • iOS에서 GrapheneOS로 옮기면서 사진을 셀프 호스팅하기로 했고, Immich도 검토했지만 암호화 때문에 Ente를 선택함
    Ente Photos는 매우 다듬어져 있고 Apple Photos와 견줄 만한 품질임
    많은 종단 간 암호화 프로젝트처럼 클라이언트만 열어두는 대신 서버도 공개하고 셀프 호스팅 가능하게 유지하는 점이 좋음
    계정 없이도 누구나 앨범에 기여할 수 있게 공유할 수 있고, 휴대폰을 다른 사람에게 건넬 때 선택한 사진만 보이도록 잠글 수 있는 기능도 마음에 듦

    • “Ente Photos는 매우 다듬어져 있고 Apple Photos와 견줄 만한 품질”이라는 말에는 동의하기 어려움
      셀프 호스팅 기준으로 사진 업로드조차 안정적으로 못함. 며칠 동안 아무것도 업로드하지 못한 적이 있었고, 진단 정보도 없어 직접 빌드하고 디버깅해야 했음
      앱을 전면에 두고 충전기에 꽂아 몇 시간씩 유지했으며, 동영상 업로드와 기계학습 기능을 모두 꺼서 사진에만 집중하게 했는데도 그랬음
      서버 쪽은 괜찮고 웹 업로드는 문제없이 되는데 앱만 안 됨. 아직 원인을 못 찾았음
    • 궁금한 사람들을 위해 적으면, “Ente Photos는 유료 서비스지만 10GB 무료 저장공간을 제공함. 이 저장소를 복제해 셀프 호스팅할 수도 있음”
      즉 두 형태가 모두 가능함
      https://github.com/ente/ente
    • Ente Auth도 최고임. 접근하려는 바로 그 기기를 포함해 어떤 기기에서도 동작하기 때문임
      어쩌면 2단계 인증의 목적을 약화시키는 셈일 수 있지만, 가끔은 별로 신경 쓰지 않음
    • 이벤트별로 사진 업로드 링크를 만들고 싶어서 Ente를 쓰기 시작함. 친구들에게 “오늘 밤 사진이나 영상을 찍으면 이 URL로 올려줘”라고 말하면 그냥 동작함
      앱이 필요 없고, 매우 단순하고, 아주 저렴함. 그다음에는 사진 백업/아카이브 서비스도 쓰게 됐음
      겉으로 보이는 그대로인 서비스라서 팬이 됨

  • Immich는 Apple Photos나 Google Photos를 대체하기에 너무 자연스러운 선택임. Tailscale 같은 VPN과 함께 쓰면 거의 그대로 갈아끼울 수 있음

    • Immich에서 iCloud/Google로 다시 이전하는 건 Immich가 신경 쓰는 영역이 아니니 주의해야 함. 어디에도 “전체 다운로드”가 없고, 가장 좋은 방법은 서버에 들어가 원본 파일을 가져오는 것임
      https://github.com/immich-app/immich/discussions/14365
    • Immich를 공개로 두면 부작용이 있는지 궁금함. 위험을 과대평가하는 경우가 많다고 생각함
      정기적으로 업데이트하고, 간단한 규칙을 따르고, CrowdSec 같은 것을 설정하면 됨
      Tailscale 같은 도구를 쓰는 게 더 단순한 건 알지만, 요즘은 그 외의 선택지를 아예 고려하지 않는 흐름이 보임
    • photoprism을 쓰고 있는데, 갈아타야 할지 궁금함
    • 중첩 앨범이나 폴더 안 앨범을 지원하면 Lightroom Cloud도 쉽게 대체할 수 있을 텐데 아쉬움
      내 사진은 events -> year/month - holiday -> (album_1, ...), home town -> year -> (album_1, ...)처럼 정리돼 있음
      사진은 여러 앨범에 들어갈 수 있고 편집본도 있으며, 선택/거절 상태도 추적하고 필터링해야 함
      아직 Immich로 옮기지 못한 유일한 이유는 내 사진 정리 방식을 Immich의 방식에 보기 좋게 매핑하는 데 어려움을 겪고 있기 때문임. 지금까지의 시도는 다루기 불편했음
    • 휴대폰을 하루 종일 Tailscale VPN에 연결해 두면 부작용이 있는지 궁금함

  • 종단 간 암호화 부재보다 더 불만인 점이 있음. Google Photos나 iCloud 같은 다른 서비스에서 가져오기를 쉽게 만들지 않았는데, 이게 우선순위여야 한다고 봄
    Immich는 immich-go 프로젝트에 의존하는데, 버그가 많고 사실상 방치된 상태임
    자체 iOS 앱도 iCloud 갤러리 동기화에 쓸 수 있지만, 약 2년 된 미해결 버그 때문에 Live Motion 사진 업로드에 실패함
    Immich로 내보낸 사진 중 약 9000개가 깨졌거나 반쯤만 가져온 Live Photos이고, 이를 고칠 시간이 없음
    이게 우선순위가 아니라는 사실을 이해할 수 없음. 가장 철저하게 A/B 테스트되어야 할 기능인데 말임
    가져온 추억을 망가뜨리지 않았다고 믿을 수 없다면 OCR이 무슨 의미가 있는지 모르겠음

    • 오픈소스에서는 자원봉사 개발자들이 재미있거나 자기 문제를 해결하는 일에 집중하는 경우가 많음
      Google Photos의 반쯤 망가진 내보내기를 다루는 일이 누구에게 재미있을 것 같지는 않고, 가져오기 고통은 한 번만 겪고 나면 더 이상 긁어야 할 가려움도 사라짐
    • 여기서 보이는 권리 의식이 놀라울 정도임
    • 비슷한 상황에서 지난주 Google Takeout으로 사진/동영상 1만 2천 개를 Immich로 이전했음
      Ceph를 백엔드로 둔 Immich를 설정했고, immich-go로 모든 메타데이터와 앨범까지 전부 옮겼음
      병렬화 옵션을 조금 바꿔야 했지만 그 외에는 아주 쉬웠음
    • 그런 서비스들은 닫힌 블랙박스라서 아주 우회적인 방식 말고는 제대로 접근하게 해주지 않기 때문 아님?

  • 설정에 엄청 시간을 들이고 한 번 쓰고 다시 안 쓰는 것도 많고, 설정은 쉬우면서 매일 조금씩 이득을 주는 것도 많음
    Immich는 설정에 오래 걸렸고 아주 드물게 쓰지만, 1년에 한 번 쓸 때마다 설치해두길 정말 잘했다는 생각이 드는 소프트웨어임

    • 내 경우에는 설정에는 그리 오래 걸리지 않았고, 가끔 깨지는 변경 때문에 수동 작업을 하며 업그레이드에 시간을 조금 썼지만 자주 있는 일은 아니었음
      매주 쓰고 있고 그냥 잘 동작해서 훌륭함
    • 내 경험도 그랬으면 좋았겠음. Proxmox LXC로 썼는데 2개월 동안 정리한 뒤 데이터 손상이 생겼고, 디버깅을 끝까지 할 기운이 없었음
      기억상 큰 버전 이전과 관련 있었을 수 있음. 그 뒤로 이 스택에 마음이 식었음
      업그레이드가 원하는 만큼 손쉬운 방식이 아니었고, 지금도 크게 다르지 않을 것 같음
      멍청한 라이브러리 시스템 밖에서 폴더를 정리하고 싶을 뿐인데, 당시 Immich는 그 방식과도 잘 맞지 않았음

  • iOS 사진 동기화가 나아졌는지 궁금함. 휴대폰에 사진이 2만 장 있는데, 마지막으로 시도했을 때 원본으로 휴대폰 저장공간이 가득 찼고, 며칠 동안 같은 로컬 네트워크에서 휴대폰을 열어 잠금 해제한 채 Immich 앱을 전면 실행해도 끝나지 않았음
    작업 중이라는 건 알지만 따라가 보진 못했음. 지금은 더 잘 동작해서 다시 시도해볼 만한지 알고 싶음

    • 릴리스 노트에는 이렇게 되어 있음
      “iOS에서 백그라운드 새로고침 작업이 이제 동기화와 업로드를 병렬로 실행하므로, iOS가 허용하는 짧은 시간 창 안에서 실제로 업로드가 시작됨”
      다만 이게 그 문제를 고치는지는 모르겠음
    • 2월에 휴대폰에서 약 9000장을 동기화했는데 꽤 잘 됐음. 약 10시간 만에 끝났음
      원본이 다운로드됐는지, 이후 자동으로 삭제됐는지는 기억나지 않지만 전체 과정은 매끄럽게 느껴졌음
    • 대용량 파일 업로드는 이어서 올릴 수 없음. 적당한 비트레이트와 해상도의 동영상이 있으면 한 세션 안에서 파일 전체를 올릴 수 있어야 함
      iOS는 백그라운드 업로드로 이걸 쉽게 해주지 않음. 앱을 밤새 열어둬서 전부 업로드했음
    • Immich 문제라기보다 iOS 문제일 가능성이 큼. Apple은 iCloud를 떠나기 쉽게 해주는 앱을 반기지 않음

  • “모바일 앱에서 에셋을 앨범에 직접 업로드”가 이 문제를 고치는 건지 궁금함: https://github.com/immich-app/immich/discussions/12748
    여러 기기와 여러 사람이 고양이 사진을 한 앨범에 모으고 싶어서 나에게는 꽤 큰 문제임
    현재는 이런 식으로 구성해야 함. Syncthing으로 사진을 Immich를 호스팅하는 홈랩 서버의 /mnt/Syncthing/a1/cats/, /mnt/Syncthing/a2/cats/, /mnt/Syncthing/b/cats/에 동기화함
    cron 작업으로 사진을 읽기 전용 외부 라이브러리 볼륨으로 마운트된 /mnt/immich/ext-lib/cats/ 폴더에 하드링크 복사함
    또 다른 cron 작업으로 외부 라이브러리 폴더 구조에서 앨범을 자동 생성하는 스크립트 https://github.com/Salvoxia/immich-folder-album-creator를 실행함
    마지막으로 휴대폰 공간 확보를 위해 Syncthing 폴더에서 1년이 지난 사진을 정리하는 cron 작업을 돌림. 전체가 약 1TB라, 문제가 있긴 함
    그래도 3.0 릴리스는 축하함. 다만 이 프로그램을 한 달 전에야 발견했고, 셀프 호스팅 구성을 일주일 전에야 안정화했기 때문에 조금 아쉽긴 함

답변달기