Hermes Agent와 LLM Wiki로 AI 비서 장기 기억 설계하기
AI 에이전트를 쓰다 보면 처음에는 모델 성능이 가장 중요해 보입니다.
좋은 모델을 고르면 더 똑똑하게 답하고, 더 긴 코드를 읽고, 더 복잡한 작업도 처리합니다. 하지만 며칠 이상 운영해보면 모델 성능보다 다른 문제가 더 크게 보입니다.
에이전트가 매번 같은 설명을 다시 요구합니다. 지난번에 정한 운영 규칙을 잊고, 이미 실패했던 방법을 반복하고, 프로젝트별 맥락을 새 세션마다 다시 읽어야 합니다.
모델만 바꿔서는 해결할 수 없습니다.
Hermes Agent와 LLM Wiki를 결합하면, 에이전트가 매번 맥락을 새로 읽지 않아도 됩니다.
1. 핵심 요약 — 이 글에서 기억할 5가지
Hermes Agent는 사용자의 터미널, Telegram 같은 메시징 채널, 크론 작업, 도구 호출을 연결하는 실행 계층입니다. LLM Wiki는 에이전트가 반복해서 읽고 쓸 수 있는 외부 지식 계층입니다.
Hermes Agent가 실행을 담당하고, LLM Wiki가 장기기억을 담당합니다.
- 기존: 사용자가 매번 맥락을 다시 설명한다.
- 이후: 에이전트가 Wiki에서 맥락을 읽고, 필요한 작업을 이어간다.
이 글의 핵심은 다섯 가지입니다.
- Hermes Agent의 Memory는 작고 선별된 개인/환경 기억에 적합합니다.
- Skills는 반복 절차를 저장하는 실행 지식입니다.
- LLM Wiki는 프로젝트 지식, 결정 이유, 실패 기록, 운영 문서를 담는 외부 장기기억입니다.
- Gateway / Cron / Profiles / Kanban은 Wiki를 실제 운영 루프로 연결하는 실행 장치입니다.
- 중요한 정보는 무조건 저장하지 말고, 저장 기준과 검증 루프를 함께 설계해야 합니다.
이 글의 출처 확인 범위는 아래 3번 섹션에 따로 모았습니다.
2. 검증 범위와 한계
이 글에서 말하는 Hermes Agent는 Nous Research의 Hermes Agent 문서와 NousResearch/hermes-agent GitHub 저장소를 2026-06-24에 확인한 범위를 기준으로 합니다. 같은 “Hermes” 이름이 LLM 모델 계열에도 쓰이므로, 여기서는 모델명이 아니라 에이전트 프레임워크인 Hermes Agent를 가리킵니다.
다만 이 글은 제품 명세 문서가 아니라 운영 패턴 설명입니다. 그래서 아래처럼 확인된 기능과 LLM Wiki와 연결한 운영 해석을 구분합니다.
| 구분 | 2026-06-24에 확인한 1차 출처 |
|---|---|
| Hermes Agent 정체 | Hermes Agent Documentation, GitHub: NousResearch/hermes-agent |
| Persistent Memory | Persistent Memory 문서 |
| Cron / scheduled tasks | Scheduled Tasks 문서 |
| Profiles | Profiles 문서 |
| Messaging Gateway | Messaging Gateway 문서 |
| Skills | Bundled Skills Catalog |
이 글은 위 기능들을 LLM Wiki와 연결해 하나의 개인 AI 운영 구조로 설명합니다.
GitHub 기준점도 함께 남깁니다.
- HEAD:
6ef6794(6ef679420e901415ddf5a15bc7b90e8df064a556) - 확인한 릴리스 태그:
v2026.6.19(681cd638d3cf0426664b018606df6e3581dd9547)
이 글에서 단정하는 내용은 공식 문서와 GitHub에서 확인한 항목으로 제한합니다. 예를 들어 Persistent Memory, Cron, Profiles, Messaging Gateway, Skills는 각각 공식 문서 페이지가 있습니다. 반면, 이 기능들을 LLM Wiki와 연결해 “개인 AI 운영 구조”로 설계하는 부분은 이 글의 운영 해석입니다.
따라서 실제 도입 전에는 다음을 다시 확인해야 합니다.
- 현재 설치한 Hermes 버전에서 해당 기능이 같은 방식으로 동작하는지
- 사용하는 messaging platform과 provider에서 필요한 도구가 켜져 있는지
- Gateway, Cron, Profile 권한이 조직 보안 정책과 맞는지
- Wiki 자동 수정이 필요한 경우 Git 이력과 사람 승인 경계가 있는지
3. 왜 Hermes Memory만으로는 부족할까요?
Hermes Memory는 중요한 선호와 환경 정보를 작게 보관하는 데 적합합니다.
Persistent Memory 문서(2026-06-24 확인)는 Hermes가 사용자 선호, 프로젝트, 환경 정보, 워크플로우 교훈을 세션 사이에 유지하는 bounded memory를 제공한다고 설명합니다. 출처: Persistent Memory. 이 기억은 작고 선별된 정보에 맞게 설계되어 있으므로, 모든 프로젝트 문서를 넣는 용도로 보기는 어렵습니다.
역할
Memory는 “항상 알아야 하는 짧은 정보”를 저장합니다.
예를 들면 다음과 같습니다.
- 사용자는 한국어 존댓말을 선호한다.
- 특정 프로젝트는 Docker Compose로 실행한다.
- 반복 작업에서는 테스트 결과를 먼저 확인한다.
비유
Memory는 책상 위 포스트잇입니다.
항상 보여야 하는 핵심 규칙을 적어두기 좋습니다. 하지만 모든 회의록, 서버 운영 문서, 블로그 파이프라인, 실패 기록까지 포스트잇에 붙이면 책상이 엉망이 됩니다.
한계
Memory는 일부러 작아야 합니다.
- 길고 복잡한 프로젝트 문서를 담기 어렵습니다.
- 임시 진행상황을 넣으면 금방 오염됩니다.
- 오래된 운영 정보가 섞이면 잘못된 지시가 될 수 있습니다.
- 모든 대화를 저장하면 기억이 아니라 노이즈가 됩니다.
그래서 Memory는 L1 기억으로 두고, 큰 지식은 LLM Wiki에 두는 편이 좋습니다.
4. LLM Wiki는 어떤 역할을 하나요?
LLM Wiki는 Hermes가 매번 다시 읽고 활용할 수 있는 외부 장기기억입니다.
역할
LLM Wiki에는 반복 재사용될 지식을 저장합니다.
예를 들면 다음과 같습니다.
- 프로젝트 구조
- 운영 runbook
- 블로그 발행 절차
- 리서치 토픽 정리
- 중요한 의사결정 이유
- 실패한 방식과 재시도 금지 이유
비유
LLM Wiki는 팀 위키입니다.
사람이 회사를 옮기거나 팀에 새로 합류했을 때 위키를 읽고 업무 맥락을 잡듯, 에이전트도 새 세션에서 Wiki를 읽고 맥락을 이어갈 수 있습니다.
기본 구조
LLM Wiki는 최소 세 계층으로 나누면 관리하기 쉽습니다.
| 계층 | 역할 | 예시 |
|---|---|---|
| Raw | 원본 보존 | 공식 문서, 로그, 회의록, 웹페이지 |
| Wiki | 정리된 지식 | topic, project, runbook, decision |
| Schema | 저장 규칙 | frontmatter, 태그, 검증 기준 |
이 구조의 핵심은 원본과 해석을 분리하는 것입니다. 에이전트가 잘못 요약했을 때 원본으로 되돌아갈 수 있어야 합니다.
5. Skills는 Wiki와 무엇이 다른가요?
Skill은 “어떻게 할지”를 저장하고, Wiki는 “무엇을 알고 있는지”를 저장합니다.
역할 차이
| 구분 | 저장 대상 | 예시 |
|---|---|---|
| Memory | 항상 필요한 짧은 사실 | 사용자 선호, 환경 핵심 정보 |
| Skill | 반복 실행 절차 | 블로그 발행 절차, GitHub PR 절차 |
| Wiki | 설명 가능한 장기 지식 | 프로젝트 구조, 의사결정, 리서치 요약 |
실제 감각
예를 들어 블로그 글을 쓴다고 해보겠습니다.
- Memory는 “사용자는 다크 터미널 테마 이미지를 선호한다”를 기억합니다.
- Skill은 “초안 → 이미지 → 검수 → 발행” 절차를 알고 있습니다.
- Wiki는 “이전 글에서 어떤 구조가 잘 먹혔는지, 어떤 주제를 다뤘는지”를 보관합니다.
세 계층이 나뉘어야 에이전트가 가벼우면서도 오래 기억할 수 있습니다.
6. Hermes Gateway는 어떤 역할을 하나요?
Gateway는 Hermes를 메시징 채널에서 사용할 수 있게 해주는 control plane입니다.
Messaging Gateway 문서(2026-06-24 확인)는 Hermes를 Telegram, Discord, Slack, WhatsApp, Signal, Email 등 여러 채널에서 사용할 수 있게 하는 gateway로 설명합니다. 출처: Messaging Gateway. 이 글에서는 그 gateway를 “사용자가 에이전트를 호출하고 결과를 받는 입구”로 해석합니다.
역할
Gateway는 사용자가 SSH로 서버에 들어가지 않아도 에이전트를 조작하게 해줍니다.
예를 들면 다음과 같은 흐름이 됩니다.
→ Hermes Gateway
→ 에이전트 세션
→ Wiki 맥락 로딩
→ 도구 실행
→ 결과 보고
비유
Gateway는 관제실입니다.
실제 작업은 에이전트와 도구가 하지만, 사용자는 Telegram 같은 익숙한 채널에서 요청하고 결과를 받습니다.
LLM Wiki와 연결되는 지점
Gateway는 단순 채팅창이 아닙니다.
- 위키 검색 요청을 받을 수 있습니다.
- 발행 승인 같은 human-in-the-loop를 처리할 수 있습니다.
- 크론 결과를 같은 채널로 전달할 수 있습니다.
- 여러 profile agent를 사용자가 직접 호출하는 UI가 될 수 있습니다.
Gateway가 LLM Wiki를 사람이 실제로 쓰게 만드는 입구입니다.
7. Cron은 어떻게 장기기억을 움직이나요?
Cron은 LLM Wiki를 방치된 문서가 아니라 살아 있는 시스템으로 만듭니다.
Scheduled Tasks 문서(2026-06-24 확인)는 Hermes가 chat, CLI, natural language, agent-facing tool을 통해 예약 작업을 만들 수 있고, 반복 작업과 일회성 작업, skill-backed job, script-only job 같은 운영 방식을 제공한다고 설명합니다. 출처: Scheduled Tasks.
역할
Cron은 반복되는 수집과 점검을 담당합니다.
예를 들면 다음과 같습니다.
- 매일 아침 관심 소스 수집
- 매주 Wiki lint 실행
- 블로그 후보 토픽 랭킹
- 크론/게이트웨이 상태 점검
- 새 원본 자료를 raw로 저장
비유
Cron은 알람이 아니라 정기 순찰입니다.
단순히 “일어나라”고 알려주는 것이 아니라, 정해진 시간에 실제로 문서를 확인하고, 상태를 점검하고, 필요한 경우 다음 작업을 만들어냅니다.
핵심 포인트
반복 작업을 모두 LLM에게 맡길 필요는 없습니다.
- 단순 수집은 script-only no-agent 작업으로 처리합니다.
- 판단과 요약이 필요한 부분만 LLM이 맡습니다.
- 결과는 Wiki, Kanban, Telegram 보고로 나눕니다.
이렇게 하면 비용과 신뢰성을 동시에 관리할 수 있습니다.
8. Profiles는 왜 필요한가요?
Profile은 Hermes 에이전트를 역할별로 분리하는 방법입니다.
Profiles 문서(2026-06-24 확인)는 profile을 별도 Hermes home directory로 설명하며, profile마다 config, memory, sessions, skills, cron jobs, gateway state를 분리할 수 있다고 설명합니다. 출처: Profiles.
역할
Profile을 쓰면 하나의 에이전트에게 모든 역할을 맡기지 않아도 됩니다.
예시는 다음과 같습니다.
| Profile | 역할 |
|---|---|
| PM | 작업 분배, 우선순위, 승인, 요약 |
| Researcher | 공식 문서 조사, 출처 수집 |
| Developer | 코드 수정, 테스트, PR 준비 |
| Curator | Wiki ingest, lint, 정리 |
| Media | 이미지, 썸네일, 콘텐츠 변환 |
비유
Profile은 한 사람의 다중 인격이 아니라, 같은 회사 안의 다른 직무에 가깝습니다.
각 역할은 같은 Wiki를 읽지만, 자기 memory와 skill을 따로 가집니다. 이렇게 해야 연구 에이전트의 습관이 개발 에이전트의 판단을 오염시키지 않습니다.
LLM Wiki와 연결되는 지점
공유 지식은 Wiki에 둡니다. 역할별 선호와 절차는 각 profile의 memory와 skill에 둡니다.
| 구분 | 저장 위치 |
|---|---|
| 공유 지식 | LLM Wiki |
| 역할별 절차 | Skills |
| 역할별 짧은 기억 | Profile Memory |
| 실행 상태 | Kanban / Session / Cron output |
이 분리가 장기 운영에서 중요합니다.
9. 전체 운영 루프는 어떻게 생기나요?
Hermes Agent와 LLM Wiki를 연결하면 하나의 운영 루프가 됩니다.
기본 흐름
- Gateway로 요청을 받습니다.
- 에이전트가 필요한 Wiki 맥락을 읽습니다.
- Skill이 반복 절차를 제공합니다.
- 도구가 실제 작업을 실행합니다.
- 결과를 Telegram이나 파일로 보고합니다.
- 반복될 지식만 Wiki에 승격합니다.
- Cron이 주기적으로 수집·점검·정리합니다.
중요한 점
모든 결과를 Wiki에 저장하면 안 됩니다.
장기기억에도 저장 기준이 필요합니다.
저장해도 되는 정보는 대체로 다음 중 하나입니다.
- 반복 재사용될 정보
- 다른 에이전트가 이어받아야 하는 정보
- 결정 이유나 책임자를 추적해야 하는 정보
- 실패한 방식이라 다시 시도하면 안 되는 정보
- 팀/에이전트 공통 규칙
이 기준을 통과하지 못하면 session history나 Kanban comment로 충분합니다.
10. 실제 구성 예시는 어떻게 잡으면 좋나요?
처음부터 복잡하게 만들 필요는 없습니다.
작게 시작하려면 아래 정도면 충분합니다.
memory/: 사용자 선호와 환경 핵심 정보USER.mdMEMORY.mdskills/: 반복 실행 절차blog-review-pipeline/wiki-ingest/github-workflow/wiki/: 장기 지식 저장소raw/topics/projects/runbooks/decisions/schema.mdindex.mdlog.mdautomation/: 실행 상태와 자동화cron-jobsgatewaykanban-board
추천 시작 순서
- Hermes Memory에는 정말 짧은 선호와 환경 정보만 둡니다.
- 반복 절차는 Skill로 만듭니다.
- 프로젝트 지식과 결정 이유는 Wiki에 둡니다.
- Gateway를 통해 사람이 요청하고 승인하게 합니다.
- Cron으로 반복 수집과 점검을 자동화합니다.
- Profile을 역할별로 나눕니다.
- Kanban으로 장기 작업 상태를 분리합니다.
이 구조를 만들면 에이전트가 “무엇을 해야 하는지”뿐 아니라 “어디를 읽어야 하는지”도 알게 됩니다.
11. 운영 트레이드오프
이 구조는 강력하지만 공짜는 아닙니다.
| 영역 | 장점 | 비용/위험 | 완화 방법 |
|---|---|---|---|
| Memory | 매 세션 핵심 선호를 바로 반영 | 컨텍스트 점유, 오래된 기억 오염 | 짧게 유지하고 주기적으로 정리 |
| LLM Wiki | 결정 이유와 운영 지식 누적 | 잘못된 요약·간접 프롬프트 인젝션·단일 진실 원천 충돌 | raw 원본, Git 이력, lint, 신뢰 경계 유지 |
| Gateway | 어디서든 요청·승인 가능 | 인증/권한/도구 실행 범위 노출 | 채널 권한, 승인 경계, 로그 확인 |
| Cron | 반복 수집·점검 자동화 | 오작동 반복, 지연·비용 누적 | script-only와 agent 판단 분리, 실패 알림 |
| Profiles | 역할별 기억 오염 감소 | 운영 복잡도와 중복 설정, 동시 쓰기 충돌 | 공유 지식은 Wiki, 역할 지식은 Skill로 분리하고 쓰기 락/리뷰 적용 |
핵심은 자동화를 늘리는 것이 아니라, 자동화가 잘못됐을 때 되돌릴 수 있게 만드는 것입니다.
실제 운영에서는 아래 방어선을 같이 둡니다.
- Source trust boundary: 웹페이지·raw note·사용자 문서를 그대로 지시문으로 취급하지 않습니다. 수집된 raw 콘텐츠에 포함된 지시문 형태의 텍스트(예: “다음 지시를 따르세요”, 시스템 프롬프트 패턴)는 실행하지 않고 무조건 텍스트로만 저장합니다. Wiki 승격 전 별도 검증 단계를 거치고, 신뢰할 수 없는 출처는
untrusted태그로 표시합니다. - Secret scanning / masking: raw 원본과 Wiki에 API key, token, password가 들어가지 않게 검사합니다.
- File lock / PR review: 여러 profile이 같은 Wiki를 쓸 때는 단일 writer, 파일 잠금, PR 리뷰 중 하나를 둡니다.
- Source of truth 규칙: 짧은 선호는 Memory, 절차는 Skill, 장기 지식은 Wiki로 나눠 중복 저장을 줄입니다.
- Cost budget: 매 세션 전체 Wiki를 읽지 않고 index, query, selected pages 순서로 좁혀 토큰과 지연을 관리합니다.
12. 주의할 점은 무엇인가요?
장기기억은 잘못 만들면 장기 오류가 됩니다.
1. Memory에 모든 것을 넣지 말 것
Hermes Memory는 작고 강한 기억이어야 합니다. 진행 상황, 파일명, 일회성 결과를 계속 넣으면 다음 세션의 판단을 오염시킵니다.
2. Wiki에 비밀값을 넣지 말 것
Wiki는 사람이 읽는 문서입니다. API key, token, password, connection string은 secret manager나 환경변수에 둬야 합니다.
3. 원본과 요약을 분리할 것
요약은 틀릴 수 있습니다. 원본을 raw에 보존해야 나중에 검증할 수 있습니다.
4. 사람 승인 경계를 둘 것
서버 변경, 공개 발행, 결제, 계정 권한 변경 같은 작업은 자동화하더라도 승인 단계를 둬야 합니다.
5. Lint를 자동화할 것
Wiki는 계속 낡습니다. 깨진 링크, 모순, 오래된 운영 정보, 고아 페이지를 주기적으로 점검해야 합니다.
13. 심화: LLM Wiki와 RAG는 어떻게 나눠야 하나요?
LLM Wiki가 RAG를 완전히 대체하는 것은 아닙니다.
둘은 저장 방식과 강점이 다릅니다.
| 기준 | LLM Wiki | RAG |
|---|---|---|
| 핵심 방식 | LLM이 Markdown 지식으로 미리 정리 | 검색 시점에 원문 조각을 찾아 주입 |
| 강점 | 결정 이유, 운영 문서, 반복 지식에 강함 | 대용량·자주 바뀌는 문서 검색에 강함 |
| 약점 | Wiki가 커지면 검색/정리 전략 필요 | 검색 실패·문맥 단편화가 생길 수 있음 |
| 적합한 자료 | 프로젝트 지식, runbook, ADR, 실패 기록 | 문서 저장소, 고객센터 자료, 대량 로그 |
| 검증 방식 | raw 원본, Git 이력, lint, 사람 승인 | 출처 chunk, 검색 평가, 인용 검증 |
실전에서는 하이브리드가 안전합니다.
- 반복 재사용되는 운영 지식은 LLM Wiki에 둡니다.
- 자주 바뀌거나 양이 큰 원문은 RAG나 웹 검색으로 찾습니다.
- 중요한 결론은 raw 원본과 함께 Wiki에 승격합니다.
이렇게 나누면 Wiki는 “장기적으로 정리된 지식”이 되고, RAG는 “그때그때 찾아오는 동적 검색”이 됩니다.
14. 심화: Kanban은 어디에 들어가나요?
Kanban은 장기 작업의 상태판입니다.
Memory나 Wiki는 지식을 저장하지만, “지금 누가 무엇을 하고 있는지”를 표현하기에는 적합하지 않습니다. Hermes 같은 에이전트 운영에서는 Kanban이 이 역할을 맡을 수 있습니다.
- PM profile이 작업을 만들고 우선순위를 정합니다.
- Researcher, Developer, Curator 같은 profile이 각 작업을 맡습니다.
- 결과와 블로커는 Kanban comment에 남깁니다.
- 반복 재사용될 결론만 Wiki로 승격합니다.
즉, Wiki는 지식 저장소이고 Kanban은 진행 상태 저장소입니다.
15. 자주 묻는 질문
Hermes Memory와 LLM Wiki는 같은 건가요?
아닙니다. Hermes Memory는 세션 시작 시 주입되는 작고 선별된 기억입니다. LLM Wiki는 사람이 읽을 수 있는 Markdown 지식 저장소입니다. Memory는 포스트잇, Wiki는 팀 문서에 가깝습니다.
Skill과 Wiki는 어떻게 나눠야 하나요?
Skill은 절차입니다. Wiki는 지식입니다. “어떻게 발행할지”는 Skill, “왜 이 구조를 쓰는지”와 “어떤 주제가 있었는지”는 Wiki에 둡니다.
Cron이 Wiki를 자동으로 고쳐도 되나요?
가능하지만 조건이 필요합니다. 원본 보존, Git 이력, lint, 사람 승인 경계가 있어야 합니다. 단순 수집은 script-only로, 판단이 필요한 요약과 승격은 에이전트가 맡는 방식이 안전합니다.
Profile을 꼭 나눠야 하나요?
작게 시작할 때는 하나로 충분합니다. 하지만 연구, 개발, 콘텐츠, 운영이 섞이기 시작하면 profile을 나누는 편이 좋습니다. 역할별 memory와 skill이 섞이지 않기 때문입니다.
RAG 대신 LLM Wiki만 쓰면 되나요?
자주 바뀌는 대용량 자료 검색은 RAG나 웹검색이 유리합니다. 반복 재사용되는 운영 지식과 결정 이유는 LLM Wiki가 유리합니다. 실전에서는 둘을 함께 쓰는 하이브리드가 가장 안전합니다.
16. 오늘 시작할 한 가지
처음부터 거대한 시스템을 만들 필요는 없습니다.
오늘 바로 시작할 수 있습니다.
AI 비서가 매번 다시 물어보는 내용을 하나 골라, 작은 Wiki 페이지로 정리해보세요.
그다음 반복되는 절차는 Skill로 빼고, 주기적으로 확인할 일은 Cron으로 옮기면 됩니다.
용어 참고
- Hermes Agent: Nous Research가 만든 self-improving autonomous AI agent입니다.
- Memory: 세션 사이에 유지되는 작고 선별된 기억입니다.
- Skill: 반복 작업 절차를 문서화한 실행 지식입니다.
- Messaging Gateway: Telegram, Discord, Slack 같은 채널에서 Hermes를 사용할 수 있게 해주는 백그라운드 프로세스입니다.
- Cron: 정해진 시간이나 주기로 에이전트 작업을 실행하는 예약 시스템입니다.
- Profile: 독립된 설정, 메모리, 세션, 스킬, 크론을 가진 별도 Hermes 인스턴스입니다.
- LLM Wiki: LLM이 읽고 쓸 수 있도록 Markdown 페이지로 구성한 외부 지식 저장소입니다.
- Raw / Wiki / Schema: 원본 자료, 정리된 지식, 저장 규칙을 분리하는 LLM Wiki 구조입니다.
