복잡한 주제 토론을 위한 도구, CQ2

• 복잡하고 긴 토론은 대면·채팅·포럼 어디서든 충동적 응답과 구조 부족 때문에 흐름이 쉽게 무너짐
• Discourse는 댓글이 시간순으로 쌓여 위치 맥락을 잃기 쉽고, Slack은 한 단계 스레드만 지원해 깊은 논의를 담기 어려움
• 인용으로 답변 관계를 이어가는 방식은 참여자가 늘수록 토론 구조를 머릿속으로 추적하게 만들어 quote hell로 이어짐
• CQ2는 특정 인용문이나 댓글 전체를 기준으로 스레드 안에 스레드를 만들고, 관련 답변과 상위 맥락을 한 화면에서 확인하게 함
• 아직 초기 단계의 무료 오픈소스 도구이며, 모바일 최적화 전이라 데스크톱이나 노트북에서 써보는 것이 현실적임

---

복잡한 토론이 어려워지는 지점

• 직장의 전략 논의, AI alignment, 기술 설계 문서, 공공정책처럼 긴 맥락이 필요한 주제에서 문제가 두드러짐
• 반복되는 병목은 충동적 응답과 구조 부족임
• 대면 토론은 즉각 반응을 유도하고 논의 구조를 유지하기 어려워, 복잡한 주제를 깊게 다루는 데 한계가 있음
• 적극적 경청이 이상적 해법이 될 수는 있지만, 모든 팀과 상황에서 항상 작동한다고 보기 어려움
• 글 기반 비동기 토론은 반응 속도를 늦출 수 있고, slow mode 같은 기능이 있으면 더 신중한 응답을 유도할 수 있음
• 다만 비동기 토론도 구조가 부족하면 긴 논의를 따라가기 어려운 문제는 그대로 남음

Slack과 Discourse의 구조적 한계

• Discourse의 토론은 정리되지 않은 댓글 스트림처럼 이어짐
  • 여러 사람이 겹쳐 말하고 주제가 섞이는 방식은 복잡하고 긴 주제를 깊게 파고드는 데 맞지 않음
  • 댓글이 시간순으로 정렬되어, 토론 안에서 “어디에 있는지”보다 “언제 올라왔는지”가 더 잘 드러남
  • 특정 댓글의 답글을 한곳에서 볼 수는 있지만, 그 답글에 다시 달린 답글을 보려면 다른 댓글 사이를 스크롤해야 함
• Slack은 글 기반 비동기 토론을 위해 만들어진 도구는 아니지만 널리 쓰임
  • 특정 댓글을 별도 패널의 스레드에서 논의할 수 있음
  • 스레드 안의 댓글을 다시 별도 스레드로 만들 수 없어, 한 단계 스레드에 논의가 갇힘
  • UI는 긴 비동기 토론보다 짧고 빠른 댓글 묶음을 보내는 쪽에 가깝게 느껴짐
  • typing indicator는 한 사람이 생각을 정리하는 동안 다른 사람의 주의를 분산시킬 수 있음

인용이 구조를 대신하는 quote hell

• 채팅·포럼 도구에서 공통으로 나타나는 문제는 quote hell임
• 전형적인 흐름은 단순함
  • Ava가 어떤 주제에 대해 댓글을 남김
  • Caleb이 Ava의 댓글 중 일부를 인용해 답변함
  • Ava가 다시 Caleb의 답변을 인용해 답변함
• 이런 방식에서는 한 주제에 대한 답변이 여러 댓글에 흩어지고, 사용자가 인용과 답변 관계를 직접 추적해야 함
• 중간에 관련 없는 댓글까지 끼어들면 토론 흐름이 쉽게 끊김
• 2명 사이의 토론에서는 크게 드러나지 않을 수 있지만, 5명 이상이 참여하는 길고 복잡한 토론에서는 혼란이 빠르게 커짐

CQ2가 제안하는 토론 구조

• CQ2는 복잡한 토론을 위해 만든 무료 오픈소스 도구이며 아직 초기 단계임
• LessWrong의 작은 토론을 CQ2에서 시뮬레이션한 결과, 더 잘 정리되고 따라가기 쉬웠음
• 핵심은 스레드 안에 다시 스레드를 만드는 구조임
  • 각 스레드가 하나의 주제에 머물도록 돕음
  • 특정 인용문을 중심으로 새 스레드를 만들고 관련 답변을 한곳에서 볼 수 있음
  • 현재 스레드의 모든 상위 스레드를 같은 화면에서 볼 수 있어 위치 맥락을 잃지 않음
  • CQ2의 tree를 통해 읽지 않은 댓글이 있는 스레드, 결론이 난 스레드, 특정 스레드로 빠르게 이동할 수 있음
  • 해결된 스레드와 전체 토론에 결론을 추가할 수 있음

사용 흐름과 예정 기능

• 토론을 시작할 때는 제목과 설명을 입력함
  • 설명은 짧거나 길 수 있고, 토론 시작 전 맥락·필요 정보·생각을 제공하는 데 쓰임
  • 이후 참가자에게 링크를 공유함
• 일반 댓글은 첫 번째이자 가장 왼쪽에 있는 main thread에 작성함
• 특정 텍스트에 답하려면 설명이나 댓글에서 텍스트를 선택하고 “Reply in new thread” 버튼으로 해당 인용문 중심의 새 스레드를 만듦
• 댓글 전체에 답하려면 댓글 오른쪽 위의 reply 버튼을 사용할 수 있음
• 이미 특정 인용문에 대한 스레드가 있으면 인용문이 강조 표시되고, 클릭해 해당 스레드를 열어 이어서 논의할 수 있음
• 댓글 전체에 대한 스레드가 있으면 댓글 오른쪽 위의 comments 버튼이 강조 표시되며, 클릭하면 해당 스레드를 열 수 있음
• 스레드 이동은 trackpad 스크롤이나 shift 키와 마우스 휠로 할 수 있음
• 내비게이션 바의 tree는 특정 스레드로 빠르게 이동하게 하며, 스레드별 댓글 수·읽지 않은 댓글 수·결론 여부를 보여줌
• “Conclude thread” 버튼으로 스레드를 마무리할 수 있고, 결론이 난 스레드는 녹색 배지와 녹색 결론 댓글을 표시함
• 전체 토론은 내비게이션 바의 “Conclude discussion” 버튼으로 마무리함
• 예정 기능에는 서식 있는 텍스트(rich text), workspaces, thread custom title, mentions, slow mode, 유용한 reactions, 토론에서 놓친 부분을 찾도록 돕는 AI assistant가 포함됨
• CQ2는 아직 모바일 사용에 최적화되어 있지 않아, 데스크톱이나 노트북에서 사용해야 함
• Early access는 Tally 폼으로 받을 수 있음

[GN⁺]

Hacker News 의견들

• 복잡한 토론 도구는 사실 Usenet 뉴스리더에서 거의 해결됐다고 봄
  스레드 구조가 명확히 보였고, 한 화면에 게시글 50개 정도의 구조를 볼 수 있었으며, 읽지 않은 스레드와 글이 강조되고 Tab을 누르면 다음 미확인 글로 이동했음
  읽음 상태도 시간 기준이 아니라 글/댓글 단위였고, 빠른 탐색·필터링 등 편의 기능도 훨씬 많았음
  이후의 토론 플랫폼들은 사용 효율과 깊고 오래가는 토론 능력 면에서 대체로 후퇴했는데, 처음엔 웹브라우저 한계 때문이었고 나중엔 모바일 터치 인터페이스 때문이었다고 봄

  • 내가 겪은 Usenet과는 잘 연결되지 않음
    상단/하단 인용이 뒤섞이고, 스레드가 깨지고, 글이 누락돼서 사람들이 며칠씩 서로 엇갈려 말하는 일이 흔했음
    Usenet을 정말 좋아했고 내 커리어의 시작점이었지만 그립지는 않음
    게시, 중재, 정렬, 특정 사람 팔로우 같은 기본 기능 이전에, 주제 토론의 기초 체감은 오늘날 Usenet의 정당한 후계자인 Reddit보다 나빴음
  • Gmail이 이메일을 영원히 단순화해버리기 전에는 많은 이메일 클라이언트도 답장이 트리를 이룬다는 관점으로 볼 수 있었고, 지금도 일부는 가능할지도 모름
  • 맞음. Usenet 클라이언트 인터페이스에서 치명적인 문제를 꼽자면 스레드 간 연결 정도였을 듯함
    어느 순간 한 스레드는 다른 스레드의 병렬 논의 때문에 무의미해질 수 있고, 다른 스레드의 특정 지점으로 쉽게 유도할 수 있으면 큰 도움이 됨
    하지만 그러려면 URL이 필요했고, 메시지 ID는 그런 용도로 쓰이지 않았음
  • Zulip에는 이런 기능이 많이 있는 것 같음
    일화적으로는 고등학교나 대학 수준 수업의 온라인 토론 포럼을 운영하기에 꽤 좋아 보임
  • 그렇다면 왜 Usenet이 지금 대화의 주류 표준이 아니라고 생각하는지 궁금함

• 평판은 나쁘지만, 이런 토론에는 이미지보드식 댓글이 가장 낫다고 생각함
  각 글에는 고유 ID가 있고, 자기 글 안에 다른 글로 가는 링크를 넣을 수 있음
  그러면 각 글에는 자신을 인용한 모든 글을 보여주는 역링크가 붙고, 글들은 시간순으로 표시되면서도 비교적 쉽게 탐색 가능한 하이퍼링크 네트워크를 이룸
  긴 글 토론에는 꽤 효과적이었고, 다만 구조가 불필요하게 제한적이라는 점이 아쉬움
  글들이 단순히 연결 그래프를 이루고, 웹사이트가 그걸 임의의 방식으로 보여줄 수 있으면 더 좋겠음
  이 프로젝트의 배치는 Xanadu를 많이 떠올리게 하지만, 이렇게 복잡한 인터페이스가 꼭 필요하다고 보지는 않음
  오히려 생산적인 토론을 방해할 수도 있음
  글자 수 제한이나 답글 깊이 제한 같은 다른 매체의 제약이 명확성을 돕는 경우가 많고, 사람 사이의 정보 전달은 근본적으로 선형적이라 결국 짧은 에세이를 쓰고 교환하는 방식이 실제 토론의 기반이 되기 때문임

  • 기본을 개선하려는 시도가 많았지만, 하이퍼링크는 그 이후에 나온 거의 모든 것보다 정말 낫다고 봄
  • 여기서 핵심 사용자 경험은 링크된 댓글 위에 마우스를 올렸을 때 즉시 팝업으로 보이는 것이라고 생각함
    대부분의 사용자에게 가장 큰 장벽은 댓글 사이를 오가는 일이고, 상대가 무엇에 답하는지 확인하는 데 몇 초가 더 걸리는 것만으로도 흥미가 꺾일 수 있음
    실수로 엉뚱한 곳을 클릭하거나 뒤로 가기를 너무 많이 누르면 읽던 위치를 잃기도 쉬움
  • 이 방식의 단점은 정보 중복임
    여러 대화가 동시에 벌어지면 특정 대화에 대해 사람들이 무엇을 말하는지 따라가기 어려움
    스레드의 이력을 따라가려면 관련 없는 댓글을 걸러내고 중복 인용을 무시하는 인지 부하가 큼
    새 방식이라면 관심 없는 글은 한 번만 보게 됨
  • 회사 규모가 크든 작든, 로컬에서 돌리는 Reddit식 포럼은 큰 도움이 될 수 있음
    정리 작업을 사실상 하나의 형식으로 바꿔줌
  • 여기서 “이미지보드”가 4chan을 뜻하는지, 아니면 Reddit이나 HN 같은 것도 포함하는지 궁금함

• 내 생각엔 아직도 4chan식 선형 타임라인이 가장 좋음
  다만 > 참조를 따라가기 쉽게 만드는 강한 UI 지원이 필요함
  이 앱과 HN, Reddit은 “스레드 안의 스레드 안의 스레드” 트리를 택하는데, 같은 부모 댓글의 여러 답글 일부에 한꺼번에 응답하고 싶을 때는 매우 나쁨
  개선하려면 이 구조의 DAG 성격을 받아들이고, 댓글이 응답하는 부모 노드 집합을 직접 선택할 수 있어야 함
  더 중요하게는 그 집합을 수정 가능하게 만들어야 함
  다른 사람이 이미 논의된 주제로 새 댓글에 답했을 때 “여기 내 답글 봐”라는 댓글을 새로 달 필요 없이, 예전 답변을 새 부모에 연결할 수 있어야 함

  • 조용한 토론, 예컨대 전체 글이 30개 미만이면 가능할 수도 있음
    참여가 많은 토론에서는 서로 거의 관련 없는 하위 스레드들이 생기기 마련이고, 그런 경우 선형 구조는 형편없음
  • 4chanx 확장은 전체 시간순 상태를 유지하면서도 댓글을 체인으로 중첩해 스레드를 따라가기 쉽게 해줌
    답글 하나를 숨기면 그 답글에 달린 전체 답글 체인도 자동으로 숨길 수 있음
  • 좋은 생각이지만, 예전 댓글을 수정해 나중 댓글에 연결할 수 있게 하면 기술적으로는 더 이상 DAG가 아니게 됨
  • 여기서는 DAG가 자연스러워 보임
    LLM이 노드에 메타데이터를 추가하면 더 흥미로워질 수 있음
    예를 들어 A가 진술 Sa를 제시하고, B가 그에 대해 Sba로, C가 Sca로 응답한다고 하자
    새로 합류한 사람들은 Sba가 Sa의 대부분에는 동의하지만 특정 사실을 반박하고, Sca는 Sa의 어떤 내용에도 동의하지 않는다는 식으로 볼 수 있음
    또 많은 사람이 동의한 노드는 가중치가 커지고, 반대가 많으면 작아지는 식도 가능함
    구현과 파급효과는 사실상 무한함

• CQ2처럼 “스레드 안에 스레드를 만들어 각 스레드가 주제에서 벗어나지 않게 한다”는 방식이 되면 좋겠지만, 내 경험상 사람들에게 첫 번째 수준의 스레드 사용을 시키는 것조차 매우 어렵고 특히 비기술자에게 그렇다 봄
  복잡한 논의는 좋든 나쁘든 “짧게 통화해서 정리하자”로 흘러가는 경우가 대부분임
  커뮤니케이션 앱에서 가장 기대하는 기능은 머신러닝 모델이 그런 “짧은 통화”를 듣고 요약과 액션 아이템을 생성해 다시 스레드에 올려주는 것임
  그러면 양쪽의 장점을 모두 얻을 수 있음

  • 나도 첫 단계 스레드조차 쓰기 어렵다는 걸 자주 봤음
    왜 그런지 궁금함
    개인으로는 매우 똑똑하고 체계적인 사람과 일할 때도, 스레드가 등장하는 순간 구조화된 커뮤니케이션이 완전히 무너지는 경우가 많았음
    흥미롭게도 말로 할 때도 가끔 이런 일이 생김
    직장, 전화 기술지원, 예술가/작가와의 피드백 논의, 친구와의 대화에서 특정 하위 논점을 좁혀 끝까지 다룬 뒤 넘어가거나 큰 그림으로 돌아가는 방식을 싫어하는 사람들이 있음
    그 대신 여기저기 뛰거나, 가장 최근 관심 주제로 대화를 “chroot”하듯 가둠
    일화적으로는 “두 종류의 사람”에 가까운데 공통 요인은 모르겠음
    능력 부족이나 악의의 문제는 아니고, 그냥 트리나 스택으로 생각하지 않는 사람들 같음
  • 기술적으로는 끌리지만, 대부분의 사람은 특히 직장 맥락에서 사람 간 통화의 녹취나 기록을 원하지 않는다고 봄
    “AI 요약만” 목표로 해도 녹음이 필요하고 어딘가에는 전사가 남음
    삭제 약속을 신뢰할 수 있는지도 문제임
    자기검열, 선호와 지식의 왜곡이 떠오름
    프라이버시 기대가 없고 관찰받는다는 걸 알면 사람은 다르게 행동함
    고용상 불이익, 사회적 고립, 정신건강 영향 외에도, 판옵티콘식 환경은 사람들이 덜 충동적이고 더 순응적으로 행동하게 만들어 창의성과 혁신에 악영향을 줄 수 있음
    실무 경험상 로컬 전사도 상당한 연산 자원을 할당하지 않으면 즉각적이지 않은 경우가 많음
    요약이 통화 종료 후 한동안 나오지 않을 수 있고, AI 결과가 그럴듯한지/맞는지 확인하려면 머릿속에서 꽤 되짚어야 함
    경영진은 좋아하겠지만 나머지는 점점 싫어하게 될 듯함
    적어도 내게 사적인 개인 대화와 통화는 현대 원격 근무 환경에서 대인적 유대와 사회적 안도감의 마지막 보루임
  • “짧게 통화해서 정리하자”가 된다면, 그 문제는 커뮤니케이션이 아니라 의사결정에 가까움
    링크된 글에 나온 이유들 때문에 복잡한 주제는 “말로 정하자”로 끝나면 안 됨
    개인적으로는 지금도 중재가 있는 vBulletin/phpBB식 포럼이 장기 온라인 커뮤니케이션의 최고 형태라고 봄
    내가 보는 여러 포럼에는 수십 년 된 활성 토론 스레드도 있음
  • 맞음. 우리는 구조상 Slack 클론에 가까운 Google Chat을 쓰는데, 토론이 루트 수준에서 시작되고 몇 개 댓글 뒤 스레드로 갈라져도 일부 사용자는 이를 놓치고 계속 루트에 쓰며, 그 댓글은 관련 없는 내용과 섞임
    여러 스레드가 얽히면 더 나빠짐
    작년 말 Google Chat이 이 “스레드 기반” 공간/채널 방식을 강제하기 전에는 “주제 기반” 채널을 선택할 수 있었음
    모든 논의가 자체 스레드를 가졌고 루트 수준은 없었으며, 주제에 답글이 달리면 그 주제가 다시 위로 올라왔음
    소프트웨어 이슈별 주제, 지원 케이스별 주제 같은 용도에 좋았고, “각 주제는 이메일 체인 같다”고 설명할 수 있어서 비기술자도 이해하기 쉬웠음
    각 주제의 첫 댓글을 요약하는 습관도 생겼고, 그 첫 댓글은 항상 보이므로 이메일처럼 토론 목록을 훑을 수 있었음
    비기술자에게는 이메일에 비유할 수 있는 것이 가장 좋음
  • 부분적으로는 UX 문제임
    Slack과 Discord에서는 기본 동작이 맨 아래 큰 입력창과 전송 버튼으로 전체 채팅에 구조 없는 메시지를 보내는 것임
    답글로 별도 스레드를 만드는 옵션은 더 숨겨져 있음
    간단한 UX 재배치와 강조로 해결할 수 있음
    새 스레드 생성에는 제목을 요구하거나 입력창을 여는 버튼을 두는 식으로 조금 더 마찰을 줄 수도 있음

• 이건 Google Docs 댓글 시스템과 많이 비슷해 보이고, 각 옆 스레드를 하나씩 열려면 클릭이 많이 필요하다는 같은 문제가 있어 보임
  여러 답글을 한 번에 “다 읽었다”고 느끼기 어렵다
  나는 Discourse의 현재 선형 형식이 더 좋을 듯함
  새 답글이 전부 아래에 쌓이고, 이상적으로는 맥락을 위한 인용 일부가 있으면 됨
  그냥 문서처럼 스크롤하며 읽으면 되니 업데이트를 따라잡기 쉽기 때문임
  문서를 함께 작업하는 경우, 즉 변경사항을 추적하고 거기에 댓글을 다는 경우가 아니라면 각 댓글을 조각조각 훑는 건 별로 유용하지 않은 때가 많음
  여러 댓글을 한 번에 읽고 나서 전체에 대해 요약식으로 답하는 편이 모두의 시간을 아낄 수 있음
  긴 글 토론을 추적 불가능하게 만드는 건 사소한 포인트마다 끝없이 오가는 대화임
  그런 건 Slack이나 통화 같은 실시간 방식으로 처리한 뒤, 메인 대화에는 “4번 항목에 대해 Joe와 Jane과 이야기해 보니 blah blah를 쓰는 게 최선이라고 합의했다” 정도로 짧게 요약하는 편이 나음

  • 나도 첫인상은 Google Docs였음
    스레드 답글의 요약 트리는 Google Docs보다 개선될 가능성이 있어 보이지만, 기본 상호작용 흐름은 Google Docs와 같아 보임
    지난 몇 년간 제안된 웹페이지 주석 시스템 명세들을 살펴보면 더 혁신할 여지가 있을지도 모름
  • Google Docs에서는 댓글에 댓글을 달 수 없음

• “복잡하고 깊은 토론을 좋아한다”는데, 실제로 꽤 깊게 복잡해 보이니 깊고 복잡한 토론을 만들지 못할 이유는 없어 보임
  농담은 제쳐두고, 마음에 드는 점은 토론이 원문 텍스트의 특정 발췌문을 중심으로 시작된다는 것임
  즉 텍스트 일부를 선택해 스레드를 시작함
  HN에서 기사 인용으로 시작하지 않는 최상위 댓글은 늘 회의적으로 보게 되는데, 그런 경우 원문을 읽고 댓글을 단 건지 의심스러울 때가 많음
  하지만 이 방식은 텍스트 블록이 아닌 비디오, 이미지, 게임, 애플리케이션 등에 대한 대화를 어떻게 할지는 해결하지 못함
  그리고 이런 패턴에서 가장 어려운 UX 문제인 겹치는 발췌문도 해결하지 못함
  겹치는 발췌문을 같은 스레드로 볼지 새 스레드로 볼지, 경계를 어떻게 정의할지가 문제임

  • 새 답글이 부모 글의 특정 문장 하나가 아니라 전체 요지에 반응하거나 완전히 새로운 논거를 더하는 경우라면, 정확한 문장을 인용할 필요는 없음
  • 겹치는 발췌문이 같은 스레드인지 새 스레드인지, 경계를 어떻게 정할지는 아주 흥미롭고 아직 탐색 중임

• 집단 의사결정 연구를 바탕으로 만든 커스텀 플랫폼으로 그룹 토론을 지원하는 부서에서 일한 적이 있음
  그 플랫폼의 킬러 기능 중 하나는 익명성이었음
  보복을 두려워하거나 정치질로 몰리거나 군중을 따라간다는 부담 없이 댓글을 달고 투표할 수 있을 때, 그룹 토론에서 진실이 드러날 수 있었음
  cq2에서 모든 댓글에 이름이 붙는 걸 보면 불편한 아이디어를 가진 사람들은 올리기를 주저할 수 있겠다는 생각이 듦
  그래서 c2q식 추적이 어떤 종류의 질문에 적합할지 궁금함

  • 어느 지점에서는 완벽한 해결책이 없고, 익명성도 자체 문제가 있음
    묘사한 건 프레임워크보다 문화의 문제에 더 가까움
    사람들은 의심을 말한다고 보복을 두려워해서는 안 되고, 다행히 최근 고객사들이나 이전 직장은 그런 환경이 아니었음
  • 그 플랫폼 경험을 더 듣고 싶음
    공개된 플랫폼 정보나 연구가 있는지 궁금함
    트롤링 같은 익명성의 나쁜 행동은 어떻게 관리했는지도 알고 싶음
    나는 정치 시스템 개선을 희망하며 AI를 활용한 집단 의사결정 개선 관련 작은 연구 프로젝트를 살펴보는 중임
    실제 사례가 너무 적어서 이런 직관을 더 얻을 수 있으면 좋겠음
    DM이 편하면 Twitter에서 @dch임

• 시각 자료가 크게 빠져 있음
  텍스트 기반 토론은 독자마다 머릿속에 서로 다른 그림을 만들게 됨
  모두가 텍스트 설명에는 동의했는데 디자이너가 그림을 그리면 사실은 정렬되지 않았다는 게 드러나며 모두가 반대하는 일이 흔함
  비동기적으로 더 잘 토론하는 방식이라는 개념은 좋지만, 나는 이미지·비디오·다이어그램 같은 시각 자료를 포럼의 중심에 두고, 많은 사람이 만들기 어려워한다는 시각 자료의 가장 큰 문제를 극복하는 쪽을 택하겠음
  언급된 대안들은 모두 댓글을 특정 사용자에 묶고, 댓글을 다른 댓글의 응답으로 연결함
  대신 대화는 논의 주제에 초점을 맞출 수 있고, 그 주제는 종종 개념을 설명하는 시각 자료 집합으로 가장 잘 표현됨
  댓글에 응답하기보다, 시각적으로 표현된 문제의 구성요소를 중심으로 댓글을 구성할 수 있음
  그러면 특정 사용자의 댓글을 증폭하거나 비판하는 대신 여러 사람이 하나의 개념을 지지할 수 있음
  초점이 누군가의 댓글이 아니라 문제 자체에 놓이므로 방어적 태도도 줄일 수 있을지 모름

  • 이 생각에 정확히 공감함
    논의 중인 개념을 나타내는 구조를 만드는 것이 복잡한 이슈를 논의하고 이해를 개선하는 데 핵심이라고 봄
    내가 만들고 있는 도구[1]는 사람들이 그런 구조를 더 쉽게 만들고 다룰 수 있게 하려는 것임
    다만 문제 해결 맥락에 특히 초점을 맞추고 있고, 협업 사용에 중요한 기능은 아직 빠져 있음
    여기서는 댓글이 특히 관련 있는데 곧 추가될 예정임
    핵심 아이디어[2]는 앞의 내용과 맞닿아 보이지만, 이 도구는 질문·사실·출처 같은 보조 개념과 문제·원인·효과·트레이드오프·해결책 같은 주요 개념을 더 구분함
    [1] https://ameliorate.app/
    [2] https://ameliorate.app/docs/getting-started/core-ideas
  • 그룹이 무언가를 만들고 싶어 할 때는 맞음. 이미지가 도움이 됨
    하지만 그룹이 무언가를 만들게 하려면 텍스트만으로도 충분한 경우가 많음
  • 어쩌면 텍스트 댓글을 사용해 AI가 생성한 시각적 설명을 계속 업데이트하게 할 수 있을지도 모름
    그러면 아무도 직접 그림을 그릴 필요가 없음
    반대로 누구도 시각 자료를 직접 제어하지 못함
    사람들이 텍스트 박스에 댓글을 입력하면 그 댓글이 서버로 보내지고, 서버는 “아이디어를 설명하는 시각 자료”를 계속 업데이트하는 UI를 상상함
    각 클라이언트는 새 시각 자료로 UI를 갱신하고, 모든 댓글을 이미지·비디오·다이어그램에 붙이는 방법도 제공함
    즉 클라이언트 UI의 중심은 스크롤되는 댓글 목록이 아니라 AI 생성 시각 자료가 됨
    사용자는 논의의 다양한 구성요소로 파고들며 토론을 탐색할 수 있음
    AI 생성 요약도 있을 수 있음
    본질적으로 AI가 사이드 채널에서 그림을 그리는 디자이너와, 요약 추상을 계속 업데이트하는 똑똑한 비서 역할을 하는 셈임

• 서로 충분히 좋아해서 도움이 되려는 소규모 그룹이 직접 만나고, 오만할 만큼 선임인 사람은 빼야 함
  그러면 1년치 일을 한 달에 끝낼 수 있음

  • 꼭 직접 만날 필요는 없음
    서로 좋아하고 돕고 싶어 하는 작은 그룹이라면 오프라인이든 Slack이든 무엇이든 똑같이 작동함
    그걸 해결하는 기술적 해법은 없음

• 진지하게 궁금한데, HN/Old Reddit식 구조의 무엇이 문제인지 모르겠음
  내 경험상 유능한 중재자가 있으면 그 시스템은 만족스러운 토론을 만들어냄

  • 나도 같은 의문이 있음
    게다가 “복잡한” 토론이라면 참여자들이 비교적 작은 장벽에도 계속 참여하려 할 것이라는 전제가 있는데, 이 해법에는 그게 존재론적 도전처럼 보임
  • https://blog.codinghorror.com/web-discussions-flat-by-design...