팀의 기사

헤드리스 CMS의 장점: 유연성과 확장성 살펴보기

헤드리스 CMS가 콘텐츠와 표현 방식을 어떻게 분리하는지, 어떤 이점을 주는지, 팀에 어떤 책임이 남는지 알아보세요.

목차

하나의 콘텐츠 세트, 서로 다른 표현 방식. 각각의 웹사이트나 앱은 여전히 구축하고 연결해야 합니다.

강연 하나를 게시한다고 상상해 보세요. 제목, 사진, 설명, 시작 시간이 웹사이트와 모바일 앱에 모두 나타나야 합니다. 시간이 바뀌면 한 번만 수정하고 싶을 것입니다. 웹사이트는 웹사이트답게 보이고, 앱은 앱처럼 느껴지기를 원할 것입니다.

헤드리스 콘텐츠 관리 시스템은 이 두 업무를 분리합니다. 정보를 정리해 두는 일과 독자가 정보를 보는 방식을 결정하는 일을 나누는 것입니다. 이 분리는 유용할 수 있습니다. 다만 어떤 콘텐츠를 게시해야 하는지, 연결을 누가 구축하고 유지할지에 따라 이점은 달라집니다.

‘헤드리스’는 실제로 무엇을 뜻할까요?

CMS는 편집자가 콘텐츠를 작성하고 정리하고 게시하는 곳입니다. 일반적인 구성에서는 콘텐츠를 웹페이지로 바꾸는 템플릿도 제공합니다. 헤드리스 CMS는 표현 방식을 별도의 웹사이트, 앱 또는 다른 인터페이스에 맡깁니다.

두 영역은 API를 통해 통신합니다. API는 한 소프트웨어가 다른 소프트웨어에 정보를 요청하는 합의된 방식입니다. 웹사이트는 강연의 제목, 시간, 사진을 요청한 뒤 자체 레이아웃에 넣을 수 있습니다. 앱은 같은 정보를 요청해 다른 방식으로 배치할 수 있습니다.

Strapi가 한 예입니다. 편집 인터페이스, 콘텐츠 모델, 애플리케이션이 사용할 API를 제공합니다. API는 개발자가 콘텐츠에 접근하게 해 주지만, 독자 경험까지 대신 설계해 주지는 않습니다.

유연성이 유용해지는 지점

하나의 콘텐츠가 여러 곳에서 사용될 수 있습니다. 강연 시간은 각각 따로 관리하는 여러 페이지에 복사하는 대신 하나의 필드에 둘 수 있습니다. 그래도 각 애플리케이션에는 작동하는 연결과 변경 사항을 가져오는 방법이 필요합니다. 오래된 캐시 페이지는 새로 고침할 때까지 최신 상태가 아닐 수 있습니다.

새로운 디자인이 모든 글을 다시 쓰는 일을 뜻할 필요는 없습니다. 제목, 문단, 이미지, 캡션을 특정 페이지 레이아웃과 독립적으로 저장한다면 새로운 프런트엔드에서 재사용할 수 있습니다. 콘텐츠 모델이 레이아웃에 종속된 커다란 마크업 블록 하나를 저장하는 대신 자료를 명확하게 설명할 때 가장 잘 작동합니다.

독자마다 다른 표현 방식을 제공할 수 있습니다. 휴대전화 화면, 긴 글, 행사 디스플레이는 서로 다른 요구를 가집니다. 같은 기초 정보를 사용하면서도 모두를 하나의 템플릿에 억지로 넣지 않을 수 있습니다.

이 아키텍처가 대신 해 주지 않는 일

헤드리스라고 해서 자동으로 빨라지는 것은 아닙니다. 페이지를 미리 준비해 빠르게 제공할 수도 있지만, 무엇인가 나타나기 전에 느린 요청이 연쇄적으로 발생할 수도 있습니다. 이미지, 캐시, 호스팅, 프런트엔드를 구축하는 방식은 여전히 결과를 좌우합니다. 영역을 분리하면 팀이 성능을 개선하고 용량을 늘릴 위치를 선택할 수 있지만, 누군가는 그 선택을 하고 테스트해야 합니다.

편집자에게는 입력 상자 하나만으로 충분하지 않습니다. 초안을 미리 보고, 링크와 이미지를 확인하고, 올바른 언어로 게시하고, 이전 버전을 복구할 수 있어야 합니다. 개발자는 이런 작업을 새 프런트엔드에 연결해야 합니다. 아키텍처 다이어그램에서는 우아해 보이는 시스템도 일상적인 게시를 불편하게 만들 수 있습니다.

통제에도 같은 구분이 적용됩니다. API는 누가 규칙을 바꿀 수 있는지, 모든 것을 내보낼 수 있는지, 공급업체가 서비스를 중단해도 계속 게시할 수 있는지를 정해 주지 않습니다. 이런 문제는 소프트웨어, 호스팅 구성, 권한, 다른 시스템으로 옮길 실제 경로에 달려 있습니다.

완전한 게시 작업을 시험해 보세요

  1. 대표적인 항목 하나를 고르세요. 예를 들어 사진, 날짜, 설명, 두 번째 언어가 있는 강연을 선택할 수 있습니다.
  2. 그 항목을 편집할 사람에게 초안을 만들고 실제 웹사이트와 앱 레이아웃을 미리 보게 하세요.
  3. 게시하고 시간을 바꾼 뒤 각 대상에 언제 수정 사항이 표시되는지 확인하세요.
  4. 이전 버전을 복원하세요. 콘텐츠와 미디어를 내보낸 다음 다른 곳에서 사용하려면 무엇이 필요한지 확인하세요.

이 작은 시험은 기능 목록보다 많은 것을 보여 줍니다. 아키텍처가 팀에 유용한 자유를 주는지, 일상 업무를 관리할 수 있는지 드러냅니다.

게시 목적에 맞춰 선택하세요

여러 애플리케이션이 같은 구조화된 콘텐츠를 필요로 하거나 독자 경험에 상당한 맞춤 개발이 필요하다면 헤드리스가 잘 맞을 수 있습니다. 게시 대상이 하나인 단순한 사이트라면 편집과 표현 방식을 결합한 시스템이 일을 줄여 줄 수 있습니다. 업무에서 출발한 뒤 아키텍처를 선택하세요.

더 폭넓게 비교하려면 게시 작업의 부담과 이동 가능성을 기준으로 CMS를 고르는 방법을 읽어 보세요.