Jellyfin, Seerr, JellyBridge는 하나의 ZimaOS 앱을 구성하는 세 부분이 아닙니다. 2026년 6월 IceWhale 커뮤니티 스레드는 스택을 계층별로 나누어 보면서 더 쉽게 이해할 수 있게 되었습니다. Jellyfin은 미디어 서버이고, Seerr는 독립형 미디어 요청 애플리케이션이며, JellyBridge는 Jellyfin의 탐색 및 요청 작업을 Seerr에 연결하는 Jellyfin 플러그인입니다.
원 글 작성자는 이미 ZimaOS 앱 스토어에서 Jellyfin을 실행하고 있었지만 나머지 스택을 작동시키지 못했습니다. 커뮤니티 답변에서는 모든 설정을 한꺼번에 변경하기보다 각 계층을 독립적으로 진단할 것을 권장했습니다. 이후 한 사용자는 ZimaBoard 2에서 Jellyfin과 Seerr를 성공적으로 실행하고, Sonarr/Radarr 스택은 별도의 Raspberry Pi에서 실행하고 있다고 확인했습니다. 이는 URL, API 자격 증명, 네트워크 경로가 올바르다면 이러한 서비스가 동일한 컨테이너에 있거나 심지어 같은 컴퓨터에 있을 필요도 없다는 것을 보여줍니다.
먼저 Jellyfin → Seerr → JellyBridge 스택을 이해하세요
이 설정을 이해하는 가장 좋은 방법은 다음과 같습니다.
- Jellyfin: 기존 영화 및 TV 라이브러리를 제공하고 관리합니다.
- Seerr: 탐색과 미디어 요청을 제공한 다음, 승인된 요청을 Sonarr와 Radarr로 전송합니다.
- Sonarr/Radarr: TV 시리즈와 영화의 다운로드 워크플로를 처리합니다.
- JellyBridge: Jellyfin 내부에서 플러그인으로 실행되며 Seerr와 통신하여 Jellyfin에서 탐색하거나 즐겨찾기에 추가한 항목으로 요청을 생성할 수 있게 합니다.
현재 Seerr 문서에서는 Seerr를 Jellyfin, Plex, Emby용 미디어 요청 및 탐색 관리자로 설명하며, Sonarr와 Radarr를 기본으로 통합합니다. Seerr는 일반적으로 자체 Docker 컨테이너로 실행되며 포트 5055에서 웹 인터페이스를 제공합니다. 현재 Seerr 시작 가이드를 참조하세요.
Seerr는 Jellyseerr와 Overseerr를 잇는 현재의 후속 프로젝트입니다
한 커뮤니티 답변에서는 Seerr가 이전 Jellyseerr 애플리케이션을 대체했다고 설명했습니다. 현재 Seerr 프로젝트 문서에서도 Seerr가 Jellyseerr와 Overseerr 사용자를 위한 통합 후속 경로임을 확인할 수 있습니다.
이는 이전 JellyBridge 문서, 스크린샷, 환경 변수 또는 컨테이너 이름에 여전히 Jellyseerr라고 표시되어 있을 수 있기 때문에 중요합니다. 현재 JellyBridge 프로젝트는 테스트한 통합 환경에서 Seerr 3.x가 호환되는 API를 사용한다고 설명하면서도, 문서의 일부에서는 Jellyseerr라는 용어를 계속 사용합니다.
지금 이 스택을 구축하는 경우, 특정 플러그인 버전에서 명시적으로 요구하지 않는 한 더 이상 사용되지 않는 Jellyseerr 릴리스를 일부러 설치하지 말고 최신 Seerr부터 시작하세요.
1단계: JellyBridge를 설치하기 전에 Seerr 실행하기
Seerr 자체가 정상 작동하기 전에는 JellyBridge 문제를 해결하려 하지 마세요. Seerr를 별도의 ZimaOS Docker 애플리케이션으로 설치하거나 현재 시스템에서 지원되는 앱 소스를 사용하세요.
설치 후 Seerr 웹 인터페이스에 직접 접속해 확인하세요.
http://ZIMAOS_LAN_IP:5055ZimaOS 컨테이너 매핑에서 다른 외부 포트를 사용하는 경우 호스트 포트가 다를 수 있습니다. 실제 앱 설정에 표시된 호스트 측 포트를 사용하세요.
Seerr가 열리지 않으면 Jellyfin을 건드리기 전에 컨테이너를 확인하세요.
docker ps
docker images
docker logs SEERR_CONTAINER_NAME --tail 100해당 명령은 커뮤니티 스레드에서 제안된 첫 번째 문제 해결 점검 항목이었습니다. ZimaOS 빌드에서 Docker 명령에 호스트의 높은 권한이 필요한 경우 Docker 소켓 권한을 약화하지 말고 인증된 터미널 작업 흐름을 사용하세요.
2단계: Seerr를 Jellyfin에 연결
Seerr 설정 중에는 관리자 권한이 있는 Jellyfin 계정으로 Jellyfin을 구성하세요. 현재 Seerr 문서에 따르면 Jellyfin 설정 페이지에서 서버 연결과 라이브러리 동기화를 관리합니다.
계속하기 전에 다음 사항을 확인하세요.
- Seerr가 입력한 Jellyfin URL에 연결할 수 있습니다.
- 설정에 사용한 Jellyfin 계정에 필요한 관리자 권한이 있습니다.
- 동기화 후 Seerr에 Jellyfin 라이브러리가 표시됩니다.
- 수동 라이브러리 검사가 성공적으로 완료됩니다.
최신 Jellyfin 연결 절차는 Seerr 미디어 서버 설정 가이드를 참조하세요.
3단계: Seerr를 Sonarr 및 Radarr에 연결
Seerr는 미디어를 직접 다운로드하지 않습니다. 승인된 요청을 Sonarr와 Radarr로 전달하고, 이후 나머지 자동화 스택의 작업은 Sonarr와 Radarr가 조정합니다.
Sonarr와 Radarr는 다음과 같은 환경에서 실행할 수 있습니다.
- 동일한 ZimaOS 호스트에서 실행할 수도 있습니다.
- 서로 분리된 Docker 컨테이너에서 실행할 수도 있습니다.
- 다른 홈 서버에서 실행할 수도 있습니다.
- 또는 한 커뮤니티 사용자가 설명한 것처럼 별도의 Raspberry Pi에서 실행할 수도 있습니다.
중요한 요건은 연결 가능성입니다. Seerr는 Seerr 컨테이너 또는 호스트 컨텍스트에서 작동하는 주소를 사용해야 합니다. 노트북에서 작동하는 브라우저 URL이 컨테이너 간 통신에 올바른 주소인 것은 아닙니다.
ZimaOS 앱 스토어 컨테이너가 동일한 Docker 네트워크를 공유한다고 가정하지 마세요
커뮤니티 답변에서 가장 유용한 네트워킹 관련 경고는 ZimaOS 앱 스토어에서 설치한 Jellyfin 컨테이너가 수동으로 설치한 Seerr 컨테이너를 컨테이너 이름으로 자동 인식하지 못할 수 있다는 점이었습니다.
두 컨테이너가 동일한 사용자 정의 Docker 네트워크에 있다면 다음과 같은 서비스 이름을 사용할 수 있습니다.
http://seerr:5055작동할 수도 있습니다. 두 컨테이너가 서로 다른 Docker 네트워크에 있다면 다음과 같이 연결 가능한 호스트 주소와 게시된 포트를 대신 사용하세요.
http://ZIMAOS_LAN_IP:5055사용하지 마세요 localhost 컨테이너 간에 아무렇게나 localhost 는 별도의 Seerr 컨테이너가 아니라 Jellyfin 컨테이너 자체를 가리킵니다.
4단계: Jellyfin 내부에 JellyBridge 설치
JellyBridge는 Jellyfin 플러그인이며, Jellyfin을 대체하기 위해 필요한 또 다른 ZimaOS 앱이 아닙니다. 현재 프로젝트의 설치 방법에서는 Jellyfin 관리 인터페이스를 통해 플러그인 저장소를 추가하는 것을 권장합니다.
Jellyfin에서:
- 대시보드 > 플러그인을 여세요.
- 저장소 관리를 여세요.
- 프로젝트에서 제공한 JellyBridge 플러그인 저장소 URL을 추가하세요.
- 플러그인 카탈로그를 여세요.
- 사용 중인 Jellyfin 버전에 맞는 JellyBridge 빌드를 설치하세요.
- Jellyfin을 다시 시작하세요.
현재 JellyBridge 저장소에는 Jellyfin 10.10 및 10.11용 버전별 플러그인 빌드가 안내되어 있습니다. 패키지를 선택하기 전에 호환성 참고 사항을 확인하세요. JellyBridge 프로젝트 문서를 참조하세요.
5단계: JellyBridge가 Seerr에 연결되도록 구성
Jellyfin이 다시 시작되면 JellyBridge 플러그인 구성을 열고 다음을 입력하세요.
- Jellyfin에서 연결할 수 있는 Seerr URL
- 플러그인에 필요한 Seerr API 키
- JellyBridge 라이브러리 데이터를 위한 전용 디렉터리
- 사용할 동기화 동작입니다.
검색 콘텐츠를 가져오기 전에 플러그인의 연결 테스트 기능을 사용하세요. 테스트에 실패하면 아직 라이브러리를 더 만들지 마세요. 먼저 Seerr URL, Docker 네트워크 또는 API 키를 수정하세요.
6단계: JellyBridge 검색 라이브러리 생성
JellyBridge는 Jellyfin에서 라이브러리로 표시할 수 있는 자리 표시자 및 검색 콘텐츠를 생성합니다. 현재 플러그인 문서에는 해당 라이브러리를 생성하고 구성하는 플러그인 내 설정 절차가 포함되어 있습니다.
이 라이브러리는 실제 영화 및 TV 미디어 경로와 분리해 두세요. JellyBridge 검색 항목은 Sonarr, Radarr, Jellyfin에서 관리하는 실제 파일을 대신하지 않습니다.
사용자가 Jellyfin에서 지원되는 검색 항목을 즐겨찾기에 추가하면 JellyBridge가 해당 요청을 Seerr로 보낼 수 있습니다. 그러면 Seerr가 승인 처리를 담당하고 구성에 따라 Sonarr 또는 Radarr로 요청을 전달합니다.
커뮤니티 ZimaBoard 2 예시
이후 한 참여자는 ZimaBoard 2에서 Jellyfin과 최신 Seerr 애플리케이션을 함께 작동시켰으며, ARR 스택은 Raspberry Pi 4에서 실행했다고 말했습니다. 이는 이 아키텍처가 여러 시스템에 걸쳐 구성될 수 있다는 유용한 근거입니다.
ZimaBoard 하드웨어의 현재 제품 경로는 ZimaBoard 2 싱글 보드 서버입니다.
해당 답변에는 사용자의 정확한 Docker Compose 파일이나 네트워크 설정이 제공되지 않았으므로, 검증된 복사 후 붙여넣기용 구성으로 간주해서는 안 됩니다. 다만 각 통합 엔드포인트에 연결할 수 있다면 서비스를 분리할 수 있다는 아키텍처 측면의 가치가 있습니다.
다음 순서로 스택 문제 해결
- Jellyfin이 독립적으로 정상 작동하는지 확인하세요.
- Seerr 컨테이너가 계속 실행 중인지 확인하세요.
- Seerr 웹 UI를 직접 여세요.
- Seerr가 Jellyfin에 인증하고 라이브러리를 동기화할 수 있는지 확인하세요.
- Seerr가 Sonarr 및 Radarr에 연결할 수 있는지 확인하세요.
- 사용 중인 Jellyfin 버전과 호환되는 JellyBridge 버전을 설치하세요.
- JellyBridge에서 Seerr 연결을 테스트할 수 있는지 확인하세요.
- 연결 테스트가 통과한 후에만 JellyBridge 검색 라이브러리를 생성하세요.
- Jellyfin에서 요청을 하나 전송하고 Seerr에 표시되는지 확인하세요.
- 그런 다음 Seerr가 요청을 올바른 Sonarr 또는 Radarr 인스턴스로 전달하는지 확인하세요.
Jellyfin, Seerr 및 JellyBridge FAQ
Seerr에 별도의 Docker 컨테이너가 필요한가요?
예. Seerr는 독립형 요청 관리 애플리케이션입니다. JellyBridge는 Seerr와 통신하는 Jellyfin 플러그인입니다.
JellyBridge가 ZimaOS 앱 스토어 애플리케이션으로 표시되어야 하나요?
반드시 그런 것은 아닙니다. 현재 JellyBridge 프로젝트는 Jellyfin의 플러그인 저장소 시스템을 통해 설치하는 Jellyfin 플러그인으로 배포됩니다.
JellyBridge에서 localhost:5055 연결이 실패하는 이유는 무엇인가요?
Jellyfin과 Seerr가 별도의 컨테이너인 경우 localhost Jellyfin 내부의 localhost는 Jellyfin 컨테이너를 가리킵니다. 공유 Docker 네트워크 서비스 이름이나 Jellyfin 컨테이너가 실제로 연결할 수 있는 호스트/IP 주소를 사용하세요.
Jellyseerr와 Seerr 중 무엇을 설치해야 하나요?
새로 배포하는 경우 현재는 Seerr가 유지 관리되는 후속 경로입니다. JellyBridge 문서에는 전환이 최근에 이루어졌기 때문에 여전히 Jellyseerr 용어와 호환성 관련 참고 사항이 포함되어 있습니다. 따라서 설치하려는 Seerr 버전에 맞는 JellyBridge 릴리스를 확인하세요.
Sonarr와 Radarr를 다른 서버에서 실행할 수 있나요?
예. 커뮤니티 사용자가 정확히 그 구성을 설명했습니다. Seerr는 Sonarr/Radarr API 엔드포인트에 네트워크로 액세스하고 유효한 API 키를 사용하기만 하면 되며, 애플리케이션이 동일한 물리적 서버를 공유할 필요는 없습니다.
