글방

1. 한 줄로 하자면
빠르게 쏟아지는 AI 도구를 혼자 따라가기 어렵다는 문제의식에서 출발해, 비개발자 대학생들이 각자 하나씩 직접 써보고 공유하는 소규모 커뮤니티를 운영했다.

2. 기간
2026.04 ~ 2026.06

3. 규모  
총 지원자 14명 → 최종 멤버 5명 → 온보딩 포함 총 3회 운영

4. 테스트 가설
한 명이 여러 AI 도구를 얕게 보는 대신, 여러 명이 하나씩 직접 써보고 공유하면 학습 효율이 높아질까?

5. 결론 
문제의식과 초기 수요는 확인했지만, 커뮤니티 형태의 지속 가능성은 낮았다.  
다음에는 더 좁은 주제, 더 명확한 결과물, 더 정밀한 운영 구조를 가진 프로젝트형 팀으로 설계해야 한다.

들어가며,,

AI는 너무 빨리 변한다.

주 단위도, 일 단위도 아니고 시간 단위로 너무 많은 소식이 쏟아져 나온다.

ChatGPT, Claude, Gemini 같은 범용 모델뿐 아니라 Codex, Claude Code, Google Stitch, design.md, openclaw, Figma AI, n8n 같은 도구와 기법들이 거의 매주 새롭게 등장한다. 특히 X/Twitter를 보기 시작한 뒤로는 “이건 나중에 꼭 써봐야겠다” 싶은 도구가 계속 쌓였다.

문제는, 저장만 해두고 실제로 써보지는 않는다는 점이었다.

좋아 보이는 도구와 내 상황에 진짜 쓸모 있는 도구는 다르다. AI에게 ‘이거 뭐야?’라고 물으면 기능 요약은 받을 수 있다. 하지만 직접 가입해보고, 세팅해보고, 내 프로젝트에 적용해보고, 어디서 막히고, 실제 결과물이 어떤지 까지는 알기 어렵다.

이 문제를 혼자 해결하기보다, 여러 명이 나눠서 실험하면 어떨까 생각했다. 한 명이 여러 기술을 얕게 훑는 대신 여러 명이 각자 하나씩 직접 써보고 공유하면 모두가 더 빠르게 배울 수 있지 않을까 싶었다.

그렇게 시작한 것이 [AI에게쎄게얹혀사는모임]이다.

이 프로젝트는 비개발자 대학생들이 각자 새로 나오는 AI관련 기술들을 직접 실험하고, 그 사용 경험을 공유는 소규모 커뮤니티 운영 실험이었다.

결론부터 말하자면, 이 모임은 내가 기대했던 방식으로 지속되지는 못했다. 하지만 덕분에 커뮤니티가 실제로 굴러가기 위해 필요한 조건을 훨씬 구체적으로 배웠다.

이 글은 그 과정을 정리한 기록이다.

1. 문제의식: AI 정보는 쏟아지는데, 실사용 경험은 부족하다

처음 문제의식은 단순했다.

AI 도구와 정보는 너무 많은데, 정작 직접 써본 경험은 부족하다.

당시 나는 여러 개발을 직접 해보면서 AI를 많이 사용하고 있었다. 처음에는 ChatGPT나 Gemini 같은 범용 모델로 기획, 리서치, 문서화, 아이디어 정리 등을 도움받았다. 이후 Codex를 사용하면서 개발 쪽 활용이 크게 늘었다. 비개발자 입장에서 서비스를 만들고 프로토타입을 구현하려면 AI의 도움을 받을 수밖에 없었고, 실제로 많은 도움을 받고 있었다.

하지만 사용할 수 있는 도구가 늘어날수록, 따라가야 할 것도 늘어났다.

X에는 매일 새로운 AI 도구, 개발 방식, 디자인 워크플로우, 자동화 기법, 프롬프트 전략이 올라왔다. 그때마다 “이거 좋아 보인다”, “나중에 써봐야겠다” 하고 저장해뒀지만, 실제로 써보는 경우는 많지 않았다.

그러다 보니 내 안에 이런 문제가 쌓였다.

• AI 뉴스와 도구는 계속 나오지만, 그것 만으론 실제로 무엇이 쓸 만한지 판단하기 어렵다.

• 하나의 도구를 제대로 써보는 데도 시간이 많이 든다.

• 정보 요약은 AI가 해줄 수 있지만, 실사용 후기는 직접 써본 사람에게서만 나온다.

• 혼자 하면 북마크만 쌓이고 끝난다.

• 결국 “아는 것”보다 “직접 적용해보는 것”이 중요하다.

개인적으로는 이런 지론이 있다.

꿀팁은 알고만 있으면 꿀팁이 아니라 뇌용량 소비다.

직접 써봐야 꿀팁이다.

이 모임은 이 생각에서 출발했다.

AI 도구를 많이 아는 것보다, 자기 상황에 맞게 직접 써보고 판단하는 것이 더 중요하다. 그런데 혼자서는 너무 오래 걸린다. 그렇다면 여러 명이 나눠서 직접 써보고, 그 결과를 공유하면 어떨까?

2. 초기 가설: 혼자보다 나눠서 실험하면 더 빨리 배울 수 있을까?

프로젝트 초기에 세운 핵심 가설은 다음과 같았다.

한 명이 5개를 얕게 훑는 대신, 5명이 각각 1개를 깊게 파고 나누면 모두가 5개를 깊게 아는 팀이 된다.

이 문장이 이 프로젝트의 기본 구조였다.

처음 기획 문서에서는 이 모임을 다음과 같은 실험으로 정의했다.

가설 1. 분업 학습 가설

한 명이 여러 AI 도구를 얕게 훑는 것보다, 여러 명이 각자 하나씩 깊게 써보고 공유하면 학습 효율이 높아질 것이다.

가설 2. 비개발자 수요 가설

비개발자 대학생 중에도 AI 도구를 더 체계적으로 배우고 자기 프로젝트에 활용하고 싶은 수요가 있을 것이다.

가설 3. 실사용 경험 가설

단순 정보 공유보다 직접 써본 경험, 실패, 막힌 점, 결과물을 공유하는 것이 더 유용할 것이다.

가설 4. 지속성 가설

주 1회 모임과 명확한 발표 템플릿이 있으면 대학생들도 꾸준히 AI 실험을 이어갈 수 있을 것이다.

가설 5. 아카이빙 가설

Notion에 주차별 기록을 남기면 모임의 학습 결과가 휘발되지 않고, 나중에 포트폴리오나 자료로 재사용될 수 있을 것이다.

초기 목표는 꽤 야심찼다.

지금 돌아보면, 이 목표들은 실제 운영에 비해 상당히 낙관적이었다.

하지만 이 낙관적인 목표 덕분에 처음에는 구조를 나름 진지하게 설계할 수 있었다.

3. 커뮤니티 설계: 모두가 리더이자 팔로워가 되는 구조

처음 설계에서 중요하게 생각한 것은 “모두가 리더와 팔로워를 동시에 수행하는 구조”였다.

일반적인 스터디는 운영자나 발표자가 지식을 전달하고, 나머지가 듣는 방식으로 흐르기 쉽다. 하지만 내가 만들고 싶었던 모임은 누군가 한 명이 계속 가르치는 구조가 아니었다.

각자가 매주 하나의 주제를 맡고, 직접 써보고, 자신의 실험 결과를 공유한다.

그 주제를 맡은 사람은 그 세션의 리더가 된다.

다른 사람은 그 사람의 시행착오를 듣고 배운다.

즉, 모두가 리더이자 팔로워가 되는 구조를 만들고 싶었다.

기본 운영 구조

초기 설계한 운영 방식은 다음과 같았다.

주간 운영 사이클

[월~금] 각자 1개 AI 관련 도구/기법/지식 선택 → 직접 사용∙공부
    ↓
[모임 전일] Notion에 정리 문서 초안 업로드
    ↓
[모임 당일] 각자 약 30분 발표 + Q&A + 토론
    ↓
[모임 후] 피드백 반영하여 Notion 문서 최종 정리

발표 템플릿

공유의 품질을 일정 수준 이상으로 유지하기 위해 발표 템플릿도 만들었다.

각 발표자는 다음 항목을 포함하도록 설계했다.

1. 이번 주에 뭘 써봤나

2. 어떤 문제를 해결해주는가

3. 시작하기

4. 실제 사용 사례

5. 현장 워크숍

6. 소감 및 평가

7. 장점/단점

8. 추천 대상

9. 다시 쓸 의향

발표 템플릿에서 가장 중요하게 생각한 부분은 실제 사용 사례였다. 이 모임은 도구 이름을 소개하는 모임이 아니라, 직접 써본 흔적을 공유하는 모임이어야 했다.

그래서 운영 원칙도 이렇게 정했었다.

검색 요약보다 직접 써본 흔적.

4. 모집: 가볍게 시작했지만 예상보다 큰 반응이 있었다

처음에는 가볍게 시작했다. 4월 15일, 에브리타임에 모집글을 올렸다.

처음에는 “과연 사람이 있을까?” 싶었다. 그런데 모집글을 올린 지 몇 시간 만에 첫 신청자가 들어왔다.

모집에는 가능한 채널을 다 써봤다.

• 지인 제안

• 에브리타임 게시글

• 교내 포스터

모집∙신청 기간은 약 10일이었다.

최종적으로 총 14명이 신청했다.

처음 목표는 5명 정도였다. 그런데 예상보다 신청자가 많았다. 처음에는 AI를 많이 써본 헤비 유저 중심으로 선발하려고 했다. 하지만 지원자를 보면서 생각이 바뀌었다.

AI를 가볍게 쓰고 있음에도 신청한 사람들은 오히려 더 강한 학습 욕구를 가지고 있을 수 있었다고 생각했다. 그래서 단순히 경험 많은 사람만 고르기보다, 설명회를 통해 모임의 목적과 운영 방식을 충분히 설명하고, 그 이후에도 참여 의지가 있는 사람을 남기는 방식으로 바꾸었다.

즉, 선발이 아니라 자연적인 필터링을 선택했다.

모집 포스터

모집 포스터는 일부러 가볍고 자조적인 톤으로 만들었다.

“코드 한 줄 못 짜는 성대생들이 AI 시켜서 다 만드는 모임”

“비개발자만 받습니다”

“혼자 하면 못 하는 거 같이 합니다”

“혼자 따라가기 벅찬 AI, 같이 쎄게 얹혀삽시다”

이런 카피를 사용한 이유는 명확했다.

너무 진지한 AI 스터디처럼 보이면 진입장벽이 높아질 수 있다고 생각했다.

이름도 같은 이유로 정했다.

AI에게 쎄게 얹혀사는 모임.

AI를 공부 대상으로만 보지 않고, 실제로 써먹는 도구로 바라보는 태도를 담고 싶었다.

5. 설명회: 자연 필터링을 위한 첫 번째 검증

모집글과 포스터만으로는 모임의 성격을 충분히 설명하기 어렵다고 판단했다.

그래서 최종 참여자를 바로 확정하지 않고, 총 3회의 설명회를 진행했다.

설명회의 가장 큰 목적은 홍보가 아니었다.

자연 필터링이었다.

모임의 운영 방식은 가볍게 보일 수 있지만, 실제로는 매주 직접 써보고 공유해야 한다. 누군가가 강의해주는 모임도 아니고, 듣기만 해도 되는 모임도 아니다.

그래서 설명회에서는 다음을 명확히 전달하려고 했다.

• 왜 이 모임을 시작했는가

• 어떤 문제의식을 해결하는가

• 매주 무엇을 해야 하는가

• 어떤 사람이 잘 맞는가

• 어떤 사람에게는 안 맞을 수 있는가

• AI를 몰라도 괜찮지만, 아무것도 안 해도 되는 모임은 아니라는 점

설명회 자료는 이미지 생성 기반 슬라이드로 제작했다.

이것도 일종의 메시지였다. “AI를 활용하면 발표자료 제작에도 이런 식으로 사용할 수 있다”는 것을 실제 자료로 보여주고 싶었다.

설명회에서 핵심적으로 전달한 메시지는 다음과 같았다.

• AI 전문가도 개발자도 아닌 사람이 만든 모임

• AI 정보는 많지만 실사용 경험은 부족하다는 문제의식

• 혼자 10개를 얕게 보기보다, 5명이 1개씩 깊게 파는 구조

• 매주 하나를 직접 써보고 30분 공유

• 검색 요약보다 직접 써본 흔적

• AI를 몰라도 괜찮지만, 아무것도 안 해도 되는 모임은 아님

설명회 피드백과 반영

첫 번째 설명회 이후 참여자들에게 개선점을 물었다.

감사하게도 두 가지 피드백이 나왔다.

첫째, AI를 가볍게 사용하는 사람은 스터디에서 어떤 내용을 준비해야 할지 모를 수 있다는 점.

둘째, AI 도구의 무료/유료 사용 기준이 명확했으면 좋겠다는 점.

나에게는 “AI 관련 주제를 하나 정해 직접 써오세요”가 자연스럽게 느껴졌지만, 다른 사람에게는 너무 추상적일 수 있었다. 그래서 이후 설명회에서는 구체적인 공유 예시를 추가했다. design.md를 주제로 내가 직접 간단한 예시를 준비해 보여주기도 했다.

또 무료/유료 기준도 명확히 했다. 무료 도구만으로는 실험 범위가 제한될 수 있기 때문에, 정기적으로 참여하려면 ChatGPT, Claude, Gemini 같은 프론티어 모델 중 하나는 유료로 사용하는 것을 기준으로 안내했다.

설명회는 총 3회 진행되었고, 최종적으로 5명이 정기 멤버로 확정되었다.

6. 온보딩: 바로 발표하지 않고 서로를 먼저 파악하기

첫 모임은 2026년 5월 10일에 진행했다. 온보딩 세션에는 총 4명이 참석했다.

원래 이 모임은 매주 각자 AI 도구나 기법을 공유하는 구조였지만, 첫 모임부터 발표를 시키지는 않았다. 대신 서로를 이해하는 데 집중했다.

그 이유는 간단했다.

각자가 무엇을 하는 사람인지, AI를 어디에 쓰고 싶은지 모르면, 이후의 공유가 서로에게 도움이 되기 어렵다고 생각했다.

예를 들어 내가 창업과 개발 맥락에서 어떤 AI 도구를 소개하더라도, 금융 리서치나 대학원 연구를 하는 사람에게는 직접적인 도움이 덜 될 수 있다. 반대로 금융 리서치 자동화 사례가 나에게 흥미롭기는 해도 당장 내 프로젝트에 적용되지는 않을 수 있다.

그래서 첫 모임의 목표는 발표가 아니라 관심사 맵핑이었다.

온보딩에서는 다음 내용을 공유했다.

• 각자가 AI를 쓰기 시작한 계기

• 지금 주로 쓰는 AI 도구

• AI를 주로 활용하는 분야

• 앞으로 써보고 싶은 도구나 영역

• 이 모임에서 얻고 싶은 것

• 진로/연구/창업/프로젝트 얘기

온보딩 결과, 참여자들의 관심사는 예상보다 다양했다.

• 연구와 HCI

• 챗봇 실험

• 창업과 제품 제작

• 금융 리서치

• 재무 모델링

• 서비스 기획

• 디자인과 콘텐츠 제작

• 데이터 분석

• 교육과 헬스케어

• AI 코딩 도구

• 자동화

이 세션은 성공적이었다고 본다. 참여자들이 서로의 배경을 어느 정도 이해했고, 이후 어떤 주제를 공유하면 서로에게 도움이 될 수 있을지 감을 잡을 수 있었다.

온보딩을 통해 배운 점도 있었다.

팀이나 커뮤니티를 운영할 때 초반에 사람들의 관심사, 수준, 목적을 충분히 파악하는 과정은 매우 중요하다. 단순 자기소개가 아니라, “이 사람이 어떤 맥락에서 이 모임에 참여하는가”를 이해해야 이후 운영 방향을 잡을 수 있다.

7. 실제 운영: 3회의 모임과 공유 사례

전체 운영은 온보딩 포함 총 3회 진행되었다.

초기 목표였던 8주 운영, 30개 이상 도구/기법 소개와 비교하면 실제 운영은 미약하게 끝났다. 하지만 짧은 기간 안에서도 몇 가지 의미 있는 공유 사례가 있었다.

7-1. OpenAI Realtime 2

첫 번째 공유 세션에서는 OpenAI Realtime 2와 관련된 발표가 있었다.

핵심은 음성 에이전트 기술이었다. 단순히 음성을 텍스트로 바꾸는 것이 아니라, 실시간으로 듣고, 판단하고, 대화하고, 필요하면 작업을 수행하는 방향의 기술로 소개했다.

공유 내용에는 다음이 포함되었다.

• Realtime 2의 특징

• realtime-whisper, realtime-translate와의 차이

• 가격 구조

• 실제 live interpretation 사용 후기

• 어떤 경우에 유용하고, 어떤 경우에는 아직 애매한지

결론은 단순한 찬양이 아니었다.

Realtime 2 자체는 강력하지만, 가격이 높고 한국어 사용감에는 아직 아쉬움이 있었다. 반면 translate나 whisper 계열은 대체 가능한 도구가 이미 존재한다는 평가도 있었다.

이 공유는 모임의 방향과 잘 맞았다. 새로운 기술을 단순히 “좋다”라고 소개하는 것이 아니라, 직접 써보고 비용, 사용성, 대체재, 추천 대상을 함께 판단했기 때문이다.

7-2. Manus + design.md

또 다른 공유 주제는 Manus였다.

Manus는 자율형 AI 에이전트로 소개되었다. 개발 지식이 부족한 사람도 Vercel, Supabase, Hugging Face 같은 플랫폼을 연결해 웹사이트 제작, 데이터베이스 구성, 문서 작성, 리서치 등을 시도할 수 있다는 점이 공유되었다.

특히 실제 사용 사례로 다음이 소개되었다.

• design.md 생성 및 활용

• Google Stitch와의 연결 가능성

• Gemini Gems나 코딩 파트너에게 design.md를 넘겨 HTML 시안 제작

• Supabase 목업 데이터베이스 구축

처음 모임이 상상했던 “비개발자가 AI에 얹혀서 뭔가 만들어보기”에 가장 가까운 사례 중 하나였다.

동시에 한계도 명확했다.

Manus는 알아서 많은 것을 해주지만, 자율성이 높기 때문에 중간에 관리하지 않으면 결과가 어디로 갈지 알 수 없다. 특히 디자인 결과물은 레퍼런스, 색상, 스타일을 정확히 지정해야 그나마 품질이 나온다는 평가가 있었다.

즉, AI agent는 비개발자의 제작 가능성을 넓혀주지만, 아직까지 그 품질을 완벽하게 보장하지는 않는다.

7-3. Claude를 활용한 Excel 자동화

1차 공유 세션에서는 Claude를 활용해 Excel 기반 리서치와 데이터 정리를 자동화하는 방법도 공유되었다.

금융 리서치나 재무 모델링에서는 여러 가정, 매출 추정, 사업부별 분석, 데이터 정리가 반복된다. 이런 작업은 여전히 수작업과 Excel 기반으로 이루어지는 경우가 많고, 논리 구조만 잘 잡히면 AI가 검토하거나 보조할 여지가 있다.

이 주제는 AI 활용이 꼭 웹서비스 제작이나 콘텐츠 생성에만 머무르지 않는다는 점을 보여주었다.

AI는 다음과 같은 영역에도 연결될 수 있었다.

• Excel 기반 데이터 정리

• 재무 모델링 검토

• 리서치 자료 구조화

• 반복 분석 프로세스 자동화

다만 이 주제는 관심 있는 사람에게는 매우 유용하지만, 다른 관심사를 가진 참여자에게는 직접적인 효용이 낮을 수 있다는 점도 함께 드러났다.

7-4. HTML is the new Markdown

2차 공유 세션에서는 “HTML is the new Markdown”이라는 주제가 공유되었다.

핵심 문제는 AI의 긴 답변이 Markdown으로 출력될 때 가독성이 떨어진다는 점이었다. AI에게 기획서, 보고서, 분석 자료, 비교표 등을 요청하면 답변이 길어지고, Markdown만으로는 구조적으로 읽기 어려워지는 경우가 많다.

이때 HTML 문서 형태로 답변을 받으면, 카드, 표, 접이식 섹션, 버튼, 레이아웃 등을 활용해 훨씬 읽기 쉬운 결과물을 만들 수 있다.

공유된 내용은 다음과 같았다.

• AI 답변을 HTML preview artifact로 받는 방식

• 어떤 유형의 답변에 HTML이 적합한지

• 기획/PRD/실행 계획/비교 분석/학습 자료에 적용 가능성

• 장점: 높은 가독성, 구조화, 인터랙션

• 단점: 토큰 소모, 편집 불편, 출력 시간 증가

7-5. 아임웹

2차 공유 세션에서는 아임웹도 소개되었다.

이 주제는 AI 활용과 직접 연결된 것은 아니었다. ChatGPT 정도만 사용해본 참여자가 노코드 웹 제작 도구로서 아임웹을 소개하고, 랜딩페이지 제작 방식에 대해 공유했다.

이 사례는 두 가지 면에서 의미가 있었다.

첫째, 비개발자가 웹페이지를 만들 수 있는 도구에 대한 관심을 보여주었다.

둘째, 동시에 모임의 주제 범위가 흔들릴 수 있다는 점도 보여주었다.

이 모임은 AI 활용 커뮤니티였지만, 비개발자 제작이라는 넓은 문제의식 안에서는 노코드 웹 제작 도구도 자연스럽게 들어올 수 있었다. 다만 이렇게 범위가 넓어질수록, 각 공유가 모든 참여자에게 유용하기는 더 어려워졌다.

8. 운영 중 생긴 문제

처음에는 설명회와 온보딩을 충분히 거치면 모임이 어느 정도 자연스럽게 굴러갈 것이라고 생각했다.

그런데 실제 운영은 전혀 그렇게 단순하지 않았다.

8-1. 의지가 있으면 매주 모일 줄 알았다

가장 먼저 느낀 것은 커뮤니티의 우선순위 문제였다.

온보딩에서 정기 모임 시간을 고정했지만, 실제로는 다른 일정이 생기면 모임이 후순위로 밀리는 경우가 있었다. 결혼식, 논문, 시험 일정 등 각자의 개인 일정이 생기면 참석이 어려워졌다.

자연스러운 일이지만, 운영자 입장에서는 중요한 발견이었다.

처음에는 “필터링도 거쳤고, 의지가 있는 사람들만 남았으니 잘 굴러가겠지”라고 생각했다. 하지만 커뮤니티는 팀보다 훨씬 느슨하다. 같은 목표를 향해 함께 책임지는 팀이 아니라, 각자가 여유가 있을 때 참여하는 구조에 가깝다.

따라서 지속성을 만들려면 더 강한 공동 목표나 명확한 결과물이 필요했다.

8-2. AI라는 공통 관심사면 충분할 줄 알았다

초기에는 “AI”라는 큰 주제 아래에 모이면 충분하다고 생각했다.

하지만 실제로 만나보니 참여자들의 관심사는 매우 다양했다.

• 창업

• 연구

• HCI

• 금융

• 서비스 기획

• 디자인

• 데이터 분석

• 자동화

• 노코드 웹 제작

• AI 코딩

관심사가 다양하다는 것은 장점이기도 했다. 서로 다른 관점을 들을 수 있었기 때문이다.

하지만 동시에 문제이기도 했다. 한 사람이 가져온 공유가 다른 사람에게 항상 직접적인 효용을 주지는 않았다.

예를 들어 금융 리서치 자동화 사례는 관심 있는 사람에게는 유용하지만, 개발이나 디자인 도구에 관심 있는 사람에게는 흥미는 있어도 바로 적용하기 어려울 수 있다.

이때 깨달은 것은 다음과 같다.

문제의식이 같다고 해서, 필요한 해결책까지 같은 것은 아니다.

8-3. 라이트 유저와 헤비 유저가 자연스럽게 섞일 줄 알았다.

참여자 중에는 이미 여러 AI를 깊게 활용하는 사람도 있었고, 챗봇 정도만 사용해본 사람도 있었다.

처음에는 이 차이가 큰 문제가 되지 않을 것이라고 생각했다. 오히려 AI를 많이 써본 사람과 가볍게 써본 사람이 함께 있으면 서로 배울 수 있을 것이라고 생각했다.

하지만 실제 운영에서는 수준 차이가 부담으로 작용할 수 있었다.

가볍게 사용하던 참여자는 다른 사람들의 공유를 따라가기 어렵게 느낄 수 있었다. 실제로 그러하다고 느꼈던 한 분이 중간에 모임에서 빠지게 되었다.

이 경험을 통해, 초보자도 참여할 수 있게 만들려면 단순히 “괜찮다”고 말하는 것만으로는 부족하다는 점과, 타겟을 좀 더 구체적으로 정해야겠다는 것을 깨달았다.

필요한 것은 더 구체적인 온보딩, 더 낮은 진입장벽의 주제, 더 명확한 예시, 그리고 공유 수준을 맞추는 장치였다.

8-4. 템플릿을 만들어두면 발표/기록 품질이 맞춰질 줄 알았다

나는 발표 템플릿을 만들었고, 설명회에서도 공유 예시를 보여주었다.

그런데 실제 발표 세션에서는 준비 수준에 차이가 있었다. 어떤 발표는 꽤 깊게 준비되었고, 어떤 발표는 3~4분 정도의 짧은 공유에 가까웠다.

이건 참여자의 잘못이라기보다 운영 설계의 문제였다.

“이 정도면 됩니다”라는 기준이 충분히 명확하지 않았다.

발표의 최소 조건, 예시, 기대 시간, 반드시 포함해야 할 실제 사용 사례, 발표 후 기록 기준이 더 구체적이어야 했다.

8-5. 기록을 자율적으로 남길 줄 알았다

초기 설계에서 Notion 아카이빙은 매우 중요한 요소였다.

모임의 결과물이 휘발되지 않게 하고, 나중에 포트폴리오로 재사용하기 위한 장치였기 때문이다.

하지만 실제로는 모든 발표가 충분히 기록되지는 않았다. 작성 완료된 페이지는 일부에 그쳤고, 발표와 토론은 있었지만 기록으로 남지 않은 내용도 많았다.

이 경험을 통해 자율적인 아카이빙만으로는 기록이 안정적으로 쌓이기 어렵다는 것을 배웠다.

기록을 남기게 하려면 템플릿만 주는 것으로는 부족하다. 마감, 예시, 리마인드, 최소 작성 기준, 운영자의 확인이 필요하다.

8-6. 좋은 툴을 쓰면 운영도 좋아질 줄 알았다

처음에는 Discord를 운영 채널로 설계했다.

채널을 나누고, 공지, 주제 공유, 자료 공유, Notion 링크 등을 관리하려고 했다. 확장 가능성을 생각하면 Discord가 적합해 보였다.

하지만 실제 운영 규모는 5명 내외였다. 이 정도 규모에서는 카카오톡 단톡방이 더 자연스럽고 빠를 수 있었다.

결국 Discord는 기대만큼 활성화되지 않았고, 실제 소통은 카카오톡 쪽으로 옮겨갔다.

이것도 중요한 배움이었다.

도구는 확장 가능성만 보고 고르면 안 된다. 현재 규모와 사용자 습관에 맞아야 한다.

9. 운영 방향 수정: 기술 소개에서 프로젝트 적용형 공유로

5월 24일, 두 번째 공유 세션 이후 모임 운영 방향에 대해 직접 이야기를 꺼냈다.

당시 나는 이렇게 느끼고 있었다.

• 모임이 최초 설계만큼 모두에게 도움을 주고 있는가?

• 재미가 충분한가?

• 각자 가져오는 주제가 너무 흩어져 있지는 않은가?

• 단순 기술 소개만으로 계속 갈 수 있을까?

• 이 모임이 나에게도 충분히 소구되고 있는가?

그래서 참여자들에게 솔직하게 물었다.

지금 방식이 잘 작동하고 있는지, 어떻게 바꾸면 좋을지 이야기했다.

이미 비슷하게 느끼는 참여자들도 있었다.

논의 끝에 나온 방향은 다음과 같았다.

지금처럼 얕은 수준으로 AI 관련 도구를 가져와 소개하기보다, 각자의 프로젝트를 병행하면서 그 과정에서 얻은 인사이트나 병목을 공유하는 방식으로 바꾸자.

이 방향은 훨씬 타당해 보였다.

단순히 새로운 도구를 소개하는 방식은 흥미롭지만, 지속적으로 강한 효용을 만들기 어렵다. 반면 각자가 자기 프로젝트를 진행하면서 AI를 실제로 적용하면, 공유되는 내용도 더 구체적이고 실전적일 수 있다.

운영 방식도 격주로 바꾸는 방향이 논의되었다. 매주 새로운 도구를 가져오는 것보다, 더 깊게 써보고 가져오는 편이 낫다고 판단했다.

이 수정은 이 프로젝트에서 가장 중요한 변화였다.

초기 가설은 “각자 다른 AI 도구를 써보고 공유하자”였다.

운영 후반의 수정 방향은 “각자의 실제 프로젝트에 AI를 적용하고, 그 과정에서 나온 병목과 인사이트를 공유하자”에 가까웠다.

10. 가설 검증 결과

이 프로젝트의 결론을 한 문장으로 정리하면 다음과 같다.

가설 검증 결과, 커뮤니티 형태의 지속 가능성은 낮았다.

다만 “아무것도 얻지 못했다”는 뜻이 아니다. 오히려 어떤 부분은 검증되었고, 어떤 부분은 실패했는지가 분명해졌다.

초기 문제의식은 유효했다. 하지만 그 문제를 해결하는 방식으로 “느슨한 커뮤니티”가 최적이었는지는 별개의 문제였다.

모두가 “AI 도구를 따라가기 어렵다”는 문제에는 공감할 수 있다. 하지만 그것이 곧바로 “정기 커뮤니티에 꾸준히 참여해야 한다”는 강한 동기로 이어지지는 않았다.

비유하자면, 모두가 휴지가 떨어질 때마다 사러 가는 것을 귀찮아할 수 있다. 하지만 그것이 곧바로 휴지 정기구독 서비스를 반드시 써야 한다는 결론으로 이어지지는 않는다.

이번 프로젝트도 비슷했다.

문제에는 공감이 있었다. 하지만 커뮤니티라는 해결 방식이 지속될 만큼 충분한 명분과 효용을 만들지는 못했다.

11. 배운 점

11-1. 커뮤니티는 문제의식만으로 지속되지 않는다

가장 크게 배운 점은 이것이다.

문제의식이 있다고 해서 커뮤니티가 지속되는 것은 아니다.

사람들이 어떤 문제에 공감하는 것과, 그 문제를 해결하기 위해 정기적으로 시간을 내고 준비하고 참여하는 것은 완전히 다른 일이다.

이 프로젝트에서 사람들은 AI 도구를 따라가기 어렵다는 문제에 공감했다. 하지만 그 문제를 해결하기 위해 매주 시간을 내고, 주제를 준비하고, 발표하고, 기록하는 구조는 생각보다 부담이 컸다.

다음에 커뮤니티나 팀을 만들 때는 먼저 물어야 한다.

이 문제는 정말 팀이나 커뮤니티 형태로 해결해야 하는 문제인가?

만약 그렇다면, 그 이유는 무엇인가?

팀으로 했을 때만 얻을 수 있는 결과물은 무엇인가?

개인이 혼자 했을 때보다 확실히 나은 점은 무엇인가?

이 질문에 답하지 못하면 커뮤니티는 쉽게 느슨해진다.

11-2. 온보딩은 중요하다

이번 프로젝트에서 가장 성공적이었다고 느낀 부분은 온보딩이었다.

첫 모임에서 바로 발표를 시키지 않고, 서로의 AI 사용 경험과 관심사를 공유한 것은 좋은 선택이었다.

그 시간을 통해 다음을 알 수 있었다.

• 누가 어떤 AI 도구를 쓰고 있는지

• 어떤 분야에 관심이 있는지

• 각자가 AI를 어디에 적용하고 싶은지

• 어떤 주제를 공유하면 도움이 될지

• 수준 차이가 어느 정도 있는지

팀이나 커뮤니티를 운영할 때, 초반에 사람을 이해하는 과정은 단순 친목이 아니다.

이후 운영의 품질을 결정하는 데이터 수집 과정이다.

앞으로 팀이나 커뮤니티를 만든다면, 초기 온보딩은 반드시 넣을 것이다.

11-3. 자율성만으로는 운영이 굴러가지 않는다

처음 설계에서는 각자가 리더십을 가지고 주제를 준비하고 공유하기를 기대했다.

모두가 리더이자 팔로워가 되는 구조를 만들고 싶었다.

운영자 한 명이 모든 것을 끌고 가는 모임이 아니라, 각자가 자기 주제의 리더가 되는 구조를 상상했다.

하지만 실제 운영에서는 자율성만으로 충분하지 않았다.

자율성이 많으면 자유로운 것이 아니라, 오히려 무엇을 해야 할지 애매해질 수 있다. 특히 커뮤니티 초반에는 더 그렇다.

필요했던 것은 다음과 같았다.

• 더 구체적인 발표 예시

• 최소 발표 기준

• 주제 선정 가이드

• Notion 작성 마감

• 리마인드

• 발표 후 정리 확인

• 참여자별 역할 분담

자율성은 구조 위에서 작동해야 한다.

구조가 없으면 자율성은 방치가 된다.

11-4. 도구 선택은 규모와 습관에 맞아야 한다

Discord는 구조적으로 좋아 보였다.

채널을 나눌 수 있고, 자료 공유가 쉽고, 나중에 자동화도 붙일 수 있다.

하지만 5명 규모의 소규모 모임에서는 오히려 부담이었다.

참여자들에게 익숙한 것은 카카오톡이었다. 빠른 확인과 짧은 소통에는 카카오톡이 더 적합했다.

이 경험을 통해 도구 선택의 기준도 바뀌었다.

도구는 미래 확장성보다 현재 사용성에 먼저 맞아야 한다.

초기 커뮤니티에서는 가장 좋은 도구보다, 가장 덜 귀찮은 도구가 더 나을 수 있다.

11-5. 아카이브는 의지가 아니라 시스템으로 남는다

Notion 아카이빙은 처음부터 중요한 산출물이었다.

모임에서 나온 공유를 기록으로 남기고, 나중에 포트폴리오로 재사용하고 싶었다.

하지만 실제로는 충분히 쌓이지 않았다.

이는 참여자들의 의지가 부족했다기보다, 시스템이 부실했기 때문이다.

아카이브가 남으려면 다음이 필요하지만 제대로 실행하지 못했다.

• 작성 기준

• 작성 마감

• 예시 페이지

• 운영자의 확인

• 발표 직후 정리 시간

• 미작성 시 리마인드

기록은 “남기면 좋겠다”가 아니라, 운영 루프 안에 포함되어야 한다.

12. 다음에는 이렇게

이 프로젝트는 지속 운영하지 않기로 했다.

하지만 다음에 비슷한 프로젝트를 한다면, 훨씬 다르게 설계할 것이다.

12-1. 주제를 더 좁힌다

“AI”라는 주제는 너무 넓었다.

다음에는 더 좁은 주제로 시작할 것이다.

예를 들면:

• 비개발자 AI 코딩 도구 실험

• 창업자를 위한 AI 활용 모임

• 논문/리서치 AI 활용 모임

• 금융 리서치 자동화 스터디

• 발표자료/디자인 AI 워크플로우 모임

범위가 좁아져야 공유 내용의 효용이 높아진다.

12-2. 커뮤니티보다 프로젝트형 팀으로 설계한다

느슨한 커뮤니티보다, 일정 기간 안에 하나의 결과물을 만드는 프로젝트형 팀이 더 적합할 수 있다.

예를 들어:

• 4주 안에 특정 주제에 도움이 되는 AI 기술 모음집 만들기

• 1개월 동안 각자 AI로 작은 제품 하나 만들기

이렇게 명확한 결과물이 있어야 참여 이유가 강해진다.

12-3. 참여자 수준을 더 명확히 맞춘다

초보자도 받을 수 있다. 하지만 그러려면 초보자용 구조가 따로 있어야 한다.

다음에는 모집 단계에서 다음을 더 명확히 할 것이다.

• 필요한 기본 역량

• 유료 AI 사용 여부

• 매주 필요한 준비 시간

• 발표 최소 기준

• 예시 주제

• 따라오기 어려울 수 있는 지점

이건 배제하려는 것이 아니라, 서로 맞는 상태에서 시작하기 위한 조건이다.

12-4. 아카이빙을 운영 루프에 포함한다

다음에는 발표 후 바로 10분 정도 정리 시간을 둘 것이다.

모임이 끝난 뒤 각자 알아서 정리하는 방식은 잘 작동하지 않았다.

따라서 모임 시간 안에 최소한의 기록을 남기고 끝내는 구조가 필요하다.

예를 들면:

발표 20분
Q&A 10분
정리 10분

이렇게 운영하면 기록이 훨씬 안정적으로 남을 수 있다.

12-5. 운영 자동화를 붙인다

반복 리마인드, 링크 요약, 발표 정리 초안 생성 같은 부분은 AI agent로 자동화할 수 있다.

처음부터 자동화를 붙이는 것은 과할 수 있지만, 운영 구조가 잡힌 뒤에는 다음을 자동화할 수 있다.

• 주제 선언 리마인드

• 발표 전 Notion 초안 리마인드

• 발표 후 정리 템플릿 생성

• 공유된 링크 요약

• 주간 요약 리포트

• 미작성 아카이브 리마인드

이번 프로젝트에서는 자동화까지 붙이지 못했지만, 다음에는 운영자의 부담을 줄이기 위해 반드시 고려할 것이다.

13. 마무리: 운영 실험이 남긴 것

이 모임은 내가 기대했던 방식으로 지속되지는 못했다.

처음에는 설명회와 온보딩을 거치고, 의지가 있는 사람들을 모으면 어느 정도 자연스럽게 굴러갈 것이라고 생각했다.

하지만 실제로는 그렇지 않았다.

커뮤니티 운영은 훨씬 정밀한 설계가 필요했다.

• 왜 함께 해야 하는가

• 무엇이 남는가

• 어떤 수준의 준비가 필요한가

• 누가 어떤 책임을 지는가

• 기록은 어떻게 남는가

• 참여하지 못했을 때 어떻게 이어지는가

• 주제가 너무 넓지는 않은가

• 각자에게 실제 효용이 있는가

이 질문들에 대한 답이 충분하지 않으면 커뮤니티는 쉽게 느슨해진다.

그럼에도 배운 건 많았다.

문제의식은 유효했다. AI 도구를 따라가기 어렵고, 직접 써본 경험이 중요하다는 점은 여전히 맞다. 비개발자 대학생 중에도 AI를 자기 작업과 프로젝트에 적용하고 싶은 수요가 있다는 것도 확인했다.

다만 이번 운영을 통해 확인한 것은, 그 문제를 해결하는 방식이 꼭 느슨한 커뮤니티일 필요는 없다는 점이었다.

다음에는 더 좁은 주제, 더 명확한 결과물, 더 정밀한 운영 구조를 가진 프로젝트형 팀으로 실험해볼 것이다.