매달 반복되던 웨비나 운영, AI와 함께 신청부터 집계까지 다시 설계한 이야기

📝 한줄 요약

매달 웨비나를 운영할 때마다 신청 링크를 만들고, 접수 테이블을 정리하고, 안내 흐름을 다시 맞추는 일이 반복됐습니다. 이번에는 AI와 함께 신청 페이지, 피드백 페이지, 운영 도구, Airtable 집계 구조를 하나의 흐름으로 다시 설계하면서 운영 방식 자체를 새롭게 정리했습니다.

바쁘시면 이것만 읽어도 됩니다.

웨비나 운영에서 가장 불편했던 지점은 매달 비슷한 세팅을 반복해야 한다는 점이었습니다.
이번 작업에서는 단순히 신청 폼 하나를 만드는 데 그치지 않고, 신청 접수부터 피드백 수집, 집계 구조까지 한 번에 다시 살펴봤습니다.
특히 익숙하게 써오던 월별 테이블 구조가 장기적으로는 더 복잡해질 수 있다는 점을 AI가 먼저 짚어준 것이 인상적이었습니다.
그 결과, “월이 바뀔 때마다 다시 세팅하는 운영”에서 “운영 구조 자체를 설계하는 방식”으로 관점이 바뀌기 시작했습니다.
앞으로는 신청, 안내, 피드백, 월별 비교가 더 매끄럽게 이어지는 운영 시스템으로 발전시키는 것이 목표입니다.

🎯 이런 분들께 도움돼요

교육 프로그램이나 커뮤니티 행사를 꾸준히 운영하는 분
신청, 안내, 피드백 흐름이 매번 끊겨 운영 피로가 쌓이는 분
익숙한 방식으로 버티고 있지만, 이제는 구조를 다시 손봐야겠다고 느끼는 분

😫 문제 상황 (Before)

제가 가장 힘들었던 것은 단순히 운영 업무가 많다는 사실이 아니었습니다. 같은 일을 월마다 다시 세팅해야 하는 구조 자체가 더 큰 문제였습니다.

연속된 사람의 수를 보여주는 막대 차트

신청을 받는 방식, 안내를 보내는 방식, 피드백을 받는 방식이 하나의 흐름으로 이어져 있지 않다 보니, 월이 바뀔 때마다 새 링크를 만들고, 새 테이블을 맞추고, 어디까지 진행됐는지를 다시 확인해야 했습니다.

처음에는 이 방식이 익숙해서 큰 문제처럼 느껴지지 않았습니다. 하지만 웨비나를 계속 운영할수록, 이건 단순히 일이 많은 것이 아니라 구조 자체가 반복 작업을 만들어내고 있다는 사실이 더 분명해졌습니다.

그래서 이번에는 “필요한 기능 하나를 추가하는 것”보다, 신청부터 집계까지 전체 흐름을 다시 설계해보자는 마음으로 작업을 시작했습니다.

🛠️ 사용한 도구

도구명: Claude Code, Codex CLI
운영 도구: Airtable, Vercel
결과물 성격: EXE 운영 도구 정리, 신청/피드백 웹 페이지 분리, 집계 구조 재설계

🔧 작업 과정

반복 작업의 원인을 먼저 짚은 순간

처음 생각은 단순했습니다. 기존 웨비나 자동화 앱을 이어서 손보고, 필요한 페이지와 링크를 만들고, 4월 운영에 맞게 조금만 조정하면 될 것 같았습니다.

예를 들어 저는 이렇게 요청했습니다.

“웨비나접수를 3월_웨비나접수로 변경해줘. 그리고 매달마다 새로운 접수 테이블이 생기는 구조로 변경해줘.”
“그럼 EXE에서 월별 테이블을 선택할 수 있는 거야? 아니면 어떤 구조가 더 좋아? 추천해줘.”

그런데 여기서 AI는 바로 기능 추가로 들어가지 않았습니다. 오히려 지금 방식이 왜 반복 작업을 만들고 있는지부터 짚어주었습니다. 저는 월별 테이블을 계속 만드는 방식이 익숙했지만, AI는 이 구조가 집계와 연동까지 가면 점점 더 복잡해질 수 있다고 설명했습니다.

숫자 수를 보여주는 스프레드시트의 스크린샷
중국어 텍스트가 포함된 중국 웹사이트의 스크린샷

이 순간이 특히 인상적이었습니다. AI가 단순히 “원하는 대로 바꿔주는 도구”가 아니라, 제가 너무 당연하게 받아들이고 있던 운영 방식을 한 발 떨어져 다시 보게 해주는 역할을 했기 때문입니다.

신청 링크를 만드는 일이 아니라, 운영 흐름을 나누는 일

그 다음에는 신청 페이지와 피드백 페이지를 각각 별도의 링크로 운영할 수 있도록 정리했습니다. 단순히 폼 하나를 만드는 데서 끝나는 것이 아니라, 기존 EXE와는 분리된 웹 포털 형태로 구성해 실제 운영용 링크까지 만들었습니다.

당시 저는 이렇게 요청했습니다.

  1. 신청접수작성 페이지와 링크가 필요해.

  2. 신청접수는 매월 필요해. 4월 웨비나부터 시작하면 돼.

  3. 피드백작성 페이지와 링크가 필요해.

  4. 이걸 Vercel로 만드는 게 나은지, Airtable로 만드는 게 나은지도 추천해줘.

여기서 좋았던 점은 AI가 특정 도구 하나만 밀어붙이지 않았다는 점입니다. 운영 목적을 기준으로 판단해, 공개 신청과 피드백은 웹으로 분리하고, 운영 데이터는 Airtable에 두는 방식이 더 적절하다고 정리해주었습니다.

신청서 스크린샷
한국어 지원서 스크린샷
한국어와 영어 텍스트가 표시된 컴퓨터 화면
한국 이메일 계정의 스크린샷

그 결과 신청 접수, 피드백 수집, 운영 도구가 각각 역할을 나눠 가지는 구조가 만들어졌고, 이전보다 운영 흐름이 훨씬 선명해졌습니다.

문구를 고치는 것이 아니라, 다음 달에도 쓸 수 있는 구조로 바꾸기

신청 페이지를 만든 뒤에는 단순히 화면을 예쁘게 다듬는 것보다, 다음 달에도 그대로 재사용할 수 있는 구조로 만드는 데 집중했습니다.

저는 신청 페이지에 들어가야 할 항목을 이렇게 정리했습니다.

  • 제목

  • 도입 문단

  • 일정 / 방식 / 정원 / 참가비

  • 강사 1 정보와 세션 소개

  • 강사 2 정보와 세션 소개

  • 추천 대상

  • 오픈채팅 안내

  • 입금 안내 / 환불 규정

그리고 “세미나 홍보 문구는 내가 직접 입력하고 수정할 수 있도록 해달라”고 요청했습니다. 당시 4월 문구는 아직 정해지지 않았기 때문입니다.

이 요청 이후 신청 페이지는 문구가 코드 안에 고정된 상태가 아니라, 나중에 항목만 채워 넣으면 되는 골격형 구조로 바뀌었습니다. 저에게는 이 부분이 꽤 중요했습니다. 한 번 보기 좋은 페이지를 만드는 것보다, 다음 운영에서도 다시 쓸 수 있어야 실제로 도움이 되기 때문입니다.

이후에는 문항 번호 조정, 불필요한 질문 제거, 선택 해제 UX처럼 사소해 보이는 부분까지 다듬으면서 페이지가 점점 더 “운영 도구답게” 정리되어 갔습니다.

결국 핵심은 집계 구조였다

작업을 진행할수록, 신청 페이지보다 Airtable 구조가 더 중요한 문제라는 걸 느끼게 됐습니다. 특히 과거 데이터와 월별 집계를 어떻게 연결할지 이야기하면서, 이 작업이 단순한 “폼 만들기”가 아니라 “운영 기준 정하기”라는 사실이 더 분명해졌습니다.

예를 들어 저는 이런 요청도 했습니다.

“테이블 ‘웨비나_월별집계’에 합계가 반영되지 않았어. 다른 테이블들과 연동시켜줘.”
“코딩이 아니라 실제 Airtable 기능으로 상호 연동하게 하려면?”
“가장 합리적이고 지속 가능한 방식을 다시 한번 정리해줘.”
“좋아. 그럼 너의 추천대로 변경해줘.”

처음의 저는 월별 테이블을 계속 유지하는 것이 자연스럽다고 생각했습니다. 하지만 AI는 장기적으로 보면 통합 테이블을 중심에 두고, 집계 테이블이 그 데이터를 읽어오는 구조가 훨씬 안정적이라고 제안했습니다.

이 지점에서 “익숙한 방식이 곧 좋은 방식은 아니다”라는 사실을 실감했습니다. 그리고 이것이 이번 작업에서 얻은 가장 큰 교훈이기도 했습니다.

✅ 결과 (After)

Before vs After

항목

Before

After

월 변경 대응

매달 링크와 테이블을 다시 맞추는 느낌이 강했음

운영 구조를 어떻게 잡을지 기준이 생김

신청/피드백 흐름

신청, 안내, 피드백이 각각 분리되어 있었음

하나의 운영 흐름으로 보기 시작함

집계 기준

익숙한 월별 테이블 방식에 머물러 있었음

통합/집계 구조를 다시 설계하는 방향으로 전환

결과물

신청 페이지와 피드백 페이지를 별도 링크로 운영할 수 있는 구조
EXE 기반 운영 도구와 웹 포털의 역할 분리
월별 집계와 장기 운영을 고려한 Airtable 구조 재설계 방향 정리

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

효과적이었던 것

단순히 “이 기능 만들어줘”라고 요청하는 것보다, “현재 구조에서 무엇이 반복 작업을 만들고 있는지 먼저 봐줘”라고 요청했을 때 훨씬 더 좋은 답을 얻을 수 있었습니다.

또한 익숙한 운영 방식이라도 집계와 연동까지 함께 생각하면, 화면보다 저장 구조를 먼저 다시 설계하는 편이 결국 훨씬 덜 힘들다는 것도 배웠습니다.

이렇게 하면 아쉬워요

당장 필요한 화면 하나만 만들고 끝내면, 다음 달에 같은 문제를 다시 만나게 될 가능성이 큽니다.

또 익숙하다는 이유만으로 월별 테이블 같은 구조를 계속 유지하면, 나중에 비교와 집계 단계에서 더 큰 비용을 치르게 됩니다.

🌍 다른 업무에 적용한다면?

이 경험은 웨비나 운영뿐 아니라, 매달 반복되는 신청형 업무 전반에 적용할 수 있다고 느꼈습니다. 교육 프로그램 접수, 소규모 행사 운영, 커뮤니티 신청 관리처럼 “폼은 있지만 운영 흐름은 끊겨 있는” 업무라면, AI와 함께 구조부터 다시 보는 방식이 특히 잘 맞을 것 같습니다.

🚀 앞으로의 계획

지금 만든 결과물을 바탕으로, 앞으로는 신청부터 입금 확인 이후 안내, 피드백, 월별 비교까지 더 매끄럽게 이어지는 운영 시스템으로 발전시키고 싶습니다. 핵심은 기능을 더 많이 붙이는 것이 아니라, 운영자가 달이 바뀌어도 다시 처음부터 세팅하지 않아도 되는 구조를 만드는 것입니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 반복 운영 구조 점검용

나는 매달 같은 유형의 행사를 운영하고 있어. 지금 쓰고 있는 신청, 안내, 피드백, 집계 방식에서 어떤 구조가 반복 작업을 만들고 있는지 먼저 분석해줘. 기능 추가보다 운영 흐름 전체를 기준으로 더 지속 가능한 구조를 제안해줘.

프롬프트 2: 익숙한 구조를 재검토할 때

지금은 익숙해서 이렇게 운영하고 있지만, 장기적으로 집계와 연동까지 고려하면 더 나은 저장 구조가 있는지 검토해줘. 당장 바꾸기 쉬운 방법이 아니라, 실제 운영이 덜 흔들리는 방향으로 추천해줘.

지피터스 뉴스레터

이번 주 AI, 딱 쓸 것만

매주 월요일 아침,
읽고 바로 써먹을 AI 소식만