모놀리식 오버라이드에서 마이크로 프런트엔드 블록으로의 전환
Adobe Developers Blog는 2026년 9월 기고를 통해 Adobe Commerce Storefront의 커스텀 상거래 블록 구축 모델을 공개했다. 과거 Magento 환경에서는 Layout XML 설정, 복잡한 블록 클래스 상속, 템플릿 오버라이드 방식에 의존해 배포 주기가 길고 유지보수 부담이 컸다. 이번에 소개된 아키텍처는 AEM Edge Delivery Services(EDS)의 문서 기반 작성 모델과 마이크로 프런트엔드 방식의 드롭인 컴포넌트(Drop-in Components)를 결합한 컴포저블 형태다.
새로운 구조에서 장기 지원(LTS)과 핵심 비즈니스 로직의 보증 책임은 Adobe Commerce 마이크로서비스 및 드롭인 라이브러리로 이동했다. 반면 프런트엔드 개발자가 작성하는 블록(Block)은 시맨틱 HTML을 장식하는 독립 단위로 한정된다. Adobe 측은 이를 두고 레거시 프런트엔드 코드를 장기간 수정 유지하는 대신 언제든 새로 작성하거나 손쉽게 교체할 수 있는 '폐기 가능한 코드(Disposable Code)' 개념을 표방한다고 설명했다.
자유도와 생산성을 절충하는 3단계 추상화 계층
개발팀은 상거래 요구사항에 맞춰 3단계 추상화 수준(Level 0~2)을 선택하거나 조합해 블록을 구현할 수 있다. 먼저 Level 0은 개발자가 직접 GraphQL 쿼리를 작성하는 단계다. 기본 제공 스크립트의 CS_FETCH_GRAPHQL 인스턴스를 활용해 매장 컨텍스트 헤더와 고객 그룹별 가격 정책, 캐시 무효화 설정을 공유하면서 상위 API가 아직 지원하지 않는 세부 데이터를 직접 페칭한다. 단, 원시 데이터 구조를 직접 파싱해야 하는 책임이 따른다.
Level 1은 상품 탐색(Product Discovery) 등 공식 드롭인이 제공하는 공개 함수를 호출해 정제된 데이터와 필터링 일관성을 확보하는 단계다. 직접 쿼리를 관리할 필요가 없지만 드롭인 API가 반환하는 스키마 범위에 의존한다. Level 2는 드롭인 도구 패키지가 제공하는 가격 범위(PriceRange)나 이미지(Image) 같은 사전 검증 UI 컴포넌트를 직접 렌더링하는 방식이다. 디자인 토큰 상속, 통화 및 로케일 포맷, 접근성(A11y) 기준이 기본 적용되지만 컴포넌트 스펙 범위 내에서만 스타일 커스텀이 가능하다. 스키마에 필드가 누락될 경우 Level 0으로 우회하거나 App Builder를 통한 백엔드 스키마 확장으로 대응하는 탈출구를 둔다.
이벤트 버스와 비상태형 파라미터 기반의 상호작용 설계
Adobe가 예시로 제시한 '상품 비교(Product Compare)' 블록 구조는 결합도를 낮추는 프런트엔드 설계 원칙을 잘 보여준다. 이 기능은 비교 테이블을 표시하는 메인 블록과 페이지 어디에나 배치할 수 있는 하단 고정 바 블록으로 분리되어 있다. 두 블록은 직접 스크립트 참조를 주고받지 않으며, 드롭인 프레임워크가 제공하는 이벤트 버스(Event Bus)의 발행·구독(Pub/Sub) 모델을 통해 상태 이벤트를 교환한다. 이 방식은 독립 배포와 코드 격리 측면에서 마이크로 프런트엔드의 기본 원칙에 부합한다.
또한 상품 선택 상태를 로컬 스토리지나 서버 세션 대신 URL 쿼리 파라미터로 관리하도록 설계했다. 이는 사용자 간 비교 목록 공유와 북마크 저장을 손쉽게 만들고, 정적 캐싱 효율을 극대화하려는 의도다. 나아가 프런트엔드 보일러플레이트와 모델 컨텍스트 프로토콜(MCP) 기반 개발자 도구를 연계해 드롭인의 TypeScript 인터페이스를 코딩 에이전트가 학습하고 블록 코드를 보조 생성할 수 있도록 환경을 정비했다.
실무 도입 시 유의할 기술적 제약과 미검증 영역
제시된 블록 모델은 개발 생산성 측면에서 명확한 장점을 지니지만 실무 도입 시 냉정하게 따져보아야 할 기술적 제약도 존재한다. Adobe 측은 순수 클라이언트 측 자바스크립트와 CSS 데코레이터 블록만으로 구현되어 강력한 Lighthouse 점수를 유지한다고 주장했다. 그러나 원문에는 모바일 네트워크 스로틀링 환경이나 세부 코어 웹 바이탈(LCP, TBT 등)에 대한 정량적 벤치마크 지표가 공개되지 않아 실제 성능 영향은 개별 프로젝트 환경에서 직접 측정해 검증해야 한다.
상태 관리 방식 역시 엔터프라이즈 환경에서 한계를 보일 수 있다. 비교 대상 상품의 수가 급증하거나 결제·계정 등 세션 영속성이 필수적인 시나리오에서는 URL 길이 제약과 브라우저 히스토리 관리가 복잡해질 수 있다. 아울러 이 구조는 기본적으로 Adobe Commerce as a Cloud Service(ACCS)나 Adobe Commerce Optimizer(ACO), 그리고 AEM Edge Delivery Services 환경을 전제로 하므로, 추가적인 백엔드 GraphQL 스키마 확장이 필요할 경우 Adobe I/O Runtime(App Builder) 라이선스와 개발 역량이 필수로 요구된다.
프런트엔드 엔지니어링 팀을 위한 점진적 마이그레이션 제안
기존 Magento 모놀리스를 운영 중인 조직이라면 프런트엔드 전체를 즉시 전면 개편하기보다 점진적인 분리 전략을 취하는 편이 현실적이다. 드롭인 라이브러리가 기본 제공하는 카탈로그 탐색과 장바구니 기능을 먼저 검토하고, 커스텀 비즈니스 로직이 필요한 영역에 한해 Level 1(API 위임)과 Level 2(UI 재사용)를 우선 적용하는 하이브리드 접근법을 권장한다.
특히 예시로 공개된 상품 비교 기능은 현재 공식 코어 드롭인으로 번들링되어 제공되는 기능이 아니라 확장 예시 블록에 불과하다. 따라서 수천 개의 제품 속성을 다루는 대규모 카탈로그 환경에서는 클라이언트 측 브라우저 렌더링 부하와 메모리 소비량을 사전에 벤치마킹해야 한다. 공식 기능으로 지원되지 않는 비즈니스 요구사항에 대해서는 백엔드 App Builder 확장 비용과 프런트엔드 블록 유지보수 비용을 비교 검토한 뒤 아키텍처 수준을 결정해야 한다.
출처
Adobe Developers Blog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Build Your Own Commerce Storefront Block (새 창)
