코딩 무경험자 60여 명이 이틀 만에 배포한 방법: 틀렸던 것과 다행이었던 것

9월에 가톨릭대학교 신입생 60여 명과 AI 부트캠프를 했습니다. 대부분 코딩을 해 본 적이 없는 학생들이었습니다. 이틀이 끝났을 때 각자 자기 이름이 걸린 홈페이지와 자기가 만들고 싶던 서비스를 인터넷 주소로 갖고 갔어요. 무엇을 했는지는 운영 사례 페이지에 정리해 뒀으니, 이 글에는 그 페이지에 안 쓴 것을 씁니다. 준비하면서 틀렸던 것, 당일에 다행이었던 것, 다음에 바꿀 것.

설계의 기준은 "이해"가 아니라 "완주"였습니다

처음 제안서를 쓸 때 정한 문장입니다. 수십 명이 한 공간에서 실습하면 가장 흔한 실패는 내용이 어려워서가 아니라, 한 번 막힌 학생이 끝까지 따라오지 못하고 빠지는 거예요. 그래서 세 가지를 고정했습니다. 매 구간이 눈에 보이는 결과물로 끝난다, 막힌 학생을 기다리게 하지 않는다, 팀이 아니라 개인이 만든다. 이 세 가지는 끝까지 유지했고 다음에도 그대로 갈 생각입니다.

틀렸던 것: 도구를 바꾸면 문서가 따로 논다

준비 중에 기본 도구를 한 번 바꿨습니다. 그러자 커리큘럼, 설치 안내, 플랫폼 카드, 포스터가 서로 다른 시점에 고쳐지면서 홍보물에 예전 도구 이름이 남았어요. 학교 담당자분이 발견해 주셨습니다. 배운 것은 단순합니다. 도구를 바꾸면 그날 모든 문서를 한 번에 훑는다. 문서마다 따로 고치면 반드시 하나가 남습니다.

틀렸던 것: 90명 기준으로 준비했지만 실제는 그보다 적었습니다

좌석, 조교, 자료는 정원 기준으로 준비했고 실제 참가는 60여 명이었습니다. 비어 있는 자리가 생기면 조교 배치가 흐트러져요. 다음에는 행사 이틀 전에 실제 참가 인원으로 좌석과 존을 다시 짜는 단계를 일정에 넣으려고 합니다.

틀렸던 것: 인터넷을 "되는지"만 확인했습니다

첫날 오후, 수십 명이 동시에 코딩 에이전트를 돌리기 시작하자 강의장 인터넷이 느려졌습니다. 서버 쪽 부하는 미리 점검했는데, 정작 학생 노트북에서 나가는 트래픽은 "Wi-Fi 되나요" 수준으로만 확인했던 거예요. 에이전트 코딩은 패키지 설치와 배포 업로드, API 스트리밍이 학생마다 동시에 일어나서 일반 강의와 트래픽 성격이 다릅니다. 다음부터는 AP를 여러 대로 나누고 5GHz 전용으로 쓰는 것, 무거운 설치를 사전과제로 빼는 것, 존별 LTE 라우터를 예비로 두는 것을 준비 목록에 넣었습니다. 기준 수치와 함께 해커톤 기획 체크리스트의 인터넷 항목에 정리했습니다.

다행이었던 것: 첫날 첫 시간에 "되네?"가 나왔습니다

첫날은 초보자에게 "AI로 이런 게 된다, 내 홈페이지를 내가 만들 수 있다"를 눈으로 보여 주는 것으로 시작했습니다. 학생은 행사 전에 설문을 냈고 저는 그 답으로 학생마다 프롬프트를 미리 써 갔어요. 학생이 한 일은 사실상 그 문서를 순서대로 붙여 넣는 것뿐이었는데, 한 시간쯤 지나자 각자의 홈페이지가 인터넷 주소로 올라갔습니다. 이 순간이 이틀 전체를 끌고 갔습니다. 오후에 사례 발표를 하고 싶은 사람을 물었을 때 절반 가까이가 손을 들었어요. 발표를 시키려고 애쓰는 게 아니라 발표할 자리를 나눠야 하는 문제가 됐습니다.

다행이었던 것: 간식 테이블이 쉬는 시간을 만들었습니다

뒤쪽에 간식 테이블을 두고 오후 중간에 한 번 채웠습니다. 따로 쉬는 시간을 선언하지 않아도 학생이 자기 속도로 일어났다 돌아왔고 조교가 그 틈에 막힌 자리를 돌 수 있었습니다. 작은 것인데 다음에도 뺄 생각이 없습니다.

다행이었던 것: 동시 접속을 미리 눌러 봤습니다

행사 플랫폼에서 학생 전원이 같은 순간에 제출하고 투표합니다. 행사 전에 그 규모의 동시 접속 시나리오로 부하를 걸어 봤고 데이터베이스 연결이 한계에 걸리는 문제를 찾아 고쳤습니다. 당일에 발견했다면 투표 시간에 화면이 멈췄을 거예요. 플랫폼을 직접 만들어 쓸 때는 "당일 규모로 미리 눌러 보기"가 기능 개발보다 중요했습니다.

다행이었던 것: 학생별 자료가 오전을 살렸습니다

첫날 오전 실습은 학생이 자기 설문 답으로 만든 설계도 5장을 AI에 붙여 넣는 것으로 시작했습니다. 빈 화면에서 "뭐라고 쓰지"로 멈추는 학생이 거의 없었어요. 대신 자료를 만드는 쪽은 예상보다 훨씬 오래 걸렸습니다. 설문 수정본이 계속 들어와서 행사 전날 밤까지 배치를 나눠 만들었거든요. 다음에는 설문 마감을 더 앞당기고 마감 뒤 수정은 공통 프롬프트로 안내할 생각입니다. 방법은 설문 답으로 학생마다 다른 프롬프트를 만든 방법에 있습니다.

다행이었던 것: 손들기가 화면에 보였습니다

강당에서 "모르는 사람 손 드세요"는 작동하지 않습니다. 학생이 플랫폼 좌석도에서 자기 자리의 손을 들면 담당 조교 화면에 뜨고 3분이 넘으면 강조되게 했어요. 조교가 자기 존만 보면 되니까 순회하다 놓치는 학생이 줄었습니다.

다음에 바꿀 것

• 설문 마감을 행사 일주일 전으로 당기고 그 뒤에는 공통 자료로 안내한다.
• 실제 참가 인원 확정 → 좌석·존 재배치 단계를 행사 이틀 전에 넣는다.
• 도구·일정이 바뀌면 문서 전체를 같은 날 훑는 체크리스트를 둔다.
• 결과물 공개 동의를 신청 단계에서 받는다. 행사 뒤에 받으면 전시에 올릴 수 있는 결과물이 줄어듭니다.
• 인터넷은 "되는지"가 아니라 "몇 명이 동시에 설치·배포해도 되는지"로 확인한다. AP 여러 대·5GHz 전용·예비 LTE 라우터.

같은 방식으로 학교에서 부트캠프를 열고 싶으시다면 대학 AI 부트캠프 안내를 봐 주세요. 운영 체크리스트는 바이브 코딩 해커톤 기획 체크리스트에 따로 정리했습니다.

다음 단계

• 바이브 코딩 해커톤 기획 체크리스트
• 대학생 AI 리터러시, 강의 말고 만들기로

출처와 확인 (2026-09-21)

• 가톨릭대학교 AI 부트캠프 운영 사례 (2026-09-19~20 운영 기록)
• Supabase 문서: 연결 풀링 (동시 접속 점검 때 참고한 문서)