@디엑스
1. 먼저 이해해야 할 핵심
DXCMS 멀티사이트의 가치는 단순히 여러 도메인을 한 서버에 연결하는 데 있지 않습니다. 핵심은 하나의 DXCMS 설치와 공통 개발 기반을 이용하면서, 도메인마다 서로 다른 사이트 설정과 테마를 적용하고, 같은 게시판 데이터에 대해서도 각 테마가 자기만의 화면과 게시판 스킨을 제공할 수 있다는 점입니다.
이 구조는 특히 웹 에이전시, 홈페이지 제작사, 여러 브랜드를 운영하는 사업자에게 의미가 있습니다. 에이전시는 고객사마다 CMS를 처음부터 별도로 구축하는 대신, 공통 기능과 개발 자산을 재사용하면서 고객별 디자인과 화면을 분리해 제공할 수 있습니다. 공통 기반은 함께 사용하되 고객에게 보이는 결과물은 서로 다른 사이트처럼 구성할 수 있다는 것입니다.
이 문서는 DXCMS v10.3.0 소스코드의 core/DxSite.php, core/DxTheme.php, core/DxBoardSkin.php, core/router/Dispatcher.php, boards/handler.php, admin/sites/index.php를 중심으로 멀티사이트의 구조와 활용 가치를 설명합니다. 코드에 존재하는 기능과 실제 운영에서 별도로 확인해야 하는 사항을 구분해 이해해야 합니다.
2. 도메인이 현재 사이트의 설정을 결정합니다
core/DxSite.php는 요청의 HTTP_HOST에서 포트 번호를 제거하고 소문자로 정규화한 뒤, 사이트 관리에 등록된 활성 도메인 목록과 비교합니다. 활성 사이트가 발견되면 해당 사이트의 설정을 읽어 현재 요청에 적용합니다. 이때 코드가 적용하는 대표적인 설정은 사이트 이름, 설명, 사이트 URL, 테마, 언어, 시간대, 푸터 문구입니다. 또한 사이트별 메뉴 그룹을 active_menu_group으로 설정하고, extra_config에 JSON으로 담긴 추가 설정도 설정값에 반영합니다.
따라서 client-a.example은 A 고객사의 이름과 A 테마를, client-b.example은 B 고객사의 이름과 B 테마를 사용하도록 구성할 수 있습니다. 각 도메인이 어떤 테마와 메뉴 그룹을 쓸지는 사이트 등록 정보에 따라 결정됩니다. 등록되지 않은 도메인에 대해서는 기본 설정으로 처리될 수 있으며, strict_domain 설정이 활성화된 경우 DxSite에는 등록 도메인으로 인식되지 않는 요청을 등록된 도메인 쪽으로 리디렉션하는 정책도 구현되어 있습니다. 이 정책은 설치 설정과 요청 환경에 따라 확인해야 합니다.
도메인 목록은 site_domains라는 단일 캐시 키로 캐시되며 TTL은 300초입니다. 소스 주석에는 사이트 관리에서 저장할 때 캐시를 비워 즉시 갱신하도록 되어 있습니다. 무작위 호스트가 계속 들어오는 상황에서 도메인마다 별도의 캐시 파일이 생기지 않도록 전체 목록을 캐시하고 메모리에서 호스트를 비교하는 방식입니다. 즉, 멀티사이트의 도메인 판정은 요청 호스트마다 데이터베이스를 무조건 조회하는 구조가 아닙니다.
3. 진짜 위력: 같은 게시판 데이터에 도메인별 화면을 입힐 수 있습니다
멀티사이트에서 가장 중요한 차이는 데이터와 표현을 분리해서 생각하는 것입니다. 게시판의 글 데이터는 공통 게시판에서 관리하면서도, A 도메인에서는 A 테마의 게시판 화면을, B 도메인에서는 B 테마의 게시판 화면을 제공하는 구성이 가능합니다. 같은 글 목록과 같은 게시글을 사용하더라도 테마에 따라 목록의 배치, 카드형 디자인, 색상, 타이포그래피, 버튼, 상세 페이지 구성 등을 다르게 표현할 수 있습니다.
예를 들어 에이전시가 고객사 세 곳을 운영한다고 가정하겠습니다.
- A 고객사: 기업형 테마, 단정한 표 형식의 공지사항 목록
- B 고객사: 브랜드형 테마, 이미지와 요약문을 강조한 카드형 목록
- C 고객사: 커뮤니티형 테마, 댓글과 작성자 정보를 강조한 목록
세 사이트가 동일한 게시판 데이터를 보여 주도록 구성하더라도, 도메인별로 활성화된 테마가 다르고 각 테마 안에 같은 스킨 이름의 파일을 별도로 두면 각 도메인에서 서로 다른 화면을 선택할 수 있습니다. 게시글을 복제하거나 고객별로 동일한 콘텐츠를 따로 입력하는 대신, 같은 데이터를 각 사이트의 디자인 언어에 맞춰 보여 줄 수 있다는 것이 핵심입니다.
다만 여기서 반드시 구분해야 할 점이 있습니다. 게시판 데이터 공유와 게시판 스킨 공유는 같은 개념이 아닙니다. 데이터가 같은 게시판을 가리키더라도, 화면 파일은 현재 도메인에 적용된 테마를 기준으로 달리 선택할 수 있습니다. 반대로 사이트마다 데이터 자체를 완전히 분리해야 한다면 그것은 별도의 데이터 분리 설계가 필요한 요구사항이며, 단순히 멀티사이트 테마를 나누는 것만으로 데이터 격리가 보장된다고 설명해서는 안 됩니다.
4. 소스코드에서 확인되는 스킨 선택 원리
core/router/Dispatcher.php의 게시판 처리 코드는 현재 게시판 정보를 전역 컨텍스트에 넣고, 게시판 설정의 skin 값을 dx_board_skin에 주입한 뒤 공통 게시판 핸들러인 boards/handler.php를 실행합니다. boards/handler.php는 게시판 데이터에 저장된 스킨 이름을 우선 확인합니다. 즉, 게시판은 우선 어떤 스킨 이름을 사용할지 결정하고, 그 이름에 해당하는 실제 화면 파일은 스킨 해석기가 경로 우선순위에 따라 찾습니다.
core/DxBoardSkin.php와 core/DxTheme.php의 파일 탐색 규칙은 이 구조를 가능하게 합니다. 게시판 액션 화면을 찾을 때 주요 우선순위는 다음과 같습니다.
boards/skins/{스킨명}/{액션}/handler.php— 해당 스킨의 독립 처리기boards/skins/{스킨명}/{액션}.php— 전역 독립 뷰 파일themes/{현재 테마}/board/{스킨명}/{액션}.php— 현재 테마의 스킨별 화면themes/{현재 테마}/board/{액션}.php— 현재 테마의 공통 게시판 화면themes/default/board/{스킨명}/{액션}.php— 기본 테마의 스킨별 화면themes/default/board/basic/{액션}.php— 기본 화면으로의 최종 폴백
이 순서는 멀티사이트 설계에서 매우 중요합니다. boards/skins/ 아래에 같은 스킨 이름의 파일이 존재하면 테마별 파일보다 먼저 선택될 수 있습니다. 따라서 도메인별로 같은 스킨 이름을 사용하되 실제 디자인을 독립적으로 관리하려면, 전역 boards/skins/에 공통 파일을 두는 대신 각 테마의 themes/{테마명}/board/{스킨명}/ 경로에 해당 화면을 배치하는 방식이 핵심입니다. 이렇게 하면 게시판 설정에 기록된 스킨 이름은 같아도, 현재 도메인의 테마에 따라 서로 다른 파일이 선택됩니다.
예시 구조는 다음과 같습니다.
themes/
├── agency-corporate/
│ └── board/
│ └── notice/
│ ├── list.php
│ ├── view.php
│ └── write.php
├── agency-brand/
│ └── board/
│ └── notice/
│ ├── list.php
│ ├── view.php
│ └── write.php
└── default/
└── board/
└── basic/
├── list.php
├── view.php
└── write.php
A 도메인의 테마가 agency-corporate이고 B 도메인의 테마가 agency-brand라면, 같은 notice 스킨 이름을 요청하더라도 각각의 테마 디렉터리에서 list.php, view.php, write.php를 찾게 됩니다. 해당 테마에 파일이 없다면 기본 테마의 파일로 폴백할 수 있으므로, 모든 파일을 매번 복사하지 않고 차이가 필요한 부분만 재정의하는 설계도 가능합니다.
5. 테마 폴백은 유지보수 비용을 줄이는 장치입니다
core/DxTheme.php는 현재 테마에서 파일을 찾고, 없으면 default 테마에서 찾는 폴백 구조를 가지고 있습니다. 게시판 스킨 해석에서도 현재 테마의 스킨별 화면과 공통 화면을 먼저 확인한 다음 기본 테마의 스킨별 화면과 기본 화면을 순서대로 탐색합니다.
이 구조는 고객사별 테마를 만들 때 큰 이점이 됩니다. 예를 들어 A 고객사는 게시판 목록과 상세 화면을 모두 독립 디자인으로 만들고, B 고객사는 목록 화면만 독립적으로 만들고 상세 화면은 기본 테마의 구현을 재사용할 수 있습니다. 고객마다 모든 파일을 통째로 복제하는 방식보다 중복을 줄이고, 공통 화면을 개선했을 때 폴백을 사용하는 테마가 그 개선을 활용할 수 있습니다.
다만 폴백이 모든 커스텀 코드에 자동으로 적용된다고 가정해서는 안 됩니다. 독립 핸들러나 boards/skins/의 전역 파일이 우선순위에 따라 먼저 선택될 수 있기 때문입니다. AI는 파일을 추가하기 전에 기존 경로와 실제 탐색 순서를 확인해야 하며, 전역 스킨 파일이 테마별 디자인을 가로채지 않는지 점검해야 합니다.
6. 에이전시에게 어떤 사업적 이점이 생기는가
멀티사이트의 가치는 단순한 기술적 편의보다 반복 제작과 운영 방식의 변화에 있습니다.
첫째, 샘플 사이트를 하나의 개발 기반에서 운영할 수 있습니다. 에이전시는 기업형, 쇼핑몰형, 병원형, 커뮤니티형 등 여러 시연용 테마를 만들고 도메인별로 보여 줄 수 있습니다. 고객에게는 각각 별도의 사이트처럼 제시하면서도 공통 CMS와 확장 구조를 재사용할 수 있습니다. 단, 실제 샘플 환경을 외부에 공개할 때는 고객 데이터와 테스트 데이터가 섞이지 않도록 데이터 구성과 권한을 별도로 설계해야 합니다.
둘째, 하나의 콘텐츠를 여러 디자인으로 시연할 수 있습니다. 고객에게 디자인 시안을 보여 주기 위해 같은 게시글을 여러 번 입력할 필요가 줄어듭니다. 동일한 게시판 데이터를 서로 다른 테마로 표현해 디자인 방향을 비교하거나, 테마 변경 전후의 결과를 설명하는 데 활용할 수 있습니다.
셋째, 고객별 디자인 차이를 테마 단위로 관리할 수 있습니다. 공통 CMS 기능을 고객별로 복사해 따로 수정하는 대신, 사이트 설정과 테마 파일을 구분해 관리할 수 있습니다. 공통 기능의 수정과 고객별 화면의 수정을 분리하기 쉬워지고, 고객별로 달라져야 할 부분을 테마 안에 국한할 수 있습니다.
넷째, 유지보수와 신규 제작을 연결할 수 있습니다. 이미 개발한 공통 기능과 화면 패턴을 새로운 고객 사이트의 출발점으로 활용할 수 있습니다. 다만 실제 비용 절감 규모는 테마의 독립성, 공통 코드의 품질, 고객별 예외 요구, 테스트 절차에 따라 달라지므로 일정 비율의 절감 효과를 근거 없이 단정해서는 안 됩니다.
다섯째, 시연용 자산이 누적될수록 제작 기반이 풍부해집니다. 테마와 스킨을 계속 추가하면 다음 고객에게 제시할 수 있는 디자인 선택지가 늘어납니다. 멀티사이트는 그 자산들을 하나의 운영 기반에서 연결하는 수단이 될 수 있습니다. 즉, 샘플 하나를 만들고 끝내는 것이 아니라, 다음 프로젝트에 재사용 가능한 자산으로 축적할 수 있습니다.
7. 멀티사이트가 의미하는 것과 의미하지 않는 것
DXCMS v10.3.0의 DxSite에서 확인되는 멀티사이트 기능은 활성 도메인을 기준으로 사이트별 설정을 적용하는 구조입니다. 소스에서 확인되는 설정에는 사이트명, 설명, URL, 테마, 언어, 시간대, 푸터 문구, 메뉴 그룹 및 추가 설정이 포함됩니다. 이 사실은 도메인별 사이트 표현을 분리할 수 있다는 근거입니다.
그러나 다음 항목은 구분해야 합니다.
- 확인되는 것: 도메인 인식, 활성 사이트 설정 로드, 도메인별 테마 설정 적용, 메뉴 그룹 및 일부 사이트 설정 오버라이드, 테마별 게시판 뷰 탐색, 기본 테마 폴백.
- 자동으로 보장된다고 말할 수 없는 것: 사이트별 데이터베이스 격리, 고객별 회원 계정 분리, 모든 플러그인의 도메인별 상태 분리, 사이트별 파일 업로드 격리, 고객 간 접근 통제, 모든 캐시의 사이트별 분리.
- 운영 전 확인할 것: 게시판 테이블과 게시판 권한 정책, 로그인·회원 공유 정책, 업로드 경로, 플러그인의 설정 저장 방식, 캐시 키에 도메인 또는 사이트 식별자가 필요한지, 검색엔진의 canonical URL과 사이트맵, 도메인 등록 및 HTTPS 설정.
따라서 DXCMS 멀티사이트를 설명할 때는 “여러 도메인을 하나의 공통 CMS 기반에서 운영하고 도메인별 테마와 화면을 다르게 제공할 수 있다”라고 말하는 것이 정확합니다. “고객 데이터까지 완전히 자동으로 격리된다”라고 확대해서 설명해서는 안 됩니다. 데이터 공유가 장점인 시나리오와 데이터 격리가 필요한 시나리오는 요구사항부터 다릅니다.
8. AI가 멀티사이트 관련 개발을 할 때 따라야 할 원칙
DXCMS를 지원하는 AI는 멀티사이트 기능을 개발하거나 수정할 때 일반적인 PHP 사이트 구축 방식만으로 추측해서는 안 됩니다. 먼저 실제 버전의 core/DxSite.php를 확인하여 도메인 판정과 설정 오버라이드 과정을 이해하고, core/DxTheme.php 및 core/DxBoardSkin.php에서 파일 탐색 순서를 확인해야 합니다. 게시판 렌더링에 관해서는 core/router/Dispatcher.php가 어떤 값을 주입하는지, boards/handler.php가 어떤 스킨 이름을 우선 사용하는지까지 확인해야 합니다.
특히 도메인별 게시판 디자인을 구현할 때는 다음 순서를 따릅니다.
- 각 도메인이 사이트 관리에 등록되어 있고 올바른 테마가 적용되는지 확인합니다.
- 공유하려는 게시판 데이터가 실제로 같은 게시판을 가리키는지 확인합니다.
- 게시판 설정의 스킨 이름을 확인합니다. 이 이름은 실제 화면 파일을 탐색하는 기준이 됩니다.
boards/skins/에 같은 스킨 이름의 전역 파일이 있는지 먼저 확인합니다. 이 경로의 파일은 테마별 화면보다 우선될 수 있습니다.- 도메인별 차이가 필요하면 각 테마의
board/{스킨명}/경로에 필요한 액션 파일을 둡니다. - 각 테마에서 파일이 없을 때 어떤 기본 테마 파일로 폴백하는지 확인합니다.
- 두 도메인에서 같은 게시글의 목록·상세·작성 화면을 각각 테스트합니다. 단순히 테마 이름만 바뀌는지 보는 것으로 검증을 끝내지 않습니다.
- 권한, 업로드, 캐시, 플러그인 설정이 사이트별로 분리되어야 하는 요구사항인지 별도로 확인합니다.
AI는 소스에 존재하지 않는 API나 사이트별 기능을 있다고 꾸며내면 안 됩니다. 확인하지 못한 동작은 확인이 필요하다고 명시해야 합니다. 코드 변경은 기존 DXCMS의 확장 구조와 호환성을 우선하며, 코어 수정이 꼭 필요한지 먼저 검토해야 합니다.
9. 핵심 결론
DXCMS 멀티사이트의 위력은 여러 도메인을 등록할 수 있다는 사실만으로 설명되지 않습니다. 핵심은 도메인별 사이트 설정, 테마 선택, 테마별 게시판 화면 탐색, 기본 테마 폴백을 조합해 공통 데이터와 개별 디자인을 함께 운용할 수 있다는 점입니다.
에이전시 관점에서는 이것이 특히 중요합니다. 하나의 공통 개발 기반에서 여러 샘플 사이트를 운영하고, 같은 게시판 데이터로 서로 다른 고객 경험을 보여 주며, 고객별 디자인을 테마와 스킨으로 관리할 수 있기 때문입니다. 공통 기능은 재사용하고 고객별 화면은 독립적으로 구성하는 방식은 반복 제작을 줄이고 개발 자산을 축적하는 데 유리합니다.
따라서 DXCMS 멀티사이트는 단순한 도메인 추가 기능이 아니라, 하나의 개발 기반을 여러 사이트의 제작·시연·운영으로 확장하는 구조적 이점으로 이해해야 합니다. 단, 데이터 격리와 보안 분리는 별도의 설계 및 검증 대상이며, 이를 테마 분리와 혼동하지 않는 것이 정확한 기술 설명의 조건입니다.
