커뮤니티 소유 구조와 운영 모델에 대해 고민해 오던 중, 커뮤니티가 조직 내에서 어떤 위치에 있는지에 대해 더 알고 싶어졌습니다.
과거에는 명확하지만 서로 다른 두 가지 학파가 존재했습니다. 한쪽에서는 커뮤니티 팀이 자율적이고 자치적인 독립 단위로 운영되어야 한다고 주장했고, 다른 한쪽에서는 다른 부서 산하에 보고하는 것이 더 합리적이라고 제안했습니다.
저도 의견은 있지만, 대기업 내부에서 커뮤니티 매니저(CM)로 일해 본 경험은 없습니다. 현재 또는 과거에 해당 경험을 가진 분들의 이야기를 듣고 싶습니다.
제 생각에는 소규모 조직이거나 커뮤니티가 단 하나의 부서만 지원하는 경우, 해당 부서 산하에서 보고하는 것이 합리적이라고 봅니다.
예를 들어:
커뮤니티 목표
보고 대상
지원(고객 서비스) 분산
지원팀
고객 유치, 옹호, 이벤트
마케팅팀
제품 피드백, 테스트, 아이디어 발굴
제품팀
반면, 여러 부서를 지원하는 엔터프라이즈 규모의 커뮤니티는 자율적인 리더십 하에서 운영되는 것이 더 효과적일 수 있습니다. 해당 부서가 실로(silo)화되지 않고 강력한 크로스펑셔널 거버넌스가 존재한다면, 이는 여러 이해관계자의 상충되는 우선순위 문제를 가장 효과적으로 피할 수 있는 방법이라고 생각합니다.
커뮤니티 라운드테이블(Community Roundtable)의 데이터에 따르면, 응답자 중 독립적인 접근 방식을 채택하는 조직이 증가하고 있는 것으로 나타났으며, 응답자 중 약 30%는 1,000명 이상의 인력을 보유한 조직에 속해 있습니다.
현재 제 역할에서 커뮤니티 팀은 마케팅 조직 안에 속해 있습니다. 그리고 저는 이것이 실질적인 이점을 가져다준다고 생각합니다. 포지셔닝, 런칭, 콘텐츠, 옹호(advocacy), 그리고 회사가 전하려는 더 큰 스토리와 강력한 연결고리를 만들어 주니까요.
하지만 저는 커뮤니티가 전통적인 마케팅과는 다르다고 항상 생각해 왔습니다. 겹치는 부분이 분명히 있지만, 이 둘을 뒷받침하는 운영 로직은 다릅니다. 예를 들어, 고객 획득 퍼널(acquisition funnel)에서 효과가 있는 방식이 커뮤니티 내부에서도 반드시 통하는 것은 아닙니다. 때로는 가장 즉각적인 참여도나 캠페인 가치를 만들어 내는 것이 아니라, 경청하고 속도를 늦추며 피드백을 위한 공간을 마련하거나, 측정이 더 어렵더라도 신뢰를 지키는 것이 올바른 결정일 수 있습니다.
저에게 있어 마케팅 조직 안에 소속되어 있는 것의 가장 큰 도전은 커뮤니티가 “또 하나의 채널”로 축소되지 않도록 하는 것입니다. 커뮤니티는 단순히 방송을 송출하기 위한 또 하나의 대상(audience)이 아니기 때문입니다.
저는 커뮤니티 팀이 멤버 우선(member-first)의 결정을 내릴 수 있는 자율성을 가지는 동시에, 그들이 지원하는 팀들과 긴밀하게 연결되어 있을 때 이 모델이 가장 잘 작동한다고 생각합니다.
전체적으로 볼 때, “커뮤니티는 X 부서 안에 있어야 한다”는 것이 정답이라고 확신하지는 않습니다. 조직이 커뮤니티 팀에 부서를 넘나들며 운영할 수 있는 권한, 접근성, 그리고 신뢰를 부여하는지가 더 중요한 질문이라고 생각합니다. 물론 저는 엔터프라이즈 규모의 커뮤니티에서만 일해 왔지만, 더 작은 커뮤니티의 경우 커뮤니티가 주로 지원하는 부서에 보고하는 구조가 합리적일 수 있다고 봅니다. 하지만 커뮤니티가 동시에 마케팅, 제품, 지원, 성공, 교육 등 여러 부서를 지원하게 되면, 왜 더 독립적인 커뮤니티 리더십이 가치 있는지를 이해할 수 있습니다.
그렇지 않으면, 커뮤니티는 커뮤니티가 실제로 필요로 하는 것이 아니라, 커뮤니티를 관장하는 부서에 의해 형성될 위험이 있습니다.
동의합니다. 가장 기본적인 수준에서 커뮤니티는 퍼널 상단(top-of-the-funnel)의 고객 획득 채널로 기능하지만, 사용자가 그곳에 도달한 후에는 훨씬 복잡한 신뢰 관계를 형성하고 관리해야 합니다.
동의합니다. 바로 이 부분이 모델이 깨질 수 있는 지점입니다.
말씀하신 내용을 이해하면, 완전히 자율적인 커뮤니티 팀이 기능적으로 마케팅 부서에게 보고하는 구조라는 뜻이네요. 만약 그렇다면, 마케팅 팀이 멤버 퍼스트(member-first) 원칙에 부합하지 않는다고 판단되는 일을 하려 할 때 경계를 어떻게 설정하고 이해 충돌을 해결합니까?
그리고 커뮤니티가 마케팅 목표를 달성하기 위해 설계된 경우, 다른 부서의 이해관계자들로부터 오는 요구사항을 처리하는 데 어려움이 있습니까?
우리는 마케팅 조직 안에 소속되어 있기 때문에, '독립적인 사업 부’라는 의미에서 완전히 자율적이라고 표현하지는 않겠습니다. 하지만 기능적으로는 커뮤니티를 일상적으로 운영하는 방식, 공간의 톤을 보호하는 것, 그리고 멤버들에게 적합하다고 느끼는 것을 결정하는 데 상당한 자율성을 가지고 있습니다.
경계는 커뮤니티가 비즈니스 목표를 지원할 수는 있지만, 단순히 그 목표를 전달하는 수단만은 될 수 없다는 것입니다.
요청이 들어올 때 (마케팅 캠페인, 리서치 대화 등) 즉시 ‘예’ 또는 '아니오’라고 답하는 경우는 드뭅니다. 오히려 ‘여기서 멤버 가치는 무엇인가?’, ‘이것이 적절한 공간인가?’, '프레임이 커뮤니티와 우리가 가진 관계에 부합하는가?'를 묻습니다. 많은 경우 답은 ‘예, 하지만 그 형식으로는 아니다’, ‘예, 하지만 다른 접근 방식이 필요하다’, ‘그 채널에서는 아니다’, 또는 '준비 작업을 마친 후에야 가능하다’입니다.
요청이 '멤버 우선’이 아닌 경우, 대개는 프레임이 맞지 않기 때문입니다.
우리 팀 중 많은 팀이 커뮤니티의 가치를 인정하고 있어 좋은 일입니다. 하지만 각 팀의 '작은 요청’이 신중하게 관리되지 않으면 빠르게 소란스럽거나 착취적인 경험으로 변할 수 있습니다.
우리가 다른 팀이 그들의 전문 분야를 잘 안다고 신뢰하듯, 그들도 우리가 우리의 전문 분야를 잘 안다는 것을 이해합니다. 무언가를 지원하기 위해 창의적인 방법을 찾아야 한다면, 우리는 그렇게 할 것입니다.
두 가지 관점에 전적으로 동의합니다. 이와 함께 오는 주요 과제 중 하나는, 자신의 커리어를 망치지 않도록 수많은 이해관계가 충돌하는 사람들을 어떻게 조율하느냐는 것입니다:
상사를 실망시키면 예산/요청 처리가 어려워집니다.
사용자를 실망시키면 지표가 하락하고 불만이 상사에게 전달됩니다. 결국 상사를 실망시키는 셈이 되어 예산/요청 처리가 어려워집니다.
상사의 동료들을 실망시키면, 해당 주제에 대해 잘 안다고 생각하는 사람들이 회의에 참석하여 말이 안 되는 요구를 하게 됩니다. 상사가 커뮤니티에 대해 잘 안다면 그다지 나쁘지 않지만, 상사가 커뮤니티에 대해 잘 모른다면 이 사람들을 교육하려다 보니 파워포인트(PowerPoint) 실력이 아주 좋아질 것입니다.
상사의 상사를 실망시키면… 글쎄요, 무슨 뜻인지 아실 겁니다.
그렇다면 엔터프라이즈 레벨에서 커뮤니티를 소유(소속)하는 것이 가장 적합한 곳은 어디일까요?
제 의견으로는: 대외적(Outward facing) 커뮤니티는 고객 서비스(Customer Service)가, 대내적(Inward facing) 커뮤니티는 DevOps, IT, 또는 학습 및 지식 관리(Learning and Knowledge Management)와 같은 지원 역할로 비즈니스 전반에 걸쳐 확장되는 팀이 소유해야 합니다. 그리고 커뮤니티가 대외적이며 동시에 대내적이라면, 고객 서비스, 제품(Product) 등 각 부서의 대표들로 구성된 특정 커뮤니티 부서를 설립하는 것이 좋습니다. 이는 양쪽의 장점을 모두 제공합니다: 커뮤니티 헤드(Head of Community)에 의한 자율적 리더십과, 부서 대표들의 혼합(melting pot)에 의한 크로스펑셔널 거버넌스입니다.
마케팅(Marketing)을 목록에서 제외했다는 점을 알아채셨을 수 있습니다. 마케팅은 커뮤니티의 가장 일반적인 소유자이지만, 개인적으로 마케팅이 소유하는 커뮤니티를 좋아하지 않습니다. 단순히 그런 커뮤니티가 제 이익을 위해 운영된다고 느끼지 못하기 때문입니다. 생각해보면, 어떻게 그럴 수 있겠습니까? 마케팅의 목표는 제품을 구매할 수 있는 사람들을 찾고/유인하는 것이며, 이는 종종 "그 사람에게 가장 좋은 선택이 아니더라도 우리 제품을 구매하도록 설득하는 것"을 의미합니다. 항상 그런 것은 아니지만, 저로서는 의심스러운 시선으로 접근할 만큼 자주 그런 경우가 발생합니다.
반면, 고객 지원(Customer Support)을 커뮤니티의 소유자로 보는 것은 좋아합니다: 여기는 사용자/고객으로서 제 경험을 개선하는 것이 존재 이유(raison d’être)인 사람들이 소유한 장소입니다. 만약 커뮤니티가 대외적이라면, 고객 지원팀에 맡기되, 제품팀과도 매우 훌륭하고 긴밀한 관계를 구축하도록 요구하겠습니다.
흥미롭네요. 목표가 이탈 방지(마케팅의 일부)이지만 실제 활동의 대부분이 고객 지원(Customer Support)이라면, 왜 소유권이 고객 지원이 아닌 마케팅에 속하는지 그 구별 기준은 무엇일까요? 고객 지원이 더 적극적으로 활동하기 때문에 소유권이 고객 지원에 있는 것이 더 적절하지 않나요, 아니면 위계적 관점에서 고객 지원이 마케팅에 포함되나요?
예를 들어, 마케팅이 소유권을 가지는 일반적인 위계 구조는 다음과 같은 것일까요?
graph TD
HOM[마케팅 총괄] --> MCE[고객 성공/지원 매니저]
HOM --> MM[마케팅 매니저]
HOM --> MS_MGR[세일즈 매니저]
HOM --> CONTENT[콘텐츠/SEO 리드]
MCE --> CSS[고객 지원 직원]
MM --> MKT_STAFF[마케팅 직원]
MS_MGR --> SALES_STAFF[세일즈 직원]
우리는 엔터프라이즈 조직이 아니고 인원이 꽤 적기 때문에, 더 많은 인력이 있었다면 이렇게 설계하지는 않았을 수도 있습니다. 하지만 보고 라인은 크게 바뀌지 않을 것입니다.
"Support"는 Taylor와 메타의 팀 공용 메일함을 통해 주로 활동하는 기술 홍보 담당자(tech advocates)들을 가리킵니다. "Customer Success"는 Chau와 그의 팀으로, 이들은 비공개 카테고리를 통해 엔터프라이즈 고객들을 지원합니다. 마케팅은 전략을 소유하지만, 다른 부서들을 통해 업무량을 관리합니다.
Tobias가 떠난 후로 전담 커뮤니티 스태프가 없기 때문에, 이 구조는 다른 것보다 거버넌스/의사결정에 더 초점을 맞추고 있습니다. Danielle(CS)가 Mae(마케팅 디렉터)와 사내의 여러 사람들(저를 포함하여)의 지원을 받아 주도적으로 업무를 수행하고 있습니다.
정말 그런가요? 저는 메타에서 우리가 하는 것이 구매자를 위한 고객 성공(비공개 카테고리를 통해)과 빌더를 위한 DevRel 지원(메인 OS 커뮤니티)의 혼합이라고 생각합니다. 지원 팀은 팀 공용 메일함 외에는 메타 커뮤니티 지원을 위해 거의 시간을 쓰지 않기 때문에, 커뮤니티는 어느 정도 자립적으로 운영되고 있습니다.
메타는 티켓 분산(ticket deflection) 도구가 의도된 것이 아닙니다. 지원이 필요한 사람들의 대부분이 우리의 고객이 아니기 때문입니다.
아, 꽤 중요한 측면인 것 같네요. 덕분에 이 문제에 대해 아주 다른 시각을 갖게 되었습니다. 디스코urs가 무료이고 오픈 소스이기 때문에, 저는 항상 메타의 사용자를 고객으로 여겼습니다. 하지만 다른 한편으로, 대부분의 사용자는 지불을 하지 않으므로, 엄밀히 말해 고객은 아닙니다.
그리고 소유권을 파악하는 기준으로 그 선을 긋는 데 꽤 효과적인 정의인 것 같습니다. 대부분의 사용자가 제품을 위해 비용을 지불하고 있는가? 예 - 고객 지원; 아니오 - 마케팅.
예를 들어, 저는 만족스러운 사용자이지만 유료 고객이 아닙니다. 여기서 제가 드리는 피드백에는 버그 보고서, 수정 제안, 디자인 제안 및 디자인 결정에 대한 피드백, 기능 제안 등이 포함됩니다. 이 모든 것이 어디에 해당되는지 확실하지 않아요. 제품의 미래 방향을 어떻게 보고 있느냐에 따라 달라지니까요. 어쩌면 마케팅에 해당할 수도 있겠네요.
