📝 [Wiki] Gopedia → High-Efficiency Enterprise Knowledge Graph Platform

[lyckabc]

[Gopedia ] Official Wiki

KR: 이 페이지는 Gopedia의 비전, 기술적 방향성, 그리고 협업 방식을 정의하는 통합 문서입니다. 팀원과 외부 기여자들이 조화롭게 협업할 수 있도록 돕는 공식 가이드라인입니다.

EN: This page serves as the comprehensive documentation defining the vision, technical direction, and collaboration methods for Gopedia. It is an official guideline to ensure seamless collaboration between the team and external contributors.

프로젝트 소개 (KR)

1. 프로젝트 개요 (Project Overview)

Purpose (목적)

• Gopedia는 파편화된 정보를 지식 신경망으로 통합하는 Enterprise Knowledge Graph Platform(ingestion 및 RAG) 입니다.
• 단순한 저장소를 넘어, 관계 추론과 맥락 파악이 가능한 Enterprise Ontology의 근간을 제공합니다.
• Target: 분산된 데이터의 단일 진실 공급원(SSoT) 및 지식 추론 엔진.

Background / Introduction (배경·소개)

“데이터라는 토양에 지식의 뿌리를 내려, 유기적으로 연결된 지혜의 열매를 맺는다.”

Gopedia는 데이터를 “적재”하는 수준을 넘어, Root(플러거블 소스) → Stem(Phloem: Ingestion / Xylem: RAG) → Rhizome(저장·관계) → Leaf(인덱싱 뷰) · Fruit(리포트) 의 생명 주기에 맞춰 설계됩니다. GeneSo Design Standard(v1.3)의 관계 중심 원칙을 적용하며, 리좀(Rhizome) 메타포를 통해 수평·무한 확장 가능한 지식망을 지향합니다.

Core Values (핵심 가치)

메타포	의미	설명
Pluggable (Root)	입력의 유연성	뿌리. 외부 소스·연결(DB, API, 스트림)을 플러거블하게 정의
Scalable (Stem)	파이프라인 확장성	gRPC 기반 Phloem(Ingestion)·Xylem(RAG) 으로 데이터 실어나르기. Phloem: 소스→Rhizome 기록. Xylem: Rhizome→Leaf/사용자 검색·응답.
Relational (Rhizome)	저장·관계	TypeDB·Qdrant·PostgreSQL 등 폴리글랏 저장소와 관계 추론
View (Leaf)	인덱싱 뷰	도메인·프로젝트별로 인덱싱된 보기. Markdown, Code, Ticket 등 소스가 Rhizome에 적재된 뒤 xylem-flow로 끌어올려 보이는 형태
Actionable (Fruit)	가치 산출	여러 Leaf·Root 데이터를 조합한 리포트 템플릿·형식. Skill Engine·RAG 결과물 등 사용자가 소비하는 결실

해결하고자 하는 문제

1. 분산·비정형 데이터 통합: 여러 소스(Markdown, Code, Ticket, Meeting, ERP 등)에 흩어진 정보를 단일 진실 공급원(SSoT) 으로 모으고, Rhizome형 지식 신경망(관계·온톨로지)으로 정돈하기 위함.
2. 밀도 높은 조회·생성: 통합된 데이터를 L1/L2/L3 계층(요약 → ToC → 증거 청크)으로 구조화해, RAG 시 적은 토큰으로 원하는 문맥만 골라 조회·생성할 수 있게 함. (reference/gopedia-feature-guide.md §2 참조)

적용 가능한 대상 (도메인·조직)

• 범위: 모든 기업, 정부, 팀.
• 구체적 예:
  • 핀테크·규제 리포팅: 분산된 거래·규정 문서를 하나의 지식 그래프로 통합 후, 감사·리포트 생성 시 문맥만 선택해 토큰 비용 절감.
  • 대규모 인프라 운영: K8s 50노드 이상, 다수 서버 로그·설정을 Machine ID 기반으로 통합하고, “어느 서버·어느 구간”만 골라 RAG에 활용. (reference/gopedia-feature-guide.md §6, §11 Skill Engine·Hydration)
  • 개발·문서·이슈 통합: 코드 저장소, 위키, 티켓(Jira/Vikunja), 회의록을 Root(플러거블 소스)로 수집해 Phloem으로 Rhizome에 기록하고, 관계 추론(TypeDB)·계층 검색(Skill Engine, Xylem)으로 질의·요약·리포트 생성.

작동 방식 (요약)

• Root → Stem → Rhizome → Leaf · Fruit 생명 주기:
  • phloem-flow(Ingestion) — Root(소스)에서 수집한 원문을 Envelope로 포장해 gRPC로 전달하고, L1→L2→L3 계층으로 분해한 뒤 Smart Sink가 HierarchyLevel·SourceDomain에 따라 폴리글랏 저장소(PostgreSQL·TypeDB·Qdrant·ClickHouse)에 기록.
  • xylem-flow(RAG) — 사용자 질의 시 Rhizome(Qdrant/TypeDB 등)에서 L1·L2로 필터한 뒤 관련 L3 청크를 끌어와, Skill Engine으로 조합해 Leaf(인덱싱 뷰)·
    leaf, Rhizome 활용 사용자에게 응답·리포트(Fruit)로 제공. (universitas/gopedia/SKILL.md, reference/gopedia-feature-guide.md 참조)

완성도 및 PoC 가능 범위

• 기간·Target Date
  • Code Format(4.1.2): 4월 말까지 구현 완료 목표.
  • Ticket(4.1.3)·Meeting(4.1.4): 5월 말까지 구현 완료 목표.
  • 상세 target-day·마일스톤은 RoadMap/SKILL.md 참조.
• 필요 환경: gRPC/Protobuf, Red Panda(Kafka 호환), PostgreSQL·TypeDB·Qdrant·ClickHouse, SpiceDB(Connect 단계). 로컬/스테이징 검증 후 확장.
• 예상 결과물: Verify 단계별 “root → Stem → Rhizome 안착 → Leaf” 검증 스크립트·문서, Expand/Connect 단계에서 Skill Engine·권한 적용 PoC.

---

2. 팀 구성 (The Team)

Roles and responsibilities for the member team.

이름 (Name)	ID	역할 (Role)	SNS	주요 책임 (Responsibilities - KR/EN)
신동호	@lyckabc	Team Leader	Link	로드맵 및 최종 의사결정 / Roadmap & Final decision-making
박보민	@bmops0719	Core Infra	Link	인프라 아키텍처 리뷰 / Infra Architecture reviews
김준곤	@jgkim	Core Dev	Link	리뷰어 / reviewer

---

3. 기술 스택 (Tech Stack)

• 통신·계약: gRPC / Protobuf — 모든 Stem 통신의 공통 언어. Contract-First, Schema Registry(Red Panda)로 호환성 유지.

• Rhizome 저장소 (폴리글랏):

  • PostgreSQL: 마스터 메타·레코드·Machine 레지스트리(identity-so).
  • TypeDB: 그래프·온톨로지·관계(ontology-so).
  • Qdrant: 벡터·시맨틱 검색(L1/L2/L3 임베딩).
  • ClickHouse: 분석·BM25·원문 보존·감사.

• 권한: SpiceDB 기반 ReBAC(auth-so).

• 메시징: Red Panda(Kafka 호환)

• 언어·런타임: Go(gRPC·Stem 파이프라인), Python(Leaf 어댑터·스크립트 등). 다국어 스텁은 buf로 생성.

상세 기능(L1/L2/L3, Envelope, Smart Sink, Machine ID/Key 등)은 reference/gopedia-feature-guide.md 참조.

---

4. 로드맵 (Roadmap)

Gopedia는 Verify → Expand → Connect 세 단계로 진화합니다. 일정·target-day는 RoadMap/SKILL.md에서 관리합니다.

단계	의미	요약
Verify (발아)	최소 단위 검증	Root(소스) → Stem(Phloem) → Rhizome 안착 검증. 4.1.1 Markdown(2일), 4.1.2 Code(7일), 4.1.3 Ticket, 4.1.4 Meeting, 4.1.5 ERP 등.
Expand (생장)	용량·다소스 확장	Machine ID 분산(sharding-so), DB View 활성화, 다양한 소스 추가.
Connect (결실)	생태계 연동	GeneSo·MorphSo 등과 통합, RAG Fruit(Skill Engine), SpiceDB 권한 적용.

• 4.1.1 Markdown Origin 설계 target-day: 2026-03-08, 구현 완료: 2026-03-10.

• 4.1.2 Code Origin 구현 완료: 2026-03-18.

• 이후 4.1.3~4.1.5, Expand, Connect 일정은 RoadMap/SKILL.md 참조.

---

5. 참여 방법 (How to Contribute)

• 이메일 신청: lyckabc@gmail.com

• 설계 원칙·명명 규칙(Rhizome 관계, Root/Stem-Xylem·Phloem/Leaf/Rhizome/Fruit)은 universitas/gopedia/SKILL.md 및 geneso/references/geneso-design-standard.md를 따릅니다.

• Verify 단계 서브스킬·체크리스트는 skills/gopedia-verify-flow/ 및 README.md 참조.

---

6. 리소스 및 링크 (Resources & Links)

리소스	비고
GitHub - tojiuni/gopedia · GitHub	public docker compose file 공개
https://git.toji.homes/toji/gopedia	팀 오픈 예정
universitas/gopedia/SKILL.md	설계 원칙·구조·단계·서브스킬 라우팅
reference/gopedia-feature-guide.md	기능·개념 정의(L1/L2/L3, Envelope, Smart Sink, 폴리글랏, Skill Engine 등)
RoadMap/SKILL.md	Verify·Expand·Connect target-day 및 마일스톤

Project Introduce (EN)

1. Project Overview

Purpose

• Gopedia is an Enterprise Knowledge Graph Platform (ingestion and RAG) that unifies fragmented information into a knowledge network.
• Beyond a simple store, it provides the foundation for Enterprise Ontology with relationship inference and context awareness.
• Target: Single Source of Truth (SSoT) for distributed data and a knowledge inference engine.

Background / Introduction

“Put down roots of knowledge in the soil of data, and bear the fruit of wisdom, organically connected.”

Gopedia is designed around the lifecycle Root (pluggable sources) → Stem (Phloem: Ingestion / Xylem: RAG) → Rhizome (storage & relations) → Leaf (indexed views) · Fruit (reports), rather than mere data loading. It follows the relationship-centric principles of GeneSo Design Standard (v1.3) and aims for a horizontally, infinitely scalable knowledge network through the Rhizome metaphor.

Core Values

Metaphor	Meaning	Description
Pluggable (Root)	Input flexibility	Roots. Define external sources and connections (DB, API, streams) in a pluggable way
Scalable (Stem)	Pipeline scalability	gRPC-based Phloem (Ingestion) and Xylem (RAG) to move data. Phloem: source → Rhizome write. Xylem: Rhizome → Leaf / user search and response.
Relational (Rhizome)	Storage & relations	Polyglot stores (TypeDB, Qdrant, PostgreSQL, etc.) and relationship inference
View (Leaf)	Indexed views	Domain- and project-specific indexed views. Sources such as Markdown, Code, Ticket are stored in Rhizome, then surfaced via xylem-flow
Actionable (Fruit)	Value delivery	Report templates and formats combining multiple Leaf and Root data; Skill Engine and RAG outputs consumed by users

Problems Addressed

1. Distributed and unstructured data integration: Gather information scattered across many sources (Markdown, Code, Ticket, Meeting, ERP, etc.) into a Single Source of Truth (SSoT) and organize it as a Rhizome-style knowledge network (relationships and ontology).

2. Dense query and generation: Structure integrated data in L1/L2/L3 layers (summary → ToC → evidence chunks) so that at RAG time you can retrieve and generate only the desired context with fewer tokens. (See reference/gopedia-feature-guide.md §2.)

Applicable Domains and Organizations

• Scope: Any enterprise, government, or team.
• Examples:
  • Fintech and regulatory reporting: Unify distributed transactions and regulatory documents into one knowledge graph, then select only the needed context for audit and report generation to reduce token cost.
  • Large-scale infrastructure operations: Integrate 50+ K8s nodes and multiple server logs and configs by Machine ID, and use only “which server, which segment” in RAG. (reference/gopedia-feature-guide.md §6, §11, Skill Engine, Hydration)
  • Dev, docs, and issues integration: Collect code repos, wiki, tickets (Jira/Vikunja), and meeting notes as Root (pluggable sources), record to Rhizome via Phloem, and use relationship inference (TypeDB) and hierarchical search (Skill Engine, Xylem) for query, summary, and report generation.

How It Works (Summary)

• Root → Stem → Rhizome → Leaf · Fruit lifecycle:
  • phloem-flow (Ingestion) — Raw content collected from Root (sources) is wrapped in Envelopes and sent over gRPC, decomposed into L1→L2→L3 layers, then Smart Sink writes to polyglot stores (PostgreSQL, TypeDB, Qdrant, ClickHouse) by HierarchyLevel and SourceDomain.
  • xylem-flow (RAG) — On user query, filter by L1/L2 from Rhizome (Qdrant/TypeDB, etc.), pull relevant L3 chunks, combine via Skill Engine, and deliver to Leaf (indexed view) and Rhizome-using users as response and reports (Fruit). (See universitas/gopedia/SKILL.md, reference/gopedia-feature-guide.md.)

Completeness and PoC Scope

• Timeline and target dates

• Code Format (4.1.2): Target implementation complete by end of April.

• Ticket (4.1.3) and Meeting (4.1.4): Target implementation complete by end of May.

• For detailed target-day and milestones, see RoadMap/SKILL.md.

• Required environment: gRPC/Protobuf, Red Panda (Kafka-compatible), PostgreSQL, TypeDB, Qdrant, ClickHouse, SpiceDB (Connect phase). Validate locally/staging, then scale.

• Expected deliverables: Verify-phase “Root → Stem → Rhizome landing → Leaf” verification scripts and docs; Skill Engine and authorization PoC in Expand/Connect phases.

---

2. The Team

Name	ID	Role	SNS	Responsibilities - EN
신동호	@lyckabc	Team Leader	Link	Roadmap & Final decision-making
박보민	@bmops0719	Core Infra	Link	Infra Architecture reviews
김준곤	@jgkim	Core Dev	Link	reviewer

---

3. Tech Stack

• Communication & contract: gRPC / Protobuf — common language for all Stem communication. Contract-First; Schema Registry (Red Panda) for compatibility.

• Rhizome storage (polyglot):

  • PostgreSQL: Master metadata, records, Machine registry (identity-so).
  • TypeDB: Graph, ontology, relations (ontology-so).
  • Qdrant: Vector and semantic search (L1/L2/L3 embeddings).
  • ClickHouse: Analytics, BM25, raw text retention, audit.

• Authorization: SpiceDB-based ReBAC (auth-so).

• Messaging: Red Panda (Kafka-compatible).

• Languages & runtime: Go (gRPC, Stem pipelines), Python (Leaf adapters, scripts, etc.). Multi-language stubs generated with buf.

For detailed concepts (L1/L2/L3, Envelope, Smart Sink, Machine ID/Key, etc.), see reference/gopedia-feature-guide.md.

---

4. Roadmap

Gopedia evolves in three phases: Verify → Expand → Connect. Schedule and target-day are managed in RoadMap/SKILL.md.

Phase	Meaning	Summary
Verify (Sprouting)	Minimal-unit validation	Validate Root (sources) → Stem (Phloem) → Rhizome landing. 4.1.1 Markdown (2 days), 4.1.2 Code (7 days), 4.1.3 Ticket, 4.1.4 Meeting, 4.1.5 ERP, etc.
Expand (Growth)	Capacity & multi-source scale	Machine ID distribution (sharding-so), DB View activation, additional sources.
Connect (Fruiting)	Ecosystem integration	Integration with GeneSo, MorphSo, etc.; RAG Fruit (Skill Engine), SpiceDB authorization.

• 4.1.1 Markdown Origin: design target-day 2026-03-08, implementation complete 2026-03-10.

• 4.1.2 Code Origin: implementation complete 2026-03-18.

• For 4.1.3–4.1.5, Expand, and Connect schedules, see RoadMap/SKILL.md.

---

5. How to Contribute

• Apply by email: lyckabc@gmail.com

• Design principles and naming (Rhizome relationship, Root/Stem-Xylem·Phloem/Leaf/Rhizome/Fruit) are defined in universitas/gopedia/SKILL.md and geneso/references/geneso-design-standard.md.

• For Verify-phase sub-skills and checklists, see skills/gopedia-verify-flow/ and README.md.

---

6. Resources & Links

Resource	Notes
GitHub - tojiuni/gopedia · GitHub	public Docker file open
https://git.toji.homes/toji/gopedia	Team repo, to be opened
universitas/gopedia/SKILL.md	Design principles, structure, phases, sub-skill routing
reference/gopedia-feature-guide.md	Feature and concept definitions (L1/L2/L3, Envelope, Smart Sink, polyglot, Skill Engine, etc.)
RoadMap/SKILL.md	Verify, Expand, Connect target-day and milestones

| This is a space where knowledge is not merely consumed, but respected, sovereign, and connected—shared together with cloud industry professionals (Bros).|
| 지식이 소비되지 않고 존중·주권보장·연결되는 공간으로 클라우드 현업 전문가(Bro)와 함께 공유하고 있습니다. |