레스토랑 메뉴를 PDF로 올리지 마세요: 대신 해야 할 일

나는 "우리는 이미 메뉴를 온라인에 올렸어요!"라고 자랑스럽게 말하는 레스토랑 주인들과 몇 번을 대화했는지 셀 수 없습니다. 그리고 나서 그들은 나에게 4MB PDF 링크를 보내는데, 모바일에서는 8초가 걸리고, Google이 읽을 수 없으며, 2003년 복합기로 스캔한 것처럼 보입니다.

알겠습니다. 당신은 아름답게 디자인된 인쇄 메뉴에 좋은 돈을 썼습니다. PDF를 업로드하는 것이 쉬운 승리처럼 느껴집니다. 하지만 이것은 당신의 사업에 적극적으로 해를 끼치고 있습니다. 매일 잠재적 고객들이 휴대폰에서 애피타이저 섹션을 확대해서 읽을 수 없어서 당신의 사이트를 나가고 있습니다. Google은 당신의 요리를 제대로 색인할 수 없습니다. 그리고 가격을 업데이트하거나 계절 요리를 제거해야 할 때? 당신은 InDesign으로 돌아가서 다시 내보내고, 다시 업로드하고, 링크를 깨뜨리지 않았기를 바랍니다.

더 나은 방법이 있습니다. 그리고 그것은 그렇게 어렵지도 않습니다.

레스토랑 메뉴를 PDF로 올리지 마세요: 대신 해야 할 일

목차

PDF 메뉴가 레스토랑에 나쁜 이유

솔직히 말하겠습니다. PDF 메뉴는 "웹사이트를 갖는다"는 것이 몇 개의 정적 페이지를 붙이고 끝내는 시대의 유물입니다. 실제로 뭐가 문제인지 알아봅시다:

모바일 친화적이지 않습니다

2025년 초 기준으로, Google의 자체 데이터에 따르면 레스토랑 검색의 약 77%이 모바일 기기에서 일어납니다. 휴대폰에서 PDF는 악몽입니다. 사용자는 확대, 축소, 옆으로 스크롤, 그리고 눈을 일일이 해야 합니다. 텍스트는 반응형이 아닙니다. 레이아웃이 맞춰지지 않습니다. 그리고 대부분의 사람들은 그냥... 나갑니다.

Google의 자체 연구에 따르면 모바일 사용자의 53%이 3초 이상 걸리는 사이트를 포기합니다. 당신의 3MB PDF 메뉴? 불안정한 셀룰러 연결에서 그 기준에 미치지 못합니다.

Google이 제대로 색인할 수 없습니다

기술적으로 Google은 PDF 콘텐츠를 크롤링할 수 있습니다. 하지만 HTML과 같은 방식으로 취급하지 않습니다. PDF 텍스트는 종종 특히 PDF가 디자인 도구에서 내보낸 경우 텍스트가 아웃라인으로 렌더링되거나 이미지에 포함된 경우 잘못 구문 분석됩니다. 텍스트를 파싱할 수 있을 때도 Google은 적절하게 구조화된 HTML 콘텐츠처럼 개별 메뉴 항목을 검색 결과에 표시하지 않습니다.

누군가 "best lobster bisque near me"를 검색할 때, 구조화된 데이터가 있는 HTML 메뉴 페이지는 표시될 실제 기회가 있습니다. 당신의 PDF? 기회가 없습니다.

업데이트하기가 번거롭습니다

계절 재료가 없어집니다. 가격이 변합니다. 새로운 요리가 추가됩니다. PDF 워크플로우를 사용하면 매 변경마다:

  1. 소스 디자인 파일 열기 (아직 있기를 바라며)
  2. 편집하기
  3. 새로운 PDF 내보내기
  4. 호스팅에 업로드
  5. URL이 변경되지 않았는지 확인
  6. CDN 캐시 지우기

데이터베이스 기반 메뉴를 사용하면, 필드의 숫자를 변경하고 저장을 누릅니다. 완료.

PDF 메뉴의 실제 비용: 숫자로

이것을 실제 데이터로 뒷받침해봅시다.

메트릭 PDF 메뉴 HTML 데이터베이스 메뉴
평균 로드 시간 (모바일, 4G) 4-8초 0.5-1.5초
Google 색인 가능성 부분적, 신뢰할 수 없음 전체, 구조화된 데이터 포함
모바일 사용성 점수 Core Web Vitals 실패 Core Web Vitals 통과
가격 업데이트 시간 15-30분 30초
접근성 (WCAG 2.1 AA) 거의 항상 실패 적절한 마크업으로 달성 가능
바운스 율 영향 모바일에서 40-60% 높음 기준
Schema.org 지원 없음 전체 Menu/MenuItem 마크업
다국어 지원 별도 PDF 필요 동적, 같은 URL

이것들은 지어낸 숫자가 아닙니다. 로드 시간 데이터는 우리가 레스토랑 사이트에서 실행한 실제 성능 감사에서 나옵니다. 바운스 율 수치는 모바일 로드 시간 영향에 대한 Google과 Akamai의 연구와 일치합니다.

레스토랑 메뉴를 PDF로 올리지 마세요: 대신 해야 할 일 - 아키텍처

데이터베이스 기반 디지털 메뉴가 실제로 어떻게 보이는지

평면 파일 (PDF) 대신에, 메뉴 데이터를 구조화된 데이터베이스에 저장합니다. 각 요리는 이름, 설명, 가격, 카테고리, 식이 태그, 이미지 URL 및 가용성 상태와 같은 필드가 있는 레코드가 됩니다.

프론트엔드는 이 데이터를 아름답고 반응형 HTML로 렌더링합니다. 결과는 디자인된 메뉴처럼 보입니다 -- 하지만 검색 가능하고, 필터링 가능하고, Google에서 색인할 수 있고, 스크린 리더로 읽을 수 있고, 몇 초 안에 업데이트할 수 있는 실시간 데이터입니다.

다음은 정신 모델입니다:

[콘텐츠 관리] → [API/데이터베이스] → [프론트엔드 렌더링] → [사용자의 브라우저]
     (직원 편집)        (구조화된 데이터)    (HTML/CSS/JS)        (빠름, 접근 가능)

이것은 모든 현대 웹 애플리케이션의 동일한 패턴입니다. 단지 메뉴에 적용된 것입니다.

디지털 메뉴를 위한 기술 스택 선택

당신은 옵션이 있습니다. 주요 접근 방식을 살펴봅시다.

옵션 1: 정적 사이트 생성기 + 헤드리스 CMS

이것은 대부분의 레스토랑을 위한 나의 추천입니다. 프론트엔드를 위해 Astro 또는 Next.js와 같은 프레임워크를 사용하고, 콘텐츠 관리를 위해 헤드리스 CMS와 짝을 이루세요.

장점: 매우 빠름 (정적 HTML), 훌륭한 SEO, 저렴한 호스팅, 비기술적 직원이 쉽게 업데이트. 단점: 초기 개발 투자 필요.

옵션 2: 메뉴 플러그인이 있는 WordPress

flavor, 레스토랑 메뉴 플러그인의 flavor-developer 에디션 같은 플러그인이 존재합니다. 간단한 설정에는 괜찮습니다.

장점: 이미 WordPress에 있다면 낮은 장벽. 단점: 플러그인 품질은 천차만별, WordPress의 성능 오버헤드, 보안 유지 부담.

옵션 3: 타사 메뉴 플랫폼

Popmenu, BentoBox, 또는 Toast와 같은 서비스는 메뉴 위젯을 당신의 사이트에 임베드합니다.

장점: 빠른 설정, 일부는 주문 포함. 단점: 데이터를 소유하지 않음, SEO 값은 그들의 도메인으로 이동 (iframe!), 월별 $100-$500+ 비용, 디자인 제어 제한.

옵션 4: 헤드리스 CMS를 사용한 커스텀 빌드

레스토랑 그룹 또는 고급 시설의 경우, 완전히 커스텀 헤드리스 CMS 설정은 데이터 모델링, 디자인, 다중 위치 관리에 대한 전체 제어를 제공합니다.

접근 방식 설정 비용 월별 비용 SEO 제어 업데이트 용이성 디자인 자유도
정적 + 헤드리스 CMS $3,000-$10,000 $0-$50 전체 우수 전체
WordPress + 플러그인 $500-$3,000 $20-$100 좋음 좋음 중간
타사 플랫폼 $0-$1,000 $100-$500 낮음 (iframe) 우수 제한됨
커스텀 헤드리스 빌드 $8,000-$25,000 $0-$100 전체 우수 전체

메뉴 데이터베이스 스키마 구축

이제 실용적으로 들어가봅시다. 여기 견고한 메뉴 데이터베이스 스키마가 어떻게 보이는지 있습니다:

// 메뉴 카테고리
interface MenuCategory {
  id: string;
  name: string;           // "Appetizers", "Entrées", "Desserts"
  slug: string;           // "appetizers"
  description?: string;
  sortOrder: number;
  image?: string;
  isActive: boolean;
}

// 메뉴 항목
interface MenuItem {
  id: string;
  categoryId: string;
  name: string;           // "Pan-Seared Diver Scallops"
  slug: string;           // "pan-seared-diver-scallops"
  description: string;    // "With cauliflower purée, brown butter, capers"
  price: number;          // 3400 (센트, 항상 돈을 정수로 저장)
  priceLabel?: string;    // "Market Price" for variable pricing
  dietaryTags: string[];  // ["gluten-free", "dairy-free"]
  allergens: string[];    // ["shellfish"]
  spiceLevel?: number;    // 0-3
  isAvailable: boolean;
  isNew: boolean;
  isFeatured: boolean;
  image?: string;
  sortOrder: number;
  calories?: number;
  variants?: MenuItemVariant[];
}

// 크기 옵션이 있는 항목의 경우
interface MenuItemVariant {
  label: string;          // "Small", "Large"
  price: number;
}

여기서 주목할 몇 가지 사항이 있습니다. 가격을 센트 (또는 당신의 통화의 가장 작은 단위)로 저장하세요. 부동 소수점 계산과 돈은 잘 섞이지 않습니다 -- 이것은 당신이 한 번만 배워야 할 교훈입니다. 그리고 isAvailable을 first-class 필드로 만드세요. 서빙 중 요리가 86'd될 때, 누군가는 즉시 이를 토글할 수 있어야 합니다.

헤드리스 CMS: 레스토랑 메뉴의 최적 지점

헤드리스 CMS는 당신의 주방 직원 (또는 메뉴를 관리하는 누구든)이 친화적인 관리 인터페이스를 통해 항목을 업데이트하도록 합니다, 개발자는 프론트엔드를 렌더링하는 방식에 대한 완전한 제어를 유지합니다.

2025년 인기 있는 옵션:

  • Sanity -- 커스텀 스키마, 실시간 협업, 관대한 무료 계층 (최대 월 100K API 요청)에 탁월
  • Contentful -- 더 엔터프라이즈 지향, 팀 플랜 $300/월
  • Strapi -- 오픈 소스, 자체 호스팅, 시트별 비용 없음
  • Payload CMS -- Node.js 기반, 자체 호스팅, 훌륭한 TypeScript 지원
  • Hygraph -- GraphQL 네이티브, 복잡한 메뉴 관계에 좋음

여기 메뉴 항목의 Sanity 스키마가 어떻게 보이는지 있습니다:

// sanity/schemas/menuItem.js
export default {
  name: 'menuItem',
  title: 'Menu Item',
  type: 'document',
  fields: [
    {
      name: 'name',
      title: 'Dish Name',
      type: 'string',
      validation: Rule => Rule.required()
    },
    {
      name: 'slug',
      title: 'Slug',
      type: 'slug',
      options: { source: 'name' }
    },
    {
      name: 'description',
      title: 'Description',
      type: 'text',
      rows: 3
    },
    {
      name: 'price',
      title: 'Price (in cents)',
      type: 'number',
      validation: Rule => Rule.min(0)
    },
    {
      name: 'category',
      title: 'Category',
      type: 'reference',
      to: [{ type: 'menuCategory' }]
    },
    {
      name: 'dietaryTags',
      title: 'Dietary Tags',
      type: 'array',
      of: [{ type: 'string' }],
      options: {
        list: [
          { title: 'Vegetarian', value: 'vegetarian' },
          { title: 'Vegan', value: 'vegan' },
          { title: 'Gluten-Free', value: 'gluten-free' },
          { title: 'Dairy-Free', value: 'dairy-free' },
          { title: 'Nut-Free', value: 'nut-free' }
        ]
      }
    },
    {
      name: 'isAvailable',
      title: 'Currently Available',
      type: 'boolean',
      initialValue: true
    },
    {
      name: 'image',
      title: 'Photo',
      type: 'image',
      options: { hotspot: true }
    }
  ]
}

비기술적 직원도 이것을 관리할 수 있습니다. 그냥 형식일 뿐입니다. InDesign 없음, PDF 내보내기 없음, FTP 업로드 없음. 우리는 정기적으로 이러한 종류의 설정을 구축합니다 -- 당신이 접근 방식을 보고 싶다면 헤드리스 CMS 개발 기능을 확인해보세요.

PDF를 통한 HTML 메뉴의 SEO 이점

여기서 온라인에서 발견되는 것을 신경 쓰는 레스토랑 주인을 위해 정말 흥미로워집니다.

개별 요리 페이지

데이터베이스 기반 메뉴를 사용하면, 선택적으로 특정 요리에 대한 개별 페이지를 만들 수 있습니다. /menu/pan-seared-diver-scallops의 페이지는 "scallops restaurant [당신의 도시]" 및 유사한 롱테일 쿼리에 대해 순위를 매길 수 있습니다. PDF로 그것을 해보세요.

로컬 SEO 신호

Google의 로컬 알고리즘은 콘텐츠 관련성에 주의를 기울입니다. 메뉴가 당신의 사이트의 HTML 텍스트일 때, Google은 당신이 특정 요리와 요리를 서빙한다는 것을 이해합니다. 이것은 "Italian restaurant near me" 또는 "where to get ramen in Austin"과 같은 검색을 위한 당신의 Google 비즈니스 프로필 관련성에 직접 피드됩니다.

페이지 속도

Core Web Vitals는 순위 지정 요소입니다. Astro 또는 Next.js로 구축된 정적 HTML 메뉴 페이지는 PageSpeed Insights에서 95+ 점수를 받을 수 있습니다. PDF 다운로드를 트리거하는 페이지? Google은 파일 다운로드에 대해 Core Web Vitals를 측정하지 않습니다 -- 그냥 더 나쁜 사용자 경험 신호를 봅니다.

레스토랑 메뉴를 위한 구조화된 데이터 및 스키마 마크업

이것은 대부분의 레스토랑이 완전히 무시하는 비결 무기입니다. Schema.org는 레스토랑과 메뉴를 위한 특정 어휘를 가지고 있습니다. 올바른 마크업이 어떻게 보이는지 있습니다:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "The Example Kitchen",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "Austin",
    "addressRegion": "TX"
  },
  "hasMenu": {
    "@type": "Menu",
    "hasMenuSection": [
      {
        "@type": "MenuSection",
        "name": "Appetizers",
        "hasMenuItem": [
          {
            "@type": "MenuItem",
            "name": "Pan-Seared Diver Scallops",
            "description": "With cauliflower purée, brown butter, and capers",
            "offers": {
              "@type": "Offer",
              "price": "34.00",
              "priceCurrency": "USD"
            },
            "suitableForDiet": "https://schema.org/GlutenFreeDiet"
          }
        ]
      }
    ]
  }
}

이 구조화된 데이터는 Google이 메뉴 항목, 가격 및 식이 편의를 이해하는 것을 돕습니다. 그것은 풍부한 결과, 지식 패널 및 Google Maps 목록에 표시될 수 있습니다. PDF로는 이것을 할 수 없습니다.

접근성: PDF 메뉴가 WCAG 표준을 실패하는 이유

접근성은 선택 사항이 아닙니다. 올바른 일을 하는 것 외에도, ADA는 레스토랑 웹사이트에 적용되며, PDF 접근성 소송은 2023년 이후 증가 추세에 있습니다.

대부분의 레스토랑 PDF는 이러한 방식으로 접근성에 실패합니다:

  • 정의된 읽기 순서 없음 -- 스크린 리더가 레이아웃을 구문 분석할 수 없음
  • 이미지로 렌더링된 텍스트 -- 디자인된 메뉴에서 흔함, 보조 기술에 완전히 보이지 않음
  • 장식 요소에 alt 텍스트 없음
  • 제목 구조 없음 -- 섹션 간 이동 방법 없음
  • 고정 폰트 크기 -- 사용자가 텍스트 크기를 조정할 수 없음

의미론적 마크업으로 구축된 HTML 메뉴 페이지는 모두 자연스럽게 처리합니다. 제목, 목록, 적절한 ARIA 레이블, 반응형 텍스트 크기 조정 -- 이것은 모두 표준 웹 개발입니다.

실제로 작동하는 디자인 패턴

내가 당신이 생각하는 것을 알고 있습니다: "하지만 내 PDF 메뉴는 아름다워 보이고 HTML 페이지는 일반적으로 보일 거야." 아니요. 현대 CSS를 사용하면 웹 메뉴를 멋있게 만들 수 있습니다.

스티키 네비게이션이 있는 섹션화된 레이아웃

탭 또는 스티키 네비 레이아웃은 사용자가 모든 것을 스크롤하지 않고도 Appetizers, Entrées, Desserts 및 Drinks 사이를 점프할 수 있게 합니다. 이 패턴 하나만으로 사용성을 드라마틱하게 개선합니다.

식이 필터 토글

Vegetarian, Vegan, Gluten-Free 등을 위한 필터 버튼을 추가하세요. 활성화되면, 일치하지 않는 항목이 희미해지거나 숨겨집니다. 이것은 PDF에서는 불가능하며 식사자들이 가장 많이 요청하는 기능 중 하나입니다.

가격 형식

단순히 "$34.00"을 요리 이름 옆에 덤프하지 마세요. 적절한 타이포그래피를 사용하세요 -- 점 리더, 오른쪽 정렬된 가격, 명확한 시각 계층. CSS Grid는 이것을 사소하게 만듭니다:

.menu-item {
  display: grid;
  grid-template-columns: 1fr auto;
  gap: 0.5rem;
  align-items: baseline;
}

.menu-item__name {
  font-weight: 600;
  border-bottom: 1px dotted #999;
}

.menu-item__price {
  font-variant-numeric: tabular-nums;
  white-space: nowrap;
}

프로그레시브 이미지 로딩

요리 사진을 포함하는 경우, 현대 이미지 형식 (WebP/AVIF), 반응형 srcset 속성 및 지연 로딩을 사용하세요. 단일 최적화되지 않은 음식 사진은 모든 성능 이득을 취소할 수 있습니다.

실제 구현 예시

여기 메뉴 섹션을 렌더링하기 위한 간단한 Astro 컴포넌트가 있습니다. 이것은 Astro 개발 프로젝트에서 우리가 구축할 종류입니다:

---
// src/components/MenuSection.astro
import { formatPrice } from '../utils/format';

interface Props {
  category: {
    name: string;
    description?: string;
    items: Array<{
      name: string;
      description: string;
      price: number;
      priceLabel?: string;
      dietaryTags: string[];
      isAvailable: boolean;
    }>;
  };
}

const { category } = Astro.props;
const availableItems = category.items.filter(item => item.isAvailable);
---

<section class="menu-section" id={category.name.toLowerCase().replace(/\s+/g, '-')}>
  <h2>{category.name}</h2>
  {category.description && <p class="section-desc">{category.description}</p>}
  
  <div class="menu-items">
    {availableItems.map(item => (
      <article class="menu-item">
        <div class="menu-item__header">
          <h3 class="menu-item__name">{item.name}</h3>
          <span class="menu-item__price">
            {item.priceLabel || formatPrice(item.price)}
          </span>
        </div>
        <p class="menu-item__description">{item.description}</p>
        {item.dietaryTags.length > 0 && (
          <div class="menu-item__tags">
            {item.dietaryTags.map(tag => (
              <span class="dietary-tag" data-tag={tag}>{tag}</span>
            ))}
          </div>
        )}
      </article>
    ))}
  </div>
</section>

이것은 빌드 시간에 순수 정적 HTML을 생성합니다. 메뉴 콘텐츠 자체에 대해 클라이언트로 배송된 JavaScript 없음. 빠름, 접근 가능, 색인 가능.

헤드리스 CMS 웹훅과 짝을 이루면, 메뉴가 업데이트될 때마다 사이트가 자동으로 재구축될 수 있습니다. 직원이 Sanity에서 가격을 변경하면, 웹훅이 빌드를 트리거하고, 새로운 메뉴는 60초 안에 라이브됩니다.

자주 묻는 질문

데이터베이스 기반 레스토랑 메뉴 웹사이트를 구축하는데 얼마나 드나요? 단일 위치 레스토랑의 경우, 헤드리스 CMS를 포함한 커스텀 빌드에 대해 $3,000-$10,000을 예상하세요. 여기에는 메뉴 시스템, 디자인 및 직원을 위한 기본 교육이 포함됩니다. 복잡한 메뉴를 가진 다중 위치 레스토랑 그룹은 $10,000-$25,000 범위에 있을 것입니다. 더 구체적인 견적은 가격 페이지를 확인하세요. 월간 호스팅 비용은 일반적으로 $50 미만입니다.

내 직원이 개발자 없이 디지털 메뉴를 업데이트할 수 있나요? 그렇습니다, 이것이 전체 포인트입니다. Sanity 또는 Strapi와 같은 헤드리스 CMS를 사용하면, 메뉴를 업데이트하는 것은 양식을 편집하고 게시를 클릭하는 것만큼 간단합니다. 코드 없음, 디자인 파일 없음, FTP 없음. 우리는 일반적으로 교육 세션과 서면 문서를 포함하므로 당신의 팀은 첫 날부터 독립적입니다.

디지털 메뉴가 내 레스토랑의 브랜드 디자인을 해칠까요? 전혀. 현대 웹 기술은 타이포그래피, 레이아웃, 색상 및 이미지에 대한 완전한 제어를 제공합니다. 당신의 웹 메뉴는 인쇄 메뉴의 미학과 완벽하게 일치할 수 있습니다 -- 단지 빠르고, 접근 가능하고, SEO 친화적일 뿐입니다. 내가 본 가장 아름답게 디자인된 레스토랑 메뉴 중 일부는 PDF가 아닌 HTML입니다.

QR 코드 메뉴는 어떻게 -- 그것을 사용해야 하나요? HTML 메뉴 페이지로 연결되는 QR 코드? 훌륭한 아이디어. PDF 다운로드로 연결되는 QR 코드? 끔찍한 아이디어. QR 코드는 단지 배달 메커니즘일 뿐입니다. 중요한 것은 사용자가 도착했을 때 무엇을 보는지입니다. 빠르고 반응형 웹 페이지는 항상 올바른 답변입니다.

디지털 메뉴가 로컬 SEO에 어떻게 도움이 되나요? Google의 로컬 검색 알고리즘은 관련성을 결정할 때 당신의 웹사이트의 콘텐츠를 고려합니다. HTML 메뉴 콘텐츠는 Google이 당신이 "wood-fired Neapolitan pizza" 또는 "dry-aged ribeye"를 서빙한다는 것을 알 수 있다는 것을 의미합니다. Schema.org Menu 마크업과 결합하면, 특정 요리가 Google Maps 결과 및 지식 패널에 나타날 수 있습니다. PDF 콘텐츠는 이 시스템에 대부분 보이지 않습니다.

여전히 메뉴를 다운로드하고 싶어하는 사람들을 위한 PDF 버전을 가질 수 있나요? 절대로. 당신은 데이터베이스에서 다운로드 또는 인쇄 목적을 위해 PDF를 자동 생성할 수 있습니다. 핵심은 PDF가 보조 출력이지, 주요 경험이 아니라는 것입니다. 많은 헤드리스 CMS 설정은 Puppeteer 또는 전용 PDF 생성 API와 같은 도구를 사용하여 인쇄 준비 PDF를 생성할 수 있습니다.

저녁 서빙 중 메뉴를 변경해야 하면 어떻게 되나요? 헤드리스 CMS를 사용하면, 변경 사항은 설정에 따라 몇 초에서 분 안에 라이브될 수 있습니다. Next.js의 ISR (Incremental Static Regeneration) 또는 온디맨드 재검증을 사용하면, 가격 변경 또는 86'd 항목 업데이트는 거의 즉시 라이브 사이트에 반영될 수 있습니다. 이것은 PDF를 다시 내보내고 업로드하는 것보다 드라마틱하게 빠릅니다.

디지털 레스토랑 메뉴를 만드는 무료 도구가 있나요? Sanity의 무료 계층 (소규모 사이트에 대해 관대함) 및 Vercel 또는 Netlify의 무료 호스팅이 있습니다. 개발 기술이 팀에 있으면, 단지 당신의 시간 비용만으로 기본 메뉴 사이트를 구축할 수 있습니다. 그러나 대부분의 레스토랑에 대해, 전문 개발 팀과 협력하는 것은 결과가 광택 있고, 접근 가능하고, 처음부터 최적화되도록 보장합니다.