# Hermes Agent가 일을 잘 하게 하는 기억 체계

- 작성자: [북극곰](https://community.clauders.ai/member/imported-member-7x4Ve2LlfI)
- 공간: [에이전트 / 노코드 자동화](https://community.clauders.ai/automation)
- 게시: 2026-05-26
- 연재: [Hermes 에이전트 진화](https://community.clauders.ai/series/hermes-agent-evolution) 2/5편
- 태그: #Hermes메가진화
- 주소: https://community.clauders.ai/automation/post/hermes-agent%EA%B0%80-%EC%9D%BC%EC%9D%84-%EC%9E%98-%ED%95%98%EA%B2%8C-%ED%95%98%EB%8A%94-%EA%B8%B0%EC%96%B5-%EC%B2%B4%EA%B3%84-a2bddbff-a0c3-8a53-ba91-08bd51d328cc

---

### 1. `SOUL.md`: 에이전트의 기본 성격과 역할

`SOUL.md`는 에이전트가 “나는 어떤 존재로 행동해야 하는가”를 정의하는 기본 정체성 파일에 가깝습니다. Main profile의 `SOUL.md`에는 오케스트레이터로서의 역할, 말투, 사용자를 어떻게 부를지, 다른 전문 프로필에 언제 일을 넘길지 같은 원칙이 들어갑니다.

PKM profile의 `SOUL.md`는 조금 다릅니다. 여기에는 Obsidian vault 중심으로 작업하고, 규칙을 지키라는 규칙이 들어갑니다. 또한 PKM 요청이 들어오면 먼저 `pkm-router`를 통해 작업 성격을 판단하라는 규칙도 포함됩니다.

즉 `SOUL.md`는 매번 “이 에이전트가 어떤 직무를 가진 사람처럼 행동할지”를 결정합니다.

### 2. `identity.md`: 정체성 보강층

일반적으로 `identity.md`는 `SOUL.md`보다 더 세부적인 정체성, 역할 문장, 혹은 특정 실행 환경에서의 자기소개를 나누어 담는 데 쓸 수 있습니다. 다만 제 현재 Main/PKM 사례에서는 별도의 `identity.md`가 핵심 운영 파일로 발견되지는 않았습니다. 그래서 이 사례에서는 `SOUL.md`와 profile config가 실질적인 identity 층을 담당한다고 볼 수 있습니다.

중요한 것은 파일명이 아니라 역할입니다. 어떤 시스템에서는 `identity.md`가 별도 페르소나 레이어가 될 수 있고, 어떤 시스템에서는 `SOUL.md` 하나가 그 역할까지 포함할 수 있습니다. 핵심은 “정체성 계층”과 “작업 지식 계층”을 섞지 않는 것입니다.

### 3. Hermes persistent memory / user profile: 짧고 강한 반복 기억

Persistent memory와 user profile은 매번 다시 설명하기 번거로운 사실을 저장하는 층입니다. 예를 들어 사용자의 선호 말투, 자주 쓰는 vault 경로, 어떤 작업은 어느 프로필이 맡아야 하는지, 특정 프로젝트에서 반복되는 운영 관례 등이 여기에 들어갑니다.

다만 persistent memory에는 무엇이든 넣으면 안 됩니다. “어제 어떤 파일을 만들었다” 같은 작업 진행 기록은 시간이 지나면 금방 낡습니다. 반대로 “사용자는 PKM 작업에서 양보다 질을 선호한다” 같은 사실은 오래 유효합니다. 그래서 이 층에는 짧고 지속적인 사실만 남기는 것이 좋습니다.

쉽게 말하면 persistent memory는 “다음 세션에서도 굳이 다시 말하고 싶지 않은, 하지만 오래 유효한 운영 상식”입니다.

### 4. Hermes brain: 에이전트 전용 운영 기억

Hermes brain은 Obsidian vault가 아닙니다. 이 구분이 제 시스템에서 매우 중요합니다.

Obsidian vault는 제 지식·창작·연구 자산이 들어가는 곳입니다. 반면 Hermes brain은 에이전트가 안정적으로 일하기 위한 운영 기억입니다. 예를 들어 다음과 같은 정보가 brain에 들어갑니다.

- 프로필별 역할 경계
- 현재 어떤 프로젝트가 어떤 상태인지
- 어떤 실패 패턴을 피해야 하는지
- 어떤 작업은 어떤 프로필로 라우팅해야 하는지
- cron, gateway, profile 운영에서 지켜야 할 규칙
- 작업 시작 시 먼저 읽어야 할 짧은 운영 문서

brain은 짧고 현재적이어야 합니다. 이것을 제2의 Obsidian vault처럼 키우기 시작하면 문제가 생깁니다. 지식 자산은 vault로, 에이전트 운영 규칙은 brain으로 분리해야 합니다.

### 5. Obsidian vault: 지식·창작·연구 자산의 본체

DECK vault는 제가 실제로 축적하고 재사용하는 지식 저장소입니다. 여기에는 연구 노트, 개념 노트, 글감, 강의 자료, 프로젝트 문서, 공식 문서 파생 노트, 블로그 초안 등이 들어갑니다.

PKM profile은 이 vault를 기본 작업공간으로 삼습니다. 새 노트를 만들 때는 frontmatter 규칙, wikilink 규칙, CMDS 분류, index 연결, description 작성 규칙 등을 지킵니다. 특히 DECK vault에서는 새 마크다운 문서가 단순한 임시 답변이 아니라 나중에 다시 검색하고 연결할 수 있는 자산이 되도록 작성합니다.

### 6. Skills와 past sessions: 절차와 회고성 기억

Skills는 “반복 가능한 방법”을 저장하는 층입니다. 예를 들어 Obsidian vault에 새 노트를 만들 때 어떤 규칙을 확인해야 하는지, YouTube transcript를 어떻게 처리할지, GitHub PR을 어떻게 리뷰할지 같은 절차가 skill에 들어갑니다. 매번 새로 추론하는 대신 이미 검증된 절차를 불러오는 방식입니다.

Past sessions는 과거 대화 기록입니다. 특정 주제에 대해 예전에 무엇을 결정했는지 찾을 때 유용하지만, 운영 우선순위는 낮습니다. 오래된 세션은 현재 규칙과 충돌할 수 있기 때문입니다. 그래서 past sessions는 “보조 검색 기억”으로 쓰는 것이 안전합니다.

## Main profile 예시: 라우팅과 최종 보고를 맡는 관제탑

Main profile은 제가 Hermes를 부를 때 가장 앞단에서 만나는 관제탑에 가깝습니다. Main이 하는 핵심 일은 직접 모든 작업을 처리하는 것이 아니라, 일을 분류하고, 필요한 프로필에 넘기고, 결과를 검토한 뒤 사용자에게 최종 보고하는 것입니다.

예를 들어 제가 이렇게 요청했다고 해보겠습니다.

“내 Hermes 시스템의 참조 위계를 Clauders 사례글로 정리해서 vault에 저장해줘.”

Main은 먼저 이 요청이 단순 질의인지, PKM 작업인지, Dev 작업인지, Ops 작업인지 판단합니다. 이 경우 핵심 산출물은 Obsidian vault에 저장되는 글 초안이고, DECK vault 규칙을 지켜야 하며, brain과 SOUL 같은 운영 문서를 근거로 삼아야 합니다. 따라서 Main은 이 일을 PKM profile로 보내는 것이 맞습니다.

Main의 관점에서 흐름은 대략 이렇습니다.

1. 사용자 요청을 받습니다.
2. 작업이 PKM/글쓰기/vault 저장에 해당한다고 판단합니다.
3. PKM profile에 목표, 참고 파일, 품질 기준, 저장 조건을 명시해 전달합니다.
4. PKM profile이 산출물을 만들면 파일 경로와 핵심 구성을 받습니다.
5. Main이 최종적으로 사용자에게 “어디에 무엇을 저장했고, 어떤 구조로 작성했는지” 보고합니다.

Main은 gateway, profile, cron governance도 담당합니다. 예를 들어 Telegram에서 들어온 요청을 어떤 topic/profile로 보낼지, cron 작업이 만든 보고를 어떻게 다룰지, PKM/Dev/Ops 중 누가 맡아야 하는지를 판단합니다. 그래서 Main은 “모든 일을 하는 에이전트”라기보다 “일이 제대로 흘러가게 하는 라우터이자 편집장”에 가깝습니다.

## PKM profile 예시: vault 규칙을 지키며 지식 자산으로 만드는 편집자

PKM profile은 Main과 다르게 Obsidian vault 안에서 실제 지식 자산을 만드는 역할을 맡습니다. 같은 요청을 PKM이 받으면 바로 글을 쓰기보다 먼저 작업의 성격을 분류합니다.

이번 요청은 단순한 메모가 아니라 Clauders 커뮤니티에 공유할 사례글입니다. 따라서 PKM 입장에서는 다음 요소를 확인해야 합니다.

- 이 글은 public-facing article인가, 내부 운영 문서인가?
- DECK vault 안에서 초안으로 저장할 위치는 어디가 적절한가?
- frontmatter 7개 필수 속성은 들어갔는가?
- YAML wikilink는 따옴표로 감쌌는가?
- Hermes brain을 Obsidian vault와 분명히 구분했는가?
- 공개 글로 부적절한 경로, 키, 개인식별 정보가 들어가지 않았는가?

PKM profile은 이런 기준을 확인한 뒤 vault에 마크다운 파일을 저장합니다. 예를 들어 `00. Inbox/03. AI Agent/03-3. Hermes/ 같은 Hermes 초안 위치에 저장할 수 있습니다. 아직 발행 완료본이 아니라 글감/초안이기 때문에, 바로 Published 폴더에 넣기보다 Inbox 계열에 두는 것이 자연스럽습니다.

PKM이 하는 일은 “답변 생성”에서 끝나지 않습니다. 나중에 다시 찾을 수 있도록 제목을 명확히 하고, frontmatter description을 영어로 작성하고, CMDS/index를 연결하고, 상태를 `inProgress`로 둡니다. 이렇게 해야 이 글이 단순 채팅 답변이 아니라 vault 안의 재사용 가능한 자산이 됩니다.

## 실제 흐름 예시: 정보가 어떤 순서로 작동하는가

이번 Clauders 글 작성 요청을 기준으로 정보가 작동하는 순서를 풀어보면 다음과 같습니다.

1. 현재 요청이 최우선으로 작동합니다.  
   마스터가 “Clauders 사례글용 마크다운 초안을 DECK vault에 저장해 주세요”라고 요청했으므로, 이 목적이 가장 위에 옵니다. 만약 예전 노트에 다른 저장 위치가 있어도 현재 요청이 우선입니다.
2. 시스템/개발자 지시가 안전장치로 작동합니다.  
   한국어 존댓말, 민감정보 보호, DECK vault 규칙, 작업 완료 보고 방식 같은 기본 규칙이 여기서 작동합니다.
3. Hermes brain이 운영 경계를 제공합니다.  
   brain은 Main과 PKM의 역할 분리를 알려줍니다. Main은 라우팅과 최종 보고, PKM은 DECK/Obsidian/qmd/source-backed durable notes를 담당한다는 경계가 여기서 확인됩니다.
4. Profile SOUL/config가 해당 프로필의 행동 방식을 정합니다.  
   Main의 SOUL은 오케스트레이션 중심으로, PKM의 SOUL은 vault와 지식화 중심으로 행동하게 만듭니다. PKM config는 작업 디렉터리나 reasoning effort 같은 실행 환경의 일부도 정합니다.
5. Skills가 구체적인 실행 절차를 제공합니다.  
   Obsidian note 작성 skill, DECK vault 운영 skill, Hermes Agent 관련 skill 등이 “어떤 파일을 확인하고 어떤 frontmatter를 써야 하는가”를 보강합니다.
6. Obsidian vault notes가 실제 지식/문서 규칙과 산출물 위치를 제공합니다.  
   AGENTS.md 같은 vault 문서는 노트 작성 규칙, 필수 속성, 파일 위치, 문서 깊이 기준을 제공합니다.
7. Past sessions는 필요할 때만 회고성 참고로 씁니다.  
   이전 세션에서 비슷한 글을 쓴 적이 있다면 검색해 참고할 수 있지만, 현재 지시와 현재 규칙을 넘지는 않습니다.

이 순서가 있으니 에이전트가 “예전에는 이렇게 했는데요”라고 우기는 대신, 현재 작업에 맞는 기준을 따르게 됩니다.

## 운영상 장점

이 구조의 가장 큰 장점은 역할 혼선을 줄인다는 점입니다. Main이 모든 것을 직접 처리하지 않고, PKM/Dev/Ops로 나누면 각 프로필이 자기 전문 영역의 규칙을 더 잘 유지합니다.

두 번째 장점은 지식 자산과 운영 메모가 섞이지 않는다는 점입니다. Obsidian vault에는 사람이 읽고 재사용할 지식과 창작물이 남고, Hermes brain에는 에이전트가 일하기 위한 짧은 운영 규칙만 남습니다. 이것은 장기적으로 검색 품질과 유지보수성을 크게 높입니다.

세 번째 장점은 공개 가능한 산출물과 내부 운영 정보의 분리가 쉬워진다는 점입니다. 커뮤니티 글을 쓸 때 brain의 세부 경로나 실패 로그를 그대로 노출하지 않고, 구조와 원리만 설명할 수 있습니다.

네 번째 장점은 반복 업무가 안정화된다는 점입니다. 매번 “이 폴더에 저장해줘”, “frontmatter는 이렇게 써줘”, “DEXA와 CMDS를 혼동하지 마”라고 말하지 않아도, persistent memory, brain, SOUL, skill, vault 규칙이 각자 제 역할을 합니다.

## 주의점: 운영체계가 커질수록 정리 규칙이 필요하다

이 방식이 좋다고 해서 모든 것을 저장하면 오히려 역효과가 납니다. 특히 다음 세 가지를 조심해야 합니다.

첫째, brain을 제2의 vault로 만들지 않아야 합니다. brain은 에이전트 운영 기억이지 지식 저장소가 아닙니다. 길고 풍부한 지식 노트는 vault에 있어야 합니다.

둘째, persistent memory에는 오래 유효한 사실만 넣어야 합니다. 일주일 뒤 낡을 작업 진행 상황이나 임시 파일명까지 memory에 넣으면 다음 세션에서 오히려 혼란을 만듭니다.

셋째, 공개 글과 내부 운영 문서를 분리해야 합니다. Clauders에 공유할 사례글에서는 구조와 원리를 설명하는 것으로 충분합니다. 실제 개인 경로, 계정명, 토큰, 내부 로그, 실패 복구 세부는 공개 글에 넣지 않는 것이 안전합니다.

넷째, 프로필 분리는 편리하지만 과하면 복잡해질 수 있습니다. 그래서 Main은 라우팅 기준을 짧게 유지하고, 각 profile은 자기 전문 영역의 규칙만 진하게 가져가는 편이 좋습니다.

## 정리: 좋은 AI 운영은 “기억의 양”보다 “기억의 층위”에서 갈린다

Hermes를 쓰면서 느끼는 핵심은 AI 에이전트 운영이 점점 “프롬프트 작성”에서 “작은 운영체계 설계”로 이동한다는 점입니다. 어떤 에이전트가 어떤 역할을 맡고, 어떤 기억을 먼저 읽고, 어떤 지식은 사람의 vault에 남기고, 어떤 규칙은 에이전트 brain에 남길지 정하는 일이 중요해집니다.

제 사례에서 Main profile은 관제탑처럼 라우팅과 최종 보고를 맡습니다. PKM profile은 Obsidian DECK vault를 중심으로 지식 자산을 만들고 정리합니다. `SOUL.md`는 정체성과 역할을 잡고, persistent memory는 짧고 오래 가는 선호와 환경 사실을 기억하며, Hermes brain은 에이전트 운영 규칙과 실패 패턴을 보관합니다. Obsidian vault는 사람의 지식과 창작물이 쌓이는 본체로 남습니다.

이 구조는 거창한 시스템이라기보다, AI가 장기적으로 나를 도와 일하게 만들기 위한 실용적인 분리입니다. 에이전트에게 “무엇을 기억할지”보다 먼저 “어디에 어떤 종류의 기억을 둘지”를 정하면, AI는 단순한 답변 생성기를 넘어 개인 작업 흐름을 이어주는 운영 파트너가 될 수 있습니다.