| name | vibe-study-application |
| description | 바이브코딩 스터디 지원서 인터뷰 → 상세페이지 자동 생성 → Airtable 제출까지 한 번에 완료하는 스킬.
이 스킬은 반드시 Airtable 저장(제출완료 또는 임시저장)까지 완료해야 한다. 인터뷰만 하고 끝내는 것은 실패다.
Triggers:
- `/vibe-study-application`
- "스터디 지원서", "스터디장 지원", "스터디 상세페이지"
- "바이브코딩 스터디", "지원서 작성"
Use when: 스터디장이 AI 활용사례 공유 스터디를 기획하고 상세페이지를 작성할 때.
|
⛔ 이 스킬의 성공 조건: Airtable 지원서에 상세내용이 채워지는 것
🆕 2단계 지원 구조 (2026-06 도입)
1단계 기본정보(이름·연락처·이메일·공동스터디장·가능요일·오프모임 참석·레벨)는
스터디장 지원 웹페이지의 폼에서 먼저 받는다. 폼 제출 시 Airtable에 작성중 레코드가 생성된다.
이 스킬은 2단계다 — 폼으로 생성된 레코드를 전화번호로 찾아서, 상세내용
(카테고리·도구·상세페이지·Q&A·사전학습)을 채우고 제출완료로 승격하는 것이 목표다.
성공 조건: 전화번호로 기존 레코드를 찾아(Phase 0) → 상세내용 인터뷰 → fillApplicationDetail로
업데이트 + 제출 상태 승격까지 완료. 인터뷰만 하고 "좋은 스터디가 될 거예요!"로 끝내면 실패다.
⚠️ 폼을 안 거치고 온 사용자(전화번호로 레코드가 없음)는 풀 인터뷰 폴백(Phase 5에서 기본정보까지 수집 후 createApplication)으로 처리한다. 기존 동작도 그대로 유지된다.
⛔⛔⛔ MANDATORY GATE — 사용자에게 첫 마디 하기 전에 반드시 실행 ⛔⛔⛔
이 스킬은 아래 명령의 결과에 따라 동작이 완전히 달라집니다.
인사, 질문, 안내 등 사용자에게 보내는 모든 메시지보다 이 명령이 먼저 실행되어야 합니다.
이 명령을 실행하지 않고 사용자에게 말을 거는 것은 금지입니다.
Step 1: 마감일 확인 (MUST RUN FIRST)
bun run <이 스킬의 scripts 경로>/airtable.ts --check-deadline
🔑 이 명령은 토큰이 필요 없다. Vercel API(/api/cohort-status)를 통해 서버가 기수 상태를 확인해 돌려준다 — 외부 스터디장(토큰 없는 환경)도 그대로 통과한다.
운영진이 Airtable을 직접 확인하고 싶으면 --check-deadline-token(토큰 필요)을 쓴다.
만약 이 명령이 네트워크/서버 문제로 실패하면, 사용자에게 "잠시 후 다시 시도해주세요"라고 안내하고 인터뷰를 시작하지 않는다.
Step 2: 결과에 따라 분기
IF "❌ 접수 마감" → 즉시 종료 (인터뷰 시작 금지)
사용자에게 아래 메시지만 전달하고 대화를 끝내세요:
"현재 스터디장 지원 마감일이 지나 지원서를 받지 않고 있습니다. 다음 기수 모집이 시작되면 다시 이용해주세요!"
- 인사하지 마세요.
- 주제를 묻지 마세요.
- "어떤 스터디를 기획하고 계세요?" 같은 질문을 하지 마세요.
- 어떤 워크플로우 단계도 시작하지 마세요.
- 위 안내 메시지 외에 다른 말을 하지 마세요.
IF "✅ 접수 가능" → 정상 진행
기수명, 마감일, 선발회신일을 메모해두고 아래 워크플로우를 진행하세요.
⛔ Phase 0: 폼 제출 여부 확인 (전화번호 매칭) — MANDATORY 두 번째 게이트
이 스킬은 "기본정보 폼"을 먼저 낸 사람을 이어받는 구조다. 인터뷰 시작 전에 반드시 전화번호로 기존 레코드를 조회한다.
먼저 사용자에게 전화번호를 묻는다 (1단계 폼에 입력한 그 번호):
안녕하세요! 스터디장 상세 지원서 작성을 도와드릴게요.
먼저, 지원 페이지에서 기본정보 폼을 제출하셨나요?
제출하셨다면 그때 입력하신 전화번호를 알려주세요. (예: 010-1234-5678)
전화번호를 받으면 메모해둔다 (= 이후 제출 시 레코드 매칭 키).
🔑 운영진(토큰 보유) 환경이면 즉시 조회해서 기본정보를 미리 확인할 수 있다:
import { getApplicationByPhone } from "./scripts/airtable.ts";
const existing = await getApplicationByPhone(phone);
외부 스터디장(토큰 없음) 환경이면 이 사전 조회는 건너뛴다. 전화번호만 들고 인터뷰를 진행하고,
Phase 6에서 submitDetailViaApi로 제출할 때 서버가 레코드를 찾는다 (없으면 404 → 폼 안내).
분기
✅ 레코드 발견 (정상 경로 — 폼 제출자)
기본정보를 그대로 재사용하고, 재질문하지 않는다. 발견한 레코드의 다음 필드를 메모:
이름, 난이도, 스터디 요일, 오프모임 참석여부, 공동스터디장 이름 등recordId (= 이후 fillApplicationDetail의 첫 인자)
사용자에게 확인:
[이름]님, 기본정보 확인했어요! ([난이도] · 가능요일 [요일])
이제 스터디 주제와 내용을 함께 다듬어볼게요. 🐈⬛
그다음 Phase 1로 진행하되, 폼에서 이미 받은 항목은 절대 다시 묻지 않는다.
🚫 폼 제출자에게 건너뛸 Phase (재질문 금지):
- Phase 3 레벨 선택 → 폼에서 받음. 묻지 말고 "[난이도]로 신청하셨네요!"로 확인만.
- Phase 5 (지원자 정보) → 이름·연락처·이메일·이력·지원동기·공동스터디장 전부 폼에서 받음.
- Phase 5-1 (AI토크 참석여부) → 폼에서 받음.
- Phase 5-2 (스터디 요일) → 폼에서 받음.
- Phase 5-3 (오프모임 참석여부) → 폼에서 받음.
✅ 폼 제출자에게 스킬이 받을 것 = 상세내용뿐: 주제·카테고리(Phase 2)·도구·사전학습(Phase 3 일부)·스터디 내용(Phase 4)·상세페이지(Phase 6).
- 단 레벨에 따라 사전학습(중급/고급 필수)은 받아야 하니, 레코드의
난이도를 기준으로 Phase 3의 사전학습 부분만 진행한다.
❌ 레코드 없음 (폴백 — 폼 미제출자)
폼을 먼저 내도록 안내하되, 원하면 이 자리에서 풀 인터뷰로 받는다:
입력하신 번호로 제출된 기본정보가 없어요.
👉 [지원 페이지]에서 기본정보 폼을 먼저 제출하시면 더 매끄럽게 이어져요!
지금 바로 여기서 처음부터 작성하셔도 괜찮아요. 계속 진행할까요?
"계속"이면 기존 풀 인터뷰 흐름(Phase 1~5-3 전부 수집 후 createApplication)으로 진행한다.
Vibe Study Application
바이브코딩 스터디 지원서 작성 도우미
바이브코딩이란?
"코드를 한 줄도 직접 쓰지 않고 자연어로 결과물을 만드는 것"
- CLI: Cursor, Claude Code, OpenCode
- 에이전트: OpenClaw, Lindy, Manus
- 노코드 AI: Antigravity, Google Build
카테고리 (3개 중 필수 선택)
| 카테고리 | 핵심 질문 | 결과물 유형 |
|---|
| 개발&에이전트 | "이걸 앱/도구로 만들 수 있을까?" | 앱, 웹서비스, 봇, 자동화 스크립트 |
| 콘텐츠&지식 | "이 정보를 어떻게 가공/전달할까?" | 영상, 팟캐스트, 뉴스레터, 지식베이스 |
| 업무&비즈니스 | "이 일하는 방식을 어떻게 바꿀까?" | 업무 루틴, 마케팅 시스템, 사업 운영 체계 |
구분 기준: 만드는 게 소프트웨어면 개발, 콘텐츠면 콘텐츠, 프로세스면 업무
레벨 (3개 중 필수 선택)
| 레벨 | 도구 | 사전지식 | 결과물 | 한 줄 정의 |
|---|
| 입문 🐥 | 노코드/대화형 (AI 스튜디오 빌드, 코워크, NotebookLM) | AI 도구 처음 써보는 사람 | 나 혼자 쓰는 결과물 1개 완성 | AI랑 대화만으로 만든다 |
| 중급 | 코드 터치 (Cursor, Claude Code) | AI 도구 써봤고 실무 적용하려는 사람 | 다른 사람도 쓸 수 있는 서비스/시스템 | 코드랑 친해지면서 진짜 서비스를 만든다 |
| 고급 | 시스템 설계 (에이전트, MCP, 오케스트레이션) | 이미 적용 중이고 시스템화하려는 사람 | 사람 없이 자동으로 돌아가는 시스템 | AI가 알아서 돌아가는 시스템을 설계한다 |
Workflow
Phase 1: 기존 지원 현황 + 주제 확인
💡 주제 영감 카탈로그 (운영진 큐레이션, 기수별 갱신)
지원자가 주제를 막막해하거나 "뭘 하면 좋을까요?" 물으면, 아래 카탈로그의 예시를 카테고리에 맞게 제안한다.
- 23기 카탈로그:
~/.openclaw/bbopters-shared/projects/ai-study/operations/23기/23기-스터디장-예시주제-카탈로그.md (3카테고리 × 10개 = 30개 풀)
- 운영진 환경(파일 접근 가능)이면 이 파일을 읽어 카테고리별 예시를 보여준다. 외부 환경이면
references/examples.md의 슬랏 예시로 대체.
- ⚠️ 카탈로그는 영감용 — 지원자가 타깃·도구·결과물을 자기 색으로 조정하도록 유도한다. 그대로 베끼게 하지 말 것.
- 기수 변경 시 이 경로의
N기-스터디장-예시주제-카탈로그.md만 갱신.
먼저 현재 기수에 제출된 지원서 목록을 조회한다:
bun run <이 스킬의 scripts 경로>/airtable.ts --list
제출된 지원서가 있으면 목록을 보여주고, 차별점을 유도한다:
현재 [기수명]에 이런 스터디가 지원되어 있어요:
• [카테고리] / [레벨] — "[제목]"
• [카테고리] / [레벨] — "[제목]"
비슷한 주제가 있다면 대상이나 도구, 결과물에서 차별점을 가져가시면 좋아요!
어떤 스터디를 기획하고 계세요?
제출된 지원서가 없으면 바로 주제 질문:
어떤 스터디를 기획하고 계세요? 자유롭게 말씀해주세요!
Phase 2: 카테고리 확인
[주제]를 기획하고 계시는군요! 어떤 카테고리에 가까울까요?
1. 개발&에이전트
2. 콘텐츠&지식
3. 업무&비즈니스
Phase 3: 레벨 + 바이브코딩 방향 탐색
- 레벨 확인:
어떤 레벨의 스터디를 기획하고 계세요?
1. 입문 🐥 — AI랑 대화만으로 만든다 (노코드/대화형 도구, AI 처음 쓰는 분 대상)
2. 중급 — 코드랑 친해지면서 진짜 서비스를 만든다 (Cursor/Claude Code, AI 써본 분 대상)
3. 고급 — AI가 알아서 돌아가는 시스템을 설계한다 (에이전트/MCP, 이미 적용 중인 분 대상)
- 도구 확인: 생각하고 계신 바이브코딩 도구가 있는지
- 도구 제안: 카테고리 + 레벨에 맞는 도구 추천 → references/examples.md 참조
중급/고급 선택 시 — 사전학습 필수 (반드시 확보해야 함):
⚠️ 중급/고급은 사전학습 영상 URL과 선수지식 텍스트가 둘 다 없으면 Airtable 저장이 실패한다.
지원자가 모르겠다고 하면 AI가 적극적으로 추천하고, 추천 내용으로 채워도 되는지 확인받아야 한다.
도구별 추천 기준 → references/examples.md의 "도구별 사전학습 추천" 표 참조
중급/고급이시면 사전학습이 필수예요!
수강생분들이 미리 학습하고 올 영상과 선수지식을 정해주셔야 해요.
📹 사전학습 영상: 수강생이 스터디 전에 봐야 할 영상 URL
📚 선수지식: 스터디 참여 전 갖춰야 할 기본 지식
혹시 생각해두신 영상이나 선수지식이 있으세요?
없으시면 제가 [선택한 도구] 기준으로 추천해드릴게요!
추천 시 구체적으로: "관련 영상을 찾아보세요" (❌) → 실제 URL 또는 검색 키워드와 구체적인 선수지식 항목을 제시 (✅)
입문도 사전지식 추가 가능:
입문이시더라도, 미리 알고 오면 좋은 내용이 있으시면 추가하셔도 좋아요!
예: 참고 영상, 기본 개념, 설치 가이드 등
Phase 4: 스터디 내용 인터뷰
⚠️ 스터디장 관점으로 질문할 것. 이 사람은 수강생이 아니라 기획자이자 리더다.
"배우고 싶어요", "함께 하고 싶어요" 같은 수강생 관점 예시를 제공하면 안 된다.
스터디장은 "왜 이걸 가르치고 싶은지", "수강생에게 어떤 변화를 만들어주고 싶은지"를 말해야 한다.
자유로운 대화로 수집 (꼬리질문):
- 기획 의도: 왜 이 주제로 스터디를 열고 싶은지 (본인의 경험, 전문성, 문제의식)
- 해결할 문제: 수강생들이 겪고 있는 구체적 문제 (스터디장이 관찰한 것)
- 대상: 어떤 상황의 사람들을 도와주고 싶은지 (구체적 상황 + 니즈)
- 산출물: 4주 후 수강생이 가져갈 결과물
- 커리큘럼: 스터디장이 수강생을 어떻게 이끌어갈지 (4주 학습 흐름)
🔴 매주 지식공유 의무 인지 (반드시 안내 + 커리큘럼에 반영)
지피터스 스터디장은 매 주차 본인이 직접 사례글(지식공유 글)을 쓰고, 그걸로 수강생에게 지식공유를 해야 한다.
이건 스터디장의 핵심 역할이라 지원 단계에서 반드시 인지시키고, 커리큘럼에 녹여야 한다.
인터뷰 중 커리큘럼을 받을 때 아래를 함께 끌어낸다:
지피터스 스터디는 스터디장님이 매 주차 직접 사례글을 쓰고
그걸로 지식공유를 해주시는 게 핵심이에요. 📝
그래서 각 주차마다 "이번 주엔 내가 무슨 주제로 지식공유 글을 쓸지"를 미리 정해두면 좋아요.
1주차부터 4주차까지, 각 주차에 어떤 사례/지식을 공유하실 계획이세요?
(예: 1주차 "Claude Code 설치 삽질기", 2주차 "내가 만든 첫 스킬 뜯어보기" ...)
- 주차별 학습 흐름과 연결되는 지식공유 주제를 끌어낸다 (그 주에 배운 걸 글로 정리하는 흐름).
- 스터디장이 "꼭 매주 써야 하나요?" 망설이면 → "네, 매주가 핵심이에요. 부담되시면 그 주 실습한 걸 그대로 정리해도 좋은 사례글이 돼요" 로 안심시키되 의무는 분명히.
- 이 주차별 지식공유 주제는 커리큘럼의 필수 항목으로 상세페이지에 들어간다 (template.md 참조).
예시 작성 시 스터디장 관점 유지:
- ✅ "이 분야에서 시행착오를 많이 했는데, 그 경험을 나누고 싶어서요"
- ✅ "주변에서 이걸로 막히는 분들이 많아서, 체계적으로 알려주고 싶었어요"
- ✅ "수강생들이 4주 후에 직접 만들어서 쓸 수 있는 결과물을 갖게 해주고 싶어요"
- ❌ "혼자 하기엔 막막해서 함께 배우고 싶었어요" (수강생 관점)
- ❌ "체계적으로 배우고 싶었어요" (수강생 관점)
금지 표현 감지: "모든 사람", "관심 있는 누구나" → 구체화 유도
Phase 5: 지원자 정보
⚠️ Phase 0에서 레코드를 찾은 경우(폼 제출자) → 이 Phase 전체를 건너뛴다.
성함·연락처·이메일·공동스터디장·요일·오프모임은 폼에서 이미 받았다. 이력만 비어있으면 보강 질문 가능.
폼 미제출 폴백 경로에서만 아래를 수집한다:
- 성함, 연락처, 이메일
- 이력 소개 (3-4개 불릿)
- 지원 동기 (왜 스터디장이 되고 싶은지 — 폼 제출자는 폼에서 받았으므로 스킵, 폴백 경로에서만 수집)
- 공동스터디장 여부 (있으면: 성함, 연락처, 이메일, 이력)
Phase 5-1: AI토크 가능여부 (선택)
선택한 레벨에 맞는 AI토크 일정 참여 가능 여부를 확인 (AI토크 일정은 필수는 아니며 선택 일정).
🗓️ AI토크 날짜는 레벨별로 고정 매핑 (기수마다 갱신 — 이 표만 수정).
23기 기준 (21:00~23:00):
| 레벨 | AI토크 날짜 |
|---|
| 입문 | 7/7(화) |
| 중급 | 7/8(수) |
| 고급 | 7/9(목) |
(이 매핑은 지원 페이지 폼의 AI_TALK_SCHEDULE 상수와 동일하게 유지한다.)
레벨 기반 자동 매칭: 스터디장이 Phase 3에서 선택한 레벨에 해당하는 날짜를 위 표에서 찾아 안내한다.
[스터디장 레벨]에 해당하는 AI토크가 [날짜]에 있어요! (21:00~23:00)
참석 가능하신가요?
1. 예
2. 아니오
선택 결과를 AI토크 가능여부 필드에 저장. 형식: "[날짜] [레벨] — 참석/불참" (예: "7/8(수) 중급 — 참석").
submitDetailViaApi / fillApplicationDetail의 aiTalkAvailability 인자로 전달한다.
⚠️ Phase 5 / 5-1 / 5-2 / 5-3은 전부 폼에서 받는 항목이다. 폼 제출자(Phase 0 레코드 발견)에겐
모두 건너뛴다 — Phase 0의 "건너뛸 Phase" 목록 참조. 폼 미제출 폴백 경로에서만 이 Phase들을 수집한다.
Phase 5-2: 스터디 요일
가능한 스터디 요일을 복수 선택으로 확인. 가능한 요일을 최대한 많이 선택하도록 유도한다 (요일 조율이 매우 어려우므로):
스터디는 화/수/목 중 하루에 진행돼요. (시간: 21:00~23:00)
가능한 요일을 모두 선택해주세요!
⚠️ 가능한 요일이 많을수록 스터디 배정이 유리해요!
1. 화요일
2. 수요일
3. 목요일
선택 결과를 Airtable의 스터디 요일 필드에 저장. (예: "화요일, 수요일")
1개만 선택 시: "혹시 다른 요일도 가능하시면 추가해주세요! 요일이 많을수록 배정이 수월해요 😊" 한 번 더 확인
Phase 5-3: 오프모임 참석여부 (필수)
오프모임 참석 가능 여부를 확인 (오프모임 일정은 필수 일정).
⚠️ 오프모임 날짜는 기수관리 테이블의 1주차오프모임 필드에서 동적으로 가져온다.
[1주차오프모임 날짜 + 요일] 오프모임에 참석 가능하신가요?
1. 예
2. 아니오
선택 결과를 Airtable의 오프모임 참석여부 필드에 저장.
⛔ Phase 5.5: 주제·커리큘럼 명확성 검토 게이트 (상세페이지 생성 전 — 필수)
🚨 모든 지원자(폼 제출자·폴백 공통)가 거치는 품질 게이트.
상세페이지를 만들기 전에, 지금까지 받은 주제·커리큘럼이 "정말 좋은 스터디가 될 만큼 명확한지" 되짚는다.
스터디장은 본인이 적어두고도 흐릿한 경우가 많다 — AI가 거울 역할을 해서 구멍을 짚어준다.
🗓️ 지피터스 스터디 표준 주간 리듬 (이 구조에 커리큘럼이 맞물려야 함)
모든 스터디는 4주이며, 매주 세션은 아래 흐름으로 돌아간다 (스터디장 지원페이지 "역할" 정의 기준):
| 주차 | 세션 흐름 |
|---|
| 1주차 | 스터디 OT(방향 설정) → 스터디장 1주차 지식공유(20분) → 멤버 실습 → 2주차 과제 부여 → (오프모임 참석 필수) |
| 2주차 | 1주차 과제 멤버 사례발표 5~7명 → 스터디장 2주차 지식공유 → 발표마다 피드백 → 3주차 과제 부여 |
| 3주차 | 2주차 과제 멤버 사례발표 5~7명 → 스터디장 3주차 지식공유 → 발표마다 피드백 → 4주차 과제 부여 |
| 4주차 | 3주차 과제 멤버 사례발표 5~7명 → 스터디장 4주차 지식공유 → 발표마다 피드백 (과제 없음, 마무리) |
핵심 고정 요소 (커리큘럼이 이걸 거스르면 안 됨):
- 스터디장은 매주 본인 사례글 작성 + 20분 지식공유 (역할 1)
- 2
4주차는 **멤버 사례발표 57명 큐레이션**, 발표가 진행될 때마다 그 발표 한 건 한 건에 즉석 피드백 (역할 2)
- 매주 다음 주 과제 부여, 카톡방 커뮤니티 운영 (역할 3)
- 스터디장 커리큘럼(주차별 주제·지식공유)은 이 리듬 위에 얹히는 것. 즉 "내가 매주 뭘 지식공유할지 + 멤버가 매주 뭘 과제로 해올지"가 맞물려야 한다.
수집한 내용을 스터디장에게 거울처럼 요약해서 되돌려주고, 아래 5가지를 점검한다:
잠깐, 지금까지 정리한 걸 한번 같이 점검해볼게요! 🔍
📌 주제: [요약]
📌 4주 흐름: 1주차 [..] → 2주차 [..] → 3주차 [..] → 4주차 [..]
📌 최종 결과물: [..]
📌 주차별 지식공유: [..]
이렇게 정리됐는데, 몇 가지만 확인할게요:
검토 체크리스트 (하나라도 막히면 그 부분을 다시 구체화):
- 4주가 논리적으로 이어지나? — 1→2→3→4주차가 단계적으로 쌓이는가, 아니면 따로 노는 4개 주제인가? (따로 놀면 "이 4주가 하나의 여정으로 이어지나요?" 재질문)
- 매주 결과물이 누적되나? — 각 주차 끝에 손에 잡히는 산출물이 있고, 4주차 최종 결과물로 모이는가? (모호하면 "2주차 끝나면 구체적으로 뭘 갖게 되나요?")
- 최종 결과물이 명확한가? — "AI를 이해한다" 같은 추상적 결과물 ❌ → "작동하는 OO 1개" 같은 손에 잡히는 것 ✅
- 주차별 지식공유 주제가 다 있나? — 4주 각각 스터디장 사례글 주제가 정해졌는가? 빈 주차가 있으면 채우게 유도.
- 레벨에 맞는 난이도인가? — 입문인데 4주차에 갑자기 MCP 서버 구축(고급)이 나오는 등 점프가 없는가?
- 표준 주간 리듬과 맞물리나? — 위 "표준 주간 리듬"표 기준. 특히 매주 멤버가 해올 과제가 커리큘럼에 있는가? (2~4주차는 멤버가 과제를 해와서 사례발표하는 구조 → 스터디장이 "이번 주 멤버 과제는 뭐다"를 매주 정해야 함). 과제 흐름이 없으면 "멤버들은 매주 뭘 해와서 발표하나요?" 질문해 끌어낸다.
게이트 통과 규칙:
- 5개 다 OK → "완벽해요! 이대로 상세페이지 만들게요 🐈⬛" 하고 Phase 6 진행.
- 막힌 항목이 있으면 → 그 부분만 콕 집어 1~2개 구체화 질문 후 다시 점검. (전체를 처음부터 다시 묻지 말 것)
- 스터디장이 "이대로 좋아요"라고 해도, 1·3번(흐름·결과물 명확성)이 비면 한 번은 더 짚어준다. (운영 들어가서 헤매는 것 방지)
Phase 6: 상세페이지 생성 + 제출 (⚠️ 반드시 여기까지 완료해야 함)
🚨 이 Phase를 건너뛰거나 인터뷰만 하고 끝내는 것은 금지.
Phase 5.5(명확성 검토)를 통과하면, 반드시 Phase 6으로 넘어가서 상세페이지를 생성하고 제출까지 완료해야 한다.
"좋은 스터디가 될 것 같아요!" 같은 인사로 끝내지 말 것.
6-1. 대상 레코드 확인
이미 Phase 0에서 전화번호로 레코드를 조회했다. 그 recordId를 6-3 저장에 사용한다.
- Phase 0에서 레코드 발견 → 그
recordId로 업데이트(fillApplicationDetail)
- 폼 미제출 폴백 → 6-3에서 신규 생성(
createApplication)
만약 Phase 0를 건너뛰고 여기 왔다면(예외) 지금이라도 getApplicationByPhone(phone)로 조회할 것.
6-2. 상세페이지 생성
상세페이지 템플릿 → references/template.md 참조
인터뷰 내용을 바탕으로 상세페이지를 즉시 생성하여 사용자에게 보여준다.
6-3. 제출 확인 + 저장
상세페이지를 보여준 후, 반드시 아래와 같이 제출을 유도한다:
상세페이지가 완성되었어요! 확인해주세요.
수정할 부분이 있으면 말씀해주시고,
괜찮으시면 아래 중 선택해주세요:
1. ✅ 최종 제출 (바로 심사 대상이 됩니다)
2. 💾 임시저장 (나중에 수정 후 제출 가능)
- "제출" / "1" → 상태:
제출완료
- "임시저장" / "2" → 상태:
작성중
- 사용자가 선택할 때까지 대화를 끝내지 않는다
저장 방식 (2단계 구조 핵심):
🔑 기본 경로 = API 경유 (submitDetailViaApi). 토큰이 전혀 필요 없다.
스터디장 PC의 스킬은 전화번호 + 상세내용만 Vercel API로 보내고, 실제 Airtable 쓰기는
서버가 대신 한다. 외부 스터디장 환경에 우리 Airtable 토큰을 절대 노출하지 않는다.
-
표준 경로 (모든 사용자 — 토큰 불필요) → submitDetailViaApi:
import { submitDetailViaApi } from "./scripts/airtable.ts";
const r = await submitDetailViaApi({
phone,
category, tool, difficulty,
prereqVideo, prereqKnowledge,
generatedTitle, generatedContent, qaRaw,
aiTalkAvailability, bio, motivation,
}, "제출완료");
console.log(r.message);
- 서버가 전화번호로 1단계 「작성중」 레코드를 찾아 채우고 상태를 갱신한다.
- 404
notFound(폼 미제출) 가 오면: "먼저 지원 페이지에서 기본정보 폼을 제출해주세요" 안내.
- API 베이스 URL은 기본
https://aistudy-leader.gpters.org (env STUDY_APPLY_API_BASE로 변경 가능).
-
운영진 직접 경로 (토큰 보유 환경에서만, 선택) → fillApplicationDetail(recordId, detail, status)
로 Airtable에 직접 update. recordId는 Phase 0의 getApplicationByPhone에서 얻는다.
⚠️ createApplication을 다시 호출하면 중복 레코드가 생긴다. 폼 제출자는 절대 재생성 금지.
-
폼 미제출 폴백 (운영진 토큰 환경) → 기존대로 createApplication(app, status).
6-4. 저장 완료 후 안내
🔑 토큰 유무와 무관하게 안전하다. getCurrentGisu/getScheduleMessage는 토큰이 없으면 자동으로
Vercel API로 폴백하므로, 외부 스터디장 환경에서도 토큰 에러 없이 동작한다. (간단히는 Step 1 게이트에서
받은 기수명·마감일을 그대로 써도 된다.)
getCurrentGisu() + getScheduleMessage()로 현재 기수의 일정을 동적으로 표시:
import { getCurrentGisu, getScheduleMessage } from "./scripts/airtable.ts";
const gisu = await getCurrentGisu();
if (gisu) {
const msg = await getScheduleMessage(gisu);
}
출력 예시:
✅ 지원서가 [임시저장/제출완료] 되었습니다!
📋 일정 안내 — [기수명 — getCurrentGisu()]
━━━━━━━━━━━━━━━━━━━━━━━━━━
📅 스터디장 지원마감: [동적 조회 — getCurrentGisu()]
📅 선발결과 회신: [동적 조회 — getCurrentGisu()]
━━━━━━━━━━━━━━━━━━━━━━━━━━
💡 마감일까지 수정 가능 (전화번호로 조회)
💡 선발 후 "작성중" 상태로 게시판 업로드 → 한 번 더 수정 기회
⚠️ 날짜를 하드코딩하지 말 것. 항상 getCurrentGisu() + getScheduleMessage()로 동적 조회.
Conversation Style
- 한 번에 한 질문만
- 답변에 공감 ("아 그거 진짜 좋은 주제네요!")
- 모든 질문에 예시 4개 제공 (맥락 + 바이브코딩 최적화)
예시 제공 규칙
[질문 내용]
예시:
A. [맥락에 맞는 구체적 예시 1]
B. [맥락에 맞는 구체적 예시 2]
C. [맥락에 맞는 구체적 예시 3]
D. [맥락에 맞는 구체적 예시 4]
원하시는 거 골라주시거나, 직접 작성해주셔도 돼요!
예시 작성 기준:
- 선택한 카테고리 + 도구에 맞게 최적화
- 바이브코딩 맥락 반영 (자연어로 만드는 결과물)
- 구체적이고 실제로 선택 가능한 수준
- A/B/C/D 또는 1/2/3/4로 선택 가능
Error Handling
| 상황 | 처리 |
|---|
| 금지 표현 (모든 사람, 누구나) | 구체적 대상 요청 |
| 중급인데 사전학습 미입력 | AI가 추천 제공 |
| 중단 요청 (취소, 그만) | 저장 여부 확인 |
Q&A 원본 저장 규칙
⚠️ 핵심: 전체 대화를 원문 그대로 저장
요약/축약/편집 절대 금지. 인터뷰 중 오간 모든 Q&A를 빠짐없이, 사용자가 말한 그대로 기록한다.
- 사용자의 답변을 요약하거나 다듬지 말 것
- 대화 순서 그대로 Q:/A: 쌍으로 기록
- 사용자가 길게 답변했으면 길게 그대로 저장
- 짧게 답변했으면 짧게 그대로 저장
선택지 치환 필수
사용자가 A/B/C/D 또는 1/2/3/4로 선택하면, 해당 선택지의 실제 텍스트로 치환하여 저장
# 대화 중
Q: 어떤 분들이 참여하면 좋을까요?
예시:
A. 코딩 경험 없이 업무 자동화하고 싶은 마케터
B. 노코드로 사이드프로젝트 만들고 싶은 직장인
C. AI로 반복 작업 줄이고 싶은 스타트업 대표
D. 개발자 없이 MVP 만들고 싶은 기획자
사용자: B
# Q&A 원본 저장 시
Q: 어떤 분들이 참여하면 좋을까요?
A: 노코드로 사이드프로젝트 만들고 싶은 직장인
절대 금지:
- "B" 또는 "2"만 저장 ❌
- 사용자 답변을 요약/재작성 ❌
- 대화 일부 생략 ❌
Airtable 저장
scripts/airtable.ts 사용. 상세 사용법 → references/airtable-usage.md
⚠️ 실행 방법 (중요!)
절대 금지: bun -e "..." 인라인 실행 ❌ — generatedContent의 백틱()이 쉘 파싱 에러를 낸다. **필수**: 별도 스크립트 파일(/tmp/submit.ts등) 생성 후bun run`.
경로별 저장 함수 (2단계 구조)
| 경로 | 함수 | 토큰 | 동작 |
|---|
| 표준 (폼 제출자, 모든 환경) | submitDetailViaApi(input, status) | 불필요 | 전화번호로 레코드 찾아 상세 채우고 상태 갱신 (Vercel API 경유) |
| 운영진 직접 (폼 제출자) | fillApplicationDetail(recordId, detail, status) | 필요 | Airtable에 직접 update + 제출 승격 |
| 폴백 (폼 미제출, 운영진) | createApplication(app, status) | 필요 | 기본정보까지 전부 포함해 신규 생성 |
🚫 폼 제출자에게 createApplication 재호출 금지 — 중복 레코드 발생. 반드시 update 계열(submitDetailViaApi/fillApplicationDetail).
표준 경로 예시 (외부 스터디장 — 토큰 없이)
import { submitDetailViaApi } from "/path/to/scripts/airtable.ts";
const r = await submitDetailViaApi({
phone: "01012345678",
category: "개발&에이전트",
tool: "Claude Code",
difficulty: "입문",
generatedTitle: "제목",
generatedContent: `# 마크다운 (백틱 OK)`,
qaRaw: "Q&A 원본",
aiTalkAvailability: "7/7(화) 입문 — 참석",
}, "제출완료");
console.log(r.message);
기타 함수
import { getApplicationByPhone, getCurrentGisu, checkApplicationDeadline } from "./scripts/airtable.ts";
await checkApplicationDeadline();
const existing = await getApplicationByPhone("01012345678");
CLI 테스트
bun run scripts/airtable.ts --test
bun run scripts/airtable.ts --create-test
bun run scripts/airtable.ts --check-deadline
확정 전 → 확정 스터디 리스트 레코드 생성 (필드 매핑 가이드)
🚨 21기 사고 교훈: 확정 전 → 확정으로 레코드를 복사할 때 스터디시간 → 스터디 시간 매핑이 누락되어 LMS 홈화면 "다가오는 일정"에 스터디 일정이 안 나오는 버그 발생.
스터디장 선발 확정 후 확정 전 스터디 리스트(tbluZH7N0lZIRlh5R) → 확정 스터디 리스트(tblP0bMmo1xuLnX2v)로 레코드를 생성할 때, 반드시 아래 필드를 모두 매핑해야 합니다.
필수 매핑 필드 (필드명 불일치 주의!)
| 확정 전 스터디 (원본) | 확정 스터디 (대상) | 비고 |
|---|
스터디시간 (공백 없음) | 스터디 시간 (공백 있음) | ⚠️ 필드명 다름! 21기에 누락됨 |
스터디 시작일 | 스터디 시작일 | 동일 |
주제명 | 주제명 | 동일 |
요일 | 요일 | 확정 전에 없을 수 있음 (배분 시 설정) |
스터디장_이름 | 스터디장 이름 | 필드명 미묘하게 다를 수 있음 — 확인 필수 |
체크리스트
확정 스터디 레코드 생성 시:
