[RFC] Discourse용 네이티브 데이터 출처 및 사실 매핑

디스커스 커뮤니티 여러분,

안녕하세요. 저는 시스템 디자이너로, 현재 디스커스 생태계를 탐구하고 있습니다. 아직 디스커스의 내부 아키텍처에 대한 전문가라고 할 수는 없지만, 저는 다가오는 프로젝트를 위해 이 플랫폼을 선택했습니다. 그 이유는 강력한 데이터 모델, 확장성, 그리고 커뮤니티 주도 거버넌스 때문입니다.

저는 현재 개발 승인을 위해 상사에게 제출할 제안서를 준비하고 있습니다. 여기에서 공유하는 목적은 디스커스를 가장 잘 아는 분들의 피드백, 통찰력, 그리고 건설적인 비판을 수집하는 것입니다. 특히 실현 가능성, 핵심 기능과의 중복, 그리고 디스커스 모범 사례와의 정합성에 대한 의견을 듣고 싶습니다.

참고: 아래 제안서는 상당히 상세하고 기술적입니다.
즉시 답변을 드리지 못할 수 있지만, 가능한 한 빨리 모든 댓글을 읽고 응답하겠습니다.


평이한 개요 (간단한 배경)

문제:
많은 커뮤니티 토론 — 특히 뉴스, 공공 정책, 과학, 또는 논쟁적인 주제에 관한 토론에서는 — 주장이 시간이 지남에 따라 자주 도전, 수정, 또는 정교화됩니다. 디스커스가 토론에서 강점을 보이지만, 다음 사항을 명확하게 파악하는 것은 여전히 어렵습니다:

  • 주장이 처음 어디에서 나왔는지,
  • 답글과 인용을 통해 어떻게 발전했는지,
  • 어떤 게시물이 그 주장을 지지, 수정, 또는 반박하는지,
  • 토론이 커짐에 따라 해당 주장에 대한 신뢰도가 어떻게 변하는지.

아이디어:
이 프로젝트는 토론 스레드를 투명한 증거 그래프로 전환하는 플러그인을 탐구하며, 단일 권위나 이진적 “참/거짓” 라벨에 의존하지 않고 커뮤니티가 집단적 팩트체킹을 수행할 수 있도록 돕습니다.

이 시스템은 사실을 선언하는 대신 추적 가능성, 구조, 그리고 신호에 초점을 맞춥니다 — 독자와 관리자가 커뮤니티 내에서 정보가 어떻게 출처를 찾고, 도전받고, 검증되는지에 기반하여 신뢰도를 판단할 수 있도록 합니다.

누가 혜택을 받을 수 있을까요:

  • 관리자 및 관리자(admin):
    • 공정하고 증거 기반의 관리 결정 지원
    • 수정, 분쟁, 불안정한 주장을 더 빠르게 식별
  • 팩트체커 및 연구자:
    • 토론 내부에서 주장의 계보와 검증 경로 추적
  • 커뮤니티 멤버:
    • 더 명확한 맥락과 공유된 참조를 통해 토론에 참여
  • 독자:
    • 모든 답글을 읽지 않고도 그 주장이 신뢰되거나 분쟁의 대상이 되는지 이해

[팩토 맵 (Facto Map)]

이것은 그래프가 실제로 어떻게 보일지 상상하는 예시입니다.

이것은 전문적인 사용 사례답글이 압도적으로 많은 주제를 위해 의도되었습니다. 이러한 경우 모든 논거를 수동으로 추적, 검증, 이해하는 것은 비현실적이 됩니다.

팩토 맵은 주장, 증거, 모순, 검증 경로를 시각화하여 커뮤니티가 맥락을 잃지 않고 팩트체킹, 신뢰도 평가, 구조화된 토론을 수행하기 쉽게 돕습니다.

아래는 아키텍처와 실현 가능성에 초점을 맞춘 기술 명세 / RFC 스타일 제안서입니다.


기술 명세

프로젝트 제목: 디스커스 오리지인그래프 & 팩토-매퍼 (Discourse OriginGraph & Facto-Mapper)
부제: 네이티브 데이터 출처 추적 및 신뢰성 분석 시스템
버전: 1.0.0 (제안서)


1. 경영 요약 (Executive Summary)

빠른 정보 확산의 시대, 디스커스 같은 토론 플랫폼은 구조화된 논증에서 강점을 보이지만 데이터 출처 분석, 주장 진화 추적, 투명한 팩트체킹 워크플로를 위한 네이티브 도구가 부족합니다.

디스커스 오리지인그래프 & 팩토-매퍼는 디스커스에 커뮤니티 주도 팩트 매핑 레이어를 추가하기 위해 설계된 플러그인입니다. 절대적 진실을 강제하는 대신, 이 시스템은 구조화된 토론을 통해 커뮤니티가 주장을 입증, 도전, 그리고 맥락화할 수 있도록 돕는 시각적 및 통계적 도구를 제공합니다.

이 시스템은 다음을 강조합니다:

  • 권위보다 추적 가능성,
  • 판정보다 신뢰 신호,
  • 중앙 집중식 판단보다 집단적 추론.

2. 기술적 목표

  • 추적 가능성:
    출처 → 확장 → 검증 → 수정을 위한 방향성 비순환 그래프(DAG)

  • 팩트체킹 지원:
    콘텐츠를 참 또는 거짓으로 라벨링하지 않고 주장, 반박, 수정에 대한 구조적 증거 제공

  • 시각화:
    토픽 뷰에 직접 내장된 인터랙티브 “팩토 맵”

  • 휴리스틱 분석:
    토론 구조와 검증 패턴에서 파생된 가중 신뢰 기반 점수화

  • 성능:
    Sidekiq를 통한 비동기 처리

  • 통합:
    디스커스 플러그인 아키텍처(Rails / Ember.js)에 대한 엄격한 준수


3. 작업 범위

3.1 포함 범위

  • 토픽 내 관계 그래핑 (답글, 인용, 언급, 수정, 모순)
  • cooked HTML 및 답글 메타데이터에서 신호 추출
  • 구성 가능한 출처/안정성/분쟁 점수
  • 디스커스 신뢰 레벨(Trust Levels)을 통한 거버넌스
  • 관리자 전용 팩트체킹 신호 (권위적이지 않음)

3.2 제외 범위

  • 자동 진실 분류 (참/거짓 라벨 없음)
  • NLP / LLM 의미 분석 (1단계)
  • 글로벌 검색 대체
  • 인스턴스 간 연동

4. 시스템 아키텍처

4.1 기술 스택

  • 백엔드: Ruby on Rails (디스커스 코어), Sidekiq
  • 프론트엔드: Ember.js, D3.js 또는 Cytoscape.js
  • 데이터베이스: PostgreSQL 13+, Redis
  • 데이터 교환: 내부 JSON API

4.2 개념적 아키텍처 다이어그램

[클라이언트: Ember.js]  <-- JSON -->  [컨트롤러: Rails]
       |                                  |
(인터랙티브 팩토 맵)             (요청 검증)
       |                                  |
       v                                  v
[시각화 라이브러리]                [Sidekiq 워커 풀]
                                          |
                                 +--------+--------+
                                 |                 |
                          [그래프 엔진]         [점수화 엔진]
                                 |                 |
                                 +--------+--------+
                                          |
                                    [PostgreSQL]
                           (엣지 / 스냅샷 / 로그)

5. 데이터 모델 (스키마 설계)

5.1 테이블: provenance_edges

컬럼 타입 인덱스 설명
id BigInt PK 고유 엣지 ID
topic_id Integer IDX 토픽 참조
source_post_id Integer IDX 시작 노드
target_post_id Integer IDX 도착 노드
relation_type Enum reply, quote, ref, correction, contradiction
weight Float 엣지 강도
metadata JSONB 컨텍스트 데이터

5.2 테이블: facto_graph_snapshots

컬럼 타입 인덱스 설명
id BigInt PK 스냅샷 ID
topic_id Integer UNIQUE 관련 토픽
version Integer 그래프 버전
graph_payload JSONB 노드 및 엣지
computed_at Datetime 생성 시간
is_public Boolean 가시성 플래그

5.3 Redis 키

  • facto:quota:user:{id}:daily
  • facto:job:topic:{id}:status

6. 내부 API 명세

POST /facto/analyze

  • 인증: TL1+
  • 매개변수: topic_id, force_recalc
  • 응답: job_id, status = queued

GET /facto/graph/:topic_id

version: 5
nodes:
  - id: 101
    group: source
    score: 0.8
edges:
  - source: 101
    target: 105
    type: verification

7. 알고리즘 및 로직

7.1 신호 추출 로직

  • 토픽 내 모든 게시물 반복
  • reply_to_post_number → 답글 엣지
  • cooked HTML 파싱 → 인용 엣지
  • 정규식 @username → 언급 엣지
  • 관리자 주석 → 수정 / 모순 엣지

7.2 점수화 알고리즘

가중 중심성 (PageRank 스타일):

Score(P) = (1 - d) + d × Σ((Score(Pi) × Weight(Ei,P)) / OutDegree(Pi))

부정적이거나 모순되는 엣지는 이진적 거부 대신 패널티 승수(가중치)를 적용합니다.


8. UX / UI

  • 진입점: 토픽 맵의 “그래프 보기” 버튼
  • 전체 화면 모달 팩토 맵
  • 노드 호버: 게시물 스니펫 + 저자 + 신뢰 신호
  • 노드 클릭: 게시물로 스크롤
  • 필터: 수정, 모순 표시/숨기기 또는 검증된 경로만 표시

9. 보안 및 거버넌스

  • 디스커스 RateLimiter를 통한 속도 제한
  • XSS 방지를 위한 JSONB 세리피케이션(정화)
  • 비공개 토픽은 디스커스 ACL을 상속
  • 자동화된 관리 조치 없음 — 신호는 조언 목적만

10. 개발 로드맵

  • 1단계: MVP 그래프 추출 + 기본 시각화
  • 2단계: 고급 신뢰 점수화 + 관리자 주석
  • 3단계: 외부 팩트체킹 API 및 연구용 내보내기
2개의 좋아요

안녕하세요 @Thefacto - 이 프로젝트를 시작하셨나요? 혹은 제작하셨나요?
"provenance"라는 단어로 검색해 보았는데, Discourse가 C2PA 또는 유사한 기술에 대해 무엇을 제공하고 있는지(제공할 수 있는지/하고 있는지) 알아보고 싶기 때문입니다.

여기서 (사실 지도에 초점을 맞추고 있지만) 부분적으로 구축해 두셨을 수 있는 중요한 측면은 다음과 같습니다…

  • 매니페스트 생성
  • 그 후의 암호화 서명
  • 어떤 형태의 임베딩/워터마킹
  • 그리고 배포(에셋과 함께)
  • 마지막으로 검증을 위한 표시

여기서 무엇을 구축하려는 건지 아직 완전히 파악하지 못했을 수도 있습니다. 하지만 "콘텐츠 출처(content provenance)"라는 주제는 최우선 과제입니다.

OP가 이 논문을 살펴보고 생각을 공유해 주실지 궁금합니다.

https://www.sciencedirect.com/science/article/pii/S0749597825000172

OP의 주제와 너무 관련이 적다고 생각되신다면, 새 게시물로 옮기겠습니다.
감사합니다.

1개의 좋아요