AI 에이전트가 세션을 넘어 기억하는 방법 — Hermes 3계층 메모리 구조 해부

AI 에이전트를 실무에 도입하면서 가장 먼저 부딪히는 벽이 있습니다. 오늘 세션에서 공들여 세팅한 컨텍스트가, 내일 새 세션을 열면 통째로 사라진다는 거죠. "패키지 매니저는 pnpm 써"를 매번 다시 말해줘야 하고, "저번에 Alice가 말한 그 인증 버그 있잖아"처럼 교차 세션 회상은 아예 불가능합니다. 솔직히 처음엔 그냥 프롬프트에 다 욱여넣으면 되겠지 싶었는데, 컨텍스트 윈도우(에이전트가 한 번에 처리할 수 있는 텍스트의 양)는 한없이 짧고 반복 작업은 쌓여만 갔습니다.

NousResearch가 2026년 2월 출시한 Hermes Agent는 이 문제를 "메모리를 어떻게 조직할 것인가"라는 구조적 질문으로 풀어냈습니다. 핵심은 3계층 메모리 아키텍처 — 세션이 끊겨도 AI가 프로젝트 규칙을 기억하고, 수 주 전 대화를 검색하며, 반복 워크플로우를 스스로 스킬로 굳혀가는 구조입니다. 이 글에서는 그 세 계층이 각각 무엇을 저장하고 언제 작동하는지, 실무에서 어떻게 쓰이는지를 살펴봅니다. AI 코딩 도구를 써본 적 있다면 바로 적용해볼 수 있는 내용들입니다.

핵심 개념

왜 "3계층"인가 — 기억의 종류가 다르다

인간도 기억을 하나의 통으로 관리하지 않습니다. 항상 떠올려야 하는 것(이름, 직책), 필요할 때 찾아보는 것(지난 회의 내용), 몸에 밴 습관(자전거 타기)은 뇌의 서로 다른 영역에서 처리됩니다. Hermes의 설계는 이 구분을 그대로 소프트웨어로 옮겨온 것에 가깝습니다.

핵심 원칙: "중요한 사실은 항상 메모리에, 나머지는 검색 가능하게" — 컨텍스트 윈도우를 오염시키지 않으면서 대용량 기억을 유지하는 것이 목표입니다.

세 계층은 목적, 저장 위치, 로드 시점이 명확하게 분리됩니다.

저도 처음에는 이 세 계층을 무시하고 Tier 1에 모든 걸 몰아넣으려 했습니다. 결과는 예상대로였죠 — 용량 초과, 로딩 지연, 쓸모없는 정보로 가득 찬 시스템 프롬프트. 계층의 역할이 명확히 분리된 데는 이유가 있습니다.

Tier 1 — 동결 시스템 프롬프트 메모리

에이전트가 세션을 시작할 때마다 자동으로 시스템 프롬프트(에이전트의 행동 지침이 담긴 초기 설정)에 주입되는 파일들입니다. 구성은 세 가지입니다.

• SOUL.md: 에이전트의 페르소나, 가치관, 행동 원칙 — 거의 바뀌지 않는 정체성
• MEMORY.md: 프로젝트 규칙, 중요 결정 사항, 주의사항 (공식 문서 기준 약 2,200자 하드캡)
• USER.md: 사용자 선호, 커뮤니케이션 스타일, 역할 정보 (공식 문서 기준 약 1,375자 하드캡)

# MEMORY.md 예시
 
- 프로젝트 루트: ~/workspace/my-app
- 패키지 매니저: pnpm (npm 절대 사용 금지)
- DB 스키마 변경 시 반드시 prisma migrate 실행
- 코드 리뷰는 PR 단위, 직접 main 푸시 금지
- 배포 환경: k8s 스테이징(staging.myapp.internal), 프로덕션(prod.myapp.io)

용량 제한이 꽤 타이트하다 보니, 저도 처음엔 "이 정도면 다 들어가겠지" 하고 욱여넣다가 잘렸습니다. 핵심은 에이전트가 모를 때 가장 치명적인 것만 남기는 선별력입니다. 상세 내용은 Tier 2나 별도 문서로 분리하는 편이 훨씬 낫습니다.

Tier 2 — 에피소딕 아카이브 (SQLite FTS5)

~/.hermes/state.db에 저장되는 모든 대화 이력입니다. 용량 제한이 없고, 기본 상태에서는 컨텍스트에 로드되지 않습니다. 컨텍스트를 아낄 수 있는 이유가 바로 이 부분인데 — 필요할 때 session_search로 FTS5(Full-Text Search) 쿼리를 날려 관련 발췌문만 뽑아오는 방식입니다.

FTS5(Full-Text Search 5): SQLite에 내장된 전문 검색 확장입니다. 별도 검색 엔진 없이 로컬에서 텍스트 인덱싱과 빠른 쿼리가 가능하며, ACID 트랜잭션도 보장됩니다. 키워드 기반 검색이기 때문에 "인증 버그 Alice"처럼 구체적인 단어로 검색할 때 효과적입니다. 의미 기반 유사도 검색(시맨틱 서치)이 필요하다면 Supermemory 같은 벡터 검색 기반 프로바이더를 고려해볼 수 있습니다.

아래는 내부적으로 이런 형태로 검색이 이뤄지는 개념적 예시입니다. 실제 Hermes의 내부 스키마와 완전히 동일하지 않을 수 있습니다.

-- 개념적 예시: FTS5 기반 대화 검색
SELECT session_id, excerpt, relevance_score
FROM conversations_fts
WHERE conversations_fts MATCH 'Alice 인증 버그'
ORDER BY relevance_score
LIMIT 5;

실무에서 이 계층이 가장 빛나는 순간은 "수 주 전 논의를 다시 꺼낼 때"입니다. "지난달 Alice가 인증 문제 말한 게 뭐였지?" — 이런 쿼리를 날리면 관련 세션 발췌문과 LLM 요약이 함께 반환됩니다. 처음 써봤을 때 "아, 이게 되는구나" 싶었던 순간이 아직도 기억납니다.

Tier 3 — 절차적 메모리 (Skills)

Hermes에서 제가 가장 독특하다고 생각하는 계층입니다. 공식 문서 기준으로, 5개 이상의 툴 콜(에이전트가 실제로 실행하는 개별 작업 단위)로 완료된 워크플로우가 3~4회 반복되면, 백그라운드 프로세스가 자동으로 마크다운 스킬 파일을 생성합니다.

# ~/.hermes/skills/deploy-to-staging/SKILL.md
---
name: deploy-to-staging
triggers: ["배포", "스테이징 올려", "deploy staging"]
---
1. pnpm build && pnpm test
2. docker build -t app:staging .
3. kubectl apply -f k8s/staging/
4. slack notify #deployments

이후 "스테이징 올려줘"라고 입력하면 트리거가 매칭되어 해당 스킬을 재사용합니다.

스킬 목록은 이름과 설명만 먼저 로드(약 3K tokens)하고, 실제 스킬 내용은 트리거가 매칭될 때만 로드하는 lazy loading 구조입니다. 덕분에 스킬이 수십 개 쌓여도 컨텍스트를 낭비하지 않습니다 — 로드된 스킬 목록만 있으면 에이전트가 "이런 상황엔 이 스킬을 쓰면 되겠다"를 판단할 수 있거든요.

실전 적용

예시 1: 프로젝트 온보딩 컨텍스트를 Tier 1에 고정하기

새 프로젝트에 합류하거나 여러 프로젝트를 병행할 때, 에이전트가 "이 프로젝트에서는 무엇을 조심해야 하는지"를 항상 알고 있도록 설정하는 시나리오입니다. 이런 상황이 실무에서 꽤 자주 생기더라고요.

# MEMORY.md — 실무 프로젝트 예시
 
## 프로젝트 기본
- 루트: ~/workspace/payment-service
- 언어: TypeScript strict mode, Node 20 LTS
- 패키지 매니저: pnpm (npm/yarn 사용 금지)
 
## 데이터베이스
- ORM: Prisma (스키마 변경 = prisma migrate dev 필수)
- DB: PostgreSQL 15 (로컬: localhost:5432/payment_dev)
 
## 배포 규칙
- main 직접 푸시 금지, PR + 2인 리뷰 필수
- 스테이징: deploy:staging 스크립트 사용
- 시크릿: .env.local (절대 커밋 금지, Vault에 원본 존재)
 
## 알려진 주의사항
- payment_transactions 테이블은 소프트 딜리트만 허용
- Stripe 웹훅은 멱등성 키 필수 처리

이 표에서 제가 가장 신경 쓰는 항목은 "알려진 주의사항" 섹션입니다. "당연히 알겠지"라고 생각했던 것들이 실제로는 에이전트가 모르는 경우가 많거든요.

예시 2: 반복 배포 워크플로우를 Tier 3 스킬로 굳히기

스테이징 배포를 주 3~4회 반복하다 보면 Hermes가 자동으로 스킬을 생성해주지만, 처음부터 직접 작성해두는 것도 가능합니다. 오히려 중요한 프로덕션 워크플로우라면 직접 작성하는 편을 권장합니다 — 자동 생성된 스킬은 원본 워크플로우의 실수까지 그대로 굳혀버릴 수 있거든요.

# ~/.hermes/skills/full-deploy/SKILL.md
---
name: full-deploy
triggers: ["전체 배포", "프로덕션 배포", "full deploy", "릴리즈"]
preconditions:
  - "main 브랜치에서만 실행"
  - "CHANGELOG 업데이트 확인"
---
 
## 배포 전 체크
1. git status 확인 (uncommitted 없어야 함)
2. pnpm test && pnpm lint
3. CHANGELOG.md 최신 버전 항목 확인
 
## 빌드 & 배포
4. pnpm build:prod
# $VERSION은 CHANGELOG.md 최신 항목에서 직접 지정 (예: v1.4.2)
5. docker build -t payment-service:$VERSION .
6. docker push registry.myco.io/payment-service:$VERSION
# 아래 kubectl 직접 호출 방식은 GitOps 환경(ArgoCD, Flux 등)에서는 맞지 않을 수 있습니다
7. kubectl set image deployment/payment-service app=registry.myco.io/payment-service:$VERSION -n production
 
## 배포 후 검증
8. kubectl rollout status deployment/payment-service -n production
9. curl https://api.myco.io/health | grep '"status":"ok"'
10. slack notify #releases "payment-service $VERSION 배포 완료"

preconditions 필드가 실무에서 자주 빠뜨리게 되는 부분인데, 여기에 명시해두면 에이전트가 조건 충족 여부를 먼저 확인하고 진행합니다.

예시 3: Mem0 외부 프로바이더 연동 (심화)

Tier 1의 용량 제한이 답답하거나, 여러 프로젝트에 걸친 사용자 선호를 관리하고 싶을 때는 외부 메모리 프로바이더를 연결할 수 있습니다. Hermes는 공식 기준으로 Honcho, Mem0, Hindsight, Supermemory 등 8개 외부 프로바이더를 지원합니다 — 각각 사용자 행동 패턴 모델링, 장기 메모리 관리, 회고 기반 추출, 벡터 시맨틱 검색 등 특화된 방향이 다릅니다.

그 중 설정이 가장 간단한 Mem0 예시입니다.

# 30초 설정
hermes config set memory.provider mem0
hermes config set memory.mem0.api_key $MEM0_API_KEY

Mem0는 두 가지 메모리 스코프를 자동으로 관리합니다.

관련 메모리는 새 세션 시작 시 자동으로 검색·주입되어 Tier 1의 정적 파일을 동적으로 보완합니다. 단, 한 번에 하나의 외부 프로바이더만 활성화할 수 있다는 제약이 있으니 참고해두시면 좋습니다.

장단점 분석

장점

단점 및 주의사항

이 단점들 중에서 제가 가장 성가셨던 건 판단 기반 저장의 오염 문제였습니다. 에이전트가 어느 순간 잘못된 규칙을 "사실"로 기억해버리면, 의도치 않게 계속 그 패턴을 반복하거든요. 한 달에 한 번 정도 MEMORY.md를 직접 열어보는 습관이 생긴 이유입니다.

실무에서 가장 흔한 실수

1. MEMORY.md에 모든 것을 다 넣으려다 용량 초과 — 2,200자 제한은 생각보다 빨리 채워집니다. "에이전트가 이걸 모르면 치명적인가?"를 기준으로 선별하는 것이 좋습니다. 상세한 배경 설명은 Tier 2나 별도 문서 링크로 빼는 편이 낫습니다.
2. 자동 생성 스킬을 검토 없이 신뢰 — 프로덕션 배포처럼 중요한 워크플로우는 자동 생성된 스킬 파일을 반드시 열어보고 단계를 확인하는 것을 권장합니다. 원본 워크플로우에 실수가 있었다면 그대로 굳어버립니다.
3. Tier 2 데이터를 백업하지 않음 — ~/.hermes/state.db 하나에 전체 대화 이력이 저장됩니다. 디스크 문제나 OS 재설치 시 전부 날아갈 수 있으니, 주요 프로젝트에서는 주기적 백업 또는 외부 프로바이더 연동을 고려해볼 수 있습니다.

마치며

어떤 계층에 무엇을 두느냐가 에이전트의 실제 유용성을 결정합니다.

Hermes의 3계층 메모리는 "AI가 기억하는 방법"을 구조화한 시도입니다. 완벽한 아키텍처는 아닙니다 — Tier 1 용량 제한, 판단 기반 저장의 오염 가능성, 컨텍스트 손실 버그 등 현실적인 한계가 있습니다. 하지만 세션 간 맥락 유지라는 오래된 문제에 대한 실용적인 답변을 내놓은 프레임워크임은 분명합니다.

지금 바로 시작해볼 수 있는 3단계:

1. MEMORY.md부터 작성해보시면 좋습니다 — 현재 프로젝트의 패키지 매니저, DB 마이그레이션 규칙, 배포 주의사항 등 "에이전트가 몰랐을 때 가장 불편했던 것" 5가지를 2,200자 이내로 정리해보시는 것을 추천합니다.
2. 한 달 사용 후 Tier 2 검색을 활용해볼 수 있습니다 — "지난달에 논의했던 X 이슈 뭐였지?"처럼 실제 업무에서 궁금했던 질문을 session_search로 던져보시면, 에피소딕 아카이브의 실제 가치를 체감하실 수 있습니다.
3. 반복 워크플로우가 생겼을 때 스킬 파일을 직접 작성해볼 수 있습니다 — 자동 생성을 기다리기보다, 배포·테스트·PR 생성처럼 주 3회 이상 반복하는 작업을 ~/.hermes/skills/에 직접 YAML로 작성해두시면 즉시 재사용됩니다.

참고 자료

• Hermes Agent 공식 문서 — Persistent Memory
• Hermes Agent 공식 문서 — Memory Providers
• Hermes Agent Memory System: How Persistent AI Memory Actually Works — Rost Glukhov
• How Hermes Agent Memory Works — 3-Layer System Explained
• Hermes Agent memory: SOUL.md, MEMORY.md and state.db — LumaDock
• How Hermes Agent Solves the Context Window Problem — Medium
• Hermes Agent Memory Providers: All 7 Options Compared — Vectorize.io
• Hermes Agent 5-Pillar Architecture — MindStudio
• Hermes Agent Masterclass — Daily Dose of Data Science
• NousResearch/hermes-agent GitHub — DeepWiki