옵시디언 LLM Wiki가 더 똑똑해지는 방법

Knap으로 스크랩·인덱싱·검색을 다시 설계하기

옵시디언과 LLM을 함께 쓰다 보면 어느 날 이런 질문이 남습니다.

“자료는 계속 쌓이는데, 필요한 순간에 정말 찾을 수 있는가?”

“웹에서 스크랩한 글이 내 지식 체계 안으로 들어온 것인가, 아니면 또 하나의 고립된 파일이 된 것인가?”

“AI가 내 노트를 읽을 때 제목과 날짜, 출처와 주제를 일관되게 이해할 수 있는가?”

이 문제를 해결하는 데 도움이 되는 도구가 Knap입니다.

Knap은 데이터를 Markdown으로 바꾸는 템플릿 언어입니다. 변수와 조건문, 반복문, 필터로 같은 종류의 자료를 같은 모양으로 출력합니다. 겉으로는 문서 템플릿처럼 보이지만 옵시디언 LLM Wiki에 붙이면 스크랩·인덱싱·검색 규칙을 자동으로 지키게 하는 작은 변환기처럼 쓸 수 있습니다.

Knap의 문법을 빠짐없이 설명하는 사용 설명서는 아닙니다. 옵시디언에 노트를 모으고 있거나 LLM으로 개념·인물·프로젝트별 Wiki를 만들고 있다면, Knap을 넣기 전과 후에 무엇이 달라지는지에 집중하겠습니다.

기존의 옵시디언 활용법과 LLM Wiki의 기본 철학은 옵시디언과 목회자: 오래 쌓아 온 설교가 다시 말을 걸 때에서 먼저 소개했습니다. 이번에는 그 구조에 Knap이라는 “정리 규칙”을 하나 더 얹어 보겠습니다.

Knap은 무엇을 해결하는가

Knap 공식 홈페이지는 Knap을 “데이터를 Markdown으로 바꾸는 간단한 템플릿 언어”로 소개합니다. 템플릿 안에 {{ 변수 }}를 넣고, | 뒤에 필터를 연결해 값을 다듬습니다. {% if %}로 조건을 걸고 {% for %}로 배열을 반복할 수도 있습니다.

예를 들어 제목과 요약, 태그를 입력받아 옵시디언 노트를 만들고 싶다면 다음처럼 작성할 수 있습니다.

---
title: {{ title | yaml_value }}
source: {{ url | yaml_value }}
captured: {{ published | date:"YYYY-MM-DD" | yaml_value }}
tags:
{{ tags | yaml_list }}
---

# {{ title }}

{{ summary }}

출처: {{ url | link:title }}

Knap이 자료의 내용을 판단해 주는 것은 아닙니다. 자료가 들어오는 모양과 AI가 읽을 구조를 일정하게 만드는 도구입니다.

공식 문서에 따르면 Knap은 Node.js 20 이상에서 CLI로 실행할 수 있고, npm install knap으로 앱에 라이브러리로 추가할 수도 있습니다. 가장 간단한 CLI 사용법은 다음과 같습니다.

npx knap render template.md --data data.json --output note.md

문법이 맞는지 먼저 확인하려면 다음처럼 검증할 수 있습니다.

knap validate template.md

문법을 더 확인하려면 변수, 필터, 조건과 반복, CLI, API 공식 문서를 보시면 됩니다.

이전의 LLM Wiki와 무엇이 달라지는가

Knap이 없어도 LLM Wiki는 만들 수 있습니다. 사람이 Markdown을 직접 쓰거나 LLM에게 매번 같은 형식을 지시하면 됩니다. 달라지는 건 반복되는 형식의 책임을 프롬프트와 사람의 기억에서 템플릿으로 옮긴다는 점입니다.

Knap은 데이터베이스나 벡터 검색 엔진을 새로 붙이는 도구가 아닙니다. 지금 가진 Markdown을 규칙이 있는 데이터로 바꾸는 전처리 단계에 가깝습니다.

1. 인덱싱에서 생기는 변화

LLM Wiki의 인덱스는 단순한 파일 목록이 아닙니다. 어떤 자료가 있고, 서로 어떤 개념으로 연결되며, 최신 자료가 무엇인지 알려 주는 입구입니다.

도입 전

스크랩한 파일이 다음처럼 제각각 저장될 수 있습니다.

좋은 설교에 대한 글.md
sermon-research-2026-09.md
new article.md
목회 자료 최종 진짜최종.md

파일 이름만으로는 자료 유형, 출처, 작성일, 관련 주제를 알기 어렵습니다. LLM에게 전체 폴더를 읽히면 AI가 본문은 이해하더라도 “무엇이 원자료이고 무엇이 내 요약인지”를 매번 추측해야 합니다.

Knap 도입 후

Knap 템플릿으로 최소한의 frontmatter를 일정하게 만들 수 있습니다.

---
title: {{ title | yaml_value }}
source_url: {{ url | yaml_value }}
source_type: web-clip
captured_at: {{ captured_at | date:"YYYY-MM-DD" | yaml_value }}
author: {{ author | yaml_value }}
topics:
{{ topics | yaml_list }}
status: raw
---

이제 LLM Wiki는 파일명만 보지 않고 source_type, captured_at, topics, status 같은 공통 필드를 기준으로 자료를 분류할 수 있습니다.

예를 들어 인덱스 템플릿을 별도로 만들어 다음과 같은 목록을 자동 생성할 수 있습니다.

## 최근 스크랩

{% for note in notes %}
- {{ note.captured_at | date:"YYYY-MM-DD" }} — [[{{ note.title }}]] · {{ note.source_type }}
{% endfor %}

이렇게 만든 인덱스는 “폴더 안에 파일이 몇 개 있다”는 목록을 넘어 다음 질문에 답하는 화면이 됩니다.

• 이번 주에 어떤 주제의 자료를 많이 모았는가?
• 아직 읽지 않은 원자료는 무엇인가?
• 같은 저자나 같은 출처의 글이 어떻게 연결되는가?
• 특정 사역이나 설교 주제에 어떤 자료가 누적되어 있는가?

2. 검색에서 생기는 변화

검색의 품질은 AI 모델의 크기만으로 결정되지 않습니다. 검색 대상이 일정한 이름과 메타데이터를 가지고 있는지가 중요합니다.

단순 검색의 한계

“청년 사역 관련 자료를 찾아 줘”라고 했을 때, 자료 안에 청년이라는 단어가 실제로 들어 있지 않으면 검색에서 빠질 수 있습니다. 반대로 본문에 잠깐 등장했다는 이유만으로 관련성이 낮은 자료가 함께 나올 수 있습니다.

Knap을 활용한 검색 구조

스크랩 단계에서 태그와 자료 유형을 일정하게 넣으면 검색 조건을 더 구체화할 수 있습니다.

---
title: {{ title | yaml_value }}
topics:
{{ topics | kebab | yaml_list }}
ministry: {{ ministry | kebab | yaml_value }}
kind: {{ kind | yaml_value }}
---

예를 들어 다음과 같은 기준을 만들 수 있습니다.

• ministry: youth — 청년·청소년 사역
• ministry: sermon — 설교 연구
• kind: case-study — 실제 사례
• kind: theology — 신학·성경 연구
• kind: operations — 행정·운영
• status: reviewed — 사람이 확인한 자료

이렇게 해 두면 LLM에게도 “본문에 청년이라는 단어가 있는 모든 글”이 아니라 “청년 사역으로 분류되고 사람이 검토한 사례 연구”를 우선 읽으라고 지시할 수 있습니다.

다만 이것은 검색 엔진을 대체하는 마법이 아닙니다. 태그가 잘못 붙으면 검색 결과도 잘못됩니다. Knap은 분류를 자동화할 수 있지만, 무엇을 중요한 주제로 볼지는 목회자와 팀이 정해야 합니다.

3. 스크랩에서 생기는 변화

옵시디언 Web Clipper를 사용하면 웹페이지를 Markdown으로 가져올 수 있습니다. 문제는 같은 클리퍼라도 사이트마다 제목, 저자, 날짜, 본문, 이미지, 링크가 다르게 들어올 수 있다는 점입니다.

Knap은 클리퍼가 제공하는 변수를 템플릿에 넣어 스크랩 결과를 우리 Wiki의 규격으로 변환하는 역할을 할 수 있습니다.

기본 스크랩 템플릿

---
title: {{ title | yaml_value }}
url: {{ url | yaml_value }}
author: {{ author | yaml_value }}
published: {{ published | date:"YYYY-MM-DD" | yaml_value }}
captured: {{ date | date:"YYYY-MM-DD HH:mm" | yaml_value }}
tags:
  - web-clip
  - {{ type | kebab }}
---

# {{ title }}

> 원문 출처: [{{ title }}]({{ url }})

{{ content }}

## 나의 메모

- 핵심 주장:
- 우리 사역과 연결되는 지점:
- 추가로 확인할 출처:

이 템플릿의 효과는 화려한 자동화가 아닙니다. 스크랩한 모든 자료에 출처와 나의 메모 공간이 생긴다는 점입니다. 원문과 나의 해석을 분리하면 LLM이 두 내용을 섞어 사실처럼 답하는 위험도 줄어듭니다.

조건부 스크랩

모든 자료에 동일한 섹션이 필요한 것은 아닙니다. Knap의 조건문을 사용하면 저자나 요약이 있을 때만 해당 필드를 출력할 수 있습니다.

{% if author %}
저자: {{ author }}
{% endif %}

{% if summary %}
## 요약

{{ summary }}
{% endif %}

사이트마다 형식이 달라도 최종 Markdown의 골격은 일정하게 유지됩니다.

4. 목회 현장에서 달라지는 것

Knap과 LLM Wiki를 목회에 적용할 때 핵심은 “설교를 AI에게 맡긴다”가 아닙니다. 목회자가 이미 읽고 듣고 기록한 것을 다시 발견할 수 있게 만드는 것입니다.

설교 준비

설교 관련 자료를 본문, 주제, 저자, 시대, 적용 대상, 검토 상태로 정리하면 다음 설교를 준비할 때 관련 자료를 더 빨리 모을 수 있습니다.

예를 들어 “누가복음 15장과 회복을 주제로 한 청년 설교 자료 중 내가 검토한 것”처럼 질문할 수 있습니다. AI는 검색 결과를 제시하고, 목회자는 원문을 열어 문맥과 신학적 타당성을 직접 확인합니다.

설교 아카이브

과거 설교문을 Markdown으로 옮길 때 Knap 템플릿을 적용하면 제목, 본문, 설교일, 시리즈, 핵심 문장, 사용한 예화, 관련 성경구절을 일정하게 저장할 수 있습니다.

그러면 “3년 전 부활절에 어떤 메시지를 전했는가”뿐 아니라 “지난 설교에서 반복해서 강조한 목회적 주제는 무엇인가”도 돌아볼 수 있습니다. 이것은 AI가 목회자를 평가하는 일이 아니라, 목회자가 자신의 사역을 회고할 수 있는 거울을 만드는 일입니다.

새가족과 양육

새가족 교육자료, 소그룹 교재, 질문과 답변, 안내문을 주제별로 연결하면 담당자가 바뀌어도 교회의 설명 방식이 이어집니다.

예를 들어 kind: newcomer, stage: first-visit, stage: baptism-class 같은 필드를 사용하면 새가족의 여정에 맞는 자료를 빠르게 모을 수 있습니다. 단, 상담 기록과 개인정보는 일반 지식 Wiki와 분리하고, 개인을 식별할 수 있는 내용은 AI 입력 대상에서 제외해야 합니다.

목회 행정

회의록과 행사 매뉴얼을 정해진 템플릿으로 저장하면 “지난해 이 행사를 어떻게 준비했는가”를 검색할 수 있습니다. 담당자, 마감일, 예산, 장소, 체크리스트가 일정한 필드로 남으면 AI는 초안을 만들 수 있고, 팀은 누락된 업무를 확인할 수 있습니다.

목회자 개인의 회고

설교 후 느낀 점, 성도들의 질문, 사역 중 배운 점을 날짜와 주제로 기록하면 시간이 지나 자신의 목회 여정을 다시 읽을 수 있습니다. Knap은 그 기록을 월별·주제별·사역별 목록으로 재구성하는 데 도움을 줍니다.

여기서 가장 중요한 원칙은 개인 상담 내용과 민감한 성도 정보는 원자료 단계부터 분리하는 것입니다. 구조화가 잘된 데이터는 강력하지만, 잘못된 자료가 구조적으로 쌓이면 위험도 함께 커집니다.

5. LLM Wiki의 작업 흐름이 어떻게 바뀌는가

Knap을 더한 LLM Wiki는 다음과 같은 흐름으로 운영할 수 있습니다.

1. 웹 클리퍼나 문서 변환 도구로 원자료를 raw/에 저장합니다.
2. Knap 템플릿으로 제목·출처·날짜·유형·태그를 정규화합니다.
3. 사람이 원문과 메타데이터를 짧게 확인합니다.
4. LLM이 원자료를 읽고 개념·인물·프로젝트 문서와 링크를 생성합니다.
5. Knap으로 인덱스와 최근 자료 목록을 다시 렌더링합니다.
6. 질문에 대한 답변은 derived/ 같은 별도 공간에 저장합니다.
7. 정기적으로 빈 문서, 끊어진 링크, 중복, 출처 없는 주장을 점검합니다.

이 구조에서 Knap은 LLM을 대신하는 것이 아니라, LLM이 읽기 전과 읽은 후의 문서 형태를 관리하는 역할을 합니다.

언제 도입하면 좋은가

다음 중 두 가지 이상에 해당한다면 Knap을 시험해 볼 만합니다.

• 같은 형식의 웹 자료를 매주 여러 개 스크랩한다.
• 옵시디언 파일마다 frontmatter 형식이 달라 검색이 불편하다.
• LLM이 자료의 출처와 나의 해석을 자주 혼동한다.
• 인덱스를 수동으로 갱신하는 일이 부담스럽다.
• 설교·교육·행정 자료를 담당자 교체 후에도 이어 가야 한다.
• 같은 원자료를 목록, 요약, 인덱스, 보고서로 여러 번 재사용하고 싶다.

반대로 아직 노트가 몇 개 없고, 폴더 구조와 기록 습관도 정해지지 않았다면 먼저 Markdown으로 꾸준히 기록하는 것이 우선입니다. Knap은 정리되지 않은 지식을 자동으로 좋은 지식으로 바꾸는 도구가 아닙니다. 반복되는 좋은 규칙을 자동으로 지켜 주는 도구입니다.

시작하는 가장 작은 실험

처음부터 전체 볼트에 적용하지 마십시오. 다음 한 가지 실험이면 충분합니다.

1. 웹 자료 10개를 선정합니다.
2. 제목·출처·날짜·요약·태그만 포함한 Knap 템플릿을 만듭니다.
3. 기존 자료와 새 템플릿 자료를 각각 검색해 봅니다.
4. LLM에게 “청년 사역 관련 자료를 출처와 함께 정리해 달라”고 요청합니다.
5. 어느 쪽이 더 빠르고 정확한지 비교합니다.

이때 측정할 것은 AI의 말솜씨가 아닙니다.

• 원하는 자료를 찾는 데 걸린 시간
• 출처가 빠진 답변의 수
• 중복 자료와 무관한 자료의 수
• 사람이 다시 확인해야 하는 범위
• 한 달 뒤에도 구조를 유지할 수 있는지

이 다섯 가지를 보면 Knap이 우리 Wiki에 실제로 도움이 되는지 판단할 수 있습니다.

결론: Knap은 지식을 대신 만드는 도구가 아니라, 지식이 이어지게 하는 규칙이다

옵시디언은 파일을 내 컴퓨터에 남겨 줍니다. LLM Wiki는 그 파일을 서로 연결하고 질문할 수 있게 만듭니다. Knap은 그 사이에서 자료가 일정한 모양으로 들어오고 나가도록 돕습니다.

이렇게 바뀝니다.

• 스크랩은 단순 저장에서 출처가 있는 지식의 원재료가 됩니다.
• 인덱스는 파일 목록에서 질문을 시작하는 지도로 바뀝니다.
• 검색은 단어 찾기에서 주제·유형·날짜·검토 상태를 함께 보는 탐색이 됩니다.
• 목회 자료는 개인의 기억에서 팀이 이어받을 수 있는 공동 자산으로 바뀝니다.
• AI는 정리되지 않은 폴더를 추측하는 역할에서, 사람이 설계한 구조 안에서 돕는 역할로 이동합니다.

Knap을 도입한다고 해서 더 많은 자료를 모아야 하는 것은 아닙니다. 오히려 지금 모으는 자료가 다음 검색과 다음 설교, 다음 담당자와 다음 세대에게도 읽힐 수 있는 형태인지를 묻게 합니다.

그 질문에 답하면서 작은 템플릿 하나를 만들고, 자료 10개에 적용해 보십시오. 좋은 지식 시스템은 거대한 설정에서 시작하지 않습니다. 반복되는 한 가지 업무를 더 정확하고 오래 이어지게 만드는 작은 규칙에서 시작합니다.

참고 링크

• Knap 공식 홈페이지
• Knap 변수 문서
• Knap 필터 문서
• Knap 로직 문서
• Knap CLI 문서
• Knap API 문서
• Knap GitHub 저장소
• 옵시디언 Web Clipper
• 옵시디언과 목회자: 오래 쌓아 온 설교가 다시 말을 걸 때