[사내AX] "MCP? SDK? 그게 뭔데요" 🤔 — 몰라도 에어테이블 연동되게 만든 스킬 - 1탄

📝 한줄 요약

매번 새 프로젝트마다 30분씩 걸리던 에어테이블 연동을, "에어테이블 연동해줘" 한마디로 5분 컷되게 만든 스킬 이야기입니다.

바쁘시면 이것만 읽어도 돼요:

• OpenCode로 에어테이블 연동 자동화 스킬 구축 (30분 → 5분)

• MCP가 토큰 많이 먹는다는 건 오해 — 오히려 SDK만 쓰면 더 비효율적

• 스키마 캐싱으로 Claude가 매번 테이블 구조 파악하느라 토큰 낭비하는 것도 해결

🎯 이런 분들께 도움돼요

• Claude Code 같은 AI 코딩 도구로 에어테이블 연동하는데 매번 헷갈리는 분

• MCP가 토큰 많이 먹을 것 같아서 안 쓰고 있는 분

• "MCP 써야 해요? SDK 써야 해요?" 차이를 모르겠는 분

• 팀원들이 같은 시행착오 겪지 않게 표준화하고 싶은 분

😫 문제 상황 (Before)

매번 반복되는 에어테이블 연동 노가다

새 프로젝트를 시작할 때마다 에어테이블 연동이 필요했습니다. 문제는 이미 4개 프로젝트에서 제각각 연동해둔 상태라는 것.

• 어떤 프로젝트는 SDK 래퍼를 잘 만들어뒀고

• 어떤 프로젝트는 MCP 설정만 해뒀고

• 어떤 프로젝트는 둘 다 어중간하게...

매번 "저번에 어떻게 했더라?" 하면서 다른 프로젝트 뒤적거리고, 복사해오고, 환경변수 세팅하고... 최소 30분은 날아갔습니다.

나만의 문제가 아니었다

더 큰 문제는 팀원들도 똑같은 시행착오를 겪고 있다는 것. 누군가 "에어테이블 연동 어떻게 해요?"라고 물어볼 때마다 설명하는 것도 일이었고, 제가 겪은 삽질을 그들이 또 겪는 게 아까웠습니다.

MCP vs SDK, 뭘 써야 하는 거야?

가장 헷갈렸던 건 MCP를 써야 하는지 SDK를 써야 하는지였습니다.

MCP는 토큰 많이 먹을 것 같아서 안 쓰려고 했는데, 막상 SDK만 쓰니까 Claude한테 에어테이블 작업 시킬 때마다 매번 코드 읽고, API 호출하고... 오히려 더 비효율적인 느낌이었어요.

🛠️ 사용한 도구

• 도구: OpenCode (Prometheus, Sisyphus)

• 모델: Opus - 계획, Sonnet - 실행

• 작업 기간: 2일 (2026-01-28 ~ 29)

🔧 작업 과정

1. "이거 스킬로 만들 수 있을까?" — 시작점

gpters-partners 프로젝트에서 또 에어테이블 연동하려다가 문득 생각했습니다.

매번 프로젝트 새로 시작할 때마다 에어테이블 연동하는 게 번거로운데
이걸 스킬로 만들거나 재사용하는 그런 똑똑한 방법이 있을까?

Prometheus(플래닝 에이전트)가 먼저 기존 프로젝트들을 탐색했습니다. 결과가 흥미로웠어요:

4개 프로젝트가 제각각 다른 방식으로 에어테이블을 쓰고 있었습니다. 이걸 하나로 표준화하면 되겠다 싶었어요.

2. "MCP vs SDK, 둘 중 뭘 써야 해?" — 핵심 깨달음

여기서 가장 큰 배움이 있었습니다. Prometheus한테 물었어요:

용도: "Claude가 직접 조회/수정" + "앱 코드에서 사용" 둘 다 필요한데, 
MCP랑 SDK 중에 뭘 써야 해?

돌아온 답변이 명쾌했습니다:

"둘은 경쟁 관계가 아니에요. 용도가 달라요."

3. "MCP가 토큰 많이 먹지 않나?" — 오해 해소

솔직히 MCP 도구가 많으면 토큰 낭비 아닌가 걱정됐습니다. 이미 83개 도구가 로드되어 있었거든요.

그런데 Prometheus가 보여준 토큰 비용 분석표가 눈을 뜨게 해줬어요:

생각보다 도구 정의 비용이 크지 않았습니다.

더 중요한 건 이거였어요:

SDK만 쓸 때 Claude가 에어테이블 작업하려면:

1. lib/airtable.ts 파일 읽기 (토큰 소모)

2. 어떤 함수가 있는지 파악 (토큰 소모)

3. 사용법 이해하기 (토큰 소모)

4. 코드 작성해서 실행

5. 에러나면 디버깅 반복...

MCP 쓰면:

1. list_records(baseId, tableId) 호출

2. 끝

MCP 도구 정의 비용보다, SDK 코드를 매번 읽고 이해하고 실행하는 비용이 훨씬 컸던 거예요.

ALT

한국어 한국어 한국어 한국어 한국어 한국어 한국어 한국어

4. 스킬 생성 및 구조 개편 — 아쉬웠던 점 발견

플래닝을 마치고 스킬 생성에 들어갔습니다. 그런데 작업 중에 아쉬운 점이 있었어요.

skill-creator라는 스킬을 써서 구조를 잡으라고 요청했는데, 나중에 DEVLOG를 보니까 실제로는 스킬을 로드하지 않고 디렉토리 구조만 참고했더라고요.

[실제 작업 방식]
- skill-creator 스킬 로드: ❌ 안 함
- references/ 디렉토리 구조 참고: ✅ 탐색으로 확인
- init_skill.py 스크립트 사용: ❌ 안 함

결과적으로는 잘 됐지만, Claude가 어떤 스킬을 쓰고 있는지 실시간으로 확인하기 어렵다는 걸 느꼈습니다. 앞으로 이 부분은 개선이 필요할 것 같아요.

5. "더 효율적인 방법은 없을까?"

스킬 기본 구조를 완성하고 나니, 실제 사용하면서 비효율이 느껴졌습니다.

동일한 베이스에서 작업하는데도 매번 테이블 구조 읽고, 필드 타입 읽고...
굉장히 비효율적인 것 같아.

그래서 스키마 캐싱 기능을 추가했습니다:

• 테이블 구조를 로컬 파일에 저장

• Claude가 매번 API 호출 안 해도 됨

• AUTO-GENERATED / USER-ADDED 섹션 분리로 재생성해도 설명 유지

ALT

한국어 텍스트가 있는 페이지의 스크린샷

6. "여러 베이스는 어떻게 해?" — 멀티 베이스 지원

작업하다가 또 헷갈린 게 있었습니다.

.env 파일에는 1개의 baseId만 넣잖아? 
여러 베이스의 테이블을 가지고 작업해야 할 때는 어떻게 해?

알고 보니 MCP는 이미 멀티 베이스를 지원하고 있었어요:

MCP 도구들은 모든 API 호출에 baseId를 파라미터로 받기 때문에, 여러 베이스를 자유롭게 오갈 수 있었습니다. .env의 AIRTABLE_BASE_ID는 SDK용이었던 거죠.

이 차이를 몰랐으면 계속 헷갈렸을 거예요.

7. "스키마 자동 갱신은 어떻게?" — CRITICAL 지침의 힘

스키마 캐싱까지 구현하고 나니 한 가지 고민이 생겼습니다.

사용자가 작업 중에 에어테이블 스키마를 바꾸면
스키마 파일도 자동으로 업데이트되게 하고 싶은데, 어떻게 해?

Prometheus가 Claude Code의 Hook 시스템을 분석한 결과:

"Hook 시스템은 있지만 Write, Edit 같은 네이티브 도구에만 작동해요. MCP 도구에는 직접적인 Hook이 없어요. 대신 '지침 기반 자동화'가 핵심 메커니즘이에요."

그래서 SKILL.md에 CRITICAL 지침을 추가했습니다:

CRITICAL: create_field, update_field 등 스키마 변경 도구 사용 후에는 반드시 스키마 파일을 갱신해야 한다.

이렇게 하면 Claude가 필드를 추가할 때 자동으로 스키마도 업데이트합니다. 지침의 힘이 생각보다 강력하더라고요.

✅ 결과 (After)

Before vs After

결과물

완성된 스킬 구조:

airtable-integration/
├── SKILL.md (메인 워크플로우)
├── assets/ (템플릿 파일들)
└── references/ (가이드 문서들)

호출 방법:

에어테이블 연동해줘

이 한마디로:

1. MCP 서버 설정

2. SDK 래퍼 설치

3. 환경변수 가이드

4. 스키마 자동 생성

까지 전부 처리됩니다.

배포:

• GitHub 공개 레포: https://github.com/daht-mad/airtable-integration-skill

• 사내 툴킷(gpters-toolkit)에도 배포 완료

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. MCP 도구 정의 비용보다 SDK 코드 읽고 실행하는 비용이 더 크다

   • MCP 무거울 것 같아서 안 쓰는 건 오해

   • Claude한테 직접 시키는 작업은 MCP가 훨씬 효율적

2. CRITICAL 지침은 생각보다 강력하다

   • Hook이 없어도 지침만으로 자동화 가능

   • "반드시 ~해야 한다"라고 명시하면 Claude가 따름

   • 근데 더 효과적인 방법이 있는지 확인 필요 <- 도움이 필요해요!

이렇게 하면 안 돼요

1. 스킬 사용 여부를 확인 안 하면 안 돼요

   • "이 스킬 써" 했다고 실제로 쓰는 게 아님

   • 나중에 DEVLOG 보고 알게 될 수 있음

2. MCP와 SDK 용도를 헷갈리면 안 돼요

   • Claude한테 시키는 작업 → MCP

   • 앱 코드에서 돌아가는 작업 → SDK