구글 폼으로 시작해서 Aside 그리고 AI 검색되는 신청 사이트까지 — 코드 한 줄 안 쓰고 만들기

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

구글 폼에서 Aside를 거쳐 AI 검색이 가능한 신청 사이트까지, 직접 코드를 작성하지 않고 만들 수 있지만 설계·권한 승인·결과 검증은 사람이 맡아야 한다.

📌 핵심 요점

1. 자동화의 출발점은 설문 설계서다. 엑셀에 필드명·질문·형식·선택지·분석 목적을 정리하면, 같은 자료를 구글 폼 생성과 브라우저 조작, 노션 데이터베이스 구성에 활용할 수 있다.
2. 구글 폼 제작에는 두 가지 자동화 경로가 제시된다. ChatGPT가 만든 Apps Script를 사용자가 붙여 넣고 실행하거나, Aside가 화면을 조작하며 질문과 선택지를 입력하도록 맡긴다. Aside 방식에서는 사용자가 스크립트를 붙여 넣는 과정도 생략된다.
3. 노션 AI에는 응답 데이터베이스와 설문 뷰를 함께 요청한다. 시연에서는 열 개 문항이 생성됐으며, 공유 범위를 웹의 모든 사용자로 바꾼 뒤 외부 응답 화면을 확인했다.
4. Claude Code로 신청·내역 확인·관리자 조회 기능과 SQLite 저장 방식을 구현한 뒤, Cloudflare Workers와 D1에 맞춰 앱을 변경하고 배포했다. Aside가 계정 연결과 배포 작업을 이어받았으며, 사용자는 로그인·접근 승인·관리자 비밀번호 입력을 수행했다.
5. 관리자 AI 검색은 자연어를 SQL로 변환해 데이터베이스를 조회한다. 접수와 임시 저장을 구분하고 이메일·이름 등 반환 컬럼을 바꾸는 결과를 확인했다. 무료 플랜의 모델 제약으로 수정이 필요했으며, 슬랙 알림은 웹훅 코드 준비 이후 실제 연동 설정이 남아 있다.

🧩 배경과 문제 정의

• 회원 가입, 주문, 예약, 상담과 참가 신청처럼 인터넷의 많은 기능은 여전히 폼을 중심으로 작동한다. 달라진 것은 폼 자체보다 폼을 만드는 방법이다.
• 질문과 선택지가 미리 정해져 있어도 구글 폼에 하나씩 입력하면 반복 작업이 많아진다. 문항 설계 자료를 AI가 활용하면 이 입력 과정을 자동화할 수 있다.
• 바이브랩스 오프라인 모임 신청을 사례로, 구글 폼과 노션의 자동화를 거쳐 신청·내역 확인·관리자 화면·데이터베이스를 갖춘 자체 사이트와 외부 배포까지 확장한다.

🕒 시간순 섹션별 상세정리

1. 폼의 역할은 유지되고 제작 방식은 달라진다

• 과거 델파이에서 빈 폼에 입력란과 버튼을 올리던 방식처럼, 지금도 회원 가입·로그인·주문·예약·설문 등은 사용자의 입력을 받는 폼으로 움직인다. [00:31]
• 같은 모임 신청 폼을 수동 입력, AI가 작성한 코드, 브라우저 에이전트의 화면 조작으로 각각 만드는 접근을 비교한다. [01:15]

2. 수동 설문 작성은 질문과 선택지마다 반복 입력이 필요하다

• 구글 폼에서 객관식 질문을 만들려면 질문 제목과 선택지들을 직접 입력하고, 추가 버튼으로 다음 질문을 생성해야 한다. [02:02]
• 직무 선택지에 개발자, 기획·PM, 대표, 마케팅·콘텐츠, 교육·강사, 사무·관리 등을 넣는 과정도 항목별 수동 입력으로 이루어진다. [02:33]

3. 엑셀 설계서를 AI가 실행 가능한 Apps Script로 바꾼다

• 엑셀에 약 열 가지 문항을 설계하고, 필드명·질문·형식·선택지 범위·분석 목적을 칼럼으로 정리한다. 이 파일이 자동 생성의 기준 자료가 된다. [03:24]
• 설계서를 ChatGPT에 첨부하고 구글 설문지를 생성할 Apps Script 작성을 요청하면, 스크립트를 직접 작성하기 어려운 사용자도 생성된 코드를 활용할 수 있다. [04:09]

4. 스크립트 실행으로 문항을 생성하고 공개 링크를 연다

• 기존 문항을 삭제한 빈 설문지에서 Apps Script 편집기를 열고, AI가 만든 코드를 붙여 넣어 저장·실행한다. 실행 과정에는 권한 검토와 승인이 필요하다. [05:02]
• 실행 로그에 완료 표시가 나타나고, 엑셀 설계서에 있던 문항들이 구글 폼에 자동으로 생성된다. 미리 보기에서도 응답 가능한 형태를 확인할 수 있다. [06:14]

5. Aside는 연결된 AI 모델로 브라우저 화면을 조작한다

• Aside는 사용자가 구독하는 AI 모델을 연결해 웹브라우저의 내용을 직접 제어할 수 있는 에이전트 브라우저다. 새 구글 폼을 열어 둔 상태에서 문항 입력을 맡긴다. [08:03]
• 사이드 패널에서 모델을 설정하고, 앞서 사용한 설문 설계 엑셀 파일을 채팅창에 첨부한다. 시연에서는 연결해 둔 모델 중 Claude를 사용한다. [08:45]

6. 화면 조작과 스크린샷 검토로 스크립트 없이 폼을 완성한다

• Aside는 현재 화면을 캡처하고 설계서 순서대로 질문과 선택지를 입력한다. 입력할 때마다 스크린샷으로 진행 상태를 확인한 뒤 다음 문항을 추가한다. [09:46]
• 문항 종류에 맞는 메뉴를 자동으로 선택하며, 마지막에는 전체 설계 내용이 제대로 반영됐는지 스크린샷으로 검토한다. [10:40]

7. 노션에서는 응답 데이터베이스와 설문 뷰를 함께 요청한다

• 새 노션 페이지에서 노션 AI를 열고, 기존 프롬프트와 설문 설계 엑셀 파일을 전달한다. [12:11]
• 구글 폼용 요청을 수정해 설계 시트에 맞는 데이터베이스를 먼저 만들고, 설문 응답용 뷰도 함께 추가하도록 요청한다. [13:05]

8. 노션의 열 개 문항을 확인하고 외부 응답을 허용한다

• 생성된 데이터베이스에는 원하는 열 개 문항이 칼럼으로 추가되고, 설문 뷰에서는 응답용 화면이 나타난다. [14:19]
• 양식 공유 범위를 계정 사용자에서 링크가 있는 웹의 모든 사용자로 바꾸고 폼 링크를 복사하면, 외부에서도 설문에 응답할 수 있다. 실제 링크 접속으로 설문 화면을 확인한다. [14:59]

9. Claude Code에서 자체 신청 앱의 계획과 저장 방식을 정한다

• Claude 데스크탑의 코드 모드에서 새 프로젝트를 시작하고, 작업 폴더를 폼 앱으로 설정해 자체 설문 사이트 개발을 준비한다. [15:49]
• 요구사항을 간단히 입력하고 /plan으로 계획 모드를 활성화한다. 구현 목표는 최대한 간단한 신청 앱이다. [16:42]

10. 계획 수락 뒤 구현과 화면 테스트가 자동으로 계속된다

• 제안된 계획을 검토하고 ‘수락 및 자동 모드’를 선택하면, AI가 계획에 따라 구현을 진행한다. [17:27]
• 참가 신청 화면을 개발하면서 직접 테스트한 스크린샷을 제공하고, 발견한 버그를 수정한다. 모바일 화면 크기에서도 문제를 찾아 수정하는 과정이 포함된다. [18:01]

11. 신청·내역 확인·관리자 조회가 로컬 앱에서 작동한다

• 참가 신청 화면에는 이름·연락처 등 정보, 선택 항목, 비밀번호, 개인정보 수집 동의와 신청 버튼이 마련된다. [19:13]
• 테스트 정보를 입력해 신청하면 접수가 완료되고, 내역 확인에서 기존 신청 내용을 볼 수 있다. [19:36]

12. 외부 배포를 위해 Workers와 D1에 맞춰 앱을 옮긴다

• 로컬 앱은 현재 자신의 컴퓨터에서만 볼 수 있으므로 외부 배포가 필요하다. 배포 대상으로 Cloudflare Workers, 데이터베이스로 D1을 선택한다. [20:29]
• SQLite와 거의 같은 방식의 D1을 활용하는 배포 방법을 요청한다. Claude Code가 직접 설정할 수 있을지는 불확실하며, 어려우면 Aside용 작업 지시서나 연동을 활용하는 대안을 둔다. [21:12]

13. 배포 지시서를 Aside에 넘기고 계정 접근을 승인한다

• 계정 연결 방식 중 Aside에 작업 지시서를 맡기는 방법을 선택한다. 프로젝트 폴더와 deploy.md를 참고해 Cloudflare 설정을 진행하도록 전달한다. [22:30]
• Aside는 Wrangler 로그인을 진행하며 터미널 명령도 실행한다. 사용자는 열린 Cloudflare 화면에 직접 로그인하고, 완료 사실을 알려 다음 작업을 이어 간다. [23:23]

14. 관리자 비밀번호를 설정하고 Wrangler의 역할을 이해한다

• 다음 작업에는 데이터베이스 ID 교체와 관리자 비밀번호 입력이 포함된다. 비밀번호 설정을 위해 Aside가 제시한 터미널 명령을 Claude Code에 전달한다. [24:37]
• Claude Code가 터미널 창을 열면 사용자가 비밀번호를 입력한다. 설정이 끝난 뒤 Aside에 입력 완료를 알려 배포 작업을 계속 진행한다. [25:26]

15. 배포된 사이트와 D1 연결을 확인하고 최종 주소를 검증한다

• 설정한 관리자 비밀번호로 로그인한 사이트는 로컬호스트가 아닌 Cloudflare 배포 주소다. 데이터베이스도 로컬 SQLite에서 D1으로 연결되며 신청·내역 확인·관리자 기능이 작동한다. [27:47]
• 배포 상태를 다시 점검하면 D1 생성, 데이터베이스 ID 교체, 첫 배포가 완료되어 있고 테스트 신청 한 건도 들어 있다. 최신 테이블과 코드 반영을 확인한 뒤 주소 확보를 위해 다시 배포한다. [28:32]

16. 신청 완료를 슬랙 알림으로 연결

• 사용자가 신청을 완료하면 슬랙으로 메시지를 보내도록 기능 추가를 요청한다. 배포 이후에도 신청 현황을 실시간으로 확인하기 위한 확장이다 [30:29]
• 슬랙 전송용 웹훅 코드는 준비됐으며, 실제 연동에는 슬랙에 접속해 안내된 설정을 순서대로 수행하는 작업이 남아 있다 [30:53]

17. 자연어를 SQL로 바꾸는 검색과 무료 모델의 제약

• 관리자 검색은 AI가 직접 답변하는 방식이 아니라, “지난주에 신청한 사람을 알려줘” 같은 문장을 SQL로 변환해 데이터베이스를 조회하는 방식이다. 테스트용 시드 데이터 10개를 로컬 환경과 배포 환경 양쪽에 추가하도록 요청한다 [32:05]
• AI 모델은 계정 안에서 실행하고 무료 사용량을 활용할 수 있다는 이유로 Cloudflare Workers AI를 선택한다. Claude API는 별도 API 키 발급과 비용이 필요한 대안이다 [32:58]

18. 접수 상태와 요청 컬럼을 바꿔 검색 결과 검증

• 배포된 화면에서 “이번 주에 접수한 이메일 명단”을 조회하면 자연어가 SQL로 변환되고 이메일 하나가 반환된다. 같은 날짜의 다른 기록은 임시 저장 상태여서 접수 명단에 포함되지 않은 것으로 확인한다 [35:03]
• 검색 조건에 접수와 임시 저장을 함께 포함하자, 접수한 사람과 임시 저장한 사람 두 명이 반환된다. 신청 상태에 따라 조회 대상이 달라지는 결과를 확인한다 [35:20]

19. 신청 폼의 확장과 사람이 맡는 설계 판단

• AI는 사용자의 자연어를 SQL로 바꾸고, 데이터베이스에 실시간으로 쿼리를 실행해 결과를 가져오는 중간 역할을 한다. SQL을 몰라도 저장된 내용을 검색할 수 있으며, 다른 데이터베이스의 내용까지 연계해 조회하는 활용도 가능하다 [36:22]
• 처음의 폼 하나는 신청 정보를 저장하고 조회하면서, 사람을 기억하는 시스템에 가까운 형태로 확장된다 [36:35]

🧾 결론

• 폼은 여전히 사용자 입력의 중심이지만, 제작 과정은 반복 입력에서 설계서와 자연어 요구사항을 전달하는 방식으로 바뀐다.
• 코드 한 줄을 직접 쓰지 않는 제작에도 AI가 생성하는 코드, 데이터베이스, 배포 설정이 필요하다. 사용자의 역할은 요구사항 결정과 승인, 작동 확인으로 이동한다.
• 시연의 최종 결과는 실제 D1 데이터베이스를 사용하는 신청 사이트다. 신청·내역 확인·관리자 조회와 자연어 검색까지 확인했지만, 모든 확장 기능이 완료된 것은 아니다.

📈 투자·시사 포인트

• AI 도구의 활용 범위가 문항 작성에서 브라우저 조작, 앱 구현, 외부 배포, 데이터 조회로 이어진다. 시연은 여러 도구를 연결해 업무 기능을 완성하는 사례를 보여준다.
• 구독형 모델 연결, 별도 API 비용, 무료 플랜의 모델 지원 여부는 서로 다른 조건이다. 도구를 선택할 때 구독 여부만으로 전체 작업의 비용과 사용 가능 범위를 판단하기 어렵다.
• 신청 정보의 저장과 검색까지 연결되면 폼은 일회성 입력 화면을 넘어 운영 데이터를 활용하는 시스템으로 확장된다. 필요한 데이터와 조회 조건을 설계하는 능력이 함께 중요해진다.
• 이 사례만으로 특정 기업의 수익성이나 투자 매력을 판단할 수는 없다. 확인된 시사점은 제작 방식의 변화와 도구별 제약이며, 반복 작업의 절감 규모는 제시되지 않았다.

⚠️ 불확실하거나 확인이 필요한 부분

• Workers 무료 플랜에서 GLM 5.3 Flash가 지원되지 않아 모델을 바꿨지만, 최종 사용 모델명은 자막에 나오지 않는다. 같은 환경에서 재현하려면 현재 지원 모델과 사용 한도를 확인해야 한다.
• 슬랙 알림은 웹훅 코드가 준비된 단계다. 실제 슬랙 설정과 메시지 수신 완료는 제시된 내용에서 확인되지 않는다. 이전 참가자의 재신청 여부를 묻는 기능도 초기 목표로만 언급된다.
• 노션의 주간 한도와 다섯 시간 한도에 관한 설명은 시연자의 관찰과 판단이다. 확정된 요금제 정책으로 받아들이기보다 실제 계정의 안내를 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 필드명·질문·문항 형식·선택지·분석 목적을 포함한 설문 설계서를 만들고, 자동 생성 결과와 대조한다.
• 구글 폼이나 노션 설문을 게시한 뒤 외부 링크에서 직접 응답하고, 저장된 데이터까지 확인한다.
• 자체 앱의 신청·내역 확인·관리자 조회를 모바일 화면에서도 점검하고, 배포 후 D1 저장과 조회가 이어지는지 확인한다.
• 자연어 검색에 접수·임시 저장 상태와 기간 조건을 바꿔 입력하고, 반환된 이름·이메일이 예상한 기록과 일치하는지 검증한다.

❓ 열린 질문

• 최종 배포에 사용된 Workers AI 모델은 무엇이며, 무료 사용량을 넘으면 운영 비용과 검색 동작은 어떻게 달라지는가?
• 자연어를 SQL로 바꾸는 과정에서 허용할 조회 범위와 개인정보 접근 권한은 어떻게 제한했는가?
• 슬랙 알림과 이전 참가자 재신청 확인까지 연결하려면 어떤 추가 설정과 데이터 설계가 필요한가?