솔직하게 말하자면, 2023년 클라이언트가 처음 Airtable을 CMS로 사용해달라고 요청했을 때 농담인 줄 알았습니다. 스프레드시트 앱이 프로덕션 웹사이트를 구동한다고? 하지만 이런 방식으로 반 이상의 사이트를 구축한 후 — 일부는 Astro, 일부는 Next.js — 생각이 바뀌었습니다. Airtable은 기존의 헤드리스 CMS 플랫폼이 완전히 놓치는 특정 프로젝트를 위한 완벽한 지점을 찾았습니다. 마케팅 팀은 이미 사용 방법을 알고 있습니다. 대부분의 콘텐츠를 모델링할 수 있을 만큼 유연합니다. 그리고 API는 매우 간단합니다.

하지만 예리한 모서리가 없지 않습니다. 속도 제한, 첨부 파일 처리, 관계형 데이터의 괴로움 — 2023년 "Airtable을 CMS로" 블로그 포스트가 절대 알려주지 않은 많은 것들이 있습니다. 이 가이드는 2026년 이 스택으로 실제 프로젝트를 배포하면서 배운 모든 것을 다룹니다.

목차

Airtable을 Astro & Next.js의 CMS로 사용하기 (2026)

Airtable을 CMS로 사용하는 것이 실제로 합리적인 이유

Airtable의 가장 큰 주장은 기술적이지 않습니다 — 인적 요소입니다. 콘텐츠 편집자는 이미 사용 방법을 알고 있습니다. 온보딩 마찰이 없고, 잊어버릴 새로운 로그인이 없으며, 배워야 할 콘텐츠 모델링 UI가 없습니다. 스프레드시트 같은 인터페이스를 열고 뭔가를 입력하면 웹사이트에 나타납니다.

특정 사용 사례에 진정으로 좋은 점은 다음과 같습니다:

  • 편집자를 위한 학습 곡선이 전혀 없습니다. Google Sheets를 사용할 수 있다면 Airtable을 사용할 수 있습니다.
  • 유연한 스키마입니다. 새 필드를 추가하는 데 5초가 걸립니다. 마이그레이션이나 스키마 배포가 필요하지 않습니다.
  • 내장된 보기 및 필터입니다. 편집자는 필터된 보기, 칸반 보드, 갤러리를 만들 수 있습니다 — 개발자 도움 없이 모두 가능합니다.
  • 관계형 데이터입니다. 평면 스프레드시트와 달리 Airtable은 연결된 레코드, 조회 및 롤업을 지원합니다.
  • 무료 요금제가 충분히 관대합니다. 기본 요금제에서 Base당 1,000개 레코드 및 월 1,000 API 호출. 팀 요금제 (2026년 기준 월 $20/사용자)는 50,000개 레코드와 더 높은 API 제한을 제공합니다.

포트폴리오 사이트, 이벤트 목록, 팀 디렉토리, 제품 카탈로그, 채용 게시판 및 소규모 블로그를 위한 CMS로 Airtable을 사용했습니다. 이 모든 것에서 놀랍도록 잘 작동합니다.

Airtable을 CMS로 사용하면 안 되는 경우

몇 가지 고통을 덜어드리겠습니다. 다음의 경우 Airtable을 CMS로 사용하지 마세요:

  • 10,000개 이상의 콘텐츠 레코드가 있는 경우입니다. 느려지고 API 페이지 나누기가 규모에서 실제 두통이 됩니다.
  • 내장된 컴포넌트가 있는 리치 텍스트가 필요한 경우입니다. Airtable의 긴 텍스트 필드는 기본 마크다운을 지원하지만 Sanity나 Contentful처럼 React 컴포넌트나 사용자 지정 블록을 내장할 수 없습니다.
  • 콘텐츠에 대한 세분화된 권한이 필요한 경우입니다. Airtable의 권한 모델은 레코드 단위가 아닌 Base 단위, 테이블 단위입니다. 편집자 A가 편집자 B의 초안을 보면 안 되는 경우, 고생할 것입니다.
  • 실시간 미리보기가 필요한 경우입니다. 기본 제공 초안/미리보기 워크플로우가 없습니다. 필터된 보기와 상태 필드로 해킹할 수 있지만 엉망입니다.
  • 이미지 변환이 필요한 경우입니다. Airtable 첨부 파일 URL은 임시입니다 (약 2시간 후 만료됨). 별도의 이미지 파이프라인이 필요합니다.

소규모에서 중간 규모의 콘텐츠 사이트를 벗어나면 목적에 맞게 만들어진 헤드리스 CMS가 좋습니다. 우리의 headless CMS development work에서 다룹니다.

콘텐츠를 위해 Airtable Base 설정하기

코드를 작성하기 전에 Airtable Base를 올바르게 설정하세요. 일반적인 블로그에 사용하는 구조는 다음과 같습니다:

Base 구조

Posts 테이블을 만들고 다음 필드를 추가합니다:

필드명 필드 유형 메모
Title 한 줄 텍스트 기본 필드
Slug 한 줄 텍스트 URL 안전, 소문자
Body 긴 텍스트 (마크다운) 리치 텍스트 서식 활성화
Excerpt 긴 텍스트 일반 텍스트, 1-2 문장
Published 확인란 프로덕션을 위해 이를 필터링합니다
Publish Date 날짜 이를 기준으로 내림차순 정렬합니다
Author Authors 테이블에 연결 관계형 링크
Tags 다중 선택 또는 Tags 테이블에 연결
Featured Image 첨부 파일 단일 이미지
SEO Title 한 줄 텍스트 선택적 재정의
SEO Description 긴 텍스트 메타 설명

"Published"라는 필터된 보기를 만들고 Published 확인란이 체크된 레코드만 표시합니다. 이것이 프로덕션 콘텐츠입니다.

API 설정

  1. airtable.com/create/tokens로 이동하여 개인 액세스 토큰을 만듭니다.
  2. data.records:read 범위를 지정합니다 (쓰기 액세스가 필요한 경우 data.records:write도 추가).
  3. 사용 중인 특정 Base로 범위를 지정합니다.
  4. 토큰을 .env 파일에 저장합니다. 절대 커밋하지 마세요.
# .env
AIRTABLE_TOKEN=pat_xxxxxxxxxxxxx
AIRTABLE_BASE_ID=appXXXXXXXXXXXXXX

Base ID는 Airtable API 문서나 Base를 볼 때 URL에서 찾을 수 있습니다.

Airtable을 Astro & Next.js의 CMS로 사용하기 (2026) - 아키텍처

Airtable을 Astro에 연결하기

Astro는 콘텐츠가 대부분 정적인 Airtable 기반 사이트를 위한 제 선호 프레임워크입니다. Astro는 기본적으로 정적 HTML로 빌드되므로 빌드 시 모든 Airtable 데이터를 가져오므로 방문자로부터의 API 호출이 0이고 프로덕션의 속도 제한이 걱정되지 않습니다.

Astro를 다음 프로젝트에 살펴보고 있다면, 우리는 그것에 깊은 경험이 있습니다 — Astro development services를 확인해보세요.

SDK 설치

npm install airtable

데이터 가져오기 유틸리티 만들기

// src/lib/airtable.ts
import Airtable from 'airtable';

const base = new Airtable({ apiKey: import.meta.env.AIRTABLE_TOKEN })
  .base(import.meta.env.AIRTABLE_BASE_ID);

export interface Post {
  id: string;
  title: string;
  slug: string;
  body: string;
  excerpt: string;
  publishDate: string;
  featuredImage: { url: string; filename: string } | null;
  tags: string[];
}

export async function getPosts(): Promise<Post[]> {
  const records = await base('Posts')
    .select({
      view: 'Published',
      sort: [{ field: 'Publish Date', direction: 'desc' }],
    })
    .all();

  return records.map((record) => ({
    id: record.id,
    title: record.get('Title') as string,
    slug: record.get('Slug') as string,
    body: record.get('Body') as string,
    excerpt: record.get('Excerpt') as string,
    publishDate: record.get('Publish Date') as string,
    featuredImage: record.get('Featured Image')
      ? {
          url: (record.get('Featured Image') as any[])[0].url,
          filename: (record.get('Featured Image') as any[])[0].filename,
        }
      : null,
    tags: (record.get('Tags') as string[]) || [],
  }));
}

export async function getPostBySlug(slug: string): Promise<Post | undefined> {
  const records = await base('Posts')
    .select({
      view: 'Published',
      filterByFormula: `{Slug} = '${slug}'`,
      maxRecords: 1,
    })
    .all();

  if (records.length === 0) return undefined;
  const record = records[0];

  return {
    id: record.id,
    title: record.get('Title') as string,
    slug: record.get('Slug') as string,
    body: record.get('Body') as string,
    excerpt: record.get('Excerpt') as string,
    publishDate: record.get('Publish Date') as string,
    featuredImage: record.get('Featured Image')
      ? {
          url: (record.get('Featured Image') as any[])[0].url,
          filename: (record.get('Featured Image') as any[])[0].filename,
        }
      : null,
    tags: (record.get('Tags') as string[]) || [],
  };
}

Astro 페이지에서 사용하기

---
// src/pages/blog/[slug].astro
import { getPosts, getPostBySlug } from '../../lib/airtable';
import Layout from '../../layouts/Layout.astro';

export async function getStaticPaths() {
  const posts = await getPosts();
  return posts.map((post) => ({
    params: { slug: post.slug },
  }));
}

const { slug } = Astro.params;
const post = await getPostBySlug(slug!);

if (!post) return Astro.redirect('/404');
---

<Layout title={post.title}>
  <article>
    <h1>{post.title}</h1>
    <time>{post.publishDate}</time>
    <div set:html={post.body} />
  </article>
</Layout>

그게 다입니다. astro build에서 모든 게시물이 Airtable에서 가져와 정적 HTML로 렌더링됩니다. 프로덕션 사이트는 0 API 호출을 합니다.

Airtable을 Next.js에 연결하기

Next.js는 더 많은 유연성을 제공합니다. generateStaticParams를 사용하여 빌드 시 가져오거나, 서버 컴포넌트를 사용하여 요청 시 가져오거나, ISR (증분 정적 재생성)을 사용하여 둘 다의 장점을 얻을 수 있습니다.

우리는 많은 Next.js 사이트를 구축합니다 — 그것이 우리의 주력입니다. Next.js development capabilities를 참조하세요.

가져오기 유틸리티 (Next.js 버전)

Next.js에서는 SDK보다 fetch를 사용한 Airtable REST API를 직접 사용하는 것을 선호합니다. Next.js의 fetch 확장으로 캐싱을 더 잘 제어할 수 있습니다.

// lib/airtable.ts
const AIRTABLE_TOKEN = process.env.AIRTABLE_TOKEN!;
const AIRTABLE_BASE_ID = process.env.AIRTABLE_BASE_ID!;

const headers = {
  Authorization: `Bearer ${AIRTABLE_TOKEN}`,
  'Content-Type': 'application/json',
};

export async function fetchPosts() {
  const url = new URL(
    `https://api.airtable.com/v0/${AIRTABLE_BASE_ID}/Posts`
  );
  url.searchParams.set('view', 'Published');
  url.searchParams.set('sort[0][field]', 'Publish Date');
  url.searchParams.set('sort[0][direction]', 'desc');

  const res = await fetch(url.toString(), {
    headers,
    next: { revalidate: 60 }, // ISR: 60초마다 재검증
  });

  if (!res.ok) throw new Error(`Airtable API error: ${res.status}`);

  const data = await res.json();
  return data.records.map((record: any) => ({
    id: record.id,
    title: record.fields['Title'],
    slug: record.fields['Slug'],
    body: record.fields['Body'],
    excerpt: record.fields['Excerpt'],
    publishDate: record.fields['Publish Date'],
    tags: record.fields['Tags'] || [],
  }));
}

ISR 페이지 (App Router 포함)

// app/blog/[slug]/page.tsx
import { fetchPosts } from '@/lib/airtable';
import { notFound } from 'next/navigation';

export async function generateStaticParams() {
  const posts = await fetchPosts();
  return posts.map((post: any) => ({ slug: post.slug }));
}

export default async function BlogPost({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const posts = await fetchPosts();
  const post = posts.find((p: any) => p.slug === slug);

  if (!post) notFound();

  return (
    <article>
      <h1>{post.title}</h1>
      <time>{post.publishDate}</time>
      <div dangerouslySetInnerHTML={{ __html: post.body }} />
    </article>
  );
}

revalidate: 60을 사용하면 Next.js는 캐시된 페이지를 제공하고 백그라운드에서 최대 60초마다 한 번 새로 고칩니다. 편집자가 Airtable을 업데이트하면 사이트가 분 이내에 업데이트됩니다. 웹훅 설정, 빌드 트리거 없음.

이미지 및 첨부 파일 처리

Airtable을 CMS로 사용할 때 가장 큰 주의사항입니다. Airtable 첨부 파일 URL은 만료됩니다. 이들은 대략 2시간 후에 유효하지 않게 되는 서명된 URL입니다. HTML에서 직접 렌더링하면 깨집니다.

옵션은 다음과 같습니다:

옵션 1: 빌드 시 다운로드 (Astro)

정적 사이트의 경우 빌드 중에 이미지를 다운로드하여 로컬로 제공합니다:

import fs from 'fs/promises';
import path from 'path';

async function downloadImage(url: string, filename: string) {
  const res = await fetch(url);
  const buffer = Buffer.from(await res.arrayBuffer());
  const outputPath = path.join('public', 'images', 'cms', filename);
  await fs.mkdir(path.dirname(outputPath), { recursive: true });
  await fs.writeFile(outputPath, buffer);
  return `/images/cms/${filename}`;
}

옵션 2: CDN을 통해 프록시

Cloudflare Worker 또는 Vercel Edge Function을 설정하여 Airtable 이미지 URL을 프록시하고, 캐시하고, 자신의 도메인을 통해 제공합니다. Astro와 Next.js 모두에서 작동합니다.

옵션 3: 별도의 이미지 호스트 사용

Cloudinary, Imgix 또는 S3 버킷에 이미지를 업로드하고 Airtable의 첨부 파일 필드를 사용하는 대신 영구 URL을 텍스트 필드에 저장합니다. 이것이 프로덕션 사이트에 권장하는 방법입니다 — 가장 안정적인 방법입니다.

캐싱, 속도 제한 및 성능

Airtable의 API는 엄격한 속도 제한이 있습니다: Base당 초당 5개 요청입니다. 이는 많지 않습니다. 잘 유지하는 방법은 다음과 같습니다.

전략 프레임워크 작동 방식
정적 생성 Astro 모든 API 호출은 빌드 시에 발생합니다. 런타임 호출 0.
ISR Next.js 캐시된 응답, 타이머에서 재검증.
메모리 내 캐시 둘 다 TTL이 있는 Map에서 API 응답을 캐시합니다.
웹훅 + 재빌드 둘 다 Airtable 자동화는 Vercel/Netlify 재빌드를 트리거합니다.
Redis/KV 캐시 Next.js (Vercel) Vercel KV 또는 Upstash Redis에서 API 응답을 저장합니다.

Astro 사이트의 경우 빌드 시간 방법은 배포 중에만 API에 도달함을 의미합니다. ISR을 사용한 Next.js의 경우 페이지당 재검증 간격마다 최대 한 번 도달합니다.

많은 페이지가 있고 재검증 간격이 짧으면 페이지별 API 호출을 하는 대신 한 번에 모든 레코드를 가져오고 전체 데이터 세트를 캐시하는 것을 고려하세요.

페이지 나누기가 중요합니다

Airtable은 요청당 최대 100개 레코드를 반환합니다. SDK의 .all() 메서드는 자동으로 페이지 나누기를 처리하지만 fetch를 직접 사용하는 경우 offset 토큰을 따라야 합니다:

async function fetchAllRecords(tableName: string) {
  let allRecords: any[] = [];
  let offset: string | undefined;

  do {
    const url = new URL(
      `https://api.airtable.com/v0/${AIRTABLE_BASE_ID}/${tableName}`
    );
    url.searchParams.set('view', 'Published');
    if (offset) url.searchParams.set('offset', offset);

    const res = await fetch(url.toString(), { headers });
    const data = await res.json();

    allRecords = [...allRecords, ...data.records];
    offset = data.offset;
  } while (offset);

  return allRecords;
}

리치 텍스트 및 마크다운 콘텐츠

리치 텍스트 옵션을 활성화한 경우 Airtable의 긴 텍스트 필드에 마크다운을 저장할 수 있습니다. 하지만 API에서 다시 받는 것은 마크다운으로 서식이 지정된 텍스트이지 HTML이 아닙니다.

변환해야 합니다. 간단한 경우에는 marked를 사용하거나 더 많은 제어를 위해 unified with remark 플러그인을 사용합니다:

import { marked } from 'marked';

const htmlContent = marked.parse(post.body);

Astro의 경우 기본 제공 마크다운 처리를 사용할 수도 있습니다:

---
import { marked } from 'marked';
const html = marked.parse(post.body);
---
<article set:html={html} />

주의할 점은 Airtable의 리치 텍스트 에디터가 자신의 마크다운 맛을 생성한다는 것입니다. 굵게, 기울임꼴, 링크, 제목 및 목록을 잘 처리합니다. 코드 블록과 테이블이 지원되지만 까다로울 수 있습니다. 콘텐츠가 복잡한 서식이 필요하면 편집자가 일반 마크다운 모드로 작성하도록 고려하세요.

Airtable vs 기존 헤드리스 CMS 옵션

トレードオフについて정직하게 이야기합시다. 2026년 Airtable이 목적에 맞게 만들어진 헤드리스 CMS 플랫폼과 어떻게 비교되는지 보세요:

기능 Airtable Sanity Contentful Strapi
편집자 학습 곡선 매우 낮음 중간 중간 중간
콘텐츠 모델링 유연함, 비공식 훌륭함 훌륭함 좋음
API 속도 제한 Base당 5 req/s 관대함 (CDN) 관대함 (CDN) 자가 호스팅
이미지 처리 URL 만료 기본 제공 CDN 기본 제공 CDN 자가 호스팅
미리보기/초안 수동 (확인란) 기본 제공 기본 제공 기본 제공
가격 (5명 팀) $100/mo (Team) 무료 요금제 가능 $300/mo+ 무료 (자가 호스팅)
웹훅 지원 자동화를 통해 기본 제공 기본 제공 기본 제공
리치 텍스트 품질 기본 마크다운 Portable Text 구조화됨 리치 텍스트
관계형 콘텐츠 연결된 레코드 참조 참조 관계

Airtable은 편집자 경험과 유연성에서 승리합니다. 이미지 처리, 미리보기 워크플로우 및 API 안정성 면에서는 규모에서 패합니다. 콘텐츠가 대부분 정적인 소규모에서 중간 규모의 사이트로, 편집자가 이미 Airtable에 있는 경우? 견고한 선택입니다. 콘텐츠가 많은 사이트에서 복잡한 워크플로우가 필요한 경우? 실제 CMS로 이동합니다.

실제 아키텍처 패턴

프로덕션에서 사용한 패턴은 다음과 같습니다:

패턴 1: Astro와 재빌드 웹훅을 사용한 완전 정적

최적 대상: 마케팅 사이트, 포트폴리오, < 500개 레코드의 디렉토리.

  1. Astro는 빌드 시 모든 Airtable 데이터를 가져옵니다.
  2. Airtable 자동화는 레코드 업데이트 시 Vercel/Netlify에 웹훅을 보냅니다.
  3. 사이트가 30-60초 내에 재빌드됩니다.
  4. 이미지가 빌드 시 다운로드됩니다 — URL 만료 문제 없음.

패턴 2: Next.js를 사용한 ISR

최적 대상: 블로그, 카탈로그, 자주 업데이트되는 사이트.

  1. Next.js는 ISR을 사용하여 페이지를 생성합니다 (60-300초마다 재검증).
  2. Airtable API가 재검증 간격당 고유 페이지당 한 번 호출됩니다.
  3. 이미지는 Cloudinary를 통해 프록시되거나 CDN으로 다운로드됩니다.
  4. 편집자는 전체 재빌드를 트리거하지 않고 분 이내에 업데이트를 봅니다.

패턴 3: Airtable + 보충 CMS

최적 대상: 일부 콘텐츠는 Airtable에, 다른 콘텐츠는 더 풍부한 편집이 필요한 사이트.

  1. 구조화된 데이터 (팀 멤버, 이벤트, 제품)는 Airtable에 유지됩니다.
  2. 장문의 콘텐츠 (블로그 포스트, 사례 연구)는 Sanity 또는 Notion으로 이동합니다.
  3. 프론트엔드는 빌드 시 또는 ISR로 두 소스에서 모두 가져옵니다.

이 하이브리드 접근 방식은 생각한 것보다 더 일반적입니다. 우리는 여러 사이트를 이런 식으로 구축했습니다 — 유사한 것을 고려하고 있다면 연락주세요.

Airtable에서 재빌드 트리거하기

Airtable에는 웹훅을 발화할 수 있는 기본 제공 자동화가 있습니다. 게시물 테이블에서 "When a record is updated"를 트리거하도록 설정한 다음 배포 플랫폼의 빌드 훅에 POST 요청을 보냅니다:

// Vercel 배포 훅
https://api.vercel.com/v1/integrations/deploy/prj_xxxx/yyyy

// Netlify 빌드 훅
https://api.netlify.com/build_hooks/xxxxxxxxxxxx

빠른 편집을 일괄로 처리하려면 자동화에 30초 지연을 추가하세요.

FAQ

Airtable을 CMS로 무료로 사용할 수 있나요?

Airtable의 무료 요금제는 Base당 1,000개 레코드와 월 1,000 API 호출을 포함합니다. 소규모 사이트에는 충분하지만 진지한 프로젝트의 경우 팀 요금제 ($20/사용자/월, 2026년 기준)가 필요합니다. 팀 요금제는 50,000개 레코드와 더 높은 API 제한을 제공합니다.

Airtable의 이미지 URL 만료 문제를 어떻게 처리하나요?

Airtable 첨부 파일 URL은 약 2시간 후 만료됩니다. Astro로 빌드된 정적 사이트의 경우 빌드 시 이미지를 다운로드합니다. ISR을 사용한 Next.js의 경우 Cloudinary와 같은 CDN을 통해 이미지를 프록시하거나, 별도의 이미지 호스팅 서비스에 이미지 URL을 저장하고 Airtable에서 텍스트 필드로 참조합니다.

Airtable은 수백 개의 게시물이 있는 블로그를 처리할 수 있나요?

예, 일정 지점까지입니다. Airtable은 수백 개의 레코드를 잘 처리합니다. 수천 개에 들어가면 API 페이지 나누기와 빌드 시간이 눈에 띄기 시작합니다. 1,000개 미만의 게시물이 있는 블로그의 경우 잘 작동합니다. 그 이상의 경우 전용 헤드리스 CMS를 고려하세요.

Airtable이 Notion보다 CMS로 낫나요?

그들은 다른 문제를 해결합니다. Airtable은 구조화된 데이터 (제품, 이벤트, 팀 멤버)에 더 낫습니다. 관계형 데이터베이스 모델 때문입니다. Notion은 블록 기반 에디터 때문에 장문의 작성된 콘텐츠에 더 낫습니다. Airtable의 API는 또한 Notion의 보다 성숙하고 빠릅니다.

Airtable을 사용하여 미리보기/초안 기능을 어떻게 설정하나요?

"Draft", "In Review", "Published"와 같은 옵션이 있는 "Status" 다중 선택 필드를 추가합니다. 각 상태에 대해 필터된 보기를 만듭니다. 프로덕션 사이트는 "Published" 보기에서 가져옵니다. 미리보기의 경우 인증으로 보호된 "In Review" 보기에서 가져오는 별도의 미리보기 경로를 만듭니다.

Airtable SDK 또는 REST API를 직접 사용해야 하나요?

Astro의 경우 공식 airtable npm 패키지는 빌드 시 가져오므로 잘 작동합니다. Next.js의 경우 REST API를 직접 fetch로 사용하는 것을 권장합니다 — Next.js의 확장 fetch 옵션과 같은 revalidate 및 tags에 대한 캐시 지시문 제어를 제공합니다. SDK는 Next.js의 확장 fetch 옵션을 이해하지 못합니다.

Airtable은 최대 API 호출 수를 얼마나 허용하나요?

Airtable은 Base당 초당 5개 요청의 속도 제한을 시행합니다. 이를 초과하면 429 상태 코드를 반환합니다. 팀 요금제에서는 더 높은 월간 호출 허용량을 받지만 초당 속도 제한은 동일하게 유지됩니다. 정적 생성과 ISR은 API 사용을 최소화하는 최선의 방법입니다.

같은 프로젝트에서 Airtable을 Astro와 Next.js 모두에 사용할 수 있나요?

같은 프로젝트에서는 정확히는 아니지만 여러 프론트엔드를 구동하는 공유 Airtable Base를 가질 수 있습니다. 일부 팀은 마케팅 사이트에 Astro를, 웹 앱에 Next.js를 사용하며 둘 다 동일한 Airtable Base에서 읽습니다. 모든 소비자 간에 공유되는 속도 제한을 염두에 두세요.