SitecoreAI Deployments: 레거시에서 디커플드 아키텍처로의 전환

Source: Dev.to

Sitecore AI (XM Cloud)에서 프런트‑엔드 배포

“프런트‑엔드를 배포하는 방식은 구축하는 방식만큼 중요합니다.”

Next.js 앱을 배포하는 방식은 직접적으로 다음에 영향을 미칩니다:

• 릴리스 속도
• 개발자 경험
• 배포 속도
• 운영 위험

Sitecore AI 생태계에는 두 가지 주요 배포 모델이 있습니다:

디커플링은 단순히 아키텍처 선택이 아니라, 프런트‑엔드를 제품으로 다루는 것과 CMS의 의존성으로 다루는 것 사이의 차이입니다.

Sitecore AI에서 결합형과 분리형 배포란 무엇인가요?

1️⃣ 결합형 (Integrated) 배포

• Sitecore AI Deploy App을 통해 관리
• **백엔드(CM) + 프런트‑엔드(Next.js)**가 함께 배포됨
• 단일 파이프라인이 모든 것을 제어
• UI 변경이 발생하면 전체 배포(모놀리식)가 트리거

일반적인 흐름

Git → Deploy App → CM + Edge + Front‑end → Live

• 배포 시간: 15–30 분

2️⃣ 분리형 배포

• 백엔드와 프런트‑엔드가 독립적
• 별도의 CI/CD 파이프라인

프런트‑엔드 호스팅 옵션

• Vercel
• Netlify
• BYOF (Bring‑Your‑Own‑Frontend)

흐름

# Backend
Git → Deploy App → CM + Edge

# Front‑end
Git → Vercel/Netlify → Live

• 배포 시간:
  • 소규모 앱: 2–5 분
  • 엔터프라이즈 앱: 5–10 분

아키텍처: 결합형 vs. 분리형

1️⃣ 결합형 (통합) 아키텍처

• Sitecore Deploy App이 전체 스택을 조정합니다.
• 저장소 → Deploy App → 백엔드와 프론트엔드를 모두 빌드하고, 스키마 변경을 Experience Edge에 푸시하며, Next.js 코드를 Sitecore‑관리 렌더링 호스트에 배포합니다.

Git → Deploy App → CM + Edge + Front‑end → Live

2️⃣ 분리형 아키텍처

# Backend (Pipeline A)
Git → Deploy App → CM + Edge

# Front‑end (Pipeline B)
Git → Vercel/Netlify → Front‑end

• Monorepo: 백엔드 파이프라인은 프론트엔드 코드를 무시하고, 배포 파이프라인은 백엔드 코드를 무시합니다.
• Polyrepo: 백엔드와 프론트엔드에 별도 저장소를 사용합니다(명확한 분리를 위해 권장).

분리형 프런트엔드 호스팅의 두 가지 형태

Note: Sitecore‑Managed 옵션은 필요한 환경 변수를 자동으로 주입하지만, BYOF는 수동으로 구성해야 합니다.

Source: …

Architectural Implementation Steps

Step 1 – Establish the CMS Pipeline

1. Sitecore AI Cloud Portal에서 Deploy App을 CM 환경만 빌드하도록 구성합니다.
2. BYOF를 사용할 경우, 통합된 프런트‑엔드 렌더링 호스트 설정을 비활성화합니다.

Step 2 – Choose & Configure the Front‑end Pipeline

Note: Sitecore‑Managed 호스팅의 경우, 필요한 모든 변수는 자동으로 설정되므로 Step 3을 건너뛸 수 있습니다.

Step 3 – Map Environment Variables (BYOF only)

프런트‑엔드 호스트에 다음 변수를 수동으로 추가합니다:

Step 4 – Configure CI/CD Hooks

• GitHub Actions, Azure Pipelines, 또는 Vercel webhooks를 설정하여 main/staging 브랜치에 병합될 때 프런트‑엔드 빌드가 트리거되도록 합니다.

일반 문제 해결 체크리스트

• Frontend builds failing – 모든 필수 환경 변수가 존재하고 올바르게 범위가 지정되었는지 확인하십시오.
• Stale content on Delivery – CMS 파이프라인에서 스키마가 변경된 후 프런트‑엔드 파이프라인이 실행되는지 확인하십시오.
• Long deployment times – 프런트‑엔드 파이프라인이 실수로 전체 백‑엔드를 다시 빌드하고 있지 않은지 확인하십시오.
• Preview URL not reachable – Sitecore‑Managed 호스팅을 사용하는 경우 내부 편집만 지원한다는 점을 기억하고, 공개 프리뷰를 위해 BYOF로 전환하십시오.

TL;DR

• Coupled = 단일 파이프라인, 모놀리식 배포, 더 긴 사이클.
• Decoupled = 독립 파이프라인, 더 빠르고, 더 유연하며, DevOps 제어가 향상됨.

엔터프라이즈 팀은 프런트‑엔드를 일급 제품으로 다루고, 생산 위험을 감소시키며, 릴리스 속도를 크게 향상시키기 때문에 decoupled 모델을 표준화하고 있습니다. 🚀

시나리오

• 잘못된 editing‑host 설정으로 인해 Experience Editor가 중단됨
• FE와 Edge 간 GraphQL 스키마 불일치
• 환경 간 Environment‑variable 드리프트
• Preview와 Delivery 엔드포인트 혼동

장점과 단점

결합형 (레거시) 배포

장점

• 단순성 – Sitecore Cloud Portal에서 모든 배포를 한 화면으로 관리합니다.
• 초보자 친화적 – Sitecore AI가 Edge와 Editing Host 환경 변수 매핑을 자동으로 처리합니다.

단점

• 느린 피드백 루프 – 프런트엔드 배포가 CM 오케스트레이션을 기다리기 때문에 크게 오래 걸립니다.
• 복구 어려움 – 잘못된 프런트엔드 배포를 롤백하면 전체 CM 상태를 되돌려야 하는 경우가 많습니다.
• DevOps 제어 부족 – 프런트엔드 배포 전에 고급 CI/CD 테스트 단계(예: Playwright 또는 Cypress)를 쉽게 활용할 수 없습니다.

분리형 배포

장점

• 초고속 반복 – 프런트엔드 배포가 몇 분 안에 완료됩니다.
• 독립적인 롤백 – CMS 백엔드에 영향을 주지 않고 잘못된 UI 푸시를 즉시 되돌릴 수 있습니다.
• 보안 및 접근 – 프런트엔드 개발자는 작업에 Sitecore Cloud Portal 접근 권한이 필요 없습니다.
• 프런트엔드 배포 시간 감소 – ≈ 80 % 빠릅니다.
• 동시 FE/BE 릴리즈 가능

단점

• 수동 구성 – API 키, 웹훅, 환경 변수를 직접 관리해야 합니다.
• 두 개의 파이프라인 – DevOps 팀은 두 개의 별도 배포 스트림을 모니터링해야 합니다.

Feature Comparison

언제 디커플링이 올바른 선택이 아닌가?

• DevOps 전문 지식이 없는 소규모 팀
• POC(Proof of Concept) 또는 해커톤
• 프론트엔드 변경이 최소인 프로젝트
• 프론트엔드 팀이 없고 Experience Editor에 크게 의존하는 팀

기업이 디커플드 XM Cloud를 선호하는 이유

결합된 배포 모델은 빠른 개념 증명(POC)에는 훌륭하지만, 디커플드 아키텍처가 실제 운영 환경에서는 확실히 최고의 실천 방안입니다.

헤드리스 CMS의 핵심 약속은 민첩성입니다. 프론트‑엔드 개발자가 버튼 색상 하나를 바꾸기 위해 거대한 백‑엔드 배포를 기다려야 한다면, 헤드리스 아키텍처의 주요 이점인 릴리즈 속도, 팀 독립성, 병렬 개발을 잃게 됩니다.

배포를 디커플링하는 것은 현대 소프트웨어 엔지니어링 원칙과 완벽히 일치합니다:

• 관심사의 분리 – 전달 레이어(예: Next.js)와 저작 레이어(CM)는 서로 다른 라이프사이클을 가지며 독립적으로 성공하거나 실패해야 합니다.
• 개발자 경험 (DevEx) – 프론트‑엔드 엔지니어는 Sitecore 포털을 탐색할 필요 없이 자체 도구(Vercel, GitHub) 안에서 전적으로 작업할 수 있습니다.
• 위험 완화 – 전달 파이프라인을 격리하면 커스텀 백‑엔드 Sitecore 파이프라인에서 발생한 오류가 라이브 사이트에 중요한 UI 핫‑픽스를 배포하는 것을 방해하지 않게 됩니다.

혜택

• 배포 시간 70 % 이상 단축
• 프론트‑엔드와 백‑엔드 릴리즈 병렬 진행 가능
• 파이프라인을 정리하고 Edge 토큰을 안전하게 관리하며 프론트‑엔드가 자유롭게 동작하도록 지원

최종 생각

Sitecore AI에서 디커플링은 단순한 최적화가 아니라 사고방식의 전환입니다.

You move from:

“Front‑end as part of CMS”

to:

“Front‑end as an independent product”

공식 문서 참조

• 워크스루: BYOF(Bring Your Own Front‑end)로 헤드리스 프로젝트 설정
• Sitecore XM Cloud 배포 앱 아키텍처 및 빌드 구성