CMS 헤드리스 개발에 대해 알아보기

AEM Headless Developer 여정의 이 부분에서에서 헤드리스 기술과 왜 이 기술을 사용하는지 알아봅니다.

목표

이 문서는 헤드리스 콘텐츠 전달과 이 게재를 사용해야 하는 이유를 이해하는 데 도움이 됩니다. 읽은 후에는 다음을 수행해야 합니다.

  • 헤드리스 컨텐츠 전달의 기본 개념 및 용어 이해
  • 헤드리스가 필요한 이유와 시기 이해
  • 헤드리스 개념이 어떻게 사용되고 어떻게 상호 작용하는지 높은 수준에서 파악할 수 있습니다

전체 스택 컨텐츠 전달

사용이 간편하고 규모가 큰 CMS(콘텐츠 관리 시스템)가 급증한 이후 조직은 이를 메시징, 브랜딩 및 커뮤니케이션을 관리하는 중앙 위치로 활용했습니다. CMS를 경험 관리를 위한 중심점으로 사용하면 서로 다른 시스템에서 작업을 복제할 필요가 없으므로 효율성이 향상됩니다.

기존의 전체 스택 CMS

전체 스택 CMS에서 콘텐츠를 조작하기 위한 모든 기능은 CMS에 있습니다. 시스템의 기능은 CMS 스택의 다양한 구성 요소를 구성합니다. 전체 스택 솔루션에는 많은 이점이 있습니다.

  • 한 가지 시스템을 유지 관리할 수 있습니다.
  • 컨텐츠는 중앙에서 관리됩니다.
  • 시스템의 모든 서비스가 통합됩니다.
  • 컨텐츠 작성이 원활하게 수행됩니다.

따라서 새 채널을 추가하거나 새 유형의 경험을 지원하려는 경우 한 개 이상의 새 구성 요소를 스택에 삽입할 수 있으며 한 곳만 변경 작업을 수행할 수 있습니다.

스택에 새 채널 추가

변경 사항에 맞게 스택의 다른 항목을 조정해야 할 수 있으므로 스택 내의 종속성의 복잡성이 빠르게 드러납니다.

전체 스택 전달 제한

전체 스택 접근 방식은 기본적으로 모든 경험이 하나의 시스템에 있는 사일로를 만듭니다. 사일로의 한 구성 요소에 변경 또는 추가 작업을 하려면 시간이 많이 걸리고 비용이 많이 드는 다른 구성 요소를 변경해야 합니다.

이것은 전통적인 설정에서 종종 CMS와 밀접하게 연결되어 있는 프리젠테이션 시스템에 특히 적용됩니다. 모든 새 채널은 일반적으로 프레젠테이션 시스템에 대한 업데이트를 의미하며 다른 모든 채널에 영향을 줄 수 있습니다.

스택에 채널이 추가되면 복잡성이 증가합니다

이러한 자연 사일로의 제한 사항은 스택의 모든 구성 요소의 변경 사항을 조정하기 위해 더 많은 노력을 기울이기 때문에 쉽게 알 수 있습니다.

사용자는 플랫폼이나 터치 포인트에 관계없이 참여를 기대할 수 있으므로 경험을 전달하는 방법에 있어 민첩성이 필요합니다. 이러한 다중 채널 접근 방식은 디지털 경험의 표준이며 특정 상황에서 전체 스택 접근 방식은 유연성이 없다는 것을 입증할 수 있습니다.

헤드리스의 머리

시스템의 헤드는 일반적으로 해당 시스템의 출력 렌더러이며, 일반적으로 GUI 또는 기타 그래픽 출력 형태입니다.

예를 들어, 헤드리스 서버는 서버 룸의 랙에 앉아 있고 모니터가 연결되어 있지 않을 수 있습니다. 액세스하려면 원격으로 접속해야 합니다. 이 경우 모니터는 서버의 출력 렌더링을 담당하는 헤드입니다. 사용자가 서비스 수요자로서 원격으로 연결할 때 직접 헤드(모니터)를 제공합니다.

헤드리스 CMS에 대해 이야기할 때, CMS는 컨텐츠를 관리하고 소비자에게 계속 제공합니다. 그러나, 표준화된 방식으로 content​만 전달함으로써, 헤드리스 CMS가 최종 출력 렌더링을 생략하고 컨텐츠의 presentation​을 소비 서비스에 남겨 둡니다.

헤드리스 CMS

경험 AR 경험, 웹 스토어, 모바일 경험, 점진적 웹 앱(PWA) 등 소비되는 서비스는 헤드리스 CMS의 콘텐츠를 가져와서 자체 렌더링을 제공합니다. 그들은 여러분의 컨텐츠에 대해 그들 자신의 의견을 제공하는 것을 돌봅니다.

헤드를 생략하면 복잡도를 제거하여 CMS를 단순화할 수 있습니다. 이렇게 하면 컨텐츠가 실제로 필요하고 이러한 렌더링에 더 잘 맞는 서비스로 컨텐츠를 렌더링하는 작업도 이동합니다.

분리

모든 경험이 활용할 수 있는 강력하고 유연한 애플리케이션 프로그래밍 인터페이스(API) 세트를 노출하여 헤드리스 게재를 수행할 수 있습니다. API는 서비스 간의 공통 언어 역할을 하며, 표준화된 콘텐츠 전달을 통해 콘텐츠 수준에서 함께 바인딩하지만 고유한 솔루션을 구현할 수 있는 유연성을 제공합니다.

헤드리스는 프레젠테이션에서 콘텐츠를 분리하는 예입니다. 또는 일반적인 의미에서 서비스 스택의 백 엔드에서 프런트 엔드를 분리하십시오. 헤드리스 설정에서 프레젠테이션 시스템(헤드)은 컨텐츠 관리(테일)에서 분리됩니다. 두 링크는 API 호출만 상호 작용합니다.

즉, 각 소모되는 서비스(프런트엔드)가 API를 통해 전달되는 동일한 컨텐츠를 기반으로 경험을 쌓아서 컨텐츠를 재사용하고 일관성을 유지할 수 있습니다. 그런 다음 서비스를 사용하면 자체 프레젠테이션 시스템을 구현할 수 있으므로 컨텐츠 관리 스택(백 엔드)을 수평 방향으로 손쉽게 확장할 수 있습니다.

기술 기초

헤드리스 방식을 사용하면 향후 디지털 경험 요구에 쉽고 빠르게 대응할 수 있는 기술 스택을 구축할 수 있습니다.

과거에 CMS에 대한 API는 일반적으로 REST 기반이었습니다. REST(대표 상태 전송)는 상태를 저장하지 않는 방식으로 리소스를 텍스트로 제공합니다. 이렇게 하면 사전 정의된 작업 세트로 리소스를 읽고 수정할 수 있습니다. REST는 컨텐츠의 상태를 저장하지 않는 표시를 보장하여 웹에서 서비스 간에 뛰어난 상호 운용성을 보장합니다.

여전히 강력한 REST API가 필요합니다. 그러나 REST 요청은 크고 자세히 지정할 수 있습니다. 여러 소비자가 모든 채널에 REST 호출을 하는 경우 이러한 세부 정보 조합 및 성능에 영향을 줄 수 있습니다.

헤드리스 컨텐츠 전달을 통해 GraphQL API를 사용하는 경우가 많습니다. GraphQL에서는 유사한 상태 비저장 전송을 허용하지만 더 많은 대상 쿼리를 사용할 수 있으므로 필요한 총 쿼리 수를 줄일 수 있고 성능을 향상시킬 수 있습니다. 일반적으로 REST 와 GraphQL이 혼합된 솔루션을 사용하여 작업을 위한 최상의 도구를 선택하는 것이 일반적입니다.

선택한 API가 무엇이든 공통 API를 기반으로 헤드리스 시스템을 정의하여 최신 브라우저와 점진적 웹 앱(PWA) 등의 기타 웹 기술을 활용할 수 있습니다. API는 쉽게 확장 및 적용할 수 있는 표준 인터페이스를 만듭니다.

일반적으로 컨텐츠는 클라이언트측에서 렌더링됩니다. 일반적으로 이는 누군가 모바일 장치에서 콘텐츠를 호출하고, CMS가 콘텐츠를 제공한 다음, 모바일 장치(클라이언트)가 사용자가 제공한 콘텐츠를 렌더링할 책임이 있음을 의미합니다. 장치가 오래되었거나 느린 경우 디지털 경험도 마찬가지로 느립니다.

프레젠테이션에서 컨텐츠를 분리하면 이러한 클라이언트측 성능 문제를 더 잘 제어할 수 있습니다. SSR(서버측 렌더링)은 클라이언트의 브라우저에서 서버로 컨텐츠를 렌더링하는 권한을 전송합니다. 이를 통해 컨텐츠 제공자는 필요한 경우 대상자에게 안정된 성능 수준을 제공할 수 있습니다.

조직의 당면 과제

헤드리스는 디지털 경험을 전달할 수 있는 유연한 세상을 열어줍니다. 그러나 이러한 유연성은 또한 그 자신의 도전을 제시할 수 있다.

여러 채널을 사용하는 것은 각각 고유한 프레젠테이션 시스템이 있다는 것을 의미할 수 있습니다. 모두 동일한 API를 통해 동일한 콘텐츠를 소비하지만 서로 다른 프레젠테이션 때문에 경험이 다를 수 있습니다. 고객 경험의 일관성을 유지하기 위해서는 염려와 배려가 있어야 합니다.

신중한 설계 시스템을 구현하고, 패턴 라이브러리를 공유하고, 재사용 가능한 디자인 구성 요소와 더불어 구축된 오픈 클라이언트측 프레임워크를 활용함으로써 일관된 경험을 확보할 수 있지만, 이를 계획해야 합니다.

미래는 헤드리스 이고 미래는 지금 입니다

디지털 경험은 브랜드와 고객이 상호 작용하는 방법을 계속 정의합니다. 헤드리스 디자인에서 흥미로운 점은 진화하는 고객의 기대에 부응할 수 있는 유연성입니다.

미래를 예측하는 것은 불가능하지만, 헤드리스를 하지 않으면 여러분에게 미래에서 가져오는 것에 반응할 민첩성을 줍니다.

AEM 및 헤드리스

이 개발자 여정을 계속 진행하면 AEM에서 전체 스택 전달 기능 외에 헤드리스 게재를 지원하는 방법을 알 수 있습니다.

디지털 경험 관리 분야의 업계 리더인 Adobe은 경험 작성자가 직면하는 실제 문제에 대한 이상적인 솔루션이 바이너리 선택은 거의 아니라는 것을 인식하고 있습니다. 이것이 AEM이 두 모델을 모두 지원할 뿐만 아니라 헤드리스와 전체 스택의 장점을 혼합하여 두 모델의 매끄러운 하이브리드 조합을 고유하게 허용하는 이유입니다. 이러한 두 모델은 어디에 있든 소비자에게 최상의 서비스를 제공할 수 있습니다.

이 여정은 헤드리스 전용 컨텐츠 전달 모델에 중점을 둡니다. 그러나 이러한 기본 지식이 있으면 두 모델의 기능을 활용하는 방법을 더 탐색할 수 있습니다.

다음은 무엇입니까?

AEM 헤드리스 여정을 시작해 주셔서 감사합니다! 이제 이 문서를 읽고 나면 다음을 수행해야 합니다.

  • 헤드리스 컨텐츠 전달의 기본 개념 및 용어를 이해합니다.
  • 헤드리스가 필요한 이유와 시기를 이해합니다.
  • 헤드리스 개념이 어떻게 사용되고 어떻게 상호 작용하는지 높은 수준에서 파악할 수 있습니다.

이 지식을 바탕으로 AEM 헤드리스 여정을 계속 진행하려면 다음 AEM Headless 시작하기 를 Cloud Service 로 문서 Headless 시작하기 를 검토하여 필요한 도구를 설정하는 방법과 AEM이 헤드리스 컨텐츠 전달과 해당 사전 요구 사항에 어떻게 접근하는지에 대해 생각하는 방법을 학습하십시오.

추가 리소스

AEM Headless를 Cloud Service으로 시작하기 문서를 검토하여 헤드리스 개발 여정의 다음 부분으로 이동하는 것이 좋지만, 다음은 이 문서에서 언급된 일부 개념에 대해 자세히 설명하는 몇 가지 추가 선택적 리소스입니다. 하지만 헤드리스 여정에서 계속할 필요는 없습니다.

이 페이지에서는