CMS는 편집기가 아니다
Core Layer는 콘텐츠가 저장되고, 편집되고, 발행되는 기반 시스템이다. 이 계층이 제대로 설계되지 않으면, Signal Layer의 구조화 데이터도, Surface Layer의 디자인 시스템도 제대로 작동하지 않는다. 콘텐츠 인프라의 물리적 기반이 Core Layer다.
이 글은 “AI-Ready 웹 아키텍처의 세 계층” 시리즈의 마지막 글이다. Core Layer의 네 가지 설계 영역 — CMS 설계, 콘텐츠 모델링, 클라우드 인프라, 배포 자동화 — 을 구체적으로 다룬다.
1. CMS 설계 — 콘텐츠 데이터베이스로서의 CMS
대부분의 기업 웹사이트에서 CMS는 “글을 쓰고 발행하는 도구”로 쓰인다. 워드프로세서의 웹 버전이다. 제목을 쓰고, 본문을 채우고, 이미지를 넣고, 발행 버튼을 누른다. 이 방식의 문제는 콘텐츠가 “페이지”로만 존재한다는 점이다.
CMS가 콘텐츠 데이터베이스로 작동해야 한다. 보도자료, 제품 정보, 사례 연구, 기술 문서가 각각 고유한 콘텐츠 타입으로 정의되고, 각 타입에 적합한 필드가 설계되며, 타입 간의 관계가 매핑되어야 한다. 그래야 같은 콘텐츠가 뉴스룸 페이지, 메인 페이지의 최신 뉴스 섹션, 관련 제품 페이지, AI 답변의 인용 출처에서 각각 다른 형태로 작동한다.
커스텀 콘텐츠 타입(CPT)
콘텐츠 타입은 “이 사이트에 어떤 종류의 정보가 존재하는가”를 정의한다. 일반 “게시물”과 “페이지”만으로는 기업 웹사이트의 다양한 콘텐츠를 구분할 수 없다. 제품, 사례 연구, 보도자료, 기술 문서, FAQ — 각각이 독립된 콘텐츠 타입이어야 한다.
각 타입에는 고유한 필드 그룹이 붙는다. “제품”에는 모델명, 카테고리, 스펙, 적용 산업이 필요하다. “보도자료”에는 발행일, 콘텐츠 유형, 관련 사업 분야가 필요하다. 같은 “콘텐츠”이지만 내부 구조가 다르다. 이 차이를 CMS 레벨에서 정의하는 것이 콘텐츠 타입 설계다.
편집 워크플로우
편집팀이 콘텐츠를 발행하는 과정에도 구조가 필요하다. 작성 → 검토 → 승인 → 발행의 흐름이 CMS 안에서 관리되어야 한다. 편집팀이 기술팀에 의존하지 않고 독립적으로 콘텐츠를 운영할 수 있는 환경이 목표다.
GS칼텍스 미디어허브의 경우, 편집팀이 보도자료 발행, 뉴스레터 연동, 동영상 아카이브 관리를 독립적으로 수행하는 환경을 구현했다. 편집팀의 기술 의존도를 최소화하면서 발행 프로세스의 일관성을 유지하는 구조다.
2. 콘텐츠 모델링 — 아키텍처 설계로서의 데이터 모델
콘텐츠 모델링은 코딩이 아니라 아키텍처 설계다. 어떤 정보를 어떤 구조로 표현하느냐의 문제다. 데이터 모델이 잘 설계되면 콘텐츠가 “페이지”가 아니라 “데이터”로 작동한다.
택소노미 설계
택소노미(Taxonomy)는 콘텐츠를 가로지르며 연결하는 분류 체계다. 산업별, 솔루션별, 주제별 분류가 콘텐츠 사이에 관계를 만든다. 하나의 사례 연구가 “에너지” 산업에 속하면서 동시에 “뉴스룸” 솔루션에 연결되고, “ESG” 주제 태그를 가질 수 있다.
택소노미가 없으면 콘텐츠는 날짜순 목록에 쌓인다. 3개월 전 콘텐츠는 사실상 발견되지 않는다. 택소노미가 있으면 콘텐츠가 주제별, 유형별, 산업별로 교차 탐색된다. 3년 전의 ESG 보고서도 “ESG” 카테고리에서 쉽게 발견된다.
콘텐츠 간 관계
콘텐츠 타입 사이의 관계를 명시적으로 정의하면, 단일 콘텐츠의 가치가 네트워크 효과로 증폭된다. 제품 A가 사례 연구 B에 연결되고, 사례 연구 B가 산업 C 페이지에 연결되면, 방문자는 하나의 콘텐츠에서 관련 콘텐츠로 자연스럽게 이동한다.
이 관계는 Signal Layer에도 직접 반영된다. 콘텐츠 간 관계가 내부 링크 구조로 표현되면, 검색 엔진과 AI 엔진은 사이트의 주제 구조를 파악할 수 있다. 콘텐츠 모델링이 Signal Layer의 기반이 되는 이유다.
3. 클라우드 인프라 — 콘텐츠가 서빙되는 환경
콘텐츠가 만들어지고 구조화되었으면, 그것이 안정적으로 서빙되어야 한다. 클라우드 인프라는 콘텐츠의 가용성, 보안, 성능을 보장하는 물리적 기반이다.
호스팅 아키텍처
기업 웹사이트의 호스팅은 세 가지 선택지가 있다. 관리형 호스팅(Managed Hosting)은 서버 관리를 호스팅 업체에 위임한다. 운영 부담이 적지만 커스터마이징에 제한이 있다. 클라우드 인프라(AWS, GCP)는 유연성이 높지만 전문 운영 역량이 필요하다. CDN+정적 호스팅(Netlify, Vercel)은 SSG 기반 사이트에 적합하며, 운영 비용이 가장 낮다.
선택 기준은 콘텐츠 업데이트 빈도, 트래픽 규모, 보안 요구 수준, 운영 인력이다. 엔터프라이즈 뉴스룸처럼 매일 콘텐츠가 발행되고 접근 제어가 필요한 경우와, 분기 1~2회 업데이트되는 기업 소개 사이트는 요구 사항이 다르다.
보안과 모니터링
SSL 인증서, 방화벽, 접근 제어, 백업, 가동 시간 모니터링은 기업 웹사이트의 기본 요건이다. 특히 금융, 의료, 공공 분야는 규제 요건이 추가된다.
보안은 Core Layer만의 문제가 아니다. Signal Layer에서 HTTPS는 검색 순위 요소이고, Surface Layer에서 보안 경고는 사용자 이탈을 유발한다. 세 계층이 보안이라는 하나의 요구 사항에 함께 연결되어 있다.
4. 배포 자동화(CI/CD) — 콘텐츠 발행의 파이프라인
콘텐츠가 CMS에서 작성되고, 승인을 거쳐, 웹사이트에 반영되는 과정이 자동화되어야 한다. 수동 배포는 시간이 걸리고, 실수가 발생하고, 발행 빈도를 제한한다.
CI/CD(지속적 통합/지속적 배포) 파이프라인이 이 문제를 해결한다. 콘텐츠가 발행되면 자동으로 빌드가 트리거되고, 캐시가 갱신되고, 사이트맵이 업데이트되고, 검색 엔진에 인덱싱 요청이 전송된다. 편집팀이 “발행” 버튼을 누르는 것만으로 이 파이프라인이 작동한다.
이 자동화는 Signal Layer와도 연결된다. 콘텐츠가 발행될 때마다 구조화 데이터가 자동으로 생성되고, 사이트맵에 새 URL이 추가되고, RSS 피드가 갱신된다. Core Layer의 배포 자동화가 Signal Layer의 검색 최적화를 지원하는 구조다.
Core Layer 설계 체크리스트
CMS 설계:
- 콘텐츠 유형별 커스텀 타입이 정의되어 있는가
- 각 타입에 적합한 필드 그룹이 설계되어 있는가
- 편집팀이 독립적으로 콘텐츠를 발행할 수 있는가
콘텐츠 모델링:
- 택소노미(분류 체계)가 설계되어 있는가
- 콘텐츠 타입 간의 관계가 정의되어 있는가
- URI 구조가 콘텐츠의 위계와 유형을 반영하는가
클라우드 인프라:
- 호스팅 방식이 트래픽 규모와 보안 요구에 적합한가
- SSL, 방화벽, 백업, 모니터링이 구성되어 있는가
배포 자동화:
- 콘텐츠 발행 시 빌드가 자동으로 트리거되는가
- 사이트맵, RSS 피드가 자동으로 갱신되는가
시리즈를 마무리하며
이 글은 “AI-Ready 웹 아키텍처의 세 계층” 시리즈의 마지막 글이다. Signal, Surface, Core — 세 계층의 핵심은 각 계층이 독립적으로 선택·교체 가능하다는 점이다.
Core의 CMS를 교체해도 Surface의 프론트엔드는 그대로 유지된다. Surface의 렌더링 방식을 바꿔도 Signal의 구조화 데이터와 검색 자산은 보존된다. 이 분리가 만드는 실질적 변화는 “전면 리뉴얼 주기의 소멸”이다. 필요한 계층만 점진적으로 진화시키면 된다.
7년간 66개 프로젝트, 12개 산업에서 이 설계를 반복했다. 계층을 분리한 프로젝트는 리뉴얼 주기가 길어지고, 콘텐츠 운영 효율이 높아지며, 검색·AI 발견율이 유지된다. 세 계층 모두를 설계해야 한다.