여러분은 "Enterprise-Ready"가 어떤 모습이라고 보시나요? (대담한 의견 환영!)

여기 전문가 커뮤니티 운영자 여러분께 한 가지 질문을 드리고 싶습니다. 다른 곳에서 표면적인 수준으로만 논의되던 주제인데, 정의에 부합하는 깊이 있는 논의는 아직 본 적이 없거든요.

여러분은 커뮤니티의 ‘엔터프라이즈 레디(enterprise-ready)’ 상태가 무엇이라고 정의하시나요? 커뮤니티 플랫폼의 상태와 준비 수준, 그리고 확립된 기본 콘텐츠와 활동 측면에서 모두를 포함하여 질문드립니다. 이 주제가 과학이라기보다 예술에 가깝다는 제 생각을 뒤집을 수 있기를, 그리고 여기에 명확한 공통 패턴이 존재한다는 것을 입증할 수 있기를 기대합니다!

활동성은 측정하기가 상대적으로 쉽습니다. 벤치마크가 풍부하기 때문이죠.

포럼에서 '활발함(active)'의 기준으로 자주 인용되는 정의 중 하나는 Reddit의 ‘활발한 서브레딧’ 기준입니다. 저는 과거에 핵심 기반(critical core) 구축의 성공 여부를 가늠하는 실용적 기준으로 이 기준을 사용해 왔습니다. 역사적으로 이 기준은 '하루에 최소 5개의 게시물’입니다. Reddit은 과거 하루에 최소 5개의 게시물이나 댓글이 있는 서브레딧을 활성 커뮤니티로 집계했습니다. 신규 커뮤니티에서 하루에 개입이나 유도 없이도 그 정도의 게시물이나 댓글이 자연스럽게 발생한다면, 저는 스스로 지속 가능한 활동성을 달성했다고 판단합니다. 이는 새로운 분기 토론 영역이나 하위 카테고리 테스트에도 훌륭한 기준이 됩니다. 새로운 카테고리를 생성한 후, 여러분의 개입 없이도 하루 5개 이상의 활동이 발생하도록 성장시킬 수 있다면, 그것은 견고한 카테고리라고 할 수 있습니다.

엔터프라이즈 레디, 특히 B2B 또는 고객 커뮤니티의 경우, 이 기준을 하루 5개 이상의 게시물 또는 댓글, 그리고 48시간 이내에 80%의 주제에 대해 SLA 방식의 응답을 보장하는 것으로 수정하고 싶습니다. 새 게시물이 외롭게 방치되지 않고 답변을 받을 수 있도록 하는 것이 중요하다고 느끼지만, 동시에 주제에 대한 유기적 반응이 일어날 수 있도록 시간적 여유를 주는 것도 중요하다고 봅니다.

선호하는 공식이 있으신가요? 그 응답률 기준이 틀렸다고 생각하시나요? :grin:

주제를 너무 딱딱하게 나누지 않겠습니다만, 플랫폼 수준에서 엔터프라이즈 레디는 어떻게 보입니까? 제 짧은 목록을 든다면, 첫 번째 카테고리에 대한 견고한 분류 체계/정보 구조, 해결됨 또는 최선 답변 기능, 새 주기에 대한 기대 응답 시간 범위를 유지하기 위한 교활한 알림 및 라우팅, 그리고 최소한 몇 명은 되어야 하는 모더레이터 인력 확보를 꼽겠습니다. 또한 커뮤니티가 구축되는 조직을 보완하는 테마를 갖추는 것에 대해 매우 강조하지만, 그것은 전적으로 취향의 문제입니다.

여러분은 ‘엔터프라이즈 레디’ 커뮤니티가 어떤 모습이라고 보시나요? (뜨겁거나, 논란이 되거나, 반론을 제기하는 의견이 아니어도 좋습니다)

7개의 좋아요

엔터프라이즈 레디(Enterprise Ready)라고 하면, 규모에 따른 신뢰성, 가용성, 성능을 떠올리게 되는데, 이는 질문하신 내용과 다를 수 있습니다.

사이트 가동 시간 99.99%(4개의 9)를 유지하고, 가용성에 대한 정의 방식에 따라 다르지만, 하나의 구성 요소를 잃어도 가용성 자체가 사라지지 않고 용량만 감소할 수 있는 고가용성(High Availability) 또는 스케일아웃(Scale-out) 아키텍처에서 서비스를 실행하는 것이 중요합니다.

다음 단계로 나아가려면 글로벌 로드 밸런싱, 리전 간 로드 밸런싱, 또는 리전 밖의 재해 복구(Disaster Recovery) 시나리오를 고려해야 합니다.

사용자 인구 규모와 활동 수준(내장된 DAU/MAU 및 기타 통계에는 훌륭한 데이터가 포함되어 있음)를 고려해야 합니다.

사진 업로드나 채팅 기능 사용 시 성능 지연 없이 10,000명의 동시 활성 사용자를 처리할 수 있을까요?

사용자가 성능 문제나 지연/레이턴시를 인식하기 시작하는 시점은 언제일까요?

아는 것이 몇 가지 있습니다. 아키텍처가 비용을 결정하며, 규모에 맞춰 커뮤니티 설계를 어떻게 고려할지 사전에 이해하는 것이 중요합니다. 이는 어렵습니다. 엔터프라이즈 규모로 시작하는 것이 아니라면, 100명에게 필요한 것과 1,000명, 혹은 10,000명에게 필요한 것은 크게 다를 수 있기 때문입니다.

모놀리식 아키텍처의 단순성, 가용성 목표에 비해 단일 장애점(SPOF)의 위험, 그리고 Docker와 Kubernetes와 같은 접근 방식이 스케일아웃을 가능하게 하면서도 복잡성을 추가하는 지점 등에 대해 풀어야 할 것이 많습니다.

저는 Discourse의 큰 팬이고, 제 커뮤니티는 매우 작으며, Discourse와 같은 소프트웨어를 SaaS로 전환하는 방법에 대해 의미 있는 시간을 들여 평가해 본 적이 없습니다(메타를 운영하는 훌륭한 분들이 이를 해결하고 쉽게 보이게 만들었다고 가정합니다).

조금 방향을 전환해서, 질문하신 내용이 SLA(서비스 수준 협약, 계약이 함의됨)나 SLO(서비스 수준 목표, 기대치를 설정하는 데 사용될 수 있음)에 관한 것일 수 있다고 생각합니다. 이 또한 설계로 돌아옵니다.

모더레이터나 스태프가 몇 명이며, 모더레이터 대 사용자 비율은 어떻게 되는지, 그리고 게시량 대비 플래그된 게시글의 비율(예를 들어)과 비교하면 어떻게 되는지 궁금합니다. 관리자가 1명이고 사용자가 100명뿐이라면, 1영업일 SLO조차 약속하기 어려울 것 같습니다.

마지막으로 제안할 두 가지는 목표를 명확히 하고 시작하며, 명확한 요구 사항에 기반하여 설계를 구축하는 것입니다.

도움이 되셨기를 바랍니다! 행운을 빕니다!

3개의 좋아요

훌륭한 답변 감사합니다. 그리고 여기 정의에 규모에 따른 성능, 가동 시간(업타임), 서버 수준의 사용자 경험에 대한 상당한 초점이 맞춰져 있다는 점이 정말 흥미롭습니다.

성능은 커뮤니티 관리 커뮤니티에서 많이 논의되지 않는 항목 중 하나이지만, Discourse가 확실한 우위를 점하고 있는 분야이기도 합니다.

하지만 확실히 주요한 요인입니다. 제가 인용할 수 있는 가장 극적인 예시 중 하나는 XenForo의 구버전을 사용했던 Skyscraper City를 운영했을 때입니다. 이는 거대한 B2C 취미 커뮤니티였으며, 지역과 구역별로 나뉘어 있는 수많은 토론 영역을 가진 방대한 수량의 카테고리 및 하위 카테고리로 인해 지연이 발생하고 사용이 매우 불편했습니다. 전 세계적으로 독보적인 풍부한 콘텐츠를 보유하고 있었음에도 불구하고, 성능에 대한 불만이 가장 많았던 사례 중 하나였습니다.

커뮤니티 디자인 자체의 관점에서 보면, 엔터프라이즈 레디의 차이는 성능보다는 인프라적인 측면에 있습니다. 물론 커뮤니티 자체의 허용 한계에 대한 연구가 있는지 확실하지는 않습니다 - 우리는 Core Web Vitals 연구는 가지고 있습니다. Chromium Blog: The Science Behind Web Vitals 커뮤니티 내 활성 멤버들의 참여도가 높아질수록 낮은 성능에 대한 허용도와 인내가 역함수처럼 높아진다고 항상 생각해 왔습니다.

“엔터프라이즈 레디” 커뮤니티의 정의에서 자주 간과되는 필수 요건인 **“빠르야 해. 브룸 브룸!” :high_voltage:**를 제외하고, 다른 분들도 이에 대한 견해를 가지고 있는지 궁금합니다.

3개의 좋아요