시놀로지 NAS 워드프레스 구축, Docker Compose가 답이었던 이유

제 모니터에는 하얀 화면과 함께 “PHP 버전이 낮아 설치할 수 없습니다”라는 무심한 경고 창 하나만 덩그러니 떠 있었습니다. 내 집, 내 사무실에 있는 장비를 활용해 멋진 개인 사이트를 만들어보겠다며 시놀로지 NAS 워드프레스 구축을 결심한 지 고작 한 시간 만에 마주한 첫 번째 벽이었죠. 클릭 한 번이면 모든 게 끝날 줄 알았던 순정 패키지 설치는 생각보다 훨씬 무겁고 폐쇄적인 제약 속에 갇혀 있었습니다.

패키지 센터의 배신, 시놀로지 NAS 워드프레스 버전 제약에 묶여버린 첫 실패

처음에는 모든 일이 순조롭게 진행되는 듯했습니다. DSM 패키지 센터에서 워드프레스 아이콘을 찾아 ‘설치’ 버튼을 누르니 데이터베이스가 알아서 깔리며 메인 화면이 뜨더군요. “이렇게 쉬운 걸 왜 다들 어렵게 설치하지?”라며 혼자 뿌듯해하기도 했습니다. 하지만 진짜 문제는 그 뒤에 찾아왔지요.

블로그를 꾸미기 위해 마음에 드는 테마를 입히고 필수 플러그인을 활성화하려 하자마자 오류가 발생했습니다. 시스템이 요구하는 PHP 최소 버전보다 시놀로지 순정 패키지가 제공하는 버전이 한참 낮았던 것입니다. DSM 운영체제 업데이트 주기에 묶여 있어 최신 PHP 반영이 늘 늦어지는 구조였죠. 억지로 플러그인을 맞추려다 사이트 전체가 허얗게 얼어붙는 백화 현상을 겪고 나니 패키지 방식의 한계가 뼈저리게 다가왔습니다. 향후 사이트 이전이나 백업 과정도 무척 복잡하겠다는 생각이 머리를 스쳤습니다.

매달 나가는 달러의 늪, 해외 가상 전용 서버에서 느낀 또 다른 불안감

답답한 제약에서 벗어나고자 눈을 돌린 곳은 외부 클라우드 가상 전용 서버(VPS)였습니다. AWS Lightsail 같은 서비스를 알아본 뒤, 월 10달러 정도의 요금제를 선택해 독립적인 리눅스 환경에 시놀로지 NAS 워드프레스 환경을 다시 세팅했습니다. 초기 속도도 빠르고 버전 제약도 없으니 이제야 제대로 굴러간다는 안도감이 들었지요.

하지만 만족감은 그리 오래가지 못했습니다. 매달 계좌에서 빠져나가는 요금은 환율이 오를 때마다 은근한 압박이 되었거든요. 혹시 트래픽 폭증으로 초과 요금 폭탄을 맞지 않을까 전전긍긍하는 제 모습도 불만족스러웠습니다. 무엇보다 소중한 내 지식 콘텐츠가 내 통제권 밖의 외부 서버에 올라가 있다는 찝찝함이 컸습니다. 365일 든든하게 켜져 있는 집안의 NAS 하드웨어를 놀려두고 굳이 매달 달러를 내가며 남의 서버를 빌려 쓰는 모순을 해결하고 싶었습니다.

시놀로지 컨테이너 매니저와 Docker Compose로 되찾은 시놀로지 NAS 워드프레스 진짜 해답

결국 다시 원점으로 돌아와 제 책상 위의 장비를 노려보았습니다. 그러고는 DSM 7.2 버전의 ‘컨테이너 매니저(Container Manager)’를 파고들기 시작했지요. 과거와 달리 이제는 복잡한 터미널 명령어 없이도 GUI 화면의 ‘프로젝트’ 기능을 통해 Docker Compose 설정을 선언적으로 구동할 수 있게 되었습니다.

제가 선택한 방식은 YAML 설정 파일 한 장으로 애플리케이션과 데이터베이스를 유기적으로 묶어 빌드하는 방법이었습니다. 예전처럼 데이터베이스를 따로 깔고 수동으로 연동할 필요가 전혀 없으니 무척 편리하더군요. 프로젝트 생성 메뉴를 누르고 아래와 같이 세팅하여 구성을 한 번에 끝마쳤습니다.

services:
  db:
    image: mariadb:****
    restart: always
    user: "0:0"
    environment:
      MYSQL_ROOT_PASSWORD: "********"
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: "********"
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:latest
    restart: always
    depends_on:
      - db
      - redis
    ports:
      - "0000:00"
    environment:
      WORDPRESS_DB_HOST: db:0000
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: "******"
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - ./wp_data:/var/www/html
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini

  

위 설정에서 핵심은 볼륨 매핑(Volume Mapping)과 권한 값 매칭입니다. 컨테이너 내부의 데이터 경로를 시놀로지 NAS의 실제 공유 폴더인 /volume1/docker/wordpress 하위 경로로 1:1 연동했습니다. 이렇게 묶어두면 컨테이너를 지우거나 업데이트하더라도 포스팅과 이미지 데이터는 하드디스크에 고스란히 영구 보존됩니다.

또한 플러그인 설치 시 발생하는 “Permission Denied” 오류를 차단하기 위해, 실제 시스템 권한 수치인 PUID=1026과 PGID=100을 환경변수로 정확히 주입했습니다. 이 조치 덕분에 파일 쓰기 권한이 꼬여 관리자 페이지가 먹통이 되는 문제를 말끔히 해결했지요. 외부 접속은 시놀로지 DDNS 연동 가이드를 참고해 역방향 프록시(Reverse Proxy) 환경과 결합하고, 보안 SSL 인증서까지 깔끔하게 씌웠습니다.

안정성을 극대화하는 리소스 최적화 실무 팁

시놀로지 NAS 워드프레스 자가 구축 설치 방법을 마친 뒤 신나게 테마와 필수 플러그인을 무겁게 올리다 보니, 간간이 로딩이 느려지거나 메모리가 부족한 현상이 발생했습니다. 이 문제는 컨테이너 자체를 손댈 필요 없이 코드 한 줄로 바로잡았습니다.

NAS 파일 스테이션을 열고 워드프레스 폴더 루트 경로의 wp-config.php 파일을 텍스트 에디터로 연 뒤, 아래와 같이 가용 메모리 한계를 늘려주는 설정을 추가했지요.

// 변경 전 기본 설정 상태에서는 메모리 에러 발생 가능
define('WP_MEMORY_LIMIT', '64M');

// 변경 후: PHP 가용 메모리를 256MB로 확장하여 작동 안정성 확보
define('WP_MEMORY_LIMIT', '256M');

이 간단한 조정 덕분에 백화 현상이나 무거운 편집기 로딩 지연이 완벽히 사라졌습니다. 더 빠른 속도를 원한다면 워드프레스 속도 개선 방법을 참고해 캐싱 레이어를 얹는 것도 훌륭한 방법입니다.

실제 자원 효율성도 뛰어납니다. 저는 고급 모델인 DS923+ 기기를 기준으로 ‘WordPress + MariaDB + Nginx Proxy Manager’ 스택을 구동해도, 영상 스트리밍 상태에서 CPU 점유율 31% 미만, RAM 소모량은 30% 미만에 불과합니다. 8GB 메모리를 가진 기기로도 자원이 차고 넘치는 셈이지요. 경제적인 이득도 무시할 수 없습니다. 매달 10~20달러씩 나가던 외부 호스팅 비용을 절약함으로써, 3년간 운영 시 누적 약 24만 원~100만 원에 달하는 비용을 완전히 아낄 수 있게 되었습니다. 실제 DS923+ 운영 환경에서 측정한 결과이며, 사용 중인 플러그인과 동시 실행 서비스에 따라 자원 사용량은 달라질 수 있습니다.

진정한 자가 구축이 주는 정서적 만족과 경제적 자유

예전에는 매달 날아오는 달러 청구서를 보며 트래픽을 걱정하고 백업본을 들여다보며 불안해하곤 했습니다. 하지만 이제는 제 책상 밑에서 은은하게 깜빡이며 돌아가는 DS923+를 볼 때마다 든든한 기분이 듭니다. 제가 생산하는 기록과 지식들이 온전히 제 소유의 하드디스크 속에 안전하게 저장되고 있기 때문이지요.

버전 업데이트 지원이 느린 순정 패키지에 억지로 나를 맞출 필요도 없고, 매달 월세를 내며 남의 공간을 빌려 쓸 이유도 없습니다. 가장 유연하고 강력한 DSM 7.2 컨테이너 매니저 환경으로 나만의 고유한 웹 생태계를 직접 일궈보시는 건 어떨까요? 지금 바로 시놀로지 패키지에서 컨테이너 매니저를 설치하고, 첫 프로젝트의 Compose 코드를 붙여넣어 보시길 바랍니다. 생각보다 훨씬 가볍고 안전하게 통제되는 나만의 공간이 눈앞에 펼쳐질 테니까요. 구축 과정에서 막히는 부분이나 에러 메시지가 나온다면 언제든 편하게 댓글로 남겨주세요. 머리를 맞대고 같이 해결책을 찾아보겠습니다. 🙂