커뮤니티를 키울 때 /community-builder가 참여 프로그램과 앰배서더 티어를 설계해 멤버를 지지자로 바꿉니다. — Claude Skill

---

title: 섹션 구성

1. 커뮤니티 전략 (strategy)

영향도: 중요 설명: 커뮤니티 주도 성장 전략, 커뮤니티 포지셔닝, 전략 계획, 성장 모델.

2. 플랫폼 선택 (platform)

영향도: 중요 설명: Discord, Slack, Circle, Discourse 및 기타 플랫폼 비교, 선택 기준, 설정.

3. 멤버 온보딩 (onboarding)

영향도: 중요 설명: 환영 흐름, 첫 가치 순간, 활성화 시퀀스, 신규 멤버 경험.

4. 참여 프로그램 (engagement)

영향도: 높음 설명: 커뮤니티 의례, 반복 이벤트, 참여 프로그램, 참여 유도 요인.

5. 콘텐츠 및 UGC (콘텐츠)

영향도: 높음 설명: 사용자 생성 콘텐츠 프로그램, 콘텐츠 기여 시스템, 멤버 제작 콘텐츠 전략.

6. 앰배서더 프로그램 (programs)

영향도: 높음 설명: 앰배서더 프로그램, 챔피언 프로그램, 슈퍼유저 프로그램, 등급 구조, 보상.

7. 커뮤니티 지표 (metrics)

영향도: 높음 설명: 커뮤니티 건전성 지표, 참여 추적, 분석 프레임워크, ROI 측정.

8. 조정 및 거버넌스 (조정)

영향도: 중간-높음 설명: 커뮤니티 가이드라인, 조정 관행, 거버넌스 구조, 갈등 해결.

9. 개발자 관계 (devrel)

영향도: 중간-높음 설명: DevRel 기본, 개발자 옹호, 기술 커뮤니티 구축, 개발자 경험.

---

title: 사용자 생성 콘텐츠 프로그램 impact: HIGH tags: ugc, content, user-generated, contributions, member-content

사용자 생성 콘텐츠 프로그램

영향도: 높음

사용자 생성 콘텐츠(UGC)는 커뮤니티 가치를 기하급수적으로 확장합니다. 멤버가 콘텐츠를 만들면 헌신이 깊어지고, 진정성 있는 목소리를 통해 신규 멤버를 끌어옵니다. 강한 UGC를 가진 커뮤니티는 organic 성장이 3-5배 더 큽니다.

UGC 가치 사슬

멤버가 콘텐츠를 생성
        ↓
커뮤니티가 확산
        ↓
콘텐츠가 신규 멤버를 유입
        ↓
신규 멤버가 가치를 확인
        ↓
신규 멤버가 콘텐츠를 생성
        ↓
[flywheel 가속]

UGC 콘텐츠 유형

UGC 프로그램 프레임워크

좋은 UGC 프로그램

커뮤니티 템플릿 프로그램:

"템플릿을 공유하세요"

멋진 [templates/workflows/configs]를 만들어 두셨다는 것을 알고 있습니다.
커뮤니티와 공유해 주세요!

진행 방식:
1. 템플릿 + 짧은 설명 제출
2. 커뮤니티 팀이 품질 검토
3. 승인된 템플릿을 library에 소개
4. 공로 표시 + contributor 배지 제공

장점:
✓ 다른 멤버의 성공 지원
✓ 자신의 평판 구축
✓ 접근법에 대한 피드백 받기
✓ 구독자 10k+ newsletter에 소개

[Submit Template] button

튜토리얼 기여 프로그램:

"[Community]에 글을 써 주세요"

[X,000]명 멤버가 있는 커뮤니티에 전문성을 공유해 주세요.

찾고 있는 내용:
- 방법 가이드(1,000-2,000단어)
- 실제 구현과 배운 점
- 문서화되지 않은 팁과 요령

제공되는 것:
- 편집자 지원과 피드백
- 커뮤니티 blog에 소개
- 우리 audience에게 홍보
- 게시된 글당 $100 사례비

과정:
1. 아이디어 제안(2-3문장)
2. 1주 안에 답변
3. 편집 지원을 받으며 작성
4. 함께 게시하고 홍보

[Submit Pitch] button

사례 연구 프로그램:

"당신의 이야기를 들려주세요"

[Product]를 실제 현장에서 어떻게 사용하는지 소개하고 싶습니다.

이야기 형식:
- 직면했던 과제
- 해결한 방법
- 결과와 배운 점
- 스크린샷/예시 환영

제공되는 것:
- 전문적인 작성본(작성은 우리가 담당)
- 웹사이트와 newsletter에 소개
- 당신의 사이트/프로필로 가는 backlink
- 커뮤니티 내 인정

필요 시간: 30분 인터뷰

[Schedule Interview] button

나쁜 UGC 프로그램

"콘텐츠를 공유하세요!"

✗ 구체적인 요청 없음
  → 멤버가 무엇을 공유해야 할지 모름

✗ 인센티브나 인정 없음
  → 굳이 해야 할 이유가 없음

✗ 배포 약속 없음
  → 콘텐츠가 묻혀 사라짐

✗ 복잡한 제출 과정
  → 마찰이 참여를 죽임

✗ 품질 기준 없음
  → 낮은 품질이 그대로 결과가 됨

✗ 템플릿이나 안내 없음
  → 결과 편차가 매우 큼

UGC 인센티브 모델

인정 단계

1단계: 반응(모두)
- staff가 모든 기여에 반응
- "공유해 주셔서 감사합니다!"

2단계: 하이라이트(좋은 기여)
- 커뮤니티에 소개
- "[member]님이 만든 것을 확인해 보세요"

3단계: 확산(뛰어난 기여)
- newsletter 소개
- social media 공유
- "우리 멤버 [name]님이 이 훌륭한 가이드를 작성했습니다"

4단계: 영구 인정(탁월한 기여)
- 명예의 전당
- contributor 페이지
- "커뮤니티 영웅"

UGC 품질 프레임워크

콘텐츠 기여 workflow

1. 콘텐츠 모집
   - 예시가 있는 명확한 brief
   - 제출 가이드라인
   - 마감일과 일정

2. 제출
   - 쉬운 제출 양식
   - 구조화된 템플릿
   - 자동 확인

3. 검토
   - 품질 확인
   - [X]일 안에 피드백
   - 수락/수정 요청/거절

4. 편집
   - 명확성을 위한 가벼운 편집
   - 형식 일관성
   - 작성자 승인

5. 게시
   - 저작자 표시와 함께 게시
   - 기여자에게 알림
   - 여러 채널에서 홍보

6. 축하
   - 공개 인정
   - 보상 전달
   - 감사 메시지

플랫폼별 UGC 채널

Discord:

• 프로젝트 공유용 #show-and-tell
• 링크와 템플릿용 #resources
• 멤버 튜토리얼용 #guides
• 최고의 콘텐츠는 고정 메시지

Slack:

• 성공 사례용 #wins
• 프로젝트용 #share-your-work
• 유용한 콘텐츠용 #resources
• 큐레이션된 모음용 Canvas

Forum/Circle:

• 전용 "Resources" 공간
• "Tutorials" category
• "Templates" library
• 고정된 베스트 모음

콘텐츠 큐레이션

UGC 지표

UGC 확장

법적 고려사항

안티패턴

• 주기만 하고 돌려주지 않음 — 인정 없이 멤버 콘텐츠를 사용합니다
• 과도한 편집 — 목소리를 너무 바꿔 더 이상 작성자의 것이 아니게 만듭니다
• 무급 노동처럼 보이는 framing — 전문가에게 "노출을 위해 기여하세요"라고 말합니다
• 피드백 루프 없음 — 제출한 뒤 아무 소식도 듣지 못합니다
• 낮은 품질의 홍수 — 모든 것을 받아들여 품질이 떨어집니다
• gatekeeping — 기준이 너무 높아 아무도 기여할 수 없습니다
• 일회성 요청 — 지속적인 프로그램이나 시스템이 없습니다
• 일관되지 않은 확산 — 일부 콘텐츠만 홍보되고 대부분은 무시됩니다
• 저작자 표시 없음 — 제작자 공로 표시 없이 UGC를 사용합니다
• 복잡한 과정 — 마찰이 기여 동기를 죽입니다

---

title: Developer Relations 기본 impact: MEDIUM-HIGH tags: devrel, developer-relations, developer-advocacy, technical-community

Developer Relations 기본

영향도: 중간-높음

Developer Relations(DevRel)는 제품과 개발자 커뮤니티 사이의 간극을 잇습니다. 훌륭한 DevRel은 도움으로 포장한 마케팅이 아니라, 진짜 가치를 통해 신뢰를 만듭니다. 개발자는 허세와 과장을 매우 잘 감지하므로, 진정성은 타협할 수 없습니다.

DevRel 기둥

┌─────────────────────────────────────────────────────────────┐
│                        DEVREL                               │
├─────────────────┬─────────────────┬─────────────────────────┤
│    옹호         │   커뮤니티      │      교육               │
│                 │                 │                         │
│ - 발표          │ - 포럼          │ - 문서                  │
│ - 글쓰기        │ - Discord/Slack │ - 튜토리얼              │
│ - 소셜 미디어   │ - 이벤트        │ - 샘플 코드             │
│ - 팟캐스트      │ - champion      │ - 워크숍                │
│ - 오픈소스      │ - 지원          │ - 과정                  │
└─────────────────┴─────────────────┴─────────────────────────┘

DevRel 기능

개발자 journey

인지
├── 콘텐츠, 입소문, 검색을 통해 발견
├── 브랜드와 커뮤니티의 첫인상
└── "이게 내 문제를 해결할 수 있겠다"

평가
├── 문서를 읽고 튜토리얼을 시도
├── 커뮤니티에서 질문
└── "내가 필요한 것을 실제로 만들 수 있을까?"

도입
├── 첫 성공적인 구현
├── 작업 흐름에 통합
└── "내 사용 사례에 맞게 작동한다"

유지
├── 지속 사용과 확장
├── 플랫폼에 대한 깊은 이해
└── "이제 내 기술 스택의 일부다"

옹호
├── 동료에게 추천
├── 콘텐츠 생성, 기여
└── "모두가 이걸 써야 한다"

개발자를 위한 콘텐츠

좋은 개발자 콘텐츠

Tutorial: "[Product]로 실시간 dashboard 만들기"

✓ 결과를 앞에서 명확히 제시
  "끝나면 실시간으로 업데이트되는 작동 dashboard가 생깁니다"

✓ 사전 조건을 나열
  "필요한 것: Node.js 18+, 기본 React 지식, 무료 [Product] 계정"

✓ 전체에 걸쳐 작동하는 코드
  [완전하고 실행 가능한 코드 스니펫]

✓ "왜"를 설명
  "여기서 WebSockets를 쓰는 이유는 polling이 latency를 만들기 때문입니다..."

✓ 복사해 붙여 넣을 수 있는 명령
  $ npm install @product/sdk

✓ 문제 해결 섹션
  "오류 X가 보이면 Y를 확인하세요..."

✓ 다음 단계
  "기본이 작동했으니 Z를 추가해 보세요..."

나쁜 개발자 콘텐츠

튜토리얼: "시작하기"

✗ 제목과 결과가 모호함
  "우리 제품 사용법을 배워 보세요"

✗ 사전 조건 누락
  필요한 지식을 명시하지 않고 가정함

✗ 불완전한 코드
  "여기에 설정을 추가하세요..."

✗ 설명 없음
  맥락 없이 코드만 있음

✗ 오래된 예시
  폐기된 메서드, 오래된 버전

✗ 오류 처리 없음
  정상 경로만 있고 조용히 실패함

✗ 막다른 끝
  "이제 탐색할 준비가 됐습니다!"

문서 원칙

DevRel 이벤트

컨퍼런스 발표

제출 전:
✓ 청중을 파악(초보자? 전문가? 혼합?)
✓ 시의적절하고 관련 있는 주제 선택
✓ 참석자가 가져갈 명확한 학습 포인트
✓ 독창적인 관점 또는 인사이트

좋은 발표 제안:
"WebSocket 연결을 사용자 100만 명까지 확장하며 배운 5가지"
- 명확한 주제와 범위
- 숫자가 실제 경험을 암시
- 실용적인 학습 포인트 약속
- 플랫폼 사용자와 관련 있음

나쁜 발표 제안:
"[Product] 소개"
- 가치가 아니라 제품 홍보
- 명확한 학습 없음
- 자기중심적

기술 콘텐츠 calendar

DevRel 지표

개발자 경험(DX)

DX 체크리스트:
□ 가입이 2분 미만
□ 첫 API 호출이 5분 미만
□ "Hello World" 튜토리얼이 작동
□ 오류 메시지가 도움이 됨
□ 문서가 검색 가능하고 완전함
□ 주요 언어용 SDK 제공
□ 커뮤니티 지원 사용 가능
□ 상태 페이지 존재
□ 변경 기록 유지
□ 마이그레이션 가이드 제공

DX를 망치는 요인:
✗ 복잡한 인증
✗ 오래된 문서
✗ 오류 설명 없음
✗ 느리거나 응답 없는 API
✗ 경고 없는 중단 변경
✗ 커뮤니티나 지원 없음

피드백 루프

개발자 피드백 출처:
- 커뮤니티 질문과 토론
- 지원 티켓
- GitHub 이슈
- 소셜 미디어 언급
- 직접 대화
- 설문과 NPS
- 사용 분석

제품으로 되돌리는 방식:
1. 피드백 수집과 분류
2. 패턴과 우선순위 식별
3. 증거가 있는 기능 요청 생성
4. 제품 토론에서 대변
5. 출시되면 개발자와 루프 닫기

오픈소스 전략

개발자와 신뢰 구축

신뢰를 만드는 것:
✓ 약속한 것을 출시
✓ 실수를 공개적으로 인정
✓ 약점까지 포함한 솔직한 비교 제공
✓ 투명한 가격
✓ 피드백에 빠르게 반응
✓ 커뮤니티에서 활발히 활동(공지뿐 아니라)
✓ 개발자를 이해하는 기술 인력 채용
✓ 가능한 것은 오픈소스로 공개

신뢰를 무너뜨리는 것:
✗ 기술 콘텐츠 안의 마케팅 말투
✗ 버그나 이슈 무시
✗ 가짜 리뷰나 추천사
✗ 숨겨진 가격 또는 함정
✗ 방치된 라이브러리나 문서
✗ 영업에만 쓰이는 커뮤니티
✗ 비기술 에반젤리스트가 아는 척함

DevRel 팀 구조

DevRel 확장

안티패턴

• DevRel로 위장한 마케팅 — 개발자는 즉시 알아차립니다
• 비기술 옹호 담당자 — 깊이 들어가지 못해 신뢰를 잃습니다
• 가치보다 지표 — 진짜 도움보다 가입 최적화에 집중합니다
• 피드백 무시 — 요청해 놓고 아무것도 하지 않을 때 최악입니다
• 문서 부채 — 오래된 문서는 없는 문서보다 나쁩니다
• 컨퍼런스 수집 — 전략 없이 여기저기서 발표합니다
• 커뮤니티 방치 — 출시한 뒤 사라집니다
• SDK 방치 — 유지되지 않는 라이브러리는 도움보다 해가 큽니다
• 과장 판매 — 제품이 제공할 수 없는 것을 약속합니다
• 내부 목소리 없음 — DevRel은 제품을 설명만 하는 것이 아니라 제품에 영향을 줘야 합니다

---

title: 참여 프로그램과 ritual impact: HIGH tags: engagement, rituals, events, programs, participation

참여 프로그램과 ritual

영향도: 높음

ritual은 리듬을 만듭니다. 정기적이고 예측 가능한 참여 기회는 가끔 방문하는 사람을 헌신적인 멤버로 바꿉니다. 일관된 ritual을 가진 커뮤니티는 유지율이 40-60% 더 높습니다.

참여 단계

헌신 수준(낮음 → 높음)
│
├── 소비          (읽기, 보기, 조용히 관찰)
├── 반응          (좋아요, 이모지, 추천)
├── 답글          (댓글, 답변)
├── 생성          (게시, 공유, 작성)
├── 운영          (호스트, 리드, moderation)
└── 전파          (추천, 대표, champion 역할)

ritual 설계 프레임워크

핵심 커뮤니티 ritual

주간 ritual

월요일 동기부여:

형식: 토론 thread
prompt: "이번 주 집중할 일은 무엇인가요?"
가치: 책임감, 목표 설정
참여: 목표를 댓글로 남기기

예시:
"월요일 집중: 이번 주에 작업할 한 가지를 공유해 주세요.
목표를 답글로 남기면 금요일에 다시 확인하겠습니다!"

수요일 성과 공유:

형식: 축하 thread
prompt: "이번 주 성과를 공유해 주세요"
가치: 긍정적 분위기, 사회적 증거
참여: 공유 + 다른 사람 축하

예시:
"성과 수요일: 크든 작든 잘된 일을 공유해 주세요!
서로의 진전을 함께 축하합시다."

금요일 피드백:

형식: showcase thread
prompt: "직접 만든 것을 공유해 주세요"
가치: 동료 피드백, 가시성
참여: 작업물 공유, 피드백 제공

예시:
"피드백 금요일: 프로젝트를 공유하고 건설적인 피드백을 받으세요.
규칙: 피드백을 받으려면 먼저 피드백을 주세요!"

오피스아워 형식

좋은 오피스아워:

구조:
- 30-60분, 일관된 시간
- 열린 Q&A 또는 주제별 topic
- 리더/전문가가 실시간 답변
- 질문은 사전에 제출 가능

흐름:
[0-5분]    환영, 진행 안내
[5-45분]   Q&A(사전 제출 + 실시간)
[45-55분]  열린 토론
[55-60분]  마무리, 다음 세션 안내

세션 후:
- 요약을 커뮤니티에 게시
- 답하지 못한 질문은 비동기로 처리
- 녹화 공유(해당되는 경우)

나쁜 오피스아워:

✗ 구조가 없어 어색한 침묵 발생
✗ 늘 같은 3명이 모든 질문을 함
✗ 사전 홍보 없음
✗ 시간이 일관되지 않음
✗ 후속 조치나 요약 없음

Show & Tell 프로그램

구조:

형식: 영상 통화 또는 비동기 thread
주기: 매주 또는 격주
시간: showcase당 5-10분

좋은 예시:
"커뮤니티 showcase
매주 목요일, 멤버 3명이 자신이 만들고 있는 것을 공유합니다.
- 5분 발표
- 5분 Q&A
- 신청: [link]

왜 참여하나요?
✓ 동료에게 피드백 받기
✓ 다른 사람이 무엇을 만드는지 발견하기
✓ 평판 쌓기"

선정 기준:
- 참여자 순환(같은 사람 반복 아님)
- 다양한 경험 수준 혼합
- 다양한 topic/프로젝트

챌린지 프로그램

월간 챌린지 프레임워크:

1주차: 발표 + 신청
- 명확한 theme과 규칙
- 정의된 성공 기준
- 등록 시작

2-3주차: 실행
- 진행 상황 확인
- 지원과 Q&A
- 중간 동기부여

4주차: showcase + 시상
- 제출 마감
- 커뮤니티 투표
- 수상자 발표
- 축하

좋은 챌린지 예시:
"30일 만들기 챌린지
[product/skill]을 사용해 무언가를 만들고 출시하세요.
- 매일 진행 상황 게시
- 동료 피드백 받기
- 상과 인정 받기

상:
- 1등: $500 + 주요 소개
- 2등: $250 + 굿즈
- 3등: $100 + 굿즈
- 모든 완주자: 배지 + 인정"

AMA(무엇이든 물어보세요) 세션

기획 체크리스트:

2주 전:
- [ ] 게스트와 topic 확정
- [ ] 사전 제출 질문 수집
- [ ] 여러 채널에서 홍보

1주 전:
- [ ] 게스트 준비 자료 발송
- [ ] 질문 queue 확정
- [ ] 기술 환경 테스트(영상인 경우)

당일:
- [ ] 마지막 홍보
- [ ] 실시간 질문 moderation
- [ ] 시간 관리, 흐름 관리

이후:
- [ ] 요약/녹취 공유
- [ ] 게스트에게 공개 감사
- [ ] 피드백 수집

좋은 AMA 예시:

[Expert Name]와 함께하는 AMA
[Role], [Company]

topic: [Specific focus area]
시간: [Date/Time] (timezone)
장소: #ama-channel

진행 방식:
1. 아래에 질문을 남깁니다(좋은 질문에 추천)
2. [Expert]가 인기 질문에 실시간 답변합니다
3. thread에서 후속 토론을 이어갑니다

[Expert] 소개:
[2-3 sentence bio]
[Why they're relevant to community]

커뮤니티 이벤트 캘린더

참여 프로그램 지표

좋은 참여 프로그램

프로그램: "주간 성과"
주기: 매주 금요일
형식: #wins 채널의 thread

구조:
- bot이 오전 9시에 prompt 게시
- 멤버가 하루 동안 성과 공유
- 팀이 모든 게시물에 반응
- 최고의 성과를 newsletter에 소개

효과적인 이유:
✓ 참여 노력이 낮음
✓ 긍정적 에너지
✓ 일관된 시점
✓ 인정이 구조 안에 포함됨
✓ 다른 채널에 쓸 콘텐츠 생성

나쁜 참여 프로그램

프로그램: "월간 메가 이벤트"
주기: 매월 첫째 월요일
형식: 2시간 영상 통화

문제:
✗ 너무 길어 중도 이탈
✗ 매번 같은 사람만 참여
✗ 비동기 옵션 없음
✗ 시간대에 불리함
✗ 후속 조치 없음
✗ 가치 제안이 불명확함

ritual 확장

ritual 출시 체크리스트

• 명확한 이름과 설명
• 일관된 주기 설정
• 가치 제안 정의
• 형식 문서화
• 담당자 배정
• 홍보 계획 준비
• 첫 4주 계획
• 성공 지표 정의
• 피드백 체계 마련
• 필요 시 반복 개선 계획

안티패턴

• 너무 많은 ritual — 멤버 피로가 생기고 아무것도 traction을 얻지 못합니다
• 불규칙한 시간 — "격주 화요일쯤"은 작동하지 않습니다
• 아무도 오지 않음 — 홍보 없이 출시하고 왜 비었는지 궁금해합니다
• 같은 참여자만 반복 — 파벌이 생기고 다른 사람은 배제됐다고 느낍니다
• founder 번아웃 — 모든 것을 혼자 운영하는 방식은 지속 가능하지 않습니다
• 복잡한 형식 — 특히 초반에는 단순하게 유지하세요
• 축하 없음 — 참여자를 인정할 기회를 놓칩니다
• 다른 커뮤니티 복붙 — 그들에게 맞는 것이 당신의 culture에 맞지 않을 수 있습니다
• 피드백 무시 — ritual이 개선되지 않고 참여가 죽습니다
• 전부 동기식 — 다른 시간대 멤버를 배제합니다

---

title: 커뮤니티 지표와 건전성 impact: HIGH tags: metrics, analytics, health, measurement, kpis

커뮤니티 지표와 건전성

영향도: 높음

측정되는 것은 관리됩니다. 하지만 잘못된 것을 측정하면 커뮤니티를 망칩니다. 허영 지표는 오해를 만들고, 건전성 지표는 방향을 제시합니다. 참여의 양보다 질에 집중하고, 커뮤니티 지표를 항상 비즈니스 영향과 연결하세요.

지표 프레임워크

┌─────────────────────────────────────────────────────────────┐
│                    비즈니스 영향                            │
│    매출 영향, 지원 회피, 유지                               │
├─────────────────────────────────────────────────────────────┤
│                    커뮤니티 건전성                          │
│    sentiment, 응답 품질, 멤버 만족도                        │
├─────────────────────────────────────────────────────────────┤
│                    참여 깊이                                │
│    활성률, 응답률, 기여 품질                                │
├─────────────────────────────────────────────────────────────┤
│                    참여 폭                                  │
│    DAU/MAU, 게시물, 반응, 체류 시간                         │
├─────────────────────────────────────────────────────────────┤
│                       성장                                  │
│    신규 멤버, 이탈률, 순 멤버 성장                          │
└─────────────────────────────────────────────────────────────┘

핵심 커뮤니티 지표

DAU/MAU 비율(stickiness)

DAU/MAU = 일간 활성 사용자 / 월간 활성 사용자

해석:
- 50%+ : 탁월함(일상 습관)
- 30-50%: 강함(정기 참여)
- 15-30%: 건전함(주간 참여)
- 10-15%: 보통(가벼운 참여)
- <10%  : 약함(가끔 방문)

맥락이 중요함:
- 개발자 커뮤니티: 20%+면 우수
- 고객 지원 커뮤니티: 10-15%가 일반적
- 학습 커뮤니티: 15-25%면 건전

참여 깊이 지표

1-9-90 측정

일반적인 커뮤니티 분포:
- 1% 제작자(원본 콘텐츠 게시)
- 9% 기여자(답글, 반응, 참여)
- 90% 관찰자(소비만 함)

건전한 목표:
- 제작자: 3-5%
- 기여자: 15-25%
- 관찰자: 70-80%

측정:
제작자 % = 게시물 3개 이상 멤버 / 전체 멤버
기여자 % = 상호작용이 있는 멤버 / 전체 멤버
관찰자 % = 상호작용이 없는 멤버 / 전체 멤버

건전성 지표

긍정적 건전성 신호:

✓ 질문이 빠르게 답변됨(< 24시간)
✓ 여러 멤버가 질문에 응답함
✓ 신규 멤버가 남아 있음(D7 유지율 > 25%)
✓ 기존 멤버가 계속 활성 상태(낮은 이탈)
✓ sentiment가 긍정적임(> 80%)
✓ 콘텐츠가 다양함(늘 같은 몇 명이 아님)
✓ 동료 간 상호작용 발생
✓ 멤버가 다른 사람을 추천

경고 신호:

✗ 질문이 답변되지 않음
✗ 같은 5명이 모든 것을 게시함
✗ 신규 멤버가 빠르게 사라짐
✗ 부정적 sentiment 증가
✗ 갈등이 커짐
✗ staff가 모든 답변을 담당
✗ spam 증가
✗ 멤버가 커뮤니티에 대해 불평

유지 cohort 분석

표 읽는 법:

• D1: 1일 안에 다시 참여한 멤버 비율
• D7: 7일 뒤에도 활성인 비율
• D30: 30일 뒤에도 활성인 비율
• 시간이 갈수록 개선됨 = 온보딩이 좋아짐

비즈니스 영향 지표

지원 회피 계산

방법 1: 규모 비교
- 커뮤니티 이전 지원 티켓: 월 1,000건
- 커뮤니티 이후 지원 티켓: 월 700건
- 커뮤니티가 답변한 질문: 월 400건
- 회피율: (1000-700)/1000 = 30%

방법 2: 비용 계산
- 커뮤니티가 답변한 질문: 월 400건
- 평균 지원 티켓 비용: $15
- 절감액: 400 × $15 = 월 $6,000

방법 3: 설문
- 커뮤니티 멤버에게 설문
- "이 답변 덕분에 지원팀에 문의하지 않아도 되었나요?"
- 회피 % 계산

커뮤니티 ROI 프레임워크

커뮤니티 투자:
- 팀 급여
- 플랫폼 비용
- 프로그램/이벤트
- 도구/소프트웨어
= 총 투자

커뮤니티 가치:
- 지원 회피 절감액
- 커뮤니티 영향 매출
- 이탈 감소(유지된 매출)
- 콘텐츠/UGC 가치
- 추천 가치
= 총 가치

ROI = (총 가치 - 총 투자) / 총 투자

커뮤니티 유형별 기준

좋은 지표 dashboard

┌──────────────────────────────────────────────────────────┐
│ 커뮤니티 건전성 DASHBOARD                     [Dec 2024] │
├──────────────────────────────────────────────────────────┤
│ 성장                                                     │
│ 전체 멤버:      12,450  (이번 달 +450)                  │
│ 신규 멤버:      520     (지난달 480 대비)                │
│ 이탈:           70      (지난달 85 대비)                 │
│ 순성장:         +450    (+3.6%)                         │
├──────────────────────────────────────────────────────────┤
│ 참여                                                     │
│ DAU:           1,870    (전체의 15%)                    │
│ WAU:           4,200    (전체의 34%)                    │
│ MAU:           7,450    (전체의 60%)                    │
│ DAU/MAU:       25%      (건전함)                        │
├──────────────────────────────────────────────────────────┤
│ 콘텐츠                                                   │
│ 게시물:         1,240    (지난달 1,100 대비)             │
│ 답글:           4,500    (게시물당 3.6)                 │
│ 기여자:         580      (멤버의 4.7%)                  │
├──────────────────────────────────────────────────────────┤
│ 건전성                                                   │
│ 응답률:              92%     (목표: >90%)               │
│ 평균 응답 시간:      3.2h    (목표: <24h)               │
│ sentiment:           87%     (목표: >80%)               │
│ D7 유지율:           32%     (지난달 28% 대비)           │
├──────────────────────────────────────────────────────────┤
│ 비즈니스 영향                                           │
│ 지원 회피:       $18,400 절감                           │
│ 커뮤니티 매출:   $245,000 영향                          │
│ 멤버 NPS:        +52     (비멤버 +38 대비)              │
└──────────────────────────────────────────────────────────┘

나쁜 지표 집중

피해야 할 허영 지표:
✗ 전체 멤버 수(참여 맥락 없음)
✗ impression 또는 조회수(action 없음)
✗ follower(참여하지 않는 경우)
✗ 활동 없는 "커뮤니티 규모"

오해를 만드는 이유:
- 100k 멤버, 활성 1% = 활성 1,000명
- 10k 멤버, 활성 25% = 활성 2,500명
- 더 작은 커뮤니티가 더 건전함

더 나은 대안:
✓ 활성 멤버(WAU, MAU)
✓ 참여율(DAU/MAU)
✓ 유지율(D7, D30)
✓ 비즈니스 영향(매출, 회피)

지표 검토 주기

측정 도구

안티패턴

• 성장만 측정 — 큰 커뮤니티도 죽은 커뮤니티일 수 있습니다
• 유지 무시 — 유지할 수 없는 멤버를 획득하는 것은 노력을 낭비합니다
• 가치보다 허영 — "멤버 100k!"는 비활성이면 아무 의미가 없습니다
• 비즈니스 연결 없음 — ROI 없이는 투자를 정당화할 수 없습니다
• 지표 조작 — 참여를 위한 참여
• 과도한 측정 — 데이터에 빠지고 action이 없습니다
• 측정 부족 — 보이지 않는 상태로 날아가며 개선할 수 없습니다
• 정성 신호 무시 — 숫자는 커뮤니티 느낌을 담지 못합니다
• 잘못된 기준과 비교 — 당신의 커뮤니티는 고유합니다
• 너무 잦은 측정 — 일간 변화는 신호가 아니라 noise입니다

---

title: moderation과 governance impact: MEDIUM-HIGH tags: moderation, governance, guidelines, code-of-conduct, conflict

moderation과 governance

영향도: 중간-높음

moderation은 잘되면 보이지 않고, 잘못되면 치명적입니다. 통제되지 않은 악성 행위자 한 명이 커뮤니티를 오염시킬 수 있고, 과도한 moderation 결정 하나가 대규모 이탈을 부를 수 있습니다. 명확한 governance 구조와 일관된 집행은 진정성 있는 커뮤니티가 번성할 수 있는 안전을 만듭니다.

governance 프레임워크

┌─────────────────────────────────────────────────────────────┐
│                      행동 강령                               │
│           커뮤니티 가치와 기대 행동                          │
├─────────────────────────────────────────────────────────────┤
│                      커뮤니티 가이드라인                     │
│           참여를 위한 구체적 규칙                            │
├─────────────────────────────────────────────────────────────┤
│                      집행 정책                               │
│           규칙을 어겼을 때 일어나는 일                       │
├─────────────────────────────────────────────────────────────┤
│                      moderation 팀                           │
│           누가 어떻게 집행하는가                             │
└─────────────────────────────────────────────────────────────┘

행동 강령 요소

좋은 행동 강령

[Community Name] 행동 강령

우리의 mission:
[Community]는 [identity]가 [value]할 수 있는 공간입니다. 우리는 모두에게
환영받고 포용적인 환경을 제공하기 위해 노력합니다.

기대 행동:
- 모든 상호작용에서 존중하고 건설적으로 대화하세요
- 선의를 가정하고, 반응하기 전에 이해하려고 하세요
- 다른 사람이 배우도록 도우세요. 우리 모두 한때는 초보자였습니다
- 공로를 인정하세요. 출처를 인용하고 다른 사람을 acknowledge하세요
- privacy를 존중하세요. 다른 사람의 정보를 공유하지 마세요

허용되지 않는 행동:
- 어떤 종류의 괴롭힘, 위협, 차별도 금지
- 개인 공격, 모욕, 선동적 언어
- spam, 가치 없는 자기 홍보, 광고
- 동의 없이 private 정보 공유
- 의도적으로 대화를 탈선시키거나 trolling
- 모든 불법 활동

집행:
1. 첫 위반: 비공개 경고
2. 두 번째 위반: 임시 timeout(7일)
3. 세 번째 위반: 영구 제거
심각한 위반은 즉시 제거될 수 있습니다.

신고:
- @Moderator 누구에게든 DM
- 이메일: [email protected]
- 신고는 confidential하게 처리됩니다

이 강령은 chat, forum, 이벤트, 공식 커뮤니티 모임을 포함한
모든 커뮤니티 공간에 적용됩니다.

나쁜 행동 강령

✗ 너무 길고 법률 문서 같음
  → 아무도 10쪽짜리 규칙을 읽지 않음

✗ 너무 모호함
  → "친절하세요"는 경계를 정의하지 못함

✗ 집행 기준이 불명확함
  → 사람들이 결과를 모름

✗ 신고 메커니즘 없음
  → 피해자가 도움을 요청할 곳이 없음

✗ 복사한 템플릿
  → 커뮤니티 가치를 반영하지 못함

커뮤니티 가이드라인 vs 행동 강령

채널/공간 규칙

#general
- 모든 커뮤니티 topic 환영
- 친절하고 건설적으로 유지
- 긴 토론에는 thread 사용

#help
- 구체적이고 검색 가능한 질문을 하세요
- 시도한 내용을 보여 주세요
- 해결된 질문은 resolved로 표시하세요
- "그냥 Google에서 찾아보세요" 답변 금지

#show-and-tell
- 작업 중인 것을 공유하세요
- 건설적인 피드백을 주세요
- 다른 사람의 작업을 축하하세요
- 여기서는 자기 홍보 허용

#jobs
- 채용 게시물만(토론 금지)
- 포함: 역할, 회사, 위치, 급여 범위
- recruiter spam 금지
- 공고당 게시물 하나

moderation 팀 구조

moderator 선정

이상적인 moderator 특성:
✓ 존중받는 커뮤니티 멤버
✓ 압박 속에서도 침착함
✓ 공정하고 일관됨
✓ 좋은 판단력
✓ 정기적으로 활동 가능
✓ 커뮤니티 가치와 정렬됨
✓ confidential 정보를 지킬 수 있음

위험 신호:
✗ 권력을 추구함
✗ 갈등 이력
✗ 특정 멤버에게 편향됨
✗ 활동이 불규칙함
✗ 커뮤니케이션이 부족함

moderation action

escalation ladder

1단계: 동료 피드백
- 커뮤니티 멤버가 서로 reminder
- "이 대화는 건설적으로 유지해요"

2단계: 부드러운 moderation
- moderator가 대화를 방향 전환
- 콘텐츠를 적절한 채널로 이동
- 공개적이지만 부드럽게 교정

3단계: 비공개 경고
- 멤버에게 DM
- 이슈 설명
- 기대사항 설정

4단계: 공개 경고
- 보이는 개입
- 위반 사항 명확히 설명
- action 전 마지막 기회

5단계: 임시 timeout
- mute 또는 정지(1-30일)
- 이유와 기간 설명
- 복귀 경로 제시

6단계: 영구 제거
- 커뮤니티에서 ban
- 이유 문서화
- 최종 결정

좋은 moderation 예시

상황: 멤버가 누군가의 질문에 공격적인 답글을 게시함

나쁜 응답:
"무례하게 굴지 마세요. 경고입니다."
→ 공개 망신, 방어적 반응

좋은 응답:
[Private DM]
"안녕하세요 [Name], [Member]님의 질문에 남긴 답글이 꽤 harsh하게
보일 수 있다는 것을 봤습니다. 지식이 많고 기본적인 질문에 답답함을
느끼셨을 수 있다는 점은 이해하지만, 이곳에서는 모두가 편하게 질문할 수
있기를 바랍니다.

질문을 비판하기보다 리소스를 안내하는 방식으로, 환영하는 분위기를
유지하는 데 도와주실 수 있을까요?

커뮤니티에 함께해 주셔서 감사합니다. 당신의 전문성을 소중히 생각합니다."

→ 비공개, 선의를 가정, 영향을 설명, 행동을 요청

갈등 해결

1단계: 식히기
- 공개 대화를 잠시 멈춤
- "이 thread는 잠시 쉬었다가 이어가겠습니다"

2단계: 이해하기
- 양쪽 당사자에게 각각 DM
- 각자의 관점 확보
- 실제 이슈 식별

3단계: 중재하기(적절한 경우)
- 직접 대화를 촉진
- 비난이 아니라 해결에 집중
- 공통점 찾기

4단계: 해결하기
- 앞으로의 경로에 합의
- 필요 시 문서화
- 해결됐는지 후속 확인

5단계: 배우기
- 다음번에 무엇이 이를 예방할 수 있을까?
- 가이드라인을 업데이트해야 하는가?
- 놓친 경고 신호가 있었는가?

어려운 상황 처리

moderation의 투명성

공개적으로 공유할 것:
✓ 커뮤니티 가이드라인과 CoC
✓ 일반적인 집행 철학
✓ 규칙 변경 사항(설명 포함)
✓ 집계된 moderation stats(선택)

비공개로 유지할 것:
✗ 구체적 위반 세부사항
✗ 개인별 경고 이력
✗ 내부 moderator 토론
✗ 신고자 identity

문서화

moderation log 항목:
- 날짜/시간
- 관련 멤버
- 위반 유형
- 증거(스크린샷, 링크)
- 취한 action
- 처리한 moderator
- 향후 참고 notes

문서화하는 이유:
✓ moderator 간 일관성
✓ 패턴 추적
✓ 결정에 이의가 제기될 때 방어
✓ 신규 moderator 교육

자동 moderation

moderation 번아웃 예방

moderator를 위해:
✓ 경계 설정(24/7 대기하지 않기)
✓ 부담 분산(rotation, coverage)
✓ 털어놓고 회고할 private mod channel
✓ 보이지 않는 일에 대한 인정
✓ 필요할 때 물러날 수 있는 허가

커뮤니티 manager를 위해:
✓ 한 명의 hero moderator에게 의존하지 않기
✓ 자원봉사 mod에게 보상(굿즈, 접근권, 인정)
✓ mod 팀과 정기 check-in
✓ 명확한 escalation path
✓ 가장 어려운 일은 직접 처리

안티패턴

• 규칙 없음 — 문제가 생기기 전까지는 "우리는 자유로운 분위기"라고 말합니다
• 규칙 과다 — 과도한 규제가 진정성 있는 대화를 죽입니다
• 일관되지 않은 집행 — 인기 멤버는 넘어가 주면 신뢰가 무너집니다
• 공개 망신 — 위반을 공개적으로 지적하면 방어적 반응이 생깁니다
• 느린 응답 — mod가 없으면 갈등이 곪습니다
• escalation path 없음 — mod가 불가능한 결정에 갇힙니다
• 권력에 취한 mod — ego trip에 빠진 moderator는 멤버를 떠나게 합니다
• 맥락 무시 — 판단 없는 규칙은 nuance를 놓칩니다
• appeal 없음 — mod 한 명의 나쁜 결정이 영구화됩니다
• 자원봉사 mod 착취 — 무기한 무료 노동을 기대합니다

---

title: 멤버 온보딩과 활성화 impact: CRITICAL tags: onboarding, activation, welcome, new-members, first-value

멤버 온보딩과 활성화

영향도: 매우 중요

처음 48시간 안에 참여하지 않은 신규 커뮤니티 멤버의 60-70%는 다시 돌아오지 않습니다. 온보딩은 그 사람이 활성 멤버가 될지, 유령 계정으로 남을지를 결정합니다.

첫 48시간

0시간:      가입 → 즉시 환영
0-1시간:    안내 → 공간 이해
1-24시간:   첫 상호작용 → 게시, 답글, 반응
24-48시간:  두 번째 방문 → 다시 돌아와 참여
7일차:      습관 형성 → 주간 활성
30일차:     유지 → 월간 활성

멤버 활성화 프레임워크

커뮤니티의 "아하 순간"

환영 흐름 설계

좋은 환영 흐름:

1단계: 즉시 환영
┌──────────────────────────────────────────────────────┐
│  [Community]에 오신 것을 환영합니다, [Name]!          │
│                                                      │
│  [value prop]을 실천하는 5,000+ [identity]와          │
│  함께하게 되었습니다.                                │
│                                                      │
│  이렇게 시작해 보세요:                               │
│  ✓ #introductions에서 자기소개하기                   │
│  ✓ 대표 리소스 확인하기                              │
│  ✓ 주간 오피스아워에 참여하기(목요일)                 │
│                                                      │
│  질문이 있나요? 여기 답글을 남기거나 @Team 멤버에게  │
│  DM을 보내세요.                                      │
└──────────────────────────────────────────────────────┘

2단계: 자기소개 prompt
"알려주세요: 무엇 때문에 오셨나요? 지금 무엇을 하고 있나요?"

3단계: 개인화된 후속 연락(24시간)
"안녕하세요 [Name], [topic]에 관심이 있으신 것을 봤습니다.
#channel-name과 이 리소스가 도움이 될 수 있어요: [link]"

4단계: 확인 연락(7일)
"첫 주는 어떠신가요? 저희가 도울 일이 있을까요?"

나쁜 환영 흐름:

✗ 일반적인 자동 메시지
  "커뮤니티에 오신 것을 환영합니다. 규칙을 읽어 주세요."
  → 차갑고 초대받은 느낌이 없으며 다음 행동이 없음

✗ 정보 과부하
  "채널 47개, 프로그램 12개, 규칙 8개가 있습니다..."
  → 부담스럽고 이탈을 유발함

✗ 사람의 손길 없음
  → 멤버가 인정받거나 소중하게 여겨진다고 느끼지 못함

✗ 명확한 첫 행동 없음
  → 멤버가 다음에 무엇을 해야 할지 모름

자기소개 게시물 템플릿

효과적인 prompt:

안녕하세요 [Name], 환영합니다!

당신에 대해 알고 싶습니다:
- 어떤 일을 하시나요?
- 무엇 때문에 [Community]에 오셨나요?
- 이곳에서 얻고 싶은 한 가지는 무엇인가요?

아래에 자기소개를 남겨 주시면, 맞는 사람들과 연결해 드릴게요!

피해야 할 것:

✗ "자기소개해 주세요"
  → 너무 모호해서 무시되기 쉬움

✗ 10개 질문 양식
  → 마찰이 너무 큼

✗ 자기소개에 반응 없음
  → 멤버가 보이지 않는 존재처럼 느낌

플랫폼별 온보딩

Discord 온보딩:

1. 서버 가입 → 역할 자동 할당
2. bot의 빠른 시작 안내가 담긴 환영 DM
3. 자기소개 게시 전까지 잠긴 채널(선택 사항)
4. 관심사별 반응 역할
5. 공개 채널에서 팀 멤버가 환영

Slack 온보딩:

1. 초대 수락 → Slackbot 환영
2. 고정 리소스가 있는 #welcome 채널
3. #introductions에 게시하도록 안내
4. 24시간 안에 팀 멤버가 DM
5. 관심사에 따라 관련 채널에 추가

Circle/포럼 온보딩:

1. 계정 생성 → 환영 이메일
2. 공간 안내 둘러보기
3. 프로필 생성 안내
4. 자기소개 첫 게시물
5. 비활성 상태이면 후속 이메일

활성화 trigger와 action

개인화 기회

온보딩 지표

가입 마찰 줄이기

활성화 체크리스트 템플릿

[Community]에 오신 것을 환영합니다! 최대한의 가치를 얻으려면 아래를 완료하세요:

□ 프로필 설정하기(사진 + 소개)
  "다른 사람이 당신과 연결하는 데 도움이 됩니다"

□ #introductions에서 자기소개하기
  "지금 무엇을 하고 있는지 알려 주세요"

□ 게시물 하나에 반응하거나 답글 달기
  "대화에 참여해 보세요"

□ 리소스 3개 북마크하기
  "나중에 쓸 유용한 것을 저장하세요"

□ 첫 이벤트 참여하기
  "커뮤니티를 실시간으로 만나세요"

진행률: 2/5 완료
[🎉 완료하면 Champion 배지를 잠금 해제합니다!]

cohort 기반 온보딩

큰 커뮤니티에서는 cohort 단위로 온보딩하세요:

장점:
✓ 첫날부터 동료 연결 형성
✓ 공유 경험이 유대감을 만듦
✓ 확장 가능한 사람 중심 접점
✓ 자연스러운 책임감 형성

구조:
1주차: 환영, 자기소개, 안내
2주차: 가치 심화, 첫 기여
3주차: 더 넓은 커뮤니티와 연결
4주차: 수료, 메인 커뮤니티에 통합

신규 멤버 segment

안티패턴

• 잠긴 첫 행동 — "접근하려면 먼저 자기소개를 올리세요"는 관찰자를 밀어냅니다
• bot만 있는 환영 — 첫 48시간에 사람의 손길이 없습니다
• 정보 덤프 — 환영 메시지에 링크 20개를 넣으면 부담스럽습니다
• 획일적 방식 — 서로 다른 멤버에게는 서로 다른 경로가 필요합니다
• 후속 연락 없음 — 환영한 뒤 방치합니다
• 자기소개 무시 — 멤버가 게시했지만 아무 반응도 받지 못합니다
• 참여 강요 — 참여를 의무화하면 반감이 생깁니다
• 느린 질문 응답 — 첫 질문이 답변되지 않으면 멤버를 잃습니다
• 복잡한 온보딩 — 모든 단계가 이탈 지점입니다
• 명확한 가치 없음 — "환영합니다"만 있고 "무엇을 얻는지"가 없습니다

---

title: Discord와 Slack 커뮤니티 설정 impact: CRITICAL tags: discord, slack, platform, setup, bots, channels

Discord와 Slack 커뮤니티 설정

영향도: 매우 중요

Discord와 Slack은 대표적인 실시간 커뮤니티 플랫폼입니다. 각각을 효과적으로 운영하려면 전용 설정, bot, 구성이 필요합니다. 잘 구성된 server는 명확성을 만들고, 잘못 구성된 server는 혼란을 만듭니다.

Discord server 설정

채널 구조

좋은 Discord 구조:

📋 환영
├── #rules (읽기 전용, 고정된 CoC)
├── #announcements (admin만 게시, 중요 업데이트)
├── #introductions (신규 멤버 게시)
└── #roles (관심사 self-assign)

💬 일반
├── #general (메인 대화)
├── #off-topic (업무 외 chat)
└── #random (meme, 재미)

❓ 지원
├── #help (질문과 답변)
├── #troubleshooting (기술 이슈)
└── #feedback (제품 피드백)

🔧 제품
├── #feature-requests
├── #bug-reports
└── #beta (invite-only)

📚 리소스
├── #tutorials (고정된 guide)
├── #showcase (멤버 project)
└── #jobs (career 기회)

🎉 커뮤니티
├── #wins (축하)
├── #events (예정 활동)
└── #content (멤버 blog, video)

🔒 비공개
├── #champions (invite-only)
├── #team (staff만)
└── #mods (moderator 토론)

나쁜 Discord 구조:

✗ 보이는 channel이 30개 이상
  → 부담스럽고 어디에 게시할지 아무도 모름

✗ 불명확한 channel name
  → #channel-1, #stuff, #misc

✗ 읽기 전용 channel 없음
  → 공지가 묻힘

✗ 모든 것이 모두에게 보임
  → 진행감이나 독점성이 없음

Discord 역할 설정

Discord bot 필수 요소

Discord 인증 흐름

신규 멤버 가입
       ↓
#rules에 도착(유일하게 보이는 channel)
       ↓
규칙을 읽고 ✅로 반응
       ↓
bot이 @Member 역할 할당
       ↓
전체 server 접근 잠금 해제
       ↓
환영 bot이 빠른 시작 DM 발송
       ↓
#introductions에 자기소개 게시

Discord 모범 사례

✓ 긴 대화에는 thread 사용
  → channel을 깔끔하게 유지하고 context 생성

✓ 트래픽이 높은 channel에는 slow mode 설정
  → #general: 5-10초가 spam을 방지

✓ Q&A channel에는 forum 사용
  → 검색 가능하고 구조화되며 해결 표시 가능

✓ 중요한 메시지는 고정(아껴서)
  → channel당 최대 3-5개 고정

✓ 관심사별 reaction role 생성
  → 멤버가 topic channel에 opt-in 가능

✓ server discovery 설정
  → 공개 community라면 organic growth 가능

✓ logging 구성
  → 안전을 위해 가입, 탈퇴, 삭제 추적

Slack workspace 설정

채널 구조

좋은 Slack 구조:

공개 channel
├── #announcements (admin만 게시)
├── #introductions (신규 멤버 게시)
├── #general (메인 대화)
├── #random (주제 외, social)
├── #help (질문과 지원)
├── #feedback (제품 피드백)
├── #jobs (career 게시)
├── #events (커뮤니티 이벤트)
├── #wins (축하)
└── #resources (링크, guide)

topic channel (필요 시)
├── #topic-frontend
├── #topic-backend
├── #topic-devops
└── #topic-design

private channel
├── #champions (invite-only)
├── #team (staff만)
└── #mods (moderator 토론)

나쁜 Slack 구조:

✗ default channel 없음
  → 가입한 사람이 아무것도 보지 못함

✗ 너무 이른 channel 과다
  → 빈 channel은 죽은 커뮤니티라는 신호

✗ topic 구성 없음
  → 모든 것이 #general에 몰려 혼란

✗ 일반 토론을 private channel에서 함
  → 커뮤니티가 조각남

Slack workspace 설정값

Slack app과 integration

Slack 예절 가이드라인

channel 가이드라인:

#general
- 모든 커뮤니티 topic 환영
- 긴 토론에는 thread 사용
- 건설적이고 도움 되는 분위기 유지

#help
- 질문 전 검색(Cmd+K)
- 구체적으로 작성: error message, code 포함
- code에는 code block 사용(```)
- 해결된 질문은 ✅로 표시

#announcements
- admin만 게시
- 중요한 업데이트와 news
- 확인했다면 👍로 반응

#random
- 주제 외, social, 재미
- meme 환영
- 존중 유지

Discord vs Slack: 언제 사용할까

bot 구성 모범 사례

환영 bot 설정

좋은 환영 메시지:

[Community]에 오신 것을 환영합니다, {username}!

[value prop]을 실천하는 [X,000]명의 [identity]와 함께하게 되었습니다.

빠른 시작:
1. #rules를 읽고 ✅로 반응해 전체 접근 권한 받기
2. #introductions에서 자기소개하기
3. #resources에서 guide 둘러보기
4. #help에서 질문하기

질문이 있나요? @Team 멤버에게 DM하거나 #help에 게시하세요.

곧 만나요!

나쁜 환영 메시지:

✗ 너무 김(10줄 이상)
✗ 명확한 다음 action 없음
✗ 일반적임("우리 server에 오신 것을 환영합니다")
✗ option이 너무 많아 부담스러움

자동 moderation 설정

channel naming convention

Slack prefix:

#team-*     → team channel
#proj-*     → project channel
#help-*     → support channel
#social-*   → social channel
#announce-* → announcement

알림 관리

Discord:

server 설정:
- 알림 설정: @mentions만
- 대부분 role에서 @everyone/@here 억제
- #announcements에서 @everyone은 아껴서 사용

멤버 안내:
"channel 우클릭 → Notification Settings
부담을 피하려면 대부분을 'Only @mentions'로 설정하세요"

Slack:

channel default:
- #announcements: 모든 메시지
- #general: mention만(초기 기간 이후)
- topic channel: mention만

멤버 안내:
"channel name 클릭 → Notifications → Customize
대부분 channel은 'Mentions only'가 가장 잘 작동합니다"

플랫폼 간 migration

안티패턴

Discord:

• channel 과다 — 10개로 시작하고 필요할 때 추가하세요
• 복잡한 role system — 단순한 hierarchy가 이깁니다
• 인증 없음 — bot과 spam이 server를 덮칩니다
• voice channel 과다 — 대부분 아무도 쓰지 않습니다
• thread culture 없음 — channel을 읽을 수 없게 됩니다

Slack:

• 영구 무료 tier — 90일 제한이 커뮤니티 기억을 해칩니다
• channel 폭증 — 확산 전에 policy를 만드세요
• default channel 없음 — 신규 멤버가 빈 workspace를 봅니다
• 이메일식 행동 — channel이 커뮤니티를 만들 수 있는데 DM을 보냅니다
• threading 없음 — 대화가 충돌합니다

Both:

• 온보딩 없음 — 가입 → 혼란 → 이탈
• moderation bot 없음 — 수동 moderation은 확장되지 않습니다
• 모든 곳이 admin-only posting — 대화를 죽입니다
• analytics 없음 — 참여를 보지 못한 채 운영합니다
• 복사한 설정 — 모든 커뮤니티에는 다른 needs가 있습니다

---

title: 커뮤니티 플랫폼 선택 impact: CRITICAL tags: platform, discord, slack, circle, discourse, selection

커뮤니티 플랫폼 선택

Impact: CRITICAL

플랫폼 선택은 커뮤니티 culture, 참여 패턴, 확장성을 형성합니다. 잘못된 플랫폼은 마찰을 만들고, 올바른 플랫폼은 눈에 띄지 않을 만큼 자연스러워집니다.

플랫폼 비교 매트릭스

플랫폼 선택 프레임워크

Discord 심층 분석

가장 적합한 경우: 개발자 커뮤니티, 게임, crypto, 실시간 협업

강점:

• 풍부한 기능 세트(음성, 영상, thread, role)
• 규모가 커도 무료
• bot ecosystem
• 기술 청중에게 익숙함
• 성장을 위한 server discovery

약점:

• 신규 사용자에게 부담스러운 UX
• SEO 없음(콘텐츠가 검색에 보이지 않음)
• 알림이 noisy할 수 있음
• 전문가 청중이 거부감을 가질 수 있음

좋은 Discord 설정:

server 구조:
├── 📋 START HERE
│   ├── #welcome (규칙, 소개)
│   ├── #introductions (신규 멤버 게시)
│   └── #announcements (읽기 전용)
├── 💬 COMMUNITY
│   ├── #general
│   ├── #help
│   └── #show-and-tell
├── 🔧 PRODUCT
│   ├── #feature-requests
│   ├── #bug-reports
│   └── #beta-testing
├── 🎯 TOPICS
│   ├── #topic-1
│   ├── #topic-2
│   └── #topic-3
└── 🎉 SOCIAL
    ├── #off-topic
    └── #wins-celebrations

role:
- @Team (staff, 다른 색상)
- @Champion (활성 기여자)
- @Beta Tester (조기 접근)
- @New Member (자동 할당)

나쁜 Discord 설정:

✗ 첫날부터 30개 이상의 channel 표시
  → 분석 마비, 멤버가 어디에 올릴지 모름

✗ welcome channel이나 규칙 없음
  → 혼란스럽고 spam에 취약

✗ role 기반 권한 없음
  → 모든 곳에 noise, 중요한 내용이 묻힘

✗ moderation bot 없음
  → spam이 빠르게 장악

Slack 심층 분석

가장 적합한 경우: 전문가 커뮤니티, B2B, 엔터프라이즈, workplace-adjacent

강점:

• 전문가에게 익숙함
• 뛰어난 검색
• thread 구성
• 엔터프라이즈급 보안
• 앱 통합

약점:

• 규모가 커지면 비쌈(Pro 기준 사용자당 월 $7.25)
• 무료 플랜 90일 메시지 제한
• 이메일 초대 필요
• "일이 더 늘어난" 느낌을 줄 수 있음

좋은 Slack 설정:

channel 구조:
├── #welcome (고정 자료, 규칙)
├── #introductions
├── #announcements (admin만 게시)
├── #general (주요 대화)
├── #help-and-support
├── #share-your-work
├── #jobs-and-opportunities
├── #random (off-topic)
└── 필요에 따른 topic channel

Slack Connect:
- 파트너 협업에 활성화
- power user와 shared channel 생성

비용 관리:

무료 tier가 작동하는 경우:
- 커뮤니티가 활성 멤버 500명 미만
- 90일 history가 허용됨
- 기본 통합으로 충분

유료를 고려할 경우:
- 전체 history 검색 필요
- 컴플라이언스 요구사항
- 고급 admin control

Circle 심층 분석

가장 적합한 경우: 강의 creator, 유료 커뮤니티, creator economy

강점:

• 아름답고 현대적인 UX
• space가 topic을 명확히 구성
• 이벤트와 강의 내장
• 좋은 모바일 경험
• SEO-friendly 옵션

약점:

• 실시간 느낌이 약함
• 작은 ecosystem
• 활동이 낮으면 비어 보일 수 있음
• 멤버 수에 따라 가격 증가

좋은 Circle 설정:

space 구조:
├── 여기서 시작
│   ├── 환영 (규칙, orientation)
│   └── 자기소개
├── 메인 커뮤니티
│   ├── 일반 토론
│   └── 커뮤니티에 질문
├── 학습
│   ├── 자료
│   └── 강의 콘텐츠
├── showcase
│   └── 멤버 성과
└── 이벤트
    └── 예정 세션

Discourse 심층 분석

가장 적합한 경우: 오픈소스, 기술 토론, 지식 베이스

강점:

• 뛰어난 SEO(콘텐츠가 rank)
• threaded discussion 확장 가능
• trust level 시스템 내장
• self-hosted 옵션
• 성숙하고 안정적인 플랫폼

약점:

• forum UX가 일부에게 낡아 보임
• 실시간성이 낮음
• self-hosted 설정이 더 가파름
• 모바일 경험은 무난한 정도

좋은 Discourse 설정:

category 구조:
├── 환영 (규칙, FAQ)
├── 일반 토론
├── 도움 및 지원
├── 기능 요청
├── Show & Tell
└── Meta (커뮤니티 피드백)

trust level:
- TL0: 신규 사용자(제한된 행동)
- TL1: Basic(읽기를 통해 획득)
- TL2: Member(활성 참여)
- TL3: Regular(높은 신뢰)
- TL4: Leader(moderator-lite)

플랫폼 의사결정 트리

여기서 시작
    │
    ├─▶ 실시간 채팅이 중요한가?
    │       │
    │       ├─▶ 예 ──▶ 청중이 기술/게임 중심인가?
    │       │              │
    │       │              ├─▶ 예 ──▶ Discord
    │       │              └─▶ 아니오 ──▶ Slack(예산 가능 시) 또는 Discord
    │       │
    │       └─▶ 아니오 ──▶ SEO/발견 가능성이 중요한가?
    │                      │
    │                      ├─▶ 예 ──▶ Discourse 또는 Circle
    │                      └─▶ 아니오 ──▶ Circle 또는 Mighty Networks
    │
    └─▶ 개발자/오픈소스용인가?
            │
            ├─▶ 예 ──▶ GitHub Discussions 또는 Discourse
            └─▶ 아니오 ──▶ 위로 계속

하이브리드 플랫폼 전략

마이그레이션 고려사항

플랫폼 평가 체크리스트

• 대상 청중은 이미 어디에서 활동하는가?
• 커뮤니케이션 스타일은 무엇인가(실시간 vs 비동기)?
• 3년 성장 전망은 무엇인가?
• 필요한 통합은 무엇인가?
• 지속 가능한 예산은 얼마인가?
• 누가 admin과 moderation을 담당할 것인가?
• 콘텐츠 전략은 무엇인가(SEO 필요)?
• 컴플라이언스/보안 요구사항은 무엇인가?
• white-label/custom branding이 필요한가?
• 필요할 경우 마이그레이션은 어떻게 처리할 것인가?

안티패턴

• 개인 취향 기반 선택 — 내가 좋아하는 것이 청중이 쓰는 것은 아님
• 엔터프라이즈 B2B에 Discord — 전문가가 "게임 앱"으로 볼 수 있음
• 10k+ 무료 커뮤니티에 Slack — 비용이 감당 불가가 됨
• 첫날부터 여러 플랫폼 — 커뮤니티를 분열시키고 팀을 지치게 함
• 모바일 경험 무시 — 50% 이상이 모바일로 접근
• bot/자동화 전략 없음 — 수동 moderation은 확장되지 않음
• culture fit이 아니라 기능으로 선택 — 기능 < 멤버가 번성하는 곳
• 쉽게 마이그레이션할 수 있다고 가정 — 플랫폼 전환은 고통스러움

---

title: ambassador와 champion 프로그램 impact: HIGH tags: ambassador, champion, superuser, advocacy, leadership

ambassador와 champion 프로그램

영향도: 높음

ambassador는 커뮤니티의 힘을 배가하는 사람들입니다. ambassador가 된 최상위 커뮤니티 멤버는 커뮤니티 활동의 10-30%를 만들고, 회사 콘텐츠보다 구매 결정에 5배 더 큰 영향을 줍니다. 잘 구조화된 프로그램은 열정적인 사용자를 커뮤니티 리더로 바꿉니다.

프로그램 유형

champion vs ambassador

프로그램 구조 프레임워크

TIER 1: 커뮤니티 멤버
│ 누구나 참여 가능
│ 기여에 대한 기본 인정
│
├── TIER 2: champion (상위 기여자)
│   │ 향상된 권한
│   │ champion 배지
│   │ 팀에 직접 접근
│   │
│   └── TIER 3: ambassador (선발된 리더)
│       │ 공식 프로그램 멤버십
│       │ 독점 혜택
│       │ 외부 대표
│       │
│       └── TIER 4: 자문단(최상위 ambassador)
│           전략 의견
│           가장 가까운 관계
│           가장 높은 혜택

선정 기준

champion 선정(organic emergence):

관찰할 것:
✓ 꾸준히 도움을 줌(질문에 답변)
✓ 긍정적 태도(건설적, 환영)
✓ 품질 높은 기여(정확하고 사려 깊음)
✓ 정기적 존재감(주간 이상 활동)
✓ 동료에게 존중받음(다른 사람이 그들과 상호작용)

위험 신호:
✗ 자기 홍보만 함
✗ 논쟁하거나 갈등을 만듦
✗ 활동이 불규칙함
✗ 부정확한 정보

ambassador 지원 기준:

필수:
- 활성 커뮤니티 멤버(6개월 이상)
- 입증된 전문성
- 긍정적인 커뮤니티 평판
- 헌신 의지

우대:
- 외부 존재감(블로그, 소셜, 발표)
- 관련 전문 역할
- 지역/인구통계 다양성
- 사명에 대한 열정

지원 질문:
1. 커뮤니티에 어떻게 기여했나요?
2. ambassador로서 무엇을 하겠나요?
3. 어떤 외부 플랫폼/청중에 도달하나요?
4. 월 몇 시간을 헌신할 수 있나요?

ambassador 프로그램 혜택

Tier 1: 기본 ambassador

인정:
- 공식 ambassador 배지
- 디렉터리 등록
- 커뮤니티 인정

접근:
- 비공개 ambassador 채널
- 월간 ambassador 통화
- 기능 조기 접근

리소스:
- 독점 콘텐츠와 자산
- ambassador 굿즈 키트
- 발표/글쓰기 지원

Tier 2: senior ambassador

모든 Tier 1 혜택에 더해:

인정:
- 프로필 소개
- 컨퍼런스 발표 기회
- 공동 마케팅 기회

접근:
- 제품 로드맵 가시성
- 제품 팀으로 가는 직접 연락선
- 분기별 전략 통화

리소스:
- 이벤트 출장 예산
- 콘텐츠 제작 예산
- 프리미엄 굿즈

Tier 3: 자문단

모든 Tier 2 혜택에 더해:

인정:
- 자문 직함
- 연례 리트릿 초대
- 공개 공동 브랜딩

접근:
- 전략 계획 의견
- 임원 접근
- 투자/커리어 기회

리소스:
- 충분한 활동비
- 컨퍼런스 후원
- 전담 지원 연락처

좋은 ambassador 프로그램

프로그램: [Product] Champions

비전: 열정적인 사용자가 우리 커뮤니티를 이끌고 성장시키도록 지원합니다.

멤버십: 전 세계 ambassador 50명

헌신 시간: 월 5-10시간

요건:
- 커뮤니티에서 월 5개 이상 질문 답변
- 분기당 콘텐츠 1개 생성
- 월간 ambassador 통화 참석
- 외부 상호작용에서 긍정적으로 대표

혜택:
- champion 배지와 인정
- 무료 프리미엄 구독(연 $240 가치)
- 연간 굿즈 키트($100 가치)
- 분기별 가상 이벤트
- 제품 팀에 직접 피드백 채널
- 우선 지원
- 발표 시 컨퍼런스 티켓
- 추천 보너스(적격 리드당 $100)

선정: 상시 지원, 분기별 cohort

기대사항이 문서화되어 있고, 혜택이 명확하며, 헌신 시간이 달성 가능합니다.

나쁜 ambassador 프로그램

프로그램: "[Product] VIPs"

문제:
✗ 모호한 요건
  "가능할 때 소문을 퍼뜨려 주세요"
  → 책임 기준이 없고 참여가 고르지 않음

✗ 불명확한 혜택
  "독점 접근과 혜택"
  → 실제 가치가 아니라 마케팅처럼 들림

✗ 구조 없음
  → 열정적으로 출시하고 3개월 뒤 사라짐

✗ 획일적 방식
  → 고성과자가 비활성 멤버와 같다고 느낌

✗ ambassador 사이의 커뮤니티 없음
  → 고립되고 서로 연결되지 않음

✗ 가져가기만 하고 주지 않음
  → 콘텐츠를 기대하지만 아무것도 제공하지 않음

활동 기대사항

게임화(신중히 사용)

포인트 시스템 예시:
- 분기 100포인트: 상태 유지
- 분기 200포인트: 실버 등급
- 분기 400포인트: 골드 등급
- 분기 600포인트: 플래티넘 등급

등급별 혜택:
실버: 기본 굿즈, 배지
골드: 프리미엄 굿즈, 조기 접근
플래티넘: 모든 혜택, 자문 접근

주의:
✓ 게임화는 일부에게 동기를 줌
✗ 게임화는 다른 일부에게 반감을 줌
✓ 허영이 아니라 결과에 포인트 부여
✗ 포인트를 위한 포인트는 금물

신규 ambassador 온보딩

1주차: 환영
- 프로그램 세부사항이 담긴 환영 이메일
- 비공개 채널에 추가
- ambassador buddy와 짝지음
- 환영 굿즈 발송

2주차: 오리엔테이션
- 프로그램 기대사항 walkthrough
- 도구와 리소스 교육
- 첫 활동 과제
- 팀과 만나는 통화

3-4주차: 통합
- 첫 기여 지원
- 피드백과 인정
- 동료 ambassador와 연결
- 정기 리듬 확립

2개월차 이후: 지속 운영
- 월간 체크인
- 분기별 리뷰
- 지속적 피드백
- 성장 기회

ambassador 성과 관리

ambassador 커뮤니티

ambassador 사이에 커뮤니티를 만드세요:

채널:
- ambassador 전용 비공개 Slack/Discord
- 월간 화상 통화
- 연례 ambassador summit

문화:
- 동료 인정
- 지식 공유
- 프로젝트 협업
- 진짜 우정

혜택:
- 동료와 네트워킹
- 서로에게 배우기
- 회사에 전달하는 집단 목소리
- 커리어 기회

프로그램 운영

지표

ambassador 프로그램 출시

1단계: 설계(4주)
- 프로그램 목표 정의
- 등급과 혜택 구조화
- 지원 프로세스 생성
- 온보딩 자료 구축

2단계: 시드(4주)
- founding ambassador 10-15명 초대
- 최상위 커뮤니티 멤버 직접 선발
- 피드백으로 프로그램 반복 개선

3단계: 공개(지속)
- 지원 접수 공개
- 정기 코호트 접수
- 지속 개선
- 운영 확장

안티패턴

• 이름뿐인 ambassador — 실제 혜택이나 접근권 없이 배지만 있습니다
• ambassador 과다 — 의미가 희석되고 관리가 어렵습니다
• 책임 기준 없음 — 모두를 받아들이고 아무것도 기대하지 않습니다
• 일방적 추출 — 콘텐츠를 가져가고 아무것도 돌려주지 않습니다
• ambassador 무시 — 프로그램을 출시하고 잊어버립니다
• 커뮤니티 없음 — ambassador가 서로를 모릅니다
• 정적인 프로그램 — 혜택이 영원히 같고 발전 경로가 없습니다
• 과도한 요건 — 특정 활동을 강제해 진정성을 죽입니다
• 부실한 오프보딩 — 비활성 ambassador가 남아 프로그램 신뢰도가 떨어집니다
• 피드백 루프 없음 — ambassador가 무엇을 원하는지 묻지 않습니다

---

title: 커뮤니티 주도 성장 전략 impact: CRITICAL tags: strategy, clg, growth, community-led, acquisition

커뮤니티 주도 성장 전략

영향도: 중요

커뮤니티 주도 성장(CLG)은 커뮤니티를 지원 채널에서 성장 엔진으로 바꿉니다. 강한 커뮤니티를 가진 회사는 매출의 5-25%가 커뮤니티 활동의 영향을 받습니다.

커뮤니티 주도 성장 움직임

CLG vs PLG vs SLG

커뮤니티 성장 퍼널

┌─────────────────────────────────────────────────────────┐
│  인지도                                                  │
│  ├── 커뮤니티 콘텐츠가 검색에서 순위 상승                │
│  ├── 멤버의 소셜 공유                                    │
│  └── 외부 커뮤니티 평판                                  │
├─────────────────────────────────────────────────────────┤
│  고려                                                    │
│  ├── 잠재 고객이 커뮤니티를 조용히 관찰                  │
│  ├── 실제 사용자 문제가 해결되는 것을 봄                 │
│  └── 제품-시장 적합성을 실시간으로 관찰                  │
├─────────────────────────────────────────────────────────┤
│  결정                                                    │
│  ├── 질문하고 동료 답변을 받음                           │
│  ├── 성공한 사용자의 사회적 증거                         │
│  └── 커뮤니티 검증을 통한 위험 감소                      │
├─────────────────────────────────────────────────────────┤
│  온보딩                                                  │
│  ├── 커뮤니티가 가치 도달 시간을 가속                    │
│  ├── 일반 문제에 대한 동료 도움                          │
│  └── 템플릿, 예시, 모범 사례                             │
├─────────────────────────────────────────────────────────┤
│  유지 및 확장                                            │
│  ├── 제품을 넘어선 지속 가치                             │
│  ├── 동료를 통한 기능 발견                               │
│  └── 관계 고착 효과                                     │
├─────────────────────────────────────────────────────────┤
│  옹호                                                    │
│  ├── 자연 추천                                          │
│  ├── 콘텐츠 제작                                        │
│  └── 외부 발표, 글쓰기                                  │
└─────────────────────────────────────────────────────────┘

커뮤니티 전략 canvas

좋은 커뮤니티 전략

목적 문장:
"서로가 안정적인 소프트웨어를 출시하도록 돕는 DevOps 엔지니어
커뮤니티를 만들고 있습니다. 우리 제품은 그들의 toolkit 중 하나지만,
커뮤니티는 더 넓은 커리어와 전문성을 지원합니다."

가치 제안:
✓ 복잡한 문제에 대한 동료 지원
✓ 커리어 네트워킹과 채용 기회
✓ 업계 트렌드와 도구 조기 접근
✓ 제품 로드맵에 대한 직접 영향
✓ 동료 사이의 인정

성장 모델:
- 콘텐츠가 SEO 발견을 만듦
- 무료 가치가 신뢰를 구축
- 참여 멤버가 동료를 추천
- 챔피언이 외부로 증폭

나쁜 커뮤니티 전략

목적 문장:
"지원 비용을 줄이고 영업 팀을 위한 리드를 만들기 위해
커뮤니티를 구축합니다."

안티패턴:
✗ 커뮤니티가 얇게 가린 영업 채널
  → 멤버는 이용당한다고 느끼고 빠르게 떠남

✗ 가치가 한 방향으로만 흐름(회사 → 멤버)
  → peer-to-peer 연결도 stickiness도 없음

✗ 성공을 MQL로만 측정
  → 단기 추출이 장기 가치를 파괴

✗ 커뮤니티 팀에 투자 없음
  → founder가 part-time으로 하다가 커뮤니티가 죽음

✗ 즉시 수천 명에게 launch
  → core group도 culture도 없이 혼란

커뮤니티 포지셔닝 프레임워크

권장: 제품 중심으로 시작하고 지속 가능성을 위해 practice/identity 중심으로 진화하세요.

초기 core 구축

1단계: founding members (0-50)
├── 열정적인 초기 사용자를 직접 선별
├── 필요를 이해하기 위한 1:1 대화
├── invite-only, high-touch
└── culture와 규범 확립

2단계: 초기 커뮤니티 (50-500)
├── 큐레이션이 있는 공개 접근
├── 첫 커뮤니티 프로그램
├── 챔피언 식별
└── 초기 ritual 확립

3단계: 성장 커뮤니티 (500-5,000)
├── 확장 가능한 시스템 필요
├── moderation 팀 필요
├── sub-community 등장
└── governance가 중요해짐

4단계: 확장된 커뮤니티 (5,000+)
├── 커뮤니티가 대부분 스스로 운영
├── 전문 커뮤니티 팀
├── ecosystem 사고
└── 여러 touchpoint와 프로그램

중요한 CLG 지표

CLG 투자 모델

커뮤니티-제품 통합

안티패턴

• 커뮤니티로 위장한 lead gen — 멤버는 거래 의도를 감지하고 신뢰는 죽음
• 명확한 목적 없음 — 공유 identity 없는 "커뮤니티"는 실패
• 비즈니스 지표만 측정 — 커뮤니티 건전성을 놓치고 추출에 최적화
• 팀에 과소투자 — 커뮤니티가 번성하려면 전담 관심이 필요
• culture 전에 확장 — 규범 없는 성장은 혼란을 만듦
• 커뮤니티 피드백 무시 — 들리지 않는다고 느끼는 멤버는 떠남
• 커뮤니티와 제품 분리 — 통합이 network effect를 만듦
• 즉각적 ROI 기대 — 커뮤니티는 compound됨; 12-18개월을 줄 것