SEO meta description: Hermes Agent가 로컬 LLM 위키를 제2의 두뇌로 활용하는 방법. YAML 프론트매터, 위키링크, 엔티티 구조로 AI 기억력을 영속화한 1105줄 지식베이스 구축기

⚠️ 솔직히 말하면 — AI 에이전트랑 일하다 보면 똑같은 얘기를 계속하게 된다.

"아까 그 모델 설정값이 뭐였더라?"
"지난주에 테스트했던 그 벤치마크 결과 좀 볼 수 있어?"
"어? 너 또 까먹었어?"

처음 Hermes Agent를 쓰기 시작했을 때 가장 크게 실망했던 점은 기억력이었다. 대화 세션이 끝나면 에이전트는 모든 걸 잊어버렸다. 마치 새 직원이 매일 첫 출근하는 것 같았다. "내가 DGX Spark에서 Qwen3.6을 vLLM으로 돌린다고 말했잖아"라고 해도, 새 세션에서는 "아, 그게 뭐죠?"라는 답변이 돌아왔다.

이 문제를 해결하기 위해 시도한 세 가지 접근법이 있었다.

1. 메모리에 저장하기 — 부족했다

Hermes Agent에는 memory 도구가 내장되어 있다. 세션을 넘어서 정보를 보관해주는 시스템이다. 하지만 한계가 명확했다:

• 입력 토큰 예산이 제한적 — 모든 걸 다 넣을 수는 없다
• 자연어 메모리는 검색이 어렵다 — "저장한 적 있는데... 뭐라고 저장했더라?"
• 구조화된 데이터를 담기엔 부적합 — 표, 설정값, 벤치마크 결과

메모리는 "사용자는 답변을 간결하게 선호한다" 같은 취향 저장에는 좋지만, 기술 지식베이스로는 역부족이었다.

2. 채팅 히스토리 검색 — 이것도 한계가 있었다

Hermes Agent에는 session_search라는 도구가 있어서 지난 대화를 FTS5(Full-Text Search)로 검색할 수 있다. 대화 맥락을 다시 찾을 때는 유용했다. 하지만:

• 500줄짜리 기술 문서를 채팅으로 10번 주고받으면? → 검색 결과는 대화 조각일 뿐, 완전한 문서가 아니다
• 나중에 검증된 사실과 당시의 추측을 구분하기 어렵다 — 모든 대화가 동등한 가중치로 저장됨

대화 히스토리는 영수증 더미와 같았다. 필요한 정보는 거기에 있지만, 꺼내 쓰기는 힘들었다.

3. 정답: 구조화된 위키 지식베이스

결국 내가 선택한 건 위키였다. GitHub 스타일 마크다운 위키를 에이전트의 "제2의 두뇌"로 사용하기로 했다.

핵심 아이디어는 단순하다:

• 모든 기술 지식은 [local path] 디렉토리에 마크다운 파일로 저장
• 각 파일은 YAML 프론트매터 + 본문 구조
• 위키링크([[page-name]])로 페이지 간 연결
• Hermes Agent의 skill_view / read_file 도구로 위키 조회

위키 구조

wiki/
├── index.md              # 전체 목차 (15개 페이지)
├── log.md                # 변경 이력 (103줄)
├── SCHEMA.md             # 작성 규칙
├── entities/             # 엔티티 페이지
│   ├── dgx-spark-gb10.md # 하드웨어 스펙
│   ├── krea2-comfyui.md  # 이미지 생성 워크플로우
│   ├── ai-news-blogger.md# 자동 블로그 파이프라인
│   ├── devsnack-blog.md  # DevSnack 블로그 (SEO 정보)
│   ├── youtube-automation.md # YouTube 3채널 자동화
│   ├── stock-ml-pipeline.md  # 주식 ML 예측
│   └── ... (총 13개 엔티티)
├── concepts/             # 개념 설명
│   └── infrastructure-overview.md
└── raw/articles/         # 원문 자료
    └── krea2-error-troubleshooting.md

총 17개 파일, 1,105줄, 6개 도메인을 커버한다. 규모는 작지만, 핵심은 "필요한 정보를 에이전트가 즉시 찾을 수 있는가"에 있다.

YAML 프론트매터 — 기계가 읽는 메타데이터

모든 위키 페이지는 다음과 같은 프론트매터로 시작한다:

---
title: DGX Spark GB10
created: 2026-06-23
updated: 2026-06-29
type: entity
tags: [infrastructure]
sources: []
confidence: high
---

이 메타데이터는 Hermes Agent가 위키를 검색할 때 핵심적인 판단 기준이 된다. confidence: high는 검증된 사실, confidence: medium은 실험적 결과라는 신호다. updated 날짜로 정보의 신선도를 즉시 판단할 수 있다.

위키링크 — 지식의 연결

위키 페이지 내부에서 [[ai-news-blogger]] 같은 위키링크로 다른 페이지를 참조한다. 이게 중요한 이유는:

• 에이전트가 연관 지식을 연쇄적으로 찾을 수 있다
• "DGX Spark 설정을 보려면 관련 프로젝트 페이지도 함께 참고하세요" 같은 탐색 경로 제공
• 크로스 레퍼런스가 쌓이면 지식 그래프가 자연스럽게 형성됨

실제 사용 흐름

에이전트와의 전형적인 작업 흐름은 이렇다:

1. 사용자: "Krea 2로 이미지 생성해줘"
2. 에이전트: skill_view("krea2-comfyui") → 워크플로우 경로 확인
3. 에이전트: read_file("workflow.json") → 설정값 로드
4. 에이전트: ComfyUI API 호출 → 이미지 생성
5. 에이전트: 발견한 내용을 wiki에 업데이트

처음에는 모델 파일 경로, 포트 번호, 설정값 같은 기본 정보를 위해 위키를 참조하는 것에서 시작했다. 하지만 사용할수록 위키는 단순한 설정 저장소를 넘어 의사결정 기록으로 발전했다.

실제 데이터 현황 (2026-06-30 기준)

도메인	페이지 수	예시
하드웨어/인프라	4	DGX Spark GB10 스펙, ComfyUI 설정, 네트워크 구성
LLM/모델	3	Krea 2 이미지 생성, Qwopus 27B, GGUF 추론 파이프라인
프로젝트	6	YouTube 자동화, 주식 ML, DevSnack 블로그, 뉴스 블로그
개념	1	인프라 개요
메타	3	인덱스, 변경 로그, 스키마
총계	17	1,105줄

이 시스템이 효과적인 이유

1. 에이전트의 컨텍스트를 확장한다

LLM의 컨텍스트 윈도우는 아무리 길어도 수만 토큰이 한계다. 위키는 이 한계를 외부 저장소로 극복한다. 필요한 정보를 그때그때 불러와서 주입하므로, 컨텍스트를 벗어난 정보도 활용할 수 있다.

2. 지식이 축적된다

채팅 히스토리는 시간이 지나면 묻힌다. 위키는 계속 자란다. 매주 새로운 정보가 추가되고, 오래된 정보는 갱신된다. 6월 23일 생성 당시 7개 페이지에서 7일 만에 17개 페이지로 2.4배 성장했다.

3. 에이전트가 자율적으로 활용한다

가장 중요한 점은 — 에이전트가 스스로 위키를 참조한다는 것이다. "설정값이 뭐였더라?"라고 묻는 대신, 에이전트는 skill_view("krea2-comfyui")를 호출해서 직접 확인한다. 사용자 입장에서는 "아, 이 에이전트가 내 환경을 이해하고 있구나"라는 느낌을 받게 된다.

4. 증분 학습이 가능하다

위키에 쌓인 지식은 다음 세션으로 이어진다. 새 세션에서 Hermes Agent가 시스템 프롬프트를 통해 위키를 인지하고, 필요한 페이지를 열어보며 마치 "어제 일을 기억하는" 것처럼 동작한다.

실제 예: ComfyUI + Krea 2 문제 해결

며칠 전 Krea 2 모델로 이미지를 생성하는데 자꾸 실패했다. 당시의 워크플로우는 이랬다:

1. 위키에서 ComfyUI 설정 확인 → 포트 8188, run_dgx_spark.sh 실행 확인
2. 위키에서 Krea 2 워크플로우 확인 → UNETLoader 필요, ops.py 패치 불필요 (v0.26.0+)
3. 위키에서 과거 시행착오 기록 확인 → CFG=1.0 필수, VAE는 qwen_image_vae만 사용
4. 수정 후 정상 생성 → 발견한 내용을 다시 위키에 기록 (log.md 업데이트)

이 모든 과정에서 내가 직접 기억해야 했던 것은 아무것도 없었다. 위키가 기억하고, 에이전트가 찾고, 나는 결정만 내렸다.

한계와 교훈

물론 완벽한 시스템은 아니다.

• 초기 비용: 위키를 체계적으로 유지하려면 꾸준한 관리가 필요하다. 정보가 생길 때마다 바로 기록하는 습관이 중요하다.
• 검색의 어려움: 페이지가 많아지면 원하는 정보를 찾기가 어려워진다. 현재 17페이지에서는 문제없지만, 100페이지가 넘어가면 검색 전략을 개선해야 할 것이다.
• LLM 의존성: 위키의 마크다운을 해석하고 적절한 페이지를 찾는 것은 여전히 LLM의 능력에 의존한다. 모델이 약하면 위키 활용도도 떨어진다.

결론: 에이전트의 진정한 잠재력은 기억에서 나온다

AI 에이전트는 강력하다. 하지만 똑같은 정보를 매번 다시 설명해야 한다면, 그 강력함은 반감된다. 진정한 생산성 향상은 에이전트가 사용자의 환경과 이력을 이해하고 있을 때 나온다.

로컬 LLM + 구조화된 위키 + Hermes Agent의 조합은 이 문제에 대한 내가 찾은 최선의 답이다. 규모는 작지만, 매일 성장하고 있다. 1,105줄의 지식이 쌓였고, 이 지식은 더 이상 내 머릿속을 차지하지 않는다.

테스트 환경: Hermes Agent (Nous Research) + Qwen3.5-35B (로컬 LLM), DGX Spark GB10 (Grace ARM 20-core + Blackwell GPU, 128GB), 위키: [local path] (마크다운, 17개 파일)

---

📖 관련 글

• Hermes Agent + SearXNG 설치 가이드
• OpenClaw에서 Hermes Agent로 — 왜 갈아탔는가
• Hermes Agent, 24시간 개인 비서로 쓰며 느낀 것들