시놀로지 나스에 Immich 설치하기: 컨테이너 매니저 활용

Immich는 구글 포토(Google Photos)를 대체할 수 있는 대표적인 오픈소스 사진·영상 관리 솔루션입니다. 사진과 영상을 웹과 모바일 앱에서 관리할 수 있고, 자동 백업, 앨범 공유, 얼굴 인식, 메타데이터 검색, 지도 보기, 썸네일 생성, 영상 트랜스코딩 등 구글 포토에서 기대하는 기능 상당수를 셀프호스팅 환경에서 구현할 수 있습니다.

구글 포토가 편리하긴 합니다. 하지만 오랫동안 SaaS(서비스형 소프트웨어) 서비스에 사진과 영상을 맡기다 보면 계정, 요금제, 정책, 내보내기 방식에 의존하게 됩니다. 구글 테이크아웃(Takeout) 같은 내보내기 기능이 있더라도, 오랜 기간 쌓인 사진·영상·공유 앨범·메타데이터를 원래 의도한 구조 그대로 이전하는 작업은 생각보다 번거롭습니다. 구글 포토를 기반으로 여러 사람들과 사진을 공유하고 저장하다 보면 실제 그 중 어느 것이 내 소유의 데이터인지 구분하기 힘들어지고, 모든 데이터를 내보내는 건 사실상 불가능해집니다.

특히 사진처럼 오랜 기간 동안 원본 그대로를 보관해야 하는 데이터는 가능하다면 내가 관리하는 저장소 위에서 운영하는 방식을 지향해야 합니다. 시놀로지 나스(Synology NAS)를 이미 사용 중이라면 Immich는 꽤 매력적인 선택지이고, 없더라도 이것을 위해 구매하시는 분들도 있을 정도로 괜찮은 방향입니다.(관련 포스트 구독료 지옥에서 탈출하기: 온프레미스와 셀프호스팅의 결합)

다만 이 포스트에서는 Immich를 처음부터 모든 원본의 1차 저장소로 사용하는 방식보다, 기존 나스 사진 폴더를 외부 라이브러리로 읽어오는 방식을 우선 권장합니다. 이렇게 구성하면 원본 사진·영상 폴더는 그대로 유지하면서 Immich의 검색, 썸네일, 얼굴 인식, 웹 UI, 공유 기능을 함께 활용할 수 있습니다.

이 글에서 구성할 방식

이 글에서는 다음 구성을 기준으로 설명합니다.

설치 전 확인 사항

Immich는 단순 사진 뷰어가 아니라 업로드된 영상과 사진을 분석하고 썸네일 생성, 트랜스코딩, 얼굴 인식 및 OCR 기능 등을 합니다. 따라서 나스의 사양과 저장소 구성을 먼저 확인해야 합니다.

나스 사양

Immich 공식 요구 사양 기준으로 RAM은 최소 6GB, 권장 8GB입니다. CPU는 최소 2코어, 권장 4코어입니다.

시놀로지 나스 중에는 컨테이너 매니저는 설치되지만 기본 RAM이 2GB 또는 4GB인 모델도 많습니다. 이런 모델에서도 Immich를 띄우는 것 자체는 가능할 수 있지만, 머신러닝 기능이나 대량 사진 스캔을 켜면 매우 느려지거나 메모리 부족 문제가 발생할 수 있습니다.

저장 공간

Immich는 원본 사진과 영상 외에도 다음 데이터를 저장합니다.

• 썸네일과 미리보기 이미지
• 얼굴 인식 및 검색 관련 데이터
• 트랜스코딩(재인코딩)된 영상 파일
• 프로필 이미지
• 데이터베이스 백업 파일
• PostgreSQL 데이터베이스

특히 썸네일과 트랜스코딩 영상은 원본 라이브러리 크기에 따라 꽤 많은 공간을 사용할 수 있습니다. 공식 문서에서는 썸네일과 트랜스코딩 파일이 사진 라이브러리 용량의 약 10~20% 정도를 추가로 사용할 수 있다고 안내합니다.

따라서 UPLOAD_LOCATION에는 원본 업로드 파일뿐 아니라 썸네일, 인코딩 영상, DB 백업까지 저장될 수 있다는 점을 고려해야 합니다.

데이터베이스 위치

Immich의 PostgreSQL 데이터베이스는 서비스 안정성에 매우 중요한 역할을 합니다. 가능하다면 데이터베이스 경로인 DB_DATA_LOCATION은 로컬 SSD 볼륨에 두는 것이 좋습니다.

HDD 볼륨에서도 사용할 수는 있지만, 대량 스캔이나 검색 작업에서 DB I/O 병목이 생길 수 있습니다. 반대로 네트워크 공유 경로에 데이터베이스를 두는 방식은 권장하지 않습니다.

폴더 구조 준비

이 글에서는 docker 공유 폴더 아래에 Immich 프로젝트 폴더를 만드는 방식으로 진행합니다.

예시는 다음과 같습니다.

/volume1/docker/immich-app
├── docker-compose.yml
├── .env
├── library
└── postgres

각 폴더의 역할은 다음과 같습니다.

.env 파일 준비

공식 예시를 기준으로 .env 파일을 준비합니다. 아래 다운로드 버튼으로 다운로드하여 프로젝트 폴더에 미리 저장해 주세요.

위 .env 파일을 내려받은 다음 반드시 바꿔야 할 값은 DB_PASSWORD입니다.

DB_PASSWORD는 Immich가 PostgreSQL 데이터베이스에 접속할 때 사용하는 인증 암호입니다. 기존에 작성되어있는 내용이 아닌, 충분히 긴 임의 문자열로 변경해야 합니다.

IMMICH_VERSION은 원하는 버전대로 고정을 하거나 버전 정책을 정할 때 사용합니다. 현재 지정된 release 값은 릴리스된 최신 버전을 사용한다는 의미입니다. 만약 특정 버전으로 고정하려면 아래처럼 작성할 수 있습니다.

IMMICH_VERSION=v2.7.5

특정 버전으로 고정하면 패치 업데이트도 자동으로 따라가지 않지만, 잘 작동하는 것을 확인한 기존 버전에서 기능이 변경되지 않게 사용할 수 있으므로 안정적입니다. v2와 같이 2.x.x 버전대 안에서만 업데이트를 하도록 하여 향후 출시된 v3.0.0 으로의 업데이트를 막는 것도 가능합니다. 단, 서버 버전을 오래 고정해 두면서 모바일 앱만 계속 최신으로 업데이트하면 일부 기능에서 호환성 문제가 생길 수 있습니다. 일반 사용자라면 서버와 모바일 앱을 모두 최신 릴리스에 가깝게 유지하고, 서버 업데이트 전 릴리스 노트와 백업 상태를 확인하는 방식을 권장합니다.

컨테이너 매니저에서 프로젝트 생성

아직 시놀로지 나스에 컨테이너 매니저가 설치되어 있지 않다면 패키지 센터에서 먼저 설치합니다.

시놀로지 나스에서 컨테이너 매니저 설치 및 실행

기준:

Synology DSM 7.3

펼쳐서 보기

시놀로지 나스에 컨테이너 매니저를 설치하려면 먼저 패키지 센터 앱을 켜 주어야 합니다. 해당 앱의 검색창에 Container Manager를 키워드로 검색합니다.

결과로 Container Manager(Docker Inc. 개발, Synology Inc. 게시)가 나올텐데, 설치를 누른 후, 설치가 완료되어 열기 버튼이 활성화되면 눌러서 열어줍니다.

컨테이너 매니저를 처음 실행하면 좌측에 여러 메뉴 탭이 보이는데요, 주요 메뉴는 다음과 같습니다.

• 개요: 현재 실행중인 컨테이너들과 프로젝트 상태 요약
• 프로젝트: 도커 컴포즈 기반 앱 관리
• 컨테이너: 단일 도커 컨테이너 앱 관리
• 이미지: 각 도커 이미지 상태 및 업데이트 관리
• 레지스트리: 도커 허브(Docker Hub) 등 외부 이미지 저장소 검색
• 네트워크: 각 컨테이너나 프로젝트에서 사용하는 네트워크 설정
• 로그: 컨테이너 매니저의 동작 로그(이 앱의 GUI를 통한 활동만 기록합니다)

다른 메뉴는 사실 잘 만질 일이 없고, 프로젝트 메뉴가 아마 저희가 가장 많이 사용할 메뉴가 될 겁니다. 대부분의 셀프호스트 서비스들은 도커 컴포즈를 기반으로 배포되기 때문입니다.

원본 가이드에서 전체 내용 확인하기→

컨테이너 매니저 설치가 끝났다면 좌측 메뉴의 프로젝트로 이동합니다. 해당 메뉴에서 [생성] 버튼을 누릅니다.

일반 설정

프로젝트 생성 창이 나타나면 다음처럼 설정합니다.

이후 아래 도커 컴포즈 내용을 입력합니다.

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    volumes:
      # 미디어 저장 위치를 바꾸려면 이 줄을 직접 수정하지 말고 .env 파일의 UPLOAD_LOCATION 값을 변경합니다.
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro

      # 외부 라이브러리 예시입니다.
      # 왼쪽은 나스의 실제 경로, 오른쪽은 Immich 컨테이너 내부에서 보이는 경로입니다.
      # :ro는 읽기 전용 마운트입니다. 원본 보호를 위해 유지하는 것을 권장합니다.
      - /volume1/photo:/mnt/media/exphotos:ro
    env_file:
      - .env
    ports:
      - '2283:2283'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    # 하드웨어 가속을 사용하려면 공식 문서의 ml-hardware-acceleration 가이드를 확인한 뒤
    # 이미지 태그 뒤에 -openvino, -cuda, -rocm, -rknn 등 환경에 맞는 옵션을 붙입니다.
    # 시놀로지 나스에서는 모델과 CPU에 따라 지원 여부가 다르므로 잘 모르실 경우 기본 구성으로 진행합니다.
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:9@sha256:3b55fbaa0cd93cf0d9d961f405e4dfcc70efe325e2d84da207a0a8e6d8fde4f9
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'

      # 데이터베이스 저장소가 SSD가 아니라 HDD라면 아래 줄의 주석을 해제합니다.
      # DB_STORAGE_TYPE: 'HDD'
    volumes:
      # 데이터베이스 저장 위치를 바꾸려면 이 줄을 직접 수정하지 말고 .env의 DB_DATA_LOCATION 값을 변경합니다.
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    shm_size: 128mb
    restart: always
    healthcheck:
      disable: false

volumes:
  model-cache:

위 도커 컴포즈 구성은 Immich 서버, 머신러닝, Valkey, PostgreSQL 컨테이너를 함께 생성합니다.

웹 포털 설정

다음 단계의 웹 포털 설정에서는 아무 항목도 선택하지 않고 넘어갑니다.

Immich와 같은 도커 컴포즈 기반 앱들의 경우 Web Station 포털보다 DSM의 역방향 프록시 또는 VPN을 통해 접근하는 편이 운영 관리 측면에서 더 깔끔합니다.

요약 확인 및 프로젝트 시작

마지막 요약 화면에서 설정값을 확인한 뒤 프로젝트가 생성되면 프로젝트 시작을 체크하고 완료합니다.

컨테이너 매니저가 필요한 이미지를 다운로드하고 컨테이너를 생성합니다. 모든 과정이 끝난 뒤 로그에 아래와 비슷한 내용이 보이면 정상적으로 시작된 것입니다.

...
Container immich_redis Started
Container immich_postgres Started
Container immich_machine_learning Started
Container immich_server Started
Exit Code: 0

설치 직후에는 컨테이너가 정상적으로 시작되더라도 PostgreSQL 초기화와 서버 준비에 약간 시간이 걸릴 수 있습니다.

첫 접속과 관리자 계정 생성

설치가 완료되면 나스의 내부 아이피와 2283번 포트로 Immich에 접속할 수 있습니다.

예를 들어 나스의 내부 아이피가 192.168.0.99라면 다음 주소로 접속합니다.

http://192.168.0.99:2283

처음 접속하면 관리자 계정을 생성하는 화면이 나타납니다. 첫 번째로 생성한 사용자가 관리자 계정이 됩니다.

관리자 계정은 다음 용도로 사용됩니다.

• 사용자 생성 및 관리
• 외부 라이브러리 생성
• 시스템 설정 변경
• 작업 대기열 확인
• 백업 및 복구 작업
• 저장소 템플릿 설정
• OAuth 등 인증 설정

DSM 방화벽 확인

DSM 방화벽을 사용 중이라면 Immich 접속이 막힐 수 있습니다.

내부망에서 http://NAS_IP:2283 접속이 되지 않는다면 다음 항목을 확인합니다.

• DSM 방화벽에서 2283 포트가 허용되어 있는지
• 컨테이너 매니저 프로젝트가 정상 실행 중인지
• immich_server 컨테이너 로그에 오류가 없는지
• 브라우저에서 https가 아니라 http로 접속하고 있는지

방화벽의 경우 일반적으로는 본인이 아는 범위 밖으로는 건드리지 않는 경우가 많습니다만, 기존 나스 관리자가 다른 사람이었다면 이 부분도 확인해볼 필요가 있습니다.

웹 공개 전 보안 판단

Immich를 외부 인터넷에 공개하면 모바일 앱 자동 백업, 외부 앨범 공유, 공유 링크, 비가입자 업로드 같은 기능을 편하게 사용할 수 있습니다. 하지만 해킹 등의 위험이 내부망에서만 사용할 때와 비교해서 크게 올라갑니다.(Immich 개발자들과 시놀로지 DSM 개발자들 역시 주기적으로 보안 업데이트를 하겠습니다만, 그것으로 충분하다고는 할 수 없습니다)

안전한 방식은 Immich를 인터넷에 직접 공개하지 않고 WireGuard, Tailscale 같은 VPN으로 접속하는 것입니다.

DSM 역방향 프록시 설정

웹 공개를 위해 DSM의 역방향 프록시 기능을 사용할 수 있습니다.

시놀로지 DSM에서 역방향 프록시 설정하기

기준:

Synology DSM 7.3

닫기

역방향 프록시를 설정하기 위해서는 먼저 DSM에 관리자 계정으로 접속한 다음, 제어판에 접속해야 합니다.

제어판의 메뉴를 클릭하면 로그인 포털이라는 메뉴가 보입니다.

로그인 포털 메뉴를 클릭한 뒤, 고급 탭으로 이동합니다.

그러면 역방향 프록시라는 항목과 버튼이 보일텐데, 이것을 눌러줍니다.

역방향 프록시 창의 [생성] 버튼을 누르면 새로운 역방향 프록시 규칙을 지정할 수 있게 됩니다.

일반 탭에는 다음과 같은 항목들이 있습니다.

구분	항목	설명
	역방향 프록시 이름	관리용 식별 이름 (외부에 노출되지 않습니다)
소스	프로토콜	HTTP(암호화 없음), HTTPS(암호화) 프로토콜 중 선택
소스	호스트 이름	외부에서 접속할 도메인 주소
소스	포트	외부에서 접속할 포트(HTTPS 기본 포트는 443)
소스	HSTS 활성화	HTTPS 강제 적용(보안을 위해 활성화)
대상	프로토콜	서비스에서 사용중인 프로토콜
대상	호스트 이름	서비스를 제공하는 주소(도메인 혹은 아이피, localhost 등)
대상	포트	해당 서비스가 실제로 사용하는 포트 번호

NOTE

여기에서 소스 호스트 이름으로 사용하는 도메인 주소는 A Record 값이 나스의 외부 IP 주소로 향해있거나, CNAME 값을 나스에 연결된 도메인으로 연결해 두어야 합니다. [제어판] - [보안] - [인증서] 탭에 해당 도메인을 포함하는 인증서가 존재해야 하며, 인증서 페이지의 [설정] 버튼을 눌러 해당 서비스에 연결되는 인증서가 올바르게 설정되었는지 확인해야 합니다.

원본 가이드에서 전체 내용 확인하기→

역방향 프록시의 [일반] 탭에서는 다음과 같이 설정합니다.

사용자 지정 머리글

사용자 지정 머리글 탭으로 이동해 [생성] → [WebSocket]을 선택합니다.

그러면 다음 항목이 자동으로 추가됩니다.

WebSocket 설정이 빠지면 모바일 앱이나 웹 UI에서 서버 상태가 Offline으로 보이거나, 일부 실시간 기능이 정상 동작하지 않을 수 있습니다.

그 외 Immich에서는 Nginx 기준 몇가지 설정 추가를 필요로 하는데, 시놀로지 나스에서는 직접 수정이 어렵기도 하거니와 대부분의 설정이 충분히 미리 설정되어 있습니다.

이렇게 모두 설정했다면 역방향 프록시를 저장하여 웹 개방을 할 수 있습니다.

사용자와 저장 위치 이해하기

Immich에 로그인한 뒤 우측 상단 프로필 메뉴에서 관리 화면으로 이동하면 사용자, 외부 라이브러리, 작업 대기열, 시스템 설정 등을 관리할 수 있습니다.

Immich의 사용자는 DSM 사용자와 별개입니다. Immich 안에서 만든 각 사용자는 자신의 라이브러리와 업로드 공간을 가집니다.

직접 업로드한 사진과 영상의 저장 위치는 스토리지 템플릿 설정 여부에 따라 달라집니다.

기본값에서는 UPLOAD_LOCATION/library 폴더가 사용되지 않을 수 있습니다. 스토리지 템플릿을 활성화하면 업로드 파일이 UPLOAD_LOCATION/library/<userID> 아래로 이동합니다. 즉 기본값인 ./library가 UPLOAD_LOCATION이라면 Immich 프로젝트 폴더의 /library/library/<userID>가 각 사용자가 업로드한 자산의 저장 위치가 됩니다.

외부 라이브러리 설정

이 글에서 가장 권장하는 운영 방식은 외부 라이브러리입니다.

외부 라이브러리는 Immich 프로젝트 폴더 안에 사진을 새로 업로드하는 방식이 아니라, 나스에 이미 존재하는 사진·영상 폴더를 Immich가 읽어와서 라이브러리로 보여주는 기능입니다.

예를 들어 기존에 시놀로지 포토(Synology Photos)나 SMB 업로드로 /volume1/photo에 사진을 저장하고 있었다면, 해당 폴더를 Immich 컨테이너에 읽기 전용으로 마운트한 뒤 Immich에서 스캔할 수 있습니다.

이 방식의 장점은 다음과 같습니다.

• 기존 원본 폴더 구조를 유지할 수 있음
• Immich가 원본 파일을 직접 소유하지 않아도 됨
• 읽기 전용 마운트로 원본 훼손 위험을 줄일 수 있음
• 시놀로지 포토와 병행 운영하기 쉬움
• Immich의 검색, 얼굴 인식, 썸네일, 지도 보기 기능을 활용할 수 있음

사실 시놀로지 포토 역시 완벽히 잘 작동하는 것은 아닙니다. 최신 파일 포맷을 (아마도 라이선스 문제로)지원하지 않는 경우가 많고, 또 일부 영상은 트랜스코딩 시 물 빠진 색감이 되는 등 구조적으로 몇가지 문제들이 있습니다. 그래서 제가 현재 선호하는 방식은 시놀로지 포토 모바일 앱을 통해 사진을 백업하고, 모바일 기기가 아닌 다른 기기를 통해 촬영한 사진이나 영상은 SMB를 통해 직접 라이브러리 폴더에 업로드하며, Immich에서는 그것을 읽기전용으로 불러와서 사용하는 것입니다.

아래에도 언급하겠지만 Immich가 모바일 앱 백그라운드 백업을 조금 더 잘 지원해주면 완전히 넘어갈 수도 있을 듯한데, 아직은 시기가 아닌 것 같습니다.

외부 라이브러리 경로 확인

앞서 도커 컴포즈에 아래 줄을 넣었습니다.

- /volume1/photo:/mnt/media/exphotos:ro

이 뜻은 다음과 같습니다.

Immich 관리 화면에는 나스 실제 경로인 /volume1/photo가 아니라, 컨테이너 내부 경로인 /mnt/media/exphotos를 입력해야 합니다.

외부 라이브러리 생성

Immich 웹 UI에서 다음 순서로 이동합니다.

1. 우측 상단 프로필 클릭
2. 관리 클릭
3. 좌측 외부 라이브러리 메뉴 이동
4. 우측 상단 새 라이브러리 클릭
5. 소유자 선택
6. 좌측 폴더 추가
7. /mnt/media/exphotos(.yaml에 입력한 외부 라이브러리의 Immich용 경로) 입력
8. 제외 패턴(아래에서 설명) 추가
9. 스캔 실행

시놀로지 나스의 권장 제외 패턴

시놀로지 나스에서는 시스템 메타데이터 폴더, 휴지통, 스냅샷 관련 폴더가 함께 스캔되지 않도록 제외 패턴을 넣는 것이 좋습니다.

**/\@eaDir/**
**/._*
**/#recycle/**
**/#snapshot/**

@eaDir은 Synology가 썸네일이나 메타데이터 처리를 위해 생성하는 폴더입니다. Immich에서 사진 라이브러리로 가져올 필요가 없으므로 제외하는 것이 좋습니다.

읽기 전용 마운트를 하는 이유

이 글에서는 외부 라이브러리를 :ro로 마운트합니다.

- /volume1/photo:/mnt/media/exphotos:ro

이렇게 하면 Immich가 해당 폴더를 읽을 수는 있지만, 원본 파일을 수정하거나 삭제할 수 없습니다. 원본 보호 측면에서는 이 구성이 가장 안전합니다.

반대로 Immich에서 외부 라이브러리 원본 파일을 삭제하거나, XMP sidecar 같은 메타데이터 쓰기 기능까지 사용하려면 :ro를 제거해야 합니다. 하지만 그렇게 하면 Immich UI에서의 삭제나 편집이 실제 원본 파일에 영향을 줄 가능성이 있습니다.(기본적으로 Immich는 비파괴를 우선적으로 지향한다고 하지만, 시스템 상으로 막아놓는 것이 안전합니다)

외부 라이브러리 삭제와 재스캔 동작

외부 라이브러리는 Immich 내부 업로드 저장소와 동작 방식이 다릅니다.

외부 라이브러리의 원본 파일이 나스에서 삭제된 뒤 라이브러리를 다시 스캔하면, Immich는 해당 자산을 휴지통으로 이동합니다. 여기서 휴지통으로 이동시킨다는 건 해당 파일 자체가 아니라 그 파일에 저장된 메타데이터나 썸네일, 트랜스코딩된 비디오 데이터 등입니다. 이후 일정 기간(기본값은 30일)이 지나면 Immich 내부 메타데이터도 정리됩니다.

또한 외부 라이브러리 안에서 파일을 다른 폴더로 옮기면 Immich는 기존 자산이 사라지고 새 자산이 추가된 것으로 인식할 수 있습니다. 이 경우 Immich 안에서 추가한 설명, 앨범 연결, 일부 메타데이터가 유지되지 않을 수 있습니다. 특히 많은 자산이 있는 폴더 자체를 옮기면 대량 트랜스코딩, 썸네일 생성 작업이 다시 이루어질 수 있으니 주의해야 합니다.

모바일 앱 백업 설정

Immich 모바일 앱은 iOS와 안드로이드에서 사용할 수 있습니다. 앱을 설치한 뒤 서버 주소를 입력해 로그인하면 자동 백업을 설정할 수 있습니다.

내부망 혹은 VPN을 통해서 접속한다면 서버 주소는 다음과 같은 형태입니다.(물론 이렇게 할 경우 VPN을 켜거나 집 안의 Wi-Fi에 연결된 상황에서만 연결이 가능합니다)

http://192.168.0.99:2283

역방향 프록시로 외부 공개를 했다면 다음처럼 입력합니다. 이렇게 연결하면 내/외부 관계없이 접속이 됩니다.

https://immich.nasid.synology.me

모바일 앱에서는 우측 상단의 백업 아이콘을 눌러 백업할 앨범을 선택할 수 있습니다. 저는 개인적으로 잡다한 스크린샷 같은 게 백업되는 걸 원하지 않기 때문에 안드로이드 갤럭시 기준으로는 /DCIM/Camera 폴더만을 백업하는 걸 선호합니다.

다만 모바일 백업은 운영체제의 백그라운드 실행 정책, 배터리 최적화, 네트워크 상태, 앱 실행 주기 영향을 받습니다. 특히 iOS와 안드로이드 모두 앱을 장기간 열지 않으면 백그라운드 업로드가 기대만큼 안정적으로 돌지 않을 수 있습니다.

백업 전략

Immich를 운영할 때 가장 중요한 부분은 백업입니다.

RAID는 장애 대응에 도움이 되지만 백업 그 자체는 아닙니다. 실수로 삭제한 파일, 랜섬웨어, 잘못된 업데이트, DB 손상, 나스 자체 고장에 대비하기 위해 별도 백업이 필요합니다.

무엇을 백업해야 하나

구성 방식에 따라 백업 대상이 달라집니다.

Immich 데이터베이스에는 사용자 정보, 앨범, 메타데이터, 파일 경로, 작업 상태 등이 저장됩니다. 하지만 사진과 영상 원본은 파일 시스템에 저장됩니다.

따라서 데이터베이스만 백업하면 원본 사진과 영상이 복구되지 않고, 파일만 백업하면 앨범·사용자·메타데이터 관계가 정상 복구되지 않을 수 있습니다.

Immich 내장 DB 백업

Immich는 데이터베이스 백업 작업을 제공합니다. 관리 화면에서 다음 경로로 이동합니다.

관리 → 작업 대기열 → 새 작업 → 데이터베이스 덤프 생성

생성된 DB 백업은 보통 UPLOAD_LOCATION/backups 아래에 저장됩니다.

백업 순서

가장 안전한 백업 방식은 Immich 서버 컨테이너를 잠시 중지한 뒤 데이터베이스와 파일을 함께 백업하는 것입니다. 데이터가 변경되지 않는 상태에서 백업하므로 DB와 파일의 상태가 맞을 가능성이 높습니다.

서비스를 중지할 수 없는 환경이라면 다음 순서를 권장합니다.

1. 데이터베이스 백업
2. UPLOAD_LOCATION 백업
3. 외부 라이브러리 원본 폴더 백업
4. docker-compose.yml과 .env 백업

이 순서를 지키면 복구 시 DB에는 없지만 파일 시스템에는 남아 있는 파일이 생기는 정도로 리스크를 줄일 수 있습니다. 반대로 파일을 먼저 백업하고 DB를 나중에 백업하면 DB가 참조하는 파일이 백업본에 없는 상황이 생길 수 있습니다.

3-2-1 백업 원칙

사진과 영상처럼 중요한 데이터는 3-2-1 백업 원칙을 기준으로 설계하는 것이 좋습니다.

예를 들면 다음과 같습니다.

• 나스 원본
• 외장 HDD 또는 다른 나스 백업
• 클라우드 백업 또는 원격지 나스 백업

시놀로지 환경에서는 하이퍼 백업(Hyper Backup), 스냅샷 레플리케이션(Snapshot Replication), USB Copy, rsync, 다른 나스로의 백업 등을 조합할 수 있습니다.

업데이트 시 주의사항

Immich는 여전히 활발하게 개발되는 프로젝트입니다. 이것은 장점이지만, 운영 환경에서는 업데이트 리스크도 함께 봐야 합니다.

특히 데이터베이스 이미지, 벡터 검색 확장, 도커 컴포즈 구성, 환경 변수 등이 바뀌는 업데이트는 단순 이미지 업데이트보다 신중하게 접근해야 합니다.

업데이트 전 체크리스트는 다음과 같습니다.

• 공식 릴리스 노트 확인
• Breaking change 여부 확인
• 도커 컴포즈 변경 사항 확인
• .env 변경 사항 확인
• 데이터베이스 백업 생성
• UPLOAD_LOCATION 백업 상태 확인
• 외부 라이브러리 원본 백업 상태 확인
• 업데이트 후 웹 UI, 모바일 앱, 외부 라이브러리 스캔, 검색 기능 확인

업데이트를 위해서는 컨테이너 매니저 앱의 프로젝트 메뉴에서 Immich 프로젝트를 정리한 후, 이미지 메뉴에서 업데이트가 존재하는 이미지들을 업데이트하고 다시 프로젝트 메뉴에서 해당 프로젝트를 선택한 후 빌드를 하면 됩니다. SSH 접속 없이 간단하게 할 수 있고, 시놀로지 컨테이너 매니저를 쓰는 이유이기도 합니다.

업데이트 후 문제가 생겼을 때를 대비해 최소한 다음 파일은 별도로 보관해 두는 것이 좋습니다.

docker-compose.yml
.env
UPLOAD_LOCATION/backups
DB_DATA_LOCATION

Immich를 1차 원본 저장소로 바로 쓰지 않는 이유

Immich는 이미 충분히 실사용 가치가 있는 프로젝트입니다. 하지만 모든 사진과 영상을 처음부터 Immich의 내부 업로드 저장소에만 맡기는 방식은 아직 신중하게 접근하는 편이 좋습니다.

그 이유는 다음과 같습니다.

첫째, 사진과 영상은 장기 보관 데이터입니다. 앱이 아무리 좋아도 데이터 구조, 업로드 방식, 모바일 백업 안정성, 복구 절차를 충분히 검증한 뒤 주 저장소로 삼아야 합니다.

둘째, Immich는 내부 업로드 저장소와 데이터베이스가 강하게 연결되어 있습니다. UPLOAD_LOCATION 내부 파일을 사용자가 직접 옮기거나 삭제하지 못하므로 주기적으로 위치를 옮기는 작업을 할 수 없습니다.

셋째, 모바일 자동 백업은 운영체제의 백그라운드 정책 영향을 받습니다. 구글 포토처럼 플랫폼과 깊게 통합된 서비스와 비교하면, 셀프호스팅 앱은 기기별 설정과 네트워크 환경에 더 민감할 수 있습니다. 시놀로지 포토 쪽이 오히려 이 점에서는 더 나아서, 저희는 시놀로지 포토를 모바일 앱 백업용으로 주로 사용하고, Immich는 아직 테스트 단계로 사용중입니다.

넷째, 업데이트 속도가 빠릅니다. 기능 개선이 빠른 만큼 구조 변경이 아직은 있을 수 있습니다.

그래서 시놀로지 나스 환경에서는 다음과 같은 운영 방식을 추천합니다.

1. 기존 사진 원본은 /volume1/photo 같은 별도 공유 폴더나 폴더에 보관
2. 시놀로지 포토, SMB, 파일 복사 등 기존 업로드 흐름 유지(시놀로지 포토는 시놀로지에서 직접 시놀로지 나스와 긴밀하게 통합하여 개발하는 프로젝트이고, 개발/유지보수 기간도 오래되었으므로 굉장히 안정적입니다)
3. Immich에서는 해당 폴더를 외부 라이브러리로 읽기
4. 원본 폴더는 :ro 읽기 전용으로 마운트
5. Immich가 마음에 들면 일부 사용자나 일부 앨범부터 직접 업로드 테스트
6. 충분히 검증한 뒤 운영 범위 확대

이 방식은 보수적이지만 안전합니다. 나스 운영 시에는 "새로운 앱이 좋아 보이니 전체 데이터를 바로 이전"하는 것보다, 기존 원본 구조를 유지하면서 새 기능을 검증하는 접근이 훨씬 안정적입니다.

자주 겪는 문제와 확인 포인트

접속이 안 되는 경우

내부 IP로 접속이 되지 않으면 다음을 확인합니다.

http://NAS_IP:2283

• 컨테이너 매니저에서 프로젝트가 실행 중인지
• immich_server 컨테이너가 정상 상태인지
• DSM 방화벽에서 2283 포트를 허용했는지
• 나스 IP가 정확한지
• 브라우저가 자동으로 HTTPS로 바꾸지 않았는지

외부 라이브러리 스캔이 안 되는 경우

외부 라이브러리 스캔이 되지 않으면 대부분 경로 문제입니다.

확인할 항목은 다음과 같습니다.

• 도커 컴포즈의 마운트 경로가 맞는지
• Immich 관리 화면에 나스 실제 경로가 아니라 컨테이너 내부 경로를 입력했는지
• :ro 마운트 상태에서 컨테이너가 읽을 권한이 있는지
• 제외 패턴이 너무 넓게 잡히지 않았는지
• 폴더명에 특수문자나 권한 문제가 없는지

예를 들어 컴포즈에 아래처럼 입력했다면,

- /volume1/photo:/mnt/media/exphotos:ro

Immich 외부 라이브러리에는 아래 경로를 입력해야 합니다.

/mnt/media/exphotos

서버 상태가 Offline으로 보이는 경우

역방향 프록시를 사용할 때 서버 상태가 Offline으로 보이거나 모바일 앱 연결이 불안정하다면 웹소켓 설정을 확인합니다.

DSM 역방향 프록시의 사용자 지정 머리글에서 WebSocket 항목을 추가해야 합니다.

또한 immich.example.com 같은 서브도메인 루트로 연결했는지 확인합니다. /immich 같은 하위 경로 방식은 사용하지 않는 것이 좋습니다.

대용량 영상 업로드가 실패하는 경우

작은 사진은 업로드되지만 대용량 영상만 실패한다면 프록시의 문제가 있을 가능성이 높습니다. 특히 443번 포트로 개방을 해두고 CloudFlare의 프록시 기능을 쓰거나, 터널 기능을 쓸 경우 최대 용량에 제한이 있습니다.

머신러닝이 너무 느린 경우

얼굴 인식이나 스마트 검색이 느리다면 나스 사양 한계일 수 있습니다.

특히 저전력 Celeron, ARM 기반 나스, RAM 4GB 이하 모델에서는 대량 라이브러리 스캔이 오래 걸립니다. 처음에는 머신러닝 기능을 일부 끄거나 작은 라이브러리부터 테스트하는 것이 좋습니다.

마치며

Immich는 구글 포토 대체 솔루션을 찾는 사용자에게 매우 매력적인 오픈소스 프로젝트입니다. 시놀로지 나스와 조합하면 내 사진과 영상을 내 저장소에 두면서도 웹 UI, 모바일 앱, 얼굴 인식, 검색, 앨범 공유 같은 편의 기능을 사용할 수 있습니다.

다만 나스 운영 시에는 데이터 안전성이 기능보다 우선입니다. 처음부터 Immich를 모든 원본의 1차 저장소로 쓰기보다는, 기존 사진 폴더를 외부 라이브러리로 읽어오는 방식으로 시작하는 것을 권장합니다.

Immich는 아직 구글 포토나 시놀로지 포토를 모든 면에서 완전히 대체한다고 단정하기는 어렵습니다. 하지만 외부 라이브러리와 백업 전략을 함께 사용하면, 나스 기반 사진 관리 시스템으로서는 대단히 잘 작동합니다.

시놀로지 나스에 Immich, 시놀로지 포토, 백업 정책, 외부 접속 보안까지 함께 구성해야 한다면 아래 견적 요청을 통해 상담을 남겨 주셔도 됩니다.

관련 링크