RAG, LLM 위키, 그리고 veneta

세 가지는 경쟁 관계가 아닙니다. 서로 다른 질문에 답합니다.

RAG는 “지금 이 질문에 필요한 문서 조각을 어떻게 찾아 넣을까”에 답합니다.
LLM 위키는 “지식을 어떻게 미리 정리해 둘까”에 답합니다. 모델이 마크다운 페이지를 쓰고 고치며 유지합니다.
veneta는 “모델이 경험에서 배운 것을 누가 승인하고, 어디까지 기억하고, 어떻게 되돌릴까”에 답합니다.

문서는 RAG가, 지식은 위키가, 경험은 veneta가 맡습니다. 그리고 사람이 마지막 단계에 있습니다.

한눈에

	RAG	LLM 위키	veneta
기억하는 것	문서 조각	모델이 정리한 지식 페이지	사건, 결정, 결과, 배운 규칙
쓰는 주체	색인 파이프라인	모델	루프가 제안, 사람이 승인
쓰기 비용	임베딩만	소스마다 모델이 읽고 씀	임베딩만, 모델은 답할 때
읽는 방식	질문마다 검색	색인 → 페이지	하이브리드 검색, 날짜 스탬프
사람의 자리	색인 운영	선택적 검토	승인이 필수 단계
되돌리기	재색인	git	해시 체인 원장, 되돌리기
범위	코퍼스 단위	개인, 팀	에이전트별, 사용자별, 공유 결과
잘 맞는 곳	문서가 많고 자주 바뀌는 곳	한 사람의 지식 베이스	운영 에이전트, 여러 사용자, 감사가 필요한 곳

RAG

장점. 단순하고 쌉니다. 사실은 원래 자리에 그대로 두고 조각만 가져옵니다. 문서가 바뀌면 다시 색인하면 됩니다. 성숙한 도구가 많습니다.

단점. 조각은 문맥을 잃습니다. 질문마다 처음부터 다시 추론하므로 여러 문서에 흩어진 것을 세고 합치는 질문에 약합니다. 무엇을 배웠는지 기억하지 않아 같은 실수를 반복합니다. 시간 개념이 없어 어느 것이 최신인지 모릅니다. 색인에 들어간 것은 무엇이든 꺼내 주므로, 무엇이 들어가도 되는지 결정하는 문은 따로 두어야 합니다.

veneta와 같이 쓰면.

좋아지는 것: 사실은 문서에서, 경험은 veneta에서 옵니다. “이 문서로 답했더니 틀렸다”가 규칙으로 남아 다음 답을 바꿉니다. 기억의 모든 줄에 날짜가 찍혀 “언제 읽은 사실인지”가 보입니다. 기억된 값은 오늘 읽은 값에 지므로 RAG의 사실이 기억에 밀리지 않습니다.
감수할 것: 프롬프트 예산을 두 검색이 나눠 씁니다. 같은 내용이 문서 조각과 에피소드에 중복될 수 있습니다. 둘이 충돌할 때의 우선순위를 정해 두어야 합니다. veneta의 기본값은 문서가 이깁니다.

LLM 위키

장점. 사람이 읽을 수 있습니다. 페이지를 열어 직접 고칠 수 있고 git으로 버전이 남습니다. 모델이 미리 정리해 두므로 흩어진 사실을 합치는 질문에 강합니다. 링크로 관계가 드러납니다. 한 사람의 지식이 쌓이는 방식으로 자연스럽습니다.

단점. 소스가 들어올 때마다 모델이 읽고 써야 하므로 쓰기 비용이 큽니다. 로컬 모델에서는 이것이 가장 비싼 단계입니다. 정리하는 과정에서 정보가 깎입니다. 모델이 쓴 “사실”에 승인 문이 없어 틀린 페이지가 다음 답의 근거가 되어 번집니다. 페이지끼리 모순이 쌓이고 치우는 것은 사람 손입니다. 개인 규모의 답이라 여러 사용자와 에이전트의 범위를 나누지 못합니다. 기업의 원천 데이터는 권한과 규제 때문에 모델이 관리하는 파일로 복사할 수 없습니다.

veneta와 같이 쓰면.

좋아지는 것: 위키가 정리한 지식에 승인과 원장이 붙습니다. 모델이 위키에 하는 수정이 검사를 지나고, 원장에 남고, 되돌릴 수 있게 됩니다. 위키 페이지를 veneta의 저장소로 쓰면, veneta가 약한 일인 ’여러 곳에 흩어진 사실을 모아 답하기’를 위키가 대신 잘해 줍니다. 위키 문서 안에 숨긴 지시문도 같은 검사를 지납니다.
감수할 것: 쓰기 비용은 그대로입니다. 승인 문을 잘못 두면 승인 대기함이 길어지고 사람들은 “전부 승인”을 누릅니다. 위키 페이지와 veneta의 에피소드가 같은 일을 두 번 기억할 수 있습니다.
직접 써 본 기록: LLM 위키를 직접 써 봤습니다 — 잘된 장면 하나, 잘못된 장면 하나, 거기서 나온 설계.

veneta

장점. 경험을 기억합니다. 어떤 결정을 했고 결과가 어땠고 실패에서 무엇을 배웠는지. 배운 규칙은 제안으로 들어와 사람이 승인해야 켜지고, 측정이 남을지를 정하며, 해시 체인 원장에 남아 되돌릴 수 있습니다. 들어오는 모든 것을 스캔합니다. 에이전트별, 사용자별로 범위가 나뉘고 결정과 결과만 공유됩니다. 용량과 보존 기간이 있고, 오래된 것은 삭제가 아니라 보관됩니다. OpenAI 호환 인터페이스 아래 어디에나 놓입니다.

한계. 문서 지식 저장소가 아닙니다. RAG나 위키를 대체하지 않습니다. 흩어진 사실을 세고 합치는 일은 답하는 모델의 능력에 기댑니다. 로컬 모델이 천장입니다. 승인 단계는 사람의 시간을 씁니다. 아직 v0.1 전입니다.

셋을 한 그림에

왼쪽부터 문서(RAG), 지식(LLM 위키), 경험(veneta). 세 저장소가 모델 앞에 놓이고, veneta가 셋을 모델에 건넵니다. 모델이 쓰려는 것은 veneta의 검사를 지나 사실은 원장에, 규칙은 승인 대기함으로 갑니다. 오른쪽 끝에 사람이 있습니다.

측정한 것과 아직 측정하지 못한 것

같은 루프, 저장소만 교체. 공개된 메모리 레이어 4종을 veneta의 루프 아래 바꿔 끼워 같은 veneta-bench 12문항(기억 능력 벤치마크)으로 측정했습니다. 원문을 그대로 넘겨 저장한 경우(넘김)와 레이어가 대화에서 추출해 저장한 경우(추출)를 나눴습니다. 레이어의 글자는 벤치마크 페이지·백서와 같고, 제품 이름은 논문에만 둡니다. 조건: gemma-4-31b-fp8, 장비 1대, 레이어당 1회(한 레이어는 3회), 2026-10-02.

레이어	넘김: 원문 그대로 저장	추출: 모델이 추출해 저장	적재 시간 넘김 → 추출 (문항당)
A	11.7 / 12	8.0 / 12	1.4 s → 23.5 s
B	12 / 12	8 / 12	0.7 s → 22 s
C	12 / 12	7 / 12	53 s → 104 s
D	7 / 12	7 / 12	25 s → 40 s

네 레이어 모두 추출 저장이 원문 저장보다 낮거나 같았고 느렸습니다. “모델이 정리해서 저장한다”는 위키 방식의 비용이 여기서 보입니다. 12문항은 작은 표본입니다.

규모. 하이브리드 검색의 상위 k 적중률은 1,800행에서 50,000행까지 93 ~ 97 %로 평평했고, 지연 시간 p95는 행 수에 거의 비례해 늘었습니다(부하 아래 70 ms → 1,533 ms). 조건: nomic 임베딩, SQLite, 장비 1대, 합성 바늘 질문.
보안. 네 레이어 모두 심어 둔 지시문과 비밀값을 그대로 저장했다가 그대로 돌려줬고, 무엇이 저장됐는지 남는 원장이 없었습니다.
공개 벤치마크. LongMemEval-S(500문항, 원본 데이터셋)에서 같은 로컬 모델(gemma-4-31b-fp8, 16k 컨텍스트)로 메모리 없이 답하면(최근 대화 4만 자만 넣음) 15.2 %, veneta 메모리를 켜면 **85.6 %**였습니다. 심판은 벤치마크의 공식 프롬프트를 쓴 GPT-4o, 1회 실행, 장비 1대, 2026-10-03. 유형별로는 단일 세션 94 ~ 98 %, 지식 갱신 95 %, 선호 93 %, 시간 추론 78 %, 다중 세션 76 %. 남은 손실은 대부분 여러 대화에 흩어진 것을 세고 합치는 질문이며, 이는 답하는 모델의 몫이 큽니다. 널리 쓰이는 한 오픈소스 메모리 레이어는 같은 데이터셋에서 90.4 %를 보고합니다(제작사의 보고, 조건은 같지 않음: 클라우드 소형 모델이 답변, 심판 모델은 미공개). 같은 veneta 메모리 위에 GPT-4o를 writer로 얹으면 **77.6 %**였습니다(메모리 블록은 2만 자로 더 작았음: 제공자의 분당 토큰 한도 때문, 중앙값 29줄 대 53줄; 1회, 2026-10-03). 더 강한 writer가 더 낮게 나온 이유는 둘입니다. 블록이 작아 근거가 빠진 경우가 늘었고, GPT-4o는 값 하나만 짧게 답해서 지식 갱신 질문에서 옛 값을 고른 경우가 많았는데 로컬 모델은 날짜를 붙여 둘 다 나열해 공식 심판 기준을 통과했습니다. 즉 이 행은 writer의 힘보다 블록 크기와 읽는 방식을 재고 있습니다. 비교 대상 레이어의 제작사가 답변에 쓴다고 밝힌 모델(claude-haiku-4.5)을 같은 메모리·같은 블록·같은 지시문 위에 writer로 얹으면 83.2 %(440문항 81.8 %, 1회, 2026-10-03)였습니다. 같은 메모리에서 로컬 31B(87.2 %)가 그 클라우드 writer보다 높았고, 차이는 주로 클라우드 writer가 더 자주 기권한 데서 났습니다. 같은 writer로 잰 그쪽 보고치(90.4 %)와는 7점 차이이며, 그쪽은 저장할 때 별도 모델로 기억을 추출하고 veneta 팀은 추출하지 않는다는 점이 남은 차이의 후보입니다. 같은 블록에 로컬 70B를 얹은 행은 보류 중입니다(하드웨어). LoCoMo도 뒤따릅니다. 검색 설정(k, 이웃 턴, 추가 질의, 블록 크기, 지시문)은 500문항 중 60문항(25번째마다, 세 묶음)으로 골랐고, 설정마다 500문항 전체를 1회 돌렸습니다. 고르는 데 쓰지 않은 440문항만 보면 메모리 off 14.8 %, on 84.5 % (고른 60문항은 93.3 %)입니다. 첫 500문항 실행의 오답 유형을 읽고 지시문을 고친 두 번째 설정은 87.2 %(440문항 85.7 %)인데, 그 지시문은 테스트 셋을 보고 쓴 것이라 첫 설정을 대체하지 않고 나란히 둡니다. 데이터셋·심판 프롬프트(저자들의 evaluate_qa.py 그대로)·심판 모델은 벤치마크 것이고, veneta의 것은 측정 대상인 메모리 레이어와 로더·러너 코드, 그리고 답과 판정이 모두 든 실행 파일입니다. 문항마다 빈 메모리에서 시작해 그 문항의 대화만 넣고 끝나면 버리며, Critic·규칙 학습·원장은 꺼져 있어 문항 사이에도 실행 사이에도 남는 것이 없습니다. 이것들은 v0.1과 함께 공개하며, 같은 조건으로 다시 돌려 보실 분을 환영합니다.
공개 벤치마크에서 알아낸 것. (1) 점수를 정하는 것은 답변을 쓰는 LLM(writer)의 크기보다 메모리 블록과 읽는 방식이었습니다. 같은 메모리 위에서 로컬 31B 87.2 %, 클라우드 소형 모델 83.2 %, GPT-4o(블록 절반) 77.6 %. (2) 검색 자체는 거의 잃지 않았습니다. 근거 세션이 블록에 든 비율이 97 ~ 98 %였고, 남은 오답은 여러 대화에 흩어진 것을 세는 문제, 날짜 계산, 그리고 근거가 있는데도 “기록에 없다”고 한 기권이었습니다. (3) 지식 갱신 질문에서는 값 하나를 고르는 writer보다 날짜를 붙여 둘 다 나열하는 writer가 공식 심판을 통과했습니다. (4) 오답을 읽고 지시문을 고치면 점수가 오르지만(85.6 → 87.2) 그것은 테스트 셋을 본 결과라 그렇게 표기해야 합니다. (5) 16k 컨텍스트의 무메모리 기준선은 대화의 10 %도 못 보기 때문에 바닥(15 %)에 깔리고, 그래서 메모리 on/off 배수가 veneta의 운영 벤치마크보다 훨씬 큽니다.
다음 단계. 저장할 때 모델이 기억을 정리해 두는 방식(위키 저장소 compiled 모드)은 12문항에서 측정했고(아래 ‘위키 저장소’ 항목), 같은 비교를 공개 벤치마크 500문항에서 합니다. 세기 질문에는 초안이 “일부만”이라고 할 때 한 번 더 검색하는 2차 검색과 개체별 시간순 목록을, 날짜 질문에는 날짜 차이를 코드로 계산해 writer에게 건네는 도구를 붙입니다(사실은 도구가, 추론은 모델이). 근거가 있는데 기권하는 비율을 기권 문항을 잃지 않고 줄입니다. 설정을 동결하고 LoCoMo를 1회 돌리며, 반복 3회로 범위를 적고, 비교 대상 레이어들을 같은 writer 밑에서 직접 돌립니다. 70B 로컬 writer 행은 전원 문제로 보류 중이며 두 번째 기기에서 재개합니다.
위키 저장소(veneta 어댑터), 측정했습니다. 마크다운 페이지 폴더(pages/<이름>.md, index.md, log.md)를 다섯 번째 저장소로 끼워 같은 12문항으로 측정했습니다(gemma-4-31b-fp8, 장비 1대, 1회, 2026-10-04). 원문을 그대로 페이지에 적는 rows 모드는 넘김 12/12, 추출 10/12, 적재 문항당 0.1초 미만. 모델이 기록을 읽고 주제 페이지로 정리하는 compiled 모드는 넘김 10/12, 추출 9/12, 적재 문항당 중앙값 35초(24문항 중 컴파일 실패 4건은 원문으로 저장). 검색 벤치(720질의, 모델 없음) 상위 k 적중률: rows 96.9 %, compiled 92.1 %, veneta hybrid 98.8 %; 검색 지연 6 ~ 7 ms. 보안 테스트 일곱 개는 다른 세 저장소와 같은 프로파일입니다(심은 지시문과 비밀값을 그대로 저장하고 돌려줌, 검증 가능한 원장 없음, 거절한 규칙의 톰스톤 없음). 읽는 법: 저장할 때 모델이 정리하는 방식은 12문항에서 점수를 사지 않고 잃었고, 적측정하는 수백 배 느렸습니다. 위키는 저장소이고 승인·원장·톰스톤는 그 위의 루프가 더합니다. 공개 벤치마크 500문항에서는 다를 수 있어 그것이 다음 측정입니다. 실행 파일은 v0.1과 함께 공개합니다.

언제 무엇을

문서가 많고 자주 바뀌며 사실이 원래 자리에 있어야 한다면 RAG.
혼자 쓰는 지식을 사람이 읽을 수 있는 형태로 쌓고 싶다면 LLM 위키.
에이전트가 운영을 하고, 결정과 결과를 기억해야 하고, 누가 무엇을 승인했는지 남아야 한다면 veneta.
셋은 겹치지 않으니 같이 쓸 수 있습니다. 어댑터는 아래 내용을 참고하세요.

누구에게 권하나

메모리를 켜면 모델이 읽을 것이 늘어 답이 느려집니다. 기억 블록의 크기는 설정이고, 키우면 정확도와 속도를 맞바꿉니다. 승인 단계는 사람의 시간을 씁니다. 혼자 쓰고 결정의 기록이 필요 없다면 RAG나 LLM 위키만으로 충분할 수 있습니다. veneta는 에이전트가 결정을 내리고, 그 결과를 기억해야 하고, 누가 무엇을 승인했는지 남아야 하는 곳에 권합니다.

어댑터

RAG 어댑터: RAG 검색기를 veneta의 도구로 등록합니다.
LLM 위키 저장소: 마크다운 페이지 폴더를 veneta의 저장소로 씁니다. veneta의 기억을 사람이 읽는 파일로 볼 수 있습니다. 측정했고, 숫자는 이 페이지의 ‘측정한 것과 아직 측정하지 못한 것’ 절에 있습니다.
위키 위의 거버넌스: 모델의 위키 수정에 검사, 승인 대기함, 원장을 붙입니다. 설계는 v0.1과 함께 공개합니다.