Jellyfin은 웹 서버와 별도로 반드시 온라인 상태여야 하는 단일 범용 백그라운드 작업자 서비스를 제공하지 않습니다. UI가 로드되지만 “작업자”가 오프라인으로 표시된다면, 해당 증상을 멈춰 있는 특정 백그라운드 작업으로 해석하세요. 예를 들면 라이브러리 검색, 메타데이터 새로 고침, 챕터 이미지 작업, 플러그인 작업 또는 기타 예약된 작업일 수 있습니다.
이 구분이 중요한 이유는 정상적인 HTTP 엔드포인트가 주 서버 프로세스가 시작되었다는 사실만 증명하기 때문입니다. 다음 단계는 실행되어야 하는 작업 하나를 식별하고, 마지막 결과와 관련 로그 줄을 확인한 다음, 데이터베이스, 쓰기 가능한 앱 데이터, 미디어 저장소, 플러그인 또는 작업별 리소스 중 처음 실패한 종속성을 따라가는 것입니다. 이미 UI를 제공하고 있는 서버를 재구축할 필요는 없습니다.
진행되지 않는 정확한 백그라운드 작업 식별
대시보드를 열고 동작을 관찰할 수 있는 예약된 작업 하나를 선택하세요. 마지막 실행 시간, 다음 실행 시간, 현재 상태, 수동으로 시작했을 때 변화가 있는지를 기록하세요. 유휴 상태인 모든 예약 작업을 하나의 “작업자 오프라인” 증상으로 묶지 마세요.
Jellyfin 소스 트리에는 서버의 전용 ScheduledTasks 구현이 문서화되어 있으며, 백그라운드 유지 관리가 일반적인 두 번째 데몬이 아니라 개별 예약 작업으로 처리된다는 점을 확인할 수 있습니다. Jellyfin ScheduledTasks 구현
한 작업만 실패하고 다른 작업은 완료된다면 계속 작업별로 조사하세요. 모든 작업이 시작되지 않는다면 개별 라이브러리 설정을 변경하기 전에 데이터베이스 상태, 데이터 디렉터리 권한 또는 시작 마이그레이션과 같은 공통 종속성을 확인하세요.
연쇄 오류의 마지막 메시지가 아니라 첫 번째 관련 오류 확인
작업이 트리거된 시간대의 Jellyfin 로그를 확인하세요. 작업 이름을 검색한 다음 위쪽으로 이동하여 데이터베이스 잠금을 얻지 못했거나, 경로를 열지 못했거나, 애플리케이션 데이터를 쓰지 못했거나, FFmpeg를 시작하지 못했거나, 플러그인 종속성을 로드하지 못한 이유를 설명하는 첫 번째 경고 또는 오류를 찾으세요.
Jellyfin 문제 해결 가이드는 서버 및 재생 문제를 진단할 때 로그를 가장 먼저 확인할 곳으로 권장하며, 디버그 로깅을 활성화하면 출력량이 매우 커질 수 있다고 설명합니다. Jellyfin 로깅 안내
일반 로그에서 원인을 확인할 수 없을 때만 디버그 로깅을 활성화하고, 작업 시도를 한 번 재현한 다음 로깅을 다시 일반 수준으로 되돌리세요. 관련 없는 여러 예약 작업이 노이즈를 생성하는 동안 디버그 로그를 계속 활성화해 두는 것보다 통제된 재현이 더 유용합니다.
데이터 디렉터리에 쓸 수 있고 데이터베이스가 진행 가능한지 확인
이동되었거나 다시 매핑된 데이터 경로에 이후 백그라운드 작업이 쓸 수 없는 경우에도 웹 UI는 표시될 수 있습니다. 작업 설정을 수정하기 전에 런타임 UID/GID, 데이터 디렉터리 소유권, 여유 공간, 컨테이너 마운트의 쓰기 가능 여부를 확인하세요.
Jellyfin 문제 해결 문서에는 검색 실패 시 데이터베이스 잠금 관련 안내가 포함되어 있으며, 컨테이너 문서에서는 설정 및 캐시의 지속성이 마운트된 경로에 따라 달라진다고 설명합니다. Jellyfin 영구 컨테이너 경로
로그에 데이터베이스 잠금 오류가 표시되면 데이터베이스를 삭제하지 말고 해당 병렬 작업을 줄이거나 문서화된 데이터베이스 잠금 문제 해결 절차를 따르세요. 권한 또는 읽기 전용 오류가 표시되면 정확히 해당 데이터 경로를 수정한 뒤 같은 작업을 다시 실행하세요.
라이브러리 작업을 실행하기 전에 미디어 저장소가 연결되어 있는지 확인
미디어 경로 중 하나가 없거나 마운트되지 않았거나 간헐적으로 느린 경우 검색 또는 유지 관리 작업이 정상적으로 동작할 수 없습니다. 작업을 수동으로 다시 실행하기 전에 호스트와 Jellyfin 런타임에서 동일한 라이브러리 경로가 존재하고 읽을 수 있는지 확인하세요.
Jellyfin은 미디어 저장소를 사용할 수 없을 때 예약된 유지 관리가 항목을 제거할 수 있다고 경고합니다. 예약된 유지 관리의 저장소 주의 사항 따라서 NAS나 외장 디스크가 올바르게 마운트되지 않은 상태라면 “그냥 검색을 다시 실행하는 것”은 좋은 첫 단계가 아닙니다.
마운트를 복구하자 작업이 완료된다면 작업자 자체가 근본 원인은 아니었던 것입니다. 호스트 재부팅 후에도 Jellyfin의 일반 유지 관리 시간 전에 경로를 사용할 수 있도록 마운트 순서 또는 저장소 안정성을 수정하고 다시 확인하세요.
플러그인 및 작업별 종속성 분리
플러그인이 소유한 작업이나 특정 기능의 작업 하나만 실패한다면 전역 Jellyfin 설정을 변경하지 말고 해당 구성 요소를 점검하세요. 플러그인 업데이트, 서버 업그레이드, 경로 변경 또는 종속성 변경 이후에 실패가 시작되었는지 비교하세요.
의심되는 선택적 구성 요소만 비활성화하거나 롤백하고, 주 서버, 데이터베이스 및 관련 없는 작업은 유지하세요. ZimaSpace의 단일 서비스 복구 방식도 정상적인 종속성을 보존하면서 실패한 서비스 하나를 분리한다는 동일한 원칙을 따릅니다.
작업이 Jellyfin 핵심 기능의 일부이고 로그가 특정 버전의 회귀 문제를 가리킨다면, 문제를 제기하기 전에 로그와 정확한 서버 버전을 보존하세요. 플러그인 실패를 모든 영구 데이터를 다시 생성해야 할 이유로 일반화하지 마세요.
재시작은 검증 단계로만 사용
입증된 종속성 하나를 수정한 후 실패한 작업을 수동으로 시작하여 예상 완료 상태에 도달하는지 확인하세요. 그런 다음 Jellyfin을 한 번 재시작하고 작업을 다시 실행하거나 다음 예약 시간을 기다려 정상적인 서비스 시작 후에도 수정 사항이 유지되는지 확인하세요.
실패한 종속성을 설명하지 못한 채 재시작만으로 증상이 일시적으로 사라진다면 지속적인 해결이 아닙니다. 문제가 다시 발생하면 권한, 데이터베이스, 플러그인 설정을 동시에 더 변경하지 말고 새로 발생한 첫 번째 오류를 원래 오류와 비교하세요.
대상 작업이 재시작 후 완료되고 예상 출력이 나타나며 다른 예약 작업도 정상적으로 유지되면 조사를 중단하세요. 저장소와 권한이 확인되었는데도 동일한 핵심 작업이 계속 실패한다면 작업 이름, 버전, 첫 번째 오류, 데이터 경로 상태 및 재현 절차를 포함하여 문제를 제기하세요.
지원 및 팁
더 읽어보기

Home Assistant를 실행 중에 백업해야 할까요, 아니면 먼저 서비스를 중지해야 할까요?
내장된 Home Assistant 백업은 실행 중에도 진행할 수 있지만, 일반 파일 시스템 복사본을 만들 때는 데이터베이스가 일관되게 백업되지 않는 한 Home Assistant를 중지하거나 일시...

유휴 시간에 Home Assistant 서버가 뜨겁거나 시끄럽게 작동하는 이유는 무엇인가요?
냉각이나 CPU 제한을 변경하기 전에 Recorder, 백업, 통합 구성 요소 및 함께 실행되는 작업을 통해 Home Assistant의 팬 작동 또는 온도 급증 원인을 분석하세요.

Home Assistant를 수리하기보다 다시 구축해야 할 때는 언제인가요?
먼저 실패한 Home Assistant 계층 중 가장 작은 부분을 복구하고, 다음으로 검증된 정상 상태를 복원하며, 지속적인 구성을 신뢰할 수 없을 때만 다시 구축하세요.

