# 토픽 내 하위 토픽 과다 생성 방지 방법

**URL:** https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257
**Category:** Community Building
**Created:** [9월 16, 2023, 9:00오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257 "2023-09-16T21:00:52Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [9월 16, 2023, 9:00오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/1 "2023-09-16T21:00:53Z")

</div>

이 글은 제가 가진 생각들을 정리한 것이며, 스레드가 지수적으로 팽창하기 시작할 때 회원들과 관리자들이 어떻게 대응할 수 있을지에 대한 암묵적인 질문을 담고 있습니다.

Discourse는 스레드형 토론을 제공하지는 않지만, 이전 답글에 대한 답글인 경우 일종의 백포인터(back-pointer)를 갖추고 있습니다. 또한 이전 답글을 인용하는 것도 가능합니다.

전체적으로, 주제에 이미 몇 개의 답글이 붙어 있다면 다음 답글은 다음과 같은 형태가 될 수 있습니다.

- 주제 전체나 헤드 포스트에 대한 일반적인 응답
- 바로 이전 포스트에 대한 구체적인 응답
- 인용을 동반하거나 하지 않은 채 다른 포스트에 대한 답글
- 두 개 이상의 이전 포스트를 참조하는 더 복잡한 형태

또한 답글은 다음과 같은 성격을 가질 수도 있습니다.

- 헤드 포스트의 원래 논점(제목에서 설명된 바를 hopefully)에 대한 대응
- 이전 스레드에서 언급된 지점의 연속
- 아직 언급되지 않은 새로운 아이디어의 도입

저는 세 번째 경우에서 상황이 통제 불능으로 흐르기 시작한다고 생각합니다. 각 포스트가 하나 또는 두 개의 새로운 아이디어를 도입하면, 다음 포스트가 응답할 수 있는 아이디어의 수가 지수적으로 증가합니다. 또한 원래 주제 제목과의 연결성이 지수적으로 희석될 가능성이 있으며, 제목은 더 이상 토론의 내용을 대표하지 않게 됩니다.

Discourse에는 스레드 기능이 없으므로, 다음과 같은 전술에 의존할 수밖에 없습니다.

- 주제에서 벗어나지 않고 분기를 피하는 데 엄격한 규율을 유지
- 명확하게 구별되지만 상당한 아이디어가 있을 때 새로운 연결 스레드를 시작
- 분기된 주제에 대해 논의하거나 피드백을 제공하기 위해 개인 메시지를 사용
- 관리자(모드)가 하나 이상의 포스트를 분리하여 새로운 주제로 전환
- 분기된 주제에서 발생한 아이디어를 개별적으로 다루는 새로운 스레드를 장려하기 위해 관리자(모드)가 스레드를 닫음

(연결 스레드 메커니즘이 인터페이스에서 잘 발견되지 않는다는 점이 이전에 언급된 바 있습니다.)

수정: 제 생각에 내재되어 있는 것은, 폭발적으로 팽창하는 주제(topic)는 나쁜 것이라는 점입니다. 단일 아이디어를 다루지 않기 때문에 결론에 도달할 수 없고, 나중에 누군가가 발견하고 응답할 수 있는 많은 아이디어를 포함하고 있기 때문에 영원히 닫히지 않을 수 있으며, 일관성이 없기 때문에 유용한 기록이 될 수 없습니다. 포럼의 목표와 문화에 따라 일부 포럼에서는 이러한 현상이 허용될 수 있고, 다른 포럼에서는 그렇지 않을 수 있습니다.

---

<div class="post-metadata">

### Author: ![Heliosurge](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/heliosurge/32/571810_2.png) [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [9월 16, 2023, 11:23오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/2 "2023-09-16T23:23:43Z")

</div>

> [@Ed\_S](#):
>
> Discourse에는 스레딩(threading) 기능이 없으므로, 다음과 같은 전술에 의존할 수밖에 없습니다.
> 
> - 주제에 집중하고 지양(tangent)을 피하는 데 엄격하게 임하기
> - 기존 주제와 구별되지만 실질적인 아이디어가 있을 때 새 연결된 스레드를 시작하기
> - 지양된 주제에 대해 논의하거나 피드백을 제공하기 위해 개인 메시지를 사용하기
> - 한 개 이상의 게시글을 새로운 주제로 분리하기 (관리자에 의해)
> - 분기된 주제에서 발생한 아이디어를 다루는 새 스레드를 장려하기 위해 스레드를 닫기 (관리자에 의해)
> 
> (연결된 스레드 메커니즘이 인터페이스에서 잘 발견되지 않는다는 점이 이전에 언급된 바 있습니다.)

결점이 있을 수는 있지만, 우리는 연결된 주제 옵션을 가지고 있습니다.

마스터 주제는 주요 포인트를 탐색하기 위한 출발점이 될 수 있습니다. 링크 발견이 직관적이지 않다는 데에는 동의합니다. 커뮤니티가 도구를 사용하는 법을 배우도록 안내하는 것이 이 상황에서 자원이 될 수 있습니다.

예를 들어, OP(게시글 작성자)가 광범위한 범위의 주제(브레인스토밍 주제)를 생성합니다.

주제 요소가 도입될 때마다 해당 분기를 탐색하기 위해 해당 주제를 가리키는 링크가 포함된 새 주제를 생성할 수 있습니다. 이러한 주제의 첫 번째 게시글에는 ‘무제한 편집’ 권한이 있어야 합니다.

도입된 각 주요 포인트와 해당 특정 주요 포인트에 대한 토론으로 연결되는 링크를 추가합니다.

OP가 핵심적인 역할을 수행하도록 하는 것이 최우선입니다.

OP와 참여자에게 책임을 부여하는 제 사이트의 예시:

> [@Heliosurge](#):
>
> **주제 스레드:**  
> _OP의 책임_
> 
> **1)** 주제 생성에 세심한 주의를 기울입니다. 즉, 사고(Trainwreck)나 개인 또는 조직에 대한 공격을 수행하도록 설계된 주제는 금지합니다.
> 
> **2)** 주제 소유자로서, 주제가 궤도를 벗어나지 않도록 돕습니다. 멤버가 주제에서 벗어날 경우 정중하게 주제의 목적을 상기시켜 주세요. 멤버가 계속해서 주제에 대한 불경을 저지를 경우, 주제에서 벗어난 게시글 링크와 범인 이름을 포함하여 @heliosurge에게 관리자의 개입을 요청하세요. 공정하게 행동하고, 주제를 되찾도록 두 번의 기회를 주세요.
> 
> **주제 참여자의 책임:**
> 
> **1)** OP의 주제와 서로를 존중합니다. 주제가 벗어날 때 정중한 상기시켜 주는 것으로 OP를 돕습니다.
> 
> **2)** 사람을 공격하는 것이 아니라 문제를 논쟁합니다. 비난, 모욕, 개인 공격을 피하세요. 논쟁이 뜨거워질 수 있지만 이는 괜찮으며, 한계를 알고 필요할 때 휴식을 취하세요.

이제 우리는 관리자로 하여금 일을 다소 쉽게 만들 수 있는 도구도 사용할 수 있습니다. 예를 들어:

1. \*\*Staff Notice(스태프 공지)\*\*는 새 주제가 필요한 게시글을 강조하거나 새 주제로 안내하는 데 유용할 수 있습니다.
2. \*\*Reply Thread(답글 스레드)\*\*는 새 주제로 분리할 게시글을 선택하는 데 도움이 될 수 있습니다. 게시글에 연결된 답글만 표시하기 때문입니다. 물론 이는 "주제에 답글 vs 게시글에 답글"을 포착하지 못할 수 있으므로, 삽입 게시글(insert post) 기능이 유용할 수 있습니다.

---

<div class="post-metadata">

### Author: ![Heliosurge](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/heliosurge/32/571810_2.png) [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [9월 16, 2023, 11:27오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/3 "2023-09-16T23:27:47Z")

</div>

> [@Ed\_S](#):
>
> 수정: 제 생각에 내포되어 있는 것은, 폭발적으로 커지는 주제들은 나쁜 것이라는 점입니다: 결론에 도달할 수 없기 때문입니다.

이는 주제의 성격에 따라 달라집니다.

예를 들어, **삶의 의미** 는 _예견 가능한 결론이 없는 PI 수준의 주제입니다._

그러나 게시글 작성자가 주제가 새로운 가능성을 모두 소진했다고 느끼면, “브레인스토밍” 주제를 닫아달라고 요청할 수 있습니다.

---

<div class="post-metadata">

### Author: ![anon65426961](https://avatars.discourse-cdn.com/v4/letter/a/34f0e0/32.png) [@anon65426961](https://meta.discourse.org/u/anon65426961)
#### Post date: [9월 17, 2023, 12:04오전 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/4 "2023-09-17T00:04:43Z")

</div>

이를 위해 도움이 될 수 있는 일반적인 정책은 하위 주제에 대한 언급이 어떤 종류의 반응을 일으키는지 구체적으로 모니터링하는 것입니다.

즉, 명확한 소개와 해당 특정 주제에 대한 수많은 답변이 있는 확립된 주제에 무관하거나 겉보기에 관련이 없는 댓글이 나오기 시작하면, 대부분의 사람들은 이를 무시할 것이며, 백과사전에 인쇄되는 경우가 아니라면 원래의 대화에 어떤 해를 끼치지도 않을 것입니다.

그러나 사람들이 완전히 다른 주제에 대한 댓글로 답장하기 시작하고, 그 주제에 대해你来往하는 대화가 이루어진다면, 이는 주요 주제를 압도하고 교란하기 시작할 수 있습니다. 그런 경우 다른 주제로 분할하는 것이 합리적일 수 있습니다.

특정 주제에만 제한되지 않고 더 개방적인 주제 스레드를 가지는 것은 좋은 일일 수 있습니다. 이는 사람들이 서면 언어를 사용하여 소통하는 일반적인 방식에 제한을 가할 수 있기 때문입니다. 또한, 하위 주제가 언급되는 데에는 완전히 정당한 이유가 있을 수 있으며, 이는 많은 사람들이 쉽게 이해하지 못할 수 있는 방식으로 원래 주제와 직접적으로 관련되어 있을 수 있습니다.

---

<div class="post-metadata">

### Author: ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)
#### Post date: [9월 17, 2023, 1:30오전 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/5 "2023-09-17T01:30:47Z")

</div>

> [@Ed\_S](#):
>
> 토픽에 답글이 한두 개를 넘어가는 경우

사람들은 원래 그런 법이니까, 이것이 핵심일 수 있습니다. 즉, 대화에서 유용하게 존재할 수 있는 답글이나 참여자의 최대 수가 있다는 것입니다. 저는 대면 대화에서도 이것이 사실이라고 생각합니다. 온라인 토론이 잠재적으로 수백 명의 참여자와 게시물을 허용한다고 해서, 토론이 그 정도로 확장되어야 한다는 의미는 아닙니다.

두 참여자 간에 약 50개의 답글이 오가는 토픽을 읽는 것을 즐기는 자신을 상상해 볼 수 있습니다. 또한 50명의 참여자가 질문을 던지고 한 사람이 답변하는 AMA(Ask Me Anything) 토픽을 즐기는 것도 상상할 수 있습니다. 하지만 25명의 사용자가 작성한 50개의 게시물이 있는 토픽을 읽는 것을 즐긴 적은 없는 것 같습니다. (여기서 모든 숫자는 근사치이지만, 요지는 이해하실 것입니다.)

Discourse의 명시된 목표 중 하나는 읽기가 근본적이라는 것입니다: [Because Reading is Fundamental](https://blog.codinghorror.com/because-reading-is-fundamental-2/). 이를 염두에 두고, 읽기 좋은 토픽을 만들기 위해 노력하는 것은 비합리적이지 않아 보입니다.

여기서 하위 토픽을 만들 위험을 감수하면서 말하지만, 과도한 수의 게시물과 참여자가 있는 토픽에 \_게시물\_을 올리는 것도 만족스럽지 않다고 생각합니다. 내 게시물이 고작 스쳐 지나가듯 읽힐 것이라는 느낌이 들기 때문입니다.

따라서 질문에 답하자면, 저는 관리자가 토픽을 닫는 것이 이상적인 접근 방식이라고 생각하지는 않지만, 때로는 그렇게 해야 하는 이유를 이해합니다. 더 나은 접근 방식은 토픽에 제약을 추가할 수 있는 기능을 갖추어 답글과 참여자를 제한할 수 있도록 하는 것이라고 생각합니다. 예를 들어, 제한된 사용자 풀을 선택하거나, 참여자당 최대 답글 수를 허용하도록 설정된 토픽에 응답할 수 있도록 신청할 수 있습니다. 본질적으로 이는 대화의 가치를 높이기 위해 인위적인 희소성을 만들어내는 것입니다.

---

<div class="post-metadata">

### Author: ![packman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/packman/32/289322_2.png) [@packman](https://meta.discourse.org/u/packman)
#### Post date: [9월 17, 2023, 10:39오전 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/6 "2023-09-17T10:39:36Z")

</div>

> [@simon](#):
>
> 예를 들어, 제한된 사용자의 풀을 선택하거나 신청을 받아 참여자당 최대 답변 수를 허용하도록 설정된 주제에 답변할 수 있게 할 수 있습니다. 본질적으로 이는 대화의 가치를 높이기 위한 목적으로 인위적인 희소성을 만들어냅니다.

저는 이 두 가지 모두 위험이 크다고 생각합니다.

제한된 수의 사용자만 답변할 수 있도록 하면, 온라인에서 많은 시간을 보낼 수 있는 소란스러운 키보드 워리어들의 목소리는 들리지만, 온라인에서 제한된 시간만 보낼 수 있는 조용하지만 지식이 풍부한 사람들의 목소리는 들리지 않게 될 가능성이 큽니다.

마찬가지로, 답변 수를 제한하면 뛰어난 통찰력을 잃을 수 있습니다. 예를 들어, 저는 주제를 따라 읽으며 사람들이 말하는 것을 명확히 하기 위해 허용된 2개의 답변을 사용했고, 이제야 삶, 우주, 그리고 모든 것에 대한 답이 되는 돌파구를 주는 생각이 떠올랐는데, 제 한도에 도달했기 때문에 아무도 그 생각을 듣지 못할 것입니다. 물론 새로운 주제를 시작할 수는 있지만, 맥락이 끊겨버리고, 이전 주제를 다시 언급하더라도 여러분이 답변하기 전에 그 내용을 읽는 사람이 몇 명이나 될지 의문입니다.

---

<div class="post-metadata">

### Author: ![51mon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/51mon/32/299702_2.png) [@51mon](https://meta.discourse.org/u/51mon)
#### Post date: [9월 17, 2023, 12:41오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/7 "2023-09-17T12:41:46Z")

</div>

> [@simon](#):
>
> Discourse의 명시된 목표 중 하나는 읽기가 근본적이라는 것입니다: [Because Reading is Fundamental](https://blog.codinghorror.com/because-reading-is-fundamental-2/)

바나나 🙂

이제 반쯤 기억나는 sourceforge에 대한 참조를 찾아 stackoverflow로 바꿔야 합니다 - 아니면 그냥 두지 않을까요? 정정 사항만 여기에 남겨둘게요

---

<div class="post-metadata">

### Author: ![51mon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/51mon/32/299702_2.png) [@51mon](https://meta.discourse.org/u/51mon)
#### Post date: [9월 17, 2023, 2:07오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/8 "2023-09-17T14:07:05Z")

</div>

> [@Ed\_S](#):
>
> Discourse에는 스레딩(threading) 기능이 없기 때문에 우리는

위 인용구를 **단순히 하나의 예시** 로만 선택했습니다. 이는 현재 대화의 가능한 진화를 형성하는 소프트웨어를 작성한 사람들의 머릿속에 있는 밈(meme)의 함의를 보여주기 위한 것입니다. 제목의 "avoid(피하라)"를 인용하고 이를 “encouraged(장려하라)”(또는 “managed(관리하라)”)로 변경할 것을 제안했어야 했을까요?

나는 위 인용구로부터 "따라서 이 소프트웨어 플랫폼에는 설계 결함이 있다…"라고 가정할 수 있습니다.  
또는 "이 플랫폼은 x에는 적합하지만 y에는 적합하지 않다(더 깊은 통찰력이 있었다면 XY와 Z에 적합하도록 엔지니어링되었을 수도 있었을 텐데)"라고 할 수도 있습니다.  
또는 "경험이 쌓이면서 발견되는 새로운 요구사항들이 디지털의 전환 및 확장에서 문명이 번영하기 위해 반드시 수용되어야 한다"고도 할 수 있습니다.

그리고 나는 다음과 같은 것이 여전히 현재의 지향점인지 가정할 수 있습니다.

> “다음 10년의 인터넷을 위해 구축되었습니다.  
> 우리가 설립한 회사인 Civilized Discourse Construction Kit, Inc.의 목표는 정확히 그것입니다 – 더 나은 토론 소프트웨어로 인터넷에 씨앗을 뿌려 인터넷에서의 문명화된 토론의 기준을 높이는 것입니다:”

[출처](https://blog.p2pfoundation.net/discourse-next-generation-discussion-platform/2013/05/07)

현재, 옳든 그르든 톤/분위기/용인/문화는 코드 블록이 아닌 지시 원칙을 도출하는 유형의 대화에 유리하지 않습니다. "유리하지 않다(not conducive)"고 말할 때, 나는 -희망컨대- 여러분의 편집 정신에 따라, 여러분의 초안에 심어둔 마인드셋이 적어도 어딘가, 어떤 형태로든 인식되고 탐구되어야 한다는 사실을 인정하고 있습니다.  
나는 메타(Meta)가 이를 수행할 장소라고 주장합니다. 만약 토론이 다른 포럼으로 밀려난다면, 그것은 결국 CDCK에게 경쟁 우위를 확장시켜 줄 것이 아닐 수도 있습니다(?).

최근 누군가 나에게 말한 것이 있습니다 [이 코멘트의 저자에게는 제가 약간 수정했으므로 양해 부탁드립니다] “프로그래머들은 사회학에 대한 통찰력 없이 커뮤니티 소프트웨어를 작성하고, 사회학자들은 설계 원칙에 대한 대화에 참여하기를 원하지 않는다” (그리고 현존하는 모더레이션 기준을 보면 놀라운 일도 아니죠?)

> [@Ed\_S](#):
>
> 편집: 또한 제 생각에 내포되어 있는 것은, 폭발적으로 확장되는 주제(explooding topics)는 나쁜 일이라는 것입니다: 결론에 도달할 수 없기 때문이며, 단일 아이디어를 다루지 않기 때문이고, 나중에 누군가가 발견하고 반응할 수 있는 많은 아이디어를 포함하고 있기 때문에 영원히 닫히지 않을 수 있으며, 일관성이 없기 때문에 유용한 기록이 될 수 없습니다. 일부 포럼에서는 이것이 괜찮을 수 있고, 다른 포럼에서는 포럼의 목표와 문화 때문에 괜찮지 않을 수 있습니다.

Ed, 당신의 "내포(implicit)"는 맞다고 생각합니다 - 제 생각에(IMHO) - 이 인용문의 나머지 부분은 검토되어야 하며, 사용된 렌즈에 따라 분석 결과가 달라질 것입니다.

나는 당신의 “can’t(할 수 없다)”, “don’t(하지 않는다)”, "not(아니다)"라는 단어의 사용을 짚어냅니다. 저는 목표와 문화에 관한 당신의 마지막 문장에 동의합니다. 우리가 올바른 축을 가진 보스턴 매트릭스(Boston Square)를 그렸다면 (그리고 두 개 이상의 축이 필요할 수도 있고, 각 축의 분할이 필요할 수도 있으므로 27개의 하위 큐브로 이루어진 보스턴 큐브가 될 수도 있습니다¡!) 우리는 당신의 가정과 단어 선택이 완벽하게 하나의 사분면(27분의 1)에 들어맞지만 나머지 세 사분면에는 들어맞지 않음을 볼 수 있을 것입니다.

그러므로

> [@Ed\_S](#):
>
> 스레드가 지수적으로 확장되기 시작할 때 회원들과 모더레이터가 어떻게 반응할 수 있는가.

최소한 다른 하나의 사분면에 대한 그 답은 “물러나라” 또는 "나중에 다시 확인하라"라고 생각합니다. 아마도 우리가 읽을 마지막 "n"개의 게시물을 읽을 때, 우리는 이제 **모든** 것이 서로 관련되어 있음을 볼 수 있을 것입니다… 우리는 더 집중된 토론을 위한 주제를 그 안에서 증류해냅니다. 만약 그것들이 사후적으로만 감지될 수 있다면, 스레드를 떠나야 합니다. 왜냐하면 “can’t”, “don’t”, "not"은 그 특성에 대한 잘못된 단어이기 때문입니다.

나는 20년 전에 그린 그래픽과 함께 당신을 남겨두겠습니다. 이후 다른 사람들도 이를 유도해냈으며(나보다 더 잘 그려냈습니다! 그래서 저는 그들의 것을 사용합니다) 제 캡션은 "네가 네모라고 말하는 건 무슨 뜻이야? 분명히 원이야…"입니다.

 ![image_b94af30d-0e3f-49bc-852f-c4f28802123120220917_134036](https://global.discourse-cdn.com/meta/original/4X/6/2/8/6280339da120fcbab19977746fec40dfcf0620be.jpeg)

우리는 동시에 유효하고 겉보기에 모순적인 많은 관점을 가질 때만 현실에 대한 완전한 이해에 도달합니다. 그것은 우리가 아직 보이지 않는 무언가를 추구하고 있다는 것을 알려주며, 그것이 보일 때 그것은 돌파점이 될 수 있습니다.

---

<div class="post-metadata">

### Author: ![anon65426961](https://avatars.discourse-cdn.com/v4/letter/a/34f0e0/32.png) [@anon65426961](https://meta.discourse.org/u/anon65426961)
#### Post date: [9월 17, 2023, 5:41오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/9 "2023-09-17T17:41:08Z")

</div>

그 형상 다이어그램에 대한 비유가 좋습니다. 또한, 그 2차원 렌더링이 어떻게 보이는지는 빛의 원천 위치에 따라 달라진다는 점도 길조입니다.

---

<div class="post-metadata">

### Author: ![anon65426961](https://avatars.discourse-cdn.com/v4/letter/a/34f0e0/32.png) [@anon65426961](https://meta.discourse.org/u/anon65426961)
#### Post date: [9월 17, 2023, 7:53오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/10 "2023-09-17T19:53:10Z")

</div>

이 글은 오프토픽으로 분류되어 삭제될 수 있지만, 건축가들이 그런 용도로 사용하는 태양 궤도 다이어그램 몇 가지를 공유합니다:

 ![sun diagram](https://global.discourse-cdn.com/meta/original/4X/7/0/4/704fcbd39682dc6e3d6332dcee88a0bdd36c3c37.webp)

 ![solar-diagram-01](https://global.discourse-cdn.com/meta/original/4X/8/3/e/83e8e5fe509e6924dd8f25e191c4fa1d8211897d.jpeg)

---

<div class="post-metadata">

### Author: ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)
#### Post date: [9월 17, 2023, 8:58오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/11 "2023-09-17T20:58:45Z")

</div>

> [@packman](#):
>
> 나는 그 두 가지 모두 위험이 크다고 생각한다.
> 
> 응답할 수 있는 사용자의 수를 제한하면, 온라인에서 많은 시간을 보낼 수 있는 소란스러운 키보드 워리어들의 목소리만 듣게 되고, 온라인에서 제한된 시간만 보낼 수 있는 조용하지만 지식 있는 사람들의 목소리는 듣지 못하게 될 것이다.

아마도 그럴 것이다. 내 아이디어가 조금 이상하게 들릴 수 있다는 점은 인정한다. 하지만 Discourse에는 유사한 기능이 내장되어 있다. 그룹은 카테고리의 주제에 대해 어떻게 상호작용할 수 있는지에 대한 특정 권한을 부여받을 수 있다: 보기, 답장 보기, 답장 생성 보기. 이러한 그룹 멤버십은 시간이 지남에 따라 업데이트되어 일부 사용자 집단에 의해 답장이 지배되는 것을 방지하는 몇 가지 방법이 있다.

X/Twitter에는 사용자가 게시물별로 누가 자신의 게시물에 답장할 수 있는지를 제한할 수 있는 기능이 있다. 예를 들어, 답장을 최상위 게시물에서 언급된 사용자로 제한할 수 있다.

내가 하려는 핵심은 물리적 세계가 대화에 제한을 부과한다는 것이다. 조정되지 않는 현실 세계의 대화는 일반적으로 테이블 주위에 편안하게 앉을 수 있는 사람보다 많은 사람들이 참여하지 않는다. 사람들이 더 큰 모임, 예를 들어 파티에 모일 때, 사람들은 자연스럽게 더 작은 그룹으로 나뉜다. 또한 대화에는 시간 제한도 있다. 대화가 몇 시간 이상 지속되는 경우는 드물다.

> [@packman](#):
>
> 마찬가지로, 답장할 수 있는 수를 제한하면, 훌륭한 통찰력을 잃을 수 있다.

네, 그럴 수 있다. 스스로 임의로 제한을 두는 아이디어는 내게 조금 취미 같은 주제이다. 요즘 내가 YouTube에서 가장 좋아하는 것 중 하나는 두 명의 음악가가 노래를 작곡하고 녹음하는 데 1시간의 시간 제한을 스스로 부과하는 채널이다. 때로는 아이디어에 영감을 받아 제한을 깨는 것을 스스로 허용하기도 한다.

명확히 하지 않았지만, 나는 이러한 제한을 _모든_ 주제에 적용하라고 제안하는 것은 아니다.

Meta에서 사용되는 서브-주제의 폭발을 방지하는 또 다른 접근법은 30일 후 모든 답장을 삭제하는 주제 타이머를 설정하는 것이다. 이것은 문서 주제에 사용된다. 아이디어는 만약 게시물이 주제의 OP(최상위 게시물)에서 답변되지 않은 관련 질문을 묻는다면, 그 질문에 대한 답이 OP에 통합된다는 것이다. 이것은 수백 개의 답장과 여러 개의 하위 토론이 있는 문서 주제를 피하기 위해 구현되었다.

---

<div class="post-metadata">

### Author: ![anon65426961](https://avatars.discourse-cdn.com/v4/letter/a/34f0e0/32.png) [@anon65426961](https://meta.discourse.org/u/anon65426961)
#### Post date: [9월 17, 2023, 11:20오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/12 "2023-09-17T23:20:35Z")

</div>

> [@simon](#):
>
> 제가 하려는 핵심은 물리적 세계가 대화에 제한을 부과한다는 것입니다. 조절되지 않는 현실 세계의 대화는 대부분 테이블에 편안하게 앉을 수 있는 인원수를 넘지 않습니다. 사람들이 더 큰 규모로 모일 때, 예를 들어 파티에서라면, 사람들은 자연스럽게 더 작은 그룹으로 나뉩니다. 대화에는 시간적 제한도 있습니다. 대화가 몇 시간을 넘기는 경우는 드뭅니다.

이것은 고려할 가치가 있으며, 사람들이 직접 얼굴을 맞대고 볼 수 없는 경우 온라인 커뮤니티가 줌(Zoom) 또는 다른 플랫폼을 통해 정기적인 회의를 갖는 데 매우 도움이 될 수 있습니다.

포럼은 커뮤니티를 관리하는 데 유용할 수 있지만, 글, 게시물, 이모지만으로는 사람들이 같은 의견을 가지고 있는지 파악하기가 어려울 수 있습니다.

때로는 사람들이 어떤 형태의 회의에도 관심이 없는 경우가 있으며, 서로 다른 시간대에 걸쳐 이러한 회의를 조직하는 것은 어려울 수 있습니다. 다른 방법으로는, 사람들이 글로 남긴 질문에 답변하는 질문-답변(Q&A) 콜을 진행하는 것입니다. 이를 라이브 스트리밍 또는 녹화할 수 있는 영상 프레젠테이션을 통해 수행할 수 있습니다.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [9월 18, 2023, 5:24오전 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/13 "2023-09-18T05:24:48Z")

</div>

> [@simon](#):
>
> 물리적 세계는 대화에 제약을 부과합니다.

저는 이 관찰에 대해 전적으로 공감하며, 이를 온라인에서 어떻게 적용할지에 대한 방법도 고심하고 있습니다 — 말씀하신 대로, 선택적으로요.

여기서 핵심은 모든 대화가 가능한 모든 주제를 다뤄야 한다는 것은 아니라는 점입니다. 대화는 무언가에 대해 이야기하는 것입니다.

Discourse를 포함한 대부분의 포럼 소프트웨어에서 새로운 스레드(또는 주제)를 만드는 것은 매우 비용이 적게 듭니다. 주제에는 제목, 카테고리, 그리고 헤드 포스트가 있으며, 이들은 모두 대화를 프레임업하는 역할을 합니다. 우리가 가지고 있는 전술 중 하나인데, 저의 생각에 이는 충분히 활용되지 못하고 있습니다. 바로 새로운 아이디어에 대해 새로운 주제를 분기(spun off)하는 것입니다.

---

<div class="post-metadata">

### Author: ![Heliosurge](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/heliosurge/32/571810_2.png) [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [9월 18, 2023, 7:07오전 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/14 "2023-09-18T07:07:13Z")

</div>

> [@Ed\_S](#):
>
> > [@simon](#):
> >
> > 물리적 세계는 대화에 제한을 가합니다.
> 
> 이 관찰에 대해 저도 깊이 공감하며, 이를 온라인에 어떻게 적용할지에 대한 생각에도 동의합니다. 말씀하신 대로 선택적으로 말이죠.
> 
> 여기서 핵심적인 점은 모든 대화가 가능한 모든 주제를 다루어야 한다는 것은 아닙니다. 대화에는 반드시 특정 주제나 목적이 있습니다.

이 모든 내용은 타당한 지적입니다. 다만 철학에 대한 논의에서는 모든 관점(pov)이 항상 유효합니다.

@simon 님이 추가로 확장한 내용을 제외하고, OP(첫 글)의 초기 진술은 하나의 측면에서 작은 요소만을 다루고 있을 뿐입니다.

수년간의 저항 끝에 Discourse 플랫폼이 게시글에 대한 스레드형 응답 보기 옵션을 추가했습니다(커뮤니티의 지속적인 노력이 결국 필요한 변화를 이끌어낼 것입니다). 이는 Simon 님이 제시한 문제를 해결하는 데 도움이 될 수 있습니다.

주제와 무관하게, 참여자가 대량으로 늘어나면 서로 다른 분기를 탐색하는 사람들을 따라가기 어렵다는 점은 충분히 사실입니다.

특정 주제 안에서도 사람들은 종종 모여서 특정 요소를 함께 탐색합니다.

---

<div class="post-metadata">

### Author: ![Heliosurge](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/heliosurge/32/571810_2.png) [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [9월 18, 2023, 7:15오전 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/15 "2023-09-18T07:15:59Z")

</div>

> [@Ed\_S](#):
>
> 디스커스를 포함한 대부분의 포럼 소프트웨어에서는 새로운 스레드(즉, 토픽)를 만드는 데 비용이 거의 들지 않습니다. 토픽에는 제목, 카테고리, 그리고 첫 번째 게시글(OP)이 있으며, 이들은 모두 대화를 위한 틀을 제공합니다. 우리가 가지고 있지만 충분히 활용되지 않는 전략 중 하나는 새로운 아이디어에 대해 새로운 토픽을 분기(spin off)하는 것입니다.

이것이 바로 광범위한 브레인스토밍 토픽이 가이드라인과 함께 잘 작동할 수 있는 이유이며, 사람들이 토픽을 관리하는 법을 교육하고, SoG(주제 제안)와 SoP(표준 운영 절차)를 통해 새로운 하위 토픽을 생성하도록 장려하면 더욱 효과적입니다.

새로운 토픽 분기? 링크가 포함된 게시글을 예를 들어 'Staff Notice(스태프 공지)'로 강조할 수 있습니다… OP 게시글을 수정하여 특정 요소를 논의할 장소를 명시할 수 있습니다… 등등…

중요한 것은 장벽을 제거하는 것이지, 장벽을 부과하는 것이 아닙니다.

@simon 님은 30일 리셋 답변 토픽에 대해 언급했습니다. ‘무제한(Free for all)’ 목적의 리셋 카테고리도 잘 작동할 수 있습니다. 아이디어를 구체화하기 위해 토픽을 시작합니다. 30일이 끝나기 직전에 핵심 포인트를 복사하고, OP 게시글을 수정하여 새로운 30일 브레인스토밍을 시작합니다. 단지 하나의 아이디어일 뿐입니다.

* * *

이것이 생각나는데, 기억이 정확하지는 않지만 얼마 전 토픽 스레딩의 일종을 추가하는 플러그인이 있었던 것 같습니다. 찾아볼 수 있는지 확인해 보겠습니다. 😉

> [@Discourse 체인 토픽 플러그인](https://meta.discourse.org/t/discourse-chain-topics-plugin/233088?u=heliosurge):
>
> I have just released a discourse plugin for chaining topics When I was going over [Developing Discourse Plugins - Part 1 - Create a basic plugin](https://meta.discourse.org/t/beginners-guide-to-creating-discourse-plugins-part-1-creating-a-basic-plugin/30515) the guide is splitted into 7 parts. I thought why not creating a plugin for this use case; where you have topics in a chain. By using this plugin you could add “Next Topic” and “Previous Topic” links on the topic title. See screenshot below for example how it would look: For more details and install: [GitHub - zaatdev/discourse-chain-topics…](https://github.com/zaatdev/discourse-chain-topics)

---

<div class="post-metadata">

### Author: ![51mon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/51mon/32/299702_2.png) [@51mon](https://meta.discourse.org/u/51mon)
#### Post date: [9월 18, 2023, 1:02오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/16 "2023-09-18T13:02:12Z")

</div>

> [@Ed\_S](#):
>
> 디스코urs를 포함해서 새로운 스레드, 즉 토픽을 만드는 것은 매우 저렴합니다.

하지만 실제로는 저렴하지 않아요 ☹ !!

이 스레드가 존재하게 된 역사를 통해 입증되듯, 그 비용은 기술적 편의성과 바람직함을 인정하지 않는 벤치마크나 가이드라인에 대한 조정(모더레이션)에 있습니다. 모든 쪽에서 선의의 노력이 많이 쓰였는데 ☹ 그래서 [이 제안](https://meta.discourse.org/t/please-create-a-group-or/279379?u=51mon)이 나온 것입니다.

@Heliosurge - 당신이 제안하는 것은 가치 있고, 이미 기술적으로 가능하다고 생각합니다… 하지만 이것이 커뮤니티 전체의 관점 변화라는 문화적 전환을 요구하지 않나요? 그렇다면 실현 가능한가요? 어떤 시간 규모로, 어떤 노력과 어떤 예비 단계(예: 그룹 또는 그룹들 생성)가 필요합니까? 🙂

---

<div class="post-metadata">

### Author: ![mbauman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mbauman/32/139835_2.png) [@mbauman](https://meta.discourse.org/u/mbauman)
#### Post date: [9월 18, 2023, 3:41오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/17 "2023-09-18T15:41:23Z")

</div>

우리는 exploding threads(폭발적으로 커지는 스레드)를 관리하는 데 정기적으로 어려움을 겪고 있습니다.

이 문제를 해결하는 데 도움이 될 것이라고 생각하는 두 가지 구체적인 기능 아이디어는 다음과 같습니다:

- [A softer slow mode: slow bumps?](https://meta.discourse.org/t/a-softer-slow-mode-slow-bumps/200080)
- [Duplicate post when splitting](https://meta.discourse.org/t/duplicate-post-when-splitting/127710)

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [9월 18, 2023, 3:49오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/18 "2023-09-18T15:49:58Z")

</div>

누군가 두세 가지 아이디어를 답글로 남긴 지점에서 스레드를 분리하는 것은 현재 거의 불가능에 가깝습니다. 다른 관점들을 정밀하게 분리해낼 수 있는 복제 및 분리 기능은 매우 마음에 듭니다.

자기 게시글이 편집되는 것을 싫어하는 사람들이 있습니다. 만약 그들이 하나의 답글에 다양한 아이디어를 혼합하지 않는 법을 배울 수 있다면, 좀 더 만족스러워질지도 모릅니다.

---

<div class="post-metadata">

### Author: ![mbauman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mbauman/32/139835_2.png) [@mbauman](https://meta.discourse.org/u/mbauman)
#### Post date: [9월 18, 2023, 3:54오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/19 "2023-09-18T15:54:09Z")

</div>

> [@Ed\_S](#):
>
> 복제 및 분할이라는 아이디어를 매우 좋아합니다. 서로 다른 관점들을 정교하게 해체하는 듯한 섬세한 수술처럼 말이죠.

물론 분할 작업은 _이미_ 매우 노동 집약적이므로 이것도 완벽하지는 않습니다. 또한, 제 계정과 제 목소리로 \_요약\_하고, 혼합된 잡동사니나 기타 문제적인 게시물들을 선택적으로 인용하여 새로운 게시물을 생성하기도 했습니다. 이렇게 하면 토론에 참여하는 대부분의 사람들에게 문제가 되지 않는 방식으로, 그 새로운 게시물을 답글의 대상으로 사용할 수 있습니다. 결과적으로 시작 게시물이 답글보다 "더 최신"이 되지만, 이는 이해할 수 있는 일입니다… 경우에 따라서는 원래의 주제를 닫을 수도 있습니다. 하지만 여전히 매우 많은 노력이 필요합니다.

여기서의 또 다른 전략은 물론 기대치와 규범을 설정하는 것입니다. 주제에 맞는 게시물이 무엇인지에 대한 명확하고 간결한 규칙은 absolutely 필수적이며, "하지만 나의 표현의 자유"라는 식의 난동을 완전히 우회할 수 있습니다.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [9월 18, 2023, 3:55오후 UTC](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257/20 "2023-09-18T15:55:14Z")

</div>

또 다른 독립적인 잠재적 문제가 있다고 생각합니다. 각 포럼에는 고유한 문화가 있는데, 사용자가 그것을 파악하고 적응하지 못하면 계속 불만이나 모더레이션(관리)에 부딪히게 될 수 있습니다. 어떤 포럼은 폭발적으로 길어지는 스레드를 환영하는 반면, 다른 포럼은 단일 주제에 집중된 게시물을 선호할 수 있습니다. 어떤 곳에서는 에세이 길이의 긴 글을 좋아하고, 다른 곳에서는 간결한 한 가지 포인트를 담은 짧은 글을 선호할 수도 있습니다.

[다음 페이지](https://meta.discourse.org/t/how-to-avoid-an-explosion-of-sub-topics-in-a-topic/279257.md?page=2)
