라벨이 NAS인 게시물 표시

Synology vs QNAP — 홈 NAS 플랫폼, 무엇을 기준으로 골라야 할까

홈 NAS는 이제 단순한 파일 저장 장치를 넘어, 개인용 데이터 센터이자 자동화 서버의 핵심으로 자리 잡았습니다. 수많은 데이터를 안전하게 보관하고, 다양한 서비스를 24시간 운영하기 위해 어떤 NAS 플랫폼을 선택해야 할지 고민하는 분들이 많을 것입니다. 목차 NAS 선택의 주요 기준 Synology와 QNAP 비교표 Synology의 강점과 약점 QNAP의 강점과 약점 사용 상황별 선택 가이드 결론 NAS 선택의 주요 기준 NAS는 단순히 파일을 저장하는 것 이상으로, 미디어 서버, 백업 솔루션, 심지어는 웹 서버나 애플리케이션 플랫폼으로 활용될 수 있습니다. 특히 Docker와 같은 컨테이너 기술을 활용하면 그 활용 범위는 더욱 넓어집니다. 따라서 NAS를 선택할 때는 OS의 사용 편의성, 하드웨어 사양, 확장성, 그리고 애플리케이션 생태계와 Docker 지원 여부를 중요하게 고려해야 합니다. 저의 UGREEN DXP4800 Plus NAS는 단순 파일 서버를 넘어 kiwoom-bot , shorts-trend , n8n 같은 다양한 자동화 컨테이너를 Docker Compose로 운영하는 핵심 서버 역할을 합니다. PostgreSQL 데이터베이스까지 24시간 구동되죠. 이처럼 NAS를 단순히 저장 장치가 아닌 상시 구동되는 서버로 활용하려면, OS의 안정성과 Docker 지원 여부, 그리고 충분한 하드웨어 자원이 매우 중요합니다. Synology와 QNAP 비교표 Synology와 QNAP은 홈 NAS 시장의 대표적인 두 제조사입니다. 각 플랫폼의 특징을 비교표를 통해 살펴보겠습니다. 비교 항목 Synology (시놀로지) QNAP (큐냅) OS/UI DSM(DiskStation Manager), 직관적, 안정적 QTS(QNAP Turbo Station), 기능 풍부, 복잡 성능/하드웨어 보급형 모델 중심, 적당한 성능 고성능 모델 다양, 강력한 하드웨어 앱 생태계 사용자 친화적, 풍부한 ...

Docker .env를 고쳤는데 왜 안 바뀔까

고쳤는데, 그대로다 NAS에서 돌아가는 블로그 자동화 서비스의 설정값을 하나 바꿔야 했습니다. .env 파일을 열어 값을 고치고, 컨테이너를 다시 올렸습니다. 그런데 아무것도 바뀌지 않았습니다. 파일을 다시 열어봐도 분명히 수정된 상태였습니다. 결론부터 말하면, 원인이 하나가 아니었습니다. 세 가지가 겹쳐 있었고, 그중 둘은 검색해도 잘 나오지 않는 종류였습니다. 이 글은 그 과정을 그대로 적은 기록입니다. 이 글은 Docker와 Docker Compose가 이미 설치되어 있고, 리눅스 계열 서버(또는 NAS)에서 컨테이너를 운영 중이라고 가정합니다. 원인 1: 같은 이름이면 environment가 우선입니다 Compose 파일에서 환경변수를 넣는 방법은 두 가지입니다. env_file 로 파일을 통째로 읽어오는 방법과, environment 에 직접 적는 방법입니다. services: backend: env_file: - .env environment: DATABASE_URL: postgresql://user:${POSTGRES_PASSWORD}@postgres:5432/db MONTHLY_BUDGET: 5 핵심은 이겁니다. 같은 이름의 변수가 env_file 과 environment 에 모두 있으면, environment 에 지정한 값이 우선 적용됩니다. 위 설정에서 DATABASE_URL 은 .env 에 적어도 반영되지 않습니다. Compose 파일에 같은 이름이 이미 있기 때문입니다. 제 경우가 정확히 이랬습니다. 양쪽에 중복으로 들어 있는 변수가 세 개 있었고, 하필 제가 고치려던 게 그중 하나였습니다. 파일은 분명히 바뀌었는데 컨테이너는 옛날 값을 쥐고 있던 이유입니다. 지금 내 프로젝트가 어떤 상태인지는 아래 명령으로 확인할 수 있습니다. Compose가 최종적으로 해석한 값을 보여줍니다. docker compose config Compose는 여러 곳에서 ...

NAS Docker 컨테이너 데이터 자동 백업 및 복구 가이드

NAS에서 Docker 컨테이너를 운영하다 보면 언젠가 반드시 이 질문을 만나게 됩니다. "컨테이너를 지우거나 이미지를 새로 받으면, 안에 있던 데이터는 어떻게 되나?" 설정 파일, 데이터베이스, 업로드한 파일이 한순간에 사라지는 상황은 생각보다 흔합니다. 해결책은 단순합니다. 데이터가 실제로 저장된 호스트 경로를 찾아내고, 그 폴더를 주기적으로 압축해 다른 곳에 보관하는 것 입니다. 이 글에서는 그 경로를 확인하는 방법부터 셸 스크립트 작성, 크론탭 자동화, 그리고 실제 복구 절차까지 순서대로 다룹니다. 끝까지 따라 하면 매일 새벽 자동으로 백업이 쌓이고, 오래된 백업은 스스로 정리되며, 사고가 났을 때 몇 분 안에 되돌릴 수 있는 상태 가 됩니다. 목차 왜 Docker 데이터 백업이 필요한가 내 데이터가 어디 있는지 찾기 수동으로 한 번 백업해 보기 자동 백업 스크립트 작성 크론탭으로 자동화 데이터 복구 절차 가정 및 전제조건 이 글은 NAS에 Docker가 이미 설치되어 있고, SSH로 접속할 수 있으며, 컨테이너의 데이터가 바인드 마운트(Bind Mount) 로 호스트 경로에 연결되어 있다고 가정합니다. 아직 Docker를 설치하지 않았다면 NAS에 Docker 설치하기 를 먼저 참고하세요. 본문의 경로( /volume1/... )는 예시입니다. 실제 경로는 3번 단계에서 직접 확인합니다. 1. 왜 Docker 데이터 백업이 필요한가 컨테이너는 언제든 지우고 다시 만들 수 있도록 설계되어 있습니다. 이 성질이 장점이자 위험입니다. 이미지를 업데이트하거나 docker compose down 을 실행하는 것만으로도, 컨테이너 내부에만 있던 데이터는 함께 사라집니다. 반대로 데이터가 호스트 경로에 저장되어 있다면 컨테이너를 몇 번을 지우든 데이터는 남습니다. 이 원리를 다룬 사례로 Docker 재시작 후 PostgreSQL 데이터가 사라지는 이유와 영구 저장 방법 을 함께 읽어보면 이해가 빠릅니다. ...

UGREEN DXP4800PLUS NAS로 AI 자동화 시스템 구축하기 (Docker + PostgreSQL + YouTube API + n8n 완전 가이드)

이미지
 처음에는 단순히 유튜브 쇼츠 트렌드를 수집하려고 했다. 그런데 데이터를 저장할 DB가 필요했고, 자동화 워크플로가 필요했고, TTS가 필요했고, 컨테이너 관리가 필요했다. 하나를 해결하면 다음 문제가 보였다. 결국 하나의 AI 자동화 시스템으로 발전했다. 이 글은 UGREEN DXP4800PLUS NAS 위에서 실제로 운영 중인 AI 자동화 시스템의 전체 구조를 정리한 글이다. 각 컴포넌트를 왜 선택했는지, 어떻게 연결했는지를 중심으로 설명한다. 각 기술의 상세 내용은 개별 글 링크로 연결한다. 전체 아키텍처 YouTube API ↓ Collector (수집기) ↓ PostgreSQL (데이터 저장) ↓ FastAPI (대시보드 + API) ↓ Edge-TTS (음성 생성) ↓ Video Generator (영상 합성) ↓ drafts 폴더 저장 n8n (워크플로 자동화) ↓ Telegram (알림) 모든 서비스는 UGREEN DXP4800PLUS NAS에서 Docker 컨테이너로 운영된다. 왜 NAS를 선택했는가 클라우드 서버를 쓰면 월 고정 비용이 발생한다. 여러 서비스를 동시에 운영하면 비용이 빠르게 늘어난다. UGREEN DXP4800PLUS는 현재 20개 이상의 Docker 컨테이너를 동시에 운영하면서도 CPU와 메모리에 여유가 있다. 초기 구매 비용이 있지만 월 운영 비용은 전기세뿐이다. Docker 계층: 모든 서비스의 기반 Docker가 없었다면 PostgreSQL, FastAPI, n8n을 각각 별도로 설치하고 관리해야 했다. Docker Compose로 각 서비스를 컨테이너 단위로 격리하고 하나의 스택으로 관리한다. NAS 재부팅 후에도 restart: unless-stopped 설정으로 모든 서비스가 자동 복구된다. 처음 구축할 때 depends_on 만으로는 서비스 시작 순서가 보장되지 않는다는 것을 겪었다. healthchec...

n8n Telegram 연동 방법과 자동 알림 워크플로 구축하기

이미지
 매일 아침 정책자금 공고를 직접 찾아보는 게 번거로웠다. 기업마당(bizinfo.go.kr)에 매일 새로운 공고가 올라오는데 일일이 확인하기가 쉽지 않았다. n8n으로 자동화하면 되겠다는 생각에 워크플로를 만들었다. 결과적으로 매일 오전 9시에 새로운 정책자금 공고가 Telegram으로 자동 발송되는 시스템이 완성됐다. 이 글에서는 UGREEN DXP4800PLUS NAS에서 운영 중인 n8n으로 Telegram 자동 알림 워크플로를 구축하는 방법을 정리한다. n8n이란 n8n은 노코드/로우코드 워크플로 자동화 도구다. 200개 이상의 서비스와 연동할 수 있고 Docker로 셀프 호스팅이 가능하다. 현재 UGREEN DXP4800PLUS NAS에서 Docker로 운영 중이다. bash docker ps | grep n8n # n8n Up 6 days 0.0.0.0:5678->5678/tcp Telegram Bot 준비 n8n에서 Telegram으로 메시지를 보내려면 먼저 Telegram Bot을 만들어야 한다. 1. BotFather로 봇 생성 Telegram에서 @BotFather 검색 후 대화 시작: /newbot ↓ 봇 이름 입력 (예: MyAlertBot) ↓ 봇 username 입력 (예: my_alert_bot) ↓ API Token 발급 발급된 Token 형식: 1234567890:ABCdefGHIjklMNOpqrSTUvwxYZ 2. Chat ID 확인 봇에게 먼저 아무 메시지나 보내야 getUpdates 결과에 chat.id가 표시된다. 그 다음 아래 URL로 접속하면 된다: `https://api.telegram.org/bot{TOKEN}/getUpdates` n8n 설치 확인 n8n 웹 UI에 접속한다: http://NAS_IP:5678 처음 접속 시 계정 생성 후 로그인하면 워크플로 편집 화면이 나온다. 워크플로 구성 실제 운영 중인 워크플로 구조: Schedule Trig...

Docker 재시작 후 PostgreSQL 데이터가 사라지는 이유와 영구 저장 방법

이미지
 Docker로 PostgreSQL을 운영하다가 한 번쯤은 이런 상황을 겪게 된다. 컨테이너를 재생성했더니 데이터베이스가 텅 비어 있었다. 처음에는 PostgreSQL 자체 문제인 줄 알았다. 로그를 확인하고 설정을 점검했지만 이상이 없었다. 원인은 Docker 볼륨 설정이었다. UGREEN DXP4800PLUS NAS에서 쇼츠 자동화 시스템과 트레이딩 봇을 운영하면서 이 문제를 직접 겪었다. 이 글에서는 PostgreSQL 데이터가 삭제되는 원인과 NAS 환경에서 데이터를 영구적으로 보존하는 방법을 정리한다. 왜 데이터가 사라지는가 Docker 컨테이너는 애플리케이션 실행 환경만 보관한다.  데이터를 별도 저장소에 보관하지 않으면 컨테이너 삭제 시 함께 사라진다. 가장 흔한 실수는 볼륨 설정 없이 PostgreSQL을 실행하는 것이다. yaml # 잘못된 구성 - 데이터가 사라짐 services : postgres : image : postgres : 15 - alpine environment : POSTGRES_DB : mydb POSTGRES_USER : myuser POSTGRES_PASSWORD : mypassword 이 상태에서 docker compose down 후 docker compose up 을 다시 실행하면 데이터가 사라진다. docker compose down 은 컨테이너를 삭제하기 때문이다. bash # 이 명령어가 데이터를 삭제한다 docker compose down # 이건 괜찮음 (컨테이너 중지만, 삭제 안 함) docker compose stop Docker Volume 개념 데이터를 영구 보존하려면 볼륨(Volume)을 사용해야 한다. Docker Volume 방식은 두 가지다. Named Volume (도커 관리 볼륨) yaml services : postgres : image : postgres :...

UGREEN DXP4800PLUS NAS Docker Compose 설치 및 사용 가이드

이미지
 Docker를 설치하고 나서 처음에는 컨테이너를 하나씩 docker run 명령어로 실행했다. 그런데 서비스가 늘어나면서 문제가 생겼다. 어떤 포트로 실행했는지, 어떤 볼륨을 마운트했는지, 환경변수는 뭘 넣었는지 기억하기 어려워졌다. 결국 Docker Compose로 전환했다. 지금은 docker-compose.yml 파일 하나로 모든 서비스를 관리하고 있다. NAS가 재부팅되어도 restart: unless-stopped 설정 덕분에 모든 컨테이너가 자동으로 복구된다. 이 글에서는 UGREEN DXP4800PLUS NAS에서 Docker Compose를 설치하고 실제 서비스를 운영하는 방법을 정리한다. Docker Compose란 Docker Compose는 여러 컨테이너를 하나의 파일로 정의하고 관리하는 도구다. 예를 들어 FastAPI 서버와 PostgreSQL 데이터베이스를 함께 운영할 때, Docker Compose 없이는 이렇게 해야 한다. bash # Docker Compose 없이 실행 docker run -d --name postgres \ -e POSTGRES_DB = mydb \ -e POSTGRES_USER = myuser \ -v /volume2/docker/myapp/data:/var/lib/postgresql/data \ postgres:15-alpine docker run -d --name fastapi \ -p 8105 :8105 \ --depends-on postgres \ myapp:latest Docker Compose를 사용하면 이 모든 설정을 파일 하나로 관리할 수 있다. Docker Compose 설치 확인 UGREEN DXP4800PLUS에서 Docker를 설치하면 Docker Compose도 함께 설치된다. bash docker compose version 버전이 출력되면 정상이다. docker-compose (하이픈)가 아닌 dock...