Cloud Service으로 AEM Headless 시작하기

AEM Headless 개발자 여정의 이 부분에서에서는 AEM Headless로 직접 프로젝트를 시작하는 데 필요한 사항에 대해 알아봅니다.

지금까지 그 이야기

AEM 헤드리스 여정의 이전 문서에서, CMS 헤드리스 개발에서는 헤드리스 CMS가 무엇인지에 대한 기본 이론을 배웠고 이제 다음을 수행해야 합니다.

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

이 문서는 이러한 기본 사항을 기반으로 하여 AEM을 사용하여 헤드리스 솔루션을 구현하는 방법을 이해합니다.

목표

이 문서는 프로젝트 컨텍스트에서 AEM 헤드리스를 이해하는 데 도움이 됩니다. 읽은 후에는 다음을 수행해야 합니다.

  • AEM 헤드리스 기능의 기본 사항을 이해합니다.
  • AEM 헤드리스 기능을 사용하기 위한 사전 요구 사항을 알아봅니다.
  • AEM 헤드리스 통합 수준을 숙지하십시오.
  • 범위 측면에서 프로젝트를 정의할 수 있습니다.

AEM 기본 사항

AEM 내에서 헤드리스 프로젝트를 정의하려면 먼저 몇 가지 기본 AEM 개념을 이해하는 것이 중요합니다.

작성자 인스턴스

가장 간단한 방법으로서, AEM은 컨텐츠를 만들고, 관리하고, 게시하기 위해 함께 작동하는 작성자 인스턴스와 게시 인스턴스로 구성됩니다.

컨텐츠는 작성자 인스턴스에서 시작됩니다. 여기에서 컨텐츠 작성자가 컨텐츠를 만듭니다. 작성 환경에서는 작성자가 컨텐츠를 작성, 구성 및 재사용할 수 있는 다양한 도구를 제공합니다.

게시 인스턴스

작성 인스턴스에서 컨텐츠를 만들면 다른 서비스에서 사용할 수 있도록 컨텐츠를 게시해야 합니다. 게시 인스턴스에는 게시된 모든 컨텐츠가 포함됩니다.

복제

복제는 작성 인스턴스에서 게시 인스턴스로 컨텐츠를 전송하는 것입니다. 이 작업은 적절한 권한이 있는 작성자 또는 다른 사용자가 컨텐츠를 게시하면 AEM에서 자동으로 수행됩니다.

AEM 기본 사항 요약

가장 간단한 수준에서 AEM에서 디지털 경험을 만들려면 다음 단계가 필요합니다.

  1. 컨텐츠 작성자가 작성 인스턴스에서 헤드리스 컨텐츠를 만듭니다.
  2. 이 컨텐츠가 준비되면 게시 인스턴스에 복제됩니다.
  3. 그런 다음 이 컨텐츠를 검색하기 위해 API를 호출할 수 있습니다.

AEM Headless는 다음 섹션에 설명된 의 헤드리스 컨텐츠를 관리하는 강력한 도구를 제공하여 이 기술 기반을 구축합니다.

AEM Headless 기본 사항

AEM의 헤드리스 기능은 몇 가지 주요 기능을 기반으로 합니다. 이러한 내용은 여정 후반부에 자세히 설명되어 있습니다. 이제 그들이 무엇을 하고 그들이 뭐라고 불리는지에 대한 기본 사항만 아는 것이 중요하다.

컨텐츠 조각 모델

컨텐츠 조각 모델 AEM에서 만들고 관리하는 데이터 및 컨텐츠의 구조를 정의합니다. 컨텐츠를 위한 일종의 스캐폴딩 역할을 합니다. 컨텐츠를 작성하도록 선택할 때 작성자가 정의한 컨텐츠 조각 모델에서 컨텐츠 생성을 안내하는 컨텐츠 조각 모델을 선택합니다.

콘텐츠 조각

컨텐츠 조각을 사용하면 페이지에 구애받지 않고 컨텐츠를 디자인, 작성, 조정 및 게시할 수 있습니다. 이를 통해 여러 위치 및 여러 채널에서 사용할 수 있는 컨텐츠를 준비할 수 있습니다.

컨텐츠 조각은 구조화된 컨텐츠를 포함하며 JSON 형식으로 게재할 수 있습니다.

GraphQL 및 REST API

AEM에서 헤더없이 컨텐츠를 수정하기 위해 두 개의 강력한 API를 제공합니다.

  • GraphQL API를 사용하면 컨텐츠 조각에 액세스하고 전달할 요청을 만들 수 있습니다.
  • 자산 REST API 를 사용하면 컨텐츠 조각(및 기타 자산)을 만들고 수정할 수 있습니다.

이러한 API에 대해 알아보고, AEM 헤드리스 여정의 뒷부분에서 이 API를 사용하는 방법을 알아봅니다. 또는 추가 문서를 보려면 아래의 추가 리소스 섹션을 참조하십시오.

헤드리스 통합 수준

AEM은 CMS의 전체 헤드리스와 기존의 전체 스택 또는 경험 모델을 모두 지원합니다. 그러나 AEM은 이러한 두 가지 독점 옵션뿐만 아니라 두 가지 장점을 결합하는 하이브리드 모델을 지원하는 기능을 제공하여 헤드리스 프로젝트에 고유한 유연성을 제공합니다.

헤드리스 개념을 이해하기 위해 이 AEM 헤드리스 개발자 여정은 AEM에서 코딩 없이 가능한 한 빨리 시작하고 실행할 수 있도록 헤드리스 순수 모델에 중점을 둡니다.

그러나 AEM 헤드리스 기능을 이해하면 열려 있는 추가 하이브리드 가능성을 알고 있어야 합니다. 이 사건들은 여러분이 알고 있기 위해 아래에 제시되어 있습니다. 여정 종료 시 프로젝트에 이러한 유연성이 필요한 경우 이러한 개념을 보다 자세히 소개합니다.

이미 단일 페이지 애플리케이션(SPA)과 같은 헤드리스 컨텐츠의 외부 사용이 있습니다.

AEM에서 기존 외부 서비스로 콘텐츠를 전달하는 데 최소 기본 요구 사항이 있다고 가정합니다.

수준 1: 컨텐츠 조각 통합 - 기존 헤드리스 모델

이 수준의 통합 기능은 기존 헤드리스 모델로서 컨텐츠 작성자는 AEM에서 컨텐츠를 만들어 GraphQL을 사용하여 외부 서비스에 임의로 제공하거나 자산 API를 사용하여 외부 서비스에서 편집할 수 있습니다. AEM에서는 코딩이 필요하지 않습니다.

이 모델에서 AEM은 AEM 컨텐츠 조각을 사용하여 컨텐츠를 만들고 제공하는 데만 사용됩니다. 컨텐츠와의 렌더링 및 상호 작용은 종종 단일 페이지 애플리케이션(SPA)인 소비되는 외부 애플리케이션에 위임됩니다.

레벨 2: AEM - 하이브리드 모델에 SPA 포함

이 수준의 통합 빌드는 첫 번째 수준이지만, 컨텐츠 작성자가 AEM 내의 외부 애플리케이션 컨텍스트에서 컨텐츠를 볼 수 있도록 SPA(외부 애플리케이션)를 AEM에 포함할 수도 있습니다. 또한 AEM 내에서 외부 애플리케이션의 제한된 편집을 지원할 수 있습니다.

이 수준에서는 컨텐츠 작성자가 포함된 외부 SPA과 컨텍스트 내에 포함된 컨텐츠를 제시하면서 여전히 컨텐츠를 헤더없이 전달하면서 헤더링 방식으로 AEM에서 컨텐츠를 유연하게 작성할 수 있는 장점이 있습니다.

레벨 3: AEM - 하이브리드 모델의 SPA 포함 및 전체 활성화

이 통합 수준은 AEM 내에서 외부 SPA의 대부분의 컨텐츠를 편집할 수 있도록 함으로써 레벨 2에 따라 빌드됩니다.

아직 단일 페이지 애플리케이션(SPA)과 같은 헤드리스 컨텐츠의 외부 소비자가 없습니다.

목표가 AEM의 컨텐츠를 헤드리스 없이 사용하는 새 SPA을 만드는 것이면 컨텐츠 조각과 같은 기능을 사용하여 헤드리스 컨텐츠를 관리하고, AEM SPA 편집기 프레임워크를 사용하여 SPA을 빌드할 수도 있습니다.

SPA 편집기를 사용하면 SPA에서 AEM의 컨텐츠를 소비할 뿐만 아니라 컨텐츠 작성자가 AEM 내에서 헤드리스 게재와 컨텍스트 내 편집의 유연성을 모두 제공하는 등 AEM 내에서 완전히 편집할 수 있습니다.

요구 사항 및 사전 요구 사항

헤드리스 AEM 프로젝트를 시작하기 전에 많은 요구 사항이 있습니다.

지식

  • GraphQL
  • React 또는 Angular 프레임워크을 사용하여 SPA을 만드는 개발 경험
  • 컨텐츠 조각을 만들고 편집기를 사용하는 기본 AEM 기술

도구

  • 프로젝트 배포를 테스트하는 샌드박스 액세스
  • 데이터 모델링 및 테스트를 위한 로컬 개발 인스턴스
  • 헤드리스 AEM 콘텐츠의 기존 외부 SPA 또는 기타 소비자

프로젝트 정의

성공적인 프로젝트의 경우 프로젝트의 요구 사항뿐만 아니라 역할과 책임을 명확히 정의하는 것이 중요합니다.

범위

프로젝트에 대해 명확하게 정의된 범위를 갖는 것이 중요합니다. 범위는 수락 기준을 알려주고 완료를 정의할 수 있도록 해줍니다.

여러분이 질문해야 할 첫 번째 질문은 "AEM Headless로 무엇을 성취하려고 노력하고 있습니까?"입니다. 일반적으로 답변은 AEM이 아닌 자체 개발 도구로 빌드한 경험 애플리케이션을 보유하고 있거나 향후에 보유해야 합니다. 이 경험 애플리케이션은 모바일 앱, 웹 사이트 또는 기타 최종 사용자 고객 대면 경험 애플리케이션일 수 있습니다. AEM 헤드리스를 사용하는 목적은 AEM에서 생성, 저장 및 관리되는 컨텐츠로 경험 애플리케이션을 제공하는 것입니다. 이 API는 AEM Headless를 호출하여 경험 애플리케이션에서 직접 컨텐츠 또는 완전히 CRUD 컨텐츠를 가져오도록 합니다. 이 작업을 수행하지 않으려면 AEM 설명서로 돌아가서 수행하려는 작업에 더 적합한 섹션을 찾습니다.

역할 및 책임

개별 프로젝트에 대한 역할은 다르지만, AEM 헤드리스 개발 컨텐츠에서 고려해야 할 중요한 역할은 다음과 같습니다.

관리자

관리자는 시스템의 기본 설정 및 구성을 담당합니다. 예를 들어 관리자는 IMS(Identity Management System)라고 하는 Adobe 사용자 관리 시스템 내에 조직을 설정합니다. 관리자는 IMS 내의 Adobe에서 조직을 만든 후 Adobe에서 이메일 초대를 받은 조직의 첫 번째 사용자입니다. 관리자는 IMS에 로그인하고 다른 개인의 사용자를 추가할 수 있습니다.

관리자가 사용자를 구성하면, 모든 AEM 리소스에 액세스하여 AEM Headless를 사용하여 경험 애플리케이션을 제공하는 기여자로서 작업을 수행할 수 있는 권한이 부여됩니다.

관리자는 AEM을 설정하고 런타임 환경을 준비하는 사용자여야 합니다. 이 사용자는 컨텐츠 작성자가 컨텐츠를 만들고 업데이트할 수 있도록 설정하고 개발자가 경험 애플리케이션에 대한 컨텐츠를 가져오거나 수정하는 API를 사용하도록 설정해야 합니다.

컨텐츠 작성자

컨텐츠 작성자는 AEM에서 헤드라인으로 전달하는 콘텐츠를 만들고 관리합니다. 컨텐츠 작성자는 컨텐츠 조각 및 자산 콘솔과 같은 AEM 기능을 사용하여 컨텐츠를 관리합니다.

컨텐츠 작성자는 다음 모범 사례를 따라야 합니다.

번역 계획

프로젝트의 시작 부분에 번역을 계획합니다. 번역 전문가 를 번역해야 하는 컨텐츠와 번역해서는 안 되는 사항 및 지역 또는 지역 컨텐츠 제작자가 수정할 수 있는 번역된 컨텐츠를 정의하는 책임을 지는 별도의 성향으로 간주합니다.

필요한 컨텐츠 번역에 대한 계획을 만듭니다.

  • 지역 특성에 다른 언어나 언어를 사용해야 합니까?
  • 다른 로케일에 대해 이미지나 비디오와 같은 리치 미디어 콘텐츠가 필요합니까?

콘텐츠 업데이트 워크플로우에 대해 명확히 하십시오. 시스템에서 지원해야 하는 승인 프로세스는 무엇입니까? AEM 워크플로우를 활용하여 이 프로세스를 자동화할 수 있습니까?

컨텐츠 계층을 활용하여 번역을 쉽게 할 수 있습니다.

AEM Headless 번역 여정에 대한 링크를 포함하여 AEM 워크플로우 및 번역 도구에 대한 추가 설명서는 추가 리소스 섹션을 참조하십시오.

컨텐츠 계층 활용

폴더 계층 구조 는 컨텐츠 관리와 관련하여 두 가지 주요 문제를 해결할 수 있습니다.

  • 번역 - AEM은 로케일 특정 폴더에서 컨텐츠 사본을 유지 관리하여 컨텐츠 번역을 관리합니다.
  • 조직 - 폴더는 번역 요구 사항을 지원하고 컨텐츠 조각을 논리적으로 관리하는 데 필요한 컨텐츠 계층 구조를 정의하는 데 사용됩니다.

AEM을 사용하면 유연한 컨텐츠 구조를 만들 수 있으며 계층 구조가 임의로 클 수 있습니다. 그러나 폴더 구조의 모든 변경 사항에 이 컨텐츠 경로에 의존하는 기존 쿼리에 의도하지 않은 결과가 발생할 수 있다는 것을 알고 있어야 합니다. 따라서 미리 명확하게 설정된 잘 정의된 계층 구조가 컨텐츠 작성자에게 유용할 수 있습니다.

폴더를 특정 컨텐츠 유형(컨텐츠 조각 모델 기반)만 허용하도록 제한할 수도 있습니다. 계층의 모든 폴더에 대해 허용되는 모델을 항상 명시적으로 지정하는 것이 좋습니다. 지정된 폴더에 대해 허용되는 컨텐츠 지정:

  • 컨텐츠 작성자가 폴더에 속하지 않는 컨텐츠를 작성할 수 없습니다.
  • 만드는 동안 폴더에 허용된 컨텐츠 유형을 필터링하여 유효한 컨텐츠 유형만 표시하도록 컨텐츠 생성 프로세스를 최적화합니다.

적절한 컨텐츠 구조를 만들면 컨텐츠 재사용을 최대화하기 위해 채널 간에 헤드리스 컨텐츠 작성을 조정하기가 쉬워집니다. 여러 채널에서 컨텐츠를 활용하면 컨텐츠 제작 효율성 및 변경 관리 기능이 크게 향상됩니다.

올바른 이름 지정 규칙 설정

컨텐츠 조각 이름은 컨텐츠 작성자에 대해 설명적이어야 합니다. AEM은 저장소 수준에서 사용된 ID의 이름 이스케이프 및/또는 잘라내기를 투명하게 처리합니다. 따라서 컨텐츠 작성자가 제공하는 논리 이름은 항상 읽을 수 있고 컨텐츠를 나타내야 합니다.

  • 잘못된 이름: cta_btn_1
  • 이름: Call To Action Button

AEM 페이지 이름 지정 규칙에 대한 추가 설명서는 추가 리소스 섹션을 참조하십시오.

컨텐츠 중첩을 과하게 하지 마십시오

컨텐츠 조각은 헤드리스 컨텐츠를 만드는 데 AEM에서 사용됩니다. AEM에서는 컨텐츠 조각에 대해 최대 10개의 컨텐츠 중첩 수준을 지원합니다. 그러나 AEM은 상위 컨텐츠 조각에 정의된 각 참조를 반복적으로 확인한 다음 모든 동일 수준에 하위 참조가 있는지 확인해야 한다는 것을 명심해야 합니다. 이러한 작업은 신속하게 추가되어 성능 문제가 될 수 있습니다.

일반적인 경험상 컨텐츠 조각 참조는 5개 수준 이상으로 중첩되어서는 안 됩니다.

컨텐츠 설계자

컨텐츠 설계자는 헤드리스 없이 전달해야 하는 데이터에 대한 요구 사항을 분석하고 이 데이터의 구조를 정의합니다. 이러한 구조를 AEM에서 컨텐츠 조각 모델이라고 합니다. 컨텐츠 조각 모델은 컨텐츠 작성자가 만드는 컨텐츠 조각의 기초로 사용됩니다.

컨텐츠 조각 모델을 정의할 때 유용한 접근 방법은 컨텐츠를 사용하는 애플리케이션의 UX 구성 요소에 매핑되는 모델을 만드는 것입니다.

컨텐츠 작성자는 새로운 컨텐츠를 만들 때 모델과 지속적으로 상호 작용하므로 모델을 UX에 정렬하면 결과 디지털 경험을 시각화할 수 있습니다. 이 정렬을 한 단계 더 진행하면 UX 요소를 나타내는 컨텐츠 조각 모델에 아이콘을 할당하여 작성자가 시각적 큐를 기반으로 올바른 모델을 직관적으로 선택할 수 있습니다.

개발자

개발자는 AEM에서 만들어지는 컨텐츠를 해당 컨텐츠의 소비자에 헤드없이 결합할 책임이 있습니다. 이러한 컨텐츠는 종종 SPA(단일 페이지 애플리케이션), 점진적 웹 앱(PWA), 웹 샵 또는 AEM 외부의 기타 서비스일 수 있습니다.

GraphQL은 AEM과 헤드리스 컨텐츠의 소비자 간에 "접착제" 역할을 합니다. GraphQL은 AEM에서 필요한 컨텐츠를 쿼리하는 언어입니다.

개발자는 쿼리를 계획할 때 몇 가지 기본 권장 사항을 염두에 두어야 합니다.

  • 쿼리는 컨텐츠 조각을 검색하는 고정 경로(ByPath)에 의존하지 않아야 합니다.
    • 컨텐츠 작성자는 컨텐츠 조각 계층 에 대한 완전한 제어 권한을 가지며, 이러한 쿼리를 중단하는 변경 작업을 수행할 수 있습니다.
    • 쿼리는 대신 동적 쿼리 매개 변수를 사용하여 컨텐츠 조각 모델 참조를 옵트하여 결과를 필터링하여 원하는 페이로드를 생성해야 합니다.
  • 최상의 쿼리 성능을 위해 항상 AEM에서 지속된 쿼리를 사용하십시오. 이러한 내용은 여정에서 나중에 설명합니다.
  • GraphQL은 "필요한 내용을 정확히 확인하고 정확하게 파악할 수 있습니다"라는 모토에 따라 선언됩니다. 즉, GraphQL 쿼리를 만들 때 항상 관계형 데이터베이스에서 만들 수 있는 select * 유형 쿼리를 사용하지 않습니다.

AEM을 사용하는 일반적인 헤드리스 구현의 경우,🔗개발자는 AEM에 대한 코딩 지식이 필요하지 않습니다.

성능 요구 사항

모든 프로젝트가 성공하려면 컨텐츠가 생성되기 전에 성능을 고려해야 합니다.

사용자/방문자의 기대치와 디자인을 이해해야 합니다. SLO(Service Level Objects)를 설정하고 이를 측정하여 사용자의 기대에 부합하는지 파악할 수 있습니다.

트래픽 패턴

트래픽 및 트래픽 패턴을 이해하려면 과거에 알고 있는 정보를 수집한 다음 향후 몇 년 동안 예상되는 성장에 대해 계획하십시오. 고려해야 할 가장 중요한 변수 중 일부:

  • 스파이크와 양념에 대해 예상되는 시간/일/개월당 몇 개의 API 호출이 있습니까?
  • 몇 개의 다양한 컨텐츠 작성자가 있습니까?
  • 동시에 작업할 컨텐츠 작성자는 몇 명입니까?
  • 콘텐츠 업데이트 빈도는 얼마입니까?
  • 몇 개의 컨텐츠 모델이 필요합니까?
  • 몇 개의 모델 인스턴스가 필요합니까?

업데이트 빈도

경험의 여러 섹션에서 콘텐츠 업데이트 빈도를 달리하는 경우가 많습니다. CDN 및 캐시 구성을 미세 조정할 수 있어야 합니다. 또한 컨텐츠 설계자가 컨텐츠를 나타내는 모델을 설계하므로 이 입력도 중요합니다. 다음 사항을 고려하십시오.

  • 일정 기간 후에 일부 유형의 컨텐츠가 만료됩니까?
  • 사용자별로 다르므로 캐싱할 수 없는 요소가 있습니까?

다음은 무엇입니까?

AEM Headless 개발자 여정의 이 부분을 완료했으므로 다음을 수행해야 합니다.

  • AEM 헤드리스 기능의 기본 사항을 이해합니다.
  • AEM 헤드리스 기능을 사용하기 위한 사전 요구 사항을 알아봅니다.
  • AEM 헤드리스 통합 수준을 숙지하십시오.
  • 범위 측면에서 프로젝트를 정의할 수 있습니다.

다음으로 AEM 헤드리스 여정을 계속 진행하려면 문서 AEM 헤드리스를 사용하여 첫 번째 경험으로 이동 을 검토하여 필요한 도구를 설정하는 방법과 AEM에서 데이터 모델링을 시작하는 방법을 학습해야 합니다.

추가 리소스

AEM Headless를 사용하여 첫 번째 경험으로 이동 문서를 검토하여 헤드리스 개발 여정의 다음 부분으로 이동하는 것이 좋지만, 다음은 이 문서에서 언급된 일부 개념에 대해 자세히 설명하는 몇 가지 추가 선택적 리소스입니다. 그러나 헤드리스 여정을 계속 진행할 필요는 없습니다.

이 페이지에서는