[NAS] Immich NAS 성능 벤치마크와 최적화

사진이 몇 만 장을 넘어가면, 그때부터는 단순히 저장만 하는 NAS(Network Attached Storage, 네트워크 저장소)로는 답이 잘 안 나오더라고요. 특히 Immich NAS 성능 이슈는 썸네일 생성, 머신러닝(Machine Learning, 기계학습) 분석, 모바일 업로드가 한꺼번에 몰릴 때 바로 체감됩니다. 저도 홈랩에서 Docker on NAS 환경으로 Immich를 굴려보면서 “왜 평소엔 멀쩡한데 오늘만 이렇게 느리지?” 같은 상황을 꽤 겪었습니다. 이번 글은 숫자를 지어내는 벤치마크가 아니라, 실제로 재현 가능한 측정 기준과 최적화 포인트를 정리한 글입니다.

특히 Synology Docker 환경이나 TrueNAS 계열에서 Immich를 올려 쓰는 분들이라면, CPU만 볼 게 아니라 저장소 I/O(Input/Output, 입출력), 썸네일 작업 큐, PostgreSQL(포스트그레스큐엘, 데이터베이스) 설정까지 같이 봐야 합니다. 여기서 중요한 포인트! Immich 벤치마크는 단순 속도 테스트가 아니라 병목 구간을 찾는 과정이라는 점입니다.

Immich, PostgreSQL, Redis, 업로드 클라이언트, NAS 스토리지 경로가 한눈에 보이는 전체 구성도입니다.

1. 왜 Immich NAS 성능이 생각보다 중요할까요?

쉽게 말해 Immich는 그냥 사진을 쌓아두는 앱이 아닙니다. 업로드가 들어오면 메타데이터(metadata, 부가정보)를 정리하고, 썸네일(thumbnail, 미리보기 이미지)을 만들고, 검색을 위한 인덱스(index, 색인)를 쌓고, 경우에 따라 머신러닝 모델이 얼굴이나 장면 분석도 수행합니다. 그러니까 저장소 하나만 빠르다고 끝이 아니고, CPU, 메모리, 디스크, 컨테이너 배치가 같이 맞아야 하더라고요.

제가 직접 해보니 초반엔 “NAS에 Docker만 올리면 되겠지”라고 생각했었는데, 실제로 써보니까 다음 세 가지가 체감 성능을 많이 갈랐습니다.

• 대량 초기 인덱싱: 처음 라이브러리를 스캔할 때 CPU와 저장소 부하가 크게 올라갑니다.
• 동시 업로드: 휴대폰 여러 대가 동시에 백업하면 I/O 대기 시간이 늘어납니다.
• 썸네일/트랜스코딩: 작은 파일이 아주 많이 만들어져서 HDD 기반 볼륨은 생각보다 불리할 수 있습니다.

혹시 이런 경험 있으신가요? 업로드는 끝났는데 앱에서 사진이 늦게 보이거나, 검색 결과가 한참 뒤에 반영되는 경우요. 이런 게 바로 사진 관리 솔루션으로서 Immich NAS 성능 문제로 이어집니다.

2. Immich 벤치마크를 볼 때 기준을 먼저 정해야 합니다

Benchmark(벤치마크, 성능 측정)라고 하면 숫자부터 보고 싶어지는데요, 사실 환경마다 차이가 너무 커서 절대 수치만 보면 오해하기 쉽습니다. CPU 세대, SSD 캐시 여부, 데이터셋 크기, 파일당 평균 용량, 컨테이너 리소스 제한이 다 다르거든요. 그래서 저는 아래처럼 작업 단위 기준으로 보는 걸 추천합니다.

즉, Immich NAS 성능을 제대로 보려면 “몇 초 나왔냐”보다 “어떤 작업에서 느려졌냐”가 더 중요합니다. 저도 처음엔 이게 뭔가 싶었는데, 병목을 구간별로 나눠서 보니 훨씬 명확해지더라고요.

3. Docker on NAS 환경에서 먼저 확인할 구성

실전 들어가기 전에, 구성부터 정리하겠습니다. Synology Docker나 일반 리눅스 NAS, 그리고 TrueNAS 계열처럼 컨테이너 앱으로 Immich를 운영하는 경우에도 핵심은 비슷합니다.

1. 사진 원본 라이브러리 경로와 데이터베이스 저장 경로를 구분합니다.
2. 가능하면 PostgreSQL 데이터 디렉터리는 SSD 계층에 둡니다.
3. 업로드 원본과 썸네일 캐시는 같은 풀(pool, 저장소 집합)에 둘지 분리할지 미리 결정합니다.
4. 백그라운드 작업 시간대를 정합니다. 가족 사진 업로드가 많은 시간과 겹치면 체감이 확 떨어집니다.

제가 홈랩에서 삽질 좀 했습니다 ㅎㅎ 원본 사진은 대용량 HDD 어레이(array, 디스크 묶음)에 두고, DB랑 캐시까지 같은 볼륨에 몰아뒀더니 작은 파일 I/O가 몰릴 때 응답성이 확 나빠졌습니다. 이후 DB와 캐시 계층을 더 빠른 스토리지로 분리하니 체감이 꽤 좋아졌습니다.

예시 docker-compose.yml

services:
  immich-server:
    image: ghcr.io/immich-app/immich-server:release
    container_name: immich_server
    depends_on:
      - redis
      - database
    environment:
      DB_HOSTNAME: database
      DB_USERNAME: immich
      DB_PASSWORD: change_me
      DB_DATABASE_NAME: immich
      REDIS_HOSTNAME: redis
    ports:
      - "2283:2283"
    volumes:
      - /mnt/nas/photo-library:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped

  immich-machine-learning:
    image: ghcr.io/immich-app/immich-machine-learning:release
    container_name: immich_ml
    volumes:
      - /mnt/fast/immich-model-cache:/cache
    restart: unless-stopped

  redis:
    image: redis:7
    container_name: immich_redis
    restart: unless-stopped

  database:
    image: tensorchord/pgvecto-rs:pg14-v0.2.0
    container_name: immich_db
    environment:
      POSTGRES_USER: immich
      POSTGRES_PASSWORD: change_me
      POSTGRES_DB: immich
    volumes:
      - /mnt/fast/postgres-immich:/var/lib/postgresql/data
    restart: unless-stopped

버전은 예시일 뿐이고, 실제 배포 전에는 사용 중인 Immich 공식 문서와 현재 이미지 태그를 반드시 다시 확인하셔야 합니다. 중요한 건 구조입니다. 업로드 경로, 모델 캐시, 데이터베이스 경로를 어떻게 나누느냐가 성능에 직접 영향을 줍니다.

업로드 볼륨, 데이터베이스 볼륨, 모델 캐시 볼륨을 서로 다른 스토리지 계층에 배치하는 구성 예시입니다.

4. Immich 벤치마크를 위한 측정 절차

이제 본격적으로 측정해보겠습니다. 여기서 제가 추천하는 방식은 동일 데이터셋으로 세 번 반복입니다. 첫 번째는 캐시가 비어 있는 상태, 두 번째는 일부 캐시가 쌓인 상태, 세 번째는 설정 변경 후 비교용입니다.

1. 컨테이너 상태와 리소스 점유를 먼저 확인합니다.
2. 테스트용 사진 세트를 준비합니다. 가능하면 파일 크기와 개수가 섞여 있어야 합니다.
3. 업로드 직후부터 라이브러리 반영 완료 시점까지 시간을 기록합니다.
4. CPU, 메모리, 디스크 I/O, 컨테이너 로그를 함께 봅니다.
5. 설정을 하나만 바꾼 뒤 다시 측정합니다. 한 번에 여러 개 바꾸면 원인 파악이 안 됩니다.

기본 확인 명령어

docker ps

docker stats

docker logs -f immich_server

docker logs -f immich_db

df -h

iostat -x 1

여기서 iostat는 디스크 대기 시간을 보기 좋습니다. 만약 NAS 운영체제에서 직접 설치가 어렵다면, 제공되는 모니터링 도구로 대체해도 됩니다. Synology에서는 리소스 모니터(resource monitor), TrueNAS 계열에서는 대시보드와 풀 I/O 그래프를 같이 보면 감이 옵니다.

업로드 테스트 예시

time rsync -avh ./sample-photos/ /mnt/nas/photo-library/import-test/

find /mnt/nas/photo-library/import-test -type f | wc -l

실제로 써보니까 업로드 자체보다, 그 뒤에 이어지는 백그라운드 잡(background job, 백그라운드 작업)이 더 오래 걸리는 경우가 많았습니다. 그래서 저는 업로드 종료 시점과 앱에서 사진이 정상 탐색되는 시점을 따로 적어뒀습니다.

5. 제가 자주 본 병목 구간과 최적화 포인트

Immich NAS 성능을 끌어올릴 때는 무작정 CPU를 올리는 것보다 병목별 대응이 더 효과적입니다.

• DB가 느린 경우: PostgreSQL 데이터 경로를 더 빠른 스토리지로 이동해보세요. Synology Docker나 TrueNAS Docker 환경이라면 기본 스토리지 계층을 확인하고 SSD 풀로 분리하는 걸 추천합니다.
• 썸네일 생성이 밀리는 경우: 원본 사진 경로는 HDD여도, 캐시와 DB는 SSD 계층이 유리합니다.
• 컨테이너 간 I/O 경쟁: Immich 외에 미디어 서버, 백업 작업, 다운로드 작업이 동시에 돌면 NAS 전체 응답성이 떨어집니다.
• 메모리 부족: 스왑(swap, 디스크 기반 가상 메모리)이 발생하면 체감 성능이 급격히 무너집니다.

저도 처음엔 CPU 사용률만 보고 있었는데, 근데 여기서 함정이 있더라고요. CPU는 40~50% 정도인데도 체감은 엄청 느릴 수 있습니다. 이런 경우는 대체로 디스크 대기나 작은 파일 쓰기 병목이었습니다.

튜닝 전후를 비교할 때 체크할 것

6. ⚠️ 트러블슈팅: 실제로 많이 겪는 문제

이 섹션은 진짜 경험담 위주입니다. 저도 처음엔 헷갈렸는데, 아래 문제들은 꽤 자주 만났습니다.

1) 볼륨 권한 문제로 업로드는 되는데 후처리가 꼬이는 경우

컨테이너 내부 사용자 권한과 NAS 실제 디렉터리 권한이 안 맞으면 생기는 문제입니다. 파일은 생기는데 일부 작업이 실패하거나, 썸네일 생성 로그에 에러가 남을 수 있습니다.

ls -al /mnt/nas/photo-library
id

docker exec -it immich_server sh

해결 포인트: 컨테이너에서 접근하는 UID/GID와 NAS 공유 폴더 권한을 맞추는 겁니다.

2) 데이터베이스를 느린 HDD 볼륨에 둔 경우

사진 원본은 순차 읽기 비중이 커서 HDD도 어느 정도 버티는데, DB는 작은 쓰기와 랜덤 접근이 잦거든요. 그래서 같은 HDD 풀에 몰아두면 검색 반영과 라이브러리 응답성이 같이 떨어질 수 있습니다.

해결 포인트: PostgreSQL 경로를 더 빠른 SSD 계층으로 옮기고, 원본 라이브러리와 분리해보세요. 특히 Synology Docker나 TrueNAS Docker 환경에서는 별도 SSD 볼륨을 준비해두는 것이 중요합니다.

3) 머신러닝 작업이 몰리면서 NAS 전체가 답답해지는 경우

얼굴 인식이나 장면 분석이 동시에 많이 돌면 CPU 자원을 꽤 씁니다. 이럴 때는 백업 작업, 미디어 인덱싱 작업과 시간이 겹치지 않게 분산하는 게 좋습니다.

해결 포인트: 초기 분석은 야간으로 미루고, 낮에는 업로드 위주로 운영해보세요.

업로드 이후 백그라운드 작업 큐가 쌓이고, CPU와 디스크 사용량이 함께 움직이는 모습을 보여주는 대시보드 예시입니다.

7. 검증: 어떤 결과가 나오면 최적화가 잘 된 걸까요?

여기서 중요한 건 절대 점수보다 일관성입니다. 제가 직접 해보니 최적화가 잘 된 환경은 다음 특징이 있었습니다.

• 업로드 후 사진 표시까지 걸리는 시간이 들쭉날쭉하지 않습니다.
• 대량 업로드 중에도 웹 인터페이스 탐색이 완전히 무너지지 않습니다.
• 검색과 스크롤이 이전보다 자연스럽게 유지됩니다.
• 백그라운드 작업이 끝나는 패턴이 예측 가능해집니다.

즉, Immich 벤치마크의 핵심은 “최고 속도”보다 “실사용 중 안정성”입니다. 숫자 하나만 보고 판단하면 실제 사용감과 어긋날 때가 많습니다.

가능하다면 아래처럼 간단한 기록표를 만들어 두세요.

# 예시 기록 항목
# 테스트 날짜
# 사진 수 / 총 용량
# 원본 저장소 위치
# DB 저장소 위치
# 업로드 완료 시각
# 라이브러리 반영 완료 시각
# 썸네일 생성 완료 체감 시각
# CPU / 메모리 / I/O 특이사항

이렇게 해두면 Synology Docker 환경과 다른 NAS 환경을 비교할 때도 훨씬 객관적으로 볼 수 있습니다. 다음 글에서는 모니터링 스택까지 붙여서 좀 더 자동화된 방식으로 다뤄볼 예정입니다.

8. 정리 + 자주 묻는 질문

정리해보면, 사진 관리 솔루션으로서 Immich는 정말 매력적입니다. 다만 NAS 위에서 잘 돌리려면 애플리케이션만 보는 게 아니라 스토리지 구조와 컨테이너 배치까지 같이 봐야 하더라고요. 저도 처음엔 단순히 이미지 올리고 끝인 줄 알았는데, 실제로는 Docker on NAS 환경 설계가 성능의 절반 이상을 좌우했습니다. 드디어 됐다! 싶은 순간은, 업로드와 탐색이 동시에 자연스럽게 돌아갈 때 오더군요.

• Q. CPU가 높지 않은데도 느린 이유는 뭔가요?
  A. 디스크 I/O나 DB 응답 지연일 가능성이 큽니다. 작은 파일 쓰기가 많은 구간을 의심해보세요.
• Q. 사진 원본도 SSD에 둬야 하나요?
  A. 꼭 그렇진 않습니다. 다만 DB와 캐시 계층은 더 빠른 스토리지가 체감에 유리합니다.
• Q. TrueNAS Docker로 검색해도 되나요?
  A. 검색 키워드로는 많이 쓰지만, 실제 운영 방식은 NAS 플랫폼 버전에 따라 앱 또는 컨테이너 구성 방식이 다를 수 있으니 현재 환경 기준으로 확인하시는 게 좋습니다.
• Q. Immich NAS 성능 최적화에서 가장 먼저 할 일은?
  A. 원본, DB, 캐시 경로를 분리해서 병목 위치를 확인하는 겁니다.

병목 구간, 저장소 배치, 체크리스트를 한 장으로 요약한 인포그래픽입니다.

이전 글에서 NAS 볼륨 설계와 백업 전략을 다뤘다면, 이번 글은 그 위에 Immich를 얹었을 때의 실제 운영 포인트에 더 가깝습니다. 다음 글에서는 로그와 모니터링을 붙여서, 어떤 지표를 보면 병목이 바로 보이는지 이어서 정리해보겠습니다. Immich NAS 성능 문제로 답답하셨다면, 오늘은 숫자보다 구조부터 다시 보시는 걸 추천드립니다.