이 문서에서는 Adobe Developer App Builder를 통해 Adobe Commerce의 확장성을 재고하고, 사용자 정의 PHP 코드의 상당 부분을 확장성이 뛰어난 아키텍처로 대체함으로써 확장성, 안정성, 유지 관리성을 개선하고, 실제 프로덕션 환경에서 장기적인 성장을 지원하는 방법을 설명합니다.

소개

수년간 PHP 확장성은 Adobe Commerce 사용자 정의의 핵심 기반이었습니다. 하지만 클라우드 네이티브 아키텍처가 성숙해짐에 따라 더 나은 대안들도 등장하고 있습니다. 최근 유럽의 주요 모빌리티 및 금융 서비스 제공업체를 위한 구현 사례에서 기존 Adobe Commerce 모듈 개발 방식의 상당 부분을 Adobe의 클라우드 네이티브 확장 플랫폼인 App Builder로 대체했습니다. 이를 위해 런타임 액션(서버리스 함수), 이벤트 및 API를 활용하여 확장성과 유지 관리성이 뛰어난 솔루션을 제공했습니다. 이 문서에서는 이러한 결정의 배경, 아키텍처 구조 및 얻은 교훈을 자세히 살펴봅니다.

개요

Adobe Commerce에서 API 우선 접근 방식을 점진적으로 도입하려면 핵심 Adobe Commerce 플랫폼 외부에서 클라우드 네이티브 앱으로 실행할 때 가장 유익한 기능이 무엇인지 평가하고 해당 기능을 먼저 마이그레이션해야 합니다.

이 프로세스를 통해 다음과 같은 명확한 결과가 도출되었습니다.

• 기능의 약 70%는 App Builder를 사용하여 구현되었습니다.

• 나머지 30%는 Adobe Commerce PHP 기반의 기본 사용자 정의 기능으로 남았습니다.

이러한 균형을 통해 기본 로직과 결제 관련 로직은 Commerce에 가깝게 유지하면서, 통합, 유효성 검사, 백그라운드 처리 및 오케스트레이션은 확장성, 격리성 및 배포 유연성이 뛰어난 App Builder로 옮길 수 있었습니다.

결과로 생성되는 아키텍처(아래 다이어그램 참조, App Builder 확장 기능만 표시)는 이러한 하이브리드 접근 방식을 반영합니다. Adobe Commerce는 여전히 트랜잭션 코어 역할을 하고, App Builder는 통합 및 자동화의 기반 역할을 합니다. 이 전략은 이벤트 기반 흐름과 API Mesh(Adobe의 API 오케스트레이션 서비스)를 통해 ID(SSO), PIM, ERP, 타사 서비스 및 사용자 정의 비즈니스 로직을 연결합니다.

아키텍처 둘러보기: 하이브리드 모델 작동 방식

솔루션의 핵심에는 카탈로그, 가격, 장바구니, 결제 및 주문 처리와 같은 Adobe Commerce가 있습니다. Commerce 런타임 내에서 불필요한 사용자 정의를 피하고 트랜잭션 코어를 깔끔하고 안정적으로 유지했습니다.

핵심 기능과 관련된 모든 것, 즉 신원 확인, 데이터 유효성 검사, 가용성 로직, 백그라운드 처리 및 타사 통합은 App Builder와 Adobe API Mesh를 통해 처리됩니다.

쇼핑 경험은 새로운 Commerce Storefront(Edge Delivery Services 기반)를 기반으로 구축됩니다.

1. 진입 레이어: CDN, Commerce Storefront 및 ID 확인

일반 웹 사이트 방문자의 모든 트래픽은 먼저 CDN + Edge Delivery Service를 거치게 되며, 이를 통해 요청이 백엔드 시스템에 도달하기 전에 최적의 성능, 보안 및 글로벌 전송이 보장됩니다.

인증은 Keycloak SSO를 통해 처리되며, 다음을 통해 통합됩니다.

• App Builder SSO 통합

• 마켓플레이스에서 제공되는 핵심 SSO 구성 및 설정을 위한 표준 Adobe Commerce PHP 모듈

• 이 설정을 통해 플랫폼 안정성과 클라우드 네이티브의 유연성을 결합할 수 있습니다.

이 접근 방식의 주요 이점

• 검증된 마켓플레이스 모듈을 통한 중앙 집중식 ID 관리

  SSO 구성, 사용자 매핑 및 핵심 인증 흐름을 위해 지원이 잘 되는 Adobe Commerce 확장 프로그램을 사용하므로 Commerce 런타임 내부에 사용자 정의 인증 로직을 유지 관리할 필요가 없습니다.

• 최소한의 수정으로 최대한의 안전성 확보

  SSO 모듈을 다시 작성하거나 포크하는 대신, App Builder를 통해 작고 특정 목적에 맞는 확장 기능만 적용하여 원래 모듈의 업그레이드 가능성을 완벽하게 유지합니다.

• API 우선 통합 모델

  모든 통신은 SSO API에만 의존하므로 PHP 모듈의 내부 구현 세부 사항과 분리되어 있습니다. 모듈 내부가 변경되더라도 API 계약이 유효한 한 통합은 안정적으로 유지됩니다.

2. 오케스트레이션 레이어: Adobe API Mesh

통합 아키텍처의 핵심에는 플랫폼에 관련된 모든 비즈니스 시스템 간의 중앙 오케스트레이션 및 통신 허브 역할을 하는 Adobe API Mesh가 있습니다.

• Commerce Storefront(프런트엔드)

• Adobe Commerce

• PIM

• ERP

• 외부 유효성 검사 서비스

• 및 모든 App Builder 애플리케이션

EDS 프론트엔드 또는 Adobe Commerce가 각 시스템과 직접적인 지점 간 통합을 구축하는 대신, 모든 통신이 API Mesh를 통해 라우팅됩니다.

Adobe API Mesh 사용의 주요 이점

• 단일 통합 지표
  시스템은 오직 하나의 백엔드 통합 엔드포인트인 API Mesh만 '인식'하면 됩니다. 모든 외부 종속성은 통합 API 게이트웨이 뒤에 숨겨져 있습니다.

• 일관된 API 계약
  모든 시스템은 잘 정의되고 버전 관리된 계약을 통해 통신하므로, 숨겨진 결합을 제거하고 주요 변경 사항으로 인한 위험을 크게 줄일 수 있습니다.

• 백엔드 시스템 간의 완전한 디커플링
  PIM, ERP, 유효성 검사 서비스 및 App Builder 앱은 서로 완전히 독립적으로 분리되어 있습니다. 모든 시스템은 전체 시스템 구성에 변화를 강요하지 않고 독립적으로 진화할 수 있습니다.

• 중앙 집중식 보안 및 거버넌스
  인증, 권한 부여 및 트래픽 제어는 여러 개별 통합에 분산되지 않고 Mesh 수준에서 적용됩니다.

• 간소화된 Commerce 코드베이스
  Adobe Commerce 또는 프론트엔드에 더 이상 복잡한 통합 로직을 포함할 필요가 없습니다. Mesh에 의해 노출된 API만 사용하여 PHP 계층을 가벼운 트랜잭션 중심 구조로 유지합니다.

3. Storefront 및 SSO 계층에서 사용하는 App Builder 서비스

이러한 서비스는 Adobe Commerce가 아닌 Commerce 상점 및 SSO 계층에서 직접 사용하므로, 중요한 비즈니스 로직이 Commerce 런타임과 독립적으로 작동하게 합니다.

고객 데이터 수신기(SSO → App Builder)

이 서비스는 상점 또는 Commerce 성능에 영향을 주지 않고 SSO 계층에서 고객 데이터를 수신하고 동기화합니다. App Builder을 사용하면 안전한 데이터 처리, 비동기 확장성을 확보할 수 있으며, Adobe Commerce에 대한 배포 의존성을 갖지 않습니다.

고객별 제품 가용성(Storefront → App Builder → PIM)

요청이 Commerce에 도달하기 전에 고객 컨텍스트 및 PIM 데이터를 기반으로 제품 가용성이 실시간으로 산출됩니다. App Builder를 통해 해당 로직을 독립적으로 확장할 수 있으며 과도한 외부 연동 부하로부터 Commerce을 보호합니다.

회사 데이터 유효성 검사(Dun & Bradstreet)(Storefront → App Builder → 서드파티)

유효성 검사는 App Builder + API Mesh를 통해 상점에서 직접 트리거되고 제3자 서비스를 사용하여 검증되므로 외부 서비스의 지연 및 오류를 Adobe Commerce로부터 완전히 격리할 수 있습니다.

외부 ID 리디렉션 엔진(Storefront → App Builder)

외부 시스템의 인바운드 트래픽은 상점에 들어가기 전에 App Builder을 통해 처리 및 매핑되므로, 안전한 트래픽 표준화, 유연한 리디렉션 규칙 및 Commerce 코어에 대한 위험 요소를 차단할 수 있습니다.

4. Commerce Storefront Prerendering: UX를 저해하지 않는 SEO

AEM Commerce Storefront는 JavaScript를 주로 사용하여 브라우저에 제품 데이터를 로드하는 최신 프론트엔드 기반 애플리케이션입니다. 이는 탁월한 사용자 경험을 제공하지만, 전형적인 SPA 과제를 야기합니다.

검색 엔진 크롤러 및 브라우저가 없는 시스템은 JavaScript을 안정적으로 실행하지 않으므로, 거의 비어 있는 HTML을 받는 경우가 많습니다.

이 문제를 해결하기 위해 App Builder 기반의 Adobe 공식 솔루션인 AEM Commerce Prerendering을 구현했습니다.

아키텍처의 프리렌더링 작동 방식

App Builder 프리렌더 애플리케이션:

• Adobe Commerce 카탈로그 서비스에서 제품 데이터를 직접 조회

• 사전 정의된 템플릿을 기반으로 완전 하이드레이션된 HTML 페이지 생성

• 프리렌더링된 출력을 자체 blob 저장소에 저장합니다

그런 다음 Commerce Storefront는 해당 스토리지를 오버레이 소스로 사용하도록 구성됩니다. 다음 중 하나의 경우:

• 검색 엔진 웹 크롤러

• 브라우저가 없는 클라이언트가 제품 URL을 요청하는 경우

JavaScript를 실행하지 않고 실제 제품 데이터가 포함된 완전한 HTML 응답을 즉시 수신합니다.

이와 동시에:

• 일반 사용자에게는 기존 SPA 환경이 유지되며, 브라우저에서 PDP가 실시간 렌더링됩니다.

App Builder가 핵심 기반 기술인 이유

App Builder은 전체 프리렌더링 프로세스를 위한 중앙 제어 평면 역할을 합니다. 이를 통해 다음을 정의할 수 있습니다.

• 데이터 가져오기 빈도

• 포함되는 제품 및 로케일

• HTML 및 JSON-LD 구조

• SEO 메타데이터 생성

이 모든 사항은 메인 상점 또는 Adobe Commerce의 다운타임 없이 App Builder의 간단한 구성 변경을 통해 조정할 수 있습니다.

또한 Adobe는 App Builder 애플리케이션 프리렌더링용 스타터 키트를 제공하므로, 매우 짧은 시간 내에 솔루션을 운영 환경에 적용할 수 있으며 즉각적인 SEO를 개선 효과를 얻을 수 있습니다.

해당 접근법의 주요 이점

• 대규모 SEO 개선
  크롤러는 빈 HTML 대신 구조화된 데이터가 포함된 완전히 렌더링된 제품 페이지를 수신합니다.

• 상점 성능 저하 없음
  일반 사용자는 기존처럼 빠르고 동적인 SPA 환경을 유지합니다.

• 위험이 없는 배포 모델
  모든 프리렌더링 로직이 Adobe Commerce 및 상점 런타임 외부에서 실행됩니다.

• App Builder을 통한 전체 제어
  플랫폼을 재배포하지 않고 프리렌더링 규칙, 데이터 모델 및 일정을 조정할 수 있습니다.

5. 주문 및 ERP 동기화: 비동기 방식 설계

체크아웃 및 주문 처리는 데이터 무결성과 트랜잭션 일관성을 유지하면서 Adobe Commerce 내에서 전적으로 처리됩니다. 주문이 생성되면 App Builder에 구축된 전용 예약 주문 익스포터가 내보내기 프로세스를 수행합니다.

이 익스포터는 상점 및 Commerce 요청 라이프사이클 외부에서 주문을 ERP에 비동기적으로 동기화합니다.

해당 접근법의 주요 이점

• 상점 가동 시간과 ERP 가용성의 완전한 분리
  ERP가 느리거나 일시적으로 사용할 수 없는 경우에도 고객은 중단 없이 주문을 계속할 수 있습니다.

• 다운스트림 오류로 인한 체크 아웃 중단 방지
  주문 생성이 더 이상 실시간 ERP 응답에 의존하지 않으므로 주요 전환 위험 요소가 제거됩니다.

• 안전한 재시도 및 제어된 데이터 흐름
  App Builder을 사용하면 Commerce 성능에 영향을 주지 않고 예약 실행, 재시도 메커니즘 및 오류 처리를 수행할 수 있습니다.

• 독립적인 확장 및 배포
  주문 동기화는 Adobe Commerce를 재배포하거나 시스템 성능에 영향을 주지 않고 처리량을 기준으로 동기화를 확장할 수 있습니다.

App Builder로 완전히 이동하지 않는 이유는 무엇입니까?

가장 초기의 중요한 아키텍처 결정 중 하나는 App Builder를 PHP 모듈의 완전한 대체제로 취급하지 않으면서, '늘 해오던 방식'이라는 이유로 모든 것을 PHP로만 처리하려 하지 않은 것입니다.

대신, 모든 요구 사항은 다음과 같이 간단한 필터를 거쳤습니다.

PHP에 남아 있는 항목(30%)

PHP 사용자 지정은 해당 항목이 가장 적합한 위치에서만 수행되도록 유지했습니다.

• 체크아웃 및 주문 배치 조정

• 가격 책정, 장바구니 및 견적 로직

• 심층 GraphQL 및 성능 민감형 훅

• 지연 시간이 거의 0에 가깝고 완전히 동기화되어야 하는 영역

이 영역들은 직접적인 데이터베이스 액세스, Commerce 내부와의 긴밀한 연결 및 요청 수명주기 제어가 반드시 필요한 위치입니다.

App Builder로 이동한 항목(70%)

다른 모든 기능은 이전되었습니다.

• ID 및 SSO 오케스트레이션

• 고객 및 회사 유효성 검사

• 제품 가용성 판단

• 외부 시스템 조정

• ERP 및 제3자 통합

• 엔진 및 자동화 리디렉션

• 백그라운드 작업 및 스케줄러

이 영역들은 역사적으로 PHP 모듈의 취약점이 보이는 분야입니다.

• 긴밀한 연결

• 까다로운 배포

• 빈약한 실패 격리

• 및 제한된 확장성

개선 사항 이점

비즈니스 및 통합 로직의 약 70%를 App Builder로 전환함으로써 플랫폼의 구축, 배포 및 운영 방식을 근본적으로 변경했습니다. 그 영향은 아키텍처 품질 향상뿐만 아니라 게재 속도, 시스템 안정성, 장기적 비용 관리 측면에서도 가시적인 성과로 나타났습니다.

독립 배포

대부분의 통합 및 비즈니스 워크플로를 App Builder에서 처리하므로, 이제 대부분의 변경 사항을 위해 더 이상 Adobe Commerce 전체를 재배포할 필요가 없습니다. 통합 업데이트, 유효성 검사 및 백그라운드 프로세스를 독립적으로 배포할 수 있으므로, 다음 작업을 크게 줄일 수 있습니다.

• 릴리스 위험

• 배포 윈도우

• 팀 간 조율 비용

이것만으로도 일상적인 운영에서 가장 큰 생산성 향상을 끌어낸 가장 큰 요인이 되었습니다.

핵심 영역에서 확장성 강화

기존에는 다음 작업에서 트래픽이 급증했습니다.

• 가용성 확인

• 회사 유효성 검사

• 또는 외부 API 호출

이는 Commerce 성능에 직접적인 영향을 줍니다.

이제 이러한 워크로드는 App Builder에서 독립적으로 확장됩니다. 그 결과는 다음과 같습니다.

• 안정적인 체크아웃 성능 유지

• Commerce 리소스는 트랜잭션 워크로드에만 할당됩니다.

• 예측 불가능한 제3자 트래픽이 더 이상 전환율에 영향을 주지 않습니다

완벽한 장애 격리

가장 중요한 개선 사항 중 하나는 장애 억제입니다. 제3자 시스템에서 지연, 성능 저하 또는 중단이 발생하는 경우.

• App Builder가 해당 영향을 완화합니다

• 이곳에 재시도 및 폴백 로직이 적용되고

• Adobe Commerce은 영향 없이 완벽하게 운영됩니다

이를 통해 이전에 부분적 또는 전체 상점 다운타임을 야기했던 일련의 사고 시나리오를 효과적으로 제거했습니다.

코드 소유권 정립 및 권한 명확화

이제 플랫폼은 명확한 아키텍처 경계를 가지고 있습니다.

• Adobe Commerce → 트랜잭션 로직, 체크아웃, 가격 책정, 장바구니

• App Builder → 통합, 오케스트레이션, 유효성 검사, 백그라운드 작업

이 분리는,

• 새로운 개발자의 온보딩을 간소화함

• 팀 간 의존성 감소

• 또한 복잡한 통합 로직을 포함한 커스텀 코드로 인해 Commerce 코어가 점진적으로 악화되는 것을 방지합니다.

미래를 대비하는 설계

이 하이브리드 아키텍처는 Adobe의 장기적인 SaaS, API 우선 및 구성 가능한 커머스 전략과 완벽하게 부합합니다. 대부분의 커스텀 로직을 외부화하여,

• 플랫폼 업그레이드가 더욱 안전해짐

• 코드 수준에서의 공급업체 고정이 감소

• 또한 솔루션은 Adobe Commerce as a Cloud Service으로 전환할 수 있는 준비가 이미 되어 있습니다

당사는 당면한 요구 사항만 해결한 것이 아니라, Adobe Commerce의 발전하는 모습에 맞춰 구조적으로 준비된 플랫폼을 구축했습니다.