LLM 지식 정리는 왜 두 번 나눠서 할까? (분석과 생성은 다른 일입니다)

문서 하나를 LLM에게 건네고 곧바로 위키 페이지를 만들게 할 수 있습니다. 그런데 그 결과가 출처를 따라갈 수 있는 지식인지, 기존 페이지와 충돌하는 대목을 알아챘는지, 빠진 핵심을 놓치지 않았는지는 다른 문제입니다. 문장을 잘 쓰는 일과 자료를 이해해 구조를 잡는 일은 같은 버튼 하나에 넣기엔 성격이 꽤 다르거든요.

llm_wiki의 README는 이 지점을 두 단계 Chain-of-Thought Ingest로 나눕니다. 먼저 문서를 분석하고, 그 분석을 바탕으로 위키 파일을 생성합니다. 이름이 조금 거창해 보이지만 (LLM 이름표에는 원래 긴 단어가 잘 붙습니다), 핵심은 아주 평범합니다. 요리사가 재료를 손질하면서 동시에 접시에 담으려 하면 결국 파와 접시가 함께 흔들리는 것처럼, 이해와 작성을 분리하자는 이야기입니다.

한 번에 읽고 쓰면 무엇이 섞일까?

단일 단계 흐름에서는 모델이 원문을 읽는 동시에 “무엇이 중요한가”, “기존 지식과 어떻게 이어지는가”, “어떤 파일로 나눌까”, “문장을 어떻게 만들까”를 모두 처리합니다. 작은 메모 하나라면 괜찮아 보일 수 있습니다. 이 방식에서는 여러 판단과 본문 생성이 하나의 흐름 안에서 일어납니다.

예를 들어 어떤 문서에 개념 A와 개념 B가 함께 등장한다고 해 보겠습니다. 한 번에 결과물을 만들면 A와 B를 별도 페이지로 둘지, 이미 있는 페이지와 연결할지, 둘 사이에 모순이 있는지 살피는 판단이 본문 작성 속에 묻히기 쉽습니다. 생성된 문장이 자연스럽다는 사실은 그 판단이 충분했다는 증거가 아닙니다. 이 차이가 처음에는 좀 헷갈립니다. “잘 요약했는데 왜 다시 분석하지?”라는 질문이 나오죠. 바로 그 “다시”가 아니라, 먼저 분석하고 나중에 쓴다는 순서가 설계의 중심입니다.

README는 원래의 추상적인 LLM Wiki 패턴이 원문을 읽고 쓰는 단일 흐름을 설명한다고 소개하고, 이 구현은 이를 두 번의 순차적인 LLM 호출로 분리한다고 적습니다. README는 이 분리가 더 나은 품질을 위한 설계라고 설명합니다. 다만 비교 실험이나 수치가 함께 제시된 것은 아니므로, 여기서 “항상 몇 배 좋아진다” 같은 결론까지 만들 필요는 없습니다. 그보다 어떤 판단을 먼저 꺼내 놓게 하는가를 보는 편이 정확합니다.

1단계: 문장을 쓰기 전에 지도부터 그립니다

첫 번째 단계는 구조화된 분석입니다. 모델은 원문을 읽고 곧바로 위키 문장을 완성하는 대신, 다음처럼 정리할 재료를 뽑습니다.

• 핵심 엔터티와 개념
• 문서의 주장과 논거
• 기존 위키 콘텐츠와의 연결점
• 기존 지식과의 모순 또는 긴장
• 위키 구조에 관한 제안

여기서 중요한 점은 아직 “보기 좋은 페이지”를 만들지 않는다는 것입니다. 분석 결과는 문서를 어떤 조각으로 나눌지 결정하기 위한 작업대입니다. 독자라면 이 단계를 메모장에 질문을 적어 두는 일로 생각해 보셔도 좋습니다. “이 문서의 주장은 무엇인가?”, “이미 아는 것과 부딪히는가?”, “나중에 다시 원문을 찾을 수 있는가?” 같은 질문을 먼저 적으면, 정리할 때 덜 흔들립니다.

아주 작게 쓰면 흐름은 이렇습니다.

원문 문서
  -> 1단계: 엔터티·개념·주장·연결·모순을 구조화해 분석
  -> 분석 결과
  -> 2단계: 분석 결과를 바탕으로 위키 산출물 생성

이 흐름에서 분석은 최종 독자를 위한 글이 아닙니다. 생성 단계가 무엇을 놓치지 말아야 하는지 알려 주는 작업 명세에 가깝습니다. 모델에게 “생각도 하고, 글도 쓰고, 파일 구조도 알아서 해”라고 한꺼번에 부탁하는 대신, 먼저 판단 재료를 분리해 주는 셈입니다.

2단계: 분석을 페이지와 연결로 바꿉니다

두 번째 단계는 첫 단계의 분석을 받아 실제 위키 산출물을 만듭니다. README에 따르면 여기에는 원문 요약 페이지, 엔터티·개념 페이지, 페이지 사이의 교차 참조, 그리고 index.md, log.md, overview.md 갱신이 포함될 수 있습니다. 사람의 판단이 필요한 항목은 비동기 검토 항목으로 만들고, Deep Research에 쓸 검색 질의도 함께 준비합니다.

이때 원문 요약 페이지는 단순한 부록이 아닙니다. README는 모델이 누락하더라도 대체 경로를 통해 원문 요약 페이지가 항상 생성되도록 한다고 설명합니다. 또 생성된 위키 페이지의 YAML frontmatter에는 원문을 가리키는 sources: [] 필드가 들어간다고 안내합니다. 즉, 페이지를 많이 만드는 것만이 목표가 아니라 “이 페이지가 어느 원문에서 왔는가”를 남기는 것이 설계에 들어 있습니다.

물론 페이지 수준의 출처 연결이 곧 모든 문장의 사실성을 자동 보증한다는 뜻은 아닙니다. 문장 하나의 근거까지 확인하려면 사람이 원문으로 돌아가 점검해야 할 수 있습니다. 그래도 결과물에 출처 경로를 남겨 두면, 검토자가 막연히 기억을 더듬는 대신 확인할 출발점을 갖게 됩니다. 추적 가능성은 정답 판정기가 아니라, 다시 확인할 수 있게 만드는 손잡이입니다.

실무에서는 무엇을 가져오면 좋을까?

꼭 위키 프로그램을 만들지 않아도 이 생각은 유용합니다. 문서를 읽고 결과물을 만드는 자동화가 있다면, 다음 네 가지를 분리해서 적어 보세요.

• 분석 단계가 무엇을 반드시 찾아야 하는가
• 생성 단계가 어떤 분석 결과만 받아 쓰는가
• 결과물에서 원문으로 돌아가는 경로가 있는가
• 확신이 부족한 판단을 즉시 확정하지 않고 남겨 둘 자리가 있는가

예를 들어 회의록을 정리한다면 1단계는 결정 사항, 미결 사항, 담당자, 충돌하는 진술을 추출하는 단계가 될 수 있습니다. 2단계는 그 결과를 회의록·할 일·질문 목록으로 나누는 단계가 됩니다. 그냥 한 번에 “회의록 예쁘게 써 줘”라고 하는 것보다, 나중에 빠진 결정을 찾아내기 쉬워집니다.

여기서 주의할 점도 있습니다. 단계를 둘로 나누었다고 자동으로 신뢰할 수 있는 것은 아닙니다. 첫 분석이 틀릴 수도 있고, 두 번째 생성이 분석을 잘못 해석할 수도 있습니다. 그래서 원문 연결과 검토 자리가 함께 필요합니다. 분석은 책임을 없애는 마법이 아니라, 책임 있게 확인할 대상을 선명하게 해 주는 장치입니다 (마법 지팡이는 아직 배포되지 않았습니다).

정리: “한 번 더”가 아니라 “다른 일을” 시키는 것입니다

두 단계 ingest의 포인트는 LLM을 두 번 부르는 데 있지 않습니다. 첫 호출에는 증거를 구조화하는 일, 두 번째 호출에는 구조를 위키로 표현하는 일을 맡긴다는 데 있습니다. 그사이에 분석 결과를 거치고 최종 페이지에는 출처 경로가 남으므로, 사람은 결과를 읽고 의심하고 고칠 단서를 얻습니다.

다음에 “이 문서 좀 정리해 줘”라는 자동화를 만들 때, 출력 형식만 먼저 정하지 말아 보세요. 먼저 무엇을 확인해야 하는지 적고, 그다음 무엇을 만들지 정해 보세요. 한 접시에 다 올리는 속도보다, 재료가 어디서 왔는지 아는 정리가 오래 갑니다.