시놀로지 워드프레스 구축 방법과 실패 없는 HDD 고르기

구글 페이지스피드 인사이트 화면에 빨간 경고등과 ‘LCP 8.2초’라는 숫자가 선명히 떴습니다. 웹호스팅 비용을 아끼려 시놀로지 워드프레스 블로그 운영을 마음먹은 첫날 밤이었죠. 라이젠 CPU가 탑재된 4베이 모델 DS923+를 거실에 두고도 처참한 속도를 보며 깊은 한숨이 나오더군요. ‘기껏 기계값만 100만 원 넘게 쓰고 망한 건가?’ 머릿속이 하얘졌는데, 원인은 의외로 엉뚱한 곳에 있었습니다.

집에 굴러다니던 구형 PC용 일반 HDD를 대충 끼워 넣었던 게 화근이었죠. 워드프레스는 실시간으로 DB를 읽고 쓰는 동적 플랫폼인데, 하드의 기록 방식 차이를 전혀 몰랐던 겁니다. 게다가 최근 원자재 값 폭등으로 하드 가격이 치솟아 용량 설계 실패에 따른 이중 지출까지 겪었고요. 저처럼 비용 낭비를 하지 않기 위해, 장비를 주문하기 전 꼭 점검해야 할 체크리스트를 정리해 드립니다.

먼저 결론: 어떤 구성이 답일까

정리하면 워드프레스 파일과 DB는 NVMe SSD 풀에 올리고, HDD는 CMR 방식 2개를 RAID 1로 묶어 백업과 사진 저장용으로 쓰는 구성이 가장 무난합니다. 앞에서 HDD를 원인으로 말씀드렸지만, 정확히는 “DB를 읽고 쓰는 일을 HDD가 맡고 있었던 것”이 문제였다고 보시면 됩니다. 아래 표는 세 가지 구성을 같은 기준으로 비교한 것입니다.

구성	속도	안정성	비용	이런 경우에
HDD 단독 (CMR)	DB 읽기·쓰기가 디스크 속도에 묶임	디스크 고장 시 서비스와 데이터 모두 위험	가장 저렴	방문이 적은 테스트용 사이트
NVMe 풀(사이트) + HDD 단독(백업)	사이트는 빠름	HDD 고장 시 백업 유실, NVMe 풀이 1개면 사이트도 위험	SSD 추가 비용	속도가 우선이고 외부 백업을 따로 두는 경우
NVMe 풀(사이트) + HDD 2개 RAID 1(백업·사진)	사이트는 빠름	HDD 1개 고장까지 서비스 유지	가장 높음	24시간 운영하는 블로그

다만 8.2초라는 숫자 전부가 HDD 때문이라고 단정하지는 않으시길 권합니다. LCP는 서버 응답(TTFB), 리소스 로딩, 렌더링으로 나뉘기 때문에, 구성을 바꾸기 전에 TTFB부터 따로 재 두어야 어디서 줄었는지 알 수 있습니다. 방법은 아래 검증 섹션에 적어 두었습니다.

시놀로지 워드프레스 구축 전 필수 체크리스트 3

독립된 웹서버를 안정적으로 운영하려면 하드웨어 사양을 꼼꼼히 따져봐야 합니다. 아무 부품이나 썼다가는 느린 로딩 속도 때문에 구글 노출은커녕 접속자를 유지하기도 힘들어지니까요. 특히 시놀로지 워드프레스 서비스를 성공적으로 운영하려면 일반 백업용 NAS 세팅과는 전혀 다른 접근 방식이 필요합니다.

① 일반 SMR 하드가 아닌 ‘CMR 방식’의 NAS 전용 하드를 선택하셨나요?

저가형 하드는 데이터를 겹쳐 쓰는 SMR 방식을 사용하죠. 반면, 쓰기 작업이 빈번한 환경에는 수평 자기 기록 방식의 CMR 하드가 필수적인데요. 실제로 씨게이트 아이언울프(IronWolf) 같은 NAS 전용 라인은 CMR 기술과 회전 진동 센서를 탑재해 진동과 병목 현상을 잡아줍니다. 이러한 고성능 하드는 시놀로지 워드프레스 환경에서 방문자의 DB 요청을 지연 없이 매끄럽게 처리하죠. 자세한 사양은 Seagate 공식 제품 사양서를 통해 내 모델에 맞는 규격을 확인할 수 있습니다.

한 가지 덧붙이면, 회전 진동 센서 같은 세부 사양은 라인(IronWolf, IronWolf Pro)과 용량, 회전수에 따라 달라질 수 있습니다. 구매 전에 사양서의 모델 번호별 표에서 내가 살 모델의 CMR 여부와 센서 유무를 직접 확인하세요. SMR이 특히 문제가 되는 때는 DB 기록과 백업처럼 작은 쓰기가 계속 이어지거나, RAID를 다시 구성하며 대량 재기록이 일어날 때입니다. 반대로 사진을 한 번 올려 두고 거의 읽기만 하는 보관용 디스크라면 SMR의 약점이 덜 드러납니다. 그래도 사이트 DB를 올릴 디스크라면 저는 CMR로 고정하는 쪽을 택하겠습니다.

② DSM 7.2의 ‘NVMe SSD 스토리지 풀’을 준비하셨나요?

과거 시놀로지 OS는 M.2 NVMe 슬롯을 캐시 용도로만 제한했었죠. 하지만 최신 DSM 7.2부터는 DS923+ 같은 라이젠 모델에서 NVMe SSD를 단독 스토리지 풀로 구성할 수 있도록 공식 지원합니다. 워드프레스 파일과 MariaDB 10을 이 SSD 볼륨 위에 Container Manager로 올리면 속도가 비약적으로 빨라지고요. 이러한 NVMe 스토리지 풀 구성은 시놀로지 워드프레스의 로딩 속도를 드라마틱하게 개선하는 가장 확실한 방법입니다. 구체적인 속도 튜닝 방법은 워드프레스 속도 개선 방법 글에서 더 깊이 다루고 있으니 참고해 보세요.

모든 모델에서 되는 기능은 아니라는 점은 꼭 확인하셔야 합니다. 2022년 StorageReview 보도에서는 당시 DS923+가 M.2 SSD 스토리지 풀을 지원하는 유일한 DiskStation이라고 전했고(StorageReview), 이후 지원 모델과 조건은 DSM 버전과 모델에 따라 달라질 수 있습니다. 내 모델이 되는지는 Synology 지식 센터의 M.2 스토리지 풀 관련 문서에서 먼저 확인하세요. 또 Synology 정품이 아닌 SSD는 풀 생성이 제한될 수 있어 호환 목록도 함께 보시는 편이 안전합니다.

풀을 만드는 위치는 보통 이렇습니다. 화면 이름은 DSM 버전에 따라 조금 다를 수 있습니다.

1. NAS 전원을 완전히 끈 뒤 M.2 SSD를 슬롯에 장착합니다. M.2 SSD는 켠 상태로 꽂고 뺄 수 없습니다.
2. DSM에서 스토리지 관리자 → HDD/SSD에서 SSD가 정상으로 인식되는지 봅니다.
3. 스토리지 관리자 → 스토리지 풀 → 만들기를 열고, 드라이브 선택 단계에서 NVMe SSD만 고릅니다.
4. RAID 종류를 정하고 풀을 만든 뒤, 그 위에 볼륨을 만듭니다. 이 볼륨이 워드프레스와 DB가 올라갈 자리입니다.

SSD가 1개라면 RAID 없이 단일 풀이 됩니다. 사이트가 멈추지 않아야 한다면 SSD도 2개로 미러링하는 방법을 고려하되, 최소한 사이트를 HDD 쪽에 주기적으로 백업해 두세요.

③ 최근 하드 가격 폭등 시기를 고려해 최소 10TB 이상으로 구성하셨나요?

최근 글로벌 하드디스크 가격이 크게 올랐죠. 저 역시 예산 때문에 원래 계획했던 10TB 대신 아이언울프 6TB를 샀다가 피눈물을 흘렸는데요. 매일 쌓이는 워드프레스 자동 백업 파일(Hyper Backup)에 사진 백업(Synology Photos)까지 돌리다 보니 6TB 용량이 2개월도 안 돼 바닥을 드러냈기 때문입니다. 결국 하드 가격이 최고점일 때 추가 구매를 해야 했고요. 비용을 아끼는 길은 첫 구축 단계에서 최소 10TB 이상의 대용량 하드로 원패스 세팅을 하는 것입니다.

10TB가 모두에게 맞는 숫자는 아니라서, 내 상황에 맞게 계산하는 공식을 함께 적어 둡니다.

필요 용량 = (사이트 용량 × 백업 보존 개수 + 사진 라이브러리 용량) × 여유율(1.2~1.3)

항목 (예시 값)	계산	용량
사이트 용량 5GB, 보존 30개	5GB × 30	150GB
사진 라이브러리	예시 1.5TB	1.5TB
여유율 1.3 적용	(0.15TB + 1.5TB) × 1.3	약 2.1TB
RAID 1 사용 가능 용량	디스크 2개 중 1개 분량만 사용	디스크 1개 용량 ≥ 2.1TB

위 숫자는 계산 방법을 보여 드리기 위한 예시입니다. Hyper Backup은 버전을 증분 방식으로 보관하기 때문에 보존 개수만큼 곱한 값보다 실제 사용량은 적게 나오는 경우가 많습니다. 반대로 사진 라이브러리는 해마다 커지니 증가분까지 넣어 계산하세요. 저처럼 6TB가 빨리 찼다면 어느 항목이 얼마나 차지했는지 먼저 나눠 보면 10TB가 정말 필요한지 판단하기 쉬워집니다. 폴더별 사용량은 Storage Analyzer 패키지나 공유 폴더 정보에서 확인할 수 있습니다. RAID 1로 묶으면 쓸 수 있는 용량이 디스크 1개 분량이라는 점도 잊지 마세요.

시놀로지 워드프레스 안정적인 운영을 위한 드라이브 최적화

물리적 구성을 끝마쳤다면 다음은 데이터 보호와 백업 정책입니다. 아무리 우수한 하드를 선택했더라도 기계적 결함이나 정전 등으로 데이터가 유실될 위험은 언제나 존재하니까요. 특히 24시간 가동되는 개인 서버 환경 특성상 일방적인 백업만으로는 시스템 중단을 막기 어렵습니다.

따라서 저는 HDD 2개를 하나로 묶어 RAID 1(미러링) 방식으로 스토리지 풀을 구성하길 적극 권장합니다. 하나의 드라이브가 고장 나더라도 다른 한 곳에 동일한 데이터가 실시간 기록되므로 서비스 중단 없이 대처가 가능하기 때문이죠. 이처럼 안정적인 RAID 시스템이 밑바탕이 되어야 시놀로지 워드프레스가 안정적인 무중단 서비스를 제공할 수 있게 됩니다.

다만 RAID 1은 디스크 고장을 견디는 장치일 뿐 백업은 아닙니다. 실수로 지운 파일이나 해킹으로 망가진 데이터는 두 디스크에 똑같이 반영되기 때문입니다. 그래서 RAID 1 위에 Hyper Backup으로 만든 버전 백업을 두고, 가능하면 외장 디스크나 클라우드 같은 다른 위치에도 한 벌 더 보관하는 구성을 권합니다.

구축 순서: 폴더 준비부터 SSL까지

제목에서 약속한 구축 방법을 순서대로 적어 봅니다. 아래는 Container Manager 프로젝트(Docker Compose)로 올리는 방식이고, 메뉴 이름은 DSM 버전에 따라 조금 다를 수 있습니다. 독일어 가이드이긴 하지만 S-EDV의 WordPress Docker 가이드도 같은 방식이니 비교해 보셔도 좋습니다.

1. Container Manager 패키지를 설치합니다. 가이드에 따르면 DSM 7.2 이상을 전제로 하고 여유 메모리도 2GB 정도는 필요합니다.
2. File Station에서 NVMe 볼륨 안에 폴더를 미리 만듭니다. 예를 들어 docker/wordpress/html(워드프레스 파일)과 docker/wordpress/db(MariaDB 데이터)입니다. 폴더가 없으면 DB가 초기화되지 않거나 워드프레스가 쓰기 권한을 얻지 못할 수 있어서, 컨테이너를 띄우기 전에 만들어야 합니다.
3. Container Manager → 프로젝트 → 생성에서 이름을 정하고, 경로를 위에서 만든 docker/wordpress 폴더로 지정한 뒤 compose 파일을 직접 작성해 붙여 넣습니다.
4. 컨테이너가 모두 실행되면 http://NAS주소:8080으로 접속해 워드프레스 설치 화면이 뜨는지 확인합니다.

compose 파일은 아래 형태를 기준으로 하면 됩니다. 볼륨 경로의 /volume2는 NVMe 풀 볼륨이 volume2일 때의 예시이니 본인의 볼륨 번호로 바꾸세요. 비밀번호 자리에는 직접 만든 강한 값을 넣습니다. DSM이 이미 80, 443 포트를 쓰고 있어서 워드프레스는 8080처럼 다른 포트로 시작하는 것이 충돌이 없습니다.

services:
  db:
    image: mariadb:10.11
    container_name: wordpress-db
    restart: always
    environment:
      MARIADB_DATABASE: wordpress_db
      MARIADB_USER: wp_user
      MARIADB_PASSWORD: 여기에_강한_비밀번호
      MARIADB_ROOT_PASSWORD: 여기에_다른_강한_비밀번호
      TZ: Asia/Seoul
    volumes:
      - /volume2/docker/wordpress/db:/var/lib/mysql

  wordpress:
    image: wordpress:latest
    container_name: wordpress-app
    restart: always
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: 여기에_강한_비밀번호
      WORDPRESS_DB_NAME: wordpress_db
      TZ: Asia/Seoul
    volumes:
      - /volume2/docker/wordpress/html:/var/www/html

설치 화면까지 열렸다면 외부 접속을 위한 네트워크 설정이 남습니다. 앞에서 거대한 벽처럼 느껴진다고 한 부분인데, 순서대로 나누면 네 단계입니다.

1. DDNS: 제어판 → 외부 액세스 → DDNS에서 호스트 이름을 등록합니다. 개인 도메인을 쓴다면 도메인 DNS의 A 레코드(또는 CNAME)를 이 주소나 공인 IP로 연결합니다.
2. 포트포워딩: 공유기 관리 화면에서 외부 80, 443 포트를 NAS의 내부 IP로 전달합니다. 공유기 모델마다 메뉴 이름이 다릅니다.
3. SSL 인증서: 제어판 → 보안 → 인증서 → 추가에서 Let’s Encrypt 인증서를 발급합니다. 발급 확인 과정에서 80 포트가 외부에서 NAS로 닿아야 하니, 앞 단계의 포트포워딩이 먼저 끝나 있어야 합니다.
4. 리버스 프록시: 제어판 → 로그인 포털 → 고급 → 리버스 프록시에서 https://내도메인:443 요청을 http://localhost:8080으로 넘기도록 규칙을 만들고, 앞 단계의 인증서를 이 도메인에 지정합니다. 이후 워드프레스 주소(사이트 URL)도 https로 맞춥니다.

에러가 나면 어느 단계에서 막혔는지부터 가르면 됩니다. 8080 접속이 안 되면 컨테이너 단계, 도메인 접속이 안 되면 DDNS와 포트포워딩, 경고창이 뜨면 인증서와 리버스 프록시를 보면 됩니다.

속도가 실제로 나아졌는지 검증하기

구성을 바꾼 뒤에는 느낌 말고 숫자로 비교해야 합니다. 기준값은 web.dev가 제시하는 것으로, LCP는 2.5초 이하가 좋음, 4초 초과가 나쁨이며 TTFB는 대략 0.8초 이하를 목표로 합니다(web.dev LCP). 변경 전에 측정해 두지 않았다면 비교할 수 없으니, 구성을 바꾸기 전에 아래 조건으로 먼저 재 두세요.

1. 같은 URL(예: 글 하나)을 정해 놓고 매번 그 주소만 측정합니다.
2. PageSpeed Insights에서 모바일과 데스크톱을 나눠 기록합니다.
3. 캐시 플러그인 상태(켬/끔)를 전후로 똑같이 맞춥니다.
4. 한 번 값이 튈 수 있으니 3회 측정해 중앙값을 적습니다.
5. LCP 요소와 서버 응답 시간(TTFB)을 같이 적어 어디가 줄었는지 확인합니다.

구성 (예시 값)	TTFB	LCP (모바일)	판정
HDD 단독, 변경 전 (예시)	1.6초	6.5초	나쁨
NVMe 풀로 이전 (예시)	0.5초	3.4초	개선 필요
NVMe 풀 + 이미지·캐시 정리 (예시)	0.4초	2.2초	좋음

위 표는 측정 기록을 어떻게 남기면 되는지 보여 드리는 예시 값이며, 실제 측정 결과가 아닙니다. 예를 들어 NVMe로 옮긴 뒤 TTFB는 크게 줄었는데 LCP가 여전히 느리다면, 병목이 디스크가 아니라 이미지나 렌더링 쪽에 남아 있다는 뜻입니다. 그 단계의 점검은 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법과 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유에서 이어서 보시면 됩니다.

시놀로지 워드프레스 구축을 고민하는 분들을 위한 조언

처음에는 네트워크 설정부터 포트포워딩, 외부 접속을 위한 DDNS 연결, SSL 보안 인증서 발급까지 모든 과정이 거대한 벽처럼 느껴질 수 있습니다. 저 역시 그랬고요. 사소한 에러 메시지 하나에 밤을 새우며 모니터를 붙잡고 씨름하기 일쑤였습니다. 하지만 그 터널을 지나 나만의 온전한 서버 공간을 손에 쥐었을 때의 성취감은 이루 말할 수 없을 만큼 달콤하더군요. 매월 나가던 웹호스팅 요금 고지서에서 해방되는 기쁨 또한 무척 큽니다.

처음부터 완벽한 인프라를 만들려고 애쓰지 않아도 괜찮아요. 저렴한 소형 드라이브로 가볍게 테스트 빌드를 올리는 것부터 시작해도 늦지 않으니까요. 점차 방문 트래픽이 늘고 속도 욕심이 생길 때, 오늘 소개해 드린 고성능 CMR 하드 구성과 고속 NVMe SSD 스토리지 풀 레이아웃을 하나씩 적용해 나가면 되죠. 실패를 두려워하지 말고 여러분의 소중한 지식과 일상을 기록할 멋진 플랫폼을 직접 설계해 보시길 응원합니다.

지금 바로 여러분만의 고성능 시놀로지 워드프레스 블로그를 구축해 보세요! 초기 설정 과정에서 네트워크 병목 현상이 발생하거나 추가적인 속도 최적화 팁이 더 필요하시다면, 주저하지 말고 워드프레스 속도 개선 가이드를 참고하여 한 단계씩 따라 해보시는 것을 추천해 드립니다.

같이보면 좋은 글