llm-wiki-test1을 통해 3단계 지식체계론 구현 검증(2)

여기서 내가 궁금한 사항이 있어. 너는 세종대왕 관련 문서에서 claim의 유형을 fact와 interpretation으로 구분했어. 그렇다면 8개의 claim 중에서 4개가 fact(historical fact 포함)이고 4개가 interpretation인데, 3단계 지식체계론을 각각의 claim에 어떻게 적용했는지는 내가 모르겠어. 똑같이 strict로 적용했는지, 아니면 일부는 weak로 적용했는지, 아니면 적용하지 않은 것이 있는지를 모르겠어. 그리고 지금 interpretation 4개 중에 2개는 weak confirmability로 분류됐는데, 그 근거가 무엇인지 내가 알 수가 없어. 그리고 weak confirmability로 분류한 claim조차 3단계 지식체계론에서 typicality, coherence가 모두 어떻게 평가된 것인지를 알 수가 없어. 3단계 지식체계론은 순차적인 검증 단계를 거치도록 되어 있어. 그래서 1단계와 2단계를 거쳐야 해. 그런데 weak confirmability로 분류됐음에도 1단계인 typicality와 2단계인 coherence가 어떤 상태인지 알지 못한다는 것은 문제가 있는 것 같아. 이에 대해 설명해주고 개선 방안을 마련해줘

• 지적이 맞습니다. 현재 기록은 confirmability 결과만 눈에 띄고, 각 claim이 1단계 지식요건해당성과 2단계 정합성을 어떻게 통과했는지 추적하기 어렵습니다. 관련 문서를 확인한 뒤, claim별 3단계 판정표가 남도록 고치겠습니다.

• 개선은 세 갈래로 하겠습니다. 첫째, SRC-010의 8개 claim마다 typicality -> coherence -> confirmability -> answer_policy를 표로 남깁니다. 둘째, weak/contradiction register도 1·2단계 판정 없이 3단계만 적는 형태를 금지합니다. 셋째, schema에 “확증가능성만 단독 기록하지 말라”는 규칙을 추가합니다.

• 맞습니다. 이전 처리는 불완전했습니다.        
  문제는 두 가지였습니다. 첫째, SRC-010 전체 문서에는 knowledge_review: strict를 달았지만, 8개 claim 각각에 대해 typicality -> coherence -> confirmability가 어떻게 통과/탈락했는지 남기지 않았습니다. 둘째, weak-confirmability-register.md에는 confirmability만 기록하고 1단계·2단계를 생략했습니다. 3단계 지식체계론의 취지상 이건 추적성이 부족합니다.
  
개선해서 반영했습니다.

이제 세종대왕.md의 8개 claim은 모두 아래 순서로 표시됩니다.
claim -> type -> typicality -> coherence -> confirmability -> answer_policy -> reason
정리하면:
  - 8개 claim 모두 3단계 검토를 적용했습니다.                     
  - interpretation 4개도 1단계와 2단계를 거친 뒤 weak로 분류했습니다. 
  - weak의 근거는 “claim 단위로는 성립하지만, 평가 기준·독립 근거·검증 가능성이 부족하다”입니다.                            
  - “아이패드”와 “단종의 아버지” claim은 typicality: pass지만 coherence: rejected, confirmability: none, answer_policy: do_not_assert로 명시했습니다.
  - “조선의 제4대 왕”, “한글 창제”는 현재 wiki 내부에서는 SRC-010 단일 근거만 있으므로 moderate/qualify로 낮췄습니다. 공식 출처를 ingest하면 strong/assert_with_citation으로 올릴 수 있습니다. 

  또 schema에도 규칙을 추가했습니다. 
  
  confirmability는 typicality와 coherence 없이 단독 기록하지 않는다.
  
  검증 결과도 통과했습니다.
  - index 링크 누락 없음
  - Source ID 미등록 참조 없음
  - wiki frontmatter 누락 없음
  - schema 밖 coherence 값 잔존 없음

weak-sejong-001:
  claim: "세종대왕은 잘 생겼다."
  confirmability: weak
  answer_policy: mention_as_view
  reason: 주관적 외모 평가이며 근거와 판단 기준이 없다.

weak-sejong-002:
  claim: "모든 한국 사람들은 세종대왕을 추앙해야 한다."
  confirmability: weak
  answer_policy: mention_as_view
  reason: 규범적·과잉 일반화 주장이다.

conflict-sejong-001:
  new_claim: "세종대왕은 아이패드를 집어던지셨다."
  coherence: rejected
  confirmability: none
  answer_policy: do_not_assert

conflict-sejong-002:
  new_claim: "세종대왕은 단종의 아버지이다."
  coherence: rejected
  confirmability: none
  answer_policy: do_not_assert

claim -> type -> typicality -> coherence -> confirmability -> answer_policy -> reason

그렇다면, 이전의 내용은 어디에 있어? 새로운 schema에 따라서 3단계 지식체계론을 적용하기로 한 것은 좋은데, 이렇게 이전의 문서를 완전히 지우고 다시 새로운 내용으로 대체해버리면 해당 claim에 대한 개정 이력이 추적되지 않는 문제가 있는데 이에 대해 너는 어떻게 생각해?

• 맞습니다. 방금 제 수정은 “현재 문서의 정확성”은 올렸지만, “왜 이전 판단을 폐기하고 새 판단으로 바꿨는지”를 별도 이력으로 남기지 않았습니다. Git을 아직 보류한 상태라면 이런 개정 이력은 위키 내부 register로 반드시 남겨야 합니다.

• 그래서 지금 바로 개정 이력 register를 추가하겠습니다. 특히 방금 바꾼 SRC-010의 이전 판단표를 “폐기된 내용”이 아니라       
  “superseded review”로 보존하고, 앞으로 중요한 claim review를 바꿀 때는 새 내용으로 덮어쓰기 전에 이력을 남기도록 schema에 
  규칙을 넣겠습니다.                                       
  
• 동의합니다. 지금 방식에는 실제로 문제가 있었습니다.
  제가 한 일은 “현재 문서를 더 나은 schema에 맞게 고친 것”이지만, 그 과정에서 이전 판단표가 본문에서 사라졌습니다. Git을 아직 도입하지 않은 상태라면, 이렇게 덮어쓰는 방식은 지식의 개정 이력을 잃게 만듭니다. 특히 claim review는 “왜 이전 판단이 부족했고, 어떤 기준으로 새 판단이 채택됐는지”가 지식 자체의 일부라서 반드시 남겨야 합니다.
  그래서 바로 보완했습니다.
  추가한 문서:
  - llm-wiki/wiki/reviews/revision-history.md
  여기에 SRC-010 세종대왕 claim review의 이전 상태를 보존했습니다. 즉, 이전의 축약된 Candidate Claims 표, 이전 concept 문서의 Claim 처리 표, 이전 weak register/contradiction register의 부족했던 형태를 previous_state로 남겼고, 새 판단표를 new_state로 기록했습니다.
  또 schema에도 규칙을 추가했습니다.
  - llm-wiki/schema/lint-checklist.md: 중요한 claim review 변경에 revision history가 있는지 점검하도록 추가

  앞으로 원칙은 이렇게 잡았습니다.
  그 다음:
    본문 문서를 새 판단으로 갱신
  log.md:
    요약만 기록
  revision-history.md:
    이전 상태, 새 상태, 변경 이유, 영향 파일을 상세 기록
  검증도 완료했습니다.
  - index 링크 누락 없음
  - Source ID 미등록 참조 없음
  - wiki frontmatter 누락 없음

› revision history를 남기는 것은 좋은데, wiki 문서의 양이 많아지면 revision도 많이 발생할 것이고, 그렇게 되면 revision history 문서의 양도 늘어날 것인데, 그러면 revision을 추적하기가 어려워지지 않아? 이것을 revision-history 폴더를 따로 만들어서 개별 문서에 대한 revision history를 별도로 만드는 것이 나을까? 아니면 지금 방식대로 하나의 revision-history.md에 저장하는 것이 나을까?

나는 하이브리드 방식이 맞다고 봅니다.

지금처럼 revision-history.md 하나에 계속 쌓는 방식은 MVP 초기에는 좋지만, 문서가 많아지면 금방 한계가 옵니다. 반대로 문서별 revision만 두면 “최근에 전체적으로 뭐가 바뀌었는지”를 보기 어렵습니다.

추천 구조는 이겁니다. 
 
 wiki/ 
	 reviews/ 
		 revision-index.md # 전체 revision의 시간순 색인 
		 revisions/ 
			 SRC-010-sejong-the-great.md # 세종대왕 claim review 전용 이력 
			 schema-knowledge-admission.md 
			 concept-llm-wiki.md 
 
 역할 분리: 
 
 revision-index.md 
 = 전체 변경의 목차 
 = 언제, 무엇이, 왜 바뀌었는지만 짧게 기록 
 
 revisions/*.md 
 = 개별 문서/Source/claim group의 상세 개정 이력 
 = previous_state, new_state, reason, affected_files 보존 
 
 예를 들면 revision-index.md에는 이렇게만 둡니다. 
 
 ## [2026-05-31] rev-src-010-claim-review-matrix 
 
 - target: SRC-010 세종대왕 claim review 
 - detail: [[wiki/reviews/revisions/SRC-010-sejong-the-great]] 
 - reason: claim별 3단계 검증 이력 누락 보완 
 
 상세 내용은 별도 파일에 둡니다. 
 
 wiki/reviews/revisions/SRC-010-sejong-the-great.md 
 
 이 방식의 장점은 명확합니다. 
 
 - 특정 문서의 개정 이력을 추적하기 쉽다. 
 - 전체 변경 흐름도 revision-index.md에서 볼 수 있다.
 - revision-history.md 하나가 비대해지는 문제를 피한다. 
 - Git 도입 전에도 문서 단위 audit trail을 만들 수 있다. 
 - 나중에 Git을 도입해도 이 구조는 그대로 의미가 있다. 
 
 운영 규칙은 이렇게 잡으면 됩니다. 
 
 오탈자, 링크 수정: 
	 log.md에만 기록하거나 생략 가능 
 
 중요 claim review 변경: 
	 revision-index.md에 1줄 기록 
	 wiki/reviews/revisions/{target}.md에 상세 기록 
 
 schema 변경: 
	 revision-index.md에 1줄 기록 
	 wiki/reviews/revisions/schema-{name}.md에 상세 기록 
 
 canonical 문서 변경: 
	 revision-index.md에 1줄 기록 
	 wiki/reviews/revisions/concept-{name}.md에 상세 기록 
 
 결론적으로, 지금의 단일 revision-history.md는 임시로는 괜찮지만 장기 구조로는 부족합니다. 이 시점에서 revision-index.md + revisions/개별 파일 구조로 바꾸는 것이 더 낫습니다. 

› 이러면 문서의 이력 관리는 철저하게 되겠지만, 문서가 비대해지고 검색할 때 토큰 소모량이 많아지지는 않을까?

• 맞습니다. 이력 관리를 너무 철저하게 하면 위키가 “지식 저장소”가 아니라 “감사 로그 저장소”처럼 비대해질 수 있습니다. 검색·Query 때도 불필요한 revision 문서가 같이 읽히면 토큰 낭비가 큽니다. 

 그래서 핵심은 revision을 남기되 기본 검색/답변 경로에서는 제외하는 것입니다. 
 
 추천 구조는 이렇게 조정하는 게 좋습니다. 
 
 wiki/ 
	 concepts/ 
	 workflows/ 
	 source-summaries/ 
	 reviews/ 
		 revision-index.md       # 얇은 색인만 기본 참조 가능 
		 revisions/              # 상세 이력. 기본 query 제외 
			 SRC-010-sejong.md 
			 schema-knowledge-admission.md 
 
 운영 규칙: 
 
 일반 Query: 
	 index.md 
	 관련 wiki 문서 
	 source summary 
	 필요 시 review register 일부 
 
 Revision 추적 Query: 
	 revision-index.md 
	 필요한 revisions/{target}.md만 읽기 
 
 즉, revisions/는 기본 지식 검색 대상이 아니라 audit/archive 영역으로 둡니다. 
 
 frontmatter로도 명확히 표시하면 좋습니다. 
 
 --- 
 type: revision-history 
 status: archived 
 search_scope: audit_only 
 default_query: false 
 summary_l0: "SRC-010 claim review 개정 이력" 
 summary_l1: "세종대왕 claim 검토표의 이전 상태와 새 상태를 보존한 감사용 문서" 
 source_refs: 
 - SRC-010 
 tags: [revision, audit] 
 --- 
 
 그리고 AGENTS.md에는 이렇게 넣는 게 좋습니다. 
 
 일반 질문에 답할 때는 `wiki/reviews/revisions/`를 읽지 않는다. 
 사용자가 "이력", "왜 바뀌었어?", "이전 판단", "revision", "audit"을 묻는 경우에만 revision 문서를 읽는다. 
 
 결론은 이겁니다. 
 
 상세 revision은 남긴다. 
 하지만 기본 query path에서는 제외한다. 
 index에는 얇은 revision 색인만 둔다. 
 상세 이력은 사용자가 이력을 물을 때만 읽는다. 
 
 이렇게 하면 추적성과 토큰 효율을 둘 다 잡을 수 있습니다. 

 핵심 원칙               
                
 revision은 일반 wiki 본문을 비대하게 만들지 않고, 감사가 필요할 때만 읽는 별도 이력 계층으로 관리한다. 각 개정 entry는 단순 요약이 아니라 “그 개정으로 실제 무엇이 되었는지”를 재구성할 수 있을 만큼 구체적인 new_state를 남긴다.   
                
 저장 위치               
                
 wiki/reviews/revision-index.md            
 wiki/reviews/revisions/{target-id-or-slug}.md          
                
 revision-index.md는 전체 이력의 얇은 색인이다. 날짜, 대상 문서, 변경 유형, 상세 revision 문서 링크만 둔다.  
                
 wiki/reviews/revisions/는 개별 문서별 상세 이력 저장소다. 예를 들면:       

 wiki/reviews/revisions/SRC-010-sejong-the-great.md         
                
 읽기 정책               
                
 일반 질문에 답할 때는 기본적으로 읽지 않는다.          
                
 default_query: false             
 search_scope: audit_only             
                
 다만 사용자가 아래와 같은 의도를 보이면 읽는다.          
                
 이력               
 왜 바뀌었어?              
 이전 판단               
 이전 내용               
 revision               
 audit               
 개정               
 변경 근거               
                
 상세 revision 문서 구조
                
 개별 revision 문서는 역순 연대기 방식이다.          
                
 가장 최근 revision             
 그 이전 revision              
 더 이전 revision              
 초기 상태 또는 최초 등록 상태            
                
 즉 최신 변경이 항상 맨 위에 온다. 새 개정이 발생해도 별도 파일을 계속 만드는 것이 아니라, 같은 대상 문서의 revision 파일 맨 위에 새 entry를 추가한다.            
                
 Entry 기본 형식              
                
 ## 2026-05-31 - Revision Title            
                
 ### change_summary             
                
 무엇이 바뀌었는지 요약한다.            
                
 ### reason              

 왜 바꾸었는지 기록한다.             
                
 ### new_state              
                
 이 개정 후 실제 상태를 구체적으로 기록한다.          
 claim review라면 실제 claim 판정표를 넣는다.          
                
 ### affected_files             
                
 - `path/to/file.md`             
                
 ### migration_note             
                
 이전 내용이 어떻게 보존되는지, 앞으로 어떻게 읽어야 하는지 적는다.       
                
 중요한 점은 new_state가 “요약”만이면 안 된다는 것이다. 예를 들어 claim review를 바꿨다면 다음 수준까지 들어가야 한다. 
                
 claim -> type -> typicality -> coherence -> confirmability -> answer_policy -> reason     
                
 중복 방지 원칙              
                
 이전 entry의 new_state를 다음 entry에서 그대로 반복하지 않는다. 대신 새 entry는 “이번 개정 후 상태”를 구체적으로 남긴다. 
 시간이 지나면 각 entry의 new_state가 그 시점의 스냅샷 역할을 한다.       
                
 즉 구조는 이렇게 된다.             
                
 현재 최신 본문:              
 wiki/source-summaries/SRC-010-sejong-the-great.md          

 이력:               
 wiki/reviews/revisions/SRC-010-sejong-the-great.md         
 - Revision 3: 개정 후 실제 상태            
 - Revision 2: 개정 후 실제 상태            
 - Revision 1: 최초 개정 후 실제 상태           
 - Initial State: 최초 상태            
                
 이 방식이면 일반 검색 토큰은 줄이고, 필요할 때는 문서별로 충분히 상세한 변경 이력을 추적할 수 있다.