메모리 2~4 GB로 충분한데…synology nas docker wordpress가 먹통되는 이유

시놀로지 NAS에서 도커와 워드프레스를 조합해 안전하게 블로그를 구동하고 싶으신가요? synology nas docker wordpress 설정을 다듬을 때는 Container Manager의 정교한 볼륨 매핑과 역방향 프록시 설정을 올바르게 매듭지어야 하거든요.

먼저 제목의 질문에 답부터 하겠습니다. 메모리가 충분한데도 먹통이 된다면 용량보다 설정이 어긋난 경우가 많습니다. 대표적으로 프록시가 HTTPS 정보를 넘기지 못해 생기는 무한 리다이렉트, 컨테이너와 폴더의 소유권 불일치, 포트 충돌, DB 연결 실패를 먼저 의심해 볼 만합니다. 이 글은 구축 방법을 처음부터 설명하는 글이 아니라 장애가 났을 때 증상에서 원인을 찾아가는 글입니다. 구축 이유와 선택 근거는 아래 관련 글에 맡기고, 여기서는 해당 설정이 어떻게 어긋나는지에 집중합니다.

일반적으로 패키지 센터를 통한 원클릭 설치는 직관적이고 참 편리한데요. 하지만 업데이트 주기가 상대적으로 느린 편이죠. 게다가 보안 업데이트 한 번으로 소중한 데이터가 사라지거나 사이트가 멈추는 치명적인 리스크도 존재하죠.

반면 도커를 활용한 격리 설계는 아주 든든하거든요. 호스트 OS 환경의 갑작스러운 변화로부터 웹 서비스 데이터를 분리해 안정성을 높여주기 때문입니다. WordPress 공식 문서와 Synology 개발자 가이드, 커뮤니티 자료를 참고해 데이터 유실 없는 안전한 인프라 세팅법을 정리해 보았습니다.

Synology nas docker wordpress 안전한 빌드를 위한 볼륨 매핑 및 세팅

현재 DSM 7.2 이상 환경에서는 Container Manager의 프로젝트 기능이 표준으로 자리 잡았습니다. docker-compose.yml 스크립트를 사용해 데이터베이스와 워드프레스를 가상 네트워크로 안전하게 묶어 배포하는 방식이죠.

과거의 복잡한 수동 연결 방식과는 확연히 다릅니다. 이제는 통합 구성 파일 덕분에 선언적인 인프라 배포를 쉽게 진행할 수 있어요. 프로젝트 화면의 메뉴 이름이나 위치는 Container Manager 버전에 따라 다를 수 있으니, 내 화면에서 프로젝트 항목이 보이는지 먼저 확인해 보세요.

이 과정에서 데이터의 영구 보존을 위한 볼륨 매핑은 필수로 선행되어야 합니다. 도커 내부 데이터는 컨테이너가 업데이트되거나 재생성되면 모두 사라지기 때문이죠.

방법은 아주 간단한데요. 시놀로지 File Station에 실제 공유 폴더를 만들고 컨테이너 내부 경로와 1 대 1로 마운트해 두세요. 컨테이너를 수십 번 새로 생성해도 데이터는 완벽히 보존되거든요.

구체적인 작동 원리가 궁금하신가요? 시놀로지 NAS에 Docker Compose로 워드프레스를 구축해야 하는 이유에 대한 분석 글을 참고하시면 한결 쉽게 이해하실 수 있습니다.

간혹 “Permission Denied” 같은 권한 오류가 발생하기도 하는데요. 이를 막으려면 File Station에서 마운트할 폴더 속성을 열고 컨테이너 환경에 맞는 읽기·쓰기 권한을 명확하게 부여하셔야 합니다.

컨테이너 내부 프로세스가 로컬 폴더 파일을 생성하고 수정할 수 있어야 하죠. 만약 적절한 소유권과 권한 그룹 매칭 작업을 빼놓는다면, 테마나 플러그인을 업데이트할 때 오류가 자주 발생합니다. 핵심적인 단계별 인프라 구성 요소를 요약하면 다음과 같습니다.

구축 단계	핵심 작업 및 점검 내용
1. 로컬 폴더 준비	File Station 내 전용 공유 폴더 생성 후, 컨테이너가 실행되는 UID/GID를 소유자로 맞춤 (모든 사용자 쓰기 허용은 피함)
2. 프로젝트 생성	Container Manager에서 docker-compose.yml 배포 및 가상 네트워크 결합
3. 역방향 프록시	시놀로지 제어판을 통한 HTTPS 외부 도메인 수신 및 내부 포트 포워딩 연동
4. 보안 헤더 보완	wp-config.php에 HTTPS 프록시 감지 강제 인지 코드 추가

그렇다고 모든 상황에서 도커 기반 세팅만 고집할 필요는 없습니다. 리눅스 명령어와 환경 설정이 낯설고 단기간 테스트 목적으로 블로그를 가볍게 돌려볼 계획이라면 패키지 센터 간편 설치가 더 좋은 대안이 됩니다.

하지만 장기적인 관점은 조금 다릅니다. 데이터 유실 걱정 없이 보안 패치에 대처하려면 synology nas docker wordpress 환경을 구성하고 Container Manager를 도입하는 편이 제 기준에서는 결국 안전한 길이라고 봅니다.

위 표의 절차 중에서 가장 집중해서 보셔야 할 지점은 폴더 권한 부여와 보안 헤더 보완 단계입니다. 이 두 가지 핵심 마감 처리가 유기적으로 맞물리지 않으면 곤란합니다. 보안 업데이트를 하거나 외부 SSL로 접속할 때 갑작스러운 장애가 발생하기 쉽기 때문입니다.

권한은 “모든 사용자에게 쓰기를 열어 두면 해결된다”고 넘어가기 쉬운데, 저는 그 방법을 권하지 않습니다. 쓰기를 열어 두면 오류는 사라져도 NAS의 모든 프로세스가 그 폴더를 건드릴 수 있기 때문입니다. 컨테이너를 실행하는 UID/GID를 확인해 그 사용자를 소유자로 맞추는 쪽이 안전합니다. 이 방식과 chmod 777을 피하라는 이유는 Synology Docker 권한 문제를 정리한 글에서도 같은 취지로 설명합니다.

1. 컨테이너를 띄운 뒤 SSH로 NAS에 접속해 docker exec wp-app id를 실행하면 워드프레스 컨테이너의 실행 UID/GID가 나옵니다. 공식 이미지에서는 Apache 프로세스가 웹 전용 사용자로 파일을 다루는 경우가 많아서, 반드시 이 값을 직접 확인하고 쓰셔야 합니다.
2. 호스트 폴더의 소유자를 그 값으로 맞춥니다. 예를 들어 확인된 값이 33:33이라면 sudo chown -R 33:33 /volume1/docker/wordpress/html 형태가 됩니다. (숫자는 예시이며 실제 값은 1번에서 나온 값을 쓰세요.)
3. DB 폴더도 같은 방식으로 docker exec wp-db id 결과에 맞춥니다. 이 과정이 번거롭다면 아래 compose 주석처럼 DB만 도커 볼륨(named volume)으로 두는 방법도 있습니다.

데이터베이스 호스트 주소 세팅도 중요하게 다뤄야 합니다. 외부 IP 대신 컴포즈 내부 가상 네트워크 서비스 이름인 ‘db’로 지정해 주셔야 합니다. 그래야 내부망 속도로 가장 안전하게 연동을 마칠 수 있습니다.

그대로 복사해 쓸 수 있는 docker-compose.yml 예시는 다음과 같습니다. 비밀번호와 경로는 반드시 본인 환경에 맞게 바꾸세요. 워드프레스 외부 포트는 DSM이 쓰는 80·443과 겹치지 않도록 8080으로 잡았습니다.

services:
  db:
    image: mariadb:10.11
    container_name: wp-db
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wpuser
      MARIADB_PASSWORD: change-this-password
      MARIADB_ROOT_PASSWORD: change-this-root-password
    volumes:
      # 권한 문제가 반복되면 이 줄을 db_data:/var/lib/mysql 로 바꾸고
      # 아래 최상위 volumes: 에 db_data: 를 추가하세요.
      - /volume1/docker/wordpress/db:/var/lib/mysql

  wordpress:
    image: wordpress:6-apache
    container_name: wp-app
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: change-this-password
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - /volume1/docker/wordpress/html:/var/www/html

Synology 개발자 가이드의 Docker Project 예시도 MariaDB 이미지와 워드프레스 이미지를 한 compose 파일에 묶고, 워드프레스는 호스트 포트를 하나 열어 80번에 연결하는 구성을 보여 줍니다. 위 예시도 같은 구조입니다.

공식 가이드도 놓치기 쉬운 역방향 프록시 무한 리다이렉트 해결책

시놀로지 역방향 프록시로 HTTPS 보안 도메인을 적용해 보셨나요? 이때 워드프레스가 SSL 암호화 상태를 정상적으로 감지하지 못하는 상황이 종종 발생합니다. 이 경우 무한 리다이렉트가 돌거나 화면이 완전히 깨지는 오류가 생기기 쉽습니다.

이를 방지하려면 수동으로 프록시 감지 헤더를 인식시켜 주어야 합니다. 역방향 프록시에서 SSL 암호화 처리가 끝난 뒤 내부망을 거치기 때문입니다. 일반 HTTP 포트로 데이터가 넘어가다 보니 백엔드에서는 보안 연결 여부를 스스로 알아채지 못하는 것이죠.

이 문제는 워드프레스 공식 문서의 HTTPS 안내에도 나옵니다. SSL을 프록시가 맡고 워드프레스 자체는 SSL 없이 돌아가면, 강제 SSL 옵션이 처음에는 무한 리다이렉트를 일으킬 수 있다는 내용입니다. 해법으로는 워드프레스가 HTTP_X_FORWARDED_PROTO 헤더를 인식하게 하되, 프록시가 그 헤더를 실제로 보내도록 설정되어 있어야 한다고 설명합니다. 워드프레스 설치 폴더 안의 wp-config.php 파일을 열어 프록시 인식 PHP 코드를 직접 삽입해 주면 말끔하게 해결할 수 있습니다.

삽입 위치는 wp-config.php 안에서 /* That's all, stop editing! */ 주석 위쪽이면 됩니다. 파일 맨 위(<?php 바로 아래)에 넣어도 같은 효과이고, 설정이 로드되기 전이라는 점만 지키면 됩니다. 공식 문서의 예시는 헤더가 없을 때 PHP 알림이 날 수 있어서, 헤더 존재 여부를 먼저 확인하는 형태로 바꿔 적었습니다.

define( 'FORCE_SSL_ADMIN', true );
// 프록시가 http,https 처럼 값을 여러 개 넘기는 경우도 있어 https 포함 여부로 확인
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
     && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

한 가지 주의할 점이 있습니다. 이 헤더는 누구나 위조해서 보낼 수 있는 값입니다. 그래서 워드프레스 컨테이너로 가는 길이 프록시 하나뿐일 때만 이 코드를 믿는 것이 맞습니다. 8080 포트를 공유기에서 외부로 직접 열어 두었다면, 그 포트는 닫아 주세요.

네트워크를 세팅할 때 포트 충돌 역시 유의하셔야 합니다. 이미 시놀로지 DSM 관리 포털이나 기본 웹 서비스가 80 및 443 포트를 점유하고 있기 때문입니다. 만약 컨테이너 외부 포트를 이와 똑같이 설정하면 포트가 충돌해 정상 작동하지 않습니다.

이를 방지하기 위해 외부 포트를 8080이나 8181 같은 임의의 번호로 지정해 우회해 보세요. 포트 간의 연결 흐름을 명확하게 파악해 두어야 도메인을 세팅하고도 외부 접속이 막히는 답답한 상황을 예방할 수 있습니다.

프록시 규칙 입력값과 적용 후 확인

역방향 프록시 규칙은 DSM 7 기준으로 제어판 > 로그인 포털 > 고급 > 역방향 프록시에서 만듭니다. 메뉴 이름은 DSM 버전과 언어 설정에 따라 조금 다를 수 있습니다. 위 compose 예시와 맞춘 입력값은 다음과 같습니다. (도메인은 예시입니다.)

항목	입력값 (예시)
소스 프로토콜 / 호스트 이름 / 포트	HTTPS / blog.example.com / 443
대상 프로토콜 / 호스트 이름 / 포트	HTTP / localhost / 8080
사용자 지정 헤더	필요하면 이름 X-Forwarded-Proto, 값 https 를 직접 추가

사용자 지정 헤더는 규칙을 편집할 때 사용자 지정 헤더 탭에서 만듭니다. 이미 헤더가 전달되고 있다면 따로 추가할 필요가 없으니, 아래 확인 절차 결과를 보고 판단하세요. 규칙을 저장한 다음에는 눈으로 보지 말고 다음 순서로 확인해 보세요.

1. NAS에서 docker ps를 실행해 wp-app과 wp-db가 모두 Up 상태인지 봅니다. 하나라도 계속 재시작된다면 프록시가 아니라 컨테이너 문제입니다.
2. curl -I http://localhost:8080으로 컨테이너 자체의 응답을 봅니다. 여기서 200이나 302가 정상적으로 나오면 컨테이너는 살아 있는 것입니다.
3. curl -IL --max-redirs 5 https://blog.example.com으로 외부 주소를 확인합니다. 같은 주소로 301이나 302가 계속 반복되면 무한 리다이렉트이고, wp-config.php 코드나 프록시 헤더 전달을 다시 점검해야 합니다.
4. 오류가 계속되면 docker logs --tail 50 wp-app과 docker logs --tail 50 wp-db로 마지막 로그를 봅니다. Container Manager의 컨테이너 항목에서 해당 컨테이너의 로그 탭으로 같은 내용을 볼 수도 있습니다.

먹통 증상별로 원인 나눠 보기

먹통이라고 해도 화면에 보이는 증상은 제각각입니다. 증상을 먼저 나누면 메모리를 늘리기 전에 확인할 곳이 훨씬 줄어듭니다. 아래 표는 위 설정들이 어긋났을 때 나타나는 대표적인 증상을 정리한 것입니다.

증상	먼저 의심할 원인	확인 방법
502 / 504 오류	프록시 대상 포트가 컨테이너 포트와 다르거나, 컨테이너가 내려가 있음	docker ps, curl -I http://localhost:8080
ERR_TOO_MANY_REDIRECTS	프록시가 HTTPS 정보를 넘기지 않거나 wp-config.php 코드 누락	curl -IL --max-redirs 5 로 반복 여부 확인
Error establishing a database connection	DB 호스트가 db가 아님, 비밀번호 불일치, DB 컨테이너 재시작 중	docker logs wp-db, compose의 환경 변수 비교
업데이트·업로드 실패	폴더 소유권과 컨테이너 UID/GID 불일치	docker exec wp-app id 와 폴더 소유자 비교
접속은 되는데 매우 느림	PHP 메모리 한도, 컨테이너 메모리 제한, HDD I/O 대기, 플러그인·이미지 문제	docker stats --no-stream, 로그의 memory 관련 오류

제목처럼 NAS의 메모리가 충분한데도 멈추는 경우는 대개 “NAS 전체의 메모리”와 “실제로 막힌 곳의 한도”가 다르기 때문입니다. 예를 들어 NAS에는 여유가 있어도 PHP가 정해 둔 메모리 한도에 걸리면 워드프레스는 오류를 냅니다. Container Manager에서 컨테이너별로 메모리 제한을 걸어 두었다면 그 제한이 기준이 됩니다. DB 컨테이너가 재시작되는 사이에 워드프레스가 먼저 떠서 연결에 실패하는 경우도 있고, HDD 모델에서는 디스크 대기 때문에 응답이 늦어지기도 합니다. 그래서 저는 메모리 숫자를 늘리기 전에 로그와 컨테이너별 사용량부터 보는 편이 맞다고 생각합니다.

컨테이너별 사용량은 docker stats --no-stream으로 한 번에 볼 수 있습니다. 출력은 대략 다음과 같은 모양이 됩니다. 아래 값은 읽는 법을 보여 드리기 위한 예시이며 실제 측정값이 아닙니다.

컨테이너 (예시)	MEM USAGE / LIMIT (예시)	읽는 법
wp-app	150MiB / 4GiB	LIMIT가 NAS 전체 메모리와 같다면 제한이 없는 상태입니다.
wp-db	200MiB / 4GiB	USAGE가 LIMIT에 계속 가까워지면 그때 메모리를 의심합니다.

“느림”이 증상이라면 도커 설정이 아니라 사이트 자체를 봐야 할 때가 많습니다. 그때는 플러그인 개수보다 먼저 볼 것과 이미지 최적화 후에도 느릴 때 확인하는 방법이 역할을 이어받습니다.

안정적인 사이트 운영을 위한 사양 점검과 트러블슈팅

컨테이너를 쾌적하게 구동하려면 하드웨어 사양 체크가 필수입니다. 시놀로지 NAS의 CPU가 Intel 또는 AMD 기반이면 도커 이미지를 고르기 편하고, 여유 메모리는 워드프레스와 DB 컨테이너를 함께 돌릴 때 2~4 GB 정도를 가늠선으로 잡아 볼 수 있습니다. 다만 이 숫자는 공식 요구 사양이 아니라 대략적인 기준입니다. 그래서 제목처럼 이 정도 용량이 있어도 멈출 수 있고, 그럴 때는 앞의 진단 표로 원인을 나눠 봅니다.

보급형인 J 시리즈나 사양이 상대적으로 낮은 ARM 칩셋 모델은 트랜잭션 처리 속도가 다소 느려질 수 있습니다. 워드프레스 자체가 수많은 데이터베이스 쿼리를 수시로 호출해 동적 페이지를 구성하는 무거운 CMS이기 때문입니다.

Q. 도커 컴포즈 작성 시 MySQL 대신 MariaDB를 선택하는 특별한 이점이 있나요?
두 DB 모두 워드프레스와 매끄럽게 호환되지만 성격이 조금 다릅니다. MariaDB가 항상 더 가볍다고 단정하기는 어렵고, 버전과 설정에 따라 차이가 달라서 워드프레스 용도에서는 큰 차이가 없는 경우가 많습니다. Synology 개발자 가이드의 예시도 MariaDB 이미지를 쓰되 MySQL 8.0을 대안으로 언급합니다. 내 NAS에서 어느 쪽이 나은지는 같은 조건으로 두 이미지를 올려 놓고 docker stats로 비교해 보는 것이 가장 정확합니다.

Q. 이미 설치해서 사용 중인 도커 기반의 워드프레스를 안전하게 새로운 버전으로 업데이트하려면 어떻게 하나요?
Container Manager 앱에서 가동 중인 프로젝트를 잠시 멈추셔야 하거든요. 그 후 YAML 파일의 이미지 태그를 수정해 새로 빌드해 주시면 완료되죠. 다만 멈추기 전에 백업을 먼저 해 두세요.

1. DB 백업: docker exec wp-db mariadb-dump -u root -p wordpress > /volume1/docker/wordpress/backup.sql (MariaDB 10.5 이상 기준이며, 그 이전 버전은 mysqldump를 씁니다.)
2. 파일 백업: /volume1/docker/wordpress/html 폴더를 통째로 복사해 둡니다.
3. 태그 수정: image: wordpress:latest처럼 쓰지 말고 wordpress:6-apache처럼 범위를 정해 두면 예상치 못한 메이저 업데이트를 피할 수 있습니다.
4. 재빌드 후 docker ps로 두 컨테이너가 Up인지, 사이트와 관리자 화면이 열리는지, docker logs wp-app에 오류가 없는지 확인합니다.

NAS에서 워드프레스를 흔들림 없이 구동하는 원동력은 단순한 설치 기교에 머물지 않습니다. 데이터 영속성을 지키고 외부 네트워크를 직접 지휘하는 시스템 설계 역량이 핵심이라고 봅니다.

오늘 바로 시놀로지 File Station에 접속해 보시는 것은 어떨까요? wordpress 데이터 폴더의 속성 메뉴로 들어가 소유자가 컨테이너의 UID/GID와 맞는지 우선적으로 검토해 보시길 권해 드립니다.

이 글의 설정 예시는 2026년 10월 10일에 확인한 아래 공식 문서와 자료를 기준으로 정리했습니다. DSM과 Container Manager 버전에 따라 메뉴 이름이나 화면이 다를 수 있습니다.

글에 참고한 자료들

• WordPress 공식 문서: HTTPS (역방향 프록시와 X-Forwarded-Proto)
• Synology 개발자 가이드: Docker Project (WordPress·MariaDB compose 예시)
• Synology Docker: Container Manager, Ports, and the Permissions Trap (UID/GID와 권한)
• kyulingcompany.com
• svrforum.com
• synology.com
• mariushosting.com
• everest87.com

관련 글은 역할별로 나누어 두었습니다. 구축 이유와 선택 근거는 첫 번째 글, 구축과 하드웨어 선택은 두 번째 글, 사이트가 느린 증상은 그 아래 두 글에서 이어서 보실 수 있습니다.

• 시놀로지 NAS 워드프레스 구축, Docker Compose가 답이었던 이유
• 시놀로지 워드프레스 구축 방법과 실패 없는 HDD 고르기
• 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것
• 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법