Adobe Experience Manager의 15년 - 연혁

오늘로서 Adobe가 Day Software를 최종적으로 인수하여 현재 여러분 모두가 알고 있는 "AEM" 으로 제품을 인수한 지 15년이 되었습니다.

저처럼 수년간 이 플랫폼으로 작업해 온 분들에게 이 글이 Adobe가 Day를 인수한 이유와 그 후 15년 동안 무엇이 바뀌었는지(혹은 바뀌지 않았는지!) 돌아보는 즐거운(또는 고통스러운) 추억 여행이 되길 바랍니다.

당일 성명서 - Adobe 인수 전

스위스 바젤에 본사를 둔 Day Software는 커스텀 파일 시스템 기반 플랫폼에서 획기적인 Communique CMS를 개발한 회사로, 이후 오늘날 우리가 알고 있는 Java 콘텐츠 저장소 지원 시스템으로 발전했습니다.

CQ의 첫 번째 버전은 2000년 초에 넷스케이프 엔터프라이즈 서버용 CGI 스크립트 모음(사용해 본 적이 있다면 손들어 보세요!)이었고, CQ2를 위해 자바 애플리케이션으로 재작성된 후 CQ3(CQSE의 시초)를 위해 HTTP 서버가 분리되었습니다.

CQ4까지는 콘텐츠가 여전히 로컬 파일 시스템의 파일에 저장되었지만 2005년 CQ 4.0이 출시되면서 구형 "Content Bus" 파일 시스템 스토리지에서 20년이 지난 지금도 AEM을 구동하는 "Content Repository eXtreme" (또는 CRX) 리포지토리 버전 1.0으로 전환되었습니다.

CQ5는 대규모 업그레이드 & 오늘날의 AEM의 토대가 되었습니다.

CQ5는 거의 완벽하게 재작성된 제품입니다.

오늘날에는 평범해 보일 수 있는 여러 가지 기능 & 접근 방식이 CQ5 플랫폼의 거대하고 혁신적인 부분입니다. 2008년의 매력적인 CMSwire 기사 "일부 CMS 공급업체는 웹 2.0의 파급력이 임박했다고 생각하며 웹 2.0을 외면하지만, Day는 이 문제에 크게 주목하고 있습니다". 당시의 & 세대에 웹 2.0을 정의할 수 있는 사람이 얼마나 될까요? 하지만 CQ5와 함께 출시된 엄청난 새로운 기능들은 본질적으로 완전히 새로운 플랫폼이 되었고, 대부분의 사람들은 이 기능이 없는 CQ/AEM은 상상조차 할 수 없었습니다:

• 사이드킥 & 작성자 UI: 당시 CQ의 GUI와 WYSIWG 작성 기능은 큰 판매 포인트였으며, 그래픽이 풍부한 환경에서 구성 요소로 작업할 수 있다는 점은 당시 다른 CMS 제품보다 크게 향상된 기능이었습니다.

  

• 워크플로: 이번 릴리스에 추가된 워크플로 엔진은 CMS에서 바로 워크플로를 시각화하고 콘텐츠 관리 시스템으로 바로 비즈니스 로직을 개발할 수 있다는 점에서 많은 사람들의 마음을 사로잡았습니다. 이 기능만으로도 많은 기업 고객이 시스템 전환을 결정했을 것입니다.

  

• CQ 태그: 태그 없이 CQ에서 일하는 것을 상상할 수 있나요? 태그 지원을 추가함으로써 마침내 CQ에 모든 기능을 갖춘 분류 체계가 도입되었습니다.

• 이번 릴리스에서 디지털 자산 관리자는 이제 /content/dam 우리 모두에게 익숙한 경로에 있습니다. 초기에는 브라우저 기반(플래시가 아닌!) 이미지 자르기( & 회전)를 도입했습니다.

  

• 클러스터링: 이 기능은 CQ5 릴리스까지만 지속되었으며 좋든 나쁘든 AEM6에는 적용되지 않았습니다. CQ5에는 상당히 진보된 클러스터링 기능이 있어 작성자와 게시자 모두에 대해 핫 액티브-액티브 또는 액티브-패시브 클러스터링 설정이 가능했습니다. 저는 정확히 한 고객이 게시자 클러스터링을 사용하는 것을 봤는데, 정말 끔찍한 아이디어였고 왜 그렇게 했는지 모르겠습니다. "하지만 저자 클러스터링은 좋은 아이디어였습니다" 이론적으로 클러스터 마스터에서 작성하고 해당 편집 내용을 클러스터 슬레이브로 전파할 수 있습니다(현재는 폐기된 용어). 그러나 클러스터링은 항상 엄청난 안정성의 골칫거리였습니다.

• CRX 개발 환경: 당시 Day는 Java 콘텐츠 저장소에 대한 자세한 클라이언트 측 보기를 위해 작업할 수 있는 Eclipse 기반 개발 환경을 출시했습니다. 또한 Eclipse 대신 사용할 수 있는 경량 브라우저 기반 인터페이스인 "CRX 개발 환경 라이트" 또는 crxde를 출시했는데, 이는 현재까지도 거의 동일한 형태로 남아 있습니다.

이 버전에 새로 추가된 기능은 아니지만 언급할 가치가 있는 것은 CQ의 별도 작성 & 게시 계층을 통해 작성 측의 성능 제약이나 불안정성으로 인해 공개 사이트가 다운되지 않으며, 그 반대의 경우도 마찬가지입니다. CQ가 OSGI와 Sling의 기반에 있다는 것은 풍부한 동적 응답과 페이지 렌더링이 모두 가능한 매우 유연한 콘텐츠 엔진을 의미하며, 이전에는 자체 애플리케이션 서버 스택에서 실행해야 했던 모든 종류의 애플리케이션을 Java에서 무거운 작업을 플러그인할 수 있는 기능을 제공합니다.

CQ 릴리스 타임라인 & 변경 사항

Adobe가 인수하기 전까지 CQ 버전 기록은 다음과 같이 진행되었습니다:

• 데이 CQ 3.5 (2002)

• Day CQ 4.0 (2005)

• 데이 CQ 4.1 (2006)

• 데이 CQ 4.2 (2008)

• Day CQ 5.0(2008) - 내부 고객에게만 미리 보기로 공개됨

• CQ 5.1(2008년) - CQ5의 첫 번째 일반 공개 버전이 출시되었습니다. 워크플로, DAM, 태그, CRXDE, 클러스터링 및 사이드킥이처음 추가되었습니다.

• 데이 CQ 5.2 (2009):

  • 향상된 메타데이터 처리 기능으로 향상된 디지털 자산 관리(DAM)
  • 콘텐츠 처리를 위한 워크플로 엔진 개선 사항
  • Adobe 애널리틱스와의 향상된 통합
  • 여기에서 멀티사이트 매니저(MSM) 가 세상에 처음 공개되었습니다.

• 데이 CQ 5.3 (2010)

  • 소셜 공동 작업을 위한 커뮤니티 기능 도입(참고: AEM 6.5 LTS에서만 이 기능이 마침내 더 이상 사용되지 않고 제거되었습니다!).
  • "A/B 및 다변량 테스트를 위한 사이트 최적화 도구" (곧 그 이름을 다시 듣게 될 것입니다.)
  • 향상된 번역 워크플로 및 국제화 지원

Adobe가 Day Software를 인수하다 & CQ

Adobe는 2010년 7월에 Day Software를 인수할 것이라고 발표했고, 이와 함께 CQ 제품도 인수했습니다. 이 시점에서 Adobe는 이미 CQ에서 자체 웹사이트를 운영하고 있었고, 마케팅 기술 사업 부문을 구축하는 데 중점을 두고 있었기 때문에 당연한 선택이었습니다. Adobe는 2009년 9월에 Omniture를 18억 달러에 인수하고 2007년에는 Scene7을 인수한 바 있어, Adobe가 크리에이티브 소프트웨어 비즈니스 이상의 무언가를 진지하게 고려하기 시작했음을 알 수 있었습니다.

Adobe는 2010년 9월에 전액 현금으로 2억 4천만 달러에 인수를 완료했는데, 이는 Omniture에 지불한 금액보다 7배나 저렴한 가격이었으며, 지금 생각해보면 상당히 파격적인 금액이었습니다.

여러분은 어떤지 잘 모르겠지만 저는 거래가 발표되었을 때 제가 어디에 있었는지 정확히 기억합니다. 당시 저는 AARP를 위해 CQ 5.2를 실행 중이었습니다(그들은 CQ 4.2부터 CQ를 사용하고 있었죠). 당시 저에게 CQ는 "엄청난 골칫거리" 와 "CMS가 여기로 가는 건가요?" CQ에 강력한 Java 애플리케이션 서버 프레임워크가 있었기 때문에 어떤 서비스가 JBoss에 남아 있어야 하는지, 어떤 서비스가 CQ5에서 쉽게 실행될 수 있는지 고민하고 있었기 때문입니다.

하지만 지금 ADOBE에서 구매하셨나요? CQ5를 배우는 데 시간을 계속 투자할지 여부에 대한 모든 계산이 바뀌었습니다. 왜냐하면 Adobe가 지원한다면 분명히 레그가 있을 가능성이 높았기 때문입니다. 그리고 그렇게 되었습니다!

"Day Software" 앱 내부의 브랜딩은 곧 "Adobe CQ" 로 변경되었지만 다른 모든 항목은 대부분 동일하게 유지되었습니다.

• Adobe CQ 5.4 (2011)

  • 성능 및 확장성 향상을 위한 CRX2 리포지토리(CQ 5.3에서 5.4로 업그레이드하는 리포지토리 마이그레이션인 첫 번째 주요 CQ 프로젝트였음)
  • 향상된 소셜 기능 및 커뮤니티 관리
  • 향상된 모바일 저작 기능

• Adobe CQ 5.5 (2012)

  • Adobe Creative Suite, Scene7 및 검색에 대한 커넥터&프로모션
  • 직접 모바일 앱 제작
  • 전자 상거래 통합을 위한 Hybris와의 파트너십
  • 에디터의 실행 취소/다시 실행 기능
  • 콘텐츠 조각은 제가 실제로 함께 일하던 고객을 위한 커스텀 개발을 통해 처음 등장했고, 나중에 기능 팩으로 출시되었습니다.

"Adobe Experience Manager로 브랜드 변경"

Adobe는 이 이름이 영원히 "CQ" 로 불릴 수 없다는 것을 알았기 때문에 몇 차례 브랜드 변경 시도를 중단하고 처음에는 "Adobe WCM" 이라고 부른 다음 "Web Experience Manager" 로 잠시 부른 후 "Adobe Experience Manager" 로 결정했습니다. 5.6 릴리스 도중 로그인 화면이 전환되어 이제 CQ에 로그인하면 "Adobe Experience Manager" 이 표시됩니다.

• AEM 5.6 (2013)

  • 저자 환경을 위해 TouchUI가 도입되었습니다(아직도 클래식UI를 사용하는 애플리케이션이 얼마나 많은지 알고 계십니까?).
  • 모바일 사이트 및 앱 지원
  • 향상된 개인화 및 타겟팅
  • 비디오 프로필로 향상된 DAM

• AEM 6.0 (2014)
  AEM 6은 AEM의 기반이 되는 많은 부분을 크게 재구성한 버전입니다. CQ5 -> AEM6 마이그레이션은 매우 노동 집약적인 작업이었기 때문에 대부분의 시간을 할애했습니다.

  • AEM 6는 기본 리포지토리를 Apache Jackrabbit에서 Apache Oak로 전환했기 때문에 대규모 마이그레이션이 필요했습니다.
  • CQ의 액티브-액티브 클러스터링은 더 이상 사용할 수 없지만 Adobe는 이론적으로(현재 시점에서는 매우 이론적으로) 수평적으로 확장된 AEM 작성자를 제공할 수 있는 AEM용 MongoMK 스토리지 백엔드를 도입했습니다. 그러나 버그가 매우 많았고, 이를 구현한 유일한 방법은 결국 재앙으로 끝나고 TarMK 단일 작성자로 전환하는 것이었습니다.
  • 대부분의 페이지에 더 큰 TouchUI 공간 제공
  • 자산용 스마트 태그

• AEM 6.1 (2015)

  • 많은 버그가 수정되었지만 6.1 버전은 여전히 안정적인 버전은 아니었습니다.
  • 6.1에 등장한 베니티 URL 지원
  • 개인화를 위한 컨텍스트허브
  • 모바일 앱 SDK
  • AEM 커뮤니티와 함께 사용자 제작 콘텐츠를 위한 다양한 인프라 및 스토리지 옵션이 도입되었습니다. 시간이 지남에 따라 개선이 이루어지겠지만 안타깝게도 클라우드 서비스로의 이전에는 적용되지 않습니다.
  • AEM 데스크톱 앱이 6.1용으로 출시되었는데, 이 앱으로 작성자 환경을 100% 디도스 공격했습니다 :(

• AEM 6.2 (2016)

  • 더 많은 버그 수정과 안정성 개선 - 여전히 특별히 안정적인 버전은 아니지만 6.1이나 6.0보다 훨씬 개선되었습니다.
  • 광범위한 콘텐츠 조각 도입(이전에는 기능 팩을 통해 수행할 수 있었지만 이제는 제품의 일부로 제공됨)
  • AEM 내부의 SSL 지원
  • 탐색이 사이드 레일에서 상단으로 이동하는 등 현재 익숙한 방식으로 UI가 변경됩니다.

• AEM 6.3 (2017)

  • 핵심 구성 요소는 "생산 준비 완료" 로 소개됩니다.
  • 6.3의 대규모 기본 스토리지 개선으로 마침내 매우 안정적인 첫 번째 AEM 6 릴리스가 되었습니다. 이를 위해 datastore 과 segmentstore 을 분리하고 온라인 버전 관리를 위한 안정적인 메커니즘(타르 압축)을 도입했습니다.
  • 경험 조각이 소개됩니다.
  • 싱글 페이지 편집기(SPA)는 단일 페이지 앱을 위해 도입되었습니다.
  • "Adobe Sensei" 는 (당시로서는) 매우 획기적인 AI 기능을 갖춘 Adobe의 AI 브랜드인 AEM Assets에 스며들기 시작했습니다. 스마트 자르기, 스마트 태그 지정 등이 에셋에 적용되었습니다.

• AEM 6.4 (2018)

  • 6.4는 업그레이드를 더 쉽게 하고 궁극적으로 Cloud 서비스로의 전환을 위한 기반을 마련하기 위해 설계된 "리포지토리 구조 개편(" )의 첫 번째 라운드였습니다.
  • TouchUI로 이동한 워크플로
  • 번역 서비스에 대한 여러 가지 개선 사항
  • 자산의 비디오 스마트 자르기

• AEM 6.5 (2019)

  • 많은 리포지토리 구조 조정
  • 연결된 자산은 원격 자산 환경을 별도의 AEM Sites 환경에 연결할 수 있는 잠재적인 옵션을 제공했습니다. 하지만 이미지에 대해서만 작동합니다.
  • SPA 편집기 대폭 개선
  • 커머스용 GraphQL
  • 또한 6.5가 출시된 지 6년(지금까지 출시된 AEM/CQ 버전 중 가장 오래되었습니다!)이 지났기 때문에 서비스 팩을 통해 수많은 새로운 기능이 출시되었습니다. 현재 서비스팩 23을 사용 중이며, 2019년 이후 출시된 모든 새로운 기능에 대한 롤업은 별도의 블로그 포스팅을 통해 소개할 가치가 있습니다.

• 클라우드 서비스로서의 AEM(2020)
  적응() 2019에서 처음 소개되었습니다(당시에는 대부분 우리가 실제로 무엇을 보고 있는지 몰랐습니다!). 클라우드 서비스로서의 AEM은 2020년 1월에 전 세계에 출시되었으며, 2020년에 오프라인 Adobe Summit이 있었다면 Adobe Summit 2020의 중심 무대에 올랐을 것입니다. 안타까운 점이 더 있습니다. 클라우드 서비스로서의 AEM은 AEM & CQ의 오랜 단점을 해결하기 위해 만들어졌으며, 다양한 성공을 거두어 오늘날의 AEM 제품 환경이 만들어졌습니다. 제공하는 것은 다음과 같습니다:

  • 클라우드의 전체 서비스 기반 AEM 환경
  • 작성자 & 게시자 계층에서 자동 크기 조정
  • 기본 제공 CDN
  • 마이크로서비스 기반 자산 수집 엔진으로 대규모로 업데이트된 워크플로 & 데이터 수집 기능
  • AI 강화(RAG 기반)검색이 포함된 새로운 검색 기능이 방금 출시되었습니다 & 적응()에서 이야기했습니다.

• AEM 6.5 LTS
  엔지니어링 또는 마케팅 담당자에 따라 "AEM 6.6" 또는 "AEM 6.5 LTS" 로 다양하게 명명되는 6.5 LTS는 2025년 이후에도 AEM 6.5 워크로드를 계속 자체 호스팅하거나 AMS 호스팅할 계획이 있는 사용자를 위한 장기적인 옵션입니다. Java 11은 곧 수명이 종료될 예정이므로 Java 17 또는 Java 21에서 AEM을 실행하는 것이 유일한 옵션입니다.
  
  이것은 확실히 2009년에 출시된 정식 제품의 마지막 남은 진정한 후속 제품입니다. /crx/packmgr 및 /crx/de, /etc/replication.html 등)은 원래 CQ5 출시 당시와 거의 동일합니다.

• 엣지 전송 서비스 & DA
  AEM의 미래는 어떻게 될까요? 아마도 기능적으로나 정신적으로( "정신적으로" ) AEM의 후속 버전은 전달 계층의 Edge Delivery Services와 콘텐츠 관리 및 작성자 지원 계층의 문서 작성기능이 될 것입니다. 이는 논쟁의 여지가 있지만, DA는 향후 몇 년 동안 AEM이 나아갈 방향에 대해 매우 강력한 사례를 제시합니다.

저자 소개

들으신 내용이 마음에 드시나요? 어떤 것이 적합한지 궁금한 점이 있으신가요? 상담하고 싶어요! 문의하기

더 많은 AEM 관련 문서