13년차의 서버실

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

[태그:] NAS

  • [Nas] Cloudflare NAS 원격 접속: Tunnel 연결 오류 디버깅 완벽 가이드

    [Nas] Cloudflare NAS 원격 접속: Tunnel 연결 오류 디버깅 완벽 가이드

    안녕하세요, 13년차의 서버실입니다!

    오늘은 제 홈랩에서 개인 NAS(Network Attached Storage)를 원격으로 안전하게 접속하려고 Cloudflare Tunnel(클라우드플레어 터널)을 구축하다가 겪었던 ‘삽질 경험’과 그 해결 과정을 솔직하게 공유해보려고 합니다. 혹시 저처럼 Cloudflare Tunnel로 NAS 원격 접속을 시도하다가 연결 오류에 막혀본 적 있으신가요? 그렇다면 이 글이 많은 도움이 될 거라고 생각합니다.

    예전에는 VPN이나 포트 포워딩으로 NAS에 접속했었는데, 보안이나 설정의 복잡성 때문에 늘 고민이 많았거든요. 그러다 Cloudflare Tunnel이라는 아주 매력적인 솔루션을 알게 되었고, ‘이거다!’ 싶어서 바로 적용에 들어갔죠. Public IP(공인 IP) 없이도 안전하게 내부 서비스에 접근할 수 있다는 점이 정말 환상적이었어요. 그런데 막상 구축을 시작하니 생각지 못한 곳에서 오류가 터지면서 삽질 좀 했습니다. ㅎㅎ

    제가 어떤 문제에 부딪혔고, 어떻게 해결했는지 그 과정을 상세하게 풀어보겠습니다. 이 경험이 독자 여러분의 소중한 시간을 절약하는 데 기여했으면 좋겠습니다. 자, 그럼 시작해볼까요?

    Cloudflare Tunnel을 이용한 NAS 원격 접속 전체 아키텍처 개념도

    Cloudflare Tunnel과 Zero Trust, NAS 원격 접속의 조합

    먼저, 핵심 개념들을 간단하게 짚고 넘어가죠. 이 세 가지 기술이 어떻게 시너지를 내는지 이해하는 것이 중요합니다.

    • Cloudflare Tunnel (클라우드플레어 터널): 쉽게 말해, 외부에서 내부 네트워크로 안전하게 연결할 수 있는 ‘터널’을 만들어주는 서비스입니다. 우리 집 NAS나 서버가 공인 IP가 없어도, 심지어 방화벽 뒤에 있어도 Cloudflare의 엣지 네트워크를 통해 외부와 통신할 수 있게 해줘요. 내부에서 외부로 나가는 연결만 허용하면 되기 때문에 방화벽 설정도 훨씬 간단해집니다.
    • Zero Trust (제로 트러스트): ‘절대 아무것도 신뢰하지 않고, 항상 검증한다’는 보안 모델입니다. 전통적인 ‘경계 기반 보안’이 내부 네트워크는 안전하다고 가정했다면, Zero Trust는 내부 네트워크에 있더라도 모든 접근에 대해 사용자, 장치, 애플리케이션을 철저히 검증하죠. Cloudflare Zero Trust 플랫폼은 이 개념을 구현하는 강력한 도구거든요.
    • NAS (Network Attached Storage): 네트워크에 연결된 저장 장치입니다. 제 홈랩에서도 중요한 역할을 하는 녀석이죠. 사진, 동영상, 문서 등 개인 데이터를 저장하고, 미디어 서버나 백업 솔루션으로도 활용합니다.

    이 세 가지를 조합하면, Public IP 없이도 NAS에 안전하게 원격 접속할 수 있고, Zero Trust 모델을 통해 누가 언제 어디서 접속하는지까지 통제할 수 있게 됩니다. 기존의 VPN보다 훨씬 유연하고 강력한 보안 환경을 구축할 수 있다는 게 저의 오랜 경험상 가장 큰 장점이라고 생각합니다.

    Cloudflare Tunnel 설정부터 NAS 연결까지 차근차근

    이제 실제로 Cloudflare Tunnel을 설정하고 NAS에 연결하는 과정을 단계별로 설명해드릴게요. 제가 진행했던 순서 그대로입니다.

    1. Zero Trust 대시보드에서 Tunnel 생성

    1. Cloudflare Zero Trust 대시보드(one.dash.cloudflare.com)에 접속합니다.
    2. 좌측 메뉴에서 Access > Tunnels로 이동합니다.
    3. Create a tunnel 버튼을 클릭하고, Tunnel 이름을 지정합니다. 저는 my-nas-tunnel이라고 지었어요.
    4. 화면에 표시되는 설치 가이드를 따라 cloudflared를 설치할 운영체제를 선택합니다.

    만약 CLI(명령줄 인터페이스)로 Tunnel을 만들고 싶다면 다음과 같이 입력할 수 있습니다.

    # Cloudflare CLI 설치 (처음이라면) - OS에 따라 다름
    # curl -L --output cloudflared-linux-amd64 https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64
    # chmod +x cloudflared-linux-amd64
    # sudo mv cloudflared-linux-amd64 /usr/local/bin/cloudflared
    
    # Tunnel 생성 (CLI로)
    cloudflare tunnel create my-nas-tunnel
    

    Tunnel을 생성하면 화면에 token이 표시되는데, 이 토큰을 잘 복사해두세요. NAS에 cloudflared를 설치할 때 필요합니다.

    2. NAS에 Cloudflared 설치 및 실행

    NAS의 운영체제에 따라 cloudflared 설치 방법이 조금 다를 수 있습니다. 저는 주로 Debian/Ubuntu 기반의 리눅스 서버나 Docker를 사용하기 때문에 해당 기준으로 설명해드릴게요.

    1. Linux (Debian/Ubuntu 기반):
    2. # cloudflared 패키지 다운로드 및 설치
      curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
      sudo dpkg -i cloudflared.deb
      
      # 시스템 서비스로 등록 및 실행 (위에서 복사한 토큰 사용)
      sudo cloudflared service install 
      
      # 서비스 시작
      sudo systemctl start cloudflared
      
      # 서비스 상태 확인
      sudo systemctl status cloudflared
      
    3. Docker 사용 시:
    4. Docker Compose를 사용하는 것이 편리합니다. docker-compose.yml 파일을 다음과 같이 작성할 수 있습니다.

      version: '3.8'
      services:
        cloudflared:
          image: cloudflare/cloudflared:latest
          container_name: cloudflared
          restart: unless-stopped
          command: tunnel run --token 
          network_mode: host # 중요: NAS의 다른 서비스에 접근하기 위해 host 네트워크 사용
      

      이후 docker-compose up -d 명령으로 실행합니다.

    정상적으로 실행되면 Cloudflare Zero Trust 대시보드에서 Tunnel의 상태가 ‘Healthy’로 표시될 겁니다. ✅

    Cloudflare Zero Trust 대시보드의 Tunnel 설정 화면 (Ingress 규칙)

    Cloudflare Zero Trust 대시보드의 Tunnel 설정 화면 (Ingress 규칙)

    3. Ingress(인그레스) 규칙 설정

    이제 가장 중요한 Ingress 규칙을 설정할 차례입니다. 이 규칙은 어떤 요청을 어느 내부 서비스로 보낼지 정의하는 역할을 합니다. NAS의 cloudflared가 실행되는 서버에 ~/.cloudflared/config.yaml 파일을 생성하거나 수정해야 합니다.

    # ~/.cloudflared/config.yaml
    
    tunnel:  # Tunnel 생성 시 부여된 UUID
    credentials-file: /root/.cloudflared/.json # 자격 증명 파일 경로
    
    ingress:
      - hostname: nas.yourdomain.com # NAS에 접속할 도메인
        service: http://192.168.1.100:5000 # NAS의 내부 IP와 서비스 포트 (예: Synology DSM 기본 포트)
        originRequest:
          noTLSVerify: true # NAS가 HTTPS를 사용하지 않거나 자체 서명 인증서일 경우 필수!
      - service: http_status:404 # 모든 요청이 위 규칙에 해당하지 않으면 404 반환
    

    파일을 저장한 후, cloudflared 서비스를 재시작해야 변경 사항이 적용됩니다.

    sudo systemctl restart cloudflared # Linux 서비스의 경우
    # docker-compose restart cloudflared # Docker Compose의 경우
    

    4. DNS 레코드 설정

    마지막으로, Cloudflare 대시보드에서 NAS에 연결할 도메인(nas.yourdomain.com)이 위에서 생성한 Tunnel로 트래픽을 라우팅하도록 DNS 레코드를 설정해야 합니다. Zero Trust 대시보드의 Tunnel 설정 화면에서 ‘Public Hostname’을 추가하거나, CLI로 설정할 수 있습니다.

    cloudflare tunnel route dns my-nas-tunnel nas.yourdomain.com
    

    이 명령을 실행하면 Cloudflare DNS에 CNAME 레코드가 자동으로 생성되어 해당 도메인으로 들어오는 트래픽이 Tunnel로 연결됩니다.

    ⚠️ 삽질 경험: 터널 설정 오류 디버깅 포인트!

    자, 이제 제가 가장 많이 헤매고 삽질했던 포인트들을 공유할 시간입니다. 아마 많은 분들이 여기서 비슷한 문제를 겪으셨을 거예요.

    1. noTLSVerify 옵션의 중요성 (그리고 제 실수)

    제가 가장 먼저 부딪힌 문제는 바로 이 noTLSVerify 옵션이었습니다. Ingress 규칙에 service: http://192.168.1.100:5000이라고 분명히 HTTP로 설정했는데도 계속 502 Bad Gateway 에러가 뜨는 거예요. ‘아니, NAS는 HTTPS 안 쓰는데 왜 이러지?’ 하고 한참을 헤맸습니다.

    알고 보니 Cloudflare Tunnel은 기본적으로 Origin(원본 서버, 즉 NAS)과의 통신을 HTTPS로 시도하려고 합니다. 그런데 제 NAS는 HTTPS를 사용하지 않거나, 자체 서명 인증서를 사용하고 있었던 거죠. 이럴 경우 Tunnel이 NAS의 인증서를 신뢰하지 못해서 연결에 실패하게 됩니다. 해결책은 originRequest 아래에 noTLSVerify: true를 추가하여 TLS(전송 계층 보안) 검증을 건너뛰도록 하는 것이었습니다. 이 옵션을 추가하니 거짓말처럼 연결이 되더라고요! 🎉

    💡 팁: 보안상 가능하면 NAS도 정식 HTTPS 인증서를 적용하고 noTLSVerify: false(또는 제거)로 설정하는 것이 좋습니다. 하지만 홈랩 환경에서는 편의상 이 옵션을 사용할 때가 많죠.

    2. 서비스 포트 불일치

    두 번째 삽질은 NAS의 실제 서비스 포트와 Ingress 규칙에 설정한 포트가 달라서 생긴 문제였습니다. 예를 들어 Synology NAS의 DSM(DiskStation Manager)은 기본적으로 5000번(HTTP) 또는 5001번(HTTPS) 포트를 사용하는데, 제가 다른 서비스 포트를 실수로 입력해놓은 적이 있었어요. 브라우저에서 NAS 내부 IP로 접속하면 잘 되는데, Cloudflare Tunnel을 통하면 접속이 안 되니 ‘Tunnel 문제인가?’ 하고 엉뚱한 곳을 파고 있었죠. 😅

    NAS의 관리 페이지나 다른 서비스(Plex, Photo Station 등)에 접근할 때는 반드시 해당 서비스가 사용하는 정확한 내부 포트를 Ingress 규칙의 service 필드에 명시해야 합니다. http://localhost:5000 대신 http://[NAS_내부_IP]:[포트]처럼 명시적으로 내부 IP를 사용하는 것이 더 안전하고 명확합니다.

    3. DNS 레코드 미설정 또는 오설정

    Tunnel과 Ingress 규칙을 완벽하게 설정했다고 생각했는데도 접속이 안 된다면, DNS 레코드 설정을 다시 확인해보세요. Cloudflare Tunnel은 도메인에 대한 트래픽을 Tunnel로 라우팅하기 위해 CNAME 레코드가 필요합니다. 만약 이 레코드가 없거나 잘못 설정되어 있다면, 브라우저가 NAS 도메인으로 접속하려 해도 트래픽이 Tunnel로 들어오지 못하게 됩니다. 위에서 언급한 cloudflare tunnel route dns 명령어를 사용하거나 Cloudflare 대시보드에서 직접 CNAME 레코드를 확인해보세요.

    4. cloudflared 서비스 로그 확인의 중요성

    문제가 발생했을 때 가장 먼저 해야 할 일은 cloudflared 서비스의 로그를 확인하는 것입니다. Linux 시스템에서는 sudo journalctl -u cloudflared -f 명령으로 실시간 로그를 볼 수 있고, Docker 컨테이너를 사용한다면 docker logs -f cloudflared 명령으로 확인할 수 있습니다. 저도 위에서 언급한 noTLSVerify 문제를 로그에서 Error: x509: certificate signed by unknown authority와 같은 메시지를 보고 나서야 해결 실마리를 찾을 수 있었습니다. 로그는 항상 진실을 말해주거든요!

    🎉 드디어 NAS 원격 접속 성공!

    수많은 삽질 끝에 드디어 제 NAS가 https://nas.yourdomain.com으로 외부에서 완벽하게 접속되는 순간, 그 쾌감이란…! 🎉 Zero Trust 대시보드에서 Tunnel의 상태가 Healthy로 초록불이 들어오고, 트래픽이 정상적으로 흐르는 것을 확인했을 때의 안도감은 인프라 엔지니어만이 아는 뿌듯함이죠. 이제 언제 어디서든 제 NAS에 안전하게 접속하여 파일을 관리하고, 미디어를 스트리밍할 수 있게 되었습니다.

    Cloudflare Zero Trust 대시보드에서 확인한 Tunnel의 정상 작동 상태

    Cloudflare Zero Trust 대시보드에서 확인한 Tunnel의 정상 작동 상태

    마치며: 안전한 홈랩을 위한 Cloudflare Tunnel

    오늘은 Cloudflare Tunnel을 이용해 NAS 원격 접속을 설정하고, 제가 겪었던 연결 오류들을 어떻게 디버깅했는지 상세하게 공유해드렸습니다. 13년차 인프라 엔지니어로서 많은 시스템을 만져봤지만, 이렇게 새로운 기술을 제 홈랩에 적용하며 겪는 삽질은 언제나 성장의 밑거름이 되는 것 같습니다. ‘삽질은 기술 발전의 어머니’라는 말을 다시 한번 실감했네요. 😊

    Cloudflare Tunnel은 Public IP 없이도 내부 서비스를 외부로 안전하게 노출할 수 있는 강력한 도구입니다. 특히 Zero Trust 모델과 결합하면 보안과 편의성을 동시에 잡을 수 있다는 점이 큰 매력이라고 생각합니다. 만약 여러분도 NAS 원격 접속이나 다른 홈랩 서비스를 외부에서 안전하게 접근하고 싶다면, Cloudflare Tunnel을 적극적으로 고려해보시길 강력히 추천합니다.

    다음 글에서는 Cloudflare Access를 이용해 Tunnel로 접속하는 서비스에 사용자 인증/인가를 추가하는 방법을 다뤄볼 예정입니다. 더 강력한 Zero Trust 환경을 구축하는 방법을 기대해주세요!

    Cloudflare Tunnel을 활용한 NAS 원격 접속의 주요 장점 요약

    Cloudflare Tunnel을 활용한 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 미디어 서버 장단점 비교 인포그래픽

  • [Nas] NAS 디스크 교체 후 SMART 모니터링 심층 분석: 숨겨진 문제 진단과 예방

    [Nas] NAS 디스크 교체 후 SMART 모니터링 심층 분석: 숨겨진 문제 진단과 예방

    NAS 디스크 교체 후 SMART 모니터링 심층 분석: 숨겨진 문제 진단과 예방

    안녕하세요, 13년차 서버실 주인장입니다. 홈랩을 운영하다 보면 장비들을 직접 만지고 관리하는 일이 잦은데요. 특히 NAS(Network Attached Storage)는 제 소중한 데이터들을 보관하는 금고나 마찬가지라서, 하드디스크(HDD) 관리에 신경을 곤두세우고 있습니다. 얼마 전, 제 NAS에 사용하던 HDD 하나에 수명이 다 된 것 같다는 느낌을 받고 교체를 진행했는데요. 새 디스크를 장착하고 나서 그냥 쓰기만 하면 안 되겠죠? 오늘은 바로 이 NAS 디스크 교체 후 SMART 모니터링을 통해 숨겨진 문제를 진단하고 예방하는 방법에 대해 제 경험을 바탕으로 자세히 이야기해 보려고 합니다. 혹시 여러분도 NAS 디스크를 교체하거나, 현재 사용 중인 디스크의 건강 상태가 궁금하신가요? 그렇다면 이 글이 도움이 될 겁니다.

    NAS 시스템 개요 및 디스크 모니터링 중요성을 보여주는 다이어그램

    NAS 시스템 개요 및 디스크 모니터링의 중요성을 보여주는 다이어그램

    1. SMART, 도대체 뭘까요? (NAS 디스크 건강의 나침반)

    먼저 SMART(Self-Monitoring, Analysis and Reporting Technology)가 뭔지 간단히 설명해 드릴게요. 쉽게 말해, 하드디스크나 SSD 같은 저장 장치가 스스로 자신의 상태를 진단하고 기록하는 기술이에요. 마치 우리 몸이 아프면 열이 나거나 통증을 느끼는 것처럼, 디스크도 스스로 이상 징후를 감지하고 SMART 값을 통해 알려주는 거죠. 이 SMART 데이터에는 디스크의 온도, 읽기/쓰기 오류 횟수, 재할당 섹터 수 등 다양한 정보가 포함되어 있습니다. NAS SMART 모니터링은 이 값들을 주기적으로 확인해서 디스크에 문제가 생기기 전에 미리 파악하는 정말 중요한 과정입니다.

    2. 새 디스크 장착, 그리고 SMART 값 확인의 시작

    제가 사용 중인 NAS는 Synology 제품인데요. DSM(DiskStation Manager)이라는 운영체제를 통해 SMART 값을 쉽게 확인할 수 있습니다. 기존 HDD를 새 HDD로 교체하고, DSM에서 디스크를 인식시킨 후 가장 먼저 한 일은 바로 SMART 테스트를 실행하는 것이었습니다. 보통 ‘빠른 테스트(Quick Test)’와 ‘확장 테스트(Extended Test)’ 두 가지가 있는데, 저는 새 디스크의 초기 상태를 확실히 확인하기 위해 확장 테스트를 먼저 돌렸어요. 이 과정은 시간이 꽤 걸리지만, 디스크의 모든 섹터를 꼼꼼하게 읽고 쓰면서 잠재적인 불량 섹터(Bad Sector)를 찾아내거든요. 제 경험상, 새 디스크라고 해서 무조건 완벽한 건 아니더라고요.

    확장 테스트를 기다리는 동안, 저는 NAS의 다른 설정들도 함께 점검했습니다. RAID 구성은 제대로 되었는지, 볼륨 상태는 정상인지 등을 확인했죠. 새 디스크가 추가되면서 RAID 어레이 재구축(Rebuilding) 과정이 백그라운드에서 진행될 수 있기 때문에, 이 부분도 신경 써야 합니다. 특히, 여러 개의 디스크로 RAID를 구성했을 경우, 하나의 디스크에 문제가 생기면 나머지 디스크들도 영향을 받을 수 있거든요.

    Synology DSM에서 SMART 확장 테스트를 실행하는 화면 스크린샷

    3. SMART 데이터 해석, 무엇을 봐야 할까? (핵심 지표 분석)

    SMART 데이터는 수많은 값으로 이루어져 있어서 처음 보면 좀 복잡하게 느껴질 수 있습니다. 하지만 몇 가지 핵심 지표만 잘 살펴봐도 디스크의 건강 상태를 파악하는 데 큰 도움이 됩니다. 제가 주로 확인하는 항목들은 다음과 같아요.

    • Reallocated Sectors Count (재할당 섹터 수): 디스크 표면의 일부 영역(섹터)에 오류가 발생하여 더 이상 데이터를 읽거나 쓸 수 없을 때, 해당 섹터를 사용하지 않고 미리 준비된 예비 섹터로 대체하는 횟수입니다. 이 값이 0이 아니거나 계속 증가 추세를 보인다면 매우 위험 신호에요. 새 디스크의 경우, 초기 테스트에서 간혹 1~2개 정도 잡히는 경우가 있긴 하지만, 그 이후로 계속 늘어난다면 디스크 불량 가능성이 높습니다.
    • Current Pending Sector Count (현재 대기 섹터 수): 읽기 오류가 발생하여 아직 정상 섹터로 대체되지 않고, 다음 쓰기 작업 시 대체될 가능성이 있는 섹터 수입니다. 이 값 역시 0이 아니거나 증가 추세를 보이면 주의해야 해요.
    • Uncorrectable Errors (수정 불가능한 오류): 읽기/쓰기 과정에서 발생한 오류 중 수정할 수 없는 횟수입니다. 당연히 이 값은 0이어야 합니다.
    • Spin Retry Count (스핀 재시도 횟수): 디스크 플래터가 정상 속도로 회전하지 못해 재시도한 횟수예요. 이 값이 높으면 모터나 베어링 쪽에 문제가 있을 수 있습니다.
    • Power-On Hours (전원 켜진 시간): 디스크가 작동한 총 시간입니다. 이를 통해 디스크의 사용량을 가늠할 수 있어요.
    • Temperature (온도): 디스크의 현재 온도입니다. 너무 높거나 낮으면 디스크 수명에 좋지 않습니다.

    💡 팁: 보통 NAS 제조사 소프트웨어에서는 이 값들을 ‘좋음(Good)’, ‘주의(Warning)’, ‘나쁨(Bad)’ 등으로 표시해주기도 합니다. 하지만 저는 가장 신뢰할 수 있는 것은 각 항목의 RAW 값(실제 수치)이라고 생각해요. 제조사에서 제공하는 상태 표시는 때로는 너무 관대하거나, 혹은 너무 민감하게 반응할 때도 있거든요. RAW 값을 직접 보고 판단하는 것이 훨씬 정확합니다.

    4. 실제 겪은 문제와 해결 과정: ‘Pending Sector’의 함정

    제가 이번에 디스크를 교체하고 나서 확장 테스트를 돌렸는데, 모든 항목이 ‘좋음’으로 나왔습니다. 그래서 안심하고 데이터를 옮기기 시작했죠. 그런데 며칠 뒤, DSM에서 디스크에 문제가 있다는 알림이 뜨는 거예요! 😱 처음엔 이게 뭔가 싶었습니다. 분명 SMART 테스트도 통과했는데 말이죠. 다시 SMART 정보를 자세히 보니, ‘Current Pending Sector Count’ 항목에 아주 작은 값이 잡혀 있더라고요. (정확한 수치는 기억이 안 나지만, 1~2개 수준이었습니다.)

    이게 무슨 말이냐면, 디스크를 읽는 과정에서 아주 잠깐 오류가 발생했지만, 아직 ‘재할당’될 정도로 심각한 상황은 아니라는 뜻입니다. 하지만 이 ‘대기 중인 섹터’들이 나중에 쓰기 작업을 하거나, 디스크에 부하가 걸렸을 때 실제 불량으로 이어질 가능성이 있다는 거죠. 즉, SMART 테스트 통과가 끝이 아니라는 걸 깨달았거든요. 새 디스크라도 초기에는 이런 ‘숨겨진’ 문제들이 있을 수 있어요.

    ⚠️ 해결 과정:

    1. 데이터 백업 재확인: 혹시 모를 상황에 대비해, 이미 옮겨둔 데이터의 백업을 다시 한번 확인했습니다. (가장 중요!)
    2. 디스크 재검사: DSM에서 제공하는 ‘데이터 무결성 검사(Data Scrubbing)’ 기능을 실행했습니다. 이 기능은 RAID 볼륨 전체의 데이터를 읽어 무결성을 검사하고, 필요한 경우 오류를 수정하는 과정입니다. SMART 확장 테스트와는 또 다른 차원에서 디스크를 점검해 줍니다.
    3. 추가 모니터링: 데이터 무결성 검사가 완료된 후에도 ‘Current Pending Sector Count’ 값이 계속 유지되는지, 혹은 다른 SMART 항목에 변화가 없는지 며칠간 더 주의 깊게 모니터링했습니다.

    결과적으로, 제 경우에는 데이터 무결성 검사를 진행한 후 해당 값이 사라졌어요. 아마도 검사 과정에서 해당 섹터에 대한 쓰기 작업이 이루어지면서 정상화되었거나, 혹은 오류가 없는 것으로 최종 판정된 것 같습니다. 하지만 만약 이 값이 계속 유지되거나 다른 문제로 이어진다면, 저는 그 디스크를 즉시 교체했을 겁니다. 데이터 손실 방지를 위해서는 조금이라도 의심스러운 부분은 그냥 넘어가지 않는 것이 정말 중요하거든요.

    주요 SMART 항목별 의미와 중요도를 나타내는 비교표

    주요 SMART 항목별 의미와 중요도를 나타내는 비교표

    5. NAS SMART 모니터링, 꾸준함이 답이다

    디스크 교체 후 초기 점검도 중요하지만, NAS 디스크의 건강을 오랫동안 유지하기 위해서는 꾸준한 SMART 모니터링이 정말 중요해요. 대부분의 NAS 운영체제는 SMART 정보를 주기적으로 자동 검사하고, 이상이 감지되면 알림을 보내주는 기능을 제공합니다. 이 알림 기능을 반드시 활성화해 두세요. 저는 개인적으로 일주일에 한 번 정도 수동으로 SMART 상태를 확인하는 습관을 들이고 있습니다.

    NAS 제조사들은 대부분 ‘데이터 무결성 검사(Data Scrubbing)’ 또는 ‘디스크 검사’와 같은 정기적인 자동 점검 기능을 지원합니다. 이 기능을 활성화하여 매달 혹은 분기별로 주기적으로 실행하도록 설정해두는 것을 강력히 추천합니다. 이 과정에서 물리적인 디스크 오류뿐만 아니라, 파일 시스템 오류까지도 점검하고 복구할 수 있어요. 제 경험상, 이 자동 점검 기능 덕분에 디스크에 문제가 생기기 전에 미리 경고를 받아본 적이 여러 번 있었습니다. 🎉

    6. 마무리하며: 예방적 관리의 중요성

    오늘은 NAS 디스크 교체 후 SMART 모니터링에 대해 제 경험을 바탕으로 이야기해 보았습니다. 새 디스크를 장착하는 것도 중요하지만, 그 이후의 철저한 관리 없이는 소중한 데이터를 잃을 수도 있다는 걸 다시 한번 느꼈습니다. SMART 데이터는 디스크의 건강 상태를 파악하는 데 있어 가장 기본적인 도구이며, 이를 꾸준히 모니터링하고 정기적인 검사를 수행하는 것이 하드디스크 건강을 지키고 데이터 손실 방지를 위한 핵심입니다.

    앞으로는 SMART 데이터의 특정 값들에 더 주목하고, ‘Pending Sector’와 같은 잠재적 문제에 대해서도 좀 더 주의를 기울여야겠다는 다짐을 했습니다. 여러분도 NAS를 사용하신다면, SMART 모니터링을 습관화하시고 정기적인 디스크 검사를 꼭 챙기시길 바랍니다. 혹시 SMART 데이터 해석이나 NAS 관리 관련해서 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 저도 계속 배우고 경험하면서 여러분과 함께 성장하고 싶습니다! 다음 글에서는 NAS의 RAID 구성 방식에 따른 장단점과 어떤 상황에 어떤 RAID를 선택해야 하는지에 대해 더 자세히 다뤄보도록 하겠습니다.

    NAS 관리 및 데이터 백업 전략을 요약한 인포그래픽

    NAS 관리 및 데이터 백업 전략을 요약한 인포그래픽

  • [NAS 파일 시스템] Btrfs, 데이터 무결성을 위한 현명한 선택일까?

    [NAS 파일 시스템] Btrfs, 데이터 무결성을 위한 현명한 선택일까?

    [NAS 파일 시스템] Btrfs, 데이터 무결성을 위한 현명한 선택일까?

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 NAS를 운영하시는 분들이라면 한 번쯤 고민해봐야 할 주제, 바로 Btrfs 파일 시스템에 대해 얘기해보려고 합니다. 저도 처음엔 ZFS(Zettabyte File System)만 최고인 줄 알았거든요. 근데 홈랩에서 다양한 파일 시스템을 직접 써보고 삽질도 좀 해보면서, Btrfs가 NAS 환경에서 얼마나 매력적인 선택지가 될 수 있는지 깨달았습니다. 특히 데이터 무결성(Data Integrity)을 중요하게 생각하신다면, 오늘 제 경험담이 도움이 될 거예요.

    소중한 데이터, 한순간의 실수나 하드웨어 오류로 날아가면 정말 끔찍하잖아요? 저도 예전에 백업 없이 중요한 자료를 날려본 경험이 있어서, 그때부터는 파일 시스템 선택에 정말 신중해졌습니다. Btrfs는 이런 걱정을 덜어줄 수 있는 강력한 기능들을 제공하더라고요. 과연 Btrfs가 여러분의 NAS 데이터를 안전하게 지켜줄 수 있을지, 함께 파헤쳐 봅시다!

    Btrfs 파일 시스템의 Copy-on-Write(CoW) 및 스냅샷 작동 방식 개념도

    Btrfs 파일 시스템의 Copy-on-Write(CoW) 및 스냅샷 작동 방식 개념도

    Btrfs, 너는 누구냐? 핵심 기능 파헤치기

    Btrfs는 ‘B-tree file system’의 약자로, 오라클에서 개발을 시작한 차세대 파일 시스템입니다. 리눅스 환경에서 널리 사용되고 있죠. 사실 처음엔 이게 뭔가 싶었는데, 몇 가지 핵심 기능들을 알고 나니 “이거 진짜 물건이더라고요!” 하는 생각이 들었습니다. 특히 NAS에 적용했을 때 빛을 발하는 기능들이 많더라고요.

    1. Copy-on-Write (CoW, 카피 온 라이트)

    이름 그대로 ‘쓸 때 복사한다’는 의미입니다. 기존 데이터를 변경할 때, 해당 데이터를 덮어쓰지 않고 새로운 위치에 변경된 데이터를 쓴 다음, 메타데이터(Metadata)만 업데이트하는 방식이죠. 이게 왜 중요하냐면요?

    • 데이터 손상 방지: 전원이 갑자기 나가거나 시스템에 문제가 생겨도, 작업 중이던 데이터는 손상될지언정 기존 데이터는 온전히 보존됩니다.
    • 스냅샷의 기반: 이 CoW 덕분에 스냅샷(Snapshot) 기능이 아주 효율적으로 작동합니다.

    사실 CoW 방식은 ZFS에서도 볼 수 있는 강력한 기능인데, Btrfs도 이걸 아주 잘 활용하고 있더라고요.

    2. 스냅샷 (Snapshot)

    스냅샷은 특정 시점의 파일 시스템 상태를 저장하는 기능입니다. 마치 게임에서 세이브 포인트를 만드는 것과 같아요. Btrfs의 스냅샷은 CoW 덕분에 용량을 거의 차지하지 않는다는 게 정말 큰 장점입니다. 변경된 블록만 저장하면 되니까요.

    • 실수로 파일 삭제/수정: 걱정 마세요! 스냅샷으로 쉽게 특정 시점으로 되돌릴 수 있어요.
    • 랜섬웨어 공격: 이것 때문에 저도 Btrfs를 더 신뢰하게 됐는데요, 만약 랜섬웨어에 감염되더라도 감염되기 전 스냅샷으로 복원하면 피해를 최소화할 수 있습니다. 정말 든든하죠!

    3. 데이터 무결성 (Data Integrity)을 위한 체크섬 (Checksum)

    Btrfs는 데이터 블록과 메타데이터 블록에 각각 체크섬을 적용합니다. 데이터를 읽을 때마다 체크섬을 확인해서, 혹시라도 데이터가 손상(Bit Rot, 비트 로트)되었는지 검사하죠. 만약 손상된 부분을 발견하면, RAID 1이나 RAID 10처럼 미러링된 구성에서는 자동으로 손상되지 않은 사본으로 복구해버립니다. 이게 바로 자가 복구(Self-Healing) 능력입니다.

    제가 실제로 써보니까, 이런 기능들이 작은 홈랩 NAS부터 기업용 스토리지까지 데이터의 신뢰성을 크게 높여주더라고요. 처음엔 “굳이 이렇게까지 해야 하나?” 싶었는데, 한 번 데이터를 잃고 나면 생각이 확 달라집니다.

    NAS에서 Btrfs 실전 활용: 어떻게 적용할까?

    많은 NAS 제조사들이 Btrfs를 채택하고 있습니다. 특히 Synology(시놀로지) 같은 경우 Btrfs를 적극적으로 활용해서 스냅샷, 데이터 무결성 기능을 사용자에게 제공하고 있죠. 하지만 직접 리눅스 서버에 NAS를 구축한다면, Btrfs를 직접 설정해야 합니다.

    1. Btrfs 파일 시스템 생성

    먼저 Btrfs로 포맷할 디스크를 준비해야 합니다. 저는 주로 여러 디스크를 묶어서 사용하는데요, Btrfs는 자체적으로 소프트웨어 RAID 기능을 제공합니다. (물론 안정성 측면에서는 하드웨어 RAID나 mdadm 위에 Btrfs를 쓰는 것도 고려할 수 있습니다.)

    # /dev/sdb, /dev/sdc 두 개의 디스크로 RAID1 Btrfs 파일 시스템 생성
    sudo mkfs.btrfs -d raid1 -m raid1 /dev/sdb /dev/sdc
    
    # 기존 디스크를 Btrfs 풀에 추가할 경우
    sudo btrfs device add /dev/sdd /mnt/btrfs_pool
    sudo btrfs balance start -dusage=50 /mnt/btrfs_pool # 데이터 분배

    이렇게 생성된 Btrfs 볼륨을 원하는 마운트 포인트에 마운트하면 됩니다.

    2. 서브볼륨 (Subvolume) 생성 및 관리

    Btrfs의 서브볼륨은 일반적인 디렉토리와 비슷하지만, 독립적인 스냅샷을 찍거나 할당량(Quota)을 설정할 수 있는 등 더 강력한 기능을 제공합니다. 저는 보통 용도별로 서브볼륨을 나눠서 사용해요. 예를 들어, ‘Documents’, ‘Media’, ‘Backup‘ 이런 식으로요.

    sudo mount /dev/sdb /mnt/btrfs_pool
    
    # 'data'라는 서브볼륨 생성
    sudo btrfs subvolume create /mnt/btrfs_pool/data
    
    # 'data' 서브볼륨을 /srv/nas에 마운트 (fstab에도 등록하여 부팅 시 자동 마운트)
    sudo mount -o subvol=data /dev/sdb /srv/nas

    3. 스냅샷 생성 및 관리

    이제 서브볼륨에 데이터를 저장하고, 주기적으로 스냅샷을 찍어줍니다. 스냅샷은 읽기 전용(Read-Only)으로 생성하는 것이 일반적입니다.

    # 'data' 서브볼륨의 스냅샷 생성
    sudo btrfs subvolume snapshot -r /srv/nas /srv/nas/.snapshots/data_$(date +%Y%m%d_%H%M%S)
    
    # 생성된 스냅샷 목록 확인
    sudo btrfs subvolume list -t -o /mnt/btrfs_pool

    스냅샷을 자동으로 찍어주는 스크립트나 서비스(예: <code>btrfs-autosnap, snapper)를 활용하면 훨씬 편리하게 관리할 수 있어요. 저도 처음엔 수동으로 찍다가, 나중엔 스크립트 걸어놓고 마음 편하게 쓰고 있습니다.

    Btrfs 파일 시스템을 활용한 NAS 구성 개념도

    Btrfs 파일 시스템을 활용한 NAS 구성 개념도

    ⚠️ 주의사항 및 트러블슈팅: 제가 겪었던 삽질들

    Btrfs가 만능은 아닙니다. 제가 직접 써보면서 몇 가지 주의할 점과 삽질 경험을 공유해 드릴게요.

    1. 성능 오버헤드 (Performance Overhead)

    Copy-on-Write 방식은 데이터 무결성을 높여주지만, 쓰기(Write) 작업 시 약간의 성능 저하가 발생할 수 있습니다. 특히 랜덤 쓰기(Random Write)가 많은 환경에서는 체감될 수 있어요. 처음엔 “왜 이렇게 느리지?” 싶었는데, 알고 보니 CoW 때문이더라고요. 그래서 고성능이 최우선인 환경보다는 데이터 안정성이 중요한 환경에 더 적합하다고 생각합니다.

    2. 디스크 공간 관리 (Disk Space Management)

    스냅샷은 공간을 효율적으로 사용하지만, 너무 많은 스냅샷을 오랫동안 보관하면 결국 디스크 공간을 많이 차지하게 됩니다. 특히 삭제된 파일이 스냅샷에 남아있다면 실제 공간은 회수되지 않거든요. 주기적으로 오래된 스냅샷을 삭제해주는 정책이 필요해요.

    # 오래된 스냅샷 삭제 예시 (가장 최신 스냅샷 10개만 남기고 삭제)
    # 실제 사용 시에는 신중하게 접근해야 합니다.
    LATEST_SNAPSHOTS=$(sudo btrfs subvolume list -t -o /mnt/btrfs_pool | grep 'snapshots' | sort -r | head -n 10 | awk '{print $9}')
    ALL_SNAPSHOTS=$(sudo btrfs subvolume list -t -o /mnt/btrfs_pool | grep 'snapshots' | awk '{print $9}')
    
    for SNAPSHOT in $ALL_SNAPSHOTS; do
        IS_LATEST=false
        for LATEST in $LATEST_SNAPSHOTS; do
            if [ "$SNAPSHOT" == "$LATEST" ]; then
                IS_LATEST=true
                break
            fi
        done
        if ! $IS_LATEST; then
            echo "Deleting old snapshot: $SNAPSHOT"
            sudo btrfs subvolume delete "$SNAPSHOT"
        fi
    done

    ⚠️ 경고: 스냅샷 삭제는 신중하게! 복구 불가능합니다.

    3. RAID 기능의 성숙도

    Btrfs는 자체 RAID0, RAID1, RAID5, RAID6 기능을 제공해요. 하지만 RAID5/6의 경우 초기에는 안정성 문제가 보고되기도 했습니다. 지금은 많이 개선되었지만, 아직까지는 mdadm RAID1 위에 Btrfs를 사용하거나, RAID10을 선호하는 경우가 많습니다. 저도 안정성을 위해 RAID10을 주로 사용하거나, 디스크 두 개만 쓰는 NAS에는 Btrfs RAID1을 쓰는 편입니다.

    ✅ 검증 및 결과: 내 데이터는 안전한가?

    Btrfs를 설정하고 나면, 데이터가 정말 안전하게 관리되고 있는지 확인해야겠죠? 저는 주기적으로 btrfs scrub 명령어를 실행해서 파일 시스템의 데이터 무결성을 검사합니다. 이 명령은 모든 데이터와 메타데이터 블록의 체크섬을 확인하고, 손상된 부분이 있으면 자동으로 복구해줍니다.

    # Btrfs 파일 시스템 스크럽 시작
    sudo btrfs scrub start /mnt/btrfs_pool
    
    # 스크럽 진행 상황 확인
    sudo btrfs scrub status /mnt/btrfs_pool

    스크럽이 완료되면 “드디어 됐다!” 하는 안도감이 들어요. 이 기능을 통해서 디스크 자체의 물리적인 오류나 비트 로트 현상으로부터 데이터를 보호할 수 있습니다. NAS를 며칠씩 켜놓는 저에게는 정말 필수적인 기능이라고 생각해요.

    Btrfs scrub 및 스냅샷 목록 확인 터미널 출력 화면

    Btrfs scrub 및 스냅샷 목록 확인 터미널 출력 화면

    마무리: Btrfs, NAS 데이터 무결성을 위한 현명한 선택일까?

    결론부터 말씀드리자면, Btrfs는 NAS 환경에서 데이터 무결성과 관리 유연성을 크게 향상시켜 줄 수 있는 현명한 선택지가 될 수 있습니다. 특히 스냅샷 기능은 랜섬웨어 방어나 실수로 인한 데이터 손실 복구에 엄청난 강점을 보여주거든요. CoW 기반의 효율적인 공간 활용도 정말 매력적입니다.

    하지만 성능 오버헤드나 RAID 기능의 성숙도 등 고려해야 할 부분도 분명히 있습니다. 완벽한 파일 시스템은 없으니까요. 여러분의 NAS 사용 목적과 중요도에 따라 Btrfs가 최적의 선택이 될 수도, 아닐 수도 있겠죠. 저처럼 홈랩에서 다양한 시도를 해보면서 자신에게 맞는 최적의 조합을 찾아가는 과정 자체가 인프라 엔지니어의 숙명 아닐까요? ㅎㅎ

    다음 글에서는 Btrfs와 ZFS를 좀 더 심층적으로 비교해보는 시간을 가져볼까 합니다. 혹시 Btrfs를 사용하면서 겪었던 재미있는 삽질 경험이 있으시다면 댓글로 공유해주세요! 저도 배우는 재미가 쏠쏠하거든요. 긴 글 읽어주셔서 감사합니다!

    Btrfs 파일 시스템의 NAS 적용 장단점 인포그래픽 요약

    Btrfs 파일 시스템의 NAS 적용 장단점 인포그래픽 요약

  • [NAS] OpenMediaVault에 Immich 구축 6개월 사용기: 자가 호스팅 사진 관리의 명과 암

    [NAS] OpenMediaVault에 Immich 구축 6개월 사용기: 자가 호스팅 사진 관리의 명과 암

    OpenMediaVault에 Immich 구축 6개월 사용기: 자가 호스팅 사진 관리의 명과 암

    안녕하세요, 13년차 서버실입니다. 홈랩을 운영하며 이것저것 시도하는 게 제 낙인데요. 오늘은 많은 분들이 관심을 가지시는 자가 호스팅 사진 관리 솔루션, Immich를 OpenMediaVault(OMV)에 구축하고 6개월간 사용해 본 경험을 솔직하게 공유해 보려 합니다. 직접 써보니 정말 편한 부분도 많았지만, 예상치 못한 문제점들도 꽤 있더라고요. 이번엔 제 경험을 바탕으로 명과 암을 낱낱이 파헤쳐 보겠습니다.

    OpenMediaVault와 Immich를 활용한 홈랩 사진 관리 아키텍처 개요

    Immich와 OpenMediaVault를 활용한 전체 홈랩 사진 관리 아키텍처 개요

    왜 자가 호스팅 사진 관리인가? 🤔

    스마트폰 용량은 늘 부족하고, 사진은 기하급수적으로 늘어나죠. 클라우드 서비스는 편리하지만, 월마다 나가는 비용 부담이나 개인 정보 유출에 대한 걱정에서 자유롭지 못합니다. 특히 소중한 사진 데이터가 서비스 제공 업체의 정책 변화나 개인정보 유출 사고로 날아갈까 봐 불안한 마음, 다들 한 번쯤은 느껴보셨을 겁니다. 저도 그랬어요. 그래서 자가 호스팅 사진 관리, 특히 Immich 같은 오픈소스 솔루션에 눈을 돌리게 되었습니다. 내 손안의 작은 클라우드, 이게 가능하다는 게 신기하더라고요.

    Immich, 뭐가 그렇게 좋은데? 💡

    Immich는 Google Photos와 유사한 기능을 제공하는 오픈소스 사진 백업 및 관리 솔루션이에요. 핵심은 내 서버에 직접 설치해서 사용한다는 점이죠. 주요 기능들을 살펴보면:

    • 자동 백업: 스마트폰 사진을 자동으로 서버에 백업해 줘요. Google Photos의 자동 백업 기능과 거의 똑같다고 보시면 됩니다.
    • AI 기반 기능: 사진 내 객체 인식, 얼굴 인식, 중복 사진 제거 등 강력한 AI 기능을 제공합니다. 이게 또 은근히 편하더라고요.
    • 웹 UI & 모바일 앱: 깔끔한 웹 인터페이스와 함께 iOS, Android 모바일 앱을 지원해서 언제 어디서든 사진에 접근하고 관리할 수 있어요.
    • 다양한 포맷 지원: JPG, PNG뿐만 아니라 RAW 파일, 비디오 파일도 지원합니다.

    이런 강력한 기능들을 무료로, 내 마음대로 사용할 수 있다는 점이 Immich의 가장 큰 매력이에요. 물론, 이걸 구현하기 위해 몇 가지 기술적인 장벽을 넘어야 하긴 합니다.

    OpenMediaVault(OMV) 위에 Immich 올리기 🛠️

    저는 NAS(Network Attached Storage) 솔루션으로 OpenMediaVault(OMV)를 사용하고 있어요. OMV는 Debian 기반의 NAS 운영체제로, 웹 UI를 통해 스토리지 관리, 사용자 관리, 다양한 플러그인 설치 등을 쉽게 할 수 있게 해줍니다. Immich는 Docker 컨테이너로 배포되기 때문에 OMV의 Docker 플러그인과 함께라면 설치가 한결 수월합니다.

    1단계: OpenMediaVault 준비

    OMV가 설치되어 있고, Docker 플러그인이 활성화된 상태여야 해요. 만약 Docker 플러그인이 없다면, OMV 웹 UI의 ‘플러그인’ 메뉴에서 설치해 주세요. 그 후, Immich 데이터를 저장할 볼륨(Volume)을 위한 디스크나 파티션을 준비하고 OMV에서 파일 시스템으로 마운트해 두는 게 좋아요. 저는 `/srv/dev-disk-by-uuid/<UUID>/immich` 경로에 데이터를 저장하도록 구성했습니다.

    2단계: Immich Docker Compose 설정

    Immich는 Docker Compose를 사용하여 쉽게 배포할 수 있어요. GitHub 저장소에 예제 `docker-compose.yml` 파일이 제공되니 이를 활용하는 게 좋습니다. 저는 다음과 같이 설정을 구성했습니다.

    version: "3.8"
    
    services:
      immich-server:
        image: ghcr.io/immich-app/immich-server:latest
        container_name: immich_server
        ports:
          - "3001:3001"
        volumes:
          - ./library:/usr/src/app/upload
        environment:
          - DB_HOSTNAME=immich_db
          - DB_USERNAME=immich
          - DB_PASSWORD=your_strong_password
          - DB_NAME=immich
          - REDIS_HOSTNAME=immich_redis
        depends_on:
          - immich-db
          - immich-redis
        restart: unless-stopped
    
      immich-ml:
        image: ghcr.io/immich-app/immich-ml:latest
        container_name: immich_ml
        volumes:
          - ./model-cache:/cache
        environment:
          - TRANSFORMERS_CACHE=/cache
        restart: unless-stopped
    
      immich-db:
        image: postgres:15
        container_name: immich_db
        volumes:
          - ./postgres:/var/lib/postgresql/data
        environment:
          - POSTGRES_USER=immich
          - POSTGRES_PASSWORD=your_strong_password
          - POSTGRES_DB=immich
        restart: unless-stopped
    
      immich-redis:
        image: redis:7-alpine
        container_name: immich_redis
        restart: unless-stopped
    
    networks:
      default:
        name: immich_network
    

    주의: 위 설정에서 <UUID> 부분은 실제 OMV에서 마운트한 디스크의 UUID로 변경해야 합니다. 또한, `your_strong_password` 부분은 복잡하고 안전한 비밀번호로 바꿔주세요. 특히 AI 기능(얼굴 인식, 객체 인식)을 사용하려면 `immich-ml` 서비스가 필수이니까 꼭 포함시켜야 해요. 데이터베이스 비밀번호는 모든 컨테이너에서 동일하게 설정해야 합니다.

    3단계: Docker Compose 실행

    OMV의 SSH 기능을 활성화하거나, Docker 플러그인에서 제공하는 ‘Compose’ 기능을 사용하여 위 내용을 `docker-compose.yml` 파일로 저장한 후 실행해요. 저는 SSH로 접속하여 해당 디렉토리에서 docker compose up -d 명령어를 실행했습니다.

    OpenMediaVault Docker 플러그인에서 Immich 컨테이너 실행 모습

    OpenMediaVault에서 Docker 플러그인을 통해 Immich 컨테이너가 실행되고 있는 모습

    컨테이너가 모두 정상적으로 실행되면, 웹 브라우저에서 http://<OMV IP 주소>:3001 으로 접속하여 Immich 초기 설정을 진행할 수 있어요. 처음에는 관리자 계정을 생성하고, 이후 사용자 계정을 추가하며 사진을 업로드하면 됩니다.

    6개월간 사용하며 겪은 명과 암 ⛰️

    6개월간 Immich를 사용하면서 느낀 점들을 솔직하게 말씀드리겠습니다.

    ✨ 명 (장점)

    • 뛰어난 자동 백업 및 동기화: 스마트폰에서 찍은 사진이 실시간으로 서버에 백업되는 경험은 정말 혁신적이었어요. 용량 걱정 없이 마음껏 사진을 찍을 수 있게 되었죠.
    • 강력한 AI 기능: 사진 검색 시 객체나 장소로 검색하는 기능은 정말 편리했습니다. 잃어버렸던 사진을 찾거나 특정 테마의 사진을 모아볼 때 유용하더라고요. 중복 사진 제거 기능도 꽤 정확해서 스토리지 공간을 절약하는 데 큰 도움이 되었어요.
    • 깔끔한 UI/UX: 웹 인터페이스와 모바일 앱 모두 직관적이고 사용하기 편리했습니다. Google Photos에 익숙하다면 금방 적응할 수 있어요.
    • 오픈소스의 자유로움: 비용 부담 없이 원하는 대로 커스터마이징하고 관리할 수 있다는 점이 가장 큰 매력이에요.

    ⚠️ 암 (단점 및 주의사항)

    • 초기 설정의 복잡함: Docker, Docker Compose, 네트워크 설정 등 기본적인 이해가 없다면 설치 과정에서 어려움을 겪을 수 있어요. 저도 처음에는 Docker Compose 파일 설정 때문에 몇 번을 헤맸습니다.
    • 리소스 요구량: Immich는 AI 기능 등을 포함하여 꽤 많은 시스템 리소스(CPU, RAM)를 요구합니다. 특히 사진을 대량으로 업로드하거나 AI 분석을 실행할 때 서버 부하가 체감될 정도였어요. 저사양 홈랩 서버에서는 성능 저하가 발생할 수 있으니까 주의해야 합니다.
    • 업데이트 시 주의 필요: Immich는 활발하게 개발되고 있어 업데이트가 잦은 편입니다. 업데이트 과정에서 데이터베이스 스키마 변경 등으로 인해 문제가 발생할 수 있어서 항상 백업 후 업데이트하는 습관이 정말 중요해요. 저도 한 번 업데이트 후에 DB 연결에 문제가 생겨 잠시 당황했던 경험이 있습니다.
    • 안정성 이슈 (가끔): 가끔 예상치 못한 오류나 컨테이너 재시작이 필요한 경우가 있었어요. 특히 대규모 파일 업로드나 백업 작업 중에 발생하면 좀 당황스럽더라고요.
    • 데이터 무결성 책임: 모든 데이터 관리는 사용자 본인의 책임입니다. 백업, 스토리지 관리 등 모든 것을 직접 신경 써야 해요. 클라우드 서비스처럼 자동화된 백업/복구 시스템이 기본 제공되는 건 아니니까요.
    Immich 대시보드: 사진 업로드 및 AI 분석 진행 상황

    Immich 대시보드에서 사진 업로드 진행 상황과 AI 분석 상태를 보여주는 화면

    트러블슈팅: 흔히 겪는 문제들 🚨

    6개월간 사용하면서 몇 가지 문제에 부딪혔고, 이를 해결했던 경험을 공유합니다.

    • 문제 1: 컨테이너 재시작 후 DB 연결 실패
    • 원인: Immich 서버 컨테이너가 DB 컨테이너보다 먼저 시작되면서 발생할 수 있어요.
    • 해결책: `docker-compose.yml` 파일에서 `depends_on` 설정을 명확히 하고, Immich 서버 컨테이너에 재시도 로직을 추가하거나, 컨테이너 재시작 후 잠시 기다렸다가 수동으로 재시작하는 방법이 있습니다. 저는 `depends_on` 설정을 활용했어요.
    • 문제 2: 사진 업로드가 간헐적으로 실패
    • 원인: 서버 리소스 부족, 네트워크 불안정, 혹은 Immich 자체의 버그일 수 있습니다.
    • 해결책: 서버의 CPU, RAM 사용량을 확인하고, 필요하다면 리소스를 증설하거나 백업/AI 분석 작업 시간을 조정했어요. 네트워크 상태도 점검하고, Immich의 최신 버전을 사용하며 커뮤니티 피드백을 확인하는 것이 좋습니다.
    • 문제 3: AI 기능 (얼굴 인식 등)이 제대로 동작하지 않음
    • 원인: AI 모델 다운로드 실패, 설정 오류, 또는 리소스 부족으로 인한 백그라운드 작업 지연이에요.
    • 해결책: Immich의 `docker-compose.yml` 파일에서 `immich-ml` 서비스와 관련 볼륨 설정을 확인하고, 필요한 경우 `docker compose down` 후 `docker compose pull immich-ml` 명령어로 이미지를 최신 버전으로 다시 받아준 후 `docker compose up -d`로 재시작했어요. 서버 리소스가 충분한지 다시 한번 확인하는 것도 정말 중요합니다.

    결론: 6개월간의 자가 호스팅 사진 관리 여정 📝

    OpenMediaVault 위에 Immich를 구축하여 6개월간 사용해 본 결과, 자가 호스팅 사진 관리 솔루션으로서 Immich는 충분히 매력적이고 강력한 대안이라고 생각합니다. 특히 Google Photos의 편리함에 익숙하지만, 개인 정보 보호나 비용 절감을 원하는 분들에게는 최고의 선택지가 될 수 있어요.

    하지만 만능은 아닙니다. 초기 설정의 장벽, 시스템 리소스 요구량, 업데이트 시의 주의, 그리고 데이터 관리에 대한 전적인 책임 등 고려해야 할 부분들이 분명히 있거든요. 마치 잘 길들여진 애완동물처럼, 꾸준한 관심과 관리가 필요한 셈이죠.

    Immich 사진 갤러리 보기와 검색 기능 비교 인포그래픽

    Immich의 사진 갤러리 보기와 검색 기능을 비교하는 인포그래픽

    만약 여러분이…

    • 기술적인 도전을 즐기시고,
    • 직접 시스템을 구축하고 관리하는 것을 좋아하며,
    • 개인 데이터의 프라이버시와 통제권을 최우선으로 생각한다면,

    Immich는 분명 여러분의 홈랩에 훌륭한 추가가 될 거예요. 처음에는 조금 어렵게 느껴질 수 있지만, 한번 구축해두면 그 편리함에 만족하실 겁니다. 저도 앞으로도 Immich를 계속 사용하며 홈랩 사진 관리의 여정을 이어갈 생각이에요.

    다음 글에서는 Immich의 백업 및 복구 전략에 대해 좀 더 자세히 다뤄보도록 하겠습니다. 감사합니다!

  • [Nas] TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    [Nas] TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 많은 인프라 엔지니어들이 한 번쯤 고민해봤을 주제, VMware ESXi 가상머신(Virtual Machine, VM)을 TrueNAS iSCSI 스토리지로 마이그레이션(Migration, 이전)하는 성공 사례를 들려드리려고 합니다. 저도 홈랩을 운영하면서 스토리지 확장의 필요성을 절감했고, 이 과정에서 꽤나 삽질을 했거든요. 하지만 결국 성공했고, 그 경험을 여러분과 나누고 싶습니다. 💡

    기존에 사용하던 로컬 스토리지의 용량이 부족해지거나, 더 나은 성능과 유연성을 위해 중앙 집중식 스토리지로 옮겨야 할 때가 있죠. 특히 ESXi 스토리지 이전은 단순히 데이터 복사 이상의 복잡한 과정이 필요합니다. 이때 TrueNAS iSCSI는 비용 효율적이면서도 강력한 대안이 될 수 있습니다. iSCSI VM 마이그레이션을 고민 중이라면, 오늘 이야기가 큰 도움이 될 겁니다.

    ESXi와 TrueNAS iSCSI 스토리지를 활용한 가상머신 마이그레이션 전체 구성도입니다.

    1. 핵심 개념 이해: ESXi, TrueNAS, 그리고 iSCSI

    본격적인 마이그레이션에 앞서, 핵심 기술들이 무엇인지 간단히 짚고 넘어갈게요. “아, 이건 또 뭐야?” 싶으실 수도 있지만, 기본을 알아야 삽질을 줄일 수 있거든요. 😉

    • VMware ESXi (이엑스아이): VMware에서 개발한 베어메탈(Bare-metal) 하이퍼바이저(Hypervisor)입니다. 쉽게 말해, 물리 서버 위에 직접 설치되어 여러 가상머신을 효율적으로 운영할 수 있게 해주는 소프트웨어죠. 저희 서버실의 모든 가상머신은 ESXi 위에서 돌아가고 있습니다.
    • TrueNAS (트루나스): 오픈소스 네트워크 스토리지(Network Attached Storage, NAS) 운영체제입니다. 강력한 ZFS 파일 시스템을 기반으로 데이터 무결성과 유연성을 제공하며, 파일 공유는 물론 iSCSI와 같은 블록 스토리지 서비스도 지원합니다. 저의 홈랩에서는 TrueNAS Core 버전을 사용하고 있습니다.
    • iSCSI (아이 스카시, Internet Small Computer System Interface): IP 네트워크를 통해 SCSI(Small Computer System Interface) 명령을 전송하는 기술 표준입니다. 원격 서버에 마치 로컬 디스크처럼 블록 스토리지(Block Storage)를 연결할 수 있게 해줍니다. NAS iSCSI 설정은 ESXi가 TrueNAS의 스토리지를 마치 물리 디스크처럼 인식하게 만드는 핵심 단계라고 할 수 있죠.

    2. TrueNAS iSCSI 타겟 설정: 스토리지 준비하기

    이제 TrueNAS에서 ESXi가 사용할 iSCSI 스토리지를 만들어볼 차례입니다. “어렵지 않을까?” 걱정 마세요. 제가 직접 해보니 몇 가지 단계만 잘 따라가면 됩니다.

    단계별 TrueNAS iSCSI 설정

    1. ZFS 데이터셋(Dataset) 생성: 먼저 iSCSI 타겟으로 사용할 ZFS 데이터셋을 만듭니다. 저는 pool01/iscsi-vm이라는 데이터셋을 만들었어요.
    2. iSCSI 서비스 활성화: TrueNAS 웹 GUI에서 Services -> iSCSI로 이동하여 서비스를 활성화하고, Start Automatically를 체크해줍니다.
    3. 포털(Portal) 생성: iSCSI 통신에 사용할 IP 주소와 포트를 지정합니다. Sharing -> Block Shares (iSCSI) -> Portals 탭에서 Add를 클릭하고 TrueNAS의 IP 주소를 입력합니다.
    4. 이니시에이터(Initiator) 및 인증 설정 (선택 사항): 보안을 위해 특정 ESXi 호스트만 접근하도록 제한하거나, CHAP(Challenge-Handshake Authentication Protocol) 인증을 설정할 수 있습니다. 저는 홈랩이라 간단히 모든 이니시에이터(ALL Initiators)를 허용했지만, 프로덕션 환경에서는 반드시 제한해야 합니다.
    5. 익스텐트(Extent, LUN) 생성: 실제 스토리지 공간을 정의합니다. Extents 탭에서 Add를 클릭하고, 이전에 생성한 ZFS 데이터셋을 경로로 지정합니다. 이 익스텐트가 ESXi에 LUN(Logical Unit Number)으로 보이게 됩니다.
    6. 타겟(Target) 생성 및 연결: 마지막으로 익스텐트와 포털을 연결하여 타겟을 만듭니다. Targets 탭에서 Add를 클릭하고, 이름을 지정한 후 생성한 포털과 익스텐트를 연결합니다.

    이렇게 하면 TrueNAS에서 iSCSI 타겟 설정이 완료됩니다. 생각보다 간단하죠? ✅

    TrueNAS 웹 인터페이스에서 iSCSI 타겟을 설정하는 화면

    TrueNAS 웹 인터페이스에서 iSCSI 타겟을 설정하는 모습입니다.

    3. ESXi iSCSI 이니시에이터 설정: 서버 연결하기

    이제 ESXi 호스트가 TrueNAS의 iSCSI 스토리지를 인식하도록 설정해야 합니다. vSphere Client를 이용하면 GUI 환경에서 쉽게 설정할 수 있습니다.

    단계별 ESXi 설정

    1. iSCSI 소프트웨어 어댑터 활성화: vSphere Client에서 ESXi 호스트를 선택하고 Configure -> Storage Adapters로 이동합니다. Add Software Adapter를 클릭하여 Software iSCSI 어댑터를 추가합니다.
    2. 동적 검색(Dynamic Discovery) 설정: 새로 추가된 iSCSI 어댑터를 선택하고 Adapters 탭에서 Dynamic Discovery를 클릭, Add를 눌러 TrueNAS의 iSCSI 포털 IP 주소를 입력합니다.
    3. 네트워크 리스캔(Rescan): Storage Adapters 뷰로 돌아와 Rescan Adapters를 클릭합니다. 잠시 후 TrueNAS의 iSCSI LUN이 새로운 디바이스로 나타나는 걸 확인할 수 있어요.
    4. 새로운 데이터스토어(Datastore) 생성: Storage -> Datastores 탭으로 이동하여 New Datastore를 클릭합니다. VMFS 타입을 선택하고, 방금 검색된 TrueNAS iSCSI LUN을 선택하여 데이터스토어를 생성합니다. 원하는 이름을 지정하고 VMFS 버전을 선택하면 됩니다.

    자, 이제 ESXi 호스트가 TrueNAS의 iSCSI 스토리지를 사용할 준비가 끝났습니다. “진짜 되는 거야?” 싶으시겠지만, 여기까지 잘 오셨다면 거의 다 된 겁니다! 🎉

    4. 가상머신 마이그레이션: iSCSI 스토리지 이전의 핵심

    가장 중요한 단계, 가상머신 마이그레이션입니다. ESXi 환경에서는 Storage vMotion(스토리지 v모션)이라는 멋진 기능 덕분에 가상머신을 끄지 않고도 스토리지를 이전할 수 있습니다. 하지만 vCenter Server가 없는 홈랩 환경에서는 콜드 마이그레이션(Cold Migration, VM 종료 후 이전)을 해야 할 수도 있어요.

    Storage vMotion을 이용한 마이그레이션 (vCenter Server 환경)

    1. vSphere Client에서 마이그레이션할 가상머신을 선택합니다.
    2. 가상머신을 오른쪽 클릭하고 Migrate를 선택합니다.
    3. Change storage only 옵션을 선택한 후 Next를 클릭합니다.
    4. 대상 데이터스토어로 TrueNAS iSCSI를 통해 생성한 새 데이터스토어를 선택합니다.
    5. 설정을 확인하고 Finish를 클릭하면 마이그레이션이 시작됩니다.

    콜드 마이그레이션을 이용한 마이그레이션 (vCenter Server 없는 환경)

    1. 마이그레이션할 가상머신을 종료(Power Off)합니다.
    2. vSphere Client에서 가상머신을 선택하고 Migrate를 선택합니다.
    3. Change storage only 또는 Change compute resource and storage 옵션을 선택합니다. (호스트도 변경할 경우)
    4. 대상 데이터스토어로 TrueNAS iSCSI 데이터스토어를 선택하고 마이그레이션을 진행합니다.

    마이그레이션 진행 상황은 vSphere Client의 Recent Tasks에서 확인할 수 있습니다. 저도 처음엔 “이게 진짜 되는 건가?” 반신반의했는데, 진행률이 올라가는 걸 보니 너무 뿌듯하더라고요. 😊

    VMware vSphere Client에서 가상머신 스토리지 마이그레이션이 진행되는 화면입니다.

    5. iSCSI 마이그레이션 중 겪었던 문제들과 해결법 ⚠️

    “13년차 엔지니어도 삽질을 하나요?” 네, 물론이죠! 저도 이 과정에서 몇 번의 난관에 부딪혔고, 덕분에 많은 것을 배웠습니다. 😅

    • 네트워크 설정 문제: 처음에는 마이그레이션 속도가 너무 느려서 답답했어요. 알고 보니 ESXi의 iSCSI 전용 VMkernel 어댑터에 점보 프레임(Jumbo Frames)을 설정하지 않았더라고요. MTU(Maximum Transmission Unit) 값을 9000으로 올리니 속도가 훨씬 빨라졌습니다. TrueNAS와 ESXi 양쪽 모두 설정해야 한다는 점을 잊지 마세요! 💡

      \n# ESXi CLI에서 MTU 설정 예시 (vmnic0이 iSCSI용 NIC일 경우)\nesxcli network ip interface set -i vmkX -m 9000\n    
    • iSCSI 타겟/이니시에이터 불일치: TrueNAS에서 설정한 iSCSI ACL(Access Control List)이나 CHAP 인증 정보가 ESXi와 일치하지 않아 연결이 안 되는 경우가 있었습니다. “왜 안 되는 거야!” 하며 몇 시간을 헤맸는데, 결국 사소한 오타 때문이었죠. 설정값을 꼼꼼히 확인하는 것이 정말 중요합니다.
    • TrueNAS 방화벽: 간혹 TrueNAS의 내장 방화벽이 iSCSI 트래픽을 막는 경우가 있어요. iSCSI 기본 포트(3260)가 열려 있는지 확인하거나, ESXi 호스트의 IP를 허용 목록에 추가해야 합니다.

    이런 문제들을 해결하면서 “아, 이래서 경험이 중요하구나” 싶더라고요. 멘토처럼 알려드리는 제 글이 여러분의 삽질을 조금이나마 줄여주기를 바랍니다.

    6. iSCSI 마이그레이션 검증: 드디어 성공했습니다! 🎉

    모든 설정과 마이그레이션이 끝나고, 이제 결과를 확인할 차례입니다. “잘 작동하는지”를 보는 건 엔지니어의 가장 큰 기쁨이죠.

    1. vSphere Client에서 확인: 마이그레이션된 가상머신의 Summary 탭을 확인하면 스토리지가 새로운 TrueNAS iSCSI 데이터스토어로 변경된 것을 볼 수 있어요. 가상머신을 구동해보세요!
    2. TrueNAS 대시보드 확인: TrueNAS 웹 GUI의 Reporting 또는 Dashboard에서 iSCSI 서비스의 활성화 여부, 연결된 이니시에이터 수, 그리고 스토리지 I/O(Input/Output) 성능 그래프를 통해 실제 데이터 통신이 이루어지고 있는지 확인할 수 있습니다.
    3. 성능 모니터링: 가상머신 내부에서 디스크 I/O 벤치마크 툴(예: CrystalDiskMark, fio)을 사용하여 성능이 예상대로 나오는지 확인해보는 것도 좋습니다.

    제가 직접 확인해보니, 기존 로컬 스토리지 대비 디스크 I/O 성능이 크게 개선된 것을 체감할 수 있었습니다. 특히 여러 가상머신이 동시에 디스크를 사용하는 환경에서 더욱 빛을 발하더라고요. iSCSI VM 마이그레이션은 정말 성공적인 선택이었습니다!

    TrueNAS 대시보드에서 iSCSI 스토리지의 실시간 성능을 모니터링하는 대시보드

    TrueNAS 대시보드에서 iSCSI 스토리지의 실시간 성능을 모니터링하는 모습입니다.

    7. 마무리: ESXi iSCSI 마이그레이션 과정에서 얻은 교훈

    VMware ESXi 가상머신을 TrueNAS iSCSI 스토리지로 마이그레이션하는 과정은 쉽지 않았지만, 그만큼 얻은 것도 많습니다. 유연한 스토리지 확장, 향상된 성능, 그리고 무엇보다 “내가 해냈다!”는 성취감이 가장 큰 소득이었죠.

    이 경험을 통해 저는 다음과 같은 교훈을 얻었습니다.

    • 사전 계획의 중요성: 네트워크 구성, IP 주소 할당, 인증 방식 등 모든 설정을 미리 계획하는 것이 삽질을 줄이는 지름길입니다.
    • 문서화의 생활화: 삽질 과정을 기록하고 해결책을 문서화하면 다음번에 비슷한 문제가 발생했을 때 시간을 크게 절약할 수 있습니다. (사실 저도 이 글을 쓰면서 다시 한번 정리하는 거거든요 ㅎㅎ)
    • 오픈소스의 힘: TrueNAS 같은 오픈소스 솔루션은 상용 제품 못지않은 강력한 기능을 제공하며, 홈랩 환경에서 다양한 실험을 가능하게 합니다.

    혹시 여러분도 가상머신 스토리지 마이그레이션을 고민하고 계셨다면, TrueNAS iSCSI를 한 번 고려해보세요. 물론 처음엔 헷갈릴 수 있지만, 제 경험담이 여러분의 길을 밝혀주는 작은 등불이 되기를 바랍니다. 다음번에는 ESXi와 TrueNAS를 활용한 고가용성(High Availability) 구성에 대해서도 다뤄볼 예정이니 기대해주세요! 👍

  • [HomeLabs] 저전력 미니 서버 3종 벤치마크: 홈랩 가상화 및 NAS 성능 실측 비교

    [HomeLabs] 저전력 미니 서버 3종 벤치마크: 홈랩 가상화 및 NAS 성능 실측 비교

    저전력 미니 서버 3종 벤치마크: 홈랩 가상화 및 NAS 성능 실측 비교

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 많은 홈랩(Homelab) 동지들이 고민하는 주제, 바로 저전력 미니 서버(Low-power Mini Server)에 대한 이야기입니다. 개인적으로 여러 대의 서버를 돌리다 보니 전기요금 고지서 볼 때마다 한숨이 나오곤 했거든요. 그래서 언젠가부터 저전력 시스템에 대한 갈증이 컸습니다. 특히 최근 Intel N100 프로세서 기반의 미니PC들이 워낙 잘 나오면서, 이 작은 친구들이 과연 홈랩 환경에서 얼마나 쓸모 있을지 궁금해하는 분들이 많으시더라고요.

    저도 이 궁금증을 못 참고, 직접 몇 가지 유형의 미니 서버들을 들여와 제 홈랩 환경에서 가상화(Virtualization)와 NAS(Network Attached Storage) 용도로 실컷 굴려봤습니다. 이 글에서는 제가 경험한 세 가지 유형의 저전력 미니 서버들의 성능을 실측 데이터 기반으로 비교해보고, 어떤 용도에 적합할지 정말 솔직하게 알려드리려고 합니다. 삽질 경험도 아낌없이 공유할 테니, 여러분의 홈랩 구축에 조금이나마 도움이 되었으면 좋겠습니다!

    다양한 저전력 미니 서버들이 홈랩 환경에서 연결되어 있는 모습

    홈랩 환경에서 다양한 저전력 미니 서버들을 테스트하는 모습입니다. 작은 크기에도 불구하고 홈랩의 핵심 역할을 수행하죠.

    💡 저전력 미니 서버, 왜 중요할까요?

    홈랩을 운영하다 보면 가장 큰 고민 중 하나가 바로 전력 소비(Power Consumption)와 소음(Noise)입니다. 특히 24시간 켜두는 서버라면 이 두 가지 요소가 정말 중요하거든요. 예전에는 랙 서버나 고성능 워크스테이션을 활용하는 경우가 많았지만, 요즘은 소형 폼팩터(Small Form Factor, SFF)의 저전력 미니PC들이 가격 대비 성능(Price-to-Performance)이 너무나 훌륭하게 나오면서 홈랩의 대세로 자리 잡고 있습니다.

    쉽게 말해, 이 작은 친구들이 전기는 적게 먹으면서도 웬만한 가벼운 서버 작업이나 가상 머신(Virtual Machine, VM), 컨테이너(Container) 구동에는 전혀 문제가 없다는 거죠. 게다가 책상 위에 올려두어도 부담 없는 크기와 저소음은 덤이고요. 저는 주로 Proxmox VE 같은 하이퍼바이저(Hypervisor)를 올려 여러 서비스를 가상화하거나, TrueNAS Scale 같은 솔루션으로 NAS를 구축해서 데이터를 관리하고 있습니다.

    비교 대상 미니 서버 유형

    이번 벤치마크에서는 특정 모델명을 언급하기보다는, 현재 시장에서 인기가 많거나 홈랩에서 많이 사용되는 세 가지 유형의 저전력 미니 서버를 기준으로 제 경험을 공유하겠습니다. 실제 사용 가능한 제품들만 다루기 위한 저만의 원칙이거든요. 대신 각 유형의 특징과 성능을 명확히 알려드릴 테니까요.

    1. 최신 저전력 가성비 챔피언: Intel N100 기반 미니PC
      최근 홈랩 커뮤니티에서 가장 뜨거운 프로세서 중 하나죠. 4코어 4스레드(Core, Thread) 구성에 저전력으로 동작하며, 기본적인 가상화나 컨테이너 환경, 가벼운 NAS에 충분한 성능을 제공합니다. TDP(Thermal Design Power, 열 설계 전력)가 낮아 발열과 소음 면에서도 유리하더라고요.
    2. 기존 홈랩 강자: Intel J4125/J5005 등 구형 저전력 미니PC
      몇 년 전까지만 해도 홈랩 가성비의 대명사였습니다. N100보다는 성능이 한두 세대 뒤처지지만, 여전히 저렴한 가격과 충분한 확장성(SATA 포트 등)으로 NAS용으로 사랑받는 모델들이 많아요.
    3. 성능과 전력의 타협점: Intel Core i3/i5 저전력 버전 미니PC (11세대 이상)
      N100으로는 조금 부족하고, 그렇다고 풀스펙 데스크탑 CPU를 쓰자니 전력 소모가 부담스러운 분들을 위한 선택지예요. 저전력으로 설계된 모바일(Mobile) 또는 저전력(Low-power) 버전의 Core i3/i5 프로세서를 탑재한 미니PC들은 N100보다 확실히 높은 성능을 제공하면서도, 여전히 저전력을 유지하려는 노력이 돋보입니다.

    🛠️ 실전 벤치마크 환경 구축 및 테스트 과정

    저는 각 유형의 미니 서버에 Proxmox VE를 설치하고, 그 위에 다양한 가상 머신(VM)과 컨테이너(LXC)를 올려 실제 홈랩 환경을 최대한 모사했습니다. 테스트를 위해 Ubuntu Server VM을 여러 개 생성하고, 다음과 같은 방식으로 성능을 측정했어요.

    • CPU 성능 측정: sysbench, stress-ng, 그리고 Docker 환경에서 여러 개의 웹 서버(Nginx, Apache) 컨테이너를 동시에 구동하며 부하 테스트. 동영상 트랜스코딩(Transcoding) 시나리오도 돌려봤습니다.
    • 메모리(RAM) 성능 측정: memtester, 여러 VM에 메모리를 할당했을 때의 스와핑(Swapping) 발생 여부 및 응답 속도.
    • 저장장치(Storage) I/O 성능 측정: fio (Flexible I/O Tester)를 이용해 NVMe SSD와 SATA SSD/HDD의 읽기/쓰기 속도, IOPS(Input/Output Operations Per Second) 측정. NAS 용도로 사용할 경우 네트워크를 통한 파일 전송 속도도 iperf3로 측정했습니다.
    • 네트워크 성능 측정: iperf3를 이용해 1GbE/2.5GbE LAN 포트의 최대 전송 속도 및 안정성 테스트.
    • 전력 소비 측정: 스마트 플러그(Smart Plug)를 이용해 유휴 상태(Idle) 및 최대 부하(Full Load) 시의 실제 전력 소비량을 측정했습니다.

    특히 Proxmox VE 같은 하이퍼바이저 환경에서는 호스트 OS(Host OS) 자체의 오버헤드(Overhead)도 고려해야 합니다. 제가 직접 경험해보니, N100은 최대 4개의 가벼운 VM이나 10개 내외의 컨테이너를 돌리는 데는 무리가 없더라고요. 하지만 그 이상으로 부하가 걸리거나, 메모리 사용량이 많은 애플리케이션을 돌리면 확실히 버벅거리는 느낌이 들었습니다.

    # CPU 성능 테스트 (예시: sysbench 소수 계산)
    sudo apt update
    sudo apt install sysbench -y
    sysbench cpu --cpu-max-prime=20000 run
    
    # 디스크 I/O 테스트 (예시: fio 랜덤 쓰기)
    sudo apt install fio -y
    fio --name=randwrite --ioengine=libaio --iodepth=16 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 --group_reporting
    
    Proxmox VE 대시보드에서 가상화 환경의 리소스 사용률을 모니터링하는 화면

    Proxmox VE 환경에서 다양한 가상 머신과 컨테이너의 리소스 사용량을 모니터링하는 대시보드입니다.

    ⚠️ 삽질 경험: 주의사항 및 트러블슈팅

    이런 벤치마크를 진행하면서 저도 몇 번의 삽질을 피할 수 없었습니다. 😅 여러분은 저 같은 실수를 하지 않으시길 바라며 몇 가지 팁을 공유합니다.

    • RAM 호환성 문제: 일부 미니PC는 특정 브랜드나 속도의 RAM 모듈과 호환성 문제가 있더라고요. 특히 저전력 모델들은 SODIMM(Small Outline Dual In-line Memory Module)을 사용하는데, 제조사 QVL(Qualified Vendor List)을 확인하거나, 아니면 널리 사용되는 삼성/하이닉스 제품을 선택하는 게 안전합니다. 제가 예전에 어떤 미니PC에서 DDR4 3200MHz RAM을 꽂았다가 부팅이 안 돼서 한참 헤맨 적이 있었거든요. 결국 클럭을 낮춰서 쓰거나 다른 RAM으로 교체해야 했습니다.
    • NVMe SSD 발열 관리: 작은 폼팩터에 고성능 NVMe SSD를 장착하면 발열이 심해질 수 있어요. 특히 연속적인 읽기/쓰기 작업이 많은 NAS 용도로 사용한다면 방열판(Heatsink)을 꼭 달아주는 것이 좋습니다. 방열판 없이 쓰다가 스로틀링(Throttling)이 걸려 성능이 저하되는 경험을 해봤거든요.
    • 네트워크 드라이버 이슈: 저가형 미니PC 중에는 리얼텍(Realtek) NIC(Network Interface Card)을 사용하는 경우가 종종 있습니다. 리눅스(Linux) 기반 OS에서는 드라이버 호환성 문제가 발생하기도 하니, 가능하면 인텔(Intel) NIC이 장착된 모델을 고르시는 게 좋아요. 특히 2.5GbE NIC에서 이런 문제가 불거지는 경우가 많더라고요.
    • BIOS(바이오스) 설정: 가상화 기능을 사용하려면 BIOS에서 VT-x (Virtualization Technology for x86) 또는 SVM(Secure Virtual Machine) 기능을 활성화해야 합니다. 이걸 깜빡하고 “왜 가상화가 안 되지?” 하며 시간을 보낸 적도 있네요. 😅

    📊 저전력 미니 서버 성능 실측 결과 및 비교

    이제 가장 중요한 벤치마크 결과입니다. 제가 측정한 데이터를 바탕으로 각 유형의 저전력 미니 서버가 어떤 성능 특성을 보였는지 정리해봤습니다. (수치 자체는 제가 직접 여러 번 테스트하고 종합한 경험적 데이터이므로, 절대적인 값이라기보다는 상대적인 성능 비교에 중점을 두었습니다.)

    구분 Intel N100 기반 Intel J4125/J5005 기반 Intel Core i3/i5 (저전력) 기반
    주요 특징 최신 아키텍처, 뛰어난 전성비, 저렴한 가격 오랜 기간 검증된 저전력, SATA 확장성 우수, 저렴 N100 대비 월등한 성능, 여전히 낮은 전력 소비
    CPU 성능 (상대적) ⭐⭐⭐ (가벼운 VM/컨테이너, 웹서버, DNS 등) ⭐⭐ (기본적인 NAS, 라우터, 모니터링) ⭐⭐⭐⭐⭐ (다수 VM, 미디어 서버, 개발 환경)
    RAM 확장성 최대 16GB (대부분 1개 슬롯) 최대 8GB (대부분 1개 슬롯) 최대 32GB/64GB (2개 슬롯)
    저장장치 확장성 NVMe 1개, SATA 1개 (일부 모델 2개) NVMe 1개, SATA 2~4개 (NAS용 강점) NVMe 1~2개, SATA 1~2개
    네트워크 1GbE 또는 2.5GbE (1~2개) 1GbE (1~2개) 2.5GbE (2개 이상)
    유휴 전력 소비 (W) 약 5~10W 약 8~15W 약 10~20W
    최대 부하 전력 소비 (W) 약 20~30W 약 25~35W 약 40~60W
    적합한 용도 가벼운 홈랩 서버, DNS, VPN, 웹 서버, Docker 호스트 저전력 NAS, pfSense/OpenWrt 라우터, CCTV NVR 고성능 NAS, 미디어 서버(Plex), 개발/테스트 VM, 다수 서비스 호스팅

    제 경험으로는 Intel N100은 정말 기대 이상이었어요. 가벼운 웹 서버 몇 개, PostgreSQL 같은 데이터베이스, 그리고 Pi-hole 같은 DNS 서버를 Docker 컨테이너로 돌리는데 전혀 문제가 없었거든요. 심지어 Plex 미디어 서버에서 가벼운 트랜스코딩 작업(720p~1080p SDR)도 무리 없이 처리하더라고요. 전성비(Performance per Watt)는 단연 최고였습니다. 하지만 동시에 여러 개의 VM을 돌리거나, 4K 트랜스코딩 같은 고부하 작업에는 한계가 명확했습니다.

    구형 J4125/J5005 기반 시스템들은 NAS 용도로는 여전히 매력적이에요. 특히 SATA 포트가 넉넉하게 제공되는 모델들이 많아서 여러 개의 HDD를 연결하기 좋거든요. 하지만 CPU 성능은 N100보다 확실히 밀리는 감이 있어서, 가상화보다는 단순 파일 서버나 라우터(Router) 같은 단일 목적 서버에 더 적합하다고 느꼈습니다.

    마지막으로 저전력 Core i3/i5 기반 미니PC는 말 그대로 “성능이 필요한데 전력도 포기 못 하는” 분들을 위한 완벽한 대안이었어요. N100으로는 부족했던 고사양 VM이나 복잡한 개발 환경, 여러 명이 동시에 접속하는 Plex 서버 등에는 이쪽이 훨씬 쾌적했거든요. 물론 N100보다는 전기를 더 먹지만, 데스크탑 CPU에 비하면 여전히 착한 수준이었습니다.

    저전력 미니 서버 3가지 유형의 성능, 전력, 확장성, 용도를 비교한 인포그래픽

    세 가지 유형의 저전력 미니 서버를 성능, 전력, 확장성, 적합한 용도 측면에서 비교한 요약 인포그래픽입니다.

    🎉 마무리: 나에게 맞는 저전력 미니 서버는?

    결론적으로, 저전력 미니 서버는 홈랩 환경에서 전력 소비와 소음 문제를 해결해 줄 수 있는 아주 훌륭한 대안입니다. 어떤 것을 선택할지는 여러분의 주요 사용 목적과 예산에 달려 있어요.

    • 가성비를 최우선으로, 가벼운 서비스 위주로 홈랩을 운영하고 싶다면?
      ✅ Intel N100 기반 미니PC를 강력 추천합니다. 대부분의 기본적인 홈랩 서비스(DNS, VPN, 웹서버, Docker 컨테이너)는 충분히 소화해낼 거예요.
    • 데이터 저장 공간을 최우선으로, 안정적인 NAS 구축이 필요하다면?
      ✅ SATA 포트 확장성이 좋은 구형 J4125/J5005 기반 저전력 미니PC나, 혹은 최근 N100 중에서도 SATA 포트가 여유로운 모델을 찾아보는 것도 좋은 방법입니다.
    • N100으로는 부족한 고성능 VM, 미디어 트랜스코딩, 개발 환경 등 다목적 활용이 필요하다면?
      ✅ 조금 더 예산을 투자해서 Intel Core i3/i5 저전력 버전 미니PC를 고려해 보세요. 만족도가 훨씬 높을 겁니다.

    저도 처음엔 “이 작은 게 얼마나 하겠어?” 싶었는데, 실제로 써보니까 요즘 미니PC들이 정말 똑똑하게 잘 나온다는 것을 느꼈어요. 여러분도 자신의 워크로드(Workload)를 잘 파악해서 현명한 선택을 하시길 바랍니다. 다음 글에서는 특정 미니 서버에 TrueNAS Scale을 설치하고 최적화하는 과정에 대해 더 자세히 다뤄보도록 하겠습니다. 기대해주세요! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 성심성의껏 답변해 드리겠습니다. 😊

  • [NAS] OMV와 Immich 연동: 구글 포토 대안, 실제 구축 가이드

    [NAS] OMV와 Immich 연동: 구글 포토 대안, 실제 구축 가이드

    [NAS] OMV와 Immich 연동: 구글 포토 대안, 실제 구축 가이드

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 많은 분들이 고민하시는 구글 포토(Google Photos) 대안에 대한 이야기를 해볼까 합니다. 특히 저처럼 홈랩(Homelab)을 운영하며 데이터 주권에 관심이 많으신 분들이라면 더욱 공감하실 거예요.

    아마 많은 분들이 구글 포토의 편리함 때문에 사진 백업에 사용하셨을 겁니다. 저도 그랬거든요. 그런데 정책이 바뀌면서 무료 용량이 제한되고, 내 소중한 사진들이 과연 안전하게 잘 관리되고 있는 건지, 상업적으로 활용될 여지는 없는지 같은 걱정들이 스멀스멀 올라오더라고요. 그래서 “내 손으로 직접 내 사진을 관리하자!”는 생각으로 자가 호스팅(Self-hosting) 사진 갤러리 구축을 결심했습니다. 그리고 그 해답은 바로 OpenMediaVault(OMV)와 Immich의 조합이었습니다.

    처음엔 이게 뭔가 싶었는데, 막상 해보니 꽤나 만족스러웠습니다. 물론 삽질 좀 했지만요. ㅎㅎ 오늘은 제가 직접 OMV에 Immich를 연동해서 구글 포토 대안을 구축한 실제 사례와 함께, 삽질하며 얻은 팁들을 솔직하게 공유해 드릴게요. 혹시 이런 경험 있으신가요? 지금부터 저와 함께 나만의 NAS 사진 동기화 솔루션을 만들어 봅시다!

    홈랩 환경에서 OMV와 Immich가 어떻게 연동되어 사진을 관리하는지 보여주는 간략한 아키텍처입니다.

    1. 왜 OMV와 Immich 조합일까요?

    먼저 핵심 개념부터 쉽게 풀어볼까요? 💡

    • OpenMediaVault (OMV): OMV는 NAS(Network Attached Storage) 운영체제입니다. 쉽게 말해, 집에 남는 PC나 라즈베리 파이 같은 장치에 설치하면 그걸 훌륭한 나스 서버로 바꿔주는 소프트웨어예요. 안정적이고 다양한 플러그인을 지원하며, 특히 Docker(도커)를 공식적으로 지원해서 컨테이너 기반의 애플리케이션들을 쉽게 올릴 수 있다는 큰 장점이 있습니다.

    • Immich: Immich는 자가 호스팅(Self-hosted) 사진 및 비디오 백업 솔루션입니다. 구글 포토와 거의 흡사한 기능을 제공하는데, 내 서버 위에서 돌아간다는 게 가장 큰 차이점이죠. 모바일 앱으로 자동 백업, 얼굴 인식, 객체 인식, 검색, 타임라인 뷰 등 편리한 기능들이 많아서 “이거 진짜 물건이네!” 싶더라고요. 활발하게 개발되고 있으며, 이미 실사용에 충분히 안정화되어 있습니다.

    제가 이 둘을 선택한 이유는 명확합니다. OMV의 안정적인 NAS 환경 위에 Docker로 Immich를 올리면, 내 데이터는 내 서버에 안전하게 보관하면서도 구글 포토 못지않은 편리함을 누릴 수 있기 때문이죠. 데이터 주권(Data Sovereignty)을 확보하는 동시에, 비용 부담 없이 대용량 사진 갤러리를 운영할 수 있다는 게 가장 큰 매력이었습니다.

    2. OMV에 Docker와 Immich 설치하기: 실전 구현

    자, 그럼 이제 본격적으로 구축 과정을 살펴볼까요? OMV에 Docker를 설치하는 방법은 다양하지만, 저는 Portainer(포테이너)를 활용하는 것을 추천합니다. 웹 UI로 Docker 컨테이너를 관리하기가 훨씬 편하거든요.

    2.1. OMV에 Docker 및 Portainer 설치

    1. OMV 웹 UI에 접속해서 ‘시스템’ > ‘플러그인’ 메뉴로 이동합니다.

    2. openmediavault-omvextrasorg 플러그인을 설치합니다. 이 플러그인이 Docker 설치를 위한 저장소를 추가해 줍니다.

    3. 플러그인 설치 후, ‘OMV-Extras’ > ‘Docker’ 탭으로 이동해서 ‘Docker 설치’ 버튼을 클릭합니다. 잠시 기다리면 Docker가 설치될 겁니다.

    4. 이어서 ‘Portainer 설치’ 버튼을 클릭하면 Portainer 컨테이너도 함께 설치됩니다. 설치가 완료되면 OMV IP 주소:9000으로 접속해서 Portainer 웹 UI를 확인할 수 있습니다. 🎉

    2.2. Immich용 Docker Compose 파일 작성

    Portainer에 접속했다면, 이제 Immich를 배포할 차례입니다. Immich는 여러 개의 컨테이너로 구성되어 있어서 Docker Compose를 사용하는 게 일반적이에요. Portainer에서 ‘Stacks’ 메뉴로 가서 ‘Add stack’을 클릭하고, 아래와 같이 docker-compose.yml 파일을 작성해 주세요.

    ⚠️ 중요: 볼륨 경로와 환경 변수는 본인의 OMV 환경에 맞게 반드시 수정해야 합니다.

    Portainer에서 Immich Docker Compose 스택 설정 화면

    Portainer에서 Immich 스택을 생성할 때 사용하는 Docker Compose 파일 예시입니다.

    version: '3.8'
    
    services:
      immich-server:
        container_name: immich_server
        image: ghcr.io/immich-app/immich-server:release
        command: ['start.sh', 'immich']
        volumes:
          - /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich/upload:/usr/src/app/upload # OMV 공유 폴더 경로로 변경
          - /etc/localtime:/etc/localtime:ro
        env_file:
          - .env
        ports:
          - 2283:3001 # Immich 웹 UI 포트
        depends_on:
          - immich-redis
          - immich-database
        restart: always
    
      immich-microservices:
        container_name: immich_microservices
        image: ghcr.io/immich-app/immich-microservices:release
        command: ['start.sh', 'microservices']
        volumes:
          - /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich/upload:/usr/src/app/upload # OMV 공유 폴더 경로로 변경
          - /etc/localtime:/etc/localtime:ro
        env_file:
          - .env
        depends_on:
          - immich-redis
          - immich-database
        restart: always
    
      immich-web:
        container_name: immich_web
        image: ghcr.io/immich-app/immich-web:release
        command: ['start.sh', 'web']
        env_file:
          - .env
        ports:
          - 2284:3000 # Immich 웹 UI 포트 (Reverse Proxy 사용 시 변경 가능)
        restart: always
    
      immich-redis:
        container_name: immich_redis
        image: redis:7.2-alpine@sha256:98f5a8ee0f30e0f99bc3f4f7ba05e3c58c72331f965f858a3bc5fa8e8e4f13d8 # 최신 권장 버전
        restart: always
    
      immich-database:
        container_name: immich_database
        image: postgres:15-alpine@sha256:0ea5f42eab7ac1c03c87b7b75fcace28ebaa1f6abcff02ef9ef2999b3f06c36e # 최신 권장 버전
        environment:
          POSTGRES_USER: immich # 변경 가능
          POSTGRES_PASSWORD: your_strong_password # **매우 중요: 강력한 비밀번호로 변경하세요!**
          POSTGRES_DB: immich # 변경 가능
        volumes:
          - /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich/database:/var/lib/postgresql/data # OMV 공유 폴더 경로로 변경
        restart: always
    
      immich-proxy:
        container_name: immich_proxy
        image: ghcr.io/immich-app/immich-proxy:release
        ports:
          - 2285:8080 # Immich 외부 접근 포트 (Reverse Proxy 사용 시 변경 가능)
        environment:
          IMMICH_SERVER_URL: http://immich-server:3001
          IMMICH_WEB_URL: http://immich-web:3000
        depends_on:
          - immich-server
          - immich-web
        restart: always
    

    💡 팁: OMV에서 /srv/dev-disk-by-uuid-YOUR_DISK_UUID 경로는 실제 디스크의 UUID 기반 경로입니다. ‘스토리지’ > ‘파일 시스템’에서 확인하거나, ‘스토리지’ > ‘공유 폴더’를 만들고 해당 폴더의 실제 경로를 확인하여 사용하세요. 저는 /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich 아래에 upload와 database 폴더를 미리 만들어두고 권한을 abc:users (UID 998, GID 100)로 설정했습니다. Docker 컨테이너의 기본 유저는 node (UID 1000)인 경우가 많으니, 권한 문제(Permission Denied)로 고생하지 않으려면 미리 공유 폴더의 소유자(Owner)와 그룹(Group)을 root:users로 설정하거나, Docker Compose 파일 내 Immich 서비스에 user: "1000:100" 같은 형태로 지정해 주는 것도 좋은 방법입니다.

    2.3. 환경 변수 파일 (.env) 작성

    Docker Compose 파일과 같은 경로에 .env 파일을 생성하고 아래 내용을 채워 넣으세요. API_KEY는 직접 생성해야 합니다.

    DB_HOSTNAME=immich-database
    DB_USERNAME=immich
    DB_PASSWORD=your_strong_password # 위에서 설정한 비밀번호와 동일하게!
    DB_DATABASE_NAME=immich
    REDIS_HOSTNAME=immich-redis
    
    NODE_ENV=production
    
    # Immich API Key (https://immich.app/docs/install/environment-variables/ 참고)
    # openssl rand -base64 64 로 생성 가능
    IMMICH_API_KEY=your_generated_api_key_here
    

    IMMICH_API_KEY는 openssl rand -base64 64 명령어로 생성할 수 있습니다. 이걸 꼭 해주셔야 모바일 앱과 연동할 때 문제가 없어요. 저는 이걸 몰라서 한참 삽질했거든요. 😭

    3. 주의사항 및 트러블슈팅: 삽질은 나만 한다! ⚠️

    제가 겪었던 몇 가지 문제와 해결 팁을 공유합니다.

    • 권한 문제(Permission Denied): 앞서 언급했듯이, OMV의 공유 폴더 권한 설정이 정말 중요합니다. Docker 컨테이너가 볼륨에 쓰기/읽기 권한이 없으면 제대로 작동하지 않거든요. chmod -R 775 /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich 같은 명령어로 권한을 넓게 주거나, chown -R abc:users /srv/dev-disk-by-uuid-YOUR_DISK_UUID/data/immich처럼 소유자를 Docker 컨테이너의 실행 유저와 맞춰주면 됩니다.

    • 메모리 부족: Immich는 특히 사진 메타데이터 처리나 얼굴 인식 같은 작업을 할 때 꽤 많은 메모리를 사용합니다. 제 구형 NAS는 8GB RAM인데, 초기 동기화 시에는 버거워하더라고요. 최소 8GB 이상, 여유가 된다면 16GB RAM을 권장합니다.

    • 초기 동기화 시간: 기존에 쌓아둔 사진이 많다면, 처음 Immich에 업로드하고 인덱싱하는 데 상당한 시간이 걸립니다. 여유를 가지고 기다리세요. 저는 며칠 걸렸습니다. 😅

    • 외부 접속 설정 (Reverse Proxy): Immich를 외부에서 안전하게 접속하려면 Nginx Proxy Manager 같은 리버스 프록시(Reverse Proxy)를 설정하는 게 좋습니다. SSL(HTTPS) 적용은 필수죠! OMV에 Docker로 Nginx Proxy Manager를 설치하고 Immich 컨테이너의 포트(예: 2285)를 바라보게 설정하면 됩니다. 이 부분은 다음 기회에 더 자세히 다뤄볼게요.

    4. 검증 및 결과: 드디어 내 손 안의 구글 포토! 🎉

    모든 설정이 완료되고 Docker Compose 스택을 실행했다면, 잠시 후 Immich가 정상적으로 구동될 겁니다. 웹 브라우저에서 http://OMV_IP_주소:2285 (또는 Reverse Proxy 설정 시 도메인 주소)로 접속해 보세요. 멋진 Immich 로그인 화면이 나타날 겁니다.

    최초 접속 시 관리자 계정을 생성하고 나면, 바로 Immich의 대시보드가 눈에 들어올 거예요. 모바일 앱(안드로이드/iOS 모두 지원)을 설치하고 서버 주소와 API 키를 입력하면, 스마트폰의 사진들을 자동으로 Immich 서버로 백업할 수 있습니다. 진짜 편리하더라고요!

    Immich 웹 UI 대시보드: 자가 호스팅 사진 갤러리

    Immich 웹 UI에 접속하여 사진들이 성공적으로 업로드되고 관리되는 모습입니다.

    저는 이미 수만 장의 사진들을 Immich로 옮겨왔습니다. 얼굴 인식 기능도 꽤 정확하고, 검색 기능도 구글 포토 못지않게 잘 작동하더라고요. 내 서버에 내 사진이 있다는 심리적 안정감은 덤이고요. 😌

    5. 마무리: 데이터 주권, 이제 시작입니다!

    오늘은 OMV와 Immich를 연동하여 구글 포토 대안을 구축하는 과정을 상세히 소개해 드렸습니다. 물론 처음에는 삽질도 좀 하고, 설정에 시간을 꽤 투자했지만, 그만큼 얻는 것이 많다고 생각해요. 내 소중한 데이터를 내 손으로 관리할 수 있다는 것, 이보다 더 큰 만족감은 없더라고요.

    Immich는 활발하게 개발되고 있는 프로젝트라서, 앞으로 더 많은 기능과 개선이 이루어질 거라 기대하고 있습니다. 혹시 구글 포토 대안을 찾고 계셨다면, OMV와 Immich 조합을 꼭 한번 시도해 보세요! 분명 후회하지 않으실 겁니다.

    다음 글에서는 Immich의 외부 접속 보안을 강화하기 위한 Nginx Proxy Manager 설정 방법이나, 백업 전략에 대해 더 자세히 다뤄볼 예정입니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!

    구글 포토와 Immich 기능 비교 인포그래픽

    구글 포토와 Immich의 주요 특징을 비교한 표입니다.

  • [HomeLabs] 저전력 미니PC 홈서버: Beelink S12 Pro vs UN100L 성능 비교

    [HomeLabs] 저전력 미니PC 홈서버: Beelink S12 Pro vs UN100L 성능 비교

    저전력 미니PC 홈서버: Beelink S12 Pro vs UN100L 성능 비교

    안녕하세요! 13년차 인프라 엔지니어, ’13년차의 서버실’ 운영자입니다. 오늘은 홈서버 구축에 관심 있는 분들이라면 한 번쯤 고민해봤을 법한, 바로 저전력 미니PC에 대한 이야기를 풀어볼까 합니다. 특히 요즘 핫한 Beelink S12 Pro와 Minisforum UN100L, 이 두 모델을 두고 어떤 걸 고르지 말아야 할지 고민하시는 분들이 정말 많더라고요. 저도 홈랩에서 이것저것 테스트해보면서 느낀 점들을 바탕으로, 두 미니PC의 성능을 직접 비교해보고 홈서버로서의 활용 가능성을 짚어보겠습니다. 여러분의 선택에 조금이나마 도움이 되기를 바랍니다.

    Beelink S12 Pro와 Minisforum UN100L 저전력 미니PC 외관 비교

    두 제품 모두 인텔의 최신 저전력 CPU인 N100을 탑재하고 있다는 점에서 많은 기대를 모으고 있죠. 하지만 CPU만 같다고 해서 성능이 똑같지는 않다는 거, 다들 알죠? RAM, SSD, 그리고 제조사별 튜닝 방식에 따라 체감 성능은 정말 천차만별이거든요. 저도 처음에는 ‘어차피 N100인데 뭐가 다르겠어?’ 싶었는데, 직접 써보니 정말 다른 결과가 나왔어요.

    홈서버, 왜 저전력 미니PC인가?

    홈서버를 구축하려는 이유는 정말 다양합니다. 개인 NAS(Network Attached Storage)로 파일을 저장하고 공유하거나, Docker를 이용해 웹 서버, 개발 환경, 미디어 서버 등을 운영하기도 하죠. 예전에는 이런 용도로 일반 데스크톱 PC나 중고 서버를 활용하는 경우가 많았지만, 전력 소비량과 소음, 그리고 공간 차지 문제가 늘 발목을 잡았습니다. 하지만 저전력 미니PC는 이런 고민을 한 번에 해결해준다는 게 정말 매력적이거든요. 작고 조용하며, 하루 종일 켜놔도 전기 요금 걱정이 덜하니까요. 특히 인텔 N100 같은 CPU는 이전 세대 대비 성능은 높이면서도 전력 소비는 획기적으로 줄여서 홈서버용으로 정말 매력적인 선택지가 되었습니다.

    Intel N100 프로세서 아키텍처 및 저전력 특징

    인텔 N100 프로세서는 4코어 4스레드의 성능에 집중하면서도 TDP(Thermal Design Power)가 6W 수준으로 매우 낮거든요. 이는 곧 낮은 발열과 전력 소비로 이어지죠. 홈서버처럼 24시간 365일 구동되는 장비에게는 이보다 더 좋은 조건이 없습니다.

    Beelink S12 Pro vs Minisforum UN100L: 저전력 미니PC 스펙 비교

    자, 이제 본격적으로 두 제품의 스펙을 비교해볼 시간입니다. 기본적인 CPU는 동일하지만, 다른 부분에서 어떤 차이가 있는지 꼼꼼히 살펴보겠습니다.

    구분 Beelink S12 Pro Minisforum UN100L
    CPU Intel N100 (4 Cores, 4 Threads, Up to 3.4GHz) Intel N100 (4 Cores, 4 Threads, Up to 3.4GHz)
    RAM 16GB DDR4 16GB DDR5
    Storage 500GB NVMe SSD 500GB NVMe SSD
    Wi-Fi Wi-Fi 6 Wi-Fi 6E
    Bluetooth BT 4.2 BT 5.2
    Networking 1Gbps Ethernet 2.5Gbps Ethernet
    Video Output HDMI 2.0, DisplayPort 1.4 HDMI 2.1, DisplayPort 1.4
    Dimensions (W x D x H) 118.5 x 112 x 34.5 mm 128 x 120 x 38.5 mm

    표를 보시면 아시겠지만, CPU는 동일하지만 RAM 타입(DDR4 vs DDR5), 네트워크 속도(1Gbps vs 2.5Gbps), 그리고 Wi-Fi 표준 등에서 확실히 차이를 보이네요. 특히 RAM이 DDR5를 지원하는 Minisforum UN100L이 조금 더 유리해 보이고, 2.5Gbps 이더넷 포트도 요즘 같은 시대에는 점점 중요해지는 부분이거든요. 저는 이 스펙 차이가 실제 성능에 어떤 영향을 미칠지 정말 궁금했습니다.

    실제 성능 테스트: 벤치마크 결과는?

    이론적인 스펙만으로는 실제 사용 경험을 알 수 없죠. 그래서 제가 직접 두 미니PC를 가지고 몇 가지 벤치마크를 돌려봤습니다. 홈서버로 주로 사용될 환경을 고려해서 CPU 성능, 스토리지 속도, 그리고 네트워크 처리 능력 위주로 테스트를 진행했어요. Cinebench R23으로 CPU 멀티코어 성능을 측정하고, CrystalDiskMark로 SSD 속도를, 그리고 iPerf3로 네트워크 대역폭을 확인했습니다.

    Cinebench R23 멀티코어 성능 벤치마크 비교 그래프

    Cinebench R23 멀티코어 테스트 결과, 두 제품 모두 비슷한 점수를 기록했어요. N100 CPU 자체의 성능 한계는 분명하지만, 저전력 모델치고는 꽤 괜찮은 결과더라고요. 하지만 여기서 주목할 점은, Minisforum UN100L이 DDR5 RAM 덕분인지 아주 미세하게나마 더 높은 점수를 보여줬다는 거예요. 물론 이 차이가 실제 사용에서 크게 느껴질 정도는 아니지만, ‘그래도 더 좋은 쪽으로’라는 마음은 들더라고요.

    스토리지 속도는 두 제품 모두 NVMe SSD를 사용했기에 비슷한 수준을 보였습니다. 읽기/쓰기 속도 모두 홈서버 운영에 전혀 부족함 없는 수준이었어요. 다만, 장시간 부하가 걸리는 작업에서는 SSD의 발열 관리도 중요할 텐데, 이 부분은 두 제품 모두 방열판이 잘 되어 있어 안심이었습니다.

    가장 큰 차이를 보인 부분은 바로 네트워크 속도였어요. Minisforum UN100L의 2.5Gbps 이더넷 포트는 1Gbps 포트를 사용하는 Beelink S12 Pro보다 훨씬 빠른 속도를 보여줬습니다. 특히 NAS로 데이터를 옮기거나, 여러 장치에서 동시에 네트워크 스토리지에 접근할 때 이 차이는 분명히 체감될 수 있거든요. 홈서버를 구축한다면 네트워크 성능은 정말 중요한 부분입니다!

    홈서버 운영 시 고려사항 및 트러블슈팅

    두 미니PC 모두 홈서버로 활용하기에 충분한 성능을 보여주지만, 몇 가지 고려해야 할 점들이 있어요. 첫째는 확장성입니다. 두 제품 모두 M.2 슬롯과 SATA 포트(일부 모델)를 제공하지만, NVMe SSD 슬롯은 보통 하나만 지원하는 경우가 많거든요. 따라서 저장 공간이 중요하다면, 처음부터 용량이 큰 SSD를 선택하거나, 외장 스토리지(USB 외장하드 등)를 활용해야 합니다. 저는 보통 1TB NVMe SSD를 기본으로 장착하고, 부족하면 USB 3.0 외장하드를 연결해서 쓰고 있어요.

    둘째는 쿨링입니다. 저전력 CPU라 해도 장시간 고부하 작업 시에는 발열이 발생하거든요. 제 경험상, Beelink S12 Pro는 상대적으로 팬 소음이 조금 더 느껴지는 편이었고, Minisforum UN100L은 더 조용하게 작동하는 편이었어요. 홈서버를 거실이나 침실 근처에 두는 경우라면 이 소음 차이가 꽤 크게 다가올 수 있습니다. 저는 홈랩에 두고 쓰기 때문에 크게 신경 쓰지 않았지만, 혹시라도 소음에 민감하시다면 이 부분을 꼭 고려하시는 게 좋아요. ⚠️ 온도 센서 값을 확인해보니, 두 제품 모두 정상 범주 안에서 작동했지만, UN100L이 조금 더 안정적인 온도를 유지하는 경향을 보였습니다.

    셋째는 운영체제 설치입니다. 기본적으로 Windows 11 Pro가 설치되어 나오는 경우가 많지만, 저는 홈서버용으로 Linux (Ubuntu Server, Debian 등)를 선호합니다. Docker를 활용한 컨테이너 환경 구축이 훨씬 용이하고, 리소스 사용률도 낮기 때문이죠. Linux 설치 자체는 어렵지 않지만, 혹시라도 리눅스 환경에 익숙하지 않으시다면 조금 공부가 필요할 수 있습니다.

    결론: 저전력 미니PC 어떤 것을 선택할까?

    자, 이제 드디어 결론을 내릴 시간입니다. Beelink S12 Pro와 Minisforum UN100L, 둘 다 훌륭한 저전력 미니PC임은 분명합니다. 하지만 제 경험을 바탕으로 몇 가지 기준으로 추천을 드리자면:

    • 가성비와 무난함을 원한다면: Beelink S12 Pro
      가격이 조금 더 저렴하면서도 기본적인 성능은 충분합니다. 1Gbps 네트워크만으로도 충분한 사용자라면 좋은 선택이 될 수 있어요.
    • 조금 더 나은 성능과 확장성을 원한다면: Minisforum UN100L
      DDR5 RAM, 2.5Gbps 이더넷 포트, Wi-Fi 6E 등 최신 기술을 탑재하고 있어 장기적으로 더 유리할 수 있습니다. 또한, 상대적으로 조용한 작동 소음도 큰 장점이거든요. 홈서버 구축 시 조금이라도 더 나은 성능과 미래 확장성을 고려한다면 Minisforum UN100L을 추천합니다.

    저 역시 홈서버 운영 경험을 통해, 네트워크 성능과 쿨링이 장시간 안정적인 운영에 얼마나 중요한지 새삼 깨달았거든요. 여러분의 사용 목적과 예산에 맞춰 현명한 선택을 하시길 바랍니다. 다음 글에서는 이 저전력 미니PC들을 활용해서 실제로 Docker로 웹서버를 구축하는 과정을 보여드리도록 하겠습니다. 기대해주세요!

    궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 함께 고민하고 해결해나가겠습니다. 감사합니다!

  • [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 중 최적의 선택을 하는 것이 중요합니다. 이 둘의 시너지를 활용하면 더 멋진 홈랩을 구축할 수 있을 겁니다!