LLM Wiki

Query 워크플로우

14 min read

요청하신 개념 ‘Query 워크플로우’(type: workflow)에 대한 위키 노드가 작성되었습니다.

작성된 위키 노드는 지정하신 frontmatter 스키마, 템플릿 구조, Obsidian 위키링크([[노트명]]), 소스 파일 인용 경로, 구체적인 예시 및 충돌 파트 원칙을 충실히 반영하여 제작되었습니다.

작성된 노트 내용 미리보기

---
type: workflow
status: draft
core: false
tags:
  - llm
  - agent
  - workflow
  - knowledge-management
  - obsidian
aliases:
  - Query Workflow
  - 질의 워크플로우
  - 쿼리 워크플로우
sources:
  - raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md
created: '2026-08-28'
updated: '2026-08-28'
---
 
# Query 워크플로우
 
## 한 줄 정의
 
Query 워크플로우는 사용자가 자연어로 질의를 던졌을 때 [[AI 에이전트]]가 원본 문서(`raw/`)를 일일이 재검색하는 대신 이미 컴파일된 [[LLM Wiki|지식 베이스(`wiki/`)]]와 마스터 인덱스([[Index]])를 탐색하여 최선·최신의 답변을 조합하고, 유용한 탐색 결과는 새로운 분석 노트([[Analysis Page]])로 위키 내에 영구 저장하는 선순환 질의 응답 파이프라인이다.
 
## 핵심 요지
 
- **위키 기반 집계 질의(Wiki-First Retrieval)**: 매 질의 시 원본 파일(`raw/`) 전체를 뒤지고 재추론하여 이전 대화 맥락을 휘발시키는 기존 AI 방식과 달리, 사전 구조화된 `wiki/` 폴더 내 마크다운 파일과 연결망을 먼저 읽어 답변을 합성한다 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).
- **지식베이스의 선순환 누적(Compounding Knowledge)**: 질의 과정을 통해 도출된 뛰어난 분석이나 리스크 정리 답변은 일회성 채팅에 머무르지 않고, 사용자의 승인을 거쳐 영구적인 [[Analysis Page|분석 페이지(`wiki/analysis/` 또는 `wiki/`)]]로 저장되어 위키의 깊이를 지속적으로 확장한다 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).
- **인덱스 탐색 중심의 경량성**: Vector Database나 Embedding 검색 엔진 없이도, AI 에이전트가 탐색 지도인 마스터 인덱스([[Index|`wiki/index.md`]])를 먼저 확인한 후 필요한 2차·3차 하위 노드로 좁혀 들어가 수백 페이지 규모의 지식망을 효율적으로 질의할 수 있다 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).
- **3대 에이전틱 작업 체계의 일원**: Ingest([[Ingest 워크플로우]]), Query, Lint([[Lint 워크플로우]])로 구성된 [[LLM Wiki]] 유지관리 파이프라인 중 지식의 추출·활용 및 영구화를 담당하는 핵심 절차이다 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).
 
## 상세
 
### 1. Query 워크플로우의 실행 메커니즘
 
Query 워크플로우는 `CLAUDE.md` 운영 규칙에 맞춰 에이전트(예: [[Cursor]], [[Claude Code]])가 다음과 같은 수순으로 처리한다 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md):
 
1. **마스터 인덱스 참조 (Read Index)**: 질의가 입력되면 AI는 가장 먼저 `wiki/index.md`를 조회하여 질문 관련 엔티티, 용어, 소스 요약 페이지의 링크 목록을 확보한다.
2. **관련 위키 노드 추적 (Traverse Wiki Pages)**: 인덱스 지도를 바탕으로 필요한 위키 페이지들(`wiki/overview.md`, `wiki/glossary.md`, 엔티티 노트 등)로 진입하여 상호 참조([[Obsidian|위키링크]])를 따라 맥락을 수집한다.
3. **종합 답변 생성 (Synthesize Answer)**: 수집된 위키 지식을 종합하여 원본 소스 간 구조화된 답변(예: 주요 리스크, 비교 분석, 스펙 요약 등)을 작성한다.
4. **분석 노트 저장 제안 (Persistence Prompt)**: 답변 작성 후 AI가 *"이 답변을 wiki 페이지로 저장할까요?"*와 같이 질의 결과를 영구 노드로 남길지 사용자에게 제안한다.
5. **지식 확장 및 인덱스 반영 (Save Analysis & Update Index)**: 사용자가 승인하면 해당 답변은 `wiki/` 내 영구적인 분석 노트(Analysis Page)로 생성되고, 동시에 `wiki/index.md` 및 `wiki/log.md`에 타임스탬프와 함께 기록된다.
 
### 2. 전통적인 Chat / Naive RAG 질의 방식과의 비교
 
| 비교 항목 | 전통적 AI Chat / Naive RAG 질의 | LLM Wiki Query 워크플로우 |
| :--- | :--- | :--- |
| **질의 대상** | `raw/` 원본 파일 청크 또는 전체 문맥 | 컴파일 및 교차 검증이 완료된 `wiki/` 지식망 |
| **메모리 및 연속성** | 세션 종료 시 이전 질의 추론 및 탐색 결과 휘발 | 탐색 결과가 [[Analysis Page]]로 위키에 영구 축적 |
| **탐색 방식** | 벡터 유사도 기반 파편적 청크 검색 | [[Index]] 및 위키링크(`[[노트명]]`) 기반 구조적 맥락 추적 |
| **시간 지남에 따른 효과** | 매번 처음부터 다시 읽고 추론하여 비용 복리 발생 | 소스와 질문이 쌓일수록 답변 품질 및 위키의 깊이가 비례하여 증가 |
 
## 예시
 
### 1. 질의 실행 및 영구 저장 프롬프트 시나리오
 
[[Cursor]] 또는 에이전트 채팅 창에 아래와 같이 질의한다 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md):
 
```text
User: "내 모든 소스 전반에서 식별된 주요 리스크는 무엇인가요?"

AI 에이전트 처리 흐름:

  1. wiki/index.md를 열고 소스 요약 및 제품 페이지 연관 링크 확인.
  2. 각 소스 요약 노드 및 오버뷰 페이지를 읽고 교차 분석하여 리스크 목록 정리.
  3. 유저에게 종합 리스크 분석 답변 제공 후 저장 여부 확인:

    “이 답변을 ‘wiki/major-risks-analysis.md’ 분석 페이지로 저장할까요?”

  4. 유저가 “Yes” 응답 시, 해당 답변을 위키 노드로 저장하고 wiki/index.md 카탈로그와 wiki/log.md 타임라인 기록 업데이트.

2. 구체적인 활용 분야별 Query 워크플로우 적용 예시

  • 기술 문서 작성자 (Technical Writer): 제품 스펙과 회의록이 축적된 위키에 *“현재 지원 중단(deprecated) 예정인 기능과 이를 대체하는 신규 용어 목록을 정리해 줘”*라고 질의하여 글쓰기 전 일관된 기준을 확인 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).
  • 프로덕트 매니저 (PM): PRD, 고객 인터뷰, 경쟁사 분석 소스가 ingest된 위키에서 *“경쟁사 대비 우리 제품의 주요 미흡점과 고객 피드백 간의 교차점 분석해 줘”*를 질의 후 분석 페이지로 보존 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).
  • 연구자 (Researcher): ingest된 논문과 리포트 위키에서 *“이번 프로젝트에서 발견된 핵심 주장들과 상충하는 리포트들을 비교해 줘”*라고 질의하여 진화하는 연구 가설(thesis) 정리 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).

충돌

1. 원본 소스(raw/) 직접 질의 vs 위키(wiki/) 우선 질의 간 충돌

  • 문제점: 사용자가 질문 시 AI 에이전트가 wiki/를 거치지 않고 raw/ 원본 폴더로 직접 진입하여 답변을 구성하려는 경향이 발생할 수 있다. 이 경우 위키 컴파일을 통한 종합적 이점이 사라지고 기존 RAG의 맥락 휘발 문제가 재발한다 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).
  • 해결 원칙: CLAUDE.md 스키마 규정에 따라 Query 워크플로우 시 AI 에이전트는 무조건 wiki/index.md와 wiki/ 폴더 내 작성된 컴파일 노드를 1차 정보원으로 삼아야 하며, 위키에 정보가 부족한 경우에만 수집(Ingest)을 추가 권장하도록 제약한다 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).

2. 질의 답변의 위키 저장 과다(Noise Accumulation) vs 누락(Knowledge Loss)

  • 문제점: 모든 일회성 단순 질의 답변을 Analysis 페이지로 저장하면 위키 내에 노이즈 노드가 넘치게 되고, 반대로 유용한 복합 질의 결과를 저장하지 않고 버리면 탐색 과정이 대화 기록 속에 묻혀 지식 베이스 누적 효과가 저해된다 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).
  • 해결 원칙: 질의 답변 후 AI가 저장을 자동 수행하지 않고 반드시 사용자에게 확인 절차를 거치며, 구조적 통찰을 담은 질의 답변 위주로 큐레이션하여 Analysis Page로 변환하도록 조율한다 (raw/AI로 스스로 유지되는 지식 베이스를 Karpathy의 LLM Wiki로 만든 방법.md).

관련 노트

  • LLM Wiki: Query 워크플로우가 작동하는 대상 시스템이자 카파시(Karpathy)의 개인 지식 베이스 아키텍처이다.
  • Ingest 워크플로우: Query 워크플로우가 참조하는 wiki/ 노드들과 인덱스를 사전에 컴파일하고 생성하는 수집 파이프라인이다.
  • Lint 워크플로우: Query 결과 생길 수 있는 모순이나 오래된 정보를 검증하고 정돈하는 위키 상태 점검 파이프라인이다.
  • 수집 쿼리 린트 워크플로우: Ingest, Query, Lint 3대 작업을 총괄하는 에이전틱 지식 관리 종합 노트이다.
  • Analysis Page: Query 워크플로우 실행 결과 유용한 탐색 답안이 위키 노드로 영구화되는 분석 페이지 타입이다.
  • Index: Query 질의 시 AI 에이전트가 1차적으로 참조하는 위키 지식망 탐색 지도(wiki/index.md)이다.
  • CLAUDE.md 스키마: Query 시 위키 우선 참조 및 분석 노트 저장 규칙을 지시하는 에이전트 운영 매뉴얼이다.

그래프 뷰

백링크