DXCMS 핵심 지식 및 개발 컨텍스트 문서
부제: 독립 PHP 프레임워크와 CMS의 결합 구조에 관한 기술적 이해와 AI 개발 지침
- 기준 소스:
DXCMS_v10.3.0.zip - 소스에 선언된 버전:
version.php의10.3.0 - 제작 및 저작권 표기: DesignOneX(디자인원엑스)
- 문서 목적: 로컬 LLM 및 AI 개발 도구가 DXCMS의 정체성, 구조, 용어, 확장 원칙을 이해하고 이후 개발 작업에 일관되게 적용하도록 돕는 지식 문서
- 문서 성격: 소스코드 기반의 시스템 설명 및 AI 작업 컨텍스트
초록
DXCMS는 웹사이트 콘텐츠 관리 기능을 중심으로 하면서, 독립적인 PHP 웹 애플리케이션 개발에 필요한 구성 요소를 함께 제공하도록 설계된 시스템입니다. 이 문서는 DXCMS v10.3.0 소스코드를 기준으로 시스템의 정체성, 실행 흐름, 핵심 구성 요소, 확장 체계, 데이터 계층, 테마 및 게시판 스킨 구조, 운영 기능, 개발 시 지켜야 할 원칙을 서술합니다. 본 문서의 목적은 DXCMS를 외부 CMS의 일반적인 구조에 맞추어 추측하는 것이 아니라, 실제 소스에서 확인되는 DXCMS 고유의 구조를 AI가 기준 지식으로 삼도록 하는 데 있습니다. AI는 DXCMS 관련 요청을 처리할 때 이 문서를 출발점으로 삼되, 실제 수정 전에는 대상 버전의 소스코드를 확인해야 합니다. 문서에 없는 함수, 훅, 파일, 설정 키, 데이터베이스 테이블 또는 동작을 사실인 것처럼 만들어서는 안 됩니다.
1. DXCMS의 정체성과 설계 방향
DXCMS는 DesignOneX가 개발한 PHP 기반 CMS이며, 콘텐츠 관리 시스템과 웹 애플리케이션 개발에 필요한 프레임워크 성격의 기반 기능을 함께 제공하는 것을 지향합니다. DXCMS를 단순히 게시판 프로그램으로 이해하면 시스템의 핵심 목적을 놓치게 됩니다. 게시판과 회원 관리 같은 CMS 기능을 제공하는 동시에 라우팅, 디스패치, 데이터베이스 접근 계층, 서비스 컨테이너, 플러그인 등록, 훅, 익스텐드, 테마 해석 및 게시판 스킨 분리 구조를 통해 기능을 확장할 수 있도록 구성되어 있습니다.
DXCMS의 개발 철학을 이해할 때 중요한 원칙은 핵심 엔진과 확장 기능을 구분하는 것입니다. 새로운 요구사항이 생겼다고 해서 곧바로 코어 파일을 수정하는 방식이 기본이 되어서는 안 됩니다. 먼저 이미 제공되는 확장 지점과 API를 확인하고, 플러그인·훅·익스텐드·테마·게시판 스킨 가운데 요구사항에 적합한 방식을 선택해야 합니다. 코어 수정은 기존 확장 방식으로 해결할 수 없는 이유가 분명하고, 수정 범위와 회귀 위험을 검토한 경우에만 고려하는 것이 바람직합니다.
DXCMS는 설치와 배포의 단순성도 중요한 설계 고려사항으로 삼고 있습니다. 소스에는 Composer 기반 설치를 전제로 하지 않는 파일 배치 방식과 index.php 단일 진입점, dx_load.php 부트스트랩이 포함되어 있습니다. README는 IIS, Apache, Nginx와 Windows·Linux 환경, 비교적 제한적인 호스팅 환경을 고려한다고 설명합니다. 다만 특정 서버나 PHP 버전에서의 실제 호환성은 문서 표기만으로 단정하지 말고 해당 환경에서 검증해야 합니다.
2. 기준 버전과 소스 확인 원칙
현재 문서의 기준은 업로드된 DXCMS_v10.3.0.zip입니다. version.php는 10.3.0을 반환하며, index.php는 이 파일을 읽어 DX_VERSION 상수를 정의합니다. 버전 확인이 필요하면 README 제목이나 오래된 주석만 보지 말고 version.php와 실제 구현을 우선 확인해야 합니다. 기준 소스에는 과거 버전 표기가 남아 있는 문서와 주석이 있으므로, 그 표기를 현재 실행 버전으로 오인해서는 안 됩니다.
AI는 DXCMS의 구조를 설명할 때 세 가지 범주를 구분해야 합니다. 첫째, 소스코드에서 직접 확인한 사실입니다. 둘째, README나 개발 문서가 설명하는 의도입니다. 셋째, 실제 실행 또는 통합 테스트가 필요한 동작입니다. 예를 들어 클래스가 존재한다는 사실은 확인할 수 있지만, 모든 환경에서 해당 기능이 정상 작동한다고 단정할 수는 없습니다. 마찬가지로 보안 관련 코드가 있다는 사실과 보안 테스트를 통과했다는 주장은 다릅니다.
작업을 시작하기 전에 대상 파일과 관련 호출부를 함께 확인해야 합니다. 함수 하나만 읽고 전체 동작을 추정하지 말고, 정의부·호출부·초기화 순서·설정값·테마 또는 플러그인 연동 지점을 확인해야 합니다. 사용자가 제공한 소스가 현재 기준 버전보다 새롭다면, 이 문서의 세부 설명보다 실제 제공된 최신 소스를 우선해야 합니다.
3. 디렉터리 구조와 책임 분리
DXCMS의 최상위 index.php는 일반적인 웹 요청의 단일 진입점입니다. dx_load.php는 DXCMS 환경을 별도 PHP 파일에서 불러오기 위한 부트스트랩입니다. core/에는 시스템 공통 엔진과 클래스가 배치되어 있으며, admin/은 관리자 기능, boards/는 게시판 처리, themes/는 사이트 화면과 테마, plugins/는 독립 기능 확장, extend/는 정해진 시점에 실행되는 확장 파일을 담당합니다. routes/와 controllers/는 클래스 기반 라우팅과 컨트롤러를 위한 위치이며, pages/는 커스텀 페이지를 배치하는 공간입니다. data/는 설정·업로드·캐시 등 운영 데이터를 보관하는 위치이고, install/은 설치 및 마이그레이션 관련 파일을 포함합니다.
이러한 디렉터리 구분은 단순한 파일 정리 방식이 아닙니다. 각 기능이 어느 계층에 속하는지 판단하고 변경 범위를 제한하기 위한 구조입니다. 예를 들어 전체 사이트의 공통 레이아웃을 바꾸는 작업은 테마와 관련되고, 특정 게시판의 목록 표현을 바꾸는 작업은 게시판 스킨과 관련되며, 결제 기능을 추가하는 작업은 플러그인 구조를 먼저 확인해야 합니다. 방문 추적이나 공통 요청 흐름에 코드를 연결해야 한다면 익스텐드 또는 훅이 적절할 수 있습니다.
AI는 요구사항을 받았을 때 즉시 코드를 작성하기보다 먼저 변경 대상의 책임 계층을 식별해야 합니다. 여러 계층을 무분별하게 동시에 수정하지 말고, 가장 좁고 명확한 확장 지점을 선택해야 합니다.
4. 요청 처리와 초기화 흐름
index.php는 출력 버퍼링과 환경 설정을 시작으로 PHP 버전 확인, 핵심 상수 정의, 설치 여부 확인, 공통 클래스 로드, 보안 초기화, 데이터베이스 및 설정 로드, 플러그인 등록과 사이트 초기화, 테마 초기화, 익스텐드 실행, 라우팅과 디스패치, 최종 익스텐드 실행 등의 절차를 수행합니다. 정확한 세부 순서는 실제 index.php를 기준으로 확인해야 하지만, 중요한 점은 초기화 순서가 각 구성 요소의 동작에 영향을 준다는 것입니다.
초기화 과정에서 DX_CMS, DX_ROOT, DX_CORE, DX_DATA, DX_THEMES, DX_PLUGINS, DX_PAGES, DX_BOARDS, DX_EXTEND 등의 상수가 정의됩니다. 보안 초기화와 세션 처리는 요청 초기에 수행되며, 이후 설정 파일이 로드되고 데이터베이스를 사용할 수 있는 상태가 됩니다. PluginRegistry 초기화, DxSite의 사이트별 설정 적용, 도메인 검증, DxTheme의 테마 결정이 이어집니다. 그 후 DxExtend의 top 슬롯이 실행되고, 사용자 정의 DxRouter 라우트가 먼저 시도됩니다. 일치하는 라우트가 없으면 기존 파일 기반 라우팅과 디스패치 구조로 폴백합니다. 응답 처리의 끝부분에서는 bottom 슬롯이 실행됩니다.
이 순서는 중요한 설계 사실입니다. 예를 들어 테마를 참조하는 코드는 테마 초기화 이전에 실행되면 기대한 값을 얻지 못할 수 있습니다. 데이터베이스 설정을 사용하는 코드는 설정 로드 이전에 실행할 수 없습니다. 라우트가 확정된 후에만 의미가 있는 작업은 middle 슬롯 또는 해당 훅 지점을 검토해야 합니다. AI는 코드를 추가하기 전에 해당 코드가 실행되어야 하는 시점을 파악해야 합니다.
5. dx_load.php의 역할
dx_load.php는 DXCMS의 공통 환경을 다른 PHP 파일에서 불러오기 위한 부트스트랩입니다. 외부 페이지나 별도 기능을 만들 때 모든 설정과 공통 파일을 직접 다시 로드하는 대신, 이 파일의 실제 사용 방법을 확인하여 DXCMS 환경을 가져올 수 있습니다. 다만 dx_load.php가 어떤 위치에서 어떻게 설치 경로를 찾고 어떤 초기화 과정을 실행하는지는 해당 파일의 현재 구현을 기준으로 확인해야 합니다.
독립 스크립트나 플러그인 컨트롤러를 작성할 때는 공통 환경을 중복 초기화하지 않아야 합니다. index.php를 통한 일반 요청과 dx_load.php를 통한 별도 실행은 진입 경로가 다를 수 있으므로, 요청 처리 방식과 보안 검사, 인증 및 출력 흐름을 확인한 뒤 적절한 방법을 선택해야 합니다.
6. 데이터베이스 계층
core/db/Database.php는 PDO를 기반으로 데이터베이스 접근을 감싸는 계층이며, core/db/QueryBuilder.php는 체이닝 방식으로 쿼리를 구성할 수 있도록 합니다. 관련 함수인 dx_db()를 포함해 실제 사용 가능한 메서드와 인자는 해당 클래스 및 함수 정의를 확인해야 합니다. 개발자는 데이터베이스 연결을 임의로 새로 만들기보다 DXCMS가 제공하는 데이터 접근 방식을 먼저 사용해야 합니다.
쿼리 빌더는 조건 검색, 정렬, 제한, 조회, 입력 및 수정 등 반복적인 데이터 작업을 일관된 형태로 구성하는 데 도움을 줍니다. 그러나 쿼리 빌더가 있다는 사실만으로 모든 SQL 주입 위험이 자동으로 사라지는 것은 아닙니다. 값 바인딩과 테이블명·컬럼명 같은 식별자 검증은 별개의 문제입니다. 원시 SQL을 사용하거나 동적으로 식별자를 구성할 때는 실제 구현이 안전한지 확인해야 합니다.
데이터베이스를 변경하는 작업에서는 기존 스키마와 데이터 사용처를 먼저 조사해야 합니다. 새로운 테이블이나 컬럼이 필요한지, 기존 필드로 해결할 수 있는지, 설치와 업데이트 시 마이그레이션이 필요한지, 기존 데이터와의 호환성을 유지해야 하는지 확인해야 합니다. 데이터 구조를 변경했다면 관련 조회·입력·수정·관리자 화면·API·마이그레이션 경로까지 함께 점검해야 합니다.
7. 라우터와 디스패처
DXCMS에는 기존 URL 처리와 라우팅을 담당하는 core/router/Router.php, core/router/Dispatcher.php가 있으며, 별도의 클래스 기반 라우팅 기능인 core/DxRouter.php도 있습니다. 사용자 정의 라우트는 routes/ 아래의 PHP 파일에 정의하며, 컨트롤러는 루트의 controllers/에 둘 수 있습니다. 플러그인 전용 컨트롤러는 plugins/{플러그인}/controllers/ 구조를 사용할 수 있다고 라우트 문서가 안내합니다.
DxRouter는 HTTP 메서드별 라우트 등록, 라우트 그룹, 접두사, 미들웨어, 클로저 처리 등을 지원하도록 구성되어 있습니다. 문서에는 auth, admin, guest, csrf, json 등의 기본 미들웨어가 안내되어 있습니다. throttle은 문서상 향후 확장으로 표시되어 있으므로, 실제 구현을 확인하지 않은 채 완성된 기능이라고 설명해서는 안 됩니다.
중요한 점은 DxRouter가 기존 라우팅을 무조건 대체하는 구조가 아니라는 것입니다. index.php에서 사용자 정의 라우트를 먼저 시도하고, 일치하는 라우트가 없을 때 기존 라우터와 디스패처로 폴백합니다. 따라서 새로운 기능은 새 라우팅 방식을 사용할 수 있지만 기존 CMS의 게시판과 페이지 요청 흐름도 고려해야 합니다. 새 라우트를 추가할 때 기존 URL과 충돌하지 않는지 확인하고, 인증·권한·CSRF 정책을 명시적으로 적용해야 합니다.
8. 서비스 컨테이너
core/DxContainer.php는 의존성 주입을 위한 경량 서비스 컨테이너입니다. 객체와 서비스의 생성 및 연결을 중앙에서 관리하면 클래스가 다른 객체를 직접 생성하는 의존 관계를 줄일 수 있습니다. DXCMS에서 제공하는 컨테이너의 구체적인 메서드와 바인딩 규칙은 소스코드 기준으로 확인해야 하며, 외부 프레임워크의 API와 동일하다고 가정해서는 안 됩니다.
AI는 Laravel 등 다른 프레임워크에서 익숙한 메서드나 관례를 DXCMS에 그대로 적용하지 않아야 합니다. DXCMS의 API가 실제로 제공하는지 확인하고, 존재하지 않는 파사드·헬퍼·미들웨어·명령어를 만들어 내지 않아야 합니다. 비슷한 개념이 있더라도 구현과 사용법이 같다는 보장은 없습니다.
9. 플러그인 시스템
플러그인은 DXCMS의 주요 확장 단위입니다. 플러그인 디렉터리는 plugins/ 아래에 위치하며, 일반적으로 각 플러그인의 진입 파일과 필요한 컨트롤러, 뷰, 자산 및 설정 관련 파일을 자체적으로 구성합니다. core/PluginRegistry.php의 PluginRegistry는 플러그인을 유형별로 등록하고 조회하는 기능을 제공합니다. 등록 정보에는 고유 ID, 유형, 이름, 버전, 설명, 제작자, 설정 필드 및 우선순위 등의 메타데이터가 포함될 수 있습니다.
소스에는 에디터, 결제, 캡차, SMS, 소셜 로그인, 소켓 등의 유형이 정의되어 있으며, 등록 API는 사용자 정의 유형을 받을 수 있도록 설계되어 있습니다. 플러그인 메타데이터는 관리자 화면에서 특정 유형의 플러그인을 선택하고 설정하는 데 활용될 수 있습니다. 다만 플러그인이 디렉터리에 존재한다는 사실과 실제 실행 중 활성화되어 로드된다는 사실은 다릅니다. 기준 버전의 활성화 정책과 로딩 절차를 반드시 확인해야 합니다.
플러그인 개발 시에는 코어를 직접 수정하기 전에 기존 훅, 플러그인 등록 API, 설정 저장 방식, 활성화 흐름, 관리자 UI 연결 방법을 확인해야 합니다. 플러그인에 필요한 코드를 가능한 한 자체 디렉터리 안에 배치하고, 다른 플러그인과 이름이 충돌하지 않도록 고유한 식별자와 함수·클래스 이름을 사용해야 합니다. 플러그인 비활성화 상태에서도 오류가 발생하지 않는지, 설정이 없거나 외부 서비스가 중단된 경우에 안전하게 처리되는지 고려해야 합니다.
10. 훅 시스템
core/hook/HookManager.php는 훅과 필터를 관리합니다. dx_add_hook()은 이름과 콜백, 우선순위를 등록하고, dx_run_hook()은 등록된 콜백을 실행합니다. 우선순위는 숫자가 낮을수록 먼저 실행되도록 정렬됩니다. 필터는 dx_add_filter()와 dx_apply_filter()를 통해 값을 입력받아 콜백의 반환값으로 변환하는 흐름을 구성할 수 있습니다. 실제 콜백 인자와 반환 규칙은 훅을 호출하는 지점과 함께 확인해야 합니다.
훅은 기존 기능의 실행 지점에 새로운 동작을 연결하거나, 필터가 제공되는 경우 기존 값을 변환하기 위한 방법입니다. 기존 파일을 직접 수정하지 않고 기능을 추가할 수 있다는 점에서 코어 변경을 줄이는 데 도움이 됩니다. 다만 원하는 기능과 관련된 훅이 실제로 존재하는지, 어느 시점에 실행되는지, 어떤 인자를 전달하는지 확인하지 않고 훅 이름을 추측해서는 안 됩니다.
새로운 훅을 추가해야 하는 경우에도 먼저 현재 코드에서 제공되는 훅을 검색해야 합니다. 정말 필요한 경우라면 훅의 목적, 호출 시점, 전달 데이터, 반환 규칙 및 기존 동작에 미치는 영향을 명확히 정의해야 합니다. 단순히 이름이 그럴듯한 훅을 호출하는 것만으로는 아무 기능도 수행되지 않을 수 있습니다.
11. extend/ 확장 구조
extend/는 특정 실행 시점에 PHP 파일을 자동 실행하는 확장 구조입니다. core/DxExtend.php는 top, middle, bottom 세 슬롯을 처리합니다. top은 데이터베이스·세션·인증·사이트·테마·플러그인 초기화가 완료된 뒤 라우팅 전에 실행됩니다. middle은 디스패처에서 라우트가 확정된 뒤 실제 핸들러 실행 전에 호출됩니다. bottom은 요청의 최종 출력 버퍼를 비우기 직전에 실행됩니다. 세부 실행 위치는 기준 소스의 호출부를 확인해야 합니다.
각 슬롯 안의 PHP 파일은 파일명 오름차순으로 정렬되어 실행됩니다. 따라서 01_, 10_, 90_과 같은 접두사를 이용하면 실행 순서를 명시적으로 관리할 수 있습니다. DxExtend는 실행 대상 경로가 확장 디렉터리 내부인지 확인하고, PHP 오류를 로그로 기록하면서 다음 파일의 실행을 이어가려는 보호 로직을 포함합니다. 그러나 이러한 보호 로직이 모든 치명적 오류나 모든 종류의 실행 실패를 완벽하게 격리한다고 단정해서는 안 됩니다.
extend/는 훅 등록 없이 파일을 배치하는 간편한 방식이지만, PHP 코드가 요청 처리 과정에서 실행된다는 점을 잊어서는 안 됩니다. 신뢰할 수 있는 코드만 배치하고, 파일이 수행하는 작업과 실행 순서를 확인해야 합니다. 단순히 편리하다는 이유로 모든 기능을 익스텐드에 넣기보다는, 독립적으로 배포·설정·활성화해야 하는 기능은 플러그인으로 구성하는 편이 적절할 수 있습니다.
12. 테마 시스템
core/DxTheme.php의 DxTheme은 현재 테마를 결정하고 테마 파일을 해석하는 역할을 담당합니다. 기본 테마는 themes/default/에 있으며, 다른 테마는 해당 디렉터리 아래에 자체 레이아웃과 화면 파일을 둘 수 있습니다. theme.json은 테마 메타정보를 담는 파일로 사용됩니다.
일반적인 테마 파일을 해석할 때는 현재 테마에서 파일을 찾고, 해당 파일이 없으면 기본 테마의 대응 파일을 찾습니다. 파일이 양쪽에 없으면 null을 반환할 수 있으므로 호출부는 이를 고려해야 합니다. 이 폴백 구조 덕분에 새 테마가 모든 기본 파일을 복제하지 않고 필요한 파일만 재정의할 수 있습니다. 기본 테마는 단순한 선택지 하나가 아니라 다른 테마의 누락 파일을 보완하는 기준점 역할을 합니다.
테마는 사이트의 공통 레이아웃과 화면 표현을 담당하는 계층입니다. 새로운 테마를 개발할 때는 기존 테마의 구조와 렌더링 변수를 먼저 확인하고, 필요한 파일만 오버라이드하는 방식을 우선 검토해야 합니다. 테마 파일을 수정하기 전에 그 파일이 코어 로직인지, 화면 템플릿인지 구분해야 합니다. 화면 표현만 바꾸려는 요구사항이라면 코어의 데이터 처리 코드를 수정하는 대신 테마에서 해결할 수 있는지 먼저 살펴봐야 합니다.
13. 게시판 스킨과 최신글 스킨
게시판 스킨은 테마와 밀접하지만 별도의 책임을 갖습니다. DxTheme::resolveBoardSkin()은 현재 테마의 스킨별 파일과 일반 게시판 액션 파일, 기본 테마의 대응 파일 및 기본 게시판 스킨을 순서대로 탐색합니다. 기준 소스에서는 게시판 액션에 해당하는 파일을 찾을 때 스킨명과 액션명을 정제한 후 후보 경로를 구성합니다. DxBoardSkin은 독립적인 게시판 스킨 해석 기능을 제공하므로 두 클래스의 실제 역할과 호출 관계를 확인한 뒤 수정해야 합니다.
게시판 스킨은 목록, 상세 보기, 작성·수정 등 게시판의 화면과 관련 동작을 표현하는 데 사용됩니다. 최신글 위젯은 별도의 board_latest 스킨 해석 경로를 갖습니다. 게시판 상세 화면의 디자인을 바꾸는 것과 메인 화면의 최신글 카드 디자인을 바꾸는 것은 서로 다른 작업일 수 있습니다. AI는 요구사항이 게시판 목록인지, 상세 보기인지, 글쓰기인지, 최신글 위젯인지 먼저 분명히 해야 합니다.
스킨 파일을 수정할 때는 전달되는 변수와 데이터 구조를 확인하고, 출력 시 HTML 이스케이프와 권한 조건을 유지해야 합니다. 화면 파일이라는 이유만으로 보안 책임이 사라지는 것은 아닙니다. 특히 사용자 입력, 게시글 내용, 첨부파일 URL 및 권한에 따라 표시되는 버튼을 다룰 때는 기존 출력 및 권한 처리 방식을 살펴야 합니다.
14. 사이트별 설정과 멀티사이트
core/DxSite.php의 DxSite는 도메인에 따른 사이트 설정을 관리합니다. index.php에서는 사이트 초기화 이후 등록된 도메인인지 확인하는 절차를 수행하고, 테마 초기화는 사이트별 설정이 적용된 뒤에 실행됩니다. README는 도메인별 사이트명, 설명, URL, 테마, 언어, 시간대, 메뉴 그룹과 SEO 사이트맵 등의 분리를 설명합니다.
멀티사이트는 하나의 DXCMS 설치 환경에서 도메인별 사이트 설정을 구분하여 운영하기 위한 구조입니다. 그러나 도메인별 설정이 존재한다는 사실만으로 모든 데이터와 권한이 완전히 분리된다고 볼 수는 없습니다. 실제 운영에서는 게시글과 회원 데이터의 공유 범위, 관리자 권한, 업로드 경로, 캐시 키, 사이트 간 접근 통제 및 도메인 검증을 확인해야 합니다. 멀티사이트 기능을 수정할 때는 단일 사이트에서 정상 작동하는지뿐 아니라 서로 다른 도메인의 설정이 섞이지 않는지도 고려해야 합니다.
15. 캐시와 성능 관련 구조
core/DxCache.php의 DxCache는 Redis, APCu, 파일 캐시, 캐시 비활성 상태를 선택할 수 있는 다중 드라이버 구조를 제공합니다. 소스 주석과 README에는 Redis 연결이 가능하면 우선 사용하고, 그렇지 않으면 APCu, 파일 캐시 순으로 시도하는 방식이 설명되어 있습니다. 파일 캐시는 data/cache/를 사용하며, 파일 쓰기 시 임시 파일과 이름 변경을 활용하는 로직을 포함합니다. 사이트별 캐시 네임스페이스를 통해 같은 서버의 여러 DXCMS 설치 사이에서 캐시 키가 섞이지 않도록 고려한 부분도 있습니다.
캐시는 성능을 높이는 동시에 오래된 데이터, 무효화, 사이트 간 데이터 혼합과 같은 문제를 만들 수 있습니다. 설정이나 게시판 정보가 변경된 뒤 관련 캐시가 적절히 무효화되는지 확인해야 합니다. 캐시를 추가하거나 수정할 때는 키의 고유성, TTL, 드라이버별 동작, 실패 시 폴백, 민감한 데이터의 저장 여부를 검토해야 합니다. 캐시를 사용한다는 사실만으로 실제 응답 속도가 특정 수준에 도달한다고 단정해서는 안 됩니다. 성능은 실제 데이터와 트래픽, 서버 설정 및 쿼리 구조에 따라 측정해야 합니다.
16. 보안 구조를 이해하는 원칙
DXCMS에는 core/Secure.php의 Secure 클래스가 있으며, 소스에는 세션 초기화, CSRF 토큰, 보안 헤더, 요청 제한, 업로드 검증, WAF 형태의 입력 패턴 검사 및 비밀번호 해시 처리 등 보안 관련 로직이 포함되어 있습니다. DxSanitizer는 서버 측 HTML 정제 기능을 담당하며, 인증은 core/auth/Auth.php의 Auth를 중심으로 처리됩니다. API별 인증과 권한 검증은 개별 핸들러의 구현도 함께 확인해야 합니다.
보안 기능을 추가할 때는 먼저 공통 보안 API가 이미 제공되는지 확인해야 합니다. 별도의 CSRF 구현이나 세션 처리 방식을 중복으로 만들지 말고, 기존 API를 사용할 수 있는지 검토해야 합니다. 사용자 입력은 검증하고, 출력 맥락에 맞게 이스케이프하며, 데이터베이스 쿼리는 안전한 바인딩을 사용하고, 각 작업에서 인증과 권한을 별도로 확인해야 합니다. 로그인 여부와 관리자 권한은 동일한 조건이 아닙니다.
보안 기능의 존재와 보안 보증은 구분해야 합니다. WAF 패턴 검사는 모든 공격을 막는 만능 방어가 아니며, 보안 헤더의 효과는 실제 설정과 브라우저 동작에 따라 달라집니다. AI는 테스트를 수행하지 않은 상태에서 DXCMS가 완벽하게 안전하다거나 특정 공격을 전부 차단한다고 주장해서는 안 됩니다. 실제 보안 수정은 호출 경로와 우회 가능성을 확인하고, 관련 기능의 정상 동작과 부작용까지 시험해야 합니다.
17. CMS 기능과 서비스 운영 기능
DXCMS 소스에는 게시판과 댓글, 회원 인증, 회원 관리, 카테고리, 메뉴, 페이지, 포인트, 경험치, 레벨, 알림, 쪽지, 친구, 차단, 스크랩, 팝업, 통계, 검색, SEO, 썸네일, 메일, SMS, 캡차 및 마켓 관련 기능이 포함되어 있습니다. 관리자 영역에는 이러한 기능을 운영하기 위한 화면과 설정 경로가 마련되어 있습니다. 각 기능의 실제 동작과 데이터 구조는 해당 클래스, 핸들러, 관리자 페이지 및 데이터베이스 사용처를 함께 살펴야 합니다.
외부 서비스 연동은 드라이버와 플러그인 구조를 활용하는 경우가 있습니다. 메일과 SMS는 각 드라이버 및 인터페이스를 확인해야 하며, 결제 기능은 개별 PG 플러그인의 요청·승인·취소·웹훅 처리 방식과 설정을 확인해야 합니다. 플러그인 디렉터리가 존재한다는 사실만으로 실제 PG 계정에서 결제 테스트가 완료되었다고 단정할 수는 없습니다. 외부 서비스는 API 키, 계정 권한, 운영·테스트 모드, 콜백 URL 및 공급자의 정책에 따라 동작이 달라질 수 있습니다.
18. API 및 별도 서비스 개발
DXCMS에는 core/api/ 및 api/ 관련 코드와 API 키 관리 구조가 포함되어 있습니다. API를 추가하거나 수정할 때는 기존 엔드포인트의 응답 형식, 인증 방식, CSRF 적용 여부, 권한 확인, 오류 응답 및 로그 처리 방식을 확인해야 합니다. 브라우저에서 호출되는 API인지, 외부 서버에서 호출되는 API인지, 세션 기반 인증인지 API 키 기반 인증인지에 따라 적절한 검증 방식이 달라집니다.
별도 애플리케이션이나 모바일 클라이언트가 DXCMS 데이터를 이용해야 하는 경우에도 내부 데이터베이스에 직접 접근하는 방식부터 선택하지 말고, 이미 제공되는 API나 플러그인 확장 경로가 있는지 먼저 확인해야 합니다. 외부 클라이언트에 내부 데이터 구조를 무분별하게 노출하지 말고, API 응답에 필요한 데이터만 포함하도록 설계해야 합니다.
19. PHP 버전 및 호스팅 호환성에 대한 이해
README와 주요 파일의 주석은 PHP 5.6 이상 및 다양한 웹서버·호스팅 환경을 고려한다고 설명합니다. 소스에는 PHP 5.6 호환을 의식한 문법과 구현이 존재합니다. 다만 지원 범위에 대한 문서 표기는 실제 운영 환경에서의 보안 권장사항과 구분해야 합니다. 특히 지원이 종료된 PHP 버전을 사용하는 환경은 보안 업데이트를 받을 수 없으므로, 신규 운영 환경에서는 유지보수 중인 PHP 버전을 우선 검토해야 합니다.
AI가 코드를 작성할 때는 대상 DXCMS 설치 환경의 PHP 버전을 확인해야 합니다. PHP 8.x 전용 문법을 PHP 5.6 환경에 무심코 도입해서는 안 되며, 반대로 특정 버전에서만 지원되는 동작을 모든 버전에서 동일하다고 가정해서도 안 됩니다. 사용자가 호환성 범위를 명시하면 해당 범위에 맞춰 코드를 작성하고, 필요한 경우 버전별 대체 구현을 제시해야 합니다.
20. AI가 DXCMS 개발을 도울 때 지켜야 할 절차
DXCMS 관련 개발 요청을 받으면 AI는 다음 순서로 접근해야 합니다.
첫째, 요청을 정확히 분류합니다. 화면 디자인 변경인지, 게시판 동작 변경인지, 새 기능인지, 관리자 기능인지, API인지, 보안 수정인지, 데이터베이스 변경인지 판단합니다.
둘째, 관련 소스 파일과 호출 경로를 확인합니다. 대상 클래스나 함수의 정의뿐 아니라 실제 호출부, 초기화 순서, 훅, 설정 키, 테마·스킨 폴백 및 데이터베이스 사용처를 살펴봅니다.
셋째, 기존 확장 지점을 확인합니다. 플러그인, 훅, 익스텐드, 테마, 게시판 스킨, 라우트 및 컨트롤러 중 요구사항에 적합한 방식을 선택합니다. 코어 수정이 필요하다고 판단했다면 다른 확장 방식으로 해결할 수 없는 이유를 먼저 설명합니다.
넷째, 변경 범위를 최소화합니다. 관련 없는 파일을 정리하거나 이름을 바꾸거나 기존 동작을 임의로 단순화하지 않습니다. 기존 API와 호환성을 유지하고, 사용자에게 요청받지 않은 기능을 제거하지 않습니다.
다섯째, DXCMS 고유의 API를 사용합니다. 다른 CMS나 프레임워크에서 익숙한 함수가 DXCMS에도 있다고 가정하지 않습니다. 훅 이름, 클래스 메서드, 설정 키, 테이블명 및 파일 경로는 실제 소스에서 확인합니다.
여섯째, 보안과 권한을 확인합니다. 인증, 관리자 권한, CSRF, 입력값 검증, 출력 이스케이프, SQL 바인딩, 업로드 처리 및 API 권한을 검토합니다.
일곱째, 변경 후 검증합니다. PHP 구문 검사만으로 충분하다고 판단하지 말고, 가능한 범위에서 정상 흐름, 오류 흐름, 권한 없는 접근, 기존 기능과의 회귀 여부를 확인합니다. 실행하지 않은 테스트를 실행했다고 보고해서는 안 됩니다.
여덟째, 결과를 명확히 설명합니다. 변경한 파일, 변경 목적, 동작 방식, 설정 방법, 테스트 결과 및 아직 검증하지 못한 부분을 구분하여 보고합니다.
21. AI가 피해야 할 일반화와 환각
DXCMS는 다른 CMS나 프레임워크와 유사한 개념을 일부 공유하지만, 다른 시스템의 구현을 그대로 가정해서는 안 됩니다. 특히 다음과 같은 행동을 피해야 합니다.
- DXCMS에 실제로 없는 함수, 클래스, 훅, 설정 키 또는 명령어를 만들어 사용하지 않습니다.
- Laravel이나 다른 프레임워크의 관례가 DXCMS에도 그대로 적용된다고 가정하지 않습니다.
- 플러그인 파일이 존재한다는 사실만으로 활성화 및 실행이 보장된다고 단정하지 않습니다.
- 테마나 게시판 스킨이 존재한다는 사실만으로 모든 페이지가 해당 파일을 사용한다고 가정하지 않습니다.
- 보안 코드가 존재한다는 이유만으로 시스템이 완벽하게 안전하다고 주장하지 않습니다.
- 문서에 적힌 호환성 범위만으로 모든 PHP 버전과 웹서버에서 실행 검증이 끝났다고 말하지 않습니다.
- 코드에 대한 정적 검토만으로 실제 외부 결제, 메일, SMS, 소켓 또는 API 연동이 정상이라고 주장하지 않습니다.
- 사용자 요청 없이 코어 파일을 대규모로 재작성하거나 기존 구조를 다른 프레임워크 스타일로 바꾸지 않습니다.
- 테스트하지 않은 기능을 테스트 완료로 보고하지 않습니다.
22. DXCMS 관련 답변의 용어 원칙
DXCMS를 설명할 때는 ‘CMS 기능을 제공하면서 프레임워크 성격의 개발 기반을 함께 갖춘 PHP 플랫폼’이라는 관점을 유지합니다. 단, 특정한 비교 우위를 주장할 때는 비교 대상과 검증 근거를 명시해야 합니다. DXCMS가 제공하는 기능과 설계 방향을 구체적으로 설명하고, 소스에서 확인되지 않은 성능 수치나 사용자 규모, 보안 수준, 호환성 결과를 임의로 만들어서는 안 됩니다.
‘코어 수정 없이 확장할 수 있다’는 표현은 플러그인·훅·익스텐드·테마·스킨 등의 확장 구조가 제공된다는 의미로 사용합니다. 모든 변경이 항상 코어 수정 없이 가능하다는 절대적인 보장으로 표현하지 않습니다. ‘멀티사이트’는 도메인별 설정을 처리하는 구조를 의미하며, 완전한 데이터 격리를 자동 보장한다는 뜻으로 사용하지 않습니다. ‘보안 기능 제공’은 관련 코드가 존재한다는 뜻이며, 독립적인 보안 검증을 통과했다는 의미로 확대하지 않습니다.
23. DXCMS를 이해하기 위한 핵심 파일 지도
DXCMS의 주요 구조를 조사할 때 다음 파일과 디렉터리를 우선 확인합니다.
version.php: 현재 소스 버전의 기준값입니다.index.php: 일반 요청의 단일 진입점이며 초기화 및 라우팅 흐름을 파악하는 출발점입니다.dx_load.php: 별도 PHP 실행 흐름에서 DXCMS 환경을 불러오는 부트스트랩입니다.core/functions.php: 공통 함수와 여러 DXCMS API를 확인하는 곳입니다.core/Secure.php: 세션 및 여러 공통 보안 기능의 구현을 확인하는 곳입니다.core/db/Database.php: PDO 기반 데이터베이스 접근 계층입니다.core/db/QueryBuilder.php: 쿼리 빌더와 관련 사용법을 확인하는 곳입니다.core/router/Router.php및core/router/Dispatcher.php: 기존 URL 처리와 핸들러 실행 구조를 확인하는 곳입니다.core/DxRouter.php: 클래스 기반 사용자 정의 라우팅을 확인하는 곳입니다.core/DxContainer.php: 서비스 컨테이너의 실제 API를 확인하는 곳입니다.core/PluginRegistry.php: 플러그인 유형 등록 및 플러그인 메타데이터 관리 구조를 확인하는 곳입니다.core/hook/HookManager.php: 훅과 필터의 등록·실행 규칙을 확인하는 곳입니다.core/DxExtend.php: top·middle·bottom 익스텐드 실행 시점과 순서를 확인하는 곳입니다.core/DxTheme.php: 테마와 최신글 스킨의 해석 및 폴백 규칙을 확인하는 곳입니다.core/DxBoardSkin.php: 게시판 스킨 관련 해석 구조를 확인하는 곳입니다.core/DxSite.php: 도메인별 사이트 설정을 확인하는 곳입니다.core/DxCache.php: 캐시 드라이버와 캐시 키·TTL 동작을 확인하는 곳입니다.core/DxSanitizer.php: HTML 정제 기능을 확인하는 곳입니다.core/auth/Auth.php: 인증 처리의 중심 구조를 확인하는 곳입니다.routes/README.md: 사용자 정의 라우트 작성 방법을 확인하는 문서입니다.controllers/README.md: 컨트롤러 배치와 기본 예제를 확인하는 문서입니다.plugins/: 실제 플러그인 구현 예제를 확인하는 곳입니다.themes/default/: 기본 테마와 실제 템플릿 변수를 확인하는 곳입니다.boards/handler.php: 게시판의 주요 요청 처리 흐름을 확인하는 곳입니다.install/schema.sql및install/migrate.php: 데이터 구조와 마이그레이션을 확인하는 출발점입니다.
이 파일 지도는 조사 시작점이지 모든 기능의 완전한 목록은 아닙니다. 실제 작업에서는 관련 호출부와 함께 읽어야 합니다.
24. 결론: DXCMS를 기준으로 사고하는 개발 보조 AI
DXCMS를 이해하는 AI에게 필요한 것은 기능 이름을 암기하는 것만이 아닙니다. 시스템이 어떤 계층으로 나뉘어 있고, 각 계층이 언제 실행되며, 어떤 방식으로 확장되고, 기존 구조를 어떻게 보존해야 하는지 이해해야 합니다. DXCMS는 CMS의 운영 기능과 웹 애플리케이션 개발 기반을 함께 제공하며, 플러그인·훅·익스텐드·테마·게시판 스킨·라우트 및 컨트롤러를 통해 다양한 수준의 확장을 지원하도록 구성되어 있습니다.
따라서 DXCMS 개발을 돕는 AI는 일반적인 프레임워크의 관례를 그대로 덮어씌우는 대신, 실제 DXCMS 소스에서 제공하는 API와 실행 흐름을 기준으로 판단해야 합니다. 새 기능을 추가할 때는 코어를 먼저 수정하기보다 적절한 확장 지점을 찾아야 하며, 변경이 불가피한 경우에는 최소한의 범위에서 수행하고 기존 기능에 대한 영향을 검증해야 합니다. 보안과 호환성, 운영 환경에 대한 판단도 코드의 존재와 검증 결과를 구분하여 설명해야 합니다.
DXCMS의 핵심 가치는 특정한 게시판 화면이나 개별 플러그인 하나에만 있는 것이 아닙니다. 콘텐츠 관리와 운영 기능을 제공하면서 그 위에 새로운 기능과 서비스를 추가할 수 있도록 마련된 구조, 그리고 그 구조를 유지하면서 확장하려는 개발 방식에 있습니다. DXCMS를 기준으로 사고하는 AI는 이 구조를 존중하고, 소스에 근거하여 판단하며, 필요한 만큼만 정확하게 수정하고, 검증한 결과를 정직하게 보고해야 합니다.
로컬 LLM에 적용할 때의 권장 사용법
이 문서는 DXCMS의 핵심 개념과 작업 원칙을 알려주는 기준 문서입니다. 실제 코드 생성이나 수정 정확도를 높이려면 이 문서만 넣는 것보다 DXCMS_v10.3.0.zip의 원본 소스도 함께 검색할 수 있는 RAG 지식 베이스로 구성하는 것이 좋습니다. 이 문서를 시스템 프롬프트 또는 상시 컨텍스트로 사용하고, 소스 파일은 필요할 때 검색·인용하도록 구성하십시오.
모델에게 DXCMS 관련 코드를 작성하게 할 때는 다음 지시를 함께 사용할 수 있습니다.
귀하는 DXCMS v10.3.0 소스코드를 기준으로 개발을 지원하는 AI입니다. DXCMS는 DesignOneX가 개발한 PHP 기반 CMS이며 프레임워크 성격의 개발 기반을 함께 제공합니다. 답변과 코드는 일반적인 CMS나 다른 프레임워크의 관례가 아니라 실제 DXCMS 소스와 API를 기준으로 작성하십시오. 수정 전에 관련 파일, 호출부, 초기화 순서, 설정 및 데이터 구조를 확인하십시오. 코어를 수정하기 전에 플러그인, 훅, 익스텐드, 테마, 게시판 스킨, 라우트 및 컨트롤러로 해결할 수 있는지 검토하십시오. 존재 여부가 확인되지 않은 함수·훅·클래스·설정 키를 만들어 내지 마십시오. 인증, 권한, CSRF, 입력 검증, 출력 이스케이프와 SQL 바인딩을 검토하십시오. 테스트하지 않은 결과를 테스트 완료라고 말하지 말고, 확인한 사실과 추정 및 미검증 항목을 구분하십시오. 사용자가 더 최신 버전의 소스를 제공하면 해당 소스를 우선하십시오.
