1탄이 있어요.
[사내AX] "MCP? SDK? 그게 뭔데요" 🤔 — 몰라도 에어테이블 연동되게 만든 스킬 - 1탄
이후로 엄청엄청 삽질하고 공부해서 우선 지금 수준에서 얻어낸 최적의(?) 결론입니다.
아래 내용만 보셔도 공부 많이 되실 거예요!
배경
매번 새 프로젝트를 시작할 때마다 Airtable 연동을 처음부터 다시 하고 있었습니다. "테이블 구조가 어떻게 되지?", "이 필드 타입이 뭐였더라?" 이런 질문을 Claude에게 반복하면서요.
어느 날 문득 생각했습니다.
"이걸 한 번 만들어두면 다시는 안 해도 되지 않나?"
잠깐, 먼저 구분해야 할 게 있습니다
Airtable을 "연동"한다고 할 때, 두 가지 상황이 있습니다.
1. 앱 코드에서 Airtable API를 호출하는 경우
예를 들어, AI스터디 학습시스템에서 "사용자가 자신이 수강하는 스터디에 해당하는 게시글만 불러오는 기능"이 필요하다고 해봅시다. 이건 앱이 직접 Airtable API를 호출해서 데이터를 가져와야 합니다. 이럴 때 SDK(Software Development Kit, Airtable이 제공하는 공식 라이브러리)를 씁니다. MCP는 여기서 쓸 수 없어요.
2. Claude에게 "Airtable에서 뭐 좀 해줘"라고 시키는 경우
"파트너스 현황 요약해줘", "이번 달 신규 가입자 몇 명이야?" 같은 요청을 Claude에게 하는 거죠. 대화하면서 Claude가 Airtable 작업을 대신 해주는 겁니다. 이때 MCP를 쓸 수도 있고, SDK를 활용한 스크립트를 쓸 수도 있습니다.
이 글에서 다루는 건 두 번째 상황입니다. Claude가 Airtable 작업을 할 때, MCP와 SDK Skill 중 뭐가 나을까요?
첫 번째 후보: MCP
mcp 모델 컨텍스트 프로토콜
MCP(Model Context Protocol)라는 게 있습니다. 간단히 말하면, Claude가 외부 서비스를 "도구"처럼 쓸 수 있게 해주는 겁니다. Airtable MCP를 설치하면 describe_table로 테이블 구조를 바로 확인하고, create_record로 레코드를 만들 수 있죠.
npx 한 줄이면 설치 끝. 편하긴 합니다.
그런데 문제가 있었습니다. Claude Code 세션을 열 때마다 MCP 도구 정의가 통째로 로딩됩니다. 약 7,500 토큰. 대화 몇 번 하면 금방 쌓이는 양이죠.
게다가 Rate Limit 걸려도 재시도를 안 해주고, 레코드를 100개 만들려면 100번 호출해야 합니다. 배치 지원이 없거든요.
두 번째 시도: SDK로 직접 만들자
"MCP 도구들을 그냥 SDK로 구현하면 되지 않나?"
좋은 생각 같았습니다. Airtable SDK로 CRUD 스크립트를 만들고, "이 스크립트를 이렇게 쓰면 돼"라고 Skill 문서에 정리해두면 재사용 가능하니까요.
그런데 막상 해보니 문제가 생겼습니다.
Claude가 API를 호출할 때마다 필드명을 추측하는 겁니다. "아마 이 필드 이름이 '상태'일 거야..." 하고요. 당연히 틀리죠. 에러가 나면 "아, '상태'가 아니라 'Status'였구나" 하고 수정해서 다시 호출합니다.
이 디버깅 루프가 2~3번만 돌아도 MCP보다 토큰을 더 많이 씁니다. 효율화하려다가 오히려 비효율이 된 거죠.
원인을 생각해보니 명확했습니다. MCP는 describe_table로 스키마를 즉시 확인할 수 있는데, SDK 스크립트만 덜렁 있으면 Claude가 스키마를 모르니까 추측할 수밖에 없는 거였습니다.
깨달음: 스키마를 미리 저장해두면?
그래서 떠오른 아이디어가 스키마 캐싱입니다.
"스키마를 파일로 저장해두고, Claude가 작업하기 전에 먼저 읽게 하면 되지 않나?"
MCP의 장점(스키마 확인)과 SDK의 장점(토큰 효율)을 동시에 얻을 수 있는 방법이었습니다.
실제로 해보니 디버깅 루프가 거의 사라졌습니다. Claude가 스키마를 미리 알고 있으니 필드명이나 타입을 틀릴 일이 없거든요.
결과적으로 MCP 대비 토큰을 60% 정도 절약하게 됐습니다.
그런데 또 다른 문제가...
잘 쓰고 있었는데, 다른 프로젝트에서 다른 Airtable 베이스를 쓸 일이 생겼습니다.
MCP는 여러 베이스를 지원합니다. 하지만 제가 만든 SDK Skill은 하나의 베이스만 전제하고 만들어져 있었어요. 스키마 캐시 파일이 하나뿐이었거든요.
그래서 멀티 베이스 지원을 추가했습니다. bases.json에 여러 베이스 정보를 등록해두고, 스크립트 실행할 때 어떤 베이스를 쓸지 지정할 수 있게요.
이렇게 하나씩 부딪히면서 기능이 늘어나더라고요.
그래서 뭘 쓰면 되나요?
결론부터 말하면, 상황에 따라 다릅니다.
MCP가 나은 경우:
빨리 시작하고 싶을 때 (npx 한 줄이면 끝)
스키마가 자주 바뀌는 프로젝트 (API 호출이라 항상 최신)
관리할 코드를 늘리기 싫을 때
SDK Skill이 나은 경우:
토큰 비용이 신경 쓰일 때 (60% 절약)
레코드를 한꺼번에 많이 처리해야 할 때 (배치 지원)
Rate Limit 에러가 자주 날 때 (자동 재시도)
한 가지 더. SDK Skill을 직접 만들려면 약 90,000 토큰 정도 듭니다. 12세션 이상 쓸 거면 그때부터 이득이고요. 만약 누군가 이미 만들어둔 걸 복사해서 쓴다면? 첫 세션부터 바로 이득입니다.
그래서 제가 만든 걸 공개해뒀습니다. 👉 airtable-sdk Skill
~/.claude/skills/ 폴더에 클론해서 바로 쓰시면 됩니다.
마무리
처음엔 단순히 "매번 연동하기 귀찮다"에서 시작한 고민이었는데, 파고들다 보니 MCP와 SDK의 차이, 스키마 캐싱의 중요성까지 알게 됐습니다.
AI 코딩 도구를 쓰다 보면 "이거 뭔가 비효율적인데..." 싶은 순간이 종종 옵니다. 그럴 때 한 발짝 물러서서 "왜 비효율적이지?"를 고민해보면, 의외로 좋은 해결책이 나올 수 있습니다.
혹시 Airtable 연동을 자주 하시는 분이라면, 한 번쯤 스키마 캐싱을 고려해보세요.
부록: SDK Skill 써보기
SDK Skill을 직접 쓰고 싶다면, 대략 이런 구조입니다.
기본 워크플로우
스키마 확인: Claude가 작업 전에
schema-summary.json을 먼저 읽습니다.스키마 동기화: Airtable에서 테이블 구조가 바뀌면
sync-schema.ts로 캐시를 갱신합니다.CRUD 실행: 필요한 스크립트를 호출해서 작업합니다.
스키마 동기화는 언제?
스크립트로 필드를 추가하면 → 자동 동기화
Airtable 웹에서 직접 수정하면 → 수동으로
sync-schema.ts실행
