하나의 브랜디드 커뮤니티 안에 세 개의 서브커뮤니티를 운영하기를 원하는 고객이 있습니다.
이러한 구성을 성공적으로 구현해 보신 분 계신가요? Groups(그룹)와 Categories(카테고리) 중 어떤 것이 더 적합할까요?
서브커뮤니티 각각은 고유한 브랜딩, 다른 멤버 경험, 그리고 상이한 기능 및 기능성을 활용해야 합니다.
세 커뮤니티 모두 동일한 커뮤니티 매니저 또는 팀에서 관리됩니다.
어떻게 구현하셨는지 경험담과, 공유해 주실 수 있는 예시가 있다면 듣고 싶습니다.
권한 관리 목적의 그룹을 3개 생성해야 합니다. 그런 다음 3개의 '서브 커뮤니티’를 위해 카테고리를 3개 생성해야 합니다.
예를 들어,
생성:
그룹 1
그룹 2
그룹 3
그런 다음 생성:
카테고리 1 (그룹 1용) - 카테고리 보안 권한: ‘그룹 1 생성/답변/보기’
카테고리 2 (그룹 2용) - 카테고리 보안 권한: ‘그룹 2 생성/답변/보기’
카테고리 3 (그룹 3용) - 카테고리 보안 권한: ‘그룹 3 생성/답변/보기’
그래서 별도의 포럼이 필요할 것 같아요.
@ondrej에게 추가하자면, 커뮤니티당 2개의 그룹이 필요합니다. 멤버 그룹은 권한이 있는 매니저를 오너로 두어야 합니다. 그런 다음 커뮤니티 매니저 그룹이 필요하며, 이 그룹은 카테고리 모더레이터 역할도 수행해야 합니다.
자체 호스팅 환경에서 Category Restrictor 플러그인을 사용하면 카테고리 모더레이터와 전체 사이트 모더레이터의 권한을 확장할 수 있습니다. 이 플러그인은 사용자가 특정 카테고리에서 게시물을 작성하지 못하도록 침묵(silence)시키는 기능을 추가합니다.
따라서 전체 계정 정지 및 전체 침묵 조치에 대한 지원을 위해 메인 사이트 팀이 필요합니다.
이 서브 커뮤니티들 간의 어떤 상호작용을 기대하시나요?
다음과 같은 질문들을 생각하고 있습니다:
한 커뮤니티의 멤버가 다른 커뮤니티에서 자유롭게 참여할 수 있기를 원하시나요?
그들에게 하나의 더 큰 커뮤니티처럼 느껴지길 원하시나요? 아니면 한 커뮤니티와 다른 커뮤니티에 참여할 때 완전히 다른 커뮤니티를 오가는 것처럼 느껴지길 원하시나요?
한 커뮤니티의 대화가 다른 커뮤니티로 넘어갈 수 있기를 원하시나요?
예를 들어, 토론 간의 크로스 링크를 많이 기대하거나 장려하시나요? 아니면 한 대화의 일부 인용을 다른 대화에 사용하는 것 등을 원하시나요? 혹은 그러한 행동이 일어나기 어렵거나, 장려할 가치가 없거나, 심지어 억제할 가치가 있다고 생각하시나요?
각 커뮤니티가 사용할 것으로 예상하는 다양한 기능과 기능의 예시를 공유해 주실 수 있나요?
여기서 마음속에 가지고 계신 몇 가지 다른 사항을 상상할 수 있지만, 생각하시는 내용을 더 잘 설명하는 데 도움이 되는 예시를 공유해 주시면 유용할 것입니다.
훌륭한 질문들입니다 
한 커뮤니티의 멤버가 다른 커뮤니티에 자유롭게 참여할 수 있기를 원하나요?
아니요, 한 커뮤니티의 멤버가 다른 커뮤니티 중 하나에 가입하거나 참여하고 싶어할 가능성은 매우 낮을 것입니다.
한 커뮤니티의 대화가 다른 커뮤니티로 넘어가기를 원하나요?
아니요, 상호 교류는 없을 것입니다. 이들은 완전히 다른 주제와 다른 대상 멤버를 가진 커뮤니티입니다.
각 커뮤니티에서 사용할 것으로 기대하는 기능과 기능성의 예시를 공유해 주실 수 있나요?
흥미로운 내용입니다.
이 중 일부는 이 세 가지를 별개의 사이트로 유지하는 것이 더 나은 선택일 수 있다는 생각을 하게 만듭니다. 그 가능성을 배제해 본 적이 있나요? 만약 배제했다면, 그 이유는 무엇일까요?
제 생각은 다음과 같습니다. 지금까지 보기에, 이 모든 것을 하나의 사이트로 통합하려는 동기는 이를 관리하는 팀의 편의성 때문인 것 같습니다. 하지만 이를 해결할 다른 방법도 있을 수 있습니다. 여러 커뮤니티에 설정 변경 사항을 적용하는 것은 다른 방식으로 해결할 수 있는 기술적 문제로 보이며, 각 커뮤니티를 분리해 두면 각 커뮤니티가 서로 다른 필요(커뮤니티가 발전함에 따라 더 달라질 수 있는 부분)를 가진다고 판단될 경우, 각 커뮤니티에서 다른 방식으로 일을 진행할 수 있는 더 큰 자유도를 보장할 수 있습니다.
한편, 제가 상황을 묘사한 방식에 몇 가지 예외가 있음을 암시하는 단서를 발견했습니다:
고유한 세 커뮤니티로 연결되는 링크가 있는 단일 브랜드 랜딩/홈페이지
이것이 왜 중요한가요?
이 커뮤니티에 속한 사람들이 서로 완전히 분리되어 있다면, 이 모든 것을 한 곳에서 보는 것에서 누가 이익을 얻게 되나요?
아마도 이 질문에 대한 답이 아직 제가 놓치고 있는 핵심 통찰로 이어질 수 있을 것입니다.
다시 말하지만, 이 문제를 다른 방식으로 다룰 수 있다고 생각합니다. 단순히 세 개의 링크가 있는 홈 페이지일 뿐이라면, 동적으로 콘텐츠를 가져오는 것까지 포함하여, 사이트 외부에서 구현할 수 있을 것입니다.
이상 모두를 말씀드렸지만, 위의 내용을 다시 검토하는 것이 도움이 되지 않는다고 느끼고, 이 모든 것이 하나의 사이트 아래에 있어야 한다는 결정이 내려졌다면, 지금까지 공유해 주신 내용을 맥락으로 삼아 어떻게 그렇게 할 것인지에 대한 원래 질문으로 대화를 되돌릴 수 있습니다.
정말 도움이 되네요, Dave! 피드백과 조언에 감사드립니다.
현재 저희는 탐색 단계에 있습니다. 이 커뮤니티가 어떻게 운영되어야 하는지 정확히 파악하려는 중이죠(회원 관점, 커뮤니티 매니저 관점, 그리고 조직 관점에서). 이 단계에서는 아직 어떤 것도 배제하지 않았습니다.
흥미로운 포인트를 많이 언급해 주셨고, 이해관계자들에게 몇 가지 질문을 던져야 할 것 같습니다.
여기서 배운 내용과 함께 명확히 해야 할 질문들의 답변을 받아본 뒤 이 스레드에 다시 돌아올 예정입니다. 최선의 접근 방식을 찾아내는 것에 기대가 큽니다 
이 링크에 대해 조금 더 자세히 말씀해 주실 수 있을까요? 이 스레드에서 주신 유용한 조언과 질문 덕분에, 저는 클라이언트에게 두 가지 옵션을 제시하기로 결정했습니다.
여러 커뮤니티를 포함하는 단일 사이트
여러 사이트
단일 사이트 구성을 검토하는 주된 이유는 커뮤니티 매니저 한 명이 세 곳의 커뮤니티를 모두 관리할 수 있도록 하기 위해서입니다. 비용 절감 목적은 아닙니다.
처음에는 가볍고 효율적인(lean) 접근 방식을 제안합니다.
그 뜻은 먼저 특정 사용 사례에 대한 구체적인 솔루션을 설계하고, 이를 실행에 옮긴 후 반복 개선(iterate)하는 것이 도움이 될 수 있다는 것입니다. 이것이 커뮤니티 팀을 위한 본격적인 크로스 커뮤니티 대시보드로 발전할 수도 있고, 혹은 ‘충분히 좋은(good enough)’ 수준이 그보다 훨씬 작을 수도 있습니다.
예를 들어, CM(커뮤니티 관리자)은 먼저 Discourse Hub를 사용하여 세 커뮤니티의 피드를 모두 확인하고, 각 커뮤니티에서 처리가 필요한 미해결 플래그가 언제 발생하는지 파악할 수 있습니다.
한 단계 더 나아가면, 그중 하나의 커뮤니티에 있는 채팅 채널을 ‘홈 베이스’로 사용하고, 먼저 모든 커뮤니티의 검토 대기열(review queue) 알림 피드를 구성하여 모든 커뮤니티의 운영(moderation)을 지원하는 것입니다.
메트릭과 리포팅의 경우, 각 커뮤니티의 관리자 UI 영역이나 데이터 탐색기(data explorer) 보고서에 대한 북마크 세트를 시작점으로 삼는 것이 간단한 출발점이 될 수 있습니다.
한 단계 더 나아가면, Discourse Automation을 사용하여 AI가 생성한 보고서를 설정하고, 해당 커뮤니티 내 다양한 소스의 데이터를 집계하여 각 커뮤니티의 PM(프로젝트 매니저)에게 보고서를 전달할 수 있습니다. 여전히 세 개의 별도의 PM이지만, 확인해야 할 곳은 줄어들 것입니다.
그보다 한 단계 더 나아가면, AI 페르소나(AI personas) 내의 도구를 사용하여 커뮤니티 전체에서 데이터를 가져와 단일 보고서를 작성하는 것입니다.
많은 구성 요소(building blocks)가 이미 준비되어 있다고 생각합니다. 그것들을 조립하는 것이 더 많은 작업처럼 보일 수 있지만, 동시에 정확히 필요한 것을 구축하고 어떤 부분을 더 빨리, 어떤 부분을 나중에 우선적으로 배치할지 결정할 수 있는 기회이기도 합니다.
그리고 모든 것이 가치 있다고 입증되고 더 많은 것이 원해지면, 원하는 결과를 제공할 것이라는 확신을 가지고 커스텀 플러그인 같은 더 맞춤화된 것을 구축할 수 있습니다.