LLM Wiki 초기 운영 중 발견한 문제점

기쁜 마음으로 llm wiki의 20.wiki 폴더를 obsidian으로 열어서 하나하나 살펴보던 중 문제를 발견했다.

첫 번째 문제 - 문서 생성 이유의 일률적 오류(?)

나는 schema에 "본 문서 생성 이유"라는 란을 두어 문서를 생성한 이유를 적어두도록 지시했다. 왜냐하면 왜 이러한 문서가 만들어졌는지를 알아야 해당 문서에 대한 이해도가 높아질 것이라고 생각했기 때문이다.

그런데, 20.Wiki 폴더에 있는 문서들은 하나같이 모두 다음과 같은 "본 문서 생성 이유"로 되어 있었다.

본 문서 생성 이유

이 문서는 $name 내용을 LLM Wiki에서 일관되게 참조하고 재사용하기 위해 생성했다.

이러면 아무런 의미가 없다. 사실 틀린 말은 아니다. 그런데 "$name 내용"이라는 식으로 되어 있는데, 그마저도 뭔가 불완전한 것이었다.

10.Sources 폴더 내의 문서들을 열어봤다. 여기에는 별다른 수정사항이 없어야 했기에 "본 문서 생성 이유"와 같은 내용도 없었다.

그런데 다른 폴더의 문서에는 실제로 "문서 생성 이유"가 제대로 적혀있는 문서가 있었다. 그렇다면 아예 잘못 작동하는 것은 아닐 것인데, 이게 앞으로 계속해서 어떻게 작동할 것인지는 좀 지켜봐야 할 것 같다.

두 번째 문제 - 원천자료의 형식 문제

다음으로 문제는 raw 파일이 md 파일인 경우에는 해당 내용이 wiki로 잘 편입되지만, 동영상 파일이나 음성파일, PDF파일이나 이미지 파일인 경우에는 어떡할지였다. 물론 원본은 자료 그대로 보존해야 하겠지만 이것을 md파일로 변환해야 유의미한 정보가 될 것인데, 굳이 모든 자료를 그렇게 해야할지 아니면 필요한 자료만 수동으로 md화하여 적용할 것인지는 숙제로 남겨두었다.

세 번째 문제 - 원문의 역링크 문제

raw material을 ingest하면 그것이 sources에 메타데이터를 달고 저장되고, 필요한 사항은 wiki로 작성되는 것은 좋은데, 원문에는 그 원문이 어떤 wiki를 만드는 데에 쓰였는지, 아니면 어떤 산출물에 연결되는지에 대한 내용은 없다. 적어도 원문이 어디에 기여했는지를 아는 것은 유의미한 정보가 될 수 있지 않을까?

이것은 초창기에 빨리 원칙을 세워서 적용해야 할 것이기 때문에 이 부분을 그대로 codex에게 물어보았다.

그러자 다음과 같은 답이 나왔다.

맞아요. 그건 꽤 유의미한 정보입니다. 지금 구조는 산출물 -> source_refs -> 원문 방향 추적은 되는데, 반대로 원문 -> 어디에 쓰였나가 약합니다.

다만 raw 원문 자체를 수정하는 방식은 피하는 게 좋고, 원문 주변의 메타데이터에 “기여 이력”을 붙이는 게 좋아 보입니다.

추천 구조는 이렇습니다.

source_refs:
  - SRC-001

이건 지금처럼 산출물 쪽에 유지하고,

used_by:
  wiki:
    - 20.Wiki/02.Concepts/llm-wiki-harness-engineering-relationship.md
  artifacts:
    - 40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md

같은 역방향 정보는 10.Sources/source-index.md나 20.Wiki/01.Sources/SRC-###... 요약 문서에 두는 게 좋습니다.

제가 보기엔 가장 현실적인 방식은:

1. source_refs는 모든 wiki/산출물 frontmatter에 계속 둔다.

2. 10.Sources/source-index.md에는 너무 길어지지 않게 Used By 대신 Usage 또는 Impact 열을 추가한다.

3. 자세한 역방향 목록은 별도 문서 10.Sources/source-usage-index.md로 생성한다.

4. lint 때 “산출물의 source_refs와 source usage index가 서로 맞는지” 점검한다.

예를 들면 현재 열린 글은 이런 연결을 만들어야 합니다.

SRC-001, SRC-003, SRC-013, SRC-042, SRC-045, SRC-053, SRC-055
-> 40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md

이렇게 하면 Source ID가 단순 출처 목록이 아니라 “이 자료가 어떤 지식/산출물을 낳았는지”를 보여주는 provenance map이 됩니다. 특히 나중에 원문을 갱신하거나 삭제 후보를 판단할 때 엄청 유용해져요.

이렇게 답변을 받은 나는 다시 물어봤다.

이 규칙을 적용했을 때의 예시를 보여줘

그러자 codex는 다음의 예시를 보여줬다.

예를 들면 현재 열린 문서 기준으로는 이렇게 됩니다.

40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md는 지금 이미 정방향 출처를 갖고 있습니다.

source_refs:
  - SRC-001
  - SRC-003
  - SRC-013
  - SRC-042
  - SRC-045
  - SRC-053
  - SRC-055

여기에 역방향 추적을 적용하면, 각 Source 쪽에는 이런 정보가 생깁니다.

## 기여한 문서

- [[40.Projects/02.GPTers Case Posts/01-llm-wiki-build|AI에게 매번 설명하지 않으려고, Obsidian에 개인용 LLM Wiki를 만들었습니다]]
  - 기여 방식: LLM Wiki 개념 설명, Source ID 구조, ingest 운영 흐름 설명에 사용됨
  - 산출물 유형: GPTers 게시용 글
  - 반영일: 2026-05-25

예를 들어 SRC-042 요약 문서에 붙이면 이런 느낌입니다.

---
type: source_summary
source_id: SRC-042
status: linked
source_refs: []
used_by:
  artifacts:
    - "40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md"
  wiki: []
---

본문에는 이렇게 적습니다.

## 기여한 문서

- [[40.Projects/02.GPTers Case Posts/01-llm-wiki-build]]
  - 초보자용 LLM Wiki 설명 문단의 근거로 사용됨
  - 원문을 그대로 옮긴 것이 아니라, 게시용 글에 맞게 재구성됨

그리고 중앙 인덱스를 만들면 더 보기 쉬워집니다.

핵심은 이렇게 됩니다.

산출물에는 source_refs로 "무엇을 근거로 만들었는지"를 남긴다.
Source 쪽에는 used_by 또는 usage index로 "내가 어디에 쓰였는지"를 남긴다.
원문 파일 자체는 수정하지 않는다.

이렇게 하면 SRC-042를 봤을 때 “아, 이 자료가 단순히 요약만 된 게 아니라 GPTers 게시글에도 기여했구나”를 바로 알 수 있습니다.

그래서 이것은 나에게 유용한 정보가 될 것으로 생각됐다. 적용하기로 결정했다.

그런데, yaml frontmatter에 표시된 src-xxx로 연결된 문서들은 링크가 됐는지, 가능한지 궁금했다.
이게 문서 내에서 링크가 돼 있어야 의미가 있을 것 같았다. 그런데 frontmatter도 링크가 되는지 그것도 궁금했다.

그래서 물어봤다.

여기에 대한 답변은 다음과 같았다.

네. 핵심만 말하면:

source_refs: - SRC-001은 링크가 아닙니다. 그냥 문자열이에요.

Obsidian에서 frontmatter/properties 안에도 링크는 가능합니다. 공식 문서 기준으로 텍스트/리스트 property에는 Internal link를 넣을 수 있고, YAML에서는 따옴표로 감싸야 합니다. 또 Obsidian Bases의 file.links는 frontmatter 안의 링크도 포함한다고 설명합니다.

그래서 현재 방식은:

source_refs:
  - SRC-001
  - SRC-042

Obsidian 링크가 아니라 “기계가 읽기 좋은 Source ID 목록”입니다.

링크로 만들려면 이렇게 해야 합니다.

source_refs:
  - "[[20.Wiki/01.Sources/SRC-001_llm-wiki|SRC-001]]"
  - "[[20.Wiki/01.Sources/SRC-042_inbox-llm-wiki-teaching-note-review|SRC-042]]"

다만 저는 이 위키에는 아래처럼 ID 필드와 링크 필드를 분리하는 방식이 제일 좋아 보입니다.

source_refs:
  - SRC-001
  - SRC-042
source_links:
  - "[[20.Wiki/01.Sources/SRC-001_llm-wiki|SRC-001]]"
  - "[[20.Wiki/01.Sources/SRC-042_inbox-llm-wiki-teaching-note-review|SRC-042]]"

이러면 source_refs는 lint/검색/자동 처리용으로 안정적이고, source_links는 Obsidian에서 클릭 가능한 링크가 됩니다.

그리고 사람이 읽는 문서 본문에도 한 번 더 두면 가장 좋습니다.

## 근거 Source

- [[20.Wiki/01.Sources/SRC-001_llm-wiki|SRC-001]]: LLM Wiki 원문 아이디어
- [[20.Wiki/01.Sources/SRC-042_inbox-llm-wiki-teaching-note-review|SRC-042]]: 초보자용 LLM Wiki 설명 초안

정리하면: frontmatter 링크는 가능하지만, 현재 SRC-xxx만 적은 것은 링크가 아닙니다. 운영상으로는 source_refs는 ID로 유지하고, source_links나 본문 근거 Source 섹션에 실제 Obsidian 링크를 두는 게 제일 균형이 좋아요.

결국 이것은 내가 결정해야 할 문제로 남게 되었다. 따라서 아직 본격적으로 문서들을 ingest하기 전에 이 규칙을 어떻게 할 것일지를 결정해야 한다. 그래서 다음 시간에는 다른 사람들이 만들어놓은 llm wiki 제작 규칙을 살펴보고 나의 규칙과 비교해보기로 했다.

네 번째 문제

각 schema의 적용 범위를 어떻게 설정할지이다. 전역/지역으로 구분될 수 있는데, 이 구분을 결국 내가 해야 할텐데 나도 사실 확신을 하지 못하는 문제가 있어서 이 구분을 계속 미루고 있다. 또한 마음 한 편으로는 '과연 이 구분이 필요할까?'라는 의문이 떠나지 않고 있기 때문에 주저하는 것도 있다.

위의 내용을 프롬프트로 해서 그대로 codex에게 물었더니 다음과 같은 답변이 나왔다.

그 주저는 꽤 건강한 신호라고 봅니다. 지금 단계에서 전역/지역 schema를 너무 빨리 나누면, 위키가 “쓰기 위한 도구”가 아니라 “규칙을 관리하기 위한 도구”가 될 수 있어요.

제 추천은 이겁니다.

전역/지역을 먼저 완벽히 나누지 말고, “기본값 + 예외”로 시작하세요.

전역 schema = 모든 문서에 적용되는 최소 안전장치 
지역 schema = 특정 폴더/문서유형/워크플로우에서만 의미 있는 규칙

예를 들면:

더 정확히는 2단계보다 3단계가 좋아 보입니다.

1. Core Schema 
   위키 전체의 공통 생존 규칙 
2. Type Schema 
   document, transcript, artifact, workflow, decision 같은 type별 규칙 
3. Project/Folder Schema 
   뉴스레터, 법률강의, GPTers 사례글처럼 특정 작업 영역 규칙

판단 기준은 단순하게 잡으면 됩니다.

이 규칙을 어기면 위키 전체가 헷갈리는가? 
-> 전역 
이 규칙을 어겨도 특정 작업물만 이상해지는가? 
-> 지역 
아직 잘 모르겠는가? 
-> 전역으로 올리지 말고 "local/default 후보"로 둔다`

그리고 “이 구분이 필요한가?”에 대한 제 답은: 완벽한 구분은 필요 없고, 최소한의 구분은 필요합니다.

왜냐하면 source_refs, private, Source ID 같은 건 전역이어야 AI가 안정적으로 움직입니다. 반대로 뉴스레터 승인 단계나 GPTers 글쓰기 구조까지 전역으로 올리면, 다른 문서를 만들 때 불필요한 규칙이 계속 끼어들어요.

그래서 지금은 이렇게 정하면 좋겠습니다.

기본 원칙: 
새 규칙은 처음부터 전역으로 승격하지 않는다. 

1. 먼저 해당 문서나 workflow 안의 지역 규칙으로 둔다. 
2. 같은 규칙이 3개 이상의 문서 유형에서 반복되면 type schema로 올린다. 
3. 위키 전체의 안정성에 영향을 주면 core schema로 올린다.

한 줄로 줄이면:

Schema는 먼저 지역에서 태어나고, 반복되거나 위험해질 때 전역으로 승격된다.

이렇게 하면 지금처럼 확신이 부족한 상태에서도 결정을 미루는 게 아니라, “유보를 운영 방식으로 만든 것”이 됩니다.
이건 회피가 아니라 좋은 설계에 가까워요.

이러한 좋은 방안이 나왔다.

• 2단계(전역/지역)보다 3단계(전역/유형별/프로젝트, 폴더별)로 나누는 것이 좋다.

• Schema는 먼저 지역에서 태어나고, 반복되거나 위험해질 때 전역으로 승격된다.