워드프레스 사이트가 여러 개라는 이유만으로 멀티사이트를 선택할 필요는 없어요. 테마·플러그인·사용자 정책을 함께 운영해야 하고 장애와 업데이트도 한 책임 범위로 묶어도 될 때는 멀티사이트가 잘 맞습니다. 반대로 사이트마다 담당자, 기능, 배포 일정, 장애 허용 범위가 다르면 독립 설치가 대체로 더 단순합니다.
판단의 핵심은 사이트 수가 아니라 무엇을 함께 바꾸고, 무엇을 따로 보호해야 하는지예요. 아래 순서대로 확인하면 “관리 화면 하나면 편하겠지”라는 기대만으로 구조를 정했다가 다시 분리하는 일을 줄일 수 있습니다.
주소를 나누는 것과 설치를 나누는 것은 달라요
shop.example.com처럼 하위 도메인을 쓴다고 멀티사이트인 것은 아닙니다. 그 주소에 독립 워드프레스를 설치할 수도 있어요. 반대로 멀티사이트 안의 사이트에 서로 다른 도메인을 연결할 수도 있습니다. 주소의 모양만으로 설치 구조나 장애 범위를 판단하면 안 됩니다.
우선 나눠야 하는 것이 글의 주제뿐인지, 관리자·기능·계약까지인지부터 보세요. 같은 사람이 비슷한 기능으로 주제만 달리 쓴다면 한 사이트의 카테고리로 충분할 수도 있습니다. 사이트를 늘리면 설치 방식과 별개로 글 관리와 점검 대상도 늘어납니다.
워드프레스 멀티사이트는 무엇을 실제로 공유할까요?
워드프레스 멀티사이트는 한 번 설치한 워드프레스 안에 여러 사이트를 만드는 기능입니다. WordPress 멀티사이트 공식 문서에 따르면 네트워크의 사이트들은 같은 워드프레스 코어 파일을 사용하고 테마와 플러그인도 공유할 수 있습니다. 주소는 하위 디렉터리, 하위 도메인 또는 별도 도메인으로 구성할 수 있어요.
여기서 “공유”를 모든 데이터가 한데 섞인다는 뜻으로 이해하면 곤란합니다. 사이트별 콘텐츠는 기본적으로 서로 자동 공유되지 않으며 각 사이트에는 고유한 데이터베이스 테이블이 생깁니다. 사용자 관련 테이블은 네트워크에서 공유되지만, 같은 사람이 모든 사이트에서 같은 권한을 갖는다는 뜻은 아니에요. 사이트별 역할을 따로 배정해야 합니다.
파일도 마찬가지입니다. 워드프레스 코어와 설치된 플러그인·테마 파일은 한 벌을 함께 쓰지만, 업로드 미디어는 사이트별 디렉터리로 나뉩니다. 따라서 멀티사이트는 “여러 사이트를 한 화면에서 보여 주는 폴더 정리 기능”이 아니라, 여러 사이트의 기반 소프트웨어와 운영 권한을 하나의 네트워크로 묶는 구조에 가깝습니다.
멀티사이트가 잘 맞는 경우부터 확인하세요
여러 사이트에서 같은 테마와 필수 플러그인을 쓰고, 같은 운영팀이 업데이트하며, 공통 정책을 한 번에 적용해야 한다면 멀티사이트의 장점이 분명해집니다. 지점별 사이트, 학교나 부서별 사이트, 국가·지역별 사이트처럼 외형과 운영 규칙은 비슷하지만 콘텐츠 공간은 나눠야 하는 경우가 대표적이에요.
다음 질문에 대부분 “예”라고 답할 수 있다면 멀티사이트 후보로 볼 수 있습니다.
- 모든 사이트의 워드프레스 코어 업데이트 시점을 같은 관리자가 결정하나요?
- 사이트들이 공통 테마와 핵심 플러그인 세트를 사용하나요?
- 한 사이트의 점검 때문에 네트워크 전체 유지보수 시간을 잡아도 괜찮나요?
- 사이트별 관리자가 플러그인과 테마를 마음대로 설치하지 않아도 되나요?
- 백업·복구·보안 대응을 네트워크 단위로 책임질 운영자가 있나요?
- 사이트를 다른 서버나 업체로 따로 떼어낼 가능성이 낮은가요?
멀티사이트의 네트워크 관리자는 사이트, 사용자, 테마, 플러그인, 업데이트를 중앙에서 관리합니다. 네트워크 운영 문서에서 설명하듯 일반 사이트 관리자와 네트워크 최고 관리자의 권한이 다르므로, 중앙 운영팀과 각 사이트 편집자의 역할이 분명한 조직일수록 구조가 자연스럽습니다.
독립 설치가 운영 경계를 나누기 쉬운 경우
사이트마다 목적과 기능이 크게 다르면 독립 설치가 편한 경우가 많습니다. 쇼핑몰 하나, 회원제 커뮤니티 하나, 회사 소개 사이트 하나처럼 필요한 플러그인과 트래픽 성격이 다르면 함께 묶어서 얻는 이익보다 공통 장애 범위가 커질 수 있어요.
특히 사이트별로 다른 호스팅을 쓰거나, 고객마다 서버 접근 권한과 계약 주체가 다르거나, 한 사이트만 자주 배포해야 한다면 독립 설치가 책임 경계를 설명하기 쉽습니다. 다만 설치를 나눴다는 이유만으로 장애까지 자동 격리되는 것은 아닙니다. 같은 서버·호스팅 계정·DB 서버·파일 접근 권한을 공유하면 그 부분의 장애나 침해는 함께 영향을 줄 수 있어요. 사이트별 업데이트를 나누는 일과 기반 시설을 분리하는 일은 따로 결정해야 합니다.
| 판단 기준 | 멀티사이트가 자연스러운 쪽 | 독립 설치가 자연스러운 쪽 |
|---|---|---|
| 운영 주체 | 한 팀이 전체 네트워크 관리 | 사이트마다 담당자·고객·계약이 다름 |
| 테마·플러그인 | 공통 구성이 많고 중앙 통제가 필요 | 사이트마다 기능과 변경 주기가 다름 |
| 장애 범위 | 공통 점검 시간을 받아들일 수 있음 | 사이트별 변경·복구를 나눠야 함. 서버 공유 범위도 확인 |
| 이전 가능성 | 오랫동안 같은 서버·운영 체계를 유지 | 사이트별 매각·이관·호스팅 변경 가능성이 큼 |
| 권한 | 최고 관리자가 설치를 통제 | 각 사이트 관리자가 설치·배포를 독립 결정 |
표는 어느 구조가 우수한지를 가리는 점수표가 아닙니다. 공통 파일을 한 번 업데이트할 이점이 큰지, 사이트마다 변경을 따로 검증해야 하는지를 보세요. 독립 설치에서도 여러 사이트를 중앙에서 관리할 수 있습니다. 관리 화면을 모으는 것과 워드프레스 설치를 하나로 합치는 것은 다른 선택이에요.
사이트 수보다 장애 범위를 먼저 따져야 합니다
멀티사이트는 공통 코어·테마·플러그인 파일을 공유하므로 변경 영향도 함께 살펴야 합니다. 그렇다고 플러그인 오류 하나가 반드시 모든 사이트를 멈춘다는 뜻은 아닙니다. 어느 사이트에 활성화됐는지, 어떤 기능에서 오류가 나는지에 따라 다릅니다. 독립 설치는 코드와 업데이트 시점을 나눌 수 있지만, 아래처럼 공유하는 기반을 따로 확인해야 해요.
| 구성 | 나눠지는 범위 | 함께 영향을 받을 수 있는 범위 |
|---|---|---|
| 멀티사이트 한 설치 | 사이트별 글·설정·역할 | 공통 코어·테마·플러그인 파일과 서버 |
| 같은 서버의 독립 설치 | 설치별 코어·설정·업데이트 | 서버 자원·계정 권한·DB 서버 등 공유한 부분 |
| 서버·계정도 나눈 독립 설치 | 분리한 서버와 계정의 운영 범위 | DNS·백업 계정 등 여전히 공유한 부분은 별도 확인 |
WordPress의 여러 설치 안내는 독립 설치끼리도 하나의 DB를 서로 다른 테이블 접두사로 사용할 수 있다고 설명합니다. DB 이름이 같다고 무조건 멀티사이트도 아니고, 테이블 접두사만 다르다고 접근 권한이 격리되는 것도 아닙니다. 장애 격리가 목적이라면 호스팅 업체에 파일 접근 권한, DB 사용자 권한, 서버 자원과 백업 복구 단위를 구체적으로 물어보세요.
복구는 “백업이 있나요?”보다 “어느 사이트를 어느 시점으로 되돌리나요?”가 중요합니다. 예를 들어 A 사이트만 어제 상태로 되돌리고 싶은데 네트워크 전체 DB를 어제 백업으로 덮으면, B 사이트의 오늘 글도 사라질 수 있습니다. 아래 표는 이처럼 복구 단위를 나눠 판단하기 위한 예시입니다.
| 필요한 작업 | 먼저 확인할 것 | 피해야 할 오해 |
|---|---|---|
| 네트워크 전체 복원 | DB·파일·미디어·도메인 및 서버 설정을 맞출 복구본 | DB 파일 하나면 모든 상태가 돌아온다 |
| 멀티사이트 중 A만 복원 | 사이트별 테이블·미디어와 공유 사용자·네트워크 설정에 대한 도구 지원 | 전체 DB를 덮고 A만 복원됐다고 본다 |
| 글을 다른 설치로 이전 | XML 내보내기·가져오기 범위, 미디어 파일과 설정 별도 이전 | 글 내보내기가 완전한 사이트 백업이다 |
도구 → 내보내기의 WXR(XML) 파일은 글·페이지·댓글·분류 등의 콘텐츠를 옮기는 데 쓰입니다. 이미지 실파일, 테마·플러그인 파일과 전체 설정까지 묶은 복구본은 아닙니다. XML에는 첨부파일의 주소가 기록됩니다. 미디어 원본을 가져올 수 있는지, 어떤 설정을 별도로 옮겨야 하는지 확인하세요.
구조를 결정하기 전에 “사이트 A의 플러그인 업데이트가 실패하면 사이트 B도 같은 시간에 점검해도 되는가?”라고 물어보세요. 답이 아니오라면 독립 설치 쪽에 무게가 실립니다. 반대로 모든 사이트가 같은 기능을 쓰고 같은 시간에 검증해야 한다면 멀티사이트의 중앙 관리가 도움이 됩니다.
캐시도 네트워크 구조만으로 자동 해결되지 않습니다. 객체 캐시를 붙일 계획이라면 워드프레스 영구 객체 캐시와 Redis 점검 순서처럼 사이트 식별값, 캐시 드롭인, 장애 복구 범위를 먼저 이해하는 편이 안전합니다.
플러그인과 테마 권한은 생각보다 크게 달라집니다
멀티사이트의 일반 사이트 관리자는 테마·플러그인을 새로 설치할 수 없습니다. 설치와 네트워크 관리는 최고 관리자가 맡습니다. 다만 설치, 사용 허용, 활성화는 서로 다릅니다. 테마를 Network Enable하면 각 사이트에서 선택할 수 있게 되며, 모든 사이트가 그 테마로 일괄 바뀌는 것은 아닙니다.
플러그인을 Network Activate하면 네트워크의 모든 사이트에서 로드됩니다. 사이트 관리자는 이를 개별 비활성화할 수 없습니다. 네트워크 활성화하지 않은 플러그인은, 네트워크 설정에서 사이트별 Plugins 메뉴를 허용한 경우에 각 사이트가 활성화·비활성화할 수 있습니다. 네트워크 활성화했다고 설정값까지 하나로 통합되는 것은 아니며, 데이터 저장 범위는 플러그인의 구현에 달려 있습니다.
그래서 고객별 사이트를 한 네트워크에 넣을 때는 “관리자 계정을 드리면 각자 원하는 플러그인을 설치할 수 있다”라고 약속하면 안 됩니다. 그 권한까지 주려면 사실상 네트워크 전체에 영향을 줄 수 있는 최고 관리자 권한을 검토해야 하고, 이는 격리 목적과 충돌할 수 있습니다.
플러그인이 멀티사이트를 지원하는지도 소개 문구만 보고 판단하지 마세요. 네트워크 활성화가 필요한지, 사이트별 설정을 따로 저장하는지, 라이선스가 사이트 수를 어떻게 계산하는지, 제거할 때 사이트별 데이터가 어떻게 남는지를 공식 문서와 테스트 환경에서 확인해야 합니다. 플러그인마다 지원 범위가 다르니, 사용하려는 제품을 따로 확인해야 합니다.
도메인과 URL 구조도 설치 전에 결정하세요
멀티사이트는 하위 디렉터리 방식과 하위 도메인 방식을 선택할 수 있고, 별도 도메인도 사이트에 연결할 수 있습니다. 다만 DNS, TLS 인증서, 웹 서버의 가상 호스트 또는 프록시 설정은 워드프레스 밖의 영역입니다. 관리 화면에서 도메인을 적었다고 인터넷 연결이 모두 끝나는 것은 아니에요.
네트워크 만들기 공식 절차는 시작 전에 데이터베이스와 파일을 백업하고, 고유주소가 작동하는지 확인하며, 활성 플러그인을 비활성화하도록 안내합니다. 기존 사이트를 네트워크로 전환하는 작업은 새 빈 설치보다 영향 범위가 크므로 운영 사이트에서 바로 시도하지 말고 복제한 준비 환경에서 먼저 검증하는 편이 좋습니다.
또한 멀티사이트는 웹 서버의 URL 재작성 기능을 요구합니다. 하위 도메인 방식을 쓸 때는 사이트별 DNS 또는 필요에 따라 와일드카드 DNS와 서버 설정을 준비해야 하고, 관리형 호스팅에서는 상품에 따라 멀티사이트나 도메인 연결이 제한될 수 있어요. 코드를 수정하기 전에 호스팅 업체의 지원 범위를 먼저 확인하세요.
와일드카드 DNS가 모든 하위 도메인 구성의 필수 조건은 아닙니다. 공식 생성 안내는 하위 사이트가 신청에 따라 자동 생성되는 구성에 필요한 조건이라고 구분합니다. 운영자가 정해진 주소만 추가하는 경우에도 각 주소의 DNS·서버 라우팅·인증서는 갖춰야 합니다. DNS 와일드카드와 TLS 와일드카드 인증서 역시 별개의 설정입니다.
기존 단일 사이트를 바로 전환하지 마세요
멀티사이트 기능을 켜는 작업은 단순한 체크박스 설정이 아닙니다. wp-config.php와 웹 서버 규칙을 수정하고 네트워크 주소 방식을 정해야 합니다. 기존 운영 사이트라면 백업, 점검 시간, 복구 절차가 먼저 준비돼야 해요.
설치 전에는 아래 네 가지를 한 장에 적어 보세요.
- 운영 주체: 누가 플러그인을 설치하고, 업데이트하며, 사이트를 다른 업체로 옮길 수 있어야 하나요?
- 공통 기능: 테마·플러그인·라이선스·변경 주기를 함께 유지해도 되나요?
- 복구 단위: 전체 복구와 사이트 하나의 복구를 호스팅·백업 도구가 각각 어디까지 지원하나요?
- 시험 결과: 운영 환경의 복제본에서 필요한 기능과 복원을 확인했나요? 실제 걸린 시간과 필요한 권한을 기록합니다.
준비 환경에서 성공적으로 설치됐다는 것만으로 끝내지 마세요. 사이트 추가, 도메인 연결, 미디어 업로드, 로그인 권한, 플러그인 업데이트, 전체 백업, 사이트 하나의 이전까지 실제 운영에서 생길 행동을 확인해야 합니다. 이후 검색 노출을 살필 때는 Search Console에서 발견·크롤링·색인을 구분하는 순서를 적용하면 사이트 구조 문제와 단순 색인 대기를 섞지 않을 수 있습니다.
콘텐츠 공유와 나중 분리는 따로 확인하세요
여러 사이트의 글을 자동으로 함께 쓸 수 있다
멀티사이트의 사이트는 기본적으로 콘텐츠를 자동 공유하지 않습니다. 공통 페이지를 여러 사이트에 동기화하려면 별도 설계나 플러그인이 필요하며, 그 순간 수정 충돌과 원본 결정 문제가 생깁니다. 공통 콘텐츠의 원본과 수정 권한을 먼저 정하세요. 사이트를 늘리기 전에 카테고리로 충분한지는 글 앞의 기준으로 돌아가 판단하면 됩니다.
나중에 마음에 들지 않으면 쉽게 분리하면 된다
WordPress 네트워크 운영 문서도 멀티사이트 이전은 단일 설치 이전보다 복잡하다고 안내합니다. 사이트별 테이블, 사용자 관계, 미디어 경로, 도메인과 직렬화된 설정을 함께 다뤄야 하기 때문입니다. 분리 가능성이 높은 고객 사이트라면 시작부터 독립 설치가 비용을 줄일 수 있어요.
마지막 판단은 한 문장으로 정리할 수 있어야 합니다
같은 운영팀이 공통 파일과 정책을 함께 관리하려면 멀티사이트, 사이트마다 코드·업데이트·이관을 나눠야 한다면 독립 설치가 출발점입니다. 장애 격리가 목적이면 설치 방식에서 멈추지 말고 서버·계정·DB 권한까지 확인하세요. 주제만 나누려는 개인 블로그라면 한 사이트로 충분한지도 먼저 보세요.
나눠야 할 기능이나 권한이 아직 뚜렷하지 않다면, 설치 구조를 바꾸기보다 현재 사이트에서 해결할 수 있는지부터 확인하세요. 별도 사이트가 필요해지면 운영 서버가 아닌 복제 환경에서 호환성·권한·복구 범위를 검증한 뒤 결정하는 편이 낫습니다. 공식 문서 재확인일은 2026년 10월 14일입니다. 이 글은 문서에 근거한 구조 비교이며 실제 운영 서버의 전환·복구 시험기는 아닙니다. 호스팅 상품과 플러그인의 지원 범위는 적용 당일 다시 확인하세요.