안녕하세요, 제가 알아낸 내용을 공유하고 싶어서 이렇게 글을 씁니다… 저는 기존 회원 사이트에서 포럼으로 Discourse를 사용하고 있으며, 기존 사이트에서는 회원끼리 서로를 차단할 수 있습니다. 사용자가 A가 사용자를 B를 차단하면, A와 B 양쪽 모두 서로를 볼 수 없고 상호작용도 할 수 없게 됩니다.
저는 Discourse에서도 동일한 기능이 작동하도록 해야 했습니다. 어떻게 해야 할지 머리를 쥐어짰고, 마침내 해결한 것 같습니다:
Discourse 웹훅을 설정하여 이벤트를 수신받도록 했습니다. 이렇게 하면 user_logged_in 이벤트를 캡처할 수 있습니다.
사용자가 로그인하면, 제 사이트에서 해당 사용자의 ‘차단’ 목록을 순회합니다.
차단하려는 각 다른 회원에 대해, Discourse API를 사용하여 해당 사용자를 "무시(Ignore)"하도록 설정합니다. (참고로 이는 SSO와는 아무런 상관이 없습니다!)
그리고 여기가 핵심입니다: 로그인 중인 주 사용자를 무시하도록 Discourse에 다른 사용자에게도 지시합니다. 다시 말해, 현재 로그인 중인 사용자 A와 사용자 A의 차단 목록에 있는 사용자 B가 서로를 "무시"하게 됩니다.
“무시” 메시지를 전송할 때, 해당 사용자가 최소한 TL2(TL2)인지 확인해야 합니다. “무시” 기능은 TL2 전용이기 때문입니다. 만약 TL2가 아니라면, "무시"를 완료하기 전에 빠르게 TL2로 업그레이드해야 합니다. 사용자를 TL2로 업그레이드하면 다른 부수적 효과(디스코봇 고급 스크립트 시작, 배지 수여 등)가 발생하여 이를 처리해야 했습니다.
아, 그리고 Discourse 사용자 프로필의 “무시된(Ignored)” 목록을 숨깁니다(단순한 CSS 사용). 이는 메인 사이트에서 차단된 사용자를 관리할 수 있는 인터페이스가 있기 때문입니다. 저는 Discourse 회원들이 Discourse 무시 목록을 전혀 보지 않기를 원합니다.
자, 문제는 이겁니다. Discourse의 “무시” 기능은 상대방을 완전히 숨겨주지 않습니다. 상대방의 메시지를 보이지 않게 하죠(이 부분은 정말 훌륭하게 처리됩니다)… 대신 '숨겨진 x개 메시지 보기’라고 적힌 링크로 대체합니다… 이건 CSS로 쉽게 숨길 수 있으니 큰 문제는 아닙니다.
하지만! 누군가가 차단된 사용자의 글을 인용(quote)한 경우, 인용된 내용 자체는 보이지 않지만 해당 메시지에서 상대방의 아바타와 이름이 여전히 보입니다. 또한 메시지 답글 표시에서도 상대방의 아바타와 이름이 그대로 노출됩니다. 정말 짜증나네요.
즉, 제 사이트에서 사용자 A가 사용자 B를 차단하고… 제가 이전 메시지에서 설명했듯이 양방향 무시(double-ignore) 트릭을 사용하는 경우… 사용자 B(본인은 사용자 A를 차단하지 않은 상태)는 갑자기 사용자 A가 포럼에 게시물을 올리는 것을 이상하게 보게 됩니다. 그리고 사용자 A가 자신을 차단했음을 알아차릴 수 있습니다. 즉, 사용자 A가 누구를 차단했는지에 대한 개인 정보가 사용자 B에게 노출되는 셈입니다. 제 사이트에서는 이건… 전혀 좋은 일이 아닙니다.
아이고…
결국 저는 이제 드디어 RoR를 배워서, 기존 “무시” 기능을 확장하는 플러그인을 작성해야 할 것 같습니다. ‘무시’ 목록에 있는 사용자의 모든 흔적을 정말로, 완전히 지워주는 기능 말이죠. 그러면 다시 양방향 차단 아이디어로 돌아갈 수 있을 겁니다…
자, 경고합니다. 아주 사소한 방어적인 불평이 나올 예정인데, 당신보다는 저에게 차단을 필요로 하지 않는다고 말했던 모든 사람들을 겨냥한 것입니다.
저는 수십 년 동안 커뮤니티 관리 업무를 직접 해왔습니다(예전 AOL, CompuServe, GEnie에서 메시지 보드와 채팅룸의 커뮤니티 업무를 담당했을 때부터요). 지금은 제 이름으로 된 커뮤니티 사이트를 운영하고 있습니다. 포럼은 사이트의 일부이며, 제 사이트 커뮤니티의 많은(전부는 아니지만) 사람들이 상호작용하는 곳입니다.
차단이 왜 좋은 생각이 아닌지에 대한 이유를 저는 완전히 이해합니다… 이해합니다. 정말로요. meta.discourse에서 찾을 수 있는 모든 메시지를 읽었습니다. 무시(Ignore) 기능을 간청하는 사람들을 보았고, 그것이 왜 좋은 생각이 아닌지에 대한 오가는 논쟁을 보았으며, 결국 여러분이 굴복하여 소프트웨어에 해당 기능을 추가한 순간도 보았습니다.
이 모든 과정에서, 저는 일부 사람들이 단순히 Discourse만 사용하거나 단순히 포럼 기반 커뮤니티만 운영하는 사이트가 아니라는 사실을 잊었다고 생각합니다.
제 현재 상황은, Discourse가 등장하기 전에 이미 제 사이트에 강력한 커뮤니티가 있었습니다: 이전 포럼(그 엉망진창인 오래된 소프트웨어로)뿐만 아니라, 제 사이트의 채팅룸 기능(정규 멤버들이 있고 포럼과 겹치는 자체 커뮤니티가 있는) 및 기타 커뮤니티 중심 기능들에서도 그랬습니다.
좋든 나쁘든, 제 사이트는 항상 다른 멤버를 "완전히 차단"할 수 있는 기능을 제공해 왔습니다. 커뮤니티 문제 때문이기도 하지만, 제가 제공하는 커뮤니티가 법적 우려를 포함한 여러 이유로 인해 제 프라이버시에 대해 매우 민감하게 대할 것을 기대하기 때문이기도 합니다(진심으로요).
"차단은 좋은 아이디어인가?"라는 질문은 이 시점에서 제가 해야 할 올바른 질문이 아닙니다. 개인적으로 차단이라는 아이디어를 좋아하지는 않지만, 그 배는 이미 떠나고 말았습니다.
(조금 더 배경을 설명하자면: 제 이전 포럼은 사이트의 이전 소유자가 내린 결정들로 인해 꽤 독성이 강했습니다. 사람들이 2방향 차단을 요구한 이유 중 하나는 포럼 내의 그런 문제들 때문이었습니다. Discourse로 업그레이드하고 완전히 새로운 포럼을 공개하는 과정의 일환으로, 저는 손상된 포럼 커뮤니티를 복구하는 데도 힘쓰고 있습니다.)
다시 한번, 정확히 말씀드리자면, 차단은 일반적으로 건강한 커뮤니티의 징후가 아니라는 것을 제가 완전히 이해한다는 점을 명확히 하고 싶습니다. 사실, 저는 이전에 차단을 남용했던 회원들이 좀 더 차분해지도록 노력하고 있습니다.
그러니.
만약 제가 완전히 새로운 커뮤니티를 시작한다면, 저는 분명히 Discourse로 시작할 것이고 2방향 차단이 필요하지 않을 것입니다.
만약 제 사이트가 이미 2방향 차단 기능을 제공하지 않았다면(또는 이전에 2방향 차단을 지원했던 포럼 소프트웨어에서 업그레이드하는 것이 아니라면), 저는 Discourse에서 2방향 차단을 필요로 하지 않을 것입니다.
만약 제 현재 포럼 커뮤니티가 이미 손상되지 않았다면, 저는 2방향 차단을 필요로 하지 않을 것입니다. 하지만 그들은 과거에 끔찍한 경험을 했었고, 이는 차단 기능이 필요하다는 요구로 이어졌으며, 저는 그것을 구현해야 했습니다. 이제 Discourse로의 전환은 커뮤니티를 이미 뒤흔들고 있는 큰 변화입니다(제가 가지고 있던 것과 많이 다르기 때문에 과정이 필요합니다). 그리고 "아, 그리고 참고로 차단을 없애겠습니다"라고 말하는 것은 적절한 시점이 아닙니다. 반란이 일어날 것입니다.
어쨌든. 이 긴 답변에 대해 사과드리며, 제가 너무 방어적으로 들리지 않기를 바랍니다. 저는 차단에 대한 철학적 논쟁이나 그것이 왜 건강한 것이 아닌지에 대한 논쟁에 휘말리고 싶지 않을 뿐입니다.
저는 여전히 완전 차단(full-block) 기능이 필요합니다.
모든 피드백과 도움에 진심으로 감사드립니다! 그리고 제가 이 모든 것을(이 미친 듯이 긴 메시지를 작성하는 시간을 들여) 게시하는 이유 중 하나는, 제가 Discourse 커뮤니티에 보답하고자 노력하고 있기 때문입니다.
마지막으로 이렇게 마무리하겠습니다: 제가 지금 요청하는 것을 Discourse가 정확히 제공하지 않는다는 것을 알고 있습니다. 하지만 꽤 가깝습니다! 저는 Discourse 팀을 설득하여 소프트웨어에 추가하도록 하려는 것이 아닙니다(그 대화는 제가 여기 오기 훨씬 전에 시작되어 끝났습니다)… 하지만 저는 앞에 있는 도구들을 사용하여 제 목표를 달성하려고 노력하고 있습니다… 그리고 여기저기서 본 지혜롭고, 영리하고, 창의적인 사고자와 코더들의 도움을 요청하고… 그리고 그 과정에서 발견한 것들을 다른 사람들과 공유하고 있습니다.
자동 차단 기능이 없는 것은 소규모에서 중규모 포럼에서는 문제가 되지 않지만, 제 생각에는 대규모 플랫폼에서는 필수적입니다.
그 이유는, 회원이 많을수록 게시물이 많아지고, 이는 잠재적으로 훨씬 더 많은 대인 관계 문제를 야기할 수 있기 때문입니다. 10명의 모더레이터 팀이 1만/2만/3만 명의 회원을 가진 포럼을 쉽게 '관리’할 수 있지만, 회원 수가 증가할수록 그 밖의 모든 것이 더 빠른 속도로 증가합니다 - 더 많은 목소리 > 훨씬 더 많은 게시물 > 훨씬 더 많은 문제.
이것이 모든 대형 소셜 네트워크 플랫폼이 차단 기능을 제공하는 주요 이유 중 하나입니다. 또 다른 이유는 법적 관점 때문입니다. 만약 누군가 다른 회원에게 괴롭힘을 당하고 있다고 신고했는데 사이트가 아무 조치도 취하지 않는다면(예: 괴롭힘이 일어나지 않는다고 판단하여 "그건 전부 그들의 머리 속 문제"라고 생각하는 경우), 그리고 그 사용자가 자살을 한다면, 사이트는 법적 책임을 질 수 있습니다. 누군가 진심으로 괴롭힘을 당한다고 느낀다면 그것이 그들의 느낌입니다 - 당신이나 제가 어떻게 생각하든 상관없습니다. 중요한 것은 회원에 대한 돌봄 의무가 있다는 것이며, 그들이 그렇게 느끼지 않도록 하는 가장 좋은 방법 중 하나는 그 상호작용을 끊어주는 것입니다 - 이는 자신에게 고통을 주는 사람들을 차단할 수 있도록 허용하는 것(또는 때로는 우리가 그들에게 이를 강제하는 것)으로 가장 잘 이루어집니다.
판사와 배심원 역할을 하던 시대는 이미 오래 전에 지나갔으며, 우리도 그렇게 해야만 할 필요가 없습니다. 다른 사람에게 고통을 주는 것이 무엇인지, 아니 무엇이지 않은지를 결정하는 것은 우리의 일이 아닙니다.
실제로 이것이 제가 더 현대적인 모더레이션 도구가 필요하다고 생각하는 이유이기도 합니다. 모더레이터는 사람들의 게시물을 편집해야 하는 상황에 놓여서는 안 됩니다(대부분 이는 검열로 인식됩니다). 허용할 수 없는 게시물이 있다면, 이를 단순히 시야에서 제거하고 수정을 요청한 뒤, 수정된 내용을 검토 대기열에 넣을 수 있어야 합니다.
정말 잘 말씀하셨습니다. (그리고 이건 꼭 가상의 상황이 아닙니다. 저희 커뮤니티의 경우, 과거에 법 집행 기관에 개입을 요청한 적이 있습니다.) 이런 상황을 고려하고, 회원들이 스스로를 관리할 수 있는 도구를 제공하는 것은 매우 중요합니다… 또한 저는 잘 운영되는 커뮤니티 사이트라면 누구나 이 점을 중요하게 여겨야 한다고 생각합니다.
동의합니다. 그런 옵션이 있다면 큰 도움이 될 것입니다. 일반적으로 저희 포럼에서는 다른 사람의 게시글을 절대 수정하지 않습니다… 바로 이런 이유들 때문이죠. 회원들이 저희가 그들의 글에 손을 대는 것을 매우 민감하게 받아들이기 때문입니다. 현재 Discourse에서 문제 있는 콘텐츠를 처리할 수 있는 옵션은 (a) 메시지를 삭제하거나 (b) 메시지를 삭제하지 않는 것뿐입니다. 조금 무뚝뚝한 방식이고, “망치 하나만 있으면 모든 것이 못처럼 보입니다.” (미래의 모더레이션 도구에 대한 이 논의는 다른 토픽에서 하는 것이 더 적합할 것 같다는 점도 이해하고 있습니다…)
우리가 강요당하고 있는 것이 바로 이것입니다. 게시물을 수정하거나 삭제해야 하는(다른 많은 이유로 인해 이상적인 방법은 아니지만) 이유는, 만약 해당 게시물이 다른 회원에 대해 비하적이거나 우리가 원하는 것보다 덜 친근한 태도를 보이고 있다면, 다른 회원이 그 게시물을 보기 이전에 제거하는 것이 더 나기 때문입니다. 일단 그들이 게시물을 보게 되면, 대인 관계 문제를 예방할 수 있는 기회 창이 닫히고, 악순환이 시작됩니다. 시간이 지남에 따라 이는 관련된 두 회원만을 넘어 훨씬 더 큰 영향을 미칩니다.
네, 이 문제를 해결하는 데 플래그 시스템이 훌륭할 것 같습니다. 위에서 언급한 것 외에도, 사용자에게 '권장 수정 사항’이나 어떤 형태의 메시지를 보낼 수 있는 기능이 있다면 이상적일 것입니다(플래그가 관리자によって 전송되었거나, 검토 대기열에서 처리될 때 필수로 설정할 수 있음).
내 “서로 무시(mutual ignore)” 트릭의 재미있는 부작용 중 하나는 이제 이런 이메일을 정말 많이 받게 된다는 점입니다. 수십 통씩요. 이걸 억제할 방법이 있을까요? 사라지는 게 아쉬울 뿐 아니라(커뮤니티 문제를 찾아내는 데 매우 유용하다고 생각하기 때문) 제가 “무시” 기능을 블록 기능을 작동시키기 위해 전용으로 쓰고 있어서, 이런 알림은 의도치 않은 부작용이 되고 있습니다.
저희가 운영하는 매우 다양한 구성원으로 이루어진 디스코urs 포럼에서 이것이 어떤 영향을 미쳤는지 목격한 바 있어, 이 문제에 대해 한마디 덧붙여야겠습니다.
강제 이중 블로킹(forced double-blocking)은 끔찍하고, 또 끔찍한 아이디어입니다. 이는 보호하려는 취약한 개인에게 포럼의 의지를 강요하는 행위입니다. 본질적으로 "이 사용자와 함께 있으면 안전하지 않고 불편함을 느끼고 있다는 것을 이해하지만, 단순히 그 사용자의 게시물을 숨기는 것만으로는 허용할 수 없습니다. 당신이 이렇게 했다는 사실을 발견 가능하게 만들어, 이제 그 사용자에게 당신을 노리고 폭발할 또 다른 이유를 줄 것입니다"라고 말하는 것과 같습니다.
트위터에서 공개적으로 여성임을 밝힌 많은 회원들의 노력이 있었기에, 트위터는 이것이 왜 끔찍하고, 또 끔찍한 아이디어인지 이해하게 되었고, “무음(mute)” 기능을 허용하게 되었습니다. 이 기능은 해당 사실에 대해 사용자에게 알리지 않고 당신의 뷰와 타임라인에서 사용자를 제거하는 것입니다.
이 이유 하나만으로도, 이것이 디스코urs의 기능으로 존재한다면, 그것은 _요청자_가 선택해야 하며, 관리자의 의지나 사이트의 의지에 따라서는 안 됩니다.
사용자가 누군가를 블로킹해 달라고 요청하고, _사이트가 해당 사용자가 동의 없이 사용자 X에 의해 블로킹되었다고 그 사용자에게 통보_한 경우, 그리고 블로킹된 사용자가 상황을 악화시킨다면, 사이트의 관점에서도 법적 책임이 발생할 수 있는 실제 사례가 됩니다. 하지만 그보다 더 중요한 것은, 이것이 블로킹 기능을 전혀 사용하지 않겠다는 사람들에게 확실히 위축 효과를 미칠 것이라는 점입니다(저는 개인적인 경험을 통해 이를 목격했습니다). 또한 이는 가해자에게 권력을 이양합니다. "내가 알 테니까 나를 블로킹할 수 없어!"라고요.
여기서 저는 분명하게 동의합니다. 이것은 디스코urs의 기능이 절대로 없어야 하거나, 반드시 요청자 선택(opt-in)으로만 이루어져야 하며, 여기서 발생할 수 있는 실제적인 악화의 위험이 무엇인지 명확히 알려야 합니다.
아니요, 접근 방식의 문제가 아닙니다. “이 사용자는 저에게 불안감이나 불편함을 유발하므로, 그 사용자의 메시지를 더 이상 보고 싶지 않다”는 요청은 완전히 타당하며, 관리자가 동의하든 동의하지 않든 전혀 무관합니다.
포럼 운영자로서 우리가 원하든 원하지 않든, 사용자가 자신이 소비하는 콘텐츠에 대한 통제권을 갖도록 하는 것은 고귀한 목표입니다.
그렇지 않으면, 그 사용자는 커뮤니티를 떠나고 그 사용자의 기여물도 함께 사라져 버리기 때문입니다. 무시 대상 사용자에게 이중 금지 조치를 취하거나 통보해야 한다는 사이트의 과도한 관리에 “참아야” 하는 상황은 발생해서는 안 되며, 다른 이유로 그런 옵션이 제공되어야 한다면 반드시 선택적(opt-in)이어야 합니다.
그렇지 않을 경우, 다른 사용자에 대한 우려를 표명한 사용자의 자율성을 박탈하는 것이 됩니다. 그것은 그 사용자의 눈입니다. 어떤 것이 눈에 들어오는지, 그리고 누가 그 결정에 대해 알게 되는지를 통제할 권리가 있습니다.
(미래의 모더레이션 도구에 대한 이 논의는 다른 토픽에서 하는 것이 더 적합할 것 같다는 점도 이해하고 있습니다…)
