Immich는 서버(NestJS/TypeScript), 웹(SvelteKit), 모바일(Flutter/Dart), 머신러닝 서비스(Python)를 한 모노레포에 묶은 자가호스팅 사진·영상 백업 플랫폼이다. 실측 기준 확장자별 분포를 보면 ts가 1,057개 파일·164,889줄로 가장 크고, dart가 829개 파일·90,593줄로 뒤를 잇는다. 서버와 웹 UI가 모두 TypeScript 계열이고 모바일 클라이언트는 Flutter로 별도 구현되어 있다는 뜻이다. svelte 파일 417개·42,231줄이 웹 UI를, sql 36개·9,454줄이 DB 마이그레이션을, py 34개·4,676줄이 ML 서비스(임베딩·얼굴 인식류 추정)를 각각 담당하는 구조로 보인다.
모바일 쪽은 Dart 위에 kt(35개·4,584줄)와 swift(28개·3,869줄), pbxproj(1개·1,298줄)가 추가로 붙어 있어 Flutter 앱 안에 안드로이드·iOS 네이티브 연동 코드가 별도로 존재함을 보여준다. 전체 3,454개 파일 중 테스트 파일이 482개로, 대략 7개 파일당 1개꼴로 테스트가 붙어 있는 셈이다. CI 워크플로우는 27개로, 서버·웹·모바일(안드로이드/iOS)을 각각 빌드·검증해야 하는 멀티 클라이언트 프로젝트치고는 상당한 투자가 들어가 있다.
가장 큰 단일 파일은 open-api/immich-openapi-specs.json(33,202줄)인데, 이는 API 스펙을 자동 생성해 커밋한 파일로 보인다. 손으로 짠 코드가 아니라 코드젠 산출물이 저장소 최대 파일 자리를 차지하고 있다는 점은, 이 프로젝트가 API 계약을 클라이언트 코드 생성의 기준점으로 삼고 있다는 신호로 읽을 수 있다.
하이라이트
가장 눈에 띄는 건 활동량이다. 관측 범위(섀로우 클론 depth 1000, 하한값) 안에서 최근 90일 커밋이 733건으로, 전체 관측 커밋의 대다수가 최근 넉 달(첫 관측 커밋 2026-05-04부터 2026-09-03까지) 안에 몰려 있다. 기여자도 129명으로, 소수 코어 팀이 아니라 넓은 기여자 풀이 유지되고 있음을 보여준다. topAuthors 목록에 renovate[bot]이 들어 있는 것도 참고할 만하다. 사람 기여자와 나란히 자동 의존성 업데이트 봇이 상위권에 있다는 건, 의존성 관리를 사람 손이 아니라 자동화 파이프라인에 맡기고 있다는 뜻이고, 이는 devDependencies 2개·dependencies 0개인 루트 package.json 구조와도 맞아떨어진다. 즉 루트는 워크스페이스 오케스트레이터 역할만 하고 실제 의존성은 각 서브패키지(server/web/mobile)에 흩어져 있는 전형적인 모노레포 패턴이다.
두 번째는 릴리스 리듬이다. 원격 태그가 330개라는 건, 짧은 주기로 버전을 계속 끊어왔다는 뜻이다. 자가호스팅 소프트웨어에서 이 정도 릴리스 빈도는 사용자 입장에서 업데이트 추적이 수월하다는 신호로 볼 수 있다.
세 번째는 테스트와 CI의 균형이다. 482개 테스트 파일과 27개 CI 워크플로우가 함께 존재한다는 건, 단일 언어·단일 배포 타깃 프로젝트가 아니라 웹·서버·안드로이드·iOS를 동시에 검증해야 하는 복잡도를 실제로 감당하고 있다는 뜻이다. 모노레포에서 클라이언트 종류가 늘어날수록 CI 매트릭스가 기하급수적으로 커지는데, 27개라는 숫자는 그 복잡도를 어느 정도 정면으로 받아들인 결과로 보인다.
주의점
라이선스는 AGPL-3.0(GNU AFFERO GENERAL PUBLIC LICENSE)이다. 일반적인 GPL과 달리 네트워크를 통해 수정본을 서비스로 제공하는 경우에도 소스 공개 의무가 발생하는 카피레프트 조항이 핵심이다. 그냥 내려받아 개인·팀 내부에서 자가호스팅하는 용도라면 문제될 게 없지만, 이 코드를 수정해서 별도 서비스로 재배포하거나 SaaS 형태로 운영할 계획이 있다면 이 조항부터 법무 검토가 필요하다.
실측 자체의 한계도 짚어야 한다. 이번 분석은 depth 1000 섀로우 클론 기준이라 commitCount(1,000)는 실제 전체 히스토리의 하한값이고, firstCommitInRange(2026-05-04)도 저장소 생성일이 아니라 관측 범위의 시작점일 뿐이다. 따라서 "최근 90일 733커밋"이라는 활동 밀도는 신뢰할 수 있지만, 프로젝트 전체 수명이나 총 커밋 수를 이 데이터만으로 단정할 수는 없다. 또한 hasAgentDocs가 false로 나온 걸 보면, AI 코딩 에이전트를 활용한 기여를 염두에 둔 별도 가이드 문서는 아직 마련돼 있지 않은 것으로 보인다.
실측 정보
헤드 커밋
26a25f0c
관측 커밋 수(섀로우 클론 depth 1000 기준 하한)
1,000+
최근 90일 커밋
733
기여자 수
129명
원격 태그(릴리스) 수
330
전체 텍스트 LoC / 파일 수
573,505줄 / 3,454개
CI 워크플로우 수
27개
적용점
P0 · 비용 낮음루트 package.json이 dependencies 0 / devDependencies 2로 잡히는 건 모노레포 워크스페이스 구조 때문이니, 실제 의존성 범위를 보려면 server/web/mobile 서브패키지의 lockfile을 먼저 확인할 것
P1 · 비용 중간자가 호스팅을 넘어 수정본을 서비스로 재배포할 계획이면 AGPL-3.0 네트워크 카피레프트 조항을 먼저 검토
P2 · 비용 낮음open-api/immich-openapi-specs.json(3만3천줄 이상)은 자동 생성 파일이라 diff 리뷰 도구에서 제외 설정해두는 게 낫다
◆ 도입 후보
최근 90일에 733커밋, 129명의 기여자, 27개 CI 워크플로우가 동시에 돌아가는 걸 보면 유지보수가 죽어있을 리스크는 낮다. 서버·웹·모바일·ML을 한 저장소에서 관리하는 구조라 자가 호스팅 사진 백업이 목적이면 그대로 도입할 만하다. 다만 라이선스가 AGPL-3.0이라 수정본을 네트워크 서비스로 재배포할 계획이 있다면 그 조항부터 검토해야 한다.
원문 README
아래는 immich-app/immich 저장소의 README 원문입니다(GitHub 렌더, 수집 시점 기준). 저작권은 원 프로젝트에 있으며 원 저장소의 라이선스를 따릅니다. GitHub에서 보기
README 전문 펼치기
High performance self-hosted photo and video management solution
