Next.js를 사용한 호텔 그룹 웹사이트: 다중 자산 아키텍처

하나의 호텔 웹사이트를 관리하는 것은 간단합니다. 30개? 대부분의 팀이 수년 동안 후회할 결정을 내리기 시작하는 지점입니다. 나는 호텔 그룹이 property당 별도의 WordPress 설치를 함께 연결하고, 모놀리식 CMS 플랫폼에 페이지 빌더를 임시 방편으로 붙이고, 새로운 property 출시를 3개월 이내에 처리할 수 없는 엔터프라이즈 솔루션에 6자리 예산을 낭비하는 것을 봐왔습니다.

더 나은 방법이 있습니다. 제대로 구축된 단일 Next.js 애플리케이션은 하나의 코드베이스, 하나의 배포 파이프라인, 하나의 콘텐츠 관리 계층에서 호텔 그룹의 모든 property를 제공할 수 있습니다. 각 property는 자체 브랜딩, 자체 콘텐츠, 자체 도메인을 얻습니다. 엔지니어링 팀은 정신을 되찾습니다.

이 문서는 정확히 그 시스템을 구축하는 방법을 설명합니다. 이론이 아닙니다 — 실제 호텔 그룹 프로젝트에서 사용한 실제 아키텍처 패턴입니다.

목차

• 호텔 그룹이 통합 플랫폼이 필요한 이유
• 아키텍처 개요: 하나의 코드베이스, 많은 Property
• Next.js의 멀티 테넌시 패턴
• 호텔 그룹을 위한 Headless CMS 전략
• 공유 컴포넌트 대 Property 수준의 사용자 정의
• 예약 엔진 통합
• 도메인 라우팅 및 Property 해석
• 규모에 따른 성능
• 중앙집중식 관리 대시보드
• 배포 및 DevOps
• 실제 비용 비교
• FAQ

호텔 그룹이 통합 플랫폼이 필요한 이유

일반적인 호텔 그룹 웹사이트 상황은 다음과 같습니다: Property A는 2019년의 테마를 가진 WordPress에서 실행됩니다. Property B는 GM의 조카가 설정했기 때문에 Squarespace에 있습니다. Property C는 아무도 건드리고 싶지 않은 커스텀 PHP 사이트를 가지고 있습니다. 회사 사이트는 완전히 다른 플랫폼에 있습니다.

모든 property 업데이트에는 다른 워크플로우가 필요합니다. 브랜드 일관성은 그림의 떡입니다. SEO 전략은 공유된 권한이 없는 수십 개의 도메인 전체에 분산되어 있습니다. 회사가 새로운 편의시설 배지를 추가하거나 예약 위젯을 업데이트하기로 결정하면, 누군가는 15개의 다른 장소에서 그 변경을 해야 합니다.

비용은 계속 증가합니다:

• 유지 관리 오버헤드: 각 플랫폼에는 자체 호스팅, 보안 패치, 플러그인 업데이트가 필요합니다
• 브랜드 편차: Property는 천천히 브랜드 지침에서 벗어납니다
• 개발자 컨텍스트 전환: 팀(또는 에이전시)은 여러 플랫폼에 대한 전문 지식이 필요합니다
• 느린 property 출시: 새로운 인수는 온라인 상태가 되는 데 몇 개월이 걸립니다
• 분석 단편화: 포트폴리오 전체의 성능에 대한 통합 보기가 없습니다

중앙화된 다중 property 플랫폼은 이 모든 것을 해결합니다. 하나의 코드베이스. 하나의 배포. 하나의 CMS. Property별 콘텐츠 및 브랜딩은 별도의 코드베이스가 아닌 구성을 통해 제공됩니다.

아키텍처 개요: 하나의 코드베이스, 많은 Property

작동하는 고수준 아키텍처는 다음과 같습니다:

┌─────────────────────────────────────────────┐
│              CDN / Edge Network               │
│         (Vercel, Cloudflare, Fastly)          │
├─────────────────────────────────────────────┤
│           Next.js Application                 │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐     │
│  │ Property  │ │ Property  │ │ Property  │     │
│  │ Resolver  │ │ Theming   │ │ Content   │     │
│  │ Middleware│ │ Engine    │ │ Fetcher   │     │
│  └──────────┘ └──────────┘ └──────────┘     │
├─────────────────────────────────────────────┤
│              API Layer                        │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐     │
│  │ Headless  │ │ Booking   │ │ Media     │     │
│  │ CMS       │ │ Engine    │ │ CDN       │     │
│  └──────────┘ └──────────┘ └──────────┘     │
└─────────────────────────────────────────────┘

Next.js 앱은 렌더링 계층으로 작용합니다. 미들웨어는 어느 property가 요청되고 있는지 결정합니다(도메인, 서브도메인 또는 경로를 통해). 테마 엔진은 property 특정 스타일을 적용합니다. 콘텐츠 페처는 headless CMS에서 property 범위 콘텐츠를 가져옵니다.

모든 다운스트림 — CMS, 예약 엔진, 미디어 저장소 — property 식별자로 쿼리됩니다. 해당 식별자는 전체 시스템을 함께 묶는 스레드입니다.

Next.js의 멀티 테넌시 패턴

Next.js에는 세 가지 주요 멀티 테넌시 접근 방식이 있습니다. 각각은 트레이드오프가 있습니다.

패턴 1: 서브도메인 기반 라우팅

각 property는 서브도메인을 얻습니다: grandplaza.hotelgroup.com, seasideresort.hotelgroup.com.

Next.js 미들웨어는 요청을 가로채고, 서브도메인을 추출하고, property 구성을 해석합니다:

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
import { getPropertyByDomain } from '@/lib/properties';

export function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || '';
  const subdomain = hostname.split('.')[0];
  
  const property = getPropertyByDomain(subdomain);
  
  if (!property) {
    return NextResponse.redirect(new URL('/not-found', request.url));
  }
  
  // Inject property context into headers for downstream use
  const response = NextResponse.next();
  response.headers.set('x-property-id', property.id);
  response.headers.set('x-property-slug', property.slug);
  
  return response;
}

장점: 깔끔한 URL, 쉬운 property 격리, property가 별도의 TLD가 필요하지 않을 경우 SEO에 좋습니다.
단점: SSL 인증서 관리를 위한 와일드카드, property당 낮은 브랜드 독립성.

패턴 2: 커스텀 도메인 매핑

각 property는 자체 도메인을 가집니다: grandplazahotel.com, seasideresort.com.

대부분의 호텔 그룹이 실제로 원하는 것입니다. 미들웨어 논리는 유사하지만, 도메인 조회 테이블과 매칭하고 있습니다:

const DOMAIN_MAP: Record<string, string> = {
  'grandplazahotel.com': 'grand-plaza',
  'www.grandplazahotel.com': 'grand-plaza',
  'seasideresort.com': 'seaside-resort',
  'www.seasideresort.com': 'seaside-resort',
};

Vercel은 프로젝트별로 커스텀 도메인을 기본적으로 지원하며, Pro 플랜($20/월, 2025년 기준)에서 최대 50개 도메인을 매핑할 수 있습니다. 더 큰 포트폴리오의 경우, 엔터프라이즈 플랜은 해당 제한을 제거합니다.

장점: 전체 브랜드 독립성, 기존 도메인 equity 보존.
단점: DNS 관리 오버헤드, 더 복잡한 SSL 프로비저닝.

패턴 3: 경로 기반 라우팅

한 도메인 아래의 모든 property: hotelgroup.com/properties/grand-plaza, hotelgroup.com/properties/seaside-resort.

장점: 구현이 가장 간단하고, 통합된 도메인 권한은 SEO를 위합니다.
단점: property당 낮은 브랜드 아이덴티티, URL 구조는 회사처럼 느껴집니다.

패턴	브랜드 독립성	SEO 유연성	구현 복잡성	최적 사용
서브도메인	중간	중간	낮음	예산 친화적인 그룹
커스텀 도메인	높음	높음	중간	확립된 브랜드
경로 기반	낮음	높음 (통합)	가장 낮음	새로운 포트폴리오 사이트

우리와 협력하는 대부분의 호텔 그룹은 Social Animal의 Next.js 개발 capabilities 최종적으로 커스텀 도메인 매핑을 선택합니다. Property는 도메인에 브랜드 equity를 가지고 있으며, 마케팅 팀은 독립성을 원합니다.

호텔 그룹을 위한 Headless CMS 전략

CMS 선택은 이 아키텍처를 성패를 결정합니다. Property A의 편집자가 실수로 Property B의 콘텐츠를 수정할 수 없지만, 회사 관리자가 모든 것을 관리할 수 있는 콘텐츠 수준에서 멀티 테넌시를 지원하는 시스템이 필요합니다.

잘 작동하는 CMS 옵션

Sanity는 호텔 그룹을 위한 최고의 선택입니다. 문서 수준 권한, 커스텀 스튜디오 구성, GROQ 쿼리 언어는 property 범위 콘텐츠 검색을 매우 간단하게 만듭니다. property별 workspace 보기를 사용하는 단일 Sanity Studio를 구축할 수 있습니다. 가격은 Team 플랜($99/월, 2025년 가격)부터 시작하며, 대규모 콘텐츠 볼륨으로 잘 확장됩니다.

Contentful은 이미 그들의 생태계에 있다면 작동합니다. 그들의 space 수준 격리는 property로 잘 매핑되지만, 비용이 상당할 수 있습니다 — Premium 플랜의 각 space는 비용을 추가하며, 엔터프라이즈 규모의 호텔 그룹 요구사항에는 $2,500+/월을 찾고 있습니다.

Strapi (self-hosted)는 예산 옵션입니다. 커스텀 미들웨어와 역할 기반 액세스 제어를 사용하여 멀티 테넌시 계층을 직접 구축해야 하지만, 좌석별 라이선싱 비용은 없습니다.

우리는 headless CMS 개발 가이드에서 전체 CMS 선택 프로세스를 다룹니다.

호텔을 위한 콘텐츠 모델링

property 전체에서 작동하는 콘텐츠 모델은 다음과 같습니다:

// Sanity schema example
export const property = defineType({
  name: 'property',
  title: 'Property',
  type: 'document',
  fields: [
    defineField({ name: 'name', type: 'string' }),
    defineField({ name: 'slug', type: 'slug' }),
    defineField({ name: 'domain', type: 'string' }),
    defineField({ name: 'brand', type: 'reference', to: [{ type: 'brand' }] }),
    defineField({ name: 'location', type: 'geopoint' }),
    defineField({ name: 'theme', type: 'propertyTheme' }),
    defineField({ name: 'bookingEngineId', type: 'string' }),
  ],
});

export const room = defineType({
  name: 'room',
  title: 'Room Type',
  type: 'document',
  fields: [
    defineField({ name: 'property', type: 'reference', to: [{ type: 'property' }] }),
    defineField({ name: 'name', type: 'string' }),
    defineField({ name: 'description', type: 'blockContent' }),
    defineField({ name: 'maxOccupancy', type: 'number' }),
    defineField({ name: 'amenities', type: 'array', of: [{ type: 'reference', to: [{ type: 'amenity' }] }] }),
    defineField({ name: 'gallery', type: 'array', of: [{ type: 'image' }] }),
  ],
});

핵심 패턴: 모든 콘텐츠 문서는 property를 참조합니다. 쿼리는 항상 property로 필터링합니다. 편집자는 자신의 property의 콘텐츠만 봅니다. 회사 관리자는 모든 것을 봅니다.

공유 컴포넌트 대 Property 수준의 사용자 정의

아키텍처가 흥미로워지는 곳입니다. 80%의 컴포넌트를 property 전체에서 공유하고, 20%가 property별 사용자 정의를 허용하고 싶습니다.

테마 레이어

각 property에 대한 테마 구성을 만들어 컴포넌트 시스템에 공급합니다:

// types/theme.ts
export interface PropertyTheme {
  colors: {
    primary: string;
    secondary: string;
    accent: string;
    background: string;
    text: string;
  };
  typography: {
    headingFont: string;
    bodyFont: string;
  };
  logo: {
    light: string;
    dark: string;
  };
  borderRadius: 'none' | 'sm' | 'md' | 'lg';
  heroStyle: 'fullbleed' | 'contained' | 'split';
}

Tailwind CSS v4 (2025년 출시)는 CSS 우선 구성과 기본 theme 함수 지원으로 이를 훨씬 더 쉽게 만듭니다. 레이아웃 수준에서 CSS 커스텀 속성을 설정할 수 있으며, 모든 컴포넌트를 통해 계단식으로 내려옵니다:

// app/layout.tsx
export default async function PropertyLayout({ children }: { children: React.ReactNode }) {
  const property = await getCurrentProperty();
  const theme = property.theme;
  
  return (
    <html
      style={{
        '--color-primary': theme.colors.primary,
        '--color-secondary': theme.colors.secondary,
        '--font-heading': theme.typography.headingFont,
        '--font-body': theme.typography.bodyFont,
      } as React.CSSProperties}
    >
      <body className="font-body text-text bg-background">
        {children}
      </body>
    </html>
  );
}

컴포넌트 구성

공유 컴포넌트는 테마 토큰을 수락하고 분기 논리 없이 property별로 다르게 렌더링합니다:

// components/HeroSection.tsx
export function HeroSection({ property }: { property: Property }) {
  const heroConfig = property.theme.heroStyle;
  
  const variants = {
    fullbleed: 'h-screen w-full',
    contained: 'h-[70vh] max-w-7xl mx-auto rounded-2xl overflow-hidden',
    split: 'grid grid-cols-2 h-[80vh]',
  };
  
  return (
    <section className={variants[heroConfig]}>
      {/* Shared hero content structure */}
    </section>
  );
}

예약 엔진 통합

호텔 웹사이트는 한 가지 이유로 존재합니다: 예약을 유도하기 위해. 예약 엔진 통합은 견고해야 합니다.

대부분의 호텔 그룹은 이러한 예약 엔진 중 하나를 사용합니다: SynXis (Sabre), Pegasus, Bookassist, SiteMinder, 또는 proprietary 중앙 예약 시스템. 통합 패턴은 거의 항상 동일합니다: property 식별자, 날짜 범위, 손님 수를 예약 엔진에 전달하여 가용성을 얻습니다.

// lib/booking.ts
export async function checkAvailability({
  propertyCode,
  checkIn,
  checkOut,
  adults,
  children,
}: BookingQuery) {
  const response = await fetch(`${BOOKING_ENGINE_URL}/availability`, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${BOOKING_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      hotel_code: propertyCode,
      arrival: checkIn,
      departure: checkOut,
      guests: { adults, children },
    }),
  });
  
  return response.json();
}

예약 위젯 자체의 경우, 두 가지 옵션이 있습니다:

1. 임베드된 iframe: 예약 엔진은 임베드하는 위젯을 제공합니다. 가장 적은 작업, 가장 적은 제어.
2. API 구동 커스텀 UI: 검색 및 결과 UI를 구축하고, 예약 엔진 API를 직접 호출하고, 결제용으로만 예약 엔진에 인계합니다. 더 많은 작업, 훨씬 더 나은 UX.

옵션 2는 Next.js 아키텍처가 정말로 빛나는 곳입니다. 각 property에 기본인 것처럼 느껴지는 아름답고 빠르고 브랜드 온 예약 경험을 구축할 수 있습니다. Server Components는 가용성 데이터를 미리 페치할 수 있습니다. 예약 흐름은 도메인에 머물러 있으므로, 전환 추적 및 SEO에 더 좋습니다.

도메인 라우팅 및 Property 해석

property 해석 흐름은 빨라야 합니다. 정말 빨라야 합니다. 모든 단일 요청에서 실행됩니다.

프로덕션에서 작동하는 패턴은 다음과 같습니다:

1. Edge 미들웨어는 도메인 → property slug를 해석합니다 (메모리 내 조회, sub-millisecond)
2. Property 구성은 Vercel Edge Config 또는 Cloudflare KV를 사용하여 edge에서 캐시됩니다
3. 전체 property 데이터 (테마, 네비게이션, 푸터 콘텐츠)는 ISR을 통해 또는 캐싱과 함께 요청 시간에 한 번 빌드당 페치됩니다

// lib/property-resolver.ts
import { get } from '@vercel/edge-config';

export async function resolveProperty(hostname: string): Promise<PropertyConfig | null> {
  // First: check edge config (sub-5ms)
  const domainMap = await get<Record<string, string>>('domain-map');
  const propertySlug = domainMap?.[hostname];
  
  if (!propertySlug) return null;
  
  // Second: get full property config (cached)
  const propertyConfig = await get<PropertyConfig>(`property:${propertySlug}`);
  return propertyConfig;
}

Vercel Edge Config는 이를 위해 완벽합니다 — 읽기 지연 시간이 1ms 미만인 전 세계적으로 분산된 key-value 저장소입니다. Pro 플랜에서는 512KB 데이터까지 $0의 비용이 들며, 이는 property 조회 테이블에 충분합니다.

규모에 따른 성능

호텔 웹사이트는 중요한 특정 성능 특성을 가지고 있습니다:

• 이미지 집약적인 페이지: 객실 갤러리, property 사진, 목적지 이미지
• 계절별 트래픽 스파이크: 휴일, 컨벤션 시즌, 지역 행사
• 글로벌 관객: 어디에서나 브라우징하는 국제 여행객
• 전환 중심: 로드 시간의 모든 100ms는 예약 비용입니다

정적 생성 전략

Property 페이지에 증분 정적 재생성 (ISR)을 사용합니다. 호텔 콘텐츠는 매분 변경되지 않습니다 — 60초 재검증 기간은 보통 괜찮습니다:

// app/[propertySlug]/page.tsx
export async function generateStaticParams() {
  const properties = await getAllProperties();
  return properties.map((p) => ({ propertySlug: p.slug }));
}

export const revalidate = 60;

30개 property 그룹의 경우 property당 약 20개 페이지, 약 600개 페이지를 미리 생성하고 있습니다. Next.js는 이것을 쉽게 처리합니다. 빌드 시간은 5분 이하입니다.

이미지 최적화

Next.js Image 컴포넌트와 remote 로더는 property별 이미지 최적화를 처리합니다. Sanity를 사용하고 있다면, 자동 형식 변환 및 크기 조정을 사용하는 이미지 CDN은 탁월합니다. Cloudinary는 Plus 플랜($89/월)에서 또 다른 견고한 옵션입니다.

일반적인 호텔 property 페이지는 다음을 목표로 해야 합니다:

• 4G 연결에서 2.5초 이하의 LCP
• 0의 CLS (이미지 로드로 인한 레이아웃 이동 없음)
• 초기 로드에서 1.5MB 미만의 총 페이지 무게

중앙집중식 관리 대시보드

CMS 외에도, 호텔 그룹은 운영 대시보드가 필요합니다. 여기가 커스텀 도구를 구축하는 곳입니다:

• Property 개요: 각 property 사이트의 상태 (라이브, 스테이징, 유지 관리)
• 콘텐츠 신선도: 계절별 콘텐츠를 업데이트하지 않은 property들
• 성능 모니터링: property별 Core Web Vitals
• 분석 롤업: 모든 property의 예약 funnel 메트릭

우리는 일반적으로 이를 별도의 Next.js 앱으로 구축합니다 (종종 App Router의 서버 측 기능과 함께) 동일한 데이터 소스에 연결합니다. 관리 대시보드는 내부 도구입니다 — 화려할 필요는 없지만, 기능적이어야 합니다.

배포 및 DevOps

하나의 코드베이스는 하나의 CI/CD 파이프라인을 의미합니다. 배포 흐름은 다음과 같습니다:

1. 코드 변경: PR → 검토 → main에 merge
2. 빌드: Next.js는 모든 property에서 모든 정적 페이지를 빌드합니다
3. 배포: Vercel (또는 유사)는 edge 네트워크에 배포합니다
4. DNS: 각 property 도메인은 배포를 가리킵니다

콘텐츠 변경에는 배포가 필요하지 않습니다. Headless CMS는 webhook을 통해 ISR 재검증을 트리거합니다:

// app/api/revalidate/route.ts
export async function POST(request: Request) {
  const body = await request.json();
  const { propertySlug, contentType } = body;
  
  // Revalidate specific paths for the changed property
  revalidatePath(`/${propertySlug}`);
  
  if (contentType === 'room') {
    revalidatePath(`/${propertySlug}/rooms`);
  }
  
  return Response.json({ revalidated: true });
}

실제 비용 비교

20개 property 호텔 그룹의 실제 비용을 비교해봅시다:

비용 카테고리	별도 사이트 (WordPress)	통합 Next.js 플랫폼
호스팅 (월)	$2,000-4,000 (20 × 관리 WP)	$150-400 (Vercel Pro/Team)
CMS 라이선싱	$0-600 (site당 플러그인)	$99-300 (Sanity/Contentful)
SSL 인증서	$0-400 (Let's Encrypt를 사용하지 않는 경우)	$0 (자동 프로비저닝)
유지 관리 (연간)	$40,000-80,000 (업데이트, 보안)	$10,000-20,000
새로운 Property 출시	site당 $5,000-15,000	$500-2,000 (콘텐츠 + 구성)
연간 총 (예상)	$75,000-150,000	$15,000-35,000

숫자도 가깝지 않습니다. 그리고 이것은 개발자 경험 개선을 고려하지 않습니다 — 하나의 코드베이스를 가진 것은 팀이 실제로 시스템을 이해하는 것을 의미합니다. 더 이상 "그 property는 어느 WordPress 버전에서 실행되고 있습니까?"가 아닙니다.

호텔 그룹이 이 접근 방식을 고려하고 있다면, 우리는 Next.js 개발 capabilities를 설명했으며 더 자세한 견적을 위해 가격 구조를 볼 수 있습니다.

FAQ

호텔 그룹을 통합 Next.js 플랫폼으로 마이그레이션하는 데 얼마나 걸립니까? 10-20개 property 그룹의 경우, 킥오프에서 전체 출시까지 3-5개월을 예상합니다. 첫 번째 property는 가장 오래 걸립니다 (8-10주) 플랫폼을 구축하고 있기 때문입니다. 각 후속 property는 주로 콘텐츠 마이그레이션 및 테마 구성이며, 각각 1-2주가 걸립니다. 우리는 일반적으로 파도 단위로 출시합니다 — 한 번에 3-4개 property.

개별 property는 여전히 다른 property가 없는 고유한 페이지를 가질 수 있습니까? 절대적으로. 콘텐츠 모델은 property 특정 페이지 유형을 지원합니다. 리조트 property가 "Wedding Venues" 섹션은 필요하지만 비즈니스 호텔은 필요하지 않다면, 그것은 콘텐츠 수준 결정입니다. CMS 스키마는 선택적 페이지 유형을 지원하며, Next.js 동적 라우팅은 주어진 property에 대해 CMS에 존재하는 모든 페이지의 렌더링을 처리합니다.

새로운 호텔을 인수하고 플랫폼에 추가해야 할 때 어떻게 됩니까? 이것은 가장 큰 승리 중 하나입니다. 새로운 property를 추가하는 것은 다음을 의미합니다: CMS에서 property 항목 생성, 테마 구성 (색상, 글꼴, 로고), 도메인 매핑 추가, 콘텐츠 채우기. 유능한 콘텐츠 팀은 1-2주 내에 새로운 property를 라이브로 할 수 있습니다. 이를 독립형 웹사이트를 구축하기 위해 2-3개월과 비교합니다.

다른 국가에 있는 property에서 다중 언어 지원을 어떻게 처리합니까? Next.js는 기본 i18n 라우팅 지원을 가지고 있습니다. 지역화된 콘텐츠를 지원하는 headless CMS (Sanity 및 Contentful 모두 이를 훌륭하게 수행)와 결합하면, 관련 언어에서 각 property를 제공할 수 있습니다. 바르셀로나의 property는 스페인어, 카탈란어, 영어, 프랑스어가 필요할 수 있습니다. 마이애미의 property는 영어와 스페인어만 필요할 수 있습니다. 각 property의 언어 구성은 독립적입니다.

이 아키텍처가 Next.js 대신 Astro에서 작동합니까? 네, 그리고 일부 호텔 그룹의 경우 실제로 더 나은 선택입니다. property가 주로 콘텐츠 중심이고 최소한의 상호 작용 (예를 들어, 복잡한 예약 흐름 없음)이 있는 경우, Astro의 다중 페이지 아키텍처는 더 적은 JavaScript로 훨씬 더 나은 성능을 제공할 수 있습니다. 멀티 테넌시 패턴은 유사합니다 — 미들웨어 기반 property 해석, property 범위 headless CMS, property별 테마 토큰.

Google이 별도 도메인이지만 하나의 애플리케이션에서 제공되는 property를 처리할 때 SEO는 어떻게 됩니까? 각 property 도메인은 자체 sitemap, 자체 robots.txt, 자체 구조화된 데이터 (Hotel 스키마 마크업), 자체 메타 태그를 얻습니다. Google의 관점에서, 이들은 완전히 별도의 웹사이트입니다. 정규 URL은 각 property의 자체 도메인을 가리킵니다. 또한 중앙집중식 스키마 마크업 생성의 이점을 얻습니다 — 모든 property는 자동으로 호텔, 객실, 리뷰, 지역 비즈니스 정보에 대한 적절한 JSON-LD를 얻습니다.

스파 예약 또는 지역 활동 예약 같은 property 특정 통합은 어떻게 됩니까? 컴포넌트 아키텍처는 property 수준 통합 구성을 지원합니다. CMS의 각 property 구성은 사용하는 제3자 통합을 지정할 수 있습니다. 렌더링 계층은 조건부로 통합 컴포넌트를 포함합니다. 스파 property는 스파 예약 위젯을 얻습니다. 시내 비즈니스 호텔은 회의실 구성기를 얻습니다. 이들은 동적 가져오기로 로드되므로 그들을 사용하지 않는 property에 대한 번들 크기에 영향을 미치지 않습니다.

한 property의 트래픽 스파이크가 다른 property에 영향을 줄 위험이 있습니까? Vercel 또는 Cloudflare Pages 같은 플랫폼에서는 그렇지 않습니다. 이러한 edge 플랫폼은 트래픽 스파이크를 위해 설계되었습니다. 정적 페이지는 CDN 캐시에서 제공되므로, 한 property의 스파이크는 다른 property에 영향을 미칠 서버 리소스를 소비하지 않습니다. 동적 경로 (실시간 가용성 확인 같은)의 경우, property별 비율 제한을 원할 것이며, 한 property의 바이럴 순간이 예약 엔진 API 할당을 소모하는 것을 방지할 수 있습니다. 하지만 이것은 호스팅 문제가 아니라 API 수준 문제입니다.