Karpathy''s LLM Wiki Gave Hermes Agent Real Memory

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Karpathy의 LLM Wiki 아이디어를 적용한 Hermes 구축 사례는 업무 맥락을 공유 Markdown 위키에 저장해, 세션과 에이전트가 바뀌어도 다시 활용할 수 있는 기억 구조를 보여준다.

📌 핵심 요점

1. 기억을 에이전트 밖에 저장한다. 고객 정보·과거 결정·연구 자료를 서버의 공유 위키에 남기고, 에이전트가 답변 전에 조회하고 작업 후 갱신하게 한다. 원문 근거와 지식 간 연결도 함께 보존한다.
2. 파일 구조와 사용 규칙을 통일한다. 원자료인 raw와 가공 지식인 processed를 분리하고, 가공 지식은 개인·사업·연구 영역으로 나눈다. index.md, log.md, wiki.md와 공통 스킬, SOUL.md의 조회 규칙으로 여러 에이전트의 접근 방식을 맞춘다.
3. 수집 경로마다 실제 작동 범위를 확인한다. URL 수집과 파일 투입함의 30분 주기 처리를 구성했으며, YouTube 자막 플러그인이 실패하자 기본 웹 추출로 대체했다. Gmail 접근은 확인했지만 이메일 전체를 위키에 반영하는 작업은 시연에서 생략했다.
4. 기억의 품질을 정기적으로 관리한다. 외부 자료의 명령은 실행하지 않고, 제3자의 주장을 사용자 사실로 자동 전환하지 않는다. 야간에는 모순·오래된 정보·누락된 링크를 살피고, 별도 검사로 비밀정보·분류·출처를 확인하도록 구성한다.
5. 공유 작업 공간과 복구 경로를 함께 만든다. 여러 에이전트는 VPS의 동일한 위키를 사용하고, 로컬 Git 이력과 비공개 GitHub 사본으로 복원을 준비한다. 대시보드에는 실제 위키 데이터를 연결했으며, GitHub에서도 복사된 폴더를 확인했다.

🧩 배경과 문제 정의

• 에이전트가 몇 주 전 작업을 기억하지 못하고, 서버 장애나 AI 제공자·에이전트 교체 때 누적된 업무 맥락을 잃는 문제가 출발점이다.
• 기억을 에이전트 내부에서 분리해 서버의 Markdown 위키에 저장하고, 여러 에이전트가 같은 지식을 읽고 갱신하는 구조를 만든다. 각 주장은 원문 출처까지 추적할 수 있도록 설계한다.
• 공동 위키를 유지하려면 분류·검색·기록 규칙을 통일하고, 외부 자료의 주장을 사용자에 관한 사실과 구분해야 한다. 프롬프트 주입, 비밀정보 유입, 오래된 정보와 모순도 관리 대상이다.
• 실습은 Hermes 에이전트 다섯 개를 바탕으로 위키 구조와 사용 규칙을 만들고, 기존 기억·웹 자료·YouTube 자막·파일·이메일을 지식으로 연결하는 과정을 다룬다.

🕒 시간순 섹션별 상세정리

1. 에이전트와 분리된 공유 위키로 기억을 유지한다

• 고객·스폰서·과거 결정·웹 자료를 Markdown 파일로 저장하고, 에이전트가 답변 전에 읽고 작업 후 기록하는 구조다. 지식 사이의 연결을 표시하며, 주장의 근거 원문도 보존한다 [02:12]
• 기억을 위키에 두면 다른 AI 제공자나 에이전트로 옮겨도 같은 맥락을 재사용할 수 있다는 구상이다. 여러 종류의 에이전트가 하나의 위키를 함께 읽고 쓰도록 한다 [02:17]

2. 역할별 Hermes 에이전트와 지휘 담당을 구성한다

• 실습 환경은 총괄 Orchestrator, 조사 Scout, 글쓰기 Scribe, 마케팅 Reach, 개발 Dev로 구성된다. 대시보드에서는 사용 모델을 바꾸고 에이전트의 대기 상태를 확인할 수 있다 [02:27]
• Telegram 그룹 안에 에이전트별 전용 채널을 두어 대화 맥락을 분리한다. 위키 구축은 다른 에이전트에 공통 규칙을 전파하기 편한 Orchestrator가 맡지만, 다른 Hermes 에이전트로도 진행할 수 있다 [03:03]

3. 구축 전에 설계 의도와 실제 환경을 확인한다

• 초기 브리핑은 Karpathy의 LLM Wiki 아이디어와 Hermes 문서를 읽고, 프로필·스킬 구조를 이해하도록 한다. 위키에 원자료와 가공 자료를 나누어 저장하며, 한 번에 하나의 프롬프트씩 진행하도록 범위를 제한한다 [04:38]
• Orchestrator는 사용 중인 프로필과 도구, Hermes 버전과 폴더 위치, 에이전트 구성을 확인한다. 이 응답을 바탕으로 현재 설치 환경과 구축 목표가 맞는지 점검한다 [05:30]

4. 원자료와 가공 지식을 나누고 탐색용 파일을 만든다

• wiki 아래에 raw와 processed를 둔다. 이메일이나 영상 URL 등으로 들어온 자료는 원자료 영역에 저장하고, 이후 에이전트가 가공해 위키에 반영하는 방식이다 [06:11]
• 가공 자료는 personal, business, research로 나눈다. 사용자와 가족 관련 내용은 개인 영역, 판매·사업 관련 내용은 사업 영역, 영상·웹 문서·GitHub에서 읽은 내용은 연구 영역에 넣는다 [06:54]

5. 공통 스킬로 위키 접근 방식을 통일한다

• 에이전트마다 서로 다른 방식으로 위키를 다루지 않도록 전용 스킬을 만든다. 모든 에이전트가 같은 지침을 읽고 이를 공통 진입점으로 사용하게 하는 것이 목적이다 [08:26]
• Orchestrator의 완료 응답에는 스킬 생성, Scout·Scribe·Reach·Dev 각 프로필에 대한 설치, 작동 검증이 포함된다 [09:06]

6. SOUL.md에 답변 전 위키 조회 규칙을 넣는다

• 위키 사용법을 대화로만 전달하면 이후 세션에서 잊을 수 있다. 매 세션 읽는다고 설명된 SOUL.md에 위키 사용 규칙을 넣어 반복적으로 상기시키는 방식을 택한다 [09:28]
• 모든 프로필에 답변 전 위키 인덱스를 확인하고, 위키에 답이 없으면 한 줄로 알린 뒤 질문 하나를 하도록 규칙을 추가한다. 자료를 기록할 세션에서는 시작할 때 위키 규칙도 확인하게 한다 [11:21]

7. 이름으로 시작하는 응답을 규칙 적용의 확인 신호로 삼는다

• 응답마다 사용자 이름을 포함하도록 SOUL.md에 적어 두면, 이름이 빠진 메시지를 규칙 적용이 어긋났을 가능성을 확인하는 신호로 활용할 수 있다는 아이디어다. 이 방법의 고안자로 언급한 인물에 대해서는 확신하지 않는다 [12:25]
• 실제 적용에서는 모든 에이전트가 응답을 소유자 이름인 Larry로 시작하도록 하고, 조용히 실행해야 하는 예약 작업은 예외로 둔다 [13:46]

8. 기존 기억을 옮겨 빈 위키를 채운다

• Orchestrator가 이미 아는 사용자 신원, 하는 일, 사업과 고객 정보를 위키에 기록하도록 한다. 실습 환경은 새로 만든 설치라 이름·YouTube 채널·웹사이트 등 기본 정보만 알고 있다 [15:10]
• 개인 정보, 사업, 콘텐츠 전략, 에이전트 구성 등에 관한 페이지가 생성된다. 가족 정보는 기록된 내용이 없다고 남기며, 초기 위키의 풍부함은 기존에 축적한 맥락의 양에 달려 있다 [15:47]

9. 외부 자료의 명령과 주장을 사용자 사실에서 분리한다

• 인터넷 자료에는 규칙을 무시하거나, 소유자가 500유로를 빚졌다고 기록하거나, API 키를 보내라는 악성 문구가 들어갈 수 있다. 이런 문구는 실행하지 않고 해당 자료가 명령을 시도했다는 사실만 기록하도록 한다 [16:32]
• 개인·사업 영역은 사용자의 실제 맥락을 다루고, 연구 영역은 출처가 붙은 제3자의 주장과 개념 연결을 담는다. 외부 주장을 사용자에 관한 사실로 자동 승격하지 않으며, raw에는 수집한 근거 자료를 둔다 [17:24]

10. URL 수집을 연구 담당에게 맡기고 중복을 처리한다

• URL을 전달하면 위키에 넣는 수집 절차를 만들고, 현재 에이전트 중 역할이 가장 가까운 담당자를 선택한다. 이미 저장된 자료의 갱신이면 기존 연구 페이지를 업데이트하고 그 사실을 알리도록 한다 [17:44]
• 비밀정보는 수집하지 않으며, 원자료는 날짜와 짧은 식별 이름을 붙여 저장하도록 한다. 이 환경에서는 외부 자료와 출처 근거를 담당하는 Scout가 수집 역할을 맡는다 [18:31]

11. YouTube 자막 추출 실패에 대체 경로를 적용한다

• 이 구성의 YouTube 수집은 영상을 시각적으로 보는 대신 자막을 내려받아 내용을 파악하는 방식이다. 긴 영상의 내용을 요약하기 위해 yt-dlp를 이용한 추출 기능을 추가한다 [19:40]
• 설치한 기능은 해당 서버에서 YouTube의 봇 차단에 걸린다. VPN이 원인일 가능성을 제시하지만 확정하지는 않으며, Hermes의 기본 웹 추출 기능과 비교하도록 영상 두 개를 더 시험한다 [20:45]

12. 파일 투입함을 30분마다 확인해 위키에 반영한다

• 청구서 같은 파일을 채팅으로 전달해 수집하거나, 웹 대시보드에서 URL을 붙여 넣고 파일을 끌어다 놓는 입력 방식을 구상한다 [22:19]
• 입력 자료는 raw/inbox에 들어가고, 예약 작업이 30분마다 새 파일을 확인해 미처리 항목을 가공한다. Orchestrator는 이 자동 처리 설정을 완료했다고 응답한다 [22:44]

13. 이메일 지식을 축적하기 위해 Composio로 Gmail을 연결한다

• 고객의 기술 질문과 사용자의 답변을 위키에 쌓으면, 이후 비슷한 이메일의 답장 초안을 작성할 때 과거 대응을 참고할 수 있다 [23:16]
• 고객·스폰서에게 안내한 서비스 가격도 기록 대상으로 삼는다. 이메일에서 가격이 바뀌면 위키도 갱신해 에이전트가 최근 업무 정보를 활용하도록 하는 구상이다 [23:48]

14. Composio로 이메일을 연결하고 위키의 입력 자료를 확보한다

• 서버에 Composio CLI를 설치하고 로그인 URL에서 계정을 승인하면, 오케스트레이터가 Composio에 연결된 앱에 접근할 수 있다. 마케팅 에이전트 Reach는 메일함의 보안 알림 등을 확인해 실제 이메일 접근을 검증했다 [26:04]
• 프롬프트 10B는 이메일을 훑어 중요한 정보를 위키에 추가하도록 설계됐다. 사업 정보가 이메일에 많이 남아 있다는 점을 활용하지만, 전체 처리에는 시간과 토큰이 필요해 이 시연에서는 실행을 생략했다 [26:38]

15. 야간 점검으로 정보 충돌과 비밀정보 노출을 관리한다

• 사서 역할의 에이전트는 매일 2시 30분에 위키의 마크다운 파일을 살펴본다. 같은 계약이 500달러와 700달러로 다르게 기록된 경우 같은 모순, 불필요한 페이지, 누락된 링크와 미해결 항목이 점검 대상이다 [27:51]
• 검사 역할의 에이전트는 20분 뒤 API 키 등 비밀정보, 잘못된 분류, 누락된 출처를 점검한다. 결과는 Telegram으로 알리고, 사업 맥락을 몰라 판단할 수 없는 모순은 사용자에게 확인한다 [28:54]

16. Claude Code를 VPS에 연결해 기존 구축 작업을 이어간다

• 대시보드는 기존 오케스트레이터로도 만들 수 있지만, 이 시연에서는 Claude Code를 사용한다. 데스크톱에서 SSH 연결을 추가하고 VPS의 사용자 이름과 IP 주소를 입력해 서버에 접근한다 [30:22]
• 시연자의 경험상 root 계정으로는 데스크톱 연결이 되지 않아 별도 사용자 계정에 Hermes를 설치했다. 권한 문제일 가능성을 추측했으며, root에 설치된 환경의 대안으로 VPS 터미널에서 Claude Code를 직접 설치·실행하는 방법을 제시했다 [31:15]

17. 기존 에이전트 구성을 파악하고 대시보드 서버를 준비한다

• 인수인계 프롬프트는 기존 마크다운 위키와 Hermes 문서·설정을 읽도록 한다. Claude Code는 기본 에이전트와 Dev·Reach·Scout·Scribe, 각 파일 위치와 위키 경로를 확인했다. 기본 목록에 보이지 않는 예약 작업은 프로필별 작업이라는 설명이 붙었다 [32:50]
• 대시보드는 가벼운 Python 서버로 구성하고 HTML 템플릿을 받을 업로드 경로를 만든다. 서버 부담이 작을 것으로 설명됐지만, 이 구간에 성능 측정 결과는 제시되지 않았다 [33:17]

18. HTML 템플릿의 예시 데이터를 실제 위키 데이터로 바꾼다

• SSH 터널을 연 뒤 업로드 페이지에 HTML 템플릿을 올리고, 이를 실제 대시보드로 제공하도록 설정했다. Claude Code에는 페이지 내용을 읽어 템플릿 구조도 파악하도록 했다 [34:36]
• 초기 템플릿의 API 경로는 아직 구현되지 않아 404 오류가 발생했다. 화면에 보이는 값도 하드코딩된 예시였으므로, 서버의 실제 지표와 위키 데이터를 연결하는 작업이 필요했다 [35:34]

19. 자료 입력·검색·수동 점검을 대시보드에서 실행한다

• 대시보드의 자료 입력 버튼은 URL과 문서를 위키에 수집하고, 검색 버튼은 저장된 내용을 조회하도록 연결한다. 린트 버튼은 매일 예약 실행되는 위키 건강 점검을 수동으로 시작하는 용도다 [36:28]
• 기능 연결 후 Claude Code는 테스트가 정상이라고 보고했다. 화면에는 사업·연구 항목을 따로 보거나 함께 보는 필터가 있으며, URL·PDF·문서 입력, 위키 조회, 린트 실행 기능이 연결된 상태로 설명됐다 [37:14]

20. 로컬 변경 이력과 서버 외부 사본으로 복구 경로를 만든다

• 장기간 쌓은 위키를 에이전트가 잘못 수정할 가능성에 대비해, 로컬 Git 저장소에 매일 스냅샷을 남기는 구성을 만든다. 문제가 생기면 이전 상태로 복원하는 것이 목적이다 [37:42]
• 로컬 사본만으로는 VPS 자체의 장애나 데이터 손실에 대응하기 어렵다. GitHub 같은 외부 서비스에도 사본을 자동으로 보내 두면, 기존 서버나 새 서버로 위키를 가져와 복구할 수 있다 [38:20]

21. 여러 에이전트가 하나의 VPS 위키를 공유하도록 구성한다

• Claude Code·Codex·Hermes 등 여러 에이전트는 GitHub 사본에 각각 쓰는 대신, VPS에 있는 동일한 위키를 읽고 쓰도록 구성한다. 다른 에이전트의 서버 접근에는 Tailscale을 활용하는 방안이 제시됐다 [39:25]
• 제안된 운영 구조는 한 서버에서 지식을 갱신하고, 에이전트가 매일 위키를 점검하며, 그 결과를 매일 GitHub로 보내는 방식이다. 공유 작업 공간, 정기 유지보수, 외부 백업을 함께 운용한다 [39:59]

22. 비공개 GitHub 저장소와 제한된 토큰으로 백업 권한을 설정한다

• 위키 백업용 GitHub 저장소는 비공개로 만든다. 공개 저장소로 설정하면 다른 사람도 내용을 볼 수 있으므로, 개인·사업 지식이 담긴 위키의 공개 범위를 주의해야 한다 [40:36]
• 세분화된 개인 액세스 토큰은 대상 저장소만 선택해 접근 범위를 제한한다. 시연에서는 만료 기간으로 90일을 선택했으며, 만료 없는 설정도 선택지로 언급했다 [41:54]

23. 토큰 입력 오류를 수정하고 원격 백업 결과를 확인한다

• 로컬 백업 작업에서는 Claude Code가 테스트 중 발견한 버그를 수정했다고 보고했다. 이어 비공개 GitHub 저장소에 매일 외부 사본을 만드는 작업과 토큰 입력용 터미널 명령을 준비했다 [43:29]
• 첫 명령은 소유자 이름 입력 뒤 예상한 토큰 입력으로 이어지지 않았고, 수정된 명령으로 토큰을 저장한 뒤에도 접근이 실패했다. 저장소 URL을 전달하고 다시 받은 명령에서 저장소 항목은 비운 채 토큰을 입력하자 설정과 푸시가 진행됐다 [44:55]

24. 에이전트 교체 후에도 지식을 유지하고 설치 비용을 줄이는 방향을 제시한다

• 사업·연구 자료와 연결이 축적되면 위키의 활용도가 높아질 것으로 기대한다. Claude Code에서 Codex 등 다른 에이전트로 바꾸더라도 GitHub에 남은 지식을 새 에이전트에 연결해 기존 맥락을 이어갈 수 있다는 것이 최종 활용 방향이다 [45:50]
• 전체 위키 구성을 수분 안에 만들 수 있을 가능성을 목표로 자동 설치기를 개발 중이다. 현재 프롬프트와 템플릿으로 구축하면 AI 토큰이 들며, 자동 설치기는 그 비용을 줄이려는 구상으로 아직 완료된 결과는 아니다 [46:20]

🧾 결론

• 이 사례의 기억은 Markdown 지식 저장소와 조회·기록 규칙을 결합한 구조다. 세션이 끝나도 파일에 남은 맥락을 다음 작업에서 활용하도록 설계한다.
• 지속적인 활용에는 저장 기능뿐 아니라 출처 보존, 공통 분류, 정보 갱신, 모순 확인이 필요하다. 구축 직후 위키의 내용은 기존에 축적한 정보량에 영향을 받는다.
• 시연은 일부 수집·조회·접근·백업 결과를 보여주지만, 장기간 운영의 정확성과 안정성을 입증한 결과까지 제시하지는 않는다.

📈 투자·시사 포인트

• 업무 지식을 별도 위키에 보존하는 구조는 AI 제공자나 에이전트를 바꿀 때 기존 맥락을 재사용하는 방향을 제시한다. 실제 전환 편의성은 새 에이전트의 접근과 규칙 적용을 확인해야 판단할 수 있다.
• 고객 질문·답변과 서비스 가격을 축적하면 이후 답장 초안과 업무 판단에 과거 정보를 활용할 수 있다. 다만 이메일 전체 수집을 생략했으므로 생산성 개선 규모는 이 시연만으로 산정하기 어렵다.
• 도입 비용을 볼 때 초기 구축 토큰뿐 아니라 수집·가공·야간 검사에 필요한 자원도 함께 살펴야 한다. 비용을 줄이려는 자동 설치기는 개발 중인 구상으로 소개됐다.
• 도구 선택에는 실제 환경에서의 검증이 필요하다. 이 서버에서는 추가 자막 플러그인보다 Hermes 기본 추출이 안정적으로 보였고, 대시보드도 예시 데이터를 실제 위키에 연결한 뒤 표시 내용이 달라졌다.

⚠️ 불확실하거나 확인이 필요한 부분

• 예약 수집과 야간 점검은 설정 완료 응답이 중심이다. 장기간 누락 없이 실행되는지, 정보 충돌을 얼마나 정확히 찾아내는지는 추가 확인이 필요하다.
• YouTube 추출 실패의 원인을 VPN으로 확정하지 않았다. 기본 추출 결과도 일부 발화와 일치함을 확인한 수준이므로 모든 영상의 자막 완전성을 보장하지 않는다.
• Gmail 연결과 실제 메일 접근은 확인했지만, 이메일을 대량 처리해 위키에 반영하는 단계는 실행하지 않았다. 처리 비용·시간·정보 선별 품질은 미확인이다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 Hermes 버전·프로필·도구·위키 경로를 확인하고, 원자료와 가공 지식의 저장 위치를 정한다.
• 개인·사업·연구 분류와 출처 기록 방식을 정하고, 공통 스킬 및 세션 시작 규칙에 위키 조회 절차를 반영한다.
• URL·영상·파일을 각각 소량 투입해 원자료 보존, 가공 페이지 생성, 중복 갱신과 실제 내용의 일치를 확인한다.
• 외부 자료의 명령을 실행하지 않고 제3자의 주장과 사용자 사실을 구분하는지 점검한다. 비밀정보 검사와 판단하기 어려운 모순의 사용자 확인 절차도 검증한다.

❓ 열린 질문

• 여러 에이전트가 같은 위키를 동시에 수정할 때 덮어쓰기나 충돌을 어떻게 감지하고 해결할 것인가?
• 지식이 늘어난 뒤에도 인덱스 기반 조회와 야간 점검이 필요한 정보를 정확하게 찾고 유지할 수 있는가?
• 가격이나 계약 내용이 충돌할 때 최신 정보와 유효한 근거를 판별하는 기준은 무엇이며, 어디까지 사용자 확인이 필요한가?