워드프레스 멀티사이트 완벽 가이드 — 적합 판단, 서브디렉토리·서브도메인 선택, Nginx 설정까지

블로그가 하나둘 늘어나다 보면 “같은 서버에 사이트 여러 개를 관리하기가 번거롭다”는 문제에 부딪힙니다. 이때 등장하는 게 워드프레스의 멀티사이트(Multisite) 기능입니다. 워드프레스 한 벌만 설치해 두고, 그 아래로 수십 개의 서브 사이트를 자식처럼 운영할 수 있죠.

이 글에서는 멀티사이트가 언제 유용하고 언제 독이 되는지, 서브디렉토리 vs 서브도메인 선택법, wp-config.php·.htaccess(Nginx 포함) 설정 방법까지 실제 운영 기준으로 정리합니다.

멀티사이트가 “적합한 경우” vs “부적합한 경우”

✅ 적합	❌ 부적합
같은 회사/학교의 여러 부서 블로그	전혀 다른 주인의 사이트들 (권한 분리 어려움)
같은 테마·플러그인 세트를 공유	사이트마다 다른 유료 테마·플러그인 조합
관리자가 소수이고 중앙 통제 필요	사이트별로 서로 다른 서버·CDN이 필요
다국어 사이트 (`/ko`, `/en`, `/ja`)	개별 도메인 SEO 최적화가 최우선
신속한 사이트 복제/배포가 필요	사이트 한 곳이 죽으면 전체가 위험해도 되는 환경

핵심 판단 기준: “이 사이트들이 같은 운영 주체에 속하고, 같은 운영 정책을 공유하는가?” 그렇다면 멀티사이트, 아니면 각자 별도 설치가 낫습니다.

서브디렉토리 vs 서브도메인 — 어떤 구조로?

구조	예시	장점	단점
서브디렉토리	`example.com/blog-a/`	설정 간단, SEO가 메인 도메인과 통합	메인 사이트 URL 구조가 경직됨
서브도메인	`blog-a.example.com`	독립된 느낌, 도메인 단위 분석 용이	와일드카드 DNS + SSL 필요
도메인 매핑	`another.com`	완전히 다른 브랜드처럼 운영	도메인마다 별도 SSL/DNS 관리

초심자에게는 서브디렉토리를 권장합니다. DNS 설정 없이 wp-config.php·웹서버 설정만으로 동작하고, SSL도 메인 도메인의 인증서 하나로 끝납니다. 서브도메인은 “기관별로 독립 브랜드가 필요하다” 같은 명확한 이유가 있을 때만.

설치 단계별 가이드

1단계 — 백업

멀티사이트 전환은 DB 구조를 바꿉니다. 시작 전에 반드시 DB + wp-content 전체 백업. 자동화 백업은 UpdraftPlus로 자동 백업 설정하기 참고.

2단계 — 모든 플러그인 비활성화

멀티사이트 활성화 중에는 플러그인이 간섭할 수 있어 모두 꺼 두세요. 워드프레스 관리자 → 플러그인 → 전체 선택 → 비활성화.

3단계 — wp-config.php에 멀티사이트 플래그 추가

// wp-config.php (DB 정보 아래쪽, /* That's all, stop editing! */ 위)
define('WP_ALLOW_MULTISITE', true);

4단계 — 네트워크 설치

워드프레스 관리자 접속 → 도구 → 네트워크 설정 메뉴가 새로 나타남
서브디렉토리 / 서브도메인 중 선택
네트워크 이름, 관리자 이메일 입력 → 설치
화면에 나타난 wp-config.php 추가 코드와 .htaccess 코드 복사

5단계 — 제시된 설정 코드 반영

// wp-config.php에 추가 (아까의 WP_ALLOW_MULTISITE 아래)
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);  // 서브디렉토리면 false
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

6단계 — 웹서버 리라이트 규칙

Apache(.htaccess)의 경우: 워드프레스가 알려준 코드를 그대로 붙여넣습니다.

Nginx의 경우: .htaccess가 없으므로 사이트 설정에 직접 추가합니다. 서브디렉토리 모드:

# /etc/nginx/sites-available/mysite 내부의 server { ... } 안에
if (!-e $request_filename) {
    rewrite /wp-admin$ $scheme://$host$uri/ permanent;
    rewrite ^(/[^/]+)?(/wp-.*) $2 last;
    rewrite ^(/[^/]+)?(/.*\.php)$ $2 last;
}

location / {
    try_files $uri $uri/ /index.php?$args;
}

# 설정 검증 후 적용
# sudo nginx -t && sudo systemctl reload nginx

7단계 — 재로그인 후 확인

재로그인 시 상단 툴바 좌측에 “내 사이트(My Sites)” 메뉴가 생겼다면 성공. 여기서 네트워크 관리자 → 사이트 → 새로 추가로 첫 서브 사이트를 생성합니다.

멀티사이트만의 관리 개념 3가지

① 슈퍼 관리자(Super Admin) vs 사이트 관리자

멀티사이트에서는 네트워크 전체를 통제하는 슈퍼 관리자가 별도로 존재합니다. 각 하위 사이트의 관리자는 자기 사이트 안에서만 작업 가능하며, 테마·플러그인 설치는 슈퍼 관리자만 할 수 있습니다. 이 구조를 이해하지 못하면 “왜 내 관리자 화면에 플러그인 메뉴가 없지?” 하고 당황하기 쉽습니다.

② 테마·플러그인의 “네트워크 활성화”

네트워크 활성화: 모든 하위 사이트에서 강제로 사용 (공통 SEO 플러그인 등에 적합)
설치만 하고 각 사이트에서 개별 활성화: 사이트별로 선택적으로 사용

③ DB 테이블 구조

하위 사이트마다 wp_2_posts, wp_3_posts 같은 번호가 붙은 테이블이 생깁니다. 숫자 1번은 기존 메인 사이트 그대로. 백업·이전 시 이 구조를 반드시 고려해야 합니다.

멀티사이트 운영 시 주의사항 5가지

1. 모든 사이트의 운명이 하나

워드프레스 코어를 업데이트하면 모든 하위 사이트가 동시에 영향받습니다. 플러그인 충돌이 나면 전부 다 영향을 받을 수 있으니, 메이저 업데이트는 반드시 스테이징 환경에서 먼저 검증하세요.

2. 특정 플러그인은 멀티사이트 비지원

플러그인 페이지에 “Multisite Supported” 표시가 없다면 네트워크 활성화 시 에러를 낼 수 있습니다. 캐시·보안·백업류는 반드시 지원 여부 확인 후 사용.

3. 업로드 경로가 다르다

멀티사이트의 하위 사이트는 wp-content/uploads/sites/2/... 구조로 파일이 저장됩니다. 이전·복제 시 이 경로를 염두에 두세요.

4. 단일 사이트로의 되돌리기가 번거롭다

멀티사이트에서 일반 사이트로 분리하려면 DB 테이블을 수동으로 분해해야 합니다. “일단 해 보고 아니면 되돌리지 뭐”가 생각보다 비싼 작업이니, 도입 전에 확실히 검토하세요.

5. 성능은 DB I/O에 크게 좌우

사이트가 많아질수록 쿼리 수가 늘어납니다. 페이지 캐시(WP Super Cache, Redis Object Cache)를 초반부터 세팅하는 것이 좋습니다. WP Super Cache 설치는 WP Super Cache 설정 가이드 참고.

FAQ

Q. 사이트마다 다른 도메인을 쓸 수 있나요?

네. 도메인 매핑(Domain Mapping) 기능으로 blog-a.com, blog-b.com 같은 별도 도메인도 하위 사이트에 연결할 수 있습니다. 각 도메인에 Let’s Encrypt 인증서를 따로 발급받아야 하는 점만 주의하면 됩니다.

Q. WooCommerce 멀티 스토어도 되나요?

기술적으로는 가능하지만 권장되지 않습니다. WooCommerce는 세션·결제·재고가 복잡해 멀티사이트 환경에서 플러그인 호환 이슈가 잦습니다. 여러 스토어가 필요하면 별도 설치가 안전합니다.

Q. 나중에 하위 사이트만 독립시킬 수 있나요?

가능합니다. 해당 사이트의 wp_N_* 테이블만 export → 새 WP 설치에 import → 테이블 접두사 수정 → 옵션 값에서 siteurl/home 업데이트의 순서입니다. 도구로는 WP Migrate DB, All-in-One WP Migration이 편리합니다.

마무리 — 멀티사이트, 필요할 때만 쓰세요

멀티사이트는 강력하지만 “편해질 것 같다”는 느낌으로 도입하면 오히려 복잡해집니다. “여러 사이트가 같은 운영자, 같은 규칙, 같은 업데이트 주기를 공유한다”는 조건이 만족될 때만 진가를 발휘합니다. 대학교·지자체·프랜차이즈 같은 구조라면 딱 맞지만, 성격이 다른 사이트 2~3개 정도라면 그냥 별도 설치가 장기적으로 더 유연합니다.

💬𝕏 f N