Telegram 창업자 커뮤니티가 2,000명을 넘어설 때 무너지는 것들

2년 전 저는 Startup4Nation을 공동 창업했습니다. 이곳은 인도의 초기 단계 창업자들과 학생들로 구성된 2,000명 규모의 커뮤니티입니다. 대부분의 대화는 Telegram에서 이루어지며, 일부는 Luma에서 진행됩니다. 저희는 창업자 믹서(founder mixers), 데모 나이트(demo nights), 그리고 연례 피치 이벤트(pitch event)를 운영합니다.

이 포스트는 멤버 수가 1,000명에서 2,000명 사이일 때 제가 겪었던 실패 사례들에 관한 것입니다. 성공 사례가 아니라, 무너지는 지점들에 대한 이야기입니다. 만약 여러분이 특히 Telegram에서 커뮤니티를 1,000명 이상으로 확장(scaling)하고 있다면, 이것들은 아무도 저에게 경고해주지 않았던 것들입니다.

토픽(Topics)은 더 이상 라우팅 메커니즘(routing mechanism) 역할을 하지 못합니다. 그것들은 공동묘지가 됩니다.
멤버가 500명 미만일 때는 잘 이름 붙여진 몇 개의 토픽이 대화를 이끌어갑니다. 사람들은 훑어보고, 자신의 영역을 찾아 게시물을 올립니다. 1,000명이 넘어가면 이 구조가 붕괴됩니다. 신규 멤버들은 토픽 목록을 읽지 않습니다. 그들은 눈에 보이는 첫 번째 채팅방에 글을 올립니다. 하루를 시작할 때 무작위 토픽에 흩어진 6개의 "자기소개", #general 채널에 올라온 2개의 피치 덱(pitch decks), 그리고 Bangalore에 있으면서 #mumbai 채널에서 공동 창업자를 찾는 창업자 한 명을 마주하게 됩니다.

제가 시도했던 것들:

• 모든 토픽에 "X는 Y 토픽에 게시하세요"라는 한 줄 규칙이 담긴 환영 메시지를 고정(Pinned)했습니다.
• 모더레이터(mods)에게 게시물을 재지정하도록 요청했습니다. 그들은 2주 만에 지쳤습니다.
• #general 채널의 slow_mode를 60으로 설정했습니다. 사람들은 그냥 다른 토픽으로 이동했습니다.

효과가 있었던 것:
매달 제 자리를 증명하지 못하는 토픽들을 없앴습니다. 저는 30일 단위의 감사(audit)를 실시합니다. 만약 특정 토픽의 하루 평균 게시물이 3개 미만이라면, 병합하거나 삭제했습니다. 토픽을 14개에서 6개로 줄였습니다. 토픽당 활동량이 늘어났습니다. 신규 멤버들이 실제로 대화 내용을 파악할 수 있게 되었습니다.

단 하나뿐인 "아무거나 던지는" 토픽을 만들었습니다. 이를 #lounge라고 불렀습니다. 이는 카테고리를 요구하지 않는 유일한 토픽입니다. #funding, #hiring, #events, #build-in-public, #mumbai, #delhi, #blr에 해당하지 않는 모든 것은 그곳으로 갑니다. 이것은 그룹 전체에서 가장 큰 완화 밸브(relief valve) 역할을 합니다.

이 포스트에서 한 가지만 얻어 가신다면, 바로 이것입니다: 토픽을 하나 정해서 '잡동사니 서랍'으로 만드세요. 이름을 #lounge라고 해도 좋고, #random이라고 해도 좋습니다. 딱 하나만 만드세요.

1. Telegram은 세밀한 중재 기능(moderation granularity)을 제공하지 않습니다. 직접 만들어내야 합니다. Telegram에는 관리자(admins)가 있고, 채팅별 권한(per-chat permissions)이 있습니다. 그게 전부입니다. "3회 경고 시 삭제"나 "사용자별 슬로우 모드(slow mode)", "가입 날짜 기준 차단(ban by join date)" 같은 기능은 없습니다. 자원봉사 모더레이터(mods) 3명이 있는 상태에서 멤버가 2,000명에 도달하면, 3주 안에 모더레이터들은 번아웃(burn out)될 것입니다. 제가 시도했던 것: python-telegram-bot을 사용하여 Python 봇을 구축했습니다. 템플릿과 일치하지 않는 자기소개 게시물을 자동으로 삭제하도록 했습니다. 오탐(false positives) 비율이 높아 모더레이터들이 싫어했습니다. 신규 가입자를 메인 그룹에 입장시키기 전 48시간 동안 "수습(trial)" 그룹에 배치했습니다. 사람들은 이를 싫어했습니다. 이탈률(Drop-off)이 40%에 달했습니다. 효과가 있었던 것: 한 줄의 응답이 포함된 간단한 /rules 명령어입니다. 신규 가입자는 규칙이 평문(plain text)으로 적힌 자동 DM을 받습니다. 그들 중 대부분은 이를 읽습니다. 나머지 대부분은 모더레이터로부터 정중한 알림을 한 번 받고 스스로 행동을 수정합니다. 일요일 오후 9시에 진행하는 주간 모더레이터 싱크(mod sync) 미팅입니다. 20분 동안 진행합니다. 모더레이터 3명과 저, 의제(agenda)는 고정 메시지에 작성합니다. 우리는 (a) 누가 규칙을 어기고 있는지, (b) 누가 잘하고 있어서 예비 모더레이터(mod-in-training)로 승격시켜야 하는지, (c) 우리가 놓치고 있는 콘텐츠가 무엇인지 검토합니다. 이 싱크 미팅이 없으면 모더레이터들은 방향을 잃습니다. 미팅이 있으면 그들은 자리를 지킵니다. 모더레이터만 볼 수 있는 모더레이터 큐(mod queue) 채널입니다. 신고된 모든 메시지는 그곳으로 전송됩니다. 모더레이터들은 일주일 동안 비동기(async) 방식으로 이를 처리합니다. 결정적으로, 우리는 24시간 SLA(Service Level Agreement)에 합의했습니다. 만약 모더레이터가 24시간 이내에 신고를 처리할 수 없다면, 다음 모더레이터에게 넘어갑니다. 교훈: 이 정도 규모에서는 당신의 도구(tooling)가 봇이 아닙니다. 당신의 도구는 바로 미팅입니다.

2. Luma는 이벤트에는 도움이 되지만, 대화에는 도움이 되지 않습니다. 멤버가 1,200명 정도 되었을 때 모든 이벤트 RSVP(참석 회신)를 Luma로 옮겼습니다. 이는 명백한 승리였습니다. 이벤트 페이지, 티켓 유형, 대기 명단(waitlists), 이벤트 후 이메일 등 모든 문제가 해결되었습니다. 하지만 Luma는 커뮤니티 플랫폼이 아닙니다. Telegram을 대체할 수 없습니다. Luma에서 RSVP를 하고 이벤트에 나타나지 않은 5%의 사람들은 어차피 잠수(ghosted)를 탔을 똑같은 5%였습니다. 그리고 Luma에서 RSVP를 하지 않고도 모든 이벤트에 참석한 20%는 이미 Telegram에서 가장 활발하게 활동하던 똑같은 20%였습니다. 효과가 있었던 것: Luma를 커뮤니티가 아닌 캘린더(calendar)로 취급하는 것입니다.

Telegram 그룹이 커뮤니티입니다. Luma는 일정(schedule)입니다. 모든 이벤트에서 이 둘을 상호 연결(cross-link)하세요. Luma 페이지 설명란에 Telegram 링크를 넣고, Telegram 이벤트 공지에는 Luma 링크를 고정(pinned)해 두는 식입니다. 결코 어느 하나가 다른 하나를 대체할 수 있는 것처럼 행동하지 마세요.

3. 가장 어려운 문제는 성장이 아닙니다. 바로 졸업(graduating)입니다. 우리 그룹에는 프리시드(pre-seed) 투자를 받았거나 매출이 발생하고 있는 창업자가 약 30명 정도 있습니다. 이들에게는 2,000명 규모의 Telegram이 필요하지 않습니다. 그들에게 필요한 것은 자신과 비슷한 단계에 있는 다른 8명의 창업자가 있는 프라이빗한 WhatsApp입니다. 또한 그들은 공개적으로 커뮤니티를 떠나고 싶어 하지도 않습니다. 저에게 효과가 있었던 방법은 이들에게 떠나라고 요청하지 않는 것이었습니다. 저는 투자를 받았거나 월 반복 매출(MRR) 10L 루피를 달성한 사람을 자동으로 추가하는 병렬적인 #founders-only 토픽을 시작했습니다. 이는 선택 사항(opt-in)이며, 그들만의 리듬을 가집니다. 메인 그룹은 개방적이고 환영하는 분위기를 유지하고, 창업자 토픽은 긴밀하고 유용하게 유지됩니다. 제가 저지를 뻔했던 실수는 #founders-only를 유료 등급(paid tier)으로 전환하는 것이었습니다. 그랬다면 모든 것이 망가졌을 것입니다. 30명의 창업자는 떠났을 것이고, 나머지 1,970명은 커뮤니티가 자신들을 뒤처지게 만든다고 느꼈을 것입니다. 커뮤니티는 퍼널(funnel)이 아닙니다. 하나의 장소(place)입니다.

4. 처음부터 다시 시작한다면 다르게 할 일들
   첫날부터 눈팅족(lurker)을 위한 토픽을 추가하겠습니다. 대규모 Telegram 그룹의 절반은 게시물을 올리는 것이 아니라 읽는 사람들입니다. 메시지를 작성하지 않고도 반응할 수 있는 토픽을 그들에게 제공하세요. 이모지만 사용하는 응답도 허용하십시오. 멤버가 500명이 되기 전에 한 페이지 분량의 커뮤니티 핸드북(community handbook)을 작성하세요. 긴 문서가 아니라 딱 한 페이지면 됩니다. 규칙, 토픽, 모더레이터(mod) 연락처, 신고 방법 등을 담으세요. 이를 분기별로 업데이트하십시오. 멤버가 500명 늘어날 때마다 두 명의 멤버를 수습 모더레이터(mod-in-training)로 승격시키세요. 활동량(activity)을 기준으로 승격시키지 마세요. 그들이 DM(Direct Message)에서 얼마나 많은 사람을 돕는지에 기반하여 승격시키세요. 그것이 실제 신호(signal)입니다. "참여 지표(engagement metrics)"를 쫓는 것을 멈추세요. 2,000명 규모의 그룹에서 일일 활성 사용자(DAU)는 어느 날이든 8~12% 수준에 머물 것입니다. 그것으로 충분합니다. 커뮤니티는 퍼널이 아닙니다. 과도하게 최적화하여 망가뜨리지 마세요.

이것이 DevRel(Developer Relations)과 무슨 상관인가요?
저는 Failproof의 창업 멤버 DevRel(Founding DevRel) 직무에 지원하고 있습니다. 이 역할은 AI 에이전트 기업을 위해 개발자 커뮤니티를 엔드 투 엔드(end-to-end)로 책임지는 것입니다.

Slack, GitHub, Luma, 이벤트(events), 그 모든 것들까지 말이죠. 만약 여러분이 이런 종류의 역할을 위해 채용을 진행 중이며 이 글을 읽고 있다면: 이것이 바로 제가 운영해 온 커뮤니티의 모습입니다. 단 세 명의 정기 이용자만 있는 Discord가 아닙니다. 모더레이터(mods), 주제(topics), 이벤트(events), 고관여 멤버들을 위한 별도의 경로(off-ramp), 그리고 나머지 모든 사람들을 위한 잡동사니 서랍(junk drawer)까지 갖춘 2,000명 규모의 커뮤니티입니다. 저는 고작 밋업(meetup) 한 번을 운영해 본 커뮤니티 매니저(community manager)가 아닙니다. 저는 위에서 언급한 실패 모드(failure modes)들을 직접 겪어보고 그에 대한 해결책을 출시(shipped)해 온 커뮤니티 빌더(community builder)입니다. 대화를 나누고 싶다면 제 프로필에 있는 Telegram으로 연락해 주세요. 아니면 제가 이번 주에 출시한 github-triage-agent 리포지토리(repo)에 이슈(issue)를 생성해 주셔도 좋습니다. 저도 제 DM(Direct Message)을 직접 트리아지(triaging)하고 있으니까요. ***이번 주에 github-triage-agent를 구축하고 출시했습니다 — github.com/shekhar854/github-triage-agent. GitHub 이슈를 트리아지(triages)하는 작은 LangGraph + Claude 에이전트입니다. README에는 Claude Code가 프로덕션(production) 환경에서 깨지는 지점을 문서화해 두었습니다. Shekhar Thathera — Startup4Nation 공동 창업자. Aayo App 커뮤니티 매니저. B.Tech CSE (AI/Data Science), IIMT College of Engineering, Greater Noida. Founding DevRel 직무 지원 중.