구글 포토의 무료 무제한이 사라진 뒤로 “사진을 어디에 둘까”는 모두의 고민입니다. 저는 홈랩에 Immich를 올려서 스마트폰 사진을 자동 백업하고 있습니다. 구글 포토와 거의 똑같은 경험을 내 서버, 내 디스크에서요. 실제 운영 구성과 GPU 없이 돌리는 요령을 공개합니다.
1. Immich가 뭐고 왜 좋은가
Immich는 셀프호스팅 사진·영상 관리 서버입니다. 구글 포토를 대체하도록 만들어져서 —
스마트폰 앱으로 자동 백업(찍으면 알아서 올라감)
얼굴 인식·사물 검색(“바다”, “강아지”로 검색)
타임라인·앨범·공유 등 익숙한 UI
무엇보다 내 데이터가 외부로 안 나감
2. 실제 구성 — 4개 컨테이너
제 홈랩에서는 LXC 컨테이너 안에 Docker로 Immich 스택을 돌립니다. 구성은 이렇게 4개로 나뉩니다.
컨테이너
역할
immich-server
API·웹 UI·업로드 처리
immich-machine-learning
얼굴 인식·스마트 검색(ML)
postgres(pgvector)
메타데이터 + 벡터 검색 DB
redis(valkey)
작업 큐·캐시
여기서 눈여겨볼 건 postgres가 pgvector 계열이라는 점입니다. 얼굴·사물 검색을 위해 사진의 특징을 벡터로 저장하고, 그 벡터를 DB에서 유사도로 검색합니다. 그래서 “비슷한 사진”이나 자연어 검색이 됩니다.
3. 사진은 ZFS NAS에, 대용량을 감당
핵심은 사진 원본을 어디에 두느냐입니다. 저는 컨테이너 디스크가 아니라 ZFS 기반 NAS 데이터셋에 저장합니다. 현재 사진 라이브러리만 1.3TB가 넘는데, 컨테이너 rootfs(수십 GB)로는 어림도 없죠.
# docker-compose.yml (요지) — 업로드 경로를 NAS 볼륨에 매핑
services:
immich-server:
volumes:
- /mnt/nas/immich:/usr/src/app/upload # 원본은 대용량 NAS로
이렇게 하면 애플리케이션(컨테이너)과 데이터(NAS)를 분리할 수 있습니다. 컨테이너를 갈아엎어도 사진은 NAS에 그대로 있고, ZFS라 스냅샷·확장도 자유롭습니다.
4. GPU 없이 ML 돌리기
Immich의 얼굴 인식·스마트 검색은 머신러닝이라 “GPU 있어야 하지 않나?” 싶지만, 제 홈랩엔 외장 GPU가 없습니다. ML 컨테이너는 CPU로도 잘 돌아갑니다. 다만 —
처음 대량의 사진을 일괄 인덱싱할 때만 CPU를 오래 씁니다(밤새 돌려두면 됨).
인덱싱이 끝나면 이후 검색·인식은 가볍습니다.
즉 초기 1회만 참으면 GPU 없이도 실사용에 지장이 없습니다.
수만 장을 한 번에 넣으면 며칠 걸릴 수 있으니, 처음엔 ML 작업을 밤 시간대에 몰아서 돌리는 걸 권합니다.
5. 운영하며 느낀 점
백업은 별개다: Immich는 사진 “관리”이지 백업이 아닙니다. NAS가 죽으면 끝이니, 사진 원본은 반드시 별도 백업(오프사이트)을 두세요.
DB도 소중하다: 앨범·얼굴 정보는 postgres에 있습니다. 사진 파일과 함께 DB 백업도 챙겨야 완전 복구가 됩니다.
업그레이드 전 스냅샷: 마이너 업데이트에서도 DB 마이그레이션이 있으니, 올리기 전에 컨테이너·DB 스냅샷을 찍어두면 안전합니다.
구글 포토를 벗어나고 싶은 분께 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 캐시 여부, 데이터셋 크기, 파일당 평균 용량, 컨테이너 리소스 제한이 다 다르거든요. 그래서 저는 아래처럼 작업 단위 기준으로 보는 걸 추천합니다.
측정 항목
왜 중요한가
병목 힌트
초기 라이브러리 스캔 시간
대량 사진 등록 시 전체 체감 속도에 직결
CPU 또는 디스크 I/O
업로드 후 사진 표시 지연
모바일 백업 만족도와 직접 연결
썸네일 큐 적체, DB 응답 지연
검색 반영 속도
메타데이터 처리 성능 확인 가능
DB, 인덱싱 작업 병목
백그라운드 작업 중 CPU 점유
다른 NAS 서비스와 공존 가능성 판단
ML 작업, 트랜스코딩 부하
스토리지 사용 패턴
썸네일/DB 경로 최적화 판단
작은 파일 쓰기 지연
즉, Immich NAS 성능을 제대로 보려면 “몇 초 나왔냐”보다 “어떤 작업에서 느려졌냐”가 더 중요합니다. 저도 처음엔 이게 뭔가 싶었는데, 병목을 구간별로 나눠서 보니 훨씬 명확해지더라고요.
3. Docker on NAS 환경에서 먼저 확인할 구성
실전 들어가기 전에, 구성부터 정리하겠습니다. Synology Docker나 일반 리눅스 NAS, 그리고 TrueNAS 계열처럼 컨테이너 앱으로 Immich를 운영하는 경우에도 핵심은 비슷합니다.
사진 원본 라이브러리 경로와 데이터베이스 저장 경로를 구분합니다.
가능하면 PostgreSQL 데이터 디렉터리는 SSD 계층에 둡니다.
업로드 원본과 썸네일 캐시는 같은 풀(pool, 저장소 집합)에 둘지 분리할지 미리 결정합니다.
백그라운드 작업 시간대를 정합니다. 가족 사진 업로드가 많은 시간과 겹치면 체감이 확 떨어집니다.
제가 홈랩에서 삽질 좀 했습니다 ㅎㅎ 원본 사진은 대용량 HDD 어레이(array, 디스크 묶음)에 두고, DB랑 캐시까지 같은 볼륨에 몰아뒀더니 작은 파일 I/O가 몰릴 때 응답성이 확 나빠졌습니다. 이후 DB와 캐시 계층을 더 빠른 스토리지로 분리하니 체감이 꽤 좋아졌습니다.
여기서 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 풀로 분리하는 걸 추천합니다.
컨테이너 간 I/O 경쟁: Immich 외에 미디어 서버, 백업 작업, 다운로드 작업이 동시에 돌면 NAS 전체 응답성이 떨어집니다.
메모리 부족: 스왑(swap, 디스크 기반 가상 메모리)이 발생하면 체감 성능이 급격히 무너집니다.
저도 처음엔 CPU 사용률만 보고 있었는데, 근데 여기서 함정이 있더라고요. CPU는 40~50% 정도인데도 체감은 엄청 느릴 수 있습니다. 이런 경우는 대체로 디스크 대기나 작은 파일 쓰기 병목이었습니다.
튜닝 전후를 비교할 때 체크할 것
항목
튜닝 전
튜닝 후 기대 변화
업로드 후 썸네일 반영
지연이 길고 들쭉날쭉
반영 속도가 더 일정해짐
DB 응답
검색/스크롤 시 버벅임
목록 탐색이 부드러워짐
동시 작업 시 NAS 반응성
다른 서비스도 같이 느려짐
영향 범위가 줄어듦
백그라운드 작업 완료 시간
예측이 어려움
대체로 패턴이 안정적
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 성능 문제로 답답하셨다면, 오늘은 숫자보다 구조부터 다시 보시는 걸 추천드립니다.
OpenMediaVault에 Immich 구축 6개월 사용기: 자가 호스팅 사진 관리의 명과 암
안녕하세요, 13년차 서버실입니다. 홈랩을 운영하며 이것저것 시도하는 게 제 낙인데요. 오늘은 많은 분들이 관심을 가지시는 자가 호스팅 사진 관리 솔루션, Immich를 OpenMediaVault(OMV)에 구축하고 6개월간 사용해 본 경험을 솔직하게 공유해 보려 합니다. 직접 써보니 정말 편한 부분도 많았지만, 예상치 못한 문제점들도 꽤 있더라고요. 이번엔 제 경험을 바탕으로 명과 암을 낱낱이 파헤쳐 보겠습니다.
Immich와 OpenMediaVault를 활용한 전체 홈랩 사진 관리 아키텍처 개요
왜 자가 호스팅 사진 관리인가? 🤔
스마트폰 용량은 늘 부족하고, 사진은 기하급수적으로 늘어나죠. 클라우드 서비스는 편리하지만, 월마다 나가는 비용 부담이나 개인 정보 유출에 대한 걱정에서 자유롭지 못합니다. 특히 소중한 사진 데이터가 서비스 제공 업체의 정책 변화나 개인정보 유출 사고로 날아갈까 봐 불안한 마음, 다들 한 번쯤은 느껴보셨을 겁니다. 저도 그랬어요. 그래서 자가 호스팅 사진 관리, 특히 Immich 같은 오픈소스 솔루션에 눈을 돌리게 되었습니다. 내 손안의 작은 클라우드, 이게 가능하다는 게 신기하더라고요.
Immich, 뭐가 그렇게 좋은데? 💡
Immich는 Google Photos와 유사한 기능을 제공하는 오픈소스 사진 백업 및 관리 솔루션이에요. 핵심은 내 서버에 직접 설치해서 사용한다는 점이죠. 주요 기능들을 살펴보면:
자동 백업: 스마트폰 사진을 자동으로 서버에 백업해 줘요. Google Photos의 자동 백업 기능과 거의 똑같다고 보시면 됩니다.
AI 기반 기능: 사진 내 객체 인식, 얼굴 인식, 중복 사진 제거 등 강력한 AI 기능을 제공합니다. 이게 또 은근히 편하더라고요.
웹 UI & 모바일 앱: 깔끔한 웹 인터페이스와 함께 iOS, Android 모바일 앱을 지원해서 언제 어디서든 사진에 접근하고 관리할 수 있어요.
다양한 포맷 지원: JPG, PNG뿐만 아니라 RAW 파일, 비디오 파일도 지원합니다.
이런 강력한 기능들을 무료로, 내 마음대로 사용할 수 있다는 점이 Immich의 가장 큰 매력이에요. 물론, 이걸 구현하기 위해 몇 가지 기술적인 장벽을 넘어야 하긴 합니다.
OpenMediaVault(OMV) 위에 Immich 올리기 🛠️
저는 NAS(Network Attached Storage) 솔루션으로 OpenMediaVault(OMV)를 사용하고 있어요. OMV는 Debian 기반의 NAS 운영체제로, 웹 UI를 통해 스토리지 관리, 사용자 관리, 다양한 플러그인 설치 등을 쉽게 할 수 있게 해줍니다. Immich는 Docker 컨테이너로 배포되기 때문에 OMV의 Docker 플러그인과 함께라면 설치가 한결 수월합니다.
1단계: OpenMediaVault 준비
OMV가 설치되어 있고, Docker 플러그인이 활성화된 상태여야 해요. 만약 Docker 플러그인이 없다면, OMV 웹 UI의 ‘플러그인’ 메뉴에서 설치해 주세요. 그 후, Immich 데이터를 저장할 볼륨(Volume)을 위한 디스크나 파티션을 준비하고 OMV에서 파일 시스템으로 마운트해 두는 게 좋아요. 저는 `/srv/dev-disk-by-uuid/<UUID>/immich` 경로에 데이터를 저장하도록 구성했습니다.
주의: 위 설정에서 <UUID> 부분은 실제 OMV에서 마운트한 디스크의 UUID로 변경해야 합니다. 또한, `your_strong_password` 부분은 복잡하고 안전한 비밀번호로 바꿔주세요. 특히 AI 기능(얼굴 인식, 객체 인식)을 사용하려면 `immich-ml` 서비스가 필수이니까 꼭 포함시켜야 해요. 데이터베이스 비밀번호는 모든 컨테이너에서 동일하게 설정해야 합니다.
3단계: Docker Compose 실행
OMV의 SSH 기능을 활성화하거나, Docker 플러그인에서 제공하는 ‘Compose’ 기능을 사용하여 위 내용을 `docker-compose.yml` 파일로 저장한 후 실행해요. 저는 SSH로 접속하여 해당 디렉토리에서 docker compose up -d 명령어를 실행했습니다.
OpenMediaVault에서 Docker 플러그인을 통해 Immich 컨테이너가 실행되고 있는 모습
컨테이너가 모두 정상적으로 실행되면, 웹 브라우저에서 http://<OMV IP 주소>:3001 으로 접속하여 Immich 초기 설정을 진행할 수 있어요. 처음에는 관리자 계정을 생성하고, 이후 사용자 계정을 추가하며 사진을 업로드하면 됩니다.
6개월간 사용하며 겪은 명과 암 ⛰️
6개월간 Immich를 사용하면서 느낀 점들을 솔직하게 말씀드리겠습니다.
✨ 명 (장점)
뛰어난 자동 백업 및 동기화: 스마트폰에서 찍은 사진이 실시간으로 서버에 백업되는 경험은 정말 혁신적이었어요. 용량 걱정 없이 마음껏 사진을 찍을 수 있게 되었죠.
강력한 AI 기능: 사진 검색 시 객체나 장소로 검색하는 기능은 정말 편리했습니다. 잃어버렸던 사진을 찾거나 특정 테마의 사진을 모아볼 때 유용하더라고요. 중복 사진 제거 기능도 꽤 정확해서 스토리지 공간을 절약하는 데 큰 도움이 되었어요.
깔끔한 UI/UX: 웹 인터페이스와 모바일 앱 모두 직관적이고 사용하기 편리했습니다. Google Photos에 익숙하다면 금방 적응할 수 있어요.
오픈소스의 자유로움: 비용 부담 없이 원하는 대로 커스터마이징하고 관리할 수 있다는 점이 가장 큰 매력이에요.
⚠️ 암 (단점 및 주의사항)
초기 설정의 복잡함: Docker, Docker Compose, 네트워크 설정 등 기본적인 이해가 없다면 설치 과정에서 어려움을 겪을 수 있어요. 저도 처음에는 Docker Compose 파일 설정 때문에 몇 번을 헤맸습니다.
리소스 요구량: Immich는 AI 기능 등을 포함하여 꽤 많은 시스템 리소스(CPU, RAM)를 요구합니다. 특히 사진을 대량으로 업로드하거나 AI 분석을 실행할 때 서버 부하가 체감될 정도였어요. 저사양 홈랩 서버에서는 성능 저하가 발생할 수 있으니까 주의해야 합니다.
업데이트 시 주의 필요: Immich는 활발하게 개발되고 있어 업데이트가 잦은 편입니다. 업데이트 과정에서 데이터베이스 스키마 변경 등으로 인해 문제가 발생할 수 있어서 항상 백업 후 업데이트하는 습관이 정말 중요해요. 저도 한 번 업데이트 후에 DB 연결에 문제가 생겨 잠시 당황했던 경험이 있습니다.
안정성 이슈 (가끔): 가끔 예상치 못한 오류나 컨테이너 재시작이 필요한 경우가 있었어요. 특히 대규모 파일 업로드나 백업 작업 중에 발생하면 좀 당황스럽더라고요.
데이터 무결성 책임: 모든 데이터 관리는 사용자 본인의 책임입니다. 백업, 스토리지 관리 등 모든 것을 직접 신경 써야 해요. 클라우드 서비스처럼 자동화된 백업/복구 시스템이 기본 제공되는 건 아니니까요.
Immich 대시보드에서 사진 업로드 진행 상황과 AI 분석 상태를 보여주는 화면
트러블슈팅: 흔히 겪는 문제들 🚨
6개월간 사용하면서 몇 가지 문제에 부딪혔고, 이를 해결했던 경험을 공유합니다.
문제 1: 컨테이너 재시작 후 DB 연결 실패
원인: Immich 서버 컨테이너가 DB 컨테이너보다 먼저 시작되면서 발생할 수 있어요.
해결책: `docker-compose.yml` 파일에서 `depends_on` 설정을 명확히 하고, Immich 서버 컨테이너에 재시도 로직을 추가하거나, 컨테이너 재시작 후 잠시 기다렸다가 수동으로 재시작하는 방법이 있습니다. 저는 `depends_on` 설정을 활용했어요.
문제 2: 사진 업로드가 간헐적으로 실패
원인: 서버 리소스 부족, 네트워크 불안정, 혹은 Immich 자체의 버그일 수 있습니다.
해결책: 서버의 CPU, RAM 사용량을 확인하고, 필요하다면 리소스를 증설하거나 백업/AI 분석 작업 시간을 조정했어요. 네트워크 상태도 점검하고, Immich의 최신 버전을 사용하며 커뮤니티 피드백을 확인하는 것이 좋습니다.
문제 3: AI 기능 (얼굴 인식 등)이 제대로 동작하지 않음
원인: AI 모델 다운로드 실패, 설정 오류, 또는 리소스 부족으로 인한 백그라운드 작업 지연이에요.
해결책: Immich의 `docker-compose.yml` 파일에서 `immich-ml` 서비스와 관련 볼륨 설정을 확인하고, 필요한 경우 `docker compose down` 후 `docker compose pull immich-ml` 명령어로 이미지를 최신 버전으로 다시 받아준 후 `docker compose up -d`로 재시작했어요. 서버 리소스가 충분한지 다시 한번 확인하는 것도 정말 중요합니다.
결론: 6개월간의 자가 호스팅 사진 관리 여정 📝
OpenMediaVault 위에 Immich를 구축하여 6개월간 사용해 본 결과, 자가 호스팅 사진 관리 솔루션으로서 Immich는 충분히 매력적이고 강력한 대안이라고 생각합니다. 특히 Google Photos의 편리함에 익숙하지만, 개인 정보 보호나 비용 절감을 원하는 분들에게는 최고의 선택지가 될 수 있어요.
하지만 만능은 아닙니다. 초기 설정의 장벽, 시스템 리소스 요구량, 업데이트 시의 주의, 그리고 데이터 관리에 대한 전적인 책임 등 고려해야 할 부분들이 분명히 있거든요. 마치 잘 길들여진 애완동물처럼, 꾸준한 관심과 관리가 필요한 셈이죠.
Immich의 사진 갤러리 보기와 검색 기능을 비교하는 인포그래픽
만약 여러분이…
기술적인 도전을 즐기시고,
직접 시스템을 구축하고 관리하는 것을 좋아하며,
개인 데이터의 프라이버시와 통제권을 최우선으로 생각한다면,
Immich는 분명 여러분의 홈랩에 훌륭한 추가가 될 거예요. 처음에는 조금 어렵게 느껴질 수 있지만, 한번 구축해두면 그 편리함에 만족하실 겁니다. 저도 앞으로도 Immich를 계속 사용하며 홈랩 사진 관리의 여정을 이어갈 생각이에요.
다음 글에서는 Immich의 백업 및 복구 전략에 대해 좀 더 자세히 다뤄보도록 하겠습니다. 감사합니다!
안녕하세요, 13년차 인프라 엔지니어 서버실입니다. 오늘은 많은 분들이 고민하시는 사진 관리 문제, 특히 프라이빗 클라우드 구축에 대한 이야기를 해볼까 합니다. 구글 포토의 정책 변경 이후, ‘내 사진을 내 손으로 관리하고 싶다!’는 열망이 더 커진 것 같아요. 저도 처음엔 클라우드 서비스가 편해서 잘 썼는데, 역시 데이터 주권(Data Sovereignty)은 중요하더라고요. 그래서 홈랩에서 직접 OpenMediaVault(OMV)와 Immich를 연동해서 저만의 프라이빗 사진 클라우드를 구축했습니다. 나스(NAS) 환경에서 사진을 자동으로 백업하고 관리할 수 있게 된 과정을 솔직하게 공유해 드릴게요.
그림 1: OpenMediaVault 기반 Immich 프라이빗 사진 클라우드 아키텍처
OpenMediaVault와 Immich, 왜 이 조합일까요?
먼저, 이 두 친구가 어떤 역할을 하는지 간단히 짚어보고 갈까요? 쉽게 말해, OpenMediaVault(OMV)는 나스(NAS, Network Attached Storage)의 뼈대 역할을 하고, Immich는 그 위에 멋진 옷을 입혀주는 사진 관리 솔루션이라고 생각하시면 됩니다.
OpenMediaVault (OMV): 데비안(Debian) 리눅스 기반의 무료 오픈소스 NAS 운영체제입니다. 파일 공유(SMB/NFS), RAID 관리, 플러그인 확장성, 그리고 무엇보다 도커(Docker) 컨테이너 지원이 강력해서 홈랩에서 활용도가 정말 높아요. 튼튼한 스토리지 백엔드를 제공하는 셈이죠. 제가 직접 써보니 안정성도 뛰어나고 관리도 편하더라고요.
Immich: 요즘 뜨는 셀프 호스팅(Self-hosted) 사진 및 비디오 백업 솔루션입니다. 구글 포토와 비슷한 사용자 경험을 제공하면서, AI 기반 얼굴 인식(Facial Recognition), 객체 감지(Object Detection), 검색 기능, 타임라인(Timeline) 뷰, 공유 앨범 등 고급 기능까지 갖추고 있어요. 모바일 앱(iOS/Android)도 있어서 자동 백업도 가능합니다. 이 정도면 ‘나만의 구글 포토’라고 불러도 손색이 없죠.
OMV가 안정적인 스토리지 공간을 제공하고, Immich가 그 공간에 저장된 사진들을 스마트하게 관리해주니, 이보다 더 좋은 조합이 있을까요? 👍
OMV에 도커와 Immich 설치하기: 실전 구현
이제 본격적으로 OMV 위에 Immich를 올려볼 차례입니다. OMV에 도커와 포테이너(Portainer)가 이미 설치되어 있다고 가정할게요. (아직 설치 안 하셨다면, OMV 웹 UI에서 OMV-Extras 플러그인을 통해 쉽게 설치할 수 있습니다.)
1. Immich용 공유 폴더 생성
먼저 OMV에서 Immich가 사진을 저장할 공유 폴더를 만들어야 합니다. 저는 /srv/dev-disk-by-uuid-XXXX/data/immich 경로에 immich라는 공유 폴더를 만들었어요. 여기서 정말 중요한 부분이 바로 권한 설정입니다. 도커 컨테이너 내부의 프로세스가 이 폴더에 접근하고 파일을 쓸 수 있도록 적절한 권한을 부여해야 하는데, 보통 PUID와 PGID를 사용합니다. 저는 1000:1000 (기본 사용자/그룹)으로 설정했습니다.
Immich는 여러 서비스(PostgreSQL, Redis, Microservices 등)로 구성되어 있어서 도커 컴포즈(Docker Compose)로 한 번에 배포하는 게 가장 편리합니다. Immich 공식 GitHub 저장소에서 예시 docker-compose.yaml 파일을 가져오는 게 좋아요. 저는 항상 최신 버전을 확인하고 수정해서 사용합니다.
# OMV SSH 접속 후 작업 디렉토리 생성
mkdir -p /srv/dev-disk-by-uuid-XXXX/config/immich
cd /srv/dev-disk-by-uuid-XXXX/config/immich
# Immich GitHub에서 docker-compose.yaml 다운로드 (최신 버전 확인 필수)
wget https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget https://github.com/immich-app/immich/releases/latest/download/.env
다운로드한 .env 파일과 docker-compose.yml 파일을 열어서 몇 가지를 수정해야 합니다.
.env 파일 수정:
UPLOAD_LOCATION=./upload 부분을 OMV에서 생성한 공유 폴더 경로로 변경합니다. 예: UPLOAD_LOCATION=/data/immich/upload (컨테이너 내부 경로)
DB_PASSWORD, REDIS_PASSWORD 등을 강력한 비밀번호로 변경하세요.
TZ=Asia/Seoul 처럼 시간대를 설정합니다.
docker-compose.yml 파일 수정:
각 서비스의 volumes 섹션에서 OMV 공유 폴더와 연결되는 부분을 확인하고 수정합니다. 특히 ./upload:/usr/src/app/upload 부분을 /srv/dev-disk-by-uuid-XXXX/data/immich:/usr/src/app/upload (호스트 경로:컨테이너 내부 경로) 형태로 맞춰줘야 합니다.
PUID, PGID 환경 변수를 OMV에서 설정한 사용자/그룹 ID에 맞춰주세요.
이 부분이 사실 제가 겪었던 가장 큰 삽질의 핵심이었습니다. 😅 볼륨 마운트 경로를 잘못 지정하거나 권한이 없어서 컨테이너가 파일을 못 읽는 경우가 정말 많거든요. 항상 호스트 경로와 컨테이너 내부 경로가 정확히 매핑되는지, 그리고 해당 호스트 폴더에 컨테이너가 접근할 수 있는 권한이 있는지 꼼꼼히 확인해야 합니다.
그림 2: Immich Docker Compose 설정 파일 예시 (볼륨 및 환경 변수)
3. Immich 서비스 실행
파일 수정이 끝났다면, 이제 도커 컴포즈를 이용해 서비스를 실행합니다. OMV SSH 터미널에서 docker-compose.yml 파일이 있는 디렉토리로 이동한 다음 아래 명령어를 실행하세요.
docker compose up -d
-d 옵션은 백그라운드에서 컨테이너를 실행하라는 의미입니다. 컨테이너들이 모두 정상적으로 올라오는지 docker compose ps 명령어로 확인해볼 수 있습니다.
⚠️ 주의사항 및 트러블슈팅: 제가 겪은 삽질들
제가 이 OpenMediaVault와 Immich 연동 구성을 하면서 가장 많이 겪었던 문제들은 역시 권한(Permissions)과 볼륨 마운트(Volume Mount)였습니다. 특히 OMV의 공유 폴더와 도커 컨테이너 간의 권한 문제가 많았어요. 홈랩에서 사진 백업을 구축할 때 이 부분을 간과하면 정말 답답하더라고요.
권한 문제 (Permission Denied): Immich 컨테이너가 OMV 공유 폴더에 사진을 저장하거나 데이터베이스 파일을 생성할 때 ‘Permission Denied’ 에러가 발생하는 경우가 많았습니다. 이럴 때는 OMV에서 해당 공유 폴더의 ACL(Access Control List) 설정을 확인하거나, SSH로 접속해서 직접 chown 명령어로 소유권을 변경해줘야 합니다. 예를 들어, sudo chown -R 1000:1000 /srv/dev-disk-by-uuid-XXXX/data/immich 이런 식으로요. PUID, PGID 값과 일치시켜주는 게 정말 중요합니다.
리소스 부족 (Resource Exhaustion): Immich는 생각보다 많은 리소스를 사용합니다. 특히 처음 사진을 인덱싱(Indexing)하고 AI 기능을 사용할 때 CPU와 RAM 사용량이 급증할 수 있어요. 저사양 NAS나 라즈베리 파이(Raspberry Pi) 같은 장비에선 버벅거릴 수 있습니다. 저는 N100 기반 미니 PC에 16GB RAM을 사용하는데, 이 정도면 충분하더라고요. 나스 환경의 사양을 고려해서 구축해야 합니다.
포트 충돌 (Port Conflict): 만약 OMV에서 다른 서비스가 Immich와 동일한 포트(기본 2283)를 사용하고 있다면 충돌이 발생할 수 있습니다. docker-compose.yml 파일에서 Immich 서버의 포트를 다른 번호로 변경해주거나, 기존 서비스의 포트를 변경해야 합니다.
이런 문제들을 하나씩 해결해나가면서 ‘아, 역시 인프라 엔지니어는 삽질의 연속이구나’ 싶었지만, 각각을 해결할 때마다 느껴지는 성취감이 있었어요. 💡
설치 검증 및 결과 확인 🎉
모든 컨테이너가 정상적으로 실행되면, 웹 브라우저를 열고 http://[OMV_IP_주소]:2283으로 접속하면 됩니다. 처음 접속하면 관리자 계정을 생성하라는 화면이 나올 거예요. 계정을 만들고 로그인하면 드디어 Immich의 멋진 인터페이스를 만날 수 있습니다!
모바일 앱을 설치해서 OMV 서버의 IP 주소와 포트를 입력하면 스마트폰 사진을 자동으로 백업할 수 있어요. 실제로 제가 갤러리 앱에서 사진 몇 장을 찍어보니 Immich 웹 UI에 바로바로 동기화되더라고요. 정말 신기하고 뿌듯했습니다. 🤩
그림 3: Immich 웹 UI (사진 업로드 및 타임라인)
가족 사진, 여행 사진, 친구들과의 추억까지! 이제 모두 제 OMV 나스에 안전하게 보관되고, Immich의 강력한 기능으로 편리하게 관리할 수 있게 되었습니다. 프라이버시(Privacy) 걱정 없이, 원하는 만큼의 용량을 마음껏 쓸 수 있다는 점이 가장 큰 장점 같아요.
마무리하며: 나만의 사진 클라우드, 그 다음은?
OpenMediaVault와 Immich를 연동해서 나만의 프라이빗 사진 클라우드를 구축하는 과정, 어떠셨나요? 처음에는 조금 복잡하게 느껴질 수도 있지만, 한 번 구축해두면 정말 든든한 나만의 사진 보관소가 생기는 겁니다. 데이터 주권을 되찾고, 클라우드 서비스 구독료도 절약할 수 있으니 일석이조죠.
저는 여기서 멈추지 않고, Nginx Proxy Manager 같은 리버스 프록시(Reverse Proxy)를 이용해 외부에서도 안전하게 접속할 수 있도록 설정할 계획입니다. 또, 백업 전략(Backup Strategy)도 빠뜨리지 않고 구현해야 하겠더라고요. Raid는 백업이 아니라는 점, 다들 아시죠? 😉
여러분도 제 경험을 바탕으로 나만의 프라이빗 사진 클라우드 구축에 도전해 보시길 강력히 추천합니다. 궁금한 점이 있으시다면 언제든지 댓글로 남겨주세요! 다음에는 Nginx Proxy Manager를 활용한 외부 접속 설정에 대해 다뤄볼까 합니다. 기대해주세요!
안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 많은 분들이 고민하시는 구글 포토(Google Photos) 대안에 대한 이야기를 해볼까 합니다. 특히 저처럼 홈랩(Homelab)을 운영하며 데이터 주권에 관심이 많으신 분들이라면 더욱 공감하실 거예요.
아마 많은 분들이 구글 포토의 편리함 때문에 사진 백업에 사용하셨을 겁니다. 저도 그랬거든요. 그런데 정책이 바뀌면서 무료 용량이 제한되고, 내 소중한 사진들이 과연 안전하게 잘 관리되고 있는 건지, 상업적으로 활용될 여지는 없는지 같은 걱정들이 스멀스멀 올라오더라고요. 그래서 “내 손으로 직접 내 사진을 관리하자!”는 생각으로 자가 호스팅(Self-hosting) 사진 갤러리 구축을 결심했습니다. 그리고 그 해답은 바로 OpenMediaVault(OMV)와 Immich의 조합이었습니다.
처음엔 이게 뭔가 싶었는데, 막상 해보니 꽤나 만족스러웠습니다. 물론 삽질 좀 했지만요. ㅎㅎ 오늘은 제가 직접 OMV에 Immich를 연동해서 구글 포토 대안을 구축한 실제 사례와 함께, 삽질하며 얻은 팁들을 솔직하게 공유해 드릴게요. 혹시 이런 경험 있으신가요? 지금부터 저와 함께 나만의 NAS 사진 동기화 솔루션을 만들어 봅시다!
홈랩 환경에서 OMV와 Immich가 어떻게 연동되어 사진을 관리하는지 보여주는 간략한 아키텍처입니다.
1. 왜 OMV와 Immich 조합일까요?
먼저 핵심 개념부터 쉽게 풀어볼까요? 💡
OpenMediaVault (OMV): OMV는 NAS(Network Attached Storage) 운영체제입니다. 쉽게 말해, 집에 남는 PC나 라즈베리 파이 같은 장치에 설치하면 그걸 훌륭한 나스 서버로 바꿔주는 소프트웨어예요. 안정적이고 다양한 플러그인을 지원하며, 특히 Docker(도커)를 공식적으로 지원해서 컨테이너 기반의 애플리케이션들을 쉽게 올릴 수 있다는 큰 장점이 있습니다.
Immich: Immich는 자가 호스팅(Self-hosted) 사진 및 비디오 백업 솔루션입니다. 구글 포토와 거의 흡사한 기능을 제공하는데, 내 서버 위에서 돌아간다는 게 가장 큰 차이점이죠. 모바일 앱으로 자동 백업, 얼굴 인식, 객체 인식, 검색, 타임라인 뷰 등 편리한 기능들이 많아서 “이거 진짜 물건이네!” 싶더라고요. 활발하게 개발되고 있으며, 이미 실사용에 충분히 안정화되어 있습니다.
제가 이 둘을 선택한 이유는 명확합니다. OMV의 안정적인 NAS 환경 위에 Docker로 Immich를 올리면, 내 데이터는 내 서버에 안전하게 보관하면서도 구글 포토 못지않은 편리함을 누릴 수 있기 때문이죠. 데이터 주권(Data Sovereignty)을 확보하는 동시에, 비용 부담 없이 대용량 사진 갤러리를 운영할 수 있다는 게 가장 큰 매력이었습니다.
2. OMV에 Docker와 Immich 설치하기: 실전 구현
자, 그럼 이제 본격적으로 구축 과정을 살펴볼까요? OMV에 Docker를 설치하는 방법은 다양하지만, 저는 Portainer(포테이너)를 활용하는 것을 추천합니다. 웹 UI로 Docker 컨테이너를 관리하기가 훨씬 편하거든요.
2.1. OMV에 Docker 및 Portainer 설치
OMV 웹 UI에 접속해서 ‘시스템’ > ‘플러그인’ 메뉴로 이동합니다.
openmediavault-omvextrasorg 플러그인을 설치합니다. 이 플러그인이 Docker 설치를 위한 저장소를 추가해 줍니다.
플러그인 설치 후, ‘OMV-Extras’ > ‘Docker’ 탭으로 이동해서 ‘Docker 설치’ 버튼을 클릭합니다. 잠시 기다리면 Docker가 설치될 겁니다.
이어서 ‘Portainer 설치’ 버튼을 클릭하면 Portainer 컨테이너도 함께 설치됩니다. 설치가 완료되면 OMV IP 주소:9000으로 접속해서 Portainer 웹 UI를 확인할 수 있습니다. 🎉
Portainer에 접속했다면, 이제 Immich를 배포할 차례입니다. Immich는 여러 개의 컨테이너로 구성되어 있어서 Docker Compose를 사용하는 게 일반적이에요. Portainer에서 ‘Stacks’ 메뉴로 가서 ‘Add stack’을 클릭하고, 아래와 같이 docker-compose.yml 파일을 작성해 주세요.
⚠️ 중요: 볼륨 경로와 환경 변수는 본인의 OMV 환경에 맞게 반드시 수정해야 합니다.
Portainer에서 Immich 스택을 생성할 때 사용하는 Docker Compose 파일 예시입니다.
version: '3.8'
services:
immich-server:
container_name: immich_server
image: ghcr.io/immich-app/immich-server:release
command: ['start.sh', 'immich']
volumes:
- /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich/upload:/usr/src/app/upload # OMV 공유 폴더 경로로 변경
- /etc/localtime:/etc/localtime:ro
env_file:
- .env
ports:
- 2283:3001 # Immich 웹 UI 포트
depends_on:
- immich-redis
- immich-database
restart: always
immich-microservices:
container_name: immich_microservices
image: ghcr.io/immich-app/immich-microservices:release
command: ['start.sh', 'microservices']
volumes:
- /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich/upload:/usr/src/app/upload # OMV 공유 폴더 경로로 변경
- /etc/localtime:/etc/localtime:ro
env_file:
- .env
depends_on:
- immich-redis
- immich-database
restart: always
immich-web:
container_name: immich_web
image: ghcr.io/immich-app/immich-web:release
command: ['start.sh', 'web']
env_file:
- .env
ports:
- 2284:3000 # Immich 웹 UI 포트 (Reverse Proxy 사용 시 변경 가능)
restart: always
immich-redis:
container_name: immich_redis
image: redis:7.2-alpine@sha256:98f5a8ee0f30e0f99bc3f4f7ba05e3c58c72331f965f858a3bc5fa8e8e4f13d8 # 최신 권장 버전
restart: always
immich-database:
container_name: immich_database
image: postgres:15-alpine@sha256:0ea5f42eab7ac1c03c87b7b75fcace28ebaa1f6abcff02ef9ef2999b3f06c36e # 최신 권장 버전
environment:
POSTGRES_USER: immich # 변경 가능
POSTGRES_PASSWORD: your_strong_password # **매우 중요: 강력한 비밀번호로 변경하세요!**
POSTGRES_DB: immich # 변경 가능
volumes:
- /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich/database:/var/lib/postgresql/data # OMV 공유 폴더 경로로 변경
restart: always
immich-proxy:
container_name: immich_proxy
image: ghcr.io/immich-app/immich-proxy:release
ports:
- 2285:8080 # Immich 외부 접근 포트 (Reverse Proxy 사용 시 변경 가능)
environment:
IMMICH_SERVER_URL: http://immich-server:3001
IMMICH_WEB_URL: http://immich-web:3000
depends_on:
- immich-server
- immich-web
restart: always
💡 팁: OMV에서 /srv/dev-disk-by-uuid-YOUR_DISK_UUID 경로는 실제 디스크의 UUID 기반 경로입니다. ‘스토리지’ > ‘파일 시스템’에서 확인하거나, ‘스토리지’ > ‘공유 폴더’를 만들고 해당 폴더의 실제 경로를 확인하여 사용하세요. 저는 /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich 아래에 upload와 database 폴더를 미리 만들어두고 권한을 abc:users (UID 998, GID 100)로 설정했습니다. Docker 컨테이너의 기본 유저는 node (UID 1000)인 경우가 많으니, 권한 문제(Permission Denied)로 고생하지 않으려면 미리 공유 폴더의 소유자(Owner)와 그룹(Group)을 root:users로 설정하거나, Docker Compose 파일 내 Immich 서비스에 user: "1000:100" 같은 형태로 지정해 주는 것도 좋은 방법입니다.
2.3. 환경 변수 파일 (.env) 작성
Docker Compose 파일과 같은 경로에 .env 파일을 생성하고 아래 내용을 채워 넣으세요. API_KEY는 직접 생성해야 합니다.
DB_HOSTNAME=immich-database
DB_USERNAME=immich
DB_PASSWORD=your_strong_password # 위에서 설정한 비밀번호와 동일하게!
DB_DATABASE_NAME=immich
REDIS_HOSTNAME=immich-redis
NODE_ENV=production
# Immich API Key (https://immich.app/docs/install/environment-variables/ 참고)
# openssl rand -base64 64 로 생성 가능
IMMICH_API_KEY=your_generated_api_key_here
IMMICH_API_KEY는 openssl rand -base64 64 명령어로 생성할 수 있습니다. 이걸 꼭 해주셔야 모바일 앱과 연동할 때 문제가 없어요. 저는 이걸 몰라서 한참 삽질했거든요. 😭
3. 주의사항 및 트러블슈팅: 삽질은 나만 한다! ⚠️
제가 겪었던 몇 가지 문제와 해결 팁을 공유합니다.
권한 문제(Permission Denied): 앞서 언급했듯이, OMV의 공유 폴더 권한 설정이 정말 중요합니다. Docker 컨테이너가 볼륨에 쓰기/읽기 권한이 없으면 제대로 작동하지 않거든요. chmod -R 775 /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich 같은 명령어로 권한을 넓게 주거나, chown -R abc:users /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich처럼 소유자를 Docker 컨테이너의 실행 유저와 맞춰주면 됩니다.
메모리 부족: Immich는 특히 사진 메타데이터 처리나 얼굴 인식 같은 작업을 할 때 꽤 많은 메모리를 사용합니다. 제 구형 NAS는 8GB RAM인데, 초기 동기화 시에는 버거워하더라고요. 최소 8GB 이상, 여유가 된다면 16GB RAM을 권장합니다.
초기 동기화 시간: 기존에 쌓아둔 사진이 많다면, 처음 Immich에 업로드하고 인덱싱하는 데 상당한 시간이 걸립니다. 여유를 가지고 기다리세요. 저는 며칠 걸렸습니다. 😅
외부 접속 설정 (Reverse Proxy): Immich를 외부에서 안전하게 접속하려면 Nginx Proxy Manager 같은 리버스 프록시(Reverse Proxy)를 설정하는 게 좋습니다. SSL(HTTPS) 적용은 필수죠! OMV에 Docker로 Nginx Proxy Manager를 설치하고 Immich 컨테이너의 포트(예: 2285)를 바라보게 설정하면 됩니다. 이 부분은 다음 기회에 더 자세히 다뤄볼게요.
4. 검증 및 결과: 드디어 내 손 안의 구글 포토! 🎉
모든 설정이 완료되고 Docker Compose 스택을 실행했다면, 잠시 후 Immich가 정상적으로 구동될 겁니다. 웹 브라우저에서 http://OMV_IP_주소:2285 (또는 Reverse Proxy 설정 시 도메인 주소)로 접속해 보세요. 멋진 Immich 로그인 화면이 나타날 겁니다.
최초 접속 시 관리자 계정을 생성하고 나면, 바로 Immich의 대시보드가 눈에 들어올 거예요. 모바일 앱(안드로이드/iOS 모두 지원)을 설치하고 서버 주소와 API 키를 입력하면, 스마트폰의 사진들을 자동으로 Immich 서버로 백업할 수 있습니다. 진짜 편리하더라고요!
Immich 웹 UI에 접속하여 사진들이 성공적으로 업로드되고 관리되는 모습입니다.
저는 이미 수만 장의 사진들을 Immich로 옮겨왔습니다. 얼굴 인식 기능도 꽤 정확하고, 검색 기능도 구글 포토 못지않게 잘 작동하더라고요. 내 서버에 내 사진이 있다는 심리적 안정감은 덤이고요. 😌
5. 마무리: 데이터 주권, 이제 시작입니다!
오늘은 OMV와 Immich를 연동하여 구글 포토 대안을 구축하는 과정을 상세히 소개해 드렸습니다. 물론 처음에는 삽질도 좀 하고, 설정에 시간을 꽤 투자했지만, 그만큼 얻는 것이 많다고 생각해요. 내 소중한 데이터를 내 손으로 관리할 수 있다는 것, 이보다 더 큰 만족감은 없더라고요.
Immich는 활발하게 개발되고 있는 프로젝트라서, 앞으로 더 많은 기능과 개선이 이루어질 거라 기대하고 있습니다. 혹시 구글 포토 대안을 찾고 계셨다면, OMV와 Immich 조합을 꼭 한번 시도해 보세요! 분명 후회하지 않으실 겁니다.
다음 글에서는 Immich의 외부 접속 보안을 강화하기 위한 Nginx Proxy Manager 설정 방법이나, 백업 전략에 대해 더 자세히 다뤄볼 예정입니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!