본문으로 건너뛰기

Obsidian 안에서 돌아가는 Gemma 4 E4B 위키

Gemma 4 E4B를 Obsidian 안에서 실행해 원본 노트를 보존한 채 로컬 위키와 출처 기반 질의를 구축합니다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Gemma 4 E4B를 LiteRT-LM과 WebGPU로 Obsidian 내부 프로세스에서 실행하는 Gemma Wiki 플러그인이 공개됐습니다. 플러그인은 원본 노트를 수정하지 않고 별도의 gemma-wiki 계층에 노트별 카드, 색인, 개념 페이지, 태그와 링크를 만들며 모든 쓰기 작업을 미리보기와 승인 뒤에 수행합니다. Wiki 모드는 색인을 먼저 읽고 관련 페이지를 불러와 답변을 구성하며 플러그인이 실제 출처를 나열하고, 신뢰도 저하·원문 변경·오래된 페이지·출처 불일치·모순을 검토 대상으로 표시합니다. 모델과 WASM 런타임을 한 번 내려받은 뒤 추론은 로컬에서 이뤄지지만, 약 3GB의 저장 공간과 WebGPU를 요구하고 4B 모델 특성상 범용 지식과 파일 형식 지원은 클라우드 모델보다 제한적입니다.

섹션별 상세

01
이 프로젝트는 Web Clipper로 쌓인 기사, 강의 노트, 논문을 다시 읽고 연결하기 어려운 문제에서 출발합니다. Gemma 4 E4B는 노트마다 요약, 태그, 핵심 요점, 주요 언급과 자체 신뢰도를 추출해 별도의 gemma-wiki 계층에 카드로 저장하고, 색인 위에 개념 페이지를 쌓아 여러 노트를 연결합니다. 원본 노트는 모델이 직접 수정하지 않으며, 모델이 만든 답변도 사람이 판단해 다시 수집하기 전까지 검색 대상에 들어가지 않아 잘못된 생성물이 지식 기반으로 되먹임되는 경로를 차단합니다.
원본 노트, gemma-wiki 계층, schema.md 규칙 파일로 나뉜 3계층 구조를 나타낸 다이어그램입니다.
Diagram상단의 원본 노트는 사용자가 소유하고 불변으로 유지되며, 가운데 gemma-wiki에는 카드와 개념 페이지와 색인이 쌓입니다. 하단의 schema.md는 태그 어휘와 이름 규칙을 담아 모델이 위키를 기록할 때 따르는 사용자 관리 규칙으로 기능합니다.
02
Gemma 4 E4B는 LiteRT-LM과 WebGPU를 통해 Obsidian의 Electron 프로세스 안에서 실행됩니다. 첫 사용 시 약 3GB 모델과 약 20~31MB의 WASM 런타임을 내려받고, 이후에는 별도 API 키나 Ollama, LM Studio, localhost 추론 서버 없이 로컬에서 생성합니다. WebGPU 런타임에 대용량 가중치를 전달하기 위해 127.0.0.1의 임시 루프백 서버를 쓰지만 파일은 자신의 디스크에서 같은 장치로만 전달되며, 노트와 질문과 답변은 외부로 전송되지 않습니다.
03
Ingest와 Scan은 엄격한 JSON 추출과 색인 카탈로그 기반 관련 페이지 선택을 수행한 뒤 전체 결과를 검토 모달에 표시합니다. 사용자가 승인해야 카드나 개념 페이지가 기록되고, Improve와 태그·링크 추천처럼 원본 노트에 쓰는 두 기능도 전체 미리보기를 거칩니다. Scan은 지정한 폴더만 대상으로 새 노트와 변경 노트를 처리하며 낮은 신뢰도부터 검토 목록을 정렬해 사람이 위험한 결과를 먼저 확인하게 합니다.
노트에서 생성한 위키 카드의 요약, 태그, 핵심 요점과 신뢰도를 쓰기 전에 검토하는 모달입니다.
Screenshot모달에는 생성될 경로와 카드 내용, 태그, 핵심 요점, 신뢰도와 원본 경로가 함께 표시됩니다. 사용자는 Cancel 또는 Approve and write를 선택하므로 모델 출력이 미리보기와 승인 없이 vault에 기록되지 않는 흐름을 확인할 수 있습니다.
04
Wiki 모드는 gemma-wiki/index.md를 먼저 읽고 관련 카드와 개념 페이지를 불러온 뒤 답변을 생성하며, 매 답변 끝에 플러그인이 실제로 사용한 출처를 결정적으로 표시합니다. 색인과 최근 활동 로그를 항상 함께 읽기 때문에 최근에 추가한 항목 같은 메타 질문도 처리하고, 자료가 질문에 답하지 않으면 근거가 없다고 거절합니다. 저장된 답변은 일반 노트로 남지만 검색 대상에서는 제외되며, 사람이 검토해 다시 Ingest해야만 위키 자료가 됩니다.
Wiki 모드가 색인을 바탕으로 여러 페이지에 걸친 질문에 답하고 사용한 출처를 나열하는 Obsidian 화면입니다.
Screenshot왼쪽 편집기에는 여러 카드와 개념 페이지를 연결한 Wiki Index가 있고, 오른쪽 패널은 네 페이지에 걸친 질문에 답하면서 Sources 행에 사용한 페이지를 표시합니다. 이는 색인을 먼저 읽고 필요한 자료를 검색한 뒤 플러그인이 결정적으로 출처를 붙이는 질의 경로를 시각화합니다.
05
플러그인은 위키가 조용히 낡거나 원문과 어긋나는 문제를 세 가지 검토 흐름으로 관리합니다. Review board는 낮은 자체 신뢰도, source_hash가 달라진 원문 변경, 오래된 페이지를 한 목록에 모으고, Provenance spot-check는 핵심 요점을 원문 문장까지 추적하며, Contradiction sweep은 같은 태그를 공유하는 페이지의 충돌 주장을 찾아 모델의 판단 근거와 함께 표시합니다. Tidy the wiki는 모델을 쓰지 않고 고아 페이지, 삭제된 페이지를 가리키는 색인, 누락된 색인 항목, 태그 어휘의 이탈을 검사한 뒤 사용자가 선택한 수리만 각각 미리보기 후 실행합니다.
DRIFTED, LOW, STALE 상태의 위키 페이지를 한 목록에서 검토하는 Review board 화면입니다.
Screenshot목록은 원본 노트가 변경된 페이지, 생성 당시 자체 신뢰도가 낮았던 페이지, 개념 페이지의 구성원이 달라진 페이지를 서로 다른 상태로 표시합니다. 각 항목을 선택한 뒤 재수집할 수 있지만, 화면의 기본 동작은 자동 수정이 아니라 사람이 검토 대상을 고르는 것입니다.
06
규칙과 상태도 데이터베이스가 아니라 Markdown 파일로 유지됩니다. schema.md에는 태그 어휘, 이름 규칙, 거부된 태그와 별칭이 저장되고, log.md에는 작업과 경고와 오류가 추가 기록되며, skills/에 프론트매터와 프롬프트를 넣으면 메뉴에 사용자 정의 단일 작업을 추가할 수 있습니다. 이 구조 덕분에 위키를 다른 도구 없이 읽을 수 있고, 설정과 활동 이력이 일반 텍스트로 남아 버전 관리와 수동 수정이 가능합니다.
07
성능 측정은 실제 LiteRT-LM 계측값과 한 대의 하드웨어에서 실행한 다섯 가지 고정 입력을 기반으로 합니다. 2,098토큰 입력의 콜드 엔진은 prefill 74.7 tok/s, decode 29.1 tok/s, 첫 토큰까지 28.1초였고, 예열된 1,558토큰 입력은 prefill 495.0 tok/s, decode 28.9 tok/s, 3.2초를 기록했습니다. 첫 호출의 지연은 GPU 셰이더 컴파일과 가중치 변환 비용이며, 예열 뒤 짧은 274토큰 선택 영역은 0.74초까지 줄어들고 decode 속도는 약 29 tok/s로 유지됩니다.
08
수작업 품질 점검에서는 기본 오탈자, 미묘한 문법 오류, 오류가 없는 문장, 목록, 기술 용어, 긴 글을 포함한 여섯 영어 입력에서 누락 오류와 허위 수정이 없었고 이미 올바른 문장은 exact-match 결과를 냈습니다. 구조화 출력은 greedy sampling으로 5회 모두 {
09
summary
10
string
11
tags
12
string
13
[3] ,
14
형태의 유효한 JSON을 반환했습니다. 다만 4B 모델은 API 뒤의 frontier 모델보다 일반 지식이 약하고, Markdown만 읽으며 모바일·PDF·이미지·Office 파일과 다중 제공자 추상화는 지원 범위 밖에 있습니다.

용어 해설

LLM 위키(LLM Wiki)
LLM Wiki는 기존 메모를 원본 그대로 보존하면서 모델이 별도 위키 계층을 만드는 지식 관리 패턴입니다. 원본 노트, 모델이 생성한 카드와 연결 페이지, 사용자가 직접 관리하는 규칙 파일을 분리해 자동화의 편의성과 원문 보존을 함께 확보합니다.
LiteRT-LM
LiteRT-LM은 브라우저와 WebGPU 환경에서 경량 언어 모델을 실행하도록 돕는 런타임입니다. 이 프로젝트에서는 Gemma 4 E4B의 WASM 런타임과 모델 가중치를 Obsidian 프로세스에 연결해 별도 추론 서버 없이 로컬 생성 작업을 수행합니다.
WebGPU
WebGPU는 GPU를 브라우저와 Electron 기반 애플리케이션에서 직접 활용하는 그래픽·계산 API입니다. Gemma 4 E4B의 추론에 GPU를 사용해 첫 실행 뒤 예열된 엔진에서 입력 처리량을 높이고 짧은 선택 영역의 응답 시간을 줄이는 기반이 됩니다.
소스 해시(source_hash)
소스 해시는 위키 카드가 만들어질 때 원본 노트의 상태를 식별하는 값입니다. 이후 노트가 수정되어 저장된 해시가 달라지면 플러그인이 카드와 원문 사이의 불일치를 감지하고 재수집 검토 대상으로 올립니다.
출처 추적성(Provenance)
출처 추적성은 생성된 핵심 요점이 원본 노트의 어느 문장에서 나왔는지 되짚는 성질입니다. 이 플러그인은 카드의 요점을 원문 문장과 대조해 연결되지 않는 항목을 표시하지만, 원문이나 위키를 자동으로 고치지는 않습니다.
탐욕적 샘플링(greedy sampling)
탐욕적 샘플링은 각 생성 단계에서 가장 높은 확률의 토큰을 선택하는 방식입니다. 같은 모델과 입력에서는 하드웨어가 달라도 결과가 같을 가능성을 높이지만, 백엔드별 반올림 차이로 토큰 선택이 달라질 수 있다는 미검증 조건이 남아 있습니다.

기술

  • Gemma 4 E4B
  • LiteRT-LM
  • WebGPU
  • Obsidian
  • Electron
  • WASM
  • Markdown
  • JSON

활용 사례

  • Obsidian 노트의 로컬 질의와 출처 확인
  • 노트별 요약 카드와 전체 색인 생성
  • 태그 기반 개념 페이지와 노트 간 링크 구축
  • 노트에서 퀴즈와 플래시카드 생성
  • 변경 원문과 낮은 신뢰도 카드의 검토
  • 노트 간 모순과 출처 불일치 점검
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 09. 09.수집 2026. 09. 09.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.