페이지 불러오는 중
이전 글에서 Andrej Karpathy가 제안한 LLM Wiki의 개념과 구조, 기존 RAG와의 차이 및 개인 프로젝트 적용 방법에 대해 정리했습니다.
이번 글에서는 LLM Wiki 자체에 대한 설명은 제외하고, 해당 구조를 실제 프로젝트에 적용하면서 추가로 설계한 부분을 중심으로 정리합니다.
기존 LLM Wiki 구조를 실제 프로젝트에 적용하면서 추가적으로 두 가지 부분을 고민했습니다.
LLM Wiki를 프로젝트에 적용하면 AI가 프로젝트의 지식을 지속적으로 참고할 수 있는 기반을 만들 수 있습니다.
하지만 AI Agent가 단순한 질의응답을 넘어 실제 프로젝트의 코드나 문서를 수정한다고 가정하면 추가적인 문제가 발생합니다.
제가 중요하게 생각한 문제는 크게 두 가지입니다.
AI가 프로젝트의 Context를 충분히 확보하더라도 결과가 항상 올바르다고 보장할 수 없습니다.
실제 프로젝트에서는 다음과 같은 문제가 발생할 수 있습니다.
하지만 AI가 수행한 모든 Session과 Log를 관리자가 직접 확인하는 것도 비효율적입니다.
따라서 AI가 참고하고 관리하는 영역과 사람이 검토해야 하는 영역을 분리할 필요가 있다고 생각했습니다.
두 번째 문제는 Wiki 자체의 크기입니다.
프로젝트가 장기간 운영되면 Wiki 문서와 연결 관계 역시 계속해서 증가합니다.
Wiki의 Backlink를 통해 연관 문서를 탐색하는 것은 프로젝트의 Context를 이해하는 데 도움이 됩니다.
하지만 하나의 정보를 확인하기 위해 관련된 파일 전체를 계속 읽는다면 오히려 Context 사용량이 증가할 수 있습니다.
따라서 Backlink의 참조 범위를 File이 아닌 Block 단위까지 줄이는 방식을 추가적으로 생각했습니다.
제가 추가한 첫 번째 구조는 Report 영역입니다.
기존 Wiki가 AI가 프로젝트를 이해하고 참고하기 위한 영역이라면 Report는 사람이 AI의 작업을 이해하고 감독하기 위한 영역입니다.
AI Agent
│
│ 작업 수행
▼
Project
│
│ 검토 대상 추출
▼
Report
│
▼
AdminAI가 작업을 수행한 뒤 모든 과정과 Session Log를 사람이 확인하도록 하는 것이 목적은 아닙니다.
대신 실제 관리자가 확인할 필요가 있는 정보만 별도의 Report 형태로 정리합니다.
예를 들어 다음과 같이 구성할 수 있습니다.
[Project Report]
작업
- 로그인 인증 로직 변경
변경 사항
- Refresh Token 처리 방식 수정
검토 필요
- 기존 인증 정책과 동작 방식이 달라졌습니다.
Risk
- Security Policy에 영향을 줄 가능성이 있습니다.
Reference
- auth.md#AUTH-03
- security.md#SEC-07Admin은 우선 Report를 확인합니다.
특별한 문제가 없다면 모든 Wiki와 Session Log를 직접 확인할 필요가 없습니다.
반대로 문제가 있다고 판단되면 Reference를 통해 실제 근거까지 내려가 확인할 수 있습니다.
Report 구조를 생각하면서 중요하게 본 부분은 Log와 Report의 목적이 다르다는 점입니다.
Log의 목적은 기록입니다.
반면 Report의 목적은 검토입니다.
Session Log
"AI가 무엇을 했는가?"
│
▼
Report
"사람이 무엇을 확인해야 하는가?"AI Agent가 하루 동안 수십 번의 작업을 수행했다고 해서 관리자가 모든 Session Log를 읽을 필요는 없습니다.
그중에서 실제 프로젝트에 영향을 줄 수 있거나 사람이 판단해야 하는 변경만 Report에 노출합니다.
예를 들어 다음과 같이 구분할 수 있습니다.
일반적인 코드 Formatting
↓
Report X
단순 문서 오타 수정
↓
Report X
인증 정책 변경
↓
Report O
Database Schema 변경
↓
Report O
보안 정책과 충돌 가능성
↓
Report O따라서 Report는 단순한 작업 기록 저장소보다는 Human Review Queue에 가까운 역할을 담당합니다.
Report 영역에서는 Reference를 통한 추적 가능성도 중요하다고 생각했습니다.
AI가 Report에서 다음과 같이 판단했다고 가정합니다.
해당 변경은 기존 보안 정책과 충돌할 가능성이 있습니다.
하지만 관리자가 AI가 작성한 설명 자체를 그대로 신뢰한다면 AI의 Hallucination이나 잘못된 판단을 검증하기 어렵습니다.
따라서 Report에서 실제 판단에 사용한 Wiki의 영역까지 연결할 수 있도록 구성합니다.
Report
│
├─ Summary
├─ Changes
├─ Risk
│
└─ References
│
▼
Wiki Block
│
▼
Raw Source관리자는 단계적으로 정보를 확인할 수 있습니다.
Report의 Summary와 Risk를 확인합니다.
추가적인 확인이 필요한 경우 Reference로 연결된 Wiki 내용을 확인합니다.
Wiki에 정리된 내용 자체도 검증할 필요가 있다면 원본 Source까지 내려가 확인합니다.
결과적으로 다음과 같은 구조가 됩니다.
Report
↓
Human Review
↓
Wiki Block
↓
Raw Source사람이 모든 데이터를 처음부터 확인하는 것이 아니라 필요한 경우에만 상세 정보로 Drill-down하는 방식입니다.
두 번째로 추가한 부분은 Wiki Reference의 세분화입니다.
Wiki에서는 관련 정보가 Backlink를 통해 서로 연결됩니다.
하지만 프로젝트가 커지면 하나의 Wiki 문서 자체도 상당히 커질 수 있습니다.
예를 들어 다음과 같은 관계가 있다고 가정합니다.
Authentication
│
▼
architecture.mdarchitecture.md가 2,000줄의 문서이고 실제 Authentication과 관련된 내용은 80줄이라고 가정합니다.
AI가 Backlink를 따라갈 때마다 해당 파일 전체를 읽는다면 실제 필요한 정보보다 훨씬 많은 Context를 사용하게 됩니다.
여러 개의 Wiki가 연결되어 있다면 문제는 더 커질 수 있습니다.
Task
↓
Wiki A
↓
Wiki B
↓
Wiki C
↓
각 Wiki File 전체 Load
↓
Context 증가Wiki가 커지고 연결 관계가 증가할수록 불필요한 Context 역시 함께 증가할 가능성이 있습니다.
따라서 Wiki의 연결성은 유지하면서 AI가 실제로 읽는 범위는 줄일 필요가 있다고 생각했습니다.
이를 위해 Wiki의 Reference를 File 단위에서 Block 단위로 세분화하는 방식을 생각했습니다.
기존의 Reference가 다음과 같다면,
[[architecture.md]]특정 영역까지 직접 참조할 수 있도록 변경합니다.
[[architecture.md#AUTH-001]]Block은 실제 문서에서 참조해야 하는 영역에 대한 정보를 가지고 있습니다.
예를 들어 다음과 같이 표현할 수 있습니다.
block: AUTH-001
file: architecture.md
start: 120
end: 180AI가 해당 Reference를 발견하면 architecture.md 전체를 Context에 포함하는 것이 아니라 지정된 Region만 가져옵니다.
기존 방식은 다음과 같습니다.
File Reference
architecture.md
↓
전체 문서 LoadBlock 단위 Reference를 적용하면 다음과 같이 변경됩니다.
Block Reference
architecture.md
↓
AUTH-001
↓
start: 120
end: 180
↓
해당 Region만 Load즉, Backlink의 관계 자체는 유지하면서 실제 Context에 포함되는 데이터의 범위를 세분화하는 방식입니다.
Block Reference를 추가하려는 목적은 단순합니다.
AI에게 더 많은 정보를 제공하는 것이 아니라 현재 작업에 필요한 정보를 더 정확하게 제공하는 것입니다.
예를 들어 현재 작업과 연관된 Wiki가 5개 있다고 가정합니다.
File 단위로 접근하면 다음과 같은 구조가 됩니다.
Wiki A 전체
+
Wiki B 전체
+
Wiki C 전체
+
Wiki D 전체
+
Wiki E 전체반면 Block 단위 Reference를 사용하면 다음과 같이 필요한 부분만 가져올 수 있습니다.
Wiki A → Block 02
Wiki B → Block 07
Wiki C → Block 01
Wiki D → Block 12
Wiki E → Block 04이를 통해 다음과 같은 효과를 기대합니다.
Block Reference를 구현할 때 가장 단순한 방법은 start-end를 이용하여 문서의 특정 영역을 지정하는 것입니다.
하지만 이 방식에는 문제가 있습니다.
문서가 수정되면 Line Number가 변경될 수 있기 때문입니다.
예를 들어 기존 Reference가 다음과 같다고 가정합니다.
file: architecture.md
start: 120
end: 180이후 문서 상단에 새로운 내용이 30줄 추가되면 기존 Reference가 잘못된 영역을 가리킬 가능성이 있습니다.
따라서 실제 구현에서는 단순한 Line Number만 사용하는 것보다 Block 자체를 식별할 수 있는 정보를 함께 관리하는 방식을 고려할 수 있습니다.
예를 들어 다음과 같습니다.
id: AUTH-001
file: architecture.md
heading: Authentication
start: 150
end: 210
hash: xxxxx각각의 역할을 구분하면 다음과 같습니다.
Block ID : Block을 식별합니다.file : Block이 존재하는 파일을 식별합니다.heading : 문서 내부의 의미적인 위치를 식별합니다.start-end : 실제 Context를 빠르게 가져오기 위한 범위를 지정합니다.hash : 기존 Block의 내용이 변경되었는지 확인합니다.
이렇게 구성하면 start-end는 단순한 위치 정보로 사용하고, Block ID와 Hash 등을 통해 해당 Reference가 여전히 유효한지 확인할 수 있습니다.다만 이 부분은 실제 구현 과정에서 어떤 방식이 가장 효율적인지 추가적인 검증이 필요합니다.
지금까지의 내용을 합치면 다음과 같은 구조가 됩니다.
ADMIN
│
Review
│
▼
┌────────────┐
│ REPORT │
│ │
│ Summary │
│ Changes │
│ Risk │
│ Reference │
└─────┬──────┘
│
Block Ref
│
▼
┌────────────┐
│ WIKI │
│ │
│ Project │
│ Session │
│ Skill │
│ Knowledge │
└─────┬──────┘
│
Reference
│
▼
┌────────────┐
│ RAW SOURCE │
└────────────┘
▲
│
Context Retrieval
│
AI Agent여기서 Wiki를 중심으로 AI가 지식을 관리하고 활용하는 기본 아이디어는 Andrej Karpathy의 LLM Wiki를 기반으로 합니다.
해당 개념 자체에 대한 내용은 이전 글에서 정리했기 때문에 이번 글에서는 다시 다루지 않았습니다.
이번에 추가적으로 설계한 부분은 크게 두 가지입니다.
Wiki의 Backlink를 Block 단위까지 세분화하여 AI가 작업에 필요한 Context만 가져오도록 합니다.
AI의 전체 작업 과정 중 사람이 확인해야 하는 내용을 Report 영역으로 분리합니다.
필요한 경우 다음과 같이 근거를 단계적으로 추적할 수 있도록 합니다.
Report
↓
Wiki Block
↓
Raw Source결과적으로 기존 LLM Wiki의 지식 관리 구조 위에 Context 효율성을 위한 Block Reference와 Human Supervision을 위한 Report Layer를 추가하는 구조입니다.
현재는 구조를 설계한 단계이기 때문에 실제 프로젝트에 적용하면서 몇 가지 부분을 추가적으로 검증할 필요가 있습니다.
문서가 수정되더라도 Reference가 유지될 수 있도록 Block ID, Heading, Hash, Line Range 등을 어떤 방식으로 조합할지 검증해야 합니다.
File 단위 Reference와 Block 단위 Reference를 동일한 작업에 적용하여 실제 Token 사용량이 어느 정도 감소하는지 비교할 필요가 있습니다.
단순한 이론적인 개선이 아니라 실제 측정값을 통해 효과를 확인하고자 합니다.
모든 작업을 Report로 생성하면 결국 사람이 확인해야 하는 정보가 다시 많아집니다.
따라서 어떤 작업을 Report 대상으로 지정할 것인지 기준이 필요합니다.
예를 들어 다음과 같은 작업을 검토 대상으로 지정할 수 있습니다.
Report를 생성하는 주체 역시 AI라면 Report 자체에 Hallucination이 발생할 가능성도 고려해야 합니다.
따라서 AI에게 단순히 위험한 작업을 판단하도록 요청하는 것만으로 충분한지 검증해야 합니다.
가능하다면 정해진 Rule과 AI의 판단을 함께 활용하여 Report 대상을 결정하는 구조도 고려할 수 있습니다.
최종적으로는 AI가 어떤 정보를 참고하여 작업했고, 어떤 변경사항이 발생했으며, 사람이 무엇을 검토했는지 추적할 수 있도록 하는 것을 목표로 합니다.
AI Output
↓
Report
↓
Wiki Block
↓
Raw Source이를 통해 문제가 발생했을 때 결과만 확인하는 것이 아니라 AI의 판단 근거까지 역으로 추적할 수 있는 구조를 구성하고자 합니다.
기존 LLM Wiki를 공부하면서 프로젝트의 장기적인 Context를 관리하는 방법에 대한 방향을 잡을 수 있었습니다.
이번에는 여기에서 한 단계 더 나아가 실제 프로젝트에서 AI Agent를 운영한다고 가정했을 때 발생할 수 있는 문제를 생각해봤습니다.
그 과정에서 중요하다고 생각한 부분은 크게 두 가지였습니다.
AI가 읽어야 하는 범위를 줄이는 것입니다.
그리고
사람이 읽어야 하는 범위를 줄이는 것입니다.
AI에게는 File 전체가 아니라 Block 단위의 필요한 Context만 제공합니다.
사람에게는 AI의 전체 Session과 Log가 아니라 실제로 검토가 필요한 Report를 제공합니다.
결국 이번 확장 구조에서 해결하고자 하는 문제는 단순한 Wiki 관리가 아닙니다.
AI와 사람 모두에게 필요한 정보만 전달하면서도 프로젝트 전체의 Context와 판단 근거에 대한 추적 가능성을 유지하는 것을 목표로 합니다.
댓글
GitHub 계정으로 의견이나 질문을 남길 수 있습니다.