13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] 미디어 서버

  • [홈서버] Docker on NAS로 Plex 미디어 서버 구축 가이드

    [홈서버] Docker on NAS로 Plex 미디어 서버 구축 가이드

    [홈서버] Docker on NAS로 Plex 미디어 서버 구축 가이드

    집에 NAS(Network Attached Storage, 네트워크 저장소) 한 대 두고 영화나 드라마, 가족 사진까지 한 번에 정리하고 싶다는 생각, 한 번쯤 해보셨을 겁니다. 저도 홈랩(Home Lab, 집에서 운영하는 개인 실험실) 굴리면서 가장 먼저 손댄 게 바로 Docker on NAS 환경이었거든요. 처음엔 “그냥 NAS 앱스토어에서 설치하면 되는 거 아닌가?” 싶었는데, 실제로 써보니까 업데이트 관리나 볼륨(volume, 데이터 저장 경로) 분리, 백업, 마이그레이션까지 생각하면 컨테이너(container, 격리된 실행 환경)로 올리는 쪽이 훨씬 편하더라고요.

    특히 Plex는 미디어 서버 입문용으로 정말 많이 선택되는데, 처음 세팅할 때는 라이브러리 경로, 권한, 네트워크 설정에서 헷갈리기 쉽습니다. 저도 처음엔 스캔이 안 돼서 한참 헤맸고, 나중엔 파일명 규칙 때문에 메타데이터까지 꼬였었네요. 이번 글에서는 제가 직접 해보며 정리한 Docker on NAS 기반 Plex 미디어 서버 구축 흐름을, 너무 복잡하지 않게 실전 위주로 풀어보겠습니다.

    Docker on NAS 기반 Plex 미디어 서버 아키텍처 개요 이미지

    NAS, Docker, Plex, 클라이언트 기기 간 연결 구조를 한눈에 보여주는 개요 이미지입니다.

    1. 왜 Docker on NAS로 Plex를 올리냐는 질문부터

    쉽게 말해 Docker on NAS는 “NAS 위에 앱을 깔되, 운영체제와 적당히 분리해서 관리하는 방식”입니다. 이 방식의 장점은 생각보다 큽니다. NAS 제조사 전용 패키지보다 유연하고, 나중에 다른 장비로 옮길 때도 편하거든요. 제가 예전에 패키지 방식으로만 쓰다가 장비 교체할 때 설정 백업이 꼬여서 고생했었는데, 컨테이너로 분리하고 나서는 훨씬 수월했습니다.

    • 설정과 데이터를 분리하기 쉽습니다.
    • 업데이트 롤백이 상대적으로 단순합니다.
    • 다른 서비스와 격리되어 충돌 위험이 줄어듭니다.
    • 재배포가 쉬워 홈랩 운영이 깔끔해집니다.

    반대로 단점도 있습니다. 권한 매핑(user/group mapping), 네트워크 모드, 저장 경로를 이해하지 못하면 설치는 됐는데 실제로는 아무것도 안 돌아가는 상황이 생깁니다. 여기서 중요한 포인트! 컨테이너는 만능이 아니라, 구조를 이해하고 쓰면 편하고 모르고 쓰면 더 복잡해지는 도구입니다.

    2. Plex와 컨테이너 개념, 여기서 한 번 정리하고 가겠습니다

    Plex는 미디어 파일을 스캔해서 라이브러리를 만들고, TV나 모바일, 웹 브라우저에서 재생할 수 있게 해주는 플랫폼입니다. 쉽게 말해 “내가 가진 파일로 직접 넷플릭스 비슷한 개인 미디어 서버를 만드는 느낌”에 가깝습니다.

    여기서 자주 나오는 용어를 헷갈리지 않게 정리해보면 이렇습니다.

    용어 영문 쉽게 설명하면
    컨테이너 Container 앱을 격리해서 돌리는 작은 실행 단위
    이미지 Image 컨테이너를 만들기 위한 실행 템플릿
    볼륨 Volume / Bind Mount 설정 파일과 미디어를 연결하는 실제 저장 경로
    트랜스코딩 Transcoding 재생 기기에 맞게 영상 형식을 변환하는 작업
    호스트 네트워크 Host Network 컨테이너가 NAS 네트워크를 직접 사용하는 방식

    처음엔 이게 뭔가 싶었는데, 실제로 써보니까 핵심은 딱 두 가지더라고요. 설정 파일은 따로 보존하고, 미디어 폴더는 읽기 쉬운 경로로 명확히 연결하는 것. 이 두 가지만 잡아도 절반은 끝납니다.

    3. 구축 전에 준비할 것: 폴더 구조와 권한 설계

    실전 들어가기 전에 먼저 폴더 구조를 잡겠습니다. 저는 NAS에서 애플리케이션 설정과 실제 미디어 데이터를 분리하는 편입니다. 나중에 백업하거나 다른 장비로 옮길 때 진짜 편하거든요.

    1. 애플리케이션 설정용 폴더를 만듭니다.
    2. 영화, 드라마, 음악 등 미디어 폴더를 구분합니다.
    3. Plex가 읽을 수 있는 권한을 확인합니다.
    4. 트랜스코딩용 임시 폴더를 별도로 둡니다.

    예시 구조는 아래처럼 잡으면 무난합니다.

    /volume1/docker/plex/config
    /volume1/docker/plex/transcode
    /volume1/media/movies
    /volume1/media/tv
    /volume1/media/music

    만약 NAS 경로가 다르면 본인 환경에 맞게 바꾸시면 됩니다. 중요한 건 이름보다 역할 분리입니다. 제가 예전에 config랑 media를 한 폴더에 뒤섞어놨다가 백업 정책이 꼬여서 한 번 크게 정리한 적이 있었습니다. 그 뒤로는 무조건 분리합니다.

    권한은 왜 중요할까요?

    Plex 컨테이너가 미디어 폴더를 읽지 못하면 라이브러리 스캔 자체가 실패합니다. 웹 화면은 멀쩡하게 뜨는데 파일이 안 보이는 경우가 딱 이 케이스입니다. NAS 제조사 UI에서 공유 폴더 권한을 주거나, Linux 계열 셸이 가능하면 소유자와 그룹을 정리해두세요.

    4. Docker Compose로 Plex 컨테이너 배포하기

    이제 본격적으로 올려보겠습니다. 저는 단일 실행 명령보다 Docker Compose를 선호합니다. 이유는 간단한데요. 나중에 다시 봐도 구조가 남고, 수정도 쉽고, 백업 문서처럼 쓸 수 있거든요.

    services:
      plex:
        image: lscr.io/linuxserver/plex:latest
        container_name: plex
        network_mode: host
        environment:
          - PUID=1000
          - PGID=1000
          - TZ=Asia/Seoul
          - VERSION=docker
        volumes:
          - /volume1/docker/plex/config:/config
          - /volume1/docker/plex/transcode:/transcode
          - /volume1/media/movies:/movies
          - /volume1/media/tv:/tv
          - /volume1/media/music:/music
        restart: unless-stopped

    몇 가지 설명을 붙이면 좋겠습니다.

    • network_mode: host는 Plex에서 자주 쓰는 방식입니다. 기기 탐색(discovery)이나 스트리밍 연결에서 편한 경우가 많습니다.
    • PUID / PGID는 파일 권한 맞출 때 중요합니다.
    • /config는 Plex 설정과 라이브러리 정보가 저장되는 핵심 경로입니다.
    • /transcode는 변환 작업 중 임시 파일을 두는 공간입니다.

    실행은 아래처럼 하면 됩니다.

    docker compose up -d

    실행 후에는 로그를 확인해보세요.

    docker compose logs -f plex

    여기서 에러 없이 올라오고, NAS IP 기준으로 Plex 웹 초기 설정 화면이 열리면 일단 절반은 성공입니다. 드디어 됐다! 싶은 순간이 여기더라고요.

    Docker on NAS에서 Plex 컨테이너 볼륨과 네트워크 구성 이미지

    컨테이너 볼륨 연결과 호스트 네트워크 구성을 이해하기 쉽게 보여주는 설정 이미지입니다.

    5. Plex 초기 설정과 라이브러리 구성, 여기서 품질이 갈립니다

    Plex 웹 UI에 들어가면 서버 이름을 정하고 라이브러리를 추가하게 됩니다. 여기서 대충 해도 돌아가긴 하는데, 나중에 정리가 엉망이 되기 쉽습니다. 제가 직접 해보니 폴더 구조와 파일명 규칙이 정말 중요하더라고요.

    라이브러리 등록 팁

    1. 영화와 TV 시리즈는 라이브러리를 분리합니다.
    2. 각 라이브러리에 맞는 루트 폴더만 지정합니다.
    3. 폴더명과 파일명은 가능한 일관되게 유지합니다.
    4. 한글 파일명만으로 안 풀릴 때는 영문 원제 병기를 고려합니다.

    예를 들면 영화는 /movies, 시리즈는 /tv 식으로 나누는 편이 좋습니다. 한 폴더에 다 몰아넣으면 스캐너가 헷갈릴 수 있거든요. 처음엔 귀찮아 보여도 나중에 메타데이터가 깔끔하게 붙는 걸 보면 왜 이렇게 하는지 이해가 되실 겁니다.

    트랜스코딩 최적화는 어떻게 볼까요?

    모든 환경에서 무조건 트랜스코딩이 필요한 건 아닙니다. 클라이언트가 원본을 직접 재생(Direct Play, 원본 그대로 재생)할 수 있으면 서버 부담이 줄어듭니다. 그래서 저는 무조건 성능 튜닝부터 하기보다, 먼저 원본 파일 형식과 클라이언트 재생 능력을 확인하는 쪽을 권합니다.

    • 가능하면 자주 쓰는 기기에서 직접 재생되는 파일 형식을 늘립니다.
    • 트랜스코딩 임시 폴더는 여유 공간이 있는 저장소에 둡니다.
    • 동시 재생 사용자가 많으면 CPU 사용률을 함께 봅니다.
    • 하드웨어 가속(Hardware Acceleration, 하드웨어 기반 인코딩/디코딩)은 지원 환경에서만 검토합니다.

    여기서 중요한 포인트! 성능 최적화는 설정 몇 줄보다도 내가 어떤 파일을 어떤 기기에서 주로 재생하느냐가 더 크게 좌우합니다.

    6. ⚠️ 실제로 많이 겪는 문제와 해결법

    이 섹션은 이론보다 실전입니다. 저도 여기서 삽질 좀 했습니다. 특히 Plex와 컨테이너 조합은 설치보다 트러블슈팅이 더 중요합니다.

    문제 1. 웹은 열리는데 미디어가 안 보입니다

    대부분 권한 문제이거나, 라이브러리 경로를 컨테이너 내부 기준으로 잘못 넣은 경우입니다.

    • NAS 폴더 권한을 다시 확인합니다.
    • Compose의 마운트 경로와 Plex 라이브러리 경로가 일치하는지 봅니다.
    • 예: 호스트의 /volume1/media/movies를 컨테이너에서 /movies로 마운트했다면, Plex에는 /movies를 등록해야 합니다.

    문제 2. 메타데이터가 엉뚱하게 붙습니다

    파일명 규칙 문제일 가능성이 큽니다. 시리즈 시즌 표기나 연도 표기가 빠져 있으면 인식이 흔들립니다. 저도 예전에 파일명 뒤에 릴리즈 그룹명이 너무 길게 붙어서 매칭이 꼬였던 적이 있었습니다.

    • 영화는 제목과 연도를 분리합니다.
    • 시리즈는 시즌/에피소드 표기를 일관되게 맞춥니다.
    • 폴더를 장르별이 아니라 콘텐츠 타입별로 나눕니다.

    문제 3. 재생은 되는데 버벅입니다

    이건 저장소 속도, 네트워크, 클라이언트 코덱 지원, 트랜스코딩 부하가 복합적으로 엮입니다. 그래서 저는 한 번에 모든 걸 바꾸지 않고 아래 순서로 확인합니다.

    1. 같은 파일을 다른 기기에서 재생해봅니다.
    2. 서버 자원 사용률을 확인합니다.
    3. 직접 재생인지 트랜스코딩인지 Plex 대시보드에서 확인합니다.
    4. 트랜스코딩 폴더 위치와 여유 공간을 봅니다.

    문제 4. 업데이트 후 설정이 꼬일까 걱정됩니다

    그래서 /config 백업이 중요합니다. 이 경로만 잘 보존해도 복구 난도가 확 내려갑니다. 실제로 써보니까 컨테이너 자체보다 설정 데이터가 더 중요하더라고요.

    7. 결과 검증: 제대로 구성됐는지 확인하는 체크리스트

    세팅이 끝났다면 감으로 끝내지 말고 검증을 해보세요. 홈랩은 “되는 것처럼 보이는데 사실 안 되는 상태”가 은근 많습니다.

    1. Plex 웹 UI에 정상 로그인되는지 확인합니다.
    2. 영화/TV/음악 라이브러리가 각각 보이는지 확인합니다.
    3. 썸네일과 메타데이터가 정상적으로 붙는지 확인합니다.
    4. 같은 네트워크의 TV, 모바일, 브라우저에서 각각 재생 테스트를 해봅니다.
    5. 컨테이너 재시작 후에도 설정이 유지되는지 봅니다.

    추가로 저는 아래 명령으로 컨테이너 상태를 꼭 확인합니다.

    docker ps
    docker inspect plex
    docker compose logs --tail=100 plex

    이렇게 보면 실행 상태, 볼륨 마운트, 최근 오류를 빠르게 점검할 수 있습니다. 문제 생겼을 때 가장 먼저 봐야 하는 건 화려한 대시보드보다도 로그인데요. 이건 정말 경험상 그렇습니다.

    Plex 미디어 서버 결과 검증 대시보드 이미지

    라이브러리 인식, 재생 상태, 서버 동작 여부를 확인하는 결과 화면 예시입니다.

    8. 운영 최적화 팁: 오래 편하게 쓰려면

    여기부터는 구축 이후 이야기입니다. 한 번 올리고 끝이 아니라, 계속 편하게 쓰려면 운영 습관이 중요합니다.

    운영 항목 권장 방향 이유
    설정 백업 /config 정기 백업 복구 시간을 크게 줄입니다
    폴더 구조 영화/시리즈/음악 분리 메타데이터 인식 안정성
    업데이트 무작정 자동화보다 확인 후 적용 갑작스러운 변경 리스크 감소
    모니터링 로그와 저장공간 주기 확인 장애 조기 발견

    혹시 이런 경험 있으신가요? 평소엔 멀쩡했는데 어느 날 라이브러리 갱신이 멈추거나, 새 파일이 안 뜨는 경우요. 대체로 원인은 복잡하지 않더라고요. 저장 공간 부족, 권한 변경, 경로 오타, 또는 업데이트 후 재시작 누락 같은 기본적인 이슈가 많습니다. 그래서 저는 화려한 자동화보다 단순하고 추적 가능한 운영 방식을 더 선호합니다.

    9. 정리와 FAQ: Docker on NAS로 Plex를 시작하려는 분께

    Docker on NAS 환경에서 Plex를 운영하는 핵심은 대단한 튜닝이 아니라, 경로 분리, 권한 정리, 로그 확인입니다. 저도 처음엔 컨테이너만 올리면 끝일 줄 알았는데, 실제로는 운영 구조를 깔끔하게 만드는 쪽이 훨씬 중요하더라고요. 근데 한 번 구조를 잡아두면 정말 편합니다. 장비를 바꾸거나 다른 미디어 서버 도구를 시험해볼 때도 훨씬 유연해지거든요.

    다음 단계로는 리버스 프록시(Reverse Proxy, 역방향 프록시) 붙이기, HTTPS 적용, 자동 백업, 그리고 다른 컨테이너 서비스와의 연동까지 가보셔도 좋습니다. 이전 글에서 Docker 기초를 다뤘다면 그 흐름으로 이어 보셔도 좋고, 다음 글에서는 NAS 홈랩 운영 관점에서 백업 전략도 다뤄볼 예정입니다.

    자주 묻는 질문

    • Q. NAS 기본 앱으로 설치하면 안 되나요?
      A. 됩니다. 다만 이식성과 관리 편의성을 생각하면 컨테이너 방식이 장기적으로 유리한 경우가 많습니다.
    • Q. Docker Compose가 꼭 필요할까요?
      A. 필수는 아니지만, 재현성과 문서화 측면에서 추천합니다.
    • Q. Plex가 꼭 정답인가요?
      A. 아닙니다. 하지만 입문 난이도와 생태계 면에서 여전히 많이 선택되는 편입니다.
    Docker on NAS와 일반 설치 방식 비교 요약 이미지

    운영 방식의 차이와 선택 포인트를 한 장으로 정리한 요약 이미지입니다.

    정리하면 이렇습니다. Plex를 NAS에 올릴 때는 설치 자체보다 구조가 중요하고, 구조를 잡을 때는 Docker on NAS 방식이 꽤 강력합니다. 처음 세팅만 조금 공들여두면 이후 운영은 훨씬 편해집니다. 저도 여러 번 갈아엎고 나서야 이 결론에 도달했는데, 지금은 새 장비로 옮길 때도 부담이 많이 줄었네요. 이 글이 같은 삽질을 줄이는 데 도움이 되었으면 좋겠습니다.

  • [Nas] Jellyfin 트랜스코딩 성능 벤치마크: N100 미니PC vs Ryzen 5700G NAS

    [Nas] Jellyfin 트랜스코딩 성능 벤치마크: N100 미니PC vs Ryzen 5700G NAS

    안녕하세요, 13년차 서버실 지킴이입니다. 😅 요즘 홈랩에서 미디어 서버 가지고 씨름하는 재미에 푹 빠져 있네요. 다들 Plex나 Emby 많이 쓰시겠지만, 저는 오픈소스의 매력에 빠져 Jellyfin을 열심히 굴리고 있습니다. 개인 미디어 라이브러리를 구축하고 언제 어디서든 원하는 콘텐츠를 스트리밍하는 건 정말 매력적인 일이거든요.

    근데 여기서 늘 고민되는 부분이 있죠? 바로 트랜스코딩(Transcoding) 성능입니다. 원본 파일을 그대로 재생할 수 없는 기기(낮은 대역폭, 특정 코덱 미지원 등)에서 미디어를 보려면, 서버에서 실시간으로 변환해줘야 하거든요. 이 과정이 서버에 꽤나 큰 부하를 줍니다.

    그래서 제가 직접 한번 비교해봤습니다. 요즘 가성비 미니PC로 핫한 N100 미니PC와, 제가 주력으로 쓰는 Ryzen 5700G 기반의 NAS에서 Jellyfin 트랜스코딩 성능이 얼마나 차이 나는지 말이죠. 혹시 어떤 하드웨어로 미디어 서버를 구축할지 고민 중이셨다면, 오늘 제 삽질 경험과 벤치마크 결과가 작은 힌트가 될 거예요! 함께 보시죠. 🚀

    N100 미니PC와 Ryzen 5700G NAS를 활용한 Jellyfin 미디어 서버 홈랩 아키텍처 다이어그램

    N100 미니PC와 Ryzen 5700G NAS를 활용한 Jellyfin 미디어 서버 홈랩 아키텍처 다이어그램

    💡 Jellyfin 트랜스코딩, 왜 중요할까요?

    자, 먼저 트랜스코딩(Transcoding)이 뭔지 쉽게 설명해 드릴게요. 쉽게 말해, ‘실시간 동영상 변환’이라고 생각하시면 됩니다. 우리가 스마트폰으로 4K 고화질 영화를 보려고 하는데, 인터넷 회선이 느리거나 스마트폰이 4K HEVC(H.265) 코덱을 제대로 지원하지 못할 때가 있잖아요? 이럴 때 Jellyfin 서버가 ‘아, 알겠어! 그럼 이 4K HEVC 영상을 1080p H.264로 바꿔서 보내줄게!’ 하고 실시간으로 변환해서 보내주는 게 바로 트랜스코딩입니다.

    이 과정이 중요한 이유는, 모든 기기가 모든 코덱과 해상도를 지원하지 않기 때문이에요. 특히 외부에서 접속할 때는 네트워크 대역폭 문제로 트랜스코딩이 필수적일 때가 많습니다. 문제는 이 변환 작업이 CPU 자원을 엄청나게 잡아먹는다는 점이죠. 그래서 우리는 하드웨어 트랜스코딩(Hardware Transcoding)에 주목해야 합니다.

    하드웨어 트랜스코딩은 CPU가 아닌 GPU(Graphics Processing Unit)에 내장된 전용 인코더와 디코더를 활용해서 처리하는 방식입니다. 인텔 CPU의 Quick Sync Video (QSV)나 AMD CPU의 Video Core Next (VCN) 같은 기술들이 여기에 해당하죠. 이 기능을 활용하면 CPU 부하를 획기적으로 줄이고, 훨씬 많은 동시 스트림을 처리할 수 있게 됩니다. Jellyfin은 이러한 하드웨어 가속 기능을 아주 잘 지원하는 고마운 미디어 서버입니다. 🎉

    🛠️ 실전 구현: Jellyfin 벤치마크 환경 구성

    본격적인 벤치마크를 위해 두 가지 시스템에 Jellyfin을 설치하고 설정해봤습니다. 둘 다 리눅스 기반 환경에서 Docker 컨테이너로 Jellyfin을 운영했습니다.

    1. N100 미니PC 환경

    • 프로세서: Intel N100 (4코어, 4스레드)
    • 내장 GPU: Intel UHD Graphics (Quick Sync Video 지원)
    • RAM: 16GB DDR5
    • OS: Ubuntu Server 22.04 LTS
    • Jellyfin 설치: Docker Compose

    N100은 저전력 프로세서로 유명하죠. 하지만 Quick Sync Video 덕분에 미디어 트랜스코딩 성능은 예상외로 꽤나 괜찮더라고요. 특히 전성비(전력 대비 성능)가 아주 훌륭합니다.

    2. Ryzen 5700G NAS 환경

    • 프로세서: AMD Ryzen 7 5700G (8코어, 16스레드)
    • 내장 GPU: Radeon Graphics (Video Core Next, VCN 지원)
    • RAM: 32GB DDR4
    • OS: Unraid OS (내부적으로 Linux 기반)
    • Jellyfin 설치: Docker Compose

    Ryzen 5700G는 CPU 성능도 강력하고, 내장 그래픽 성능도 꽤 괜찮아서 다재다능한 NAS 구축에 인기가 많죠. 과연 Jellyfin 트랜스코딩 성능에서는 어떤 모습을 보여줄까요?

    Jellyfin Docker 설치 및 하드웨어 가속 설정 (공통)

    기본적인 Jellyfin Docker Compose 설정은 다음과 같습니다. 하드웨어 가속을 사용하려면 /dev/dri 장치를 컨테이너에 매핑해주는 것이 핵심입니다.

    version: "3.8"
    services:
      jellyfin:
        image: jellyfin/jellyfin:latest
        container_name: jellyfin
        network_mode: host
        volumes:
          - /path/to/jellyfin/config:/config
          - /path/to/jellyfin/cache:/cache
          - /path/to/your/media:/media
          # 하드웨어 가속을 위한 장치 매핑
          - /dev/dri:/dev/dri
        devices:
          # 추가적으로 디바이스 직접 매핑 (N100/Intel QSV의 경우 필수)
          - /dev/dri/renderD128:/dev/dri/renderD128
          - /dev/dri/card0:/dev/dri/card0
        restart: unless-stopped
        environment:
          - PUID=1000
          - PGID=1000
          - TZ=Asia/Seoul
          # 추가적인 환경 변수 (예: NVIDIA GPU 사용 시)
          # - NVIDIA_VISIBLE_DEVICES=all
          # - NVIDIA_DRIVER_CAPABILITIES=all
    

    Jellyfin 웹 UI에 접속한 후, 관리자 대시보드 > 재생(Playback) 설정에서 하드웨어 가속 옵션을 선택해야 합니다. N100은 VAAPI를, Ryzen 5700G는 AMF 또는 VAAPI를 선택하고 선호하는 인코더/디코더를 설정해줍니다.

    Jellyfin 미디어 서버의 하드웨어 트랜스코딩 설정 화면 예시

    Jellyfin 미디어 서버의 하드웨어 트랜스코딩 설정 화면 예시

    ⚠️ 주의사항 및 트러블슈팅: 삽질은 나의 힘!

    제가 이 과정에서 겪었던 삽질 경험을 솔직하게 공유해 드릴게요. 😭

    1. 드라이버 문제: 하드웨어 가속은 단순히 장치를 매핑한다고 끝나는 게 아닙니다. 리눅스 환경에서 해당 GPU를 위한 드라이버와 라이브러리가 제대로 설치되어 있어야 하거든요.
      • N100 (Intel QSV): intel-media-va-driver-non-free (Debian/Ubuntu 계열) 패키지 설치가 필수였습니다. 처음엔 이것 때문에 VAAPI가 제대로 작동하지 않아서 ‘N100이 생각보다 별로인가?’ 하고 좌절했었죠. 🤦
      • Ryzen 5700G (AMD VCN): AMD는 인텔보다 드라이버 세팅이 까다로운 경우가 종종 있더라고요. mesa-va-drivers 같은 VAAPI 관련 패키지는 물론이고, 커널 모듈 (amdgpu)이 제대로 로드되어 있는지 확인해야 합니다. Unraid 같은 OS는 기본적으로 잘 세팅되어 있지만, 순수 Ubuntu에서는 조금 더 신경 써야 할 수 있어요.
    2. 권한 문제: Docker 컨테이너가 /dev/dri 장치에 접근할 권한이 없어서 문제가 발생하기도 합니다. Docker Compose 파일에 devices 섹션을 추가하고, 호스트 시스템에서 Jellyfin을 실행하는 사용자(PUID/PGID)가 video 그룹에 속해 있는지 확인하는 것이 중요합니다.
    3. 코덱 지원: 모든 GPU가 모든 코덱을 하드웨어 가속으로 지원하는 건 아닙니다. 특히 VP9, AV1 같은 최신 코덱이나 10비트 HEVC 같은 특정 포맷은 하드웨어 지원 여부를 확인해야 합니다. 제가 주로 테스트한 4K HEVC -> 1080p H.264 변환은 대부분의 최신 GPU에서 잘 지원하더라고요.

    이런 문제들 때문에 밤늦게까지 구글링하고 포럼을 뒤적거렸던 기억이 생생하네요. 😅 하지만 해결하고 나면 그 성취감이란! 여러분은 저처럼 삽질하지 마시라고 이렇게 자세히 적어봅니다. 💪

    📊 Jellyfin 트랜스코딩 벤치마크 검증 및 결과

    본격적인 벤치마크는 다음과 같은 방식으로 진행했습니다.

    • 테스트 파일: 4K HEVC (H.265) 10비트 영상
    • 트랜스코딩 목표: 1080p H.264
    • 측정 방법: 여러 클라이언트에서 동시에 스트리밍을 시작하며, 각 서버의 CPU 및 GPU 사용률, 그리고 버퍼링 발생 여부 확인
    • 모니터링 도구: htop (CPU), intel_gpu_top (N100 GPU), radeontop (Ryzen 5700G GPU), Jellyfin 대시보드 로그

    N100 미니PC 결과

    예상보다 훨씬 뛰어난 성능을 보여줬습니다! N100의 Intel Quick Sync Video는 정말 대단하더군요. 3개 정도의 4K HEVC -> 1080p H.264 동시 트랜스코딩은 무리 없이 소화해냈습니다. GPU 사용률은 70~80% 정도로 올라갔지만, CPU 사용률은 20~30% 정도로 매우 낮게 유지되면서 안정적인 스트리밍을 제공했습니다. 4개 스트림부터는 가끔 버퍼링이 발생하기 시작했거든요.

    저전력 미니PC에서 이 정도 성능이라니, 정말 인상 깊었습니다. 전력 소모도 아이들 시 10W 내외, 트랜스코딩 시 20W 내외로 매우 착했습니다. 💡

    Ryzen 5700G NAS 결과

    역시 Ryzen 5700G는 강력했습니다. 5~6개 정도의 4K HEVC -> 1080p H.264 동시 트랜스코딩도 거뜬히 처리했습니다. GPU 사용률은 50~60% 수준에서 안정적이었고, CPU 사용률도 N100과 마찬가지로 낮게 유지되었습니다. 7개 이상부터는 간헐적인 버퍼링이 발생하기 시작했거든요.

    N100보다 더 많은 동시 스트림을 처리할 수 있었고, 여전히 CPU 자원에 여유가 있어서 다른 NAS 작업(가상 머신, 다른 Docker 컨테이너 등)을 병행하기에도 충분했습니다. 다만, 전력 소모는 아이들 시 30W 내외, 트랜스코딩 시 50~60W 정도로 N100보다는 높았습니다.

    정리하자면 다음과 같습니다.

    Jellyfin 트랜스코딩 N100과 Ryzen 5700G의 동시 스트림 및 CPU/GPU 사용률 비교 그래프

    Jellyfin 트랜스코딩 N100과 Ryzen 5700G의 동시 스트림 및 CPU/GPU 사용률 비교 그래프

    마무리: 당신의 선택은?

    자, 이제 결론을 내릴 시간입니다. 어떤 시스템이 더 좋은 선택일까요?

    특성 N100 미니PC Ryzen 5700G NAS
    트랜스코딩 성능 (동시 스트림) 3~4개 (4K HEVC -> 1080p H.264) 5~6개 이상 (4K HEVC -> 1080p H.264)
    전력 소모 매우 낮음 (아이들 10W, 풀로드 20W 내외) 보통 (아이들 30W, 풀로드 50~60W 내외)
    가격 저렴 (10~20만원대) 높음 (30만원 이상, NAS 구성 시 더 높음)
    다용도성 Jellyfin 전용 미디어 서버로 최적 Jellyfin + NAS + VM 등 다용도 서버로 최적
    주요 장점 압도적인 전성비, 저렴한 구축 비용 강력한 CPU 성능, 높은 동시 스트림 처리, 높은 확장성
    추천 대상 1~3인 가구, 전력 소모에 민감한 사용자 3인 이상 가구, 다양한 서버 기능 원하는 사용자

    개인적인 생각으로는, 순수하게 Jellyfin 미디어 서버만을 위한 시스템을 구축한다면 N100 미니PC의 가성비와 전성비는 정말 타의 추종을 불허하더라고요. 저렴한 가격에 이 정도 성능을 뽑아준다는 건 정말 놀라운 일입니다. 혼자 또는 가족과 함께 사용하는 미디어 서버로는 충분하고도 남습니다.

    하지만 만약 NAS에 더 많은 기능(파일 서버, 백업, 가상 머신, 다른 Docker 서비스 등)을 올리고 싶고, 동시 스트림 사용자 수가 많다면 Ryzen 5700G 같은 더 강력한 프로세서가 탑재된 NAS가 좋은 선택이 될 거예요. 저처럼 홈랩에서 이것저것 실험하는 분들에게는 이쪽이 더 매력적일 수 있습니다.

    이번 벤치마크를 통해 하드웨어 가속의 중요성을 다시 한번 깨달았더라고요. 그리고 드라이버 세팅의 중요성도요! 😅 여러분도 자신의 환경과 예산에 맞춰 현명한 선택을 하시길 바랍니다. 다음번에는 Jellyfin과 Emby의 좀 더 심층적인 비교 분석으로 찾아올게요! 그때까지 즐거운 홈랩 생활 되세요! 👋

    N100 미니PC와 Ryzen 5700G NAS의 Jellyfin 미디어 서버 장단점 비교 인포그래픽

    N100 미니PC와 Ryzen 5700G NAS의 Jellyfin 미디어 서버 장단점 비교 인포그래픽

  • [HomeLabs] 홈서버 구축을 위한 미니PC vs NAS 비교: 용도별 최적 선택 가이드

    [HomeLabs] 홈서버 구축을 위한 미니PC vs NAS 비교: 용도별 최적 선택 가이드

    안녕하세요! 13년차 인프라 엔지니어 서버실입니다. 오늘은 홈서버를 고민하면서 한 번쯤 마주하는 딜레마, 바로 미니PC와 NAS 중 무엇을 선택해야 할까?에 대해 얘기해보려고 합니다. 저도 처음 홈랩을 꾸릴 때 이 문제로 좀 삽질했거든요. 단순 데이터 저장으로 시작했다가 나중엔 Plex 미디어 서버, Docker 컨테이너 여러 개를 돌리고 싶어지면서 ‘아, 그때 왜 이걸 몰랐을까?’ 후회한 적도 많습니다. 여러분도 저처럼 시행착오를 겪지 않도록, 제 경험을 바탕으로 용도별 최적의 선택 가이드를 알려드릴게요.

    홈서버 구축, 미니PC와 NAS 사이에서 고민하고 계신가요? 이 그림처럼 다양한 서비스들을 돌리고 싶을 때, 어떤 장치가 여러분에게 더 적합할지 함께 알아보시죠.

    자, 그럼 먼저 미니PC와 NAS가 정확히 무엇인지부터 알아볼까요?

    • 미니PC (Mini PC): 말 그대로 ‘작은 PC’입니다. 일반 데스크톱 PC의 기능을 그대로 담고 있지만, 크기만 작아진 형태죠. CPU, RAM, 저장 공간(SSD/HDD), 운영체제(Windows, Linux 등)를 자유롭게 설치할 수 있어서 활용도가 정말 높습니다. 쉽게 말해, 손바닥만 한 컴퓨터라고 생각하시면 됩니다. 제가 쓰는 인텔 NUC 같은 모델들이 대표적이죠.
    • NAS (Network Attached Storage, 네트워크 결합 스토리지): 이름에서 알 수 있듯이, ‘네트워크에 연결된 저장 장치’입니다. 기본적인 목적은 데이터를 저장하고 공유하는 거죠. 시놀로지(Synology)나 큐냅(QNAP) 같은 전문 제조사 제품들이 시장을 주도하고 있습니다. NAS는 보통 자체적인 운영체제(OS)를 가지고 있고, 파일 공유, 백업, 미디어 스트리밍 같은 특정 기능에 최적화되어 있습니다. 마치 데이터 저장에 특화된 전용 서버라고 보시면 됩니다.

    NAS와 미니PC, 어떤 걸 선택해야 할까?

    본격적으로 어떤 장치를 선택해야 할지 고민해보겠습니다. 결국 ‘무엇을 할 것인가?’에 따라 답이 달라지는데요, 제가 겪어본 경험을 바탕으로 용도별 장단점을 비교해드릴게요.

    💡 용도별 미니PC vs NAS 선택 가이드

    1. 단순 파일 저장 및 공유 (사진, 동영상 백업 등)
      • NAS가 유리합니다. 정말 편하고 안정적이거든요. 시놀로지 DS220+ 같은 모델들은 초기 설정도 간단하고, 모바일 앱 지원도 잘 되어 있어서 가족들과 사진 공유하기 정말 편합니다. 저도 처음엔 일반 PC에 하드를 연결해서 썼었는데, NAS만큼 편리한 건 없더라고요.
      • 미니PC: 물론 미니PC에도 스토리지를 달아서 파일 서버를 구축할 수 있습니다. FreeNAS(TrueNAS CORE)나 OpenMediaVault 같은 OS를 올리면 되지만, 초기 설정과 관리가 NAS 전용 제품보다 복잡한 편입니다. ‘삽질’을 즐기신다면야 도전해볼 만하죠!
    2. 미디어 서버 (Plex, Jellyfin 등)
      • 사용자 수와 트랜스코딩 요구사항에 따라 달라집니다.
        • 가족 단위 (1~2명) 및 간단한 트랜스코딩: 최신 NAS 모델들도 CPU 성능이 좋아져서 Plex나 Jellyfin을 돌리기에 충분합니다. 특히 하드웨어 트랜스코딩을 지원하는 모델(예: 인텔 셀러론 J4000 시리즈 이상 CPU 탑재 NAS)은 꽤 괜찮은 성능을 보여줍니다.
        • 다수 사용자, 4K 트랜스코딩, 복잡한 라이브러리: 미니PC가 훨씬 유리합니다. NAS의 CPU로는 버거운 경우가 많습니다. 제가 NUC에 Ubuntu 깔고 Plex Docker 컨테이너로 돌려보니, 여러 명이 동시에 4K 스트리밍을 해도 문제없더라고요. 특히 GPU가 있는 미니PC(예: AMD 라이젠 내장 그래픽)는 트랜스코딩에서 정말 강력한 성능을 발휘합니다.
      • ⚠️ 팁: Plex는 하드웨어 트랜스코딩 기능을 유료 구독(Plex Pass)해야 온전히 사용할 수 있습니다. 이 점도 고려하세요!
    3. Docker 컨테이너, 가상 머신(VM) 등 다양한 서비스 운영
      • 미니PC가 압도적으로 유리합니다. 자유로운 운영체제 선택(Ubuntu Server, Proxmox VE 등), 더 강력한 CPU/RAM 확장성 덕분에 Docker Swarm, Kubernetes 클러스터, 여러 개의 가상 머신을 띄우는 등 인프라 실험에 최적입니다. 저도 홈랩에서 쿠버네티스 클러스터를 미니PC 3대로 구성해서 돌리고 있거든요. 이 정도 자유도는 NAS에서는 기대하기 어렵습니다.
      • NAS: 일부 고급 NAS 모델(예: 시놀로지 플러스(+) 시리즈)에서도 Docker나 가상 머신 기능을 제공하지만, 리소스가 제한적이고 기능 확장성이 미니PC에 비해 떨어집니다. ‘맛보기’ 정도는 가능하지만, 본격적인 개발 환경이나 실험용으로는 부족하죠.
    4. 저전력 운영 및 24/7 (상시) 구동
      • NAS가 대체로 유리합니다. NAS는 애초에 저전력으로 설계된 경우가 많아 24시간 켜두어도 전기 요금 부담이 적습니다. HDD 절전 기능 등 전력 관리 기능도 잘 되어 있죠.
      • 미니PC: 최근 미니PC들도 저전력 CPU를 많이 사용해서 NAS 못지않게 전력 효율이 좋습니다. 특히 인텔 N 시리즈(N100, N305 등)나 AMD 젠(Zen) 아키텍처 기반의 APU를 탑재한 미니PC들은 꽤나 착한 전력 소비를 보여줍니다. 다만 고성능 CPU를 탑재한 모델은 NAS보다 전력을 더 많이 소비할 수 있습니다.

    미니PC와 NAS는 이렇게 내부 구조부터 차이가 있습니다. 미니PC는 PC의 유연성을, NAS는 스토리지 전문성을 갖췄다고 볼 수 있죠.

    비교표: 한눈에 보는 미니PC vs NAS

    제가 실제 사용하며 느꼈던 점들을 바탕으로 핵심적인 특징들을 표로 정리해봤습니다.

    항목 미니PC (Mini PC) NAS (Network Attached Storage)
    주요 목적 다목적 컴퓨팅, 다양한 서비스 호스팅 데이터 저장, 공유, 백업
    운영체제 Windows, Linux (Ubuntu, Debian), Proxmox VE 등 자유롭게 선택 제조사 고유 OS (DSM by Synology, QTS by QNAP 등)
    성능/확장성 CPU, RAM, GPU 등 업그레이드 및 확장이 용이 (모델에 따라 다름) 제한적 (RAM 업그레이드 정도, CPU 고정)
    초기 설정/편의성 OS 설치 및 서비스 설정에 기술 지식 필요, ‘삽질’ 가능성 높음 GUI 기반으로 쉬운 설정, 모바일 앱 지원, 사용자 친화적
    전력 소비 모델에 따라 다양 (고성능은 높음, 저전력 CPU는 낮음) 대체로 낮음, 전력 관리 기능 우수
    가격 가성비 좋은 모델부터 고성능 모델까지 다양, SSD/HDD 별도 구매 초기 구매 비용이 미니PC보다 높을 수 있음, HDD 별도 구매
    추천 용도 개발/실험용 서버, 다수의 서비스, 미디어 서버(고화질 트랜스코딩), VM/컨테이너 호스팅 가족용 파일 서버, 사진/동영상 백업, 간단한 미디어 스트리밍, 상시 구동

    저의 홈랩 서버 대시보드입니다. 미니PC로 구축하면 이렇게 다양한 서비스들을 한눈에 관리하고 리소스를 모니터링할 수 있죠.

    ⚠️ 실제 겪은 문제와 해결법 (트러블슈팅)

    제가 홈랩을 운영하면서 겪었던 몇 가지 문제점과 그 해결책을 공유해드릴게요.

    • 문제 1: NAS의 제한된 자유도: 처음엔 시놀로지 NAS로 시작했는데, Docker Compose로 복잡한 서비스를 띄우려니 제한적인 기능과 리소스 때문에 답답하더라고요. 결국 커뮤니티에서 비공식 패키지를 설치하거나, SSH로 들어가서 직접 설정하는 ‘꼼수’를 써야 했습니다.
      • 해결책: 결국 메인 서비스는 미니PC로 옮기고, NAS는 순수하게 ‘데이터 저장소’ 역할만 하도록 분리했습니다. 각자의 역할에 충실하게 쓰는 게 정신 건강에도 좋더라고요.
    • 문제 2: 미니PC의 초기 설정 난이도: NAS는 전원 켜고 웹 GUI만 들어가면 되는데, 미니PC는 OS 설치부터 네트워크 설정, 서비스 배포까지 전부 수동으로 해야 합니다. 처음엔 ‘이게 뭔가 싶었는데’ 터미널 명령어와 씨름하느라 밤을 새기도 했습니다.
      • 해결책: Proxmox VE 같은 하이퍼바이저를 설치해서 가상 머신(VM) 위에서 다양한 OS를 테스트하는 방식으로 접근했습니다. 한 번 설치해두면 여러 환경을 쉽게 만들고 지울 수 있어서 정말 효율적이더라고요. 그리고 Ansible 같은 자동화 도구를 활용해서 반복 작업을 줄였습니다.
        # Proxmox VE 설치 후 가상 머신 생성 예시 (간단화)
        pveam update
        pveam available --section system
        qm create 100 --name "ubuntu-server" --memory 2048 --net0 virtio,bridge=vmbr0
        qm importdisk 100 /var/lib/vz/template/iso/ubuntu-22.04.3-live-server-amd64.iso local-lvm
        # ... 이후 OS 설치 및 설정
    • 문제 3: 전력 소비량: ‘저전력 미니PC’라고 해서 샀는데, 막상 24시간 돌리니 생각보다 전기 요금이 많이 나오는 경우가 있었습니다. 특히 CPU 사용량이 많아지면 전력 소비도 훅 뛰더라고요.
      • 해결책: 주기적으로 전력 측정기(Kill-A-Watt 같은)로 실제 소비량을 측정하고, BIOS 설정에서 EIST, C-States 같은 전력 관리 옵션을 최적화했습니다. 불필요한 서비스는 꺼두고, 필요한 서비스만 Docker 컨테이너로 가볍게 돌려서 리소스 효율을 높였습니다.

    마무리: 배운 점 정리 + 다음 단계 제안

    자, 오늘은 홈서버 구축을 위한 미니PC와 NAS 비교에 대해 깊이 있게 다뤄봤습니다. 제 13년차 인프라 엔지니어 경험을 비춰보면, 결국 정답은 ‘하나만 선택’하는 것이 아니라 ‘자신의 용도에 맞게 최적의 조합을 찾는 것’입니다.

    • 난이도는 낮게, 데이터 안정성이 최우선이라면? ✅ NAS
    • 다양한 서비스 실험, 개발, 고성능 미디어 서버가 필요하다면? ✅ 미니PC

    어떤 길을 선택하시든, 홈랩 구축은 정말 재미있는 경험이 될 겁니다. 처음엔 어렵고 삽질도 많이 하겠지만, 하나하나 해결해나가면서 쌓이는 지식과 뿌듯함은 그 어떤 것과도 바꿀 수 없죠.

    다음 글에서는 제가 실제로 사용하고 있는 저전력 미니PC를 활용한 Docker 홈랩 구축기에 대해 자세히 다뤄볼 예정이니 기대해주세요! 여러분의 홈서버 라이프를 응원합니다! 🎉

    결국 여러분의 용도에 맞춰 미니PC와 NAS 중 최적의 선택을 하는 것이 중요합니다. 이 둘의 시너지를 활용하면 더 멋진 홈랩을 구축할 수 있을 겁니다!