헤드리스, 결합형, 하이브리드 CMS 아키텍처 중 선택하기

전통적인 결합형 CMS는 콘텐츠를 저장하고 이를 표시하는 페이지를 렌더링합니다. 편집자는 페이지가 어떻게 보이는지 알고 있는 시스템에서 작업하고, 개발자는 그 시스템 안에서 템플릿을 만듭니다. 헤드리스 CMS는 콘텐츠를 저장·관리하고 API로 제공하며, “헤드”(웹사이트, 모바일 앱, 키오스크 화면)는 콘텐츠를 가져와 독립적으로 렌더링하는 별도의 애플리케이션입니다.

모든 차이는 이 분리에서 비롯됩니다. 헤드리스의 장점으로 꼽히는 속도, 유연성, 최신 프런트엔드 프레임워크, 멀티채널 제공은 모두 여기서 나오며, 단점 역시 마찬가지입니다. 콘텐츠가 페이지가 아닌 구조화된 데이터가 되므로 유연성이 생기지만, 누군가는 그 구조를 설계해야 합니다. 렌더링은 조직 자체의 애플리케이션이 되므로 성능, 접근성, 가동 시간도 해당 조직의 팀이 책임져야 합니다.

헤드리스가 가장 큰 효과를 내는 경우는 콘텐츠가 여러 곳에 게시되어야 할 때입니다. 예를 들어 제품 정보, 법적 고지 문구, 보도자료를 공유하는 브랜드 사이트를 십여 개 운영하는 그룹사, 같은 콘텐츠를 웹사이트, 모바일 앱, 매장 디스플레이에 게시하는 기업, 세 개 언어로 서비스하면서 번역본을 원문과 일치시켜야 하는 조직이 그렇습니다. 어느 경우든 콘텐츠를 언어 정보를 갖춘 구조화된 항목으로 한 번만 저장하고 API로 제공하면, 반복적인 복사 작업과 그에 따른 불일치를 크게 줄일 수 있습니다.

또한 헤드리스는 이미 React나 유사한 프레임워크로 개발하고 있으며, 웹사이트를 다른 애플리케이션과 동일한 파이프라인, 테스트, 배포 방식으로 관리되는 하나의 제품으로 다루려는 강력한 프런트엔드 엔지니어링 팀을 보유한 조직에 적합합니다. 그러한 팀이 있다면 템플릿 시스템보다 콘텐츠 API가 더 자연스럽게 맞습니다.

개발자는 대체로 헤드리스를 선호합니다. 깔끔한 API, 직접 제어하는 프런트엔드, 레거시 템플릿 언어가 없다는 점 때문입니다. 반면 편집자는 그만큼 반기지 않는 경우가 많으며, 콘텐츠가 실제로 게시되는지는 편집자의 경험에 달려 있습니다. 결합형 CMS에서는 편집자가 실제로 표시될 페이지를 보면서 구성 요소를 끌어다 놓고 게시 버튼을 누릅니다. 순수한 헤드리스 환경에서는 편집자가 양식의 필드를 채우고 프런트엔드가 잘 렌더링해 주리라 믿을 수밖에 없습니다. 미게시 콘텐츠로 실제 페이지를 미리 보는 기능을 별도로 구축해야 하며, CMS가 제공하지 않는다면 예약 게시, 워크플로, 승인 기능도 마찬가지입니다.

헤드리스를 선택하기 전에 편집자와 면담하십시오. 일주일에 몇 개의 페이지를 게시하는지, 랜딩 페이지를 직접 만드는지 개발자에게 요청하는지, 편집 중에 페이지를 보아야 하는지 파악하십시오. 마케팅팀이 엔지니어의 도움 없이 페이지를 만들고 수정해야 한다면, API 위에 제대로 된 시각적 편집 기능을 갖춘 CMS나 하이브리드 모델이 필요합니다. 어느 쪽이든 미리보기와 페이지 구성 도구에 대한 예산을 확보해야 합니다.

이 선택이 가장 큰 영향을 미치는 분야는 이커머스입니다. 헤드리스 아키텍처는 콘텐츠 플랫폼을 별도의 커머스 엔진, 검색 서비스, 결제 서비스 제공업체와 결합하며, 이를 컴포저블 스택이라고 합니다. 고유한 요구 사항과 역량 있는 팀을 갖춘 리테일 기업이라면 분야별 최고 수준의 기능과 어느 구성 요소든 교체할 수 있는 자유를 얻게 됩니다. 그러나 대부분의 조직에는 카탈로그, 콘텐츠, 장바구니, 결제, 프로모션 간의 연동을 직접 책임지고 여러 공급업체의 로드맵을 맞춰야 한다는 의미이기도 합니다.

콘텐츠와 커머스가 데이터 모델과 관리 인터페이스를 공유하는 통합 플랫폼은 이러한 연동 비용을 없애고, 일반적으로 상품 담당자에게 더 나은 일상 업무 경험을 제공합니다. 결정의 관건은 커머스 요구 사항이 스택을 자체적으로 구성할 만큼 특수한가 하는 점입니다. 많은 조직에서는 그렇지 않습니다.

헤드리스 사이트는 빠른 경우가 많지만, 그 속도는 아키텍처 자체가 아니라 프런트엔드를 구축하는 방식에서 나옵니다. 페이지를 미리 또는 엣지에서 렌더링하고, 적극적으로 캐싱하며, 방문할 때마다 브라우저에서 콘텐츠를 가져오는 대신 빌드 시점이나 요청 시점에 가져올 때 빠릅니다. 구성 요소마다 브라우저에서 콘텐츠 API를 호출하는 헤드리스 사이트는 기존의 결합형 CMS보다 느릴 수 있습니다. CDN 뒤에 잘 구성된 결합형 CMS 역시 페이지를 매우 빠르게 제공합니다.

성능을 예산이 정해진 요구 사항(첫 콘텐츠 표시 시간, 최대 콘텐츠 요소, 상호작용 준비 시간)으로 다루고, 후보 아키텍처마다 사무실 네트워크가 아닌 모바일 네트워크 환경을 포함해 그 예산을 어떻게 충족하는지 제시하도록 요구하십시오.

콘텐츠가 하나의 웹사이트에만 게시되고, 편집자가 페이지를 직접 구성해야 하며, 엔지니어링 팀이 작거나 다른 시스템과 공유되고, 아키텍처의 선택 여지보다 출시 시점이 더 중요하다면 결합형 또는 하이브리드를 선택하십시오. 상당수 기업의 마케팅 사이트, 인트라넷, 서비스 포털이 이에 해당합니다. 페이지를 렌더링하면서 모든 콘텐츠를 API로도 제공하는 하이브리드 CMS는 현재의 웹사이트를 지원하면서 향후 앱이나 두 번째 채널로 확장할 여지를 남겨 둡니다.

콘텐츠가 여러 곳에 게시되거나, 번역본과 브랜드 사이트가 다수의 사이트에서 일관성을 유지해야 하거나, 강력한 프런트엔드 팀이 사용자 경험을 직접 책임지려 하거나, 커머스 요구 사항상 컴포저블 스택이 필요하고 조직이 이를 운영할 준비가 되어 있다면 헤드리스를 선택하십시오. 결정은 기술에 대한 평판이 아니라 조직의 상황에 따라 내려야 합니다.