예, Plex는 다른 Docker 컨테이너와 GPU를 공유할 수 있는 경우가 많습니다. 하지만 동일한 장치를 두 컨테이너에 노출한다고 해서 어느 작업에도 성능이 예약되거나 보장되는 것은 아닙니다.
결정은 GPU, Linux 드라이버, 컨테이너 런타임, 작업 유형, 그리고 각 애플리케이션이 비디오 엔진·컴퓨팅·메모리를 사용하는 방식에 따라 달라집니다. Intel 내장 그래픽은 일반적으로 /dev/dri와 같은 Linux 장치 노드를 통해 노출되며, NVIDIA 컨테이너는 NVIDIA 컨테이너 런타임 또는 Docker GPU 예약을 사용합니다. 먼저 액세스를 구성한 다음 Plex와 두 번째 작업을 함께 실행하고, 실제로 중요하게 여기는 부하에서 Plex가 계속 하드웨어 트랜스코딩을 수행하는지 확인하세요.
먼저 Plex가 단독으로 GPU를 사용할 수 있는지 확인하세요
공유를 테스트하기 전에 다른 GPU 작업을 중지한 상태에서 Plex의 트랜스코딩을 하나 강제로 실행하세요. Plex는 해당 스트림에 하드웨어 가속이 사용되고 있다고 표시해야 하며, 호스트에서는 예상되는 비디오 엔진 또는 GPU 활동이 나타나야 합니다. Plex가 장치를 단독으로 사용하지 못한다면 다른 컨테이너를 추가할수록 원인 진단만 더 어려워집니다.
Plex 하드웨어 가속 스트리밍 가이드에서는 Docker 배포 환경에서 하드웨어 가속을 사용하려면 관련 커널 장치를 컨테이너에 노출해야 한다고 설명합니다. 호스트에서 감지된 GPU가 Plex에서도 자동으로 표시된다고 가정하지 말고, 플랫폼에 맞는 현재 장치 접근 방식을 사용하세요.
기준선으로 트랜스코딩 시작 시간, CPU 사용량, GPU·비디오 엔진 사용량, 재생 안정성을 기록하세요. 이렇게 하면 GPU 공유 테스트와 비교할 기준 결과를 확보할 수 있습니다. 깨끗한 기준선이 없으면 이후의 문제가 리소스 경합 때문인지, 원래 Plex GPU 설정 때문인지 알 수 없습니다.
두 번째 컨테이너에 동일한 장치를 의도적으로 노출하세요
NVIDIA의 경우 Docker Compose에서 서비스에 GPU를 개수 또는 장치 ID로 예약할 수 있습니다. 두 서비스가 동일한 GPU를 보도록 구성하면 런타임은 해당 장치를 양쪽에 노출할 수 있지만, 이는 액세스 제어일 뿐 독점적인 성능을 보장하는 계약이 아닙니다. Intel 또는 기타 Linux 장치의 경우 드라이버가 동시 사용을 허용하면 두 컨테이너에 동일한 관련 장치 노드에 대한 액세스 권한을 부여할 수 있습니다.
Docker의 Compose GPU 지원 문서에서는 서비스가 GPU 액세스를 요청하고 특정 장치 ID를 지정하는 방법을 보여 줍니다. GPU가 여러 개라면 테스트 중 Plex가 장치 사이를 임의로 전환하지 않도록 특정 장치를 사용하세요.
컨테이너를 다시 만들거나 앱 템플릿을 변경할 때마다 권한을 확인하세요. 두 번째 컨테이너가 작동한다고 해서 Plex에도 여전히 장치 액세스 권한이 있다는 뜻은 아니며, Plex 설정에서 하드웨어 가속이 활성화되어 있다고 표시된다고 해서 현재 스트림이 실제로 이를 사용한다는 뜻도 아닙니다.
두 작업을 함께 테스트하고 먼저 포화되는 리소스를 확인하세요
두 번째 작업을 대표적인 수준으로 시작한 다음, 기준선 테스트에 사용했던 동일한 Plex 트랜스코딩을 강제로 실행하세요. 재생 안정성, 트랜스코딩 속도, GPU 메모리, 비디오 엔진 사용률, CPU 폴백을 비교하세요. 다른 작업이 활성화된 경우에만 Plex가 하드웨어 모드에서 소프트웨어 모드로 전환되거나 버퍼링을 시작한다면, 이는 호환성 문제가 아니라 리소스 경합의 결과입니다.
ZimaSpace GPU 사전 점검 가이드에서는 장치 감지뿐 아니라 컨테이너 액세스와 스토리지·백업·미디어 작업이 결합된 부하에서도 계속 원활하게 응답하는지 확인할 것을 권장합니다. Plex가 유일한 서비스가 아닌 NAS에서는 이러한 전체 시스템 테스트가 특히 중요합니다.
두 작업이 서로 다른 GPU 엔진을 사용한다면 공유가 원활하게 작동할 수 있습니다. 반대로 두 작업이 동일한 비디오 인코딩·디코딩 엔진, 메모리 또는 전력·열 여유를 두고 경쟁하면 성능이 크게 저하될 수 있습니다. 전체 “GPU 사용률”이 낮다고 해서 Plex에 필요한 특정 비디오 엔진이 사용 가능한 상태라고 단정하지 마세요.
공유가 더 이상 적합하지 않은 시점을 정하세요
Plex가 하드웨어 모드를 유지하고, 두 번째 컨테이너가 목표를 달성하며, 결합된 부하에서도 NAS가 원활하게 응답한다면 공유 구성을 유지하세요. 장치 매핑과 권한이 일반적인 수명 주기 이벤트에서도 유지되는지 확인하기 위해 Plex를 다시 시작한 후와 두 번째 컨테이너를 다시 시작한 후에도 테스트를 반복하세요.
경합이 간헐적으로 발생한다면 스트리밍이 집중되는 시간대를 피해 두 번째 작업을 예약하거나 애플리케이션 수준의 제한을 추가하세요. 두 작업을 동시에 최대 부하로 실행해야 하고 한쪽이 다른 쪽의 리소스를 지속적으로 고갈시킨다면, 불안정한 우선순위 조정을 계속 시도하기보다 두 번째 가속기를 전용으로 할당하거나 한 작업을 다른 호스트로 옮기세요.
다른 컨테이너를 중지한 상태에서도 어느 한 컨테이너가 GPU를 잃는다면 드라이버 또는 런타임 문제 해결을 진행하세요. 공유 문제는 두 애플리케이션이 각각 독립적으로 장치에 액세스할 수 있고, 동시에 사용할 때만 장애가 발생한다는 사실을 확인한 후에 진단해야 합니다.
지원 및 팁
더 읽어보기

Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.

Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.

일관성이 깨진 데이터베이스를 백업하지 않고 Plex를 백업하는 방법
핵심 상태에는 Plex의 데이터베이스 백업을 사용하거나, 전체 앱 데이터 트리를 복사하기 전에 Plex를 중지한 다음 라이브 파일 복사본을 무작정 신뢰하지 말고 복원 가능성을 테스트하세요.

