참조 아키텍처

여기 소개하는 것은 권장 구성이며 고객 사례가 아닙니다. 가장 가까운 패턴을 골라 상황에 맞게 조정하세요.

1. 멀티 브랜드 그룹

브랜드 웹사이트를 여러 개 보유하고 각각 자체 팀을 둔 지주회사.

Organization: Group
├── Site: brand-a   (Development, Production)   editors: Brand A team
├── Site: brand-b   (Development, Production)   editors: Brand B team
└── Site: brand-c   (Development, Production)   editors: Brand C team
Approvers: group digital team (organization admins) + one reviewer per brand

• 조직 하나, 브랜드마다 사이트 하나. 콘텐츠, 미디어, 토큰, 사람은 사이트 간에 절대 넘나들지 않습니다.
• 각 브랜드는 자체 컴포넌트와 디자인 토큰이 있는 자체 웹사이트 코드와 계약을 유지합니다. Atlas는 공유 디자인을 강제하지 않습니다.
• 브랜드 편집자는 자기 사이트에서만 역할을 갖습니다. 그룹 디지털 팀이 프로덕션 릴리스를 승인합니다.
• 각 웹사이트에는 자체 전달 토큰과 웹훅이 있어, 한 브랜드의 배포나 장애가 다른 브랜드에 영향을 주지 않습니다.

2. 규제 대상 또는 승인이 많은 기업

금융, 의료, 에너지, 공공 관련 팀처럼 모든 공개 변경에 승인이 필요한 곳.

• 편집자와 마케터는 초안을 작성하고, 검토자/게시자가 개발 환경에서 게시하며, 더 작은 그룹이 프로덕션 릴리스를 승인합니다.
• 민감한 작업에는 휴대폰 승인을 켭니다.
• 모든 릴리스는 검사(계약 동기화, 게시 문제 없음, 사이트 상태, 최근 백업)를 거쳐 서명됩니다. 롤백은 한 번의 작업입니다.
• 컴플라이언스 기록을 위해 감사 로그를 내보내세요.
• 라이브 전환 전에 리드 보존 규칙에 합의하세요. 현재 보존과 CRM 전송은 개발 환경의 리드만 대상으로 한다는 점에 유의하세요.
• 서명하기 전에 호스팅 위치와 데이터 보존을 문의하여 확인하세요(보안 참고).

3. 고객 웹사이트를 운영하는 에이전시

에이전시가 여러 고객의 사이트를 구축하고 유지 관리합니다.

• 각 고객이 자신의 데이터, 사람, 요금제를 소유하도록 고객마다 조직 하나를 권장합니다. 에이전시 직원은 멤버로 초대합니다.
• 코드로 자체 컴포넌트 라이브러리를 만들어 고객별 디자인 토큰과 함께 여러 고객의 계약에 재사용하세요.
• 콘텐츠 이전에는 MCP를 통한 AI 코딩 에이전트를 사용하고, 고객의 검토자가 게시합니다.
• 인수인계가 안전합니다. 고객의 편집자는 형식 있는 필드만 바꿀 수 있고 코드는 절대 바꿀 수 없습니다.

4. 단일 기업 웹사이트

회사 웹사이트 하나, 작은 마케팅 팀, 외부 개발자.

• 조직 하나, 사이트 하나. 개발자가 웹사이트를 연결하고 계약을 한 번 작성합니다.
• 마케팅이 페이지, 뉴스, 번역을 편집하고 마케팅 책임자가 프로덕션 릴리스를 승인합니다.
• 개발자는 새 컴포넌트나 페이지 유형이 필요할 때만 필요합니다.

모든 패턴의 공통점

• 웹사이트 코드, 호스팅, 배포는 여러분이 유지합니다.
• 개발 환경 먼저, 프로덕션은 승인된 릴리스를 통해서만.
• Atlas에 연결할 수 없어도 사이트가 유지되도록 하는 내장 폴백.
• 서버의 전달 토큰은 만료되기 전에 교체합니다.