왜 회사/팀 내부에서는 Slack 대신 Discourse를 사용해야 하는가 (4년 사용 사례)

커뮤니티 구축 칭찬
1

우리는 4년 이상 Discourse를 주요 소통 도구, 기록 관리, 연구 문서화, 실험 일지 작성 도구로 사용해 왔습니다.

많은 기업들이 Slack, 이메일 체인, WhatsApp 대신 Discourse를 주요 소통 도구로 사용한다면 큰 이점을 얻을 것이라고 주장합니다.

결국 핵심은 이것입니다: 직원들 간의 대화가 향후 회고에 어떤 가치를 지닌다고 믿는다면, 여러분은 Discourse가 필요합니다.
그 단순한 이유는 채널 기반의 즉각 메시지 앱(Slack 등)은 오직 그 용도, 즉 매우 구체적인 것을 찾지 않는 한 다시 돌아가서 검토하고 싶어하지 않는 즉각적인 대화에 적합하기 때문입니다. 이러한 앱은 수천 줄에 달하는 긴 채널 안에 여러 대화를 엮어 넣고 수백 개의 하위 대화를 포함하는 경향이 있습니다.
반면, Discourse는 본질적으로 대화를 카테고리, 주제, 태그로 나누어 팀 구성원이 특정 주제, 연구 분야 및 관련 대화를 단순히 Discourse 주제를 일지처럼 읽음으로써 온보딩할 수 있게 해 줍니다. 이는 6가지 다른 대화 주제와 모든 사람의 점심 주문이 하나의 텍스트 스트림으로 융합된 채널에서 무슨 일이 있었는지 파헤치려 하지 않아도 됩니다.
귀사/팀/연구소가 어떤 형태의 R&D에 참여하고 있다면, 저는 Discourse가 필수라고 생각합니다.

Chat - 누락된 연결고리

모든 대화가 정보의 금광인 것은 아닙니다… 사실, 많은 대화는 상담, 질문, 반드시 별도의 주제가 되지 않는 빠른 브레인스토밍 세션과 같은 일상적인 것입니다. “이 버그와 에러 로그가 뭔지 누가 알아?” 또는 “오늘 점심은 뭐 먹지?” 같은 진술도 마찬가지입니다. 그래서 Slack은 여전히 모든 사람이 빠르고 효율적으로 소통하기 위해 남아 있어야 했습니다. Discourse에 Chat이 도입되면서, 모든 형태의 대화와 토론을 하나의 훌륭한 플랫폼으로 통합할 수 있게 되었습니다!

우리의 설정 - 빠르고 안전하게

우리는 AWS EC2에 Discourse를 설치했습니다. 처음 몇 년 동안 우리는 약 5명의 작은 팀이었기 때문에 t3.small만으로도 충분했습니다. 오늘날 우리는 더 크고 부유해져서 m5.xlarge를 사용할 수 있습니다.
AWS 서버를 실행하고 있으므로 S3 버킷에 권한을 부여할 수 있으며, 따라서 S3 객체 스토리지 업로드를 쉽게 활성화하여 모든 첨부 파일, 이미지, 엑셀, csv, pdf가 안전하게 백업되도록 합니다.
우리는 Secure Uploads를 활성화하여 데이터를 보호합니다(우리는 Discourse를 초대 전용 모드로 설정하고 로그인하지 않은 방문자에게 포럼 또는 파일에 대한 액세스를 거부합니다).
참고: 우리는 물론 Secure uploads의 목적에 반하기 때문에 CDN 사용을 권장하는 사항을 무시합니다.

생산성을 위한 플러그인

  • Assign → 주제를 사람에게 할당하는 것은 팀 구성원이 티켓/이슈/프로젝트를 소유하는 좋은 방법입니다.
  • Math → 연구를 수행한다면 Latex와 수식 지원이 필요합니다.
  • Reactions → 이것은 단순한 현대적 소통 방식입니다. 제 생각에는 Discourse에 기본 내장되어야 합니다.
  • Shared Edits → 팀이 위키나 기타 지식/정보 페이지를 공유하고 편집하는 데 매우 좋습니다.
  • Whos Online → 팀에서는 누가 온라인인지 아는 것이 필수입니다.
  • Footnote → 기업에는 법적 조항이 필요합니다.. 기밀 조항을 작성할 장소입니다.
  • 논쟁의 여지가 있지만 Calendar는 유용하지만, 구현 및 작동 방식은 우리에게 적합하지 않습니다. Topic Voting은 또 다른 잠재적으로 유용한 플러그인입니다.

테마 컴포넌트:

  • Custom Header Links → 회사/팀의 중요한 링크를 헤더에 배치합니다. 우리는 휴가 게시판, “내 작업”(assign 플러그인용), Jira 보드에 대한 링크를 가지고 있습니다…

  • PDF previews + iframe Lightboxes → 이 둘을 함께 설치하고 iframe origin domains에 자체 도메인을 포함하도록 설정하면, 포럼에 업로드된 모든 PDF 파일이 스레드와 함께 인라인으로 열리도록 표시되고 전체 보기로 확장하는 버튼이 있습니다. PDF는 매우 유용하며, 이렇게 하면 공유하기가 쉬워집니다.

  • Discourse Chat Sidebar → 채팅을 앞으로 가져오세요. 우리는 모두 24"에서 27" 화면을 사용하며 Slack/WhatsApp의 모든 작업을 Discourse로 옮기고 싶습니다.

  • 명예의 전당:
    ** discourse gifs 제 생각에는 Discourse에 기본 내장되어야 합니다.
    ** Discourse Kanban Jira를 대체하지는 않지만 고수준 작업에 도움이 되며 "assign plugin"과 잘 작동합니다. 올바르게 구성해야 하며, 이를 수행하는 것은 쉽지 않았습니다.
    ** Sidebar Theme Toggle 우리는 기본 다크/라이트 테마만 사용하므로 사용자가 쉽게 선호도를 선택할 수 있도록 합니다

결론

우선, 놀랍고 영감을 주는 Discourse 팀에게 감사드립니다 :clap:
Discourse는 타협 없는, 견고하고 빠르며 안전한 소통 플랫폼이며, 더 많은 팀이 기업, 대학 연구실 팀, 스타트업 등에 사용하도록 영감을 받기를 바랍니다!

86개의 좋아요
Dedicated chat client?
MKJ's Opinionated Discourse Deployment Configuration
Chat Sidebar
Chat sounds only working sometimes...intermittently or not at all?
Why isn't Discourse more frequently recommended as a "community platform"?
2024: The Year in Review
3

Discourse를 활용하는 방법에 대한 여러분의 통찰을 정말 좋아합니다. 다른 독자분들에게도 알리고 싶은 편리한 요청입니다 :loudspeaker: 내부적으로 Discourse를 어떻게 사용하고 계신지 더 많이 듣고 싶습니다. 이는 우리에게 무엇이 잘 작동하는지 배우고, 잘 작동하지 않는 부분을 우선적으로 수정하는 데 큰 도움이 됩니다.

우리는 내부적으로도 Discourse를 사용하고 있으므로, 우리의 유사점과 차이점(사실 많지는 않죠!)을 듣는 것도 꽤 재미있습니다.

:writing_hand:t2: 메모 중입니다 – 이 부분들을 고려해 보겠습니다. 감사합니다!

24개의 좋아요
4

좋은 정보 감사합니다. 덕분에 채팅(예: Slack, Mattermost, RocketChat)과 지식 공유(예: Confluence)의 전통적인 조합을 사용하는 방식과, Discourse 플랫폼을 사용하여 모든 것을 처리하는 방식을 비교해 보게 되었습니다.

자체 호스팅으로 Discourse 인스턴스를 운영하고 계신데, 휴대폰 알림은 어떻게 처리하시나요? 제 이해가 다소 구식일 수 있지만, 웹에서는 사용자에게 브라우저에서 사이트 알림을 활성화하도록 요청할 수 있습니다. 모바일에서는 Discourse 인스턴스가 Discourse 자체에 의해 호스팅되지 않는 한, 알림이 휴대폰 잠금 화면으로 전송되지 않는다고 알고 있습니다. 채팅 응답/토픽 답변에 시간적 긴박감이 자주 수반되는 경우, 이러한 알림은 어떻게 처리하시나요?

9개의 좋아요
5

솔직히 말씀드리면, 현재 푸시 알림은 다소 불편한 부분이 있습니다.
내장된 푸시 알림은 (어쨌든..) Android와 데스크톱 사용자에게는 작동하지만, iPhone 사용자에게는 작동하지 않습니다.

제 생각에 푸시 알림의 문제는 사용자가 알림을 받기까지 넘어야 할 장벽이 너무 많다는 것입니다. Discourse 개인 설정에서 활성화해야 하고, 브라우저에서도 허용해야 하며, Android/Windows 시스템에서도 허용해야 합니다. 이 세 가지 중 하나라도 알림을 차단하면 사용자는 알림을 받을 수 없습니다. 개인적으로 저는 푸시 알림을 적극적으로 원하지만, 항상 임의의 기간이 지나면 알림이 멈추는 것을 발견합니다. 브라우저 업데이트 때문일까요? 모르겠습니다. 따라서 Android 환경에서도 제가 원했던 대로 제대로 작동한다고 말하기 어렵습니다.

어제 Pushover 알림을 시도해 보았는데, 기능적으로는 Android/Apple/Windows에서 작동하지만, 두 가지 주요 결함이 있습니다(이것이 제가 최종적으로 사용하지 않은 이유입니다):

  1. 모든 사용자가 휴대폰에 서드파티 앱을 설치하고, 자신의 user_id를 Discourse 설정 페이지에 수동으로 복사해야 합니다 :grimacing:
  2. 알림이 팝업으로 뜨지만, Discourse 채팅/토픽으로 바로 이동하는 대신 Pushover 앱으로 이동합니다. 거기서부터 두 번째 탭으로 채팅/토픽 URL로 이동할 수 있습니다. 사소한 것처럼 들릴 수 있지만, 다이렉트 메시징 알림의 관점에서 푸시 알림 메시지와 실제로 가고 싶은 곳 사이에 게이트웨이 앱을 추가하는 것은 경험을 크게 저하시킵니다.

Discourse는 매일 수십 개의 커밋을 통해 지속적으로 개선되고 있으므로, 푸시 알림이 개선될 것이라고 여전히 낙관적입니다. 제 이상적인 시나리오는 관리자가 커스터마이징하여 Play/App 스토어에 제출할 수 있는 오픈소스 네이티브 Android/iOS 앱입니다. 하지만 OneSignal과 같은 서드파티를 통해 작업하는 것이 더 간단하고 동일한 목적을 달성할 수 있을지도 모릅니다.

9개의 좋아요
6

푸시 알림 옵션을 테스트해 주셔서 감사합니다. 저 역시 동일한 인상을 받았습니다. 옵션이 무엇이든, 사용자가 느끼는 마찰이 너무 크다는 것입니다. 이는 디스코URS만의 문제가 아니라, 디스코URS와 유사한 플랫폼들이 더 널리 채택되는 것을 가로막는 문제입니다. 즉, 알림과 알림을 통한 사용자 유지력(스틱키니스) 문제입니다.

4개의 좋아요
7

푸시 알림에 대해 진지하게 고려하고 있습니다. 다만, 우리가 호스팅하지 않는 포럼의 데이터를 처리하는 것은 원치 않습니다.

기술적인 우회 방법은 있습니다. 예를 들어 "핸드폰, X 사이트가 새로고침을 원해"라고 전송하는 방식이 이 주요 한계를 우회할 수 있을 것입니다. 또한 페이로드를 암호화하는 방법도 이 문제를 해결할 수 있을 것입니다.

요즘 아이폰의 PWA(유럽 지역 제외)와 안드로이드의 PWA는 꽤 잘 작동합니다. 하지만 유럽이라는 변수 때문에 네이티브 앱에 대해 더 깊이 고민하게 되었습니다.

17개의 좋아요
8

아래 부분에는 동의합니다.

PWA 알림은 작동할 때는 Android에서 잘 작동한다고 느끼지만, 작동이 중단된 것을 알아차리는 데 시간이 오래 걸리기 때문에 그런 경우가 드문 편입니다.

2개의 좋아요
9

최근에 여러 가지 수정을 했는데, 제 폰의 PWA 푸시 알림은 몇 달째 안정적으로 작동하고 있습니다. 이 문제가 완전히 해결된 것은 아니지만, 만약 '작년에 문제가 있었다’는 것이 근거라면 다시 한번 시도해 보시는 것을 강력히 권장합니다.

그런데… Apple이 유럽에서 PWA를 종료하게 되면서 이 문제를 어떻게든 해결해야 하는 상황이 되었고, 그렇게 할 것입니다.

9개의 좋아요
10

지난해라고 하셨을 때 2023년 12월을 의미하신 거라면, 그 시기와 맞물릴 수 있을 것 같습니다. 알림이 없으니 더 이상 작동하지 않는다는 사실을 알아채기 어렵거든요. 제 경우에도 마지막으로 작동을 멈췄던 시점은 12월에서 1월 사이 어딘가였습니다.

지금까지의 경험상 알림이 약 1개월간 정상적으로 오고, 그 후 약 2개월간 알림이 꺼져 있다는 것을 알아채지 못하는 주기가 반복되고 있습니다. 그러다 다시 알림을 켜서 이 주기가 시작되곤 하죠. 한 번 더 시도해 보겠습니다. 다시는 이런 일이 일어나지 않기를 바랍니다. 더 큰 문제는 제가 이 사이트에서 단연코 가장 파워풀한 사용자라는 점입니다. 평균적인 사용자는 저처럼 이런 세부 사항에 주의를 기울이지 않습니다. 이 시점까지 알림 설정 페이지를 두 번 이상 방문한 사용자는 극소수에 불과할 거라고 추정합니다.

방금 데이터 탐색기로 확인해 보니, 매일 450~500명이 방문하는 사이트에서 push_subscriptions 기록이 있는 활성 사용자는 30명뿐이었습니다. 약 6%의 사용률입니다. 그중 3분의 1은 2024년 이후로 업데이트되었습니다.

이 분야에서 이루어진 모든 노력에 감사드립니다. 또한 많은 부분이 외부 요인(예: Apple, Google)에 의존한다는 점도 잘 이해하고 있습니다. 하지만 "꽤 잘 작동하고 있다"는 표현이 제 경험이나 원 게시자의 경험과 일치하지 않는다는 제 의견을 전하고 싶을 뿐입니다.

6개의 좋아요
11

우리가 잘 알고 있듯이, 이제는 더 이상 그런 상황이 아닙니다.

그래도 여전히 Discourse가 PWA 배포의 표준을 세우고, 푸시 통지를 통해 헤게모니를 구축하는 데 앞장서기를 바랍니다!

9개의 좋아요
12

jira에 더 가깝게 다가갈 수 있도록 도와줄 수 있는 Tickets 플러그인도 있습니다.

또한 인라인 PDF 미리보기의 플러그인 버전도 있는데, 기억이 맞다면 모바일에서도 작동합니다.

1개의 좋아요
13

저희는 Discourse send PDF inline 를 사용하고 있으며 불만은 없습니다.

5개의 좋아요
14

그렇습니다, 기억이 맞다면 이 플러그인은 모바일에서도 작동할 수 있게 해줍니다. 아직 직접 설치해야 하지만, 정말 멋진 플러그인 추가입니다.

15

@Alon1 내부 커뮤니티에 대한 논의가 이루어지는 것을 보니 반갑습니다. 내부 커뮤니티는 그 자체로 고유한 도전 과제들을 안고 있습니다. 특히 모더레이션(관리)은 전혀 다른 차원의 문제일 수 있습니다. NSFW(성인 콘텐츠)나 스팸 게시물은 거의 관련이 없지만, 대신 주제 충도성(topic fidelity), 명확성, 그리고 기밀성 요구사항 준수가 그 자리를 차지합니다.

궁금한 점이 있습니다. 주제의 질을 높이기 위해 어떤 조치들을 취해 오셨나요? 그리고 모더레이션 팀은 어떤 구성인가요? 경영진이 이러한 필요성을 이해하도록 설득하는 데 얼마나 어려웠나요?

5개의 좋아요
16

이토록 흥미롭고 유용한 보고서를 공유해 주셔서 감사합니다.

저 역시 Discourse를 활용해 개인 및 조직의 가상 인프라를 구축하는 비슷한 경로를 걸어왔습니다.

저는 주로 소수의 핵심 프로젝트를 수십 년간 진행해 온 솔로prenuer(솔로 기업가)입니다. 따라서 새로운 경로와 하위 프로젝트(그리고 하하위 프로젝트), 그리고 작업을 즉석에서 신속하게 시작할 수 있는 도구가 필요합니다.

이것들은 글쓰기와 관련된 연구 자료들의 모음입니다.

효율성과 단순성을 위해 다양한 오픈소스 도구와 플랫폼(유료 도구도 포함하며, 차별 두지 않습니다)을 많이 사용하며 테스트해 왔습니다.

최근 몇 년간 Discourse와 Ghost가 제 다양한 워크플로의 중심에 가장 자주 자리 잡고 있음을 발견했습니다.

4개의 좋아요
17

중요한 점을 지적해 주셨네요!
모든 포럼에는 그 주위를 둘러싸고 형성되는 문화와 시간이 지나면서 만들어지는 현상 유지(status quo)가 있습니다.
코로나19 초기에 팀원 간의 소통 수단, 연구 인사이트 보존, 이메일 체인보다 대화가 더 잘 추적될 수 있도록 하기 위해 디스코르스(Discourse)를 사용하기 시작했을 때, 저는 이 도구가 올바르게 사용되도록 하려고 했습니다. 적어도 제 시각에서 "올바르게"라는 것이 무엇을 의미하는지에 따르면요.
제 경우에는 7명뿐인 소규모 팀이었기 때문에 그리 어렵지 않았습니다. 저는 팀의 모든 구성원에게 주제별로 잘 분리되되, 동일한 주제를 여러 토픽에 중복하지 않도록 토픽을 만드는 방법을 직접 안내할 수 있었기 때문입니다. 또한 답변을 쓸 때 미래의 가치를 염두에 두도록 했습니다(예: 실험을 했다면, 그것을 설명하고 맥락을 제공하며, 무엇을 어떻게 했는지 그래프와 축 라벨을 함께 보여 주십시오. 그러면 몇 달 후 이 게시물을 다시 읽었을 때 여전히 가치가 있을 것입니다). 올바른 카테고리에 내용을 배치하고, 효율적으로 행동하여 최소한의 단어로 최대한 많은 정보를 전달하며, 친절하게 대하는 것 등도 포함됩니다.
좋은 핵심 문화가 자리 잡으면, 회사에 새로 합류하는 직원들은 최소한의 안내만으로도 자연스럽게 그 문화를 수용합니다.
저는 여전히 특정 사람들과 그들의 토픽과 답변을 어떻게 더 잘 만들 수 있을지에 대해 가끔 대화를 나눕니다. 이는 좋은 문화를 유지하는 데 도움이 됩니다.
결론적으로, 규모가 작을 때 핵심 문화에 집중하여 다듬어 놓으면, 회사가 성장할 때 자연스럽게 확장된다고 믿습니다.

8개의 좋아요
18

부서 간 논의가 있는 경우, 모든 사용자를 다른 부서의 그룹 멤버로 만들고 싶지 않을 때는 어떻게 처리하나요? 아니면 모든 사용자가 모든 논의에 접근할 수 있도록 해야 하나요? 제 경우를 보면, 일부 부서 수준의 논의는 다른 모든 사람에게 숨겨져야 합니다.

1개의 좋아요
19

모든 사용자는 하나 이상의 그룹에 속하며, 저는 특정 그룹이 특정 카테고리에 접근할 수 있도록 권한을 관리했습니다.
두 개의 카테고리는 모든 그룹에 공개되어 있지만, 일부 부서별 카테고리는 관련 그룹에만 제공됩니다.

한 사람이 여러 그룹에 속할 수 있는 기능이 이 문제를 해결합니다. 원래 소속 부서에 해당하는 주요 그룹을 유지하면서, 부서 간 업무를 수행하는 직원을 위한 그룹을 설계할 수 있습니다.

4개의 좋아요
20

개인적 의견(IMO)으로는, 이는 내부 커뮤니티를 위해 내릴 수 있는 가장 중요한 결정 중 하나이며 서두르지 말아야 한다고 생각합니다. 우리는 주로 내부 개발자 커뮤니티이므로, 도구 기반 접근 방식을 선택했습니다. 이 결정 하나만으로 부서 간 장벽(실로)을 허물고, 정보 제한 측면에서 정보 보안 부서도 만족시킬 수 있었습니다. @Alon1과 같은 방식을 채택하여 사용자가 여러 그룹에 속할 수 있도록 했습니다. 관심 있는 도구의 그룹에 가입하면 됩니다.

또한 플랫폼 전체에 기밀 및 프로젝트 특정 정보 공유를 금지하는 정책을 두고 있습니다. 거의 모든 문제를 클라이언트를 언급하지 않고도 설명할 수 있습니다.

관리자들이 이를 어떻게 이해하게 만들었나요? 실패한 커뮤니티의 사례를 보여줘도, 그들은 이 문제가 얼마나 심각한지 제대로 인식하지 못하고 지나치게 세세한 지적(pedantic)으로만 받아들이는 경향이 있습니다. 지금까지 우리는 괜찮은 문화를 유지해 왔지만, 관리자들은 어떤 일이 있어도 확장(scale-up)에 집착하고 있습니다. 플랫폼의 가치를 중시하는 것은 좋은 점이지만, 그 가치는 우리가 구축한 문화에서 비롯된 것임을 이해하지 못하는 것이 문제입니다. 현재 이 문화는 너무 빠른 확대로 인해 위협받고 있습니다.

또 하나 우리가 직면한 문제는 모든 사람이 자신만의 카테고리(Category)를 원한다는 것입니다. 내부 커뮤니티를 고려하고 있다면, 늘 '예’라고 듣는 데 익숙한 관리자들에게 '아니오’라고 말하는 것이 업무의 매우 피곤한 부분이 될 수 있다는 점을 알아두시기 바랍니다. :sweat_smile:

4개의 좋아요
21

사실 카테고리 권한은 매우 유용합니다.

예를 들어, 부서에는 두 개의 그룹이 있을 수 있습니다. 하나는 리더십(일부 카테고리에서 주제 생성이 허용될 수 있는 사람들)을 위한 그룹입니다. 또한 특정 그룹으로 제한된 태그 그룹을 사용하여 이 기능을 구현할 수도 있습니다.

1개의 좋아요