Field Log · Entry
LLM Wiki 종류와 선택법: 코드·개인·조직·그래프·에이전트 메모리 (3/6)
이번 글의 결론
- LLM Wiki의 종류는 제품 이름보다 무엇을 넣고, 무엇을 영속화하며, 누가 검수하고, 누가 다시 쓰는가로 나누는 편이 정확합니다.
- 실무에서는 코드베이스형, 개인·연구형, 조직 지식형, 도메인 계약·그래프형, 에이전트 메모리형 다섯 유형이 자주 나타납니다.
- 다섯 유형은 배타적이지 않습니다. 하나의 제품이 여러 유형을 결합할 수 있지만 canonical source와 review policy는 분리해야 합니다.
- 첫 선택은 vector DB나 graph DB가 아니라 질문의 반복성, 관계 제약, ACL, freshness, human review 비용에서 시작합니다.
- 가장 작은 유효 형태는 Markdown page + source link + Git review일 수 있습니다.
LLM Wiki 종류는 코드용 DeepWiki, 개인용 NotebookLM, 사내 지식 검색처럼 제품 목록으로 나누기 쉽습니다. 하지만 같은 제품도 source와 사용 mode에 따라 전혀 다른 시스템이 됩니다. 이 글은 입력, 영속 산출물, 주 사용자, 검수 방식 네 축으로 다섯 유형을 분류하고 선택 기준을 제시합니다.
먼저 네 축으로 시스템을 본다
아래 분류는 업계 표준 taxonomy가 아니라 구현 결정을 돕기 위한 실무 분류입니다. 제품에 라벨 하나를 붙이기보다 실제 workflow에 네 질문을 던집니다.
입력은 무엇인가?
code / commit / issue
paper / PDF / memo
Slack / Drive / runbook
sensor report / event / experiment
agent transcript / task / diffInput format은 parser와 security boundary를 결정합니다. Code는 symbol과 dependency가 중요하고, paper는 citation과 section coordinate, 조직 문서는 ACL, agent transcript는 tool log와 secret redaction이 중요합니다.
무엇을 영속 산출물로 남기는가?
- Plain Markdown page
- Page hierarchy와 backlink
- Typed entity와 relation
- Summary·brief·FAQ 같은 derived view
- Search index만 남기고 answer는 query 때 생성
같은 source-grounded AI라도 answer만 남으면 conversational knowledge base에 가깝고, stable page/node가 남으면 LLM Wiki 성격이 강해집니다.
누가 다시 쓰는가?
사람이 읽는 onboarding document와 coding agent가 tool로 읽는 context package는 최적 구조가 다릅니다. 전자는 narrative와 diagram이, 후자는 stable ID, compact summary, schema, machine-readable link가 더 중요할 수 있습니다.
누가 정본을 결정하는가?
개인 notebook은 owner 한 명의 승인으로 충분할 수 있습니다. 조직 policy와 제조 trouble-shooting 지식은 role-based review, source permission, effective date, rollback이 필요합니다.
그림 1. 유형은 제품 브랜드가 아니라 input, artifact, consumer, governance의 조합으로 선택한다.
유형 1. 코드베이스 문서화형
Repository를 넣으면 architecture overview, component page, diagram, source link를 만드는 유형입니다. Cognition의 DeepWiki와 open-source repository wiki generator가 대표적입니다.
repository snapshot
→ file/symbol/dependency analysis
→ page plan
→ module·flow·API documentation
→ source-linked wiki + Q&A잘 맞는 문제
- 처음 보는 open-source repository를 빠르게 파악합니다.
- 팀의 onboarding 질문이 반복됩니다.
- Architecture document가 code와 자주 어긋납니다.
- Coding agent가 repository 전체의 map을 필요로 합니다.
핵심 품질 기준
- Documented file·module coverage
- Page claim에서 code line·commit으로 돌아가는 link
- Cross-module call·data flow 정확성
- Generated page가 마지막으로 읽은 commit
- Large repository의 page plan steering
DeepWiki 공식 문서도 큰 repository에서 중요한 component가 빠질 수 있어 .devin/wiki.json으로 repo_notes와 생성할 pages를 지정하는 방법을 제공합니다. 코드베이스형에서 자동 page planning은 특히 검수가 필요합니다.
주의할 점
Code가 보여 주는 것은 주로 “현재 무엇을 하는가”입니다. 왜 이 설계를 택했는지, 어떤 incident 때문에 guard가 생겼는지는 decision record와 issue를 함께 읽어야 합니다. Repository source만 넣고 조직의 맥락까지 복원했다고 주장하면 안 됩니다.
유형 2. 개인·연구 노트형
논문, PDF, web page, 강의, 개인 memo를 source-grounded notebook으로 묶는 유형입니다. Google은 NotebookLM을 source를 바탕으로 질문하고 inline citation을 확인하며 study guide, briefing, mind map 등을 만드는 research assistant로 설명합니다.
paper + memo + web source
→ notebook collection
→ citation-grounded answer
→ concept note / brief / question map잘 맞는 문제
- 여러 논문의 공통점과 차이를 비교합니다.
- 읽은 자료를 주제별 note로 연결합니다.
- 박사과정·자격 공부에서 “어디서 봤는지”를 보존합니다.
- 아이디어와 evidence를 분리합니다.
핵심 품질 기준
- Citation이 source의 정확한 page·span으로 이동하는가
- Fact, author claim, 내 inference가 구분되는가
- 같은 source의 edition·version이 구분되는가
- Note가 단순 summary를 넘어 비교·gap·open question을 남기는가
주의할 점
Research assistant가 만든 answer와 내 연구 지식의 canonical note는 같지 않습니다. 자동 summary는 candidate로 두고, 검토한 claim만 durable note로 승격해야 나중에 인용 오류가 누적되지 않습니다.
유형 3. 조직 지식형
Drive, Slack, Notion, issue tracker, runbook처럼 여러 system에 흩어진 정보를 permission-aware하게 찾고 팀 지식으로 정리하는 유형입니다.
connected enterprise sources + ACL
→ search/fetch
→ cited answer
→ optional reviewed page/runbook/decisionChatGPT company knowledge도 연결된 조직 source를 search·fetch해 citation과 함께 답하고 기존 permission을 존중한다고 설명합니다. 이 mode는 영속 page를 반드시 생성하지 않으므로 그 자체는 conversational knowledge layer에 가깝지만, 검수된 page promotion을 붙이면 조직형 LLM Wiki가 됩니다.
잘 맞는 문제
- 같은 policy 질문이 여러 channel에서 반복됩니다.
- 사람을 찾아가야만 알 수 있는 운영 지식이 많습니다.
- Incident와 decision이 source tool마다 분산돼 있습니다.
- 답변의 ACL과 audit가 중요합니다.
핵심 품질 기준
- Source permission이 retrieval·cache·generated artifact까지 전파되는가
- 퇴사자·조직 이동·문서 삭제가 반영되는가
- Policy의 effective date와 owner가 명확한가
- Answer citation뿐 아니라 promoted page의 source lineage가 남는가
주의할 점
권한이 다른 source를 한 summary에 섞으면 새 문서가 정보 누출 통로가 될 수 있습니다. “검색할 수 있는 사람”과 “파생 page를 볼 수 있는 사람”의 권한을 별도로 계산해야 합니다.
유형 4. 도메인 계약·그래프형
제조, 금융, 연구, 법무처럼 entity type, relation, lifecycle, required evidence가 중요한 영역입니다. Free-form page보다 contract를 먼저 정의합니다.
entity: experiment
required:
- hypothesis
- dataset
- metric
- result
relations:
- tests -> hypothesis
- uses -> dataset
lifecycle:
proposed: [running, rejected]
running: [completed, failed]잘 맞는 문제
- “설비 A의 alarm과 failure mode, 조치, 결과”를 연결합니다.
- 논문·module·experiment·result의 계보를 추적합니다.
- Market event·prediction·outcome을 사후 평가합니다.
- Entity와 relation의 허용 조합을 기계적으로 검사해야 합니다.
Microsoft GraphRAG도 unstructured text에서 entity, relationship, optional claim, community report를 추출하지만, 여기서 말하는 계약형 wiki와 목적은 다를 수 있습니다. GraphRAG의 graph는 query context를 만드는 retrieval index이고, 계약형 wiki의 graph는 domain record와 lifecycle의 정본일 수 있습니다. 한 시스템에서 둘을 함께 쓸 수도 있습니다.
핵심 품질 기준
- Entity schema와 required field
- Relation endpoint·direction·evidence constraint
- Duplicate entity resolution
- Lifecycle transition validity
- Source-to-claim·edge lineage
- Graph orphan·broken link·cycle 같은 integrity
주의할 점
Graph를 먼저 만들고 ontology를 나중에 붙이면 related_to edge만 가득한 hairball이 됩니다. 처음에는 독자가 실제로 물을 3~5개 relation과 page kind만 선택합니다.
유형 5. 에이전트 메모리형
Claude Code, Codex, OpenCode 같은 agent session과 task, code diff, decision을 다음 실행의 project memory로 바꾸는 유형입니다.
request + transcript + tool log + diff + test
→ work summary / decision / task / lesson proposal
→ reviewed project memory
→ next-agent context package잘 맞는 문제
- Session이 바뀔 때 같은 repository 탐색을 반복합니다.
- 여러 agent가 서로 다른 task를 수행합니다.
- “무엇을 했는가”보다 “왜 했고 무엇이 남았는가”가 중요합니다.
- 여러 project의 current state와 next action을 한 화면에서 봅니다.
핵심 품질 기준
- Request, action, result, verification을 구분하는가
- Plan과 완료된 작업을 혼동하지 않는가
- Tool log에서 secret·PII를 redaction하는가
- Diff·test·commit 같은 결과 근거가 연결되는가
- Context package가 token budget 안에서 최신 정보를 고르는가
주의할 점
Transcript summary를 사실로 승격하면 agent가 “할 예정”이라고 말한 일을 완료된 것으로 기억할 수 있습니다. Completion claim은 commit, test, artifact, handoff로 검증해야 합니다.
다섯 유형 한눈에 비교
| 유형 | 대표 입력 | 영속 산출물 | 주 소비자 | 가장 큰 위험 |
|---|---|---|---|---|
| 코드베이스 | code·commit·issue | module·flow page, diagram | 개발자·coding agent | 누락·stale architecture |
| 개인·연구 | paper·PDF·memo | concept·brief·question note | 개인·연구자 | 인용과 inference 혼합 |
| 조직 지식 | Drive·Slack·runbook | cited answer, reviewed policy | 팀·업무 agent | ACL 누출·낡은 policy |
| 계약·그래프 | domain record·문서 | typed node·edge·lifecycle | 분석가·domain agent | ontology 과설계·잘못된 relation |
| 에이전트 메모리 | transcript·task·diff | decision·work summary·next task | 다음 agent·PM | 계획을 완료로 오인 |
유형은 겹칠 수 있습니다. Code wiki를 MCP로 coding agent에게 주면 코드베이스형+에이전트 메모리형입니다. 논문 note에 experiment graph와 lifecycle을 넣으면 개인·연구형+계약·그래프형입니다.
저장 형태는 유형과 별도로 선택한다
Markdown + Git
가장 단순하고 강력한 기본값입니다.
- 사람이 바로 읽고 고칠 수 있습니다.
- Diff, review, rollback이 이미 있습니다.
- Obsidian-style link나 static site로 확장할 수 있습니다.
- Agent가 별도 SDK 없이 읽을 수 있습니다.
Weakness는 복잡한 query와 대규모 ACL입니다.
Relational database
Page metadata, review state, source ledger, ACL, job status에 적합합니다. Transaction과 unique constraint가 필요하면 먼저 선택합니다.
Graph database 또는 edge file
Relation traversal이 제품의 핵심일 때 씁니다. 수천 개 node를 그리는 UI 때문에 선택하는 것이 아니라, typed multi-hop query와 integrity rule 때문에 선택해야 합니다.
Vector index
Semantic retrieval과 Q&A에 유용하지만 canonical store가 아닙니다. Embedding을 지우고 다시 만들어도 page와 provenance가 남아 있어야 합니다.
실무에서는 다음 조합이 자주 충분합니다.
Markdown/Git = canonical knowledge
SQLite = job·review·source ledger
BM25/vector = retrieval index
edges.jsonl = typed relation선택을 위한 결정 질문
다음 순서대로 답하면 technology보다 먼저 architecture가 정리됩니다.
1. 반복되는 job은 무엇인가?
“회사 지식을 AI로”가 아니라 하나의 반복 작업을 씁니다.
새 개발자가 결제 service의 request flow를 파악한다.
연구자가 논문 20개의 dataset과 metric 차이를 비교한다.
다음 agent가 어제 실패한 test와 남은 task를 이어받는다.2. 정본은 어디에 있는가?
Code, policy document, database, human owner 중 무엇이 authoritative한지 결정합니다. LLM-generated wiki 자체를 근거의 시작점으로 두지 않습니다.
3. 답변만 필요한가, page가 필요한가?
반복 질문의 빠른 답이면 RAG Q&A가 먼저일 수 있습니다. Browse, onboarding, review, reuse가 중요하면 materialized page를 추가합니다.
4. 관계가 설명인가, 규칙인가?
“관련 글” 정도면 Markdown link로 충분합니다. experiment tests hypothesis처럼 허용 endpoint와 evidence를 검사해야 하면 typed graph가 필요합니다.
5. 잘못됐을 때 피해와 검수 비용은 얼마인가?
개인 독서 note와 production runbook은 같은 automation level을 쓰면 안 됩니다. High-stakes page는 proposal-only, owner review, source freshness gate를 둡니다.
6. Source가 바뀌면 어떻게 알 것인가?
File hash, commit, updated timestamp, CDC 중 하나를 선택합니다. 답이 없으면 build가 아니라 일회성 generation입니다.
제가 유형을 섞으며 겪은 문제
개인 LLM Wiki와 project dashboard를 함께 만들면서 코드베이스형, 조직형에 가까운 project docs, 에이전트 메모리형을 한 UI에 모았습니다. 기능은 많아졌지만 사용자가 Home, Knowledge, Wiki Gen 중 어디서 무엇을 해야 하는지 모호해졌습니다.
원인은 backend package 수가 아니라 서로 다른 lifecycle을 한 화면에 섞은 것이었습니다.
- 평소 읽는 promoted knowledge
- 지금 생성 중인 candidate
- 검수 대기 proposal
- 다음 작업을 위한 context
이 네 상태를 분리하자 필요한 화면도 분리됐습니다. 유형을 결합하더라도 ingestion pipeline과 canonical policy를 하나로 뭉치지 말아야 한다는 교훈을 얻었습니다.
자주 묻는 질문
개인 위키는 local model로 만들어야 하나?
필수는 아닙니다. Source 민감도, cloud provider 약관, 비용, 품질을 함께 봅니다. 민감한 source는 local processing 또는 승인된 enterprise boundary가 필요하고, 공개 논문은 cloud model이 더 경제적일 수 있습니다.
Graph DB 없이 지식 그래프 위키를 만들 수 있나?
가능합니다. Typed edge를 JSONL이나 relational table에 저장하고 Markdown page에 projection할 수 있습니다. Traversal 규모와 동시 query 요구가 커질 때 graph DB로 옮겨도 됩니다.
제품 하나로 다섯 유형을 모두 지원하는 것이 좋은가?
가능하지만 first release 목표로는 위험합니다. Source adapter, schema, ACL, evaluation이 유형마다 다릅니다. 한 job과 한 canonical policy를 닫은 뒤 domain pack으로 확장하는 편이 안전합니다.
기존 Notion·Confluence를 버려야 하나?
그럴 필요가 없습니다. 기존 wiki를 canonical source로 두고 LLM layer가 search, proposal, stale detection을 제공할 수 있습니다. 가장 먼저 해결할 문제는 migration이 아니라 provenance와 review flow입니다.
마무리
LLM Wiki를 선택할 때 제품 demo보다 다음 표를 먼저 채우세요.
job_to_be_done:
authoritative_sources:
persistent_artifacts:
primary_consumers:
review_owner:
freshness_signal:
permission_boundary:
failure_cost:답이 코드 onboarding이면 코드베이스형, 논문 sensemaking이면 개인·연구형, permission-aware policy 답변이면 조직형, relation constraint가 핵심이면 계약·그래프형, 다음 agent handoff가 목적이면 에이전트 메모리형에서 시작합니다.
다음 글 LLM Wiki와 RAG의 차이에서는 가장 많이 혼동하는 두 개념을 query-time architecture와 knowledge lifecycle로 분리합니다.