출처 https://youtu.be/Lsut4TCfygw · 채널 LangChain · 길이 00:44:14 포맷 LangChain 공동창업자 겸 CEO 해리슨 체이스(Harrison Chase) 가 진행하는 웨비나 패널 토론. 패널은 LangChain Applied AI 총괄 브레이스 스프라울(Brace Sproul), DOSU 창업자 데빈 스타인(Devin Stein), Chroma 창업자 겸 CEO 제프 후버(Jeff Huber). 초반 8분은 브레이스와 데빈의 실시간 화면 공유 데모, 이후는 “LLM 위키란 무엇인가”를 둘러싼 원탁 토론과 청중 Q&A. 원본 자막:
raw/transcripts/2026-07-11-llm-wikis-and-how-to-give-your-agents-memory.en.srt
한눈에 보는 요약
- 위키를 정의하는 것부터 의견이 갈린다. 해리슨은 “에이전트가 생성하고 에이전트를 위한, 어떤 디렉터리 구조의 파일 묶음”으로 소박하게 정의하지만, 제프는 이를 “기술과 용례에 과적합된” 정의라 반박하며 위키를 더 추상적으로 — 서로 링크된 하이퍼텍스트 페이지 묶음, 정보 소비에 최적화된 레이아웃 — 로 봐야 한다고 말한다. 데빈은 카파시의 트윗을 인용해 위키를 컴파일된 지식(compiled knowledge), 즉 매번 다시 탐색하지 않도록 캐싱해두는 것으로 규정한다.
- 데빈의 핵심 비유는 “위키 = 캐시”. 지식에는 ①다른 곳에 존재하지 않는 필수 지식과 ②탐색 비용을 줄여주는 기능적(캐시) 지식 두 종류가 있고, 캐시가 늘 그렇듯 자주 접근되거나 재계산 비용이 비쌀 때만 캐싱할 가치가 있다 — DB 전체를 캐시로 만들면 최신화 비용이 폭발하는 것과 같은 논리다.
- 오늘날 위키 구현은 여전히 “사람 지향적”이다. 데빈은 웨비나 초대 자체가 아이러니라며 “위키는 틀린 추상화”라는 핫테이크를 던진다 — 지금의 위키는 사람이 앞에서 뒤로 읽는다는 전제(도입부→아키텍처 순서)로 만들어지는데, 에이전트 우선으로 다시 설계하면 간결하고 참조 밀도가 높은 문체, 그리고 접근 안 되면 삭제(eviction) 하는 지식 구조가 되어야 한다고 본다.
- 위키를 만드는 것보다 유지하는 게 더 어렵다. 세 사람 모두 유지보수(maintenance)를 최대 난제로 꼽는다 — 브레이스는 300번째 업데이트쯤 가면 에이전트가 기존 문장을 고치는 대신 계속 새 줄만 삽입해 위키가 비대해지는 문제를, 데빈은 대규모 코드베이스(수천만 줄)에서 “뭐가 중요한지” 골라내는 게 생성 단계부터 어렵다는 점을, 제프는 이 전체를 프롬프트 엔지니어링이 아니라 하니스/시스템 엔지니어링 문제(동시성 제어 등)로 규정한다.
- ROI 측정은 아직 답이 없다. 벤치마크는 이미 학습 데이터에 오염돼 있어 무의미하고, 대신 같은 답에 도달하는 데 필요한 툴 콜·토큰 수가 줄었는지, 결과 일관성이 높아졌는지(같은 시드=위키에서 시작하면 궤적이 더 안정적)를 내부 지표로 쓴다는 답이 나온다. DOSU 내부 벤치마크로는 위키 항목이 있는 주제의 실행 비용이 대략 절반.
- 위키 vs 지식 그래프: 세 사람은 RDF triple store·Neo4j류의 엄격한 그래프 DB는 “너무 옵션이 많고(opinionated)” 유연성을 해친다고 본다. 위키의 자유로운 링크 구조가 에이전트에게 더 맞고, 시맨틱 유사도 공간에 자연스럽게 놓인다는 점에서 그래프 쿼리보다 낫다는 데 합의한다.
- 에이전트를 위키에 어떻게 붙일까엔 명확한 정답이 없다. 파일시스템 툴(bash/grep류)이 코드베이스 탐색엔 매우 강하지만, 버전 관리·접근 제어·발견성(discovery)엔 약하다 — 결국 풀텍스트·시맨틱·에이전틱 검색을 섞어 쓰되 에이전트에게 모든 도구를 주고 스스로 고르게 하라(bitter lesson)는 쪽으로 의견이 모인다.
장면별 상세 설명
[00:00] 1. 오프닝 — 네 명의 패널
해리슨은 이 웨비나가 원래 한 달 전쯤 기획하는 정례 포맷인데, “너무 뜨거운 주제”라 데빈과의 점심 자리에서 즉흥적으로 last-minute로 잡았다고 밝힌다. “위키·메모리·지식”이라는 주제는 초기 RAG 시절부터 늘 뜨거웠고, 최근 코딩 에이전트 진영과 카파시의 트윗을 계기로 다시 부상했다는 게 그의 진단이다. 각 패널에게 2분 이내로 자기 작업을 소개해달라고 요청하며 시작한다.
[02:00] 2. 브레이스 데모 — OpenWiki 퍼스널 초기화
브레이스(LangChain)는 이날 아침 막 릴리스한 OpenWiki 0.1의 범용 메모리 모듈을 시연한다. “메모리를 생성·유지하는 건 시간이 오래 걸리고 지루하다”는 전제에서, npm으로 설치하는 CLI로 이를 완전히 백그라운드로 밀어 넣는 게 목표라고 설명한다. openwiki personal --init 한 번이면 모델 프로바이더 설정과 위키 브리프(메모리 에이전트에게 주는 시스템 프롬프트 — 무엇에 집중할지, 어떻게 구조화할지)를 정하는 온보딩이 끝난다. 이후 매일 새벽 2시 크론으로 자동 갱신되며(맥 자동 기상 옵션 포함), Notion·Gmail·Slack 등 커넥터를 붙이면 그 데이터를 인제스천해 문서를 자동으로 써 내려간다. (같은 툴의 후속 데모는 2026-07-11-openwiki-brains-general-purpose-memory-for-agents에 더 자세히 정리돼 있다.)
[04:00] 3. 데빈 데모 — DOSU의 지식 인프라
데빈 스타인(DOSU 창업자)은 “에이전트와 사람을 위한 지식 인프라”로 DOSU를 소개한다. MCP를 통해 코딩 에이전트 워크플로에 바로 꽂히며, 에이전트가 작업 중 지식을 읽거나 쓸 때 DOSU의 API/툴을 호출한다. 예시로 새 사용자용 DB 테이블을 만드는 작업을 Claude에게 시키면, 그 과정에서 배운 내용(스키마·마이그레이션 동작 방식 등)을 DOSU가 영속적인 조직 지식으로 포착한다. 이후 DOSU의 “라이브러리언 에이전트”가 이를 사람도 읽을 수 있으면서 간결·고참조밀도·정보밀도 위주로 최적화된 지식 인덱스(토픽 페이지) 로 정리하고, 같은 주제를 다시 다룰 때 클로드 코드 세션에 자동 주입한다. 코드 변경에 맞춰 지식을 계속 최신화하고, 위키 사용이 실제로 조직에 미치는 영향을 분석하는 기능도 있다고 언급한다.
[06:26] 4. 제프 소개 — Chroma와 “새로운 인덱스”로서의 위키
브레이스·데빈과 달리 제프 후버(Chroma)는 라이브 데모 없이 배경을 설명한다. 2023년 aigrant.com에 Chroma를 “AI를 위한 프로그래머블 메모리”로 소개한 게 이 문제를 다뤄온 시작점이었다며, Chroma를 단순 “벡터 데이터베이스”가 아니라 대량의 비정형 데이터를 저장하고 극도로 조회 가능하게 만드는 문제를 푸는 도구로 규정한다. 봄에 낸 Context One(에이전틱 검색에서 SOTA인 모델)도 같은 맥락이다. 그는 위키를 인덱싱의 새로운 형태로 본다 — 인덱스가 전혀 없으면 그냥 데이터 덩어리에 프로브를 찔러보는 수준(guess and check)이고, 임베딩(sparse/dense)이 있으면 지도의 지형(topology)은 갖췄지만 여전히 guess-and-check에 가깝고, 위키는 여기에 도로망과 배관(파이프·연결)을 더해 에이전트가 더 잘 이동(traverse)하게 해준다. Chroma 팀도 내부적으로 자체 조직 메모리를 구축해보고 있으며, “위키는 만들기도 유지하기도 정말 어렵다”는 걸 체감했다고 덧붙인다.
[08:33] 5. 위키란 무엇인가 — 정의를 둘러싼 이견
해리슨이 소박한 정의(“에이전트가 만들고 에이전트를 위한, 어떤 디렉터리 구조의 파일 묶음”)를 던지자 제프가 즉시 반박한다 — “그건 기술과 용례에 과적합된 정의다. 위키피디아가 실제로 데이터를 어떻게 저장하는지가 위키의 본질은 아니지 않냐”며, 위키를 더 추상적으로 서로 링크된 하이퍼텍스트 페이지의 집합, 광고 없이 정보 소비에 최적화된 레이아웃으로 재정의한다. 브레이스는 “오늘날엔 결국 마크다운 파일 묶음”이라는 실용적 절충안을 낸다. 데빈은 카파시의 트윗을 근거로 LLM 위키 특유의 성격 — 소스를 컴파일해 인덱스로 만드는 것, 각 페이지가 사실상 캐시로 작동해 미래에 같은 정보를 재탐색하지 않게 해주는 것 — 을 강조한다.
[15:36] 6. “위키 = 캐시” 비유 심화
해리슨이 요청하자 데빈이 캐시 비유를 확장한다. 오늘날 위키 구현이 “사람 지향적”인 이유는 학습 데이터 자체가 사람이 쓴 위키이기 때문 — getting-started, architecture 순서로 앞에서 뒤로 읽힌다는 전제가 깔려 있다. 첫 번째 원칙으로 돌아가면 지식은 두 종류다: ①필수 지식 — 위키에 문서화되지 않으면 에이전트가 접근할 방법이 아예 없는 정보. ②기능적(캐시) 지식 — 있으면 같은 결론에 도달하기 위해 매번 재탐색하지 않아도 되게 해주는, 있으면 좋은 정보. 캐시가 늘 그렇듯 DB 전체를 캐시로 만들면 소스와 계속 동기화해야 해서 비용이 폭발하므로, 자주 접근되거나 재계산이 비싼 것만 골라 캐싱해야 한다는 게 요지다.
[16:44] 7. 사람 vs 에이전트, 그리고 인간 개입(human-in-the-loop)
“이 위키들은 결국 사람용인가 에이전트용인가”라는 질문에 브레이스는 “역사적으로는 둘 다를 위한 용어였다”며 코그니션의 딥위키(사람용 웹사이트 + 에이전트용 MCP 서버)를 예로 들지만, “에이전틱 개발이 확산될수록 사람이 문서를 직접 읽는 비중은 줄고 에이전트에게 물어보는 비중이 늘 것이므로, 앞으로 위키는 순수하게 에이전트 인터페이싱을 우선해 설계해야 한다”고 본다. 제프는 사고실험으로 반박한다 — “만약 에이전트가 완전히 latent vector로만 위키를 저장하는 게 최적이라면? 그건 사람의 통제·조종성(steerability)·가독성·공유 작업공간을 완전히 깨뜨린다. 그래서 위키는 영어로 남아야 하고, 곧 사람과 에이전트 둘 다를 위한 것이다.”
human-in-the-loop 실무에서 데빈은 DOSU가 지식 리뷰를 PR 리뷰처럼 운영하되 모든 변경을 승인받게 하진 않는다고 설명한다 — 고객들이 이미 코드 리뷰에 지쳐 있어 지식 리뷰까지 부담 주고 싶지 않기 때문. 대신 “지식은 결과적 일관성(eventually consistent)을 갖는다”는 원칙으로, 자기 교정 루프만 있으면 틀린 캐시 항목도 언젠가 바로잡힌다고 본다. 브레이스는 OpenWiki에서 에이전트가 답을 모르는 질문을 open-questions 파일에 적어두고 나중에 답을 찾으면 스스로 체크하는 방식, 그리고 개별 diff 대신 **변경 로그(change log)**로 사람이 고수준에서만 감사하는 아이디어를 소개한다. 제프는 지금 단계를 “프롬프트 엔지니어링 시대”로 규정하며, 결국은 루프 엔지니어링으로, 그리고 궁극적으로는 에이전트가 스스로 언제 사람에게 도움을 요청해야 하는지 아는 단계로 갈 것이라 전망한다.
[24:14] 8. 위키를 만드는 가장 어려운 부분
브레이스는 업데이트 프롬프팅이 가장 어렵다고 꼽는다 — 첫 초안은 잘 쓰지만, 업데이트가 300번쯤 누적되면 에이전트가 기존 문장을 고치기보다 계속 새 줄을 삽입하려 해서 위키가 비대해진다. 데빈은 세 가지를 든다: ①생성 자체가 어렵다 — 수천만 줄 규모의 대형 코드베이스에서 “뭐가 중요한지” 골라내지 못하면 에이전트가 엉뚱한 것에 집중한다(작은 프로젝트에선 문제없음). ②유지보수 — 프롬프팅은 그 일부일 뿐, 규모가 커지면 토큰 비용 대비 실제 ROI가 나는지가 불확실해진다. ③관찰가능성(observability) — 다들 위키의 가치를 직관적으론 느끼지만 임팩트를 실제로 측정하긴 어렵다. 제프는 이를 “정확도 대 비용 관리” 사이의 하니스 엔지니어링 문제로 재구성한다 — 모든 인제스천·업데이트에 최고급 모델을 쓸 순 없으니, 프롬프트·모델 선택·전체 파이프라인이 뒤섞이는 다변량 최적화 문제라는 것.
[29:01] 9. ROI 측정의 어려움
데빈은 DOSU 내부 벤치마크를 공유한다 — 위키 항목이 있는 토픽에서 작업하면 컨텍스트 수집이 줄어 실행 비용이 대략 절반이고, 같은 작업을 10번 반복해도 결과 궤적(trajectory)이 더 일관적이다(같은 시드=위키에서 출발하니 다운스트림 변동이 준다). 브레이스는 벤치마크가 이미 모델 학습 데이터에 오염돼 있어(SWE-bench류) 문서 유무로 성능 차이가 잘 안 나온다며, 대신 같은 정답에 더 적은 툴콜·더 적은 토큰으로 도달하는지를 자체 인하우스 eval로 측정한다고 말한다. 데빈은 측정 관점을 두 갈래로 나눈다 — ①기존 워크플로에 위키를 꽂아 더 싸고 빠르고 사람 개입이 준다는 식의 개선, ②위키가 있어야만 새롭게 가능해지는 일(long-horizon task, 에이전트 간 협업 등) — 후자는 아직 “감으로 판단하는(vibes)” 단계라고 인정한다.
[33:10] 10. 데빈의 핫테이크 — “위키는 틀린 추상화”
해리슨이 데빈의 사전 핫테이크(“위키는 틀린 추상화”)를 다시 꺼낸다. 데빈은 “오늘날 우리가 위키를 이야기하는 방식 자체가 너무 사람 지향적”이라며, 에이전트 우선(agent-first) 관점에서 다시 접근하면 콘텐츠와 구조 모두 토큰 효율 기준으로 재검토된다고 답한다. 구체적으로는: ①언어가 훨씬 간결해진다 — 사람에게 필요한 산문(prose)이 필요 없고, 에이전트가 스스로 추가 탐색을 잘하기 때문에 참조 밀도(referential)가 더 높은 스타일이 낫다. ②삭제(eviction) — 사람용 위키는 영원히 보존하고 싶어 하지만, 에이전트용은 접근되지 않으면 그냥 지워버리거나, 애초에 재계산이 싸고 쉬운 정보는 아예 쓰지 않는 게 낫다는 것. 제프는 자신의 “링크된 페이지” 정의에 동의하면서, 페이지 길이(짧게 vs 길게)와 **점진적 공개(progressive disclosure)**를 위한 헤딩 구조, 능동적 링킹 vs 검색어 기반 수동 링킹, 백링크 정리 등은 여전히 답이 없는 유지보수 문제로 남겨둔다.
[37:17] 11. Q&A — 비개발 지식노동자, 위키 vs 지식 그래프, 벡터 DB
첫 청중 질문은 “개발자가 아닌 지식노동자 조직에도 의미 있는 가치 지표가 있는가”다. 브레이스는 “그렇다”고 답한다 — 회사의 모든 소스로 범용 위키를 만들고 그걸 조직 구성원이 이미 쓰는 챗 인터페이스에 연결하면, 사람에게 다시 물어보지 않고도 더 빠르게 답을 얻을 수 있다는 것. 데빈은 극단적 입장을 취한다 — “위키라는 용어조차 안 쓰겠지만, 본질적으로 이건 조직의 상태(state) 레이어다. 앞으로 모든 회사의 소통·조정·실행 레이어가 될 것”이라며, 지식노동자뿐 아니라 조직 전체에 영향을 미친다고 본다.
위키 vs 지식 그래프 질문에는 세 명 모두 회의적이다. 브레이스는 카파시식 위키나 구글의 OKF(Open Knowledge Format)처럼 페이지끼리 서로 링크하는 구조 자체가 이미 “그래프적”이라고 본다. 제프는 “RDF triple store나 Neo4j 같은 경직된 그래프 DB는 너무 옵션이 많다(opinionated) — 명사-동사-명사 같은 고정 스키마보다 링킹의 유연성이 낫다”고 잘라 말한다. 데빈은 그래프가 쿼리 언어 중심이라 훨씬 구조적이며, 위키는 시맨틱 공간(유사한 개념끼리 가까이 있는)에 더 잘 어울린다고 덧붙인다.
벡터 데이터베이스 질문(제프에게 직접)에는 농담 섞인 답이 나온다 — “벡터 데이터베이스가 뭔지 아무도 나한테 제대로 정의해준 적이 없다. a16z가 만들어낸 용어일 뿐 아닌가. 요즘은 모든 DB가 벡터 검색을 지원하니 결국 모든 DB가 벡터 DB다.” Chroma가 푸는 진짜 문제는 여전히 “대량의 비정형 데이터를 저장하고 검색 가능하게 만드는 것”이라고 재확인한다.
[40:22] 12. Q&A — 위키가 틀렸거나 오래됐는지 어떻게 아는가
“위키가 틀렸거나 오래됐다는 걸 어떻게 알 수 있나, 검증 프록시가 필요한가”라는 질문에 브레이스는 OpenWiki의 open-questions 파일 개념을 다시 든다 — 에이전트가 새 컨텍스트를 추가할 때 그게 나중에 낡을 수 있다고 판단되면 스스로 “이 날짜쯤 다시 확인” 메모를 남긴다. 사람이 이 데이터를 절대 안 보고 손대지 않는다고 가정하면(손댄다면 사람이 감사(audit)하면 되므로), 프롬프트 차원에서 “낡을 수 있는 것을 적어두고 나중에 되돌아보게” 유도하는 게 지금 가능한 최선이라는 것. 데빈은 다시 “지식은 결과적 일관성을 갖는다”는 원칙을 반복하며, 가장 단순한 자기 교정 루프는 “에이전트가 읽는다 → 틀렸다는 걸 발견한다 → 고치는 툴을 쓴다” 세 단계뿐이라고 요약한다.
[43:38] 13. Q&A — 에이전트를 위키에 어떻게 노출할 것인가(파일시스템 vs 검색)
마지막 질문은 “파일시스템 오퍼레이션/bash 검색 툴 중 무엇이 최선인가”다. 데빈은 코드베이스처럼 큰 디렉터리에서 특정 컨텍스트를 찾을 때 에이전틱 검색(파일시스템 툴만 사용)이 실제로 잘 작동한다고 하면서도, 유일한 정답은 아니라며 풀텍스트 검색(키워드), 시맨틱 검색을 섞어 쓰는 편이 낫고, 그 검색 모드를 에이전트가 스스로 고르게 할지 매번 다 던져줄지는 아직 미지수라고 답한다. 제프는 여기서 “bitter lesson을 검색에 적용하면” — 토큰을 아끼려고 매 쿼리마다 파일 85개를 재발견하게 만드는 방식에 대한 “잘못된 정보”가 많이 퍼져 있다며, 대신 에이전트에게 모든 도구를 주고(grep 같은 패턴 탐색, sparse/dense 벡터 검색 모두) 최선의 조합과 순서를 에이전트가 알아서 찾게 하는 게 맞다고 주장한다. 그는 또한 파일시스템이 이 데이터의 “정착지(data-at-rest)” 표현으로 오래갈 것이라 생각하지 않는다 — 파일시스템은 빠른 파일 접근(린팅 등)엔 강하지만 버전 관리·접근 제어·발견성(discovery)엔 취약하다며, “데이터베이스가 왜 발명됐는지에는 이유가 있다”고 못박는다. 저장 방식과 LLM에 노출하는 방식은 서로 얽힌 문제이며, 결국 에이전트에게 읽기·쓰기·검색 중 무엇을 얼마나 줄지가 저장 형태를 거꾸로 결정한다는 데 의견이 모이며 시간 종료로 마무리된다.
핵심 개념·용어 메모
- 위키 = 캐시(데빈) — 지식을 필수 지식(문서화 없이는 접근 불가)과 기능적/캐시 지식(재탐색 비용을 줄여주는 것)으로 나누고, 캐시처럼 자주 쓰이거나 재계산이 비쌀 때만 캐싱할 가치가 있다는 프레이밍.
- 위키 = 새로운 인덱스(제프) — 인덱스 없음(guess-and-check) → 임베딩(지형만 있음, 여전히 guess-and-check) → 위키(도로망·파이프 추가, 에이전트 이동성 향상)로 이어지는 3단계 비유.
- 컴파일된 지식(compiled knowledge) — 카파시 트윗 기반, 소스를 인제스천해 압축된 인덱스로 만드는 LLM 위키 특유의 성격.
- 지식의 결과적 일관성(eventually consistent knowledge, 데빈) — 위키 항목이 당장 틀려도 에이전트의 자기 교정 루프(읽기→오류 발견→수정 툴 사용)만 있으면 장기적으로 옳아진다는 원칙. 토큰 효율은 일부 희생.
- 에이전트 우선 위키의 형태(데빈의 핫테이크) — 사람 지향적 산문 대신 간결·고참조밀도 문체, 그리고 접근 안 되는 지식은 삭제(eviction)하는 구조.
- 하니스/루프 엔지니어링(제프) — 지금은 “프롬프트 엔지니어링 시대”지만 곧 “루프/하니스 엔지니어링” 단계로, 궁극적으로는 에이전트가 스스로 사람에게 개입을 요청하는 단계로 갈 것이라는 전망.
- open-questions 파일(브레이스, OpenWiki) — 에이전트가 모르는 걸 지어내는 대신 질문으로 남겨두고 나중 실행에서 스스로/사람이 답을 채우는 메커니즘. 자세한 구현은 2026-07-11-openwiki-brains-general-purpose-memory-for-agents 참고.
- 위키 vs 지식 그래프(RDF/Neo4j) — 세 패널 모두 엄격한 그래프 스키마보다 위키의 자유로운 하이퍼링크가 에이전트에 더 적합하다고 평가.
- bitter lesson을 검색에 적용(제프) — 토큰 절약을 이유로 검색 도구를 제한하기보다, 에이전트에게 모든 검색 수단(파일시스템, 풀텍스트, 시맨틱)을 주고 스스로 최적 조합을 찾게 하는 편이 낫다는 입장.
등장한 사람·조직·키워드
해리슨 체이스(Harrison Chase, LangChain 공동창업자·CEO, 진행), 브레이스 스프라울(Brace Sproul, LangChain Applied AI 총괄), 데빈 스타인(Devin Stein, DOSU 창업자), 제프 후버(Jeff Huber, Chroma 창업자·CEO), OpenWiki(LangChain, openwiki personal --init), DOSU(MCP 기반 지식 인프라, “라이브러리언 에이전트”), Chroma, Context One(Chroma의 에이전틱 검색 모델), 카파시(Andrej Karpathy)의 LLM 위키 트윗, 딥위키(Cognition, DeepWiki), Claude Code, SWE-bench, RDF triple store, Neo4j, 구글 OKF(Open Knowledge Format), LangChain Interrupt(런던·뉴욕 컨퍼런스 예고).
원문 인용 모음
- [08:33] “When I think of a wiki, naively I think of kind of like a set of files in some directory structure that is usually like generated by an agent and usually for an agent.” — 해리슨의 소박한 정의.
- [09:44] “I think that definition of wiki is overfit to the technology and overfit to the use case in some ways.” — 제프의 반박.
- [11:02] “I think for the LLM wiki… I really think of it as like that compiled knowledge aspect… each page is acting, I mean I’m biased, but as like a cache basically.” — 데빈, 위키=캐시 비유.
- [17:57] “Wiki’s, you know, generally true, but I think… we’re going to think of it more as a cache or an index.” — 데빈의 핫테이크.
- [17:20] “The thing that I don’t love about wikis today… it’ll look like a wiki for a human… there’s an expectation that someone’s reading it sort of front to back.” — 데빈.
- [17:38] “It’s just the way we talk about wikis today is very human oriented.” — 데빈, “위키는 틀린 추상화” 핫테이크의 근거.
- [17:53] “Knowledge is eventually consistent. Meaning that if it is incorrect, as long as you kind of build in self-correcting mechanisms, it’ll ultimately be fixed in the future.” — 데빈.
- [24:24] “if you get 300 updates into your wiki… getting it to identify where in the wiki to update… I think that’s probably the most difficult part.” — 브레이스, 유지보수 난제.
- [26:44] “when you have something at that scale figuring out what is important is actually a hard problem.” — 데빈, 대규모 코드베이스의 생성 난제.
- [29:44] “runs can cost about half as much because it’s doing less context gathering.” — 데빈, ROI 내부 벤치마크.
- [39:41] “I don’t know what a vector database is. No one’s ever given me a good definition of a vector database.” — 제프.
- [41:20] “The RDF triple store, Neo4j style rigid graph database thingy… too opinionated… you want linking, you don’t actually want like noun verb noun.” — 제프, 위키 vs 지식 그래프.
- [43:38] “What’s the best way to expose an agent to the wiki? File system operations slash bash search tools.” — 청중 질문.
- [44:20] “I don’t think that file systems are or will be the… data at rest representation of this data… they’re bad at version control… access control… discovery.” — 제프.
관련 노트
- 원본 자막:
raw/transcripts/2026-07-11-llm-wikis-and-how-to-give-your-agents-memory.en.srt - 같은 발표자(브레이스)의 OpenWiki 데모 상세: 2026-07-11-openwiki-brains-general-purpose-memory-for-agents
- OpenWiki 도구 자체: openwiki
- 본문에 언급된 Google OKF(Open Knowledge Format): 2026-06-18-open-knowledge-format-data-sharing
- 데빈이 인용한 카파시의 LLM 위키 원출처: 2026-04-03-karpathy-llm-knowledge-bases
- 상위 허브: moc-llm-wiki, moc-ai-agents-memory
이 영상에서 얻을 수 있는 것
세 가지 멘탈 모델
- 위키 = 캐시(데빈) — 지식을 ①필수 지식(문서화 없으면 접근 불가)과 ②기능적 캐시 지식(재탐색 비용을 줄여주는 것)으로 나눈다. “DB 전체를 캐시로 만들면 동기화 비용이 폭발”하므로 자주 쓰거나 재계산이 비싼 것만 캐싱한다.
- 위키 = 새로운 인덱스(제프) — 인덱스 없음(찍어보기) → 임베딩(지형만) → 위키(도로망·배관 추가로 에이전트 이동성↑).
- 컴파일된 지식(카파시) — 소스를 매번 재탐색하지 않도록 압축된 인덱스로 컴파일해 둔 것.
실무 교훈
- 만드는 것보다 유지가 더 어렵다. 업데이트가 300번쯤 쌓이면 에이전트가 기존 문장을 고치는 대신 새 줄만 삽입해 위키가 비대해진다 → 업데이트 프롬프팅과 삭제(eviction) 설계가 관건.
- 에이전트 우선으로 다시 설계하라. 사람용 산문 대신 간결·고참조밀도 문체, 접근 안 되는 지식은 삭제.
- 지식은 결과적 일관성을 갖는다. “읽기→오류 발견→수정 툴 사용” 자기 교정 루프만 있으면 틀린 캐시도 언젠가 바로잡힌다 → 모든 변경을 사람이 승인할 필요 없음.
- 검색엔 bitter lesson. 도구를 제한하지 말고 에이전트에게 모든 검색 수단(grep·풀텍스트·시맨틱)을 주고 스스로 조합을 고르게 한다.
판단에 도움되는 관점
- ROI 측정 — 벤치마크는 오염돼 무의미. 대신 “같은 답에 도달하는 툴콜·토큰이 줄었는지”, “결과 일관성이 높아졌는지”를 본다. DOSU 내부 지표로 위키 있는 주제의 실행 비용은 약 절반.
- 위키 vs 지식 그래프 — RDF/Neo4j 같은 경직된 그래프는 “너무 옵션이 많다” → 자유로운 하이퍼링크가 에이전트에 더 적합.
- 파일시스템의 한계 — 빠른 접근엔 강하지만 버전 관리·접근 제어·발견성엔 약해 최종 저장소로는 부적합할 것.
에이전트 장기 메모리 관점에서의 함의
이 웨비나는 제목대로 “에이전트에게 메모리를 주는 법”을 다루지만, 인지과학적 의미의 메모리 전 영역이 아니라 저장·유지·경제학에 초점이 맞춰져 있다. 그럼에도 장기 메모리 설계에 직접 쓸 수 있는 고찰이 있다.
주는 것
- 장기 메모리 = 압축된 캐시 — “무엇을 기억할 가치가 있는가”라는 본질적 질문을 필수 지식/캐시 지식 구분으로 정리한다. 인간 기억이 모든 경험을 저장하지 않고 선택적으로 응고(consolidation)하는 것과 대응된다.
- 망각(eviction)이 기능이다 — “더 많이·더 오래 저장”에 매몰되는 통념과 달리 “접근 안 되면 삭제”를 명시적 설계 원리로 삼는다. 망각은 버그가 아니라 일반화·추상화를 낳는 기능.
- 통합(reconsolidation)이 진짜 난제 — “300번째 업데이트에서 새 줄만 삽입” 문제는 저장이 아니라 기존 기억을 새 정보와 합치는 게 어렵다는 걸 보여준다. RAG/벡터DB로는 안 풀린다.
- 결과적 일관성 = 자기 교정하는 기억 — 장기 메모리를 정적 저장소가 아니라 살아있는 프로세스로 보게 한다.
다루지 않는 것
- 에피소딕(일화) vs 시맨틱 메모리 구분 — 위키=컴파일된 시맨틱 지식만 논하고 “언제 무슨 일이 있었나”는 거의 없음.
- 회상(retrieval)의 인지 모델 — 검색 도구 얘기는 있으나 “관련 기억이 어떻게 떠오르는가”의 이론은 없음.
- 개인화·정체성 층위 — 에이전트의 지속적 자아·선호 학습은 깊이 다루지 않음.
정리 — 장기 메모리를 “조직·프로젝트 지식의 압축된 인덱스”로 좁게 보면 뛰어난 1차 자료(특히 무엇을 기억할지의 경제학과 망각의 설계). 반면 에이전트 개인의 경험 축적·정체성으로서의 장기 메모리를 찾는다면 출발점이지 완결편은 아니다.