llm wiki 입문기 feat.secall

113.235.***.***
8

요 며칠동안 secall을 알게 되고 llm wiki를 구축하면서 시행착오도 많이 겪어보고 처음으로 max100 세션한도를 다써보게 됐네요

secall로 모든걸 claude 로 진행해보았으나 사용량이 감당이 되지 않더군요.. 개발자님의 충고를 너무 늦게 봤던거죠

그래도 어찌어찌 기존 세션 위키화를 진행한 후 wiki update는 secall의 의 기능이 아닌 gemma4에게 맡기고 있습니다

물론 gemma4도 완전히 믿을 수는 없는지라 나름의 pr시스템을 갖춰나가고 있습니다

현제 pr파이프라인은 3개로 구축 되어있습니다

  1. 스케쥴로 session 대화들을 확인하여 wiki후보탐색, wiki 문서작성(gemma4)

  2. llm wiki 외부의 project 관점에서 wiki search mcp를 이용한 wiki 조회로 프로젝트와 wiki문서 갭, 신규 wiki문서 작성(claude)

  3. obsidian web clipper로 게시판, 유튜브등을 본문 내용과 인터프리터 기능으로 ai요약 등을생성하여 클리핑(gemma4,인간)

위 3가지 파이프라이닝은 llm wiki 관리자인 claude에게 pr 요청을 하고 claude가 판단을 하여 반영, 반려, 수정 식으로 구축을 하고 있습니다 . 물론 아직 조정중이지만요

codex사용도 해보고 싶어서 1번을 codex의 gpt에게 시켜볼까 하는 생각도 있습니다. 제미나이는 안되겠더라구요

3번 의 경우 직접 클리핑을 해서 raw에 저장하는 구조다보니 secall 임베딩에 포함되지 않아 꼼수로 claude code 대화 session json파일을 모사하여 대화 첫턴에 md파일 내용을 밀어넣는 형태로 임베딩을 하고 있습니다

좀 더 고도화가 필요하겠지만요

🧠 LLM Wiki / Second Brain 아키텍처 요약


📌 핵심 철학

"세션은 끊기지만 맥락은 죽지 않는다"

인간의 해마처럼, LLM의 망각을 구조적으로 막는 외부 메모리 시스템.
내가 보는 노트가 아니라, LLM이 효율적으로 소비하는 외부 기억.


🏗️ 계층 구조

Raw Memory       → SQLite (seCall) — 대화/클리핑/로그 원본
Working Memory   → 정제 중인 PR 레이어
Knowledge Layer  → Obsidian Wiki — 검증된 지식

버리는 게 아니라 레이어를 이동. Reject 대신 Downgrade.


🤖 멀티 LLM 역할 분리

역할

담당

웹 클리퍼 인터프리터

Gemma 4 (로컬)

세션 스캔 → wiki PR 생성

GPT (배치)

wiki 관리자 / 가드닝 / PR 승인

Claude

어느 LLM과 대화하든 같은 메모리 레이어를 바라보는 구조.


🔁 PR 파이프라인

세션/클리핑
   ↓
Gemma (요약/압축/정규화)
   ↓
GPT (구조화/PR 생성)
   ↓
Claude (검토/승인/거절)
   ↓
Wiki 반영

🌱 클리핑 = Seed 개념

클리핑은 완성된 지식이 아니라 지식의 씨앗.

  • 단락 단위 turn 분해 → 임베딩 가능

  • Retrieval unit = Wiki unit

  • 가져온 순간 바로 사용 가능한 단위로 저장

권장 turn 구조

## Summary
핵심 요약

## Key Actions
실행 포인트

## Core Concepts
핵심 개념

## Insight
추론 / 의미

## Raw
원문

🔍 seCall 역할

명령

역할

wiki search

형태소 기반 — "무엇을 아는가"

recall

벡터 검색 — "어떻게 생각했는가"

get

turn 복원 — 과거 사고 replay

BM25 + 벡터 하이브리드로 정밀도 + 재현율 동시 확보.


💡 기존 RAG와의 차이

기존 RAG

LLM Wiki

데이터

정적 문서

살아있는 지식베이스

세션 간 맥락

없음

wiki + seCall이 연결

업데이트

수동

멀티 LLM 자율 운영

설계 기준

인간이 읽기 좋게

LLM이 소비하기 좋게


⚖️ 주요 설계 원칙

  1. Chunking이 가장 중요 — embedding보다 "어떻게 나누느냐"가 핵심

  2. Retrieval unit = Wiki unit — 가져온 순간 바로 사용 가능한 단위

  3. Reject 대신 Downgrade — 버리지 않고 레이어 이동

  4. Insight는 2차 데이터 — 반드시 검증 필요, Claude가 gatekeeper

  5. Layered Memory — Raw → Working → Wiki 단계적 정제


🚀 진화 계보

전통 RAG
→ 문서 청크 임베딩, 쿼리 시 검색 주입
→ 한계: 정적, 구조 없음

LLM Wiki (현재 개념)
→ 대화/경험을 구조화된 문서로 변환
→ 한계: 아직 인간 중심 설계

이 시스템
→ LLM이 소비하기 최적화된 구조
→ 멀티 LLM 자율 생산/관리
→ 컨텍스트 윈도우의 외부 확장

🎯 한 줄 본질

RAG가 "검색해서 넣는다"라면,
LLM Wiki는 "LLM이 스스로 기억을 관리하는 구조"

단순 second brain이 아니라 멀티 LLM의 공유 장기기억 레이어.
그리고 이 대화 자체도 ingest되어 그 기억의 일부가 된다.

secall개발자님께 커피라도 한잔 사드리고 싶은대 뭔가 창구라도 하나 만들어주시죠 ㅎㅎ

issue 많이 올려서 죄송합니다

그럼이만

로그인한 회원만 댓글 등록이 가능합니다.

개발한당

KR | ID | EN
  • IDR
  • KOR
8.36 0.01

2026.07.10 KEB 하나은행 고시회차 970회

다가오는 한인 행사일정

  • 등록 된 일정이 없어요!