에이전트를 한 달쯤 쓰면 둘 중 하나가 된다. 설명을 덜 해도 되는 에이전트가
되거나, 이상한 걸 잔뜩 배운 에이전트가 되거나. 갈림길은 모델이 아니라
운영에 있다.
앞선 글들에서 재료는 다 다뤘다. 스킬을 만드는 법,
무엇을 기억하는지,
배운 것을 되짚는 journey까지. 이 글은 그 재료로
돌아가는 루틴 하나를 만든다.
주의
이 글은 공식 문서를 근거로 정리한 것이고, 직접 한 달을 돌려 확인한 것이
아니다. 설치 주소로 나가는 통신이 막힌 환경에서 썼다. 기본값은 버전에 따라
달라지니 각자 환경에서hermes curator status로 한 번 확인하기 바란다.
"똑똑해진다"를 무엇으로 볼 것인가#
먼저 기준을 정해 둔다. 애매한 말로 두면 관리할 수가 없다.
다음 세션이 지난 세션보다 덜 묻는 것. 이게 전부다.
| 안 쌓이는 상태 | 쌓이는 상태 |
|---|---|
| 매번 "이 서버는 포트가 2222" 를 다시 말한다 | 기억에 있어서 안 묻는다 |
| 배포 순서를 매번 불러 준다 | 스킬을 읽고 시작한다 |
| 지난달 장애를 다시 설명한다 | 세션 검색으로 스스로 찾는다 |
모델을 더 좋은 것으로 바꿔도 왼쪽은 안 고쳐진다. 왼쪽을 오른쪽으로 옮기는 게
운영이다.
고리 한 바퀴#
루틴은 네 칸을 도는 고리다. 각 칸에 무엇을 하는지만 정해 두면 된다.
| 칸 | 하는 일 | 주기 |
|---|---|---|
| 1. 일한다 | 평소처럼 에이전트에게 일을 시킨다 | 늘 |
| 2. 남긴다 | 잘 된 절차를 스킬로, 사실을 기억으로 | 일이 끝날 때 |
| 3. 검토한다 | 무엇이 들어갔는지 눈으로 본다 | 주 1회 |
| 4. 치운다 | 안 쓰는 것, 겹치는 것을 정리한다 | 월 1회 |
3번을 건너뛰면 4번이 의미가 없다. 무엇이 쌓였는지 모르는 채로 정리만 하면
쓸 것을 치우고 이상한 것을 남기게 된다.
1. 무엇을 어디에 둘지부터 정한다#
운영에서 제일 먼저 흔들리는 게 이것이다. 기준을 문장으로 박아 두면 매번 고민할
일이 없다.
| 남길 것 | 어디에 | 왜 |
|---|---|---|
| 한 줄로 끝나는 사실 | 기억 | 세션마다 자동으로 실린다 |
| 순서가 있는 절차 | 스킬 | 필요할 때만 읽혀서 싸다 |
| 길고 두꺼운 자료 | 스킬의 references/ |
읽은 만큼만 비용이 든다 |
| 한 번 쓰고 버릴 것 | 아무 데도 | 대화창에 두면 된다 |
기억은 MEMORY.md 2,200자, USER.md 1,375자로 작게 묶여 있다. 작은 게
단점이 아니라 설계다. 매 턴 프롬프트에 실리는 것이라 커지면 그대로 비용이 된다.
팁
애매하면 기억에 한 줄, 스킬에 자세히로 나눈다. 기억에는
"배포는deploy-staging스킬을 따른다" 한 줄만 두고 절차는 스킬에 둔다.
그러면 항상 켜져 있는 자리는 한 줄만 먹고, 필요할 때 본문이 열린다.
2. 남기는 타이밍을 정해 둔다#
Hermes 는 턴이 끝날 때마다 배경에서 "배울 게 있나" 를 스스로 본다. 그대로 둬도
쌓이긴 하지만, 사람이 찍어 주는 편이 품질이 훨씬 낫다.
/learn 방금 한 배포 순서 ← 일이 잘 끝난 직후
/refine ← "볼 만한 게 있나" 를 지금 판단시킬 때
/new ← 일이 끝났을 때, 주제가 바뀔 때/learn 은 일이 끝난 직후에 친다. 시간이 지나면 왜 그 순서였는지가
대화에서 사라진다. 그때 만든 스킬에는 함정이 안 들어간다.
/new 를 안 하면 나머지가 안 돈다. 기억은 세션이 시작할 때 프롬프트에
박히는 스냅샷이라, 방금 저장한 기억은 다음 세션부터 보인다. 텔레그램 같은
게이트웨이는 대화가 계속 이어지므로 내가 끊어 줘야 한다.
주의
처음 한 달은 승인 게이트를 켜 두는 쪽을 권한다.
yaml
memory:
write_approval: true
skills:
write_approval: true저장이 바로 되지 않고 대기열에 선다(
/memory pending,/skills pending).
번거롭지만 이 한 달이 에이전트가 무엇을 배울 만하다고 판단하는지를 배우는
기간이다. 감이 잡힌 뒤에 풀어도 늦지 않다.
3. 주 15분 점검#
일주일에 한 번, 이 순서로 본다. 길어야 15분이다.
hermes journey # 1. 이번 주에 새로 생긴 점이 있나
hermes curator status # 2. 안 쓰이는 것이 쌓였나
cat ~/.hermes/memories/MEMORY.md # 3. 기억이 정확한가각 단계에서 볼 것 하나만 정해 두면 흐려지지 않는다.
| 단계 | 딱 하나만 본다면 |
|---|---|
journey |
모르는 점이 새로 생겼나. 내가 만들지도, 시키지도 않은 것 |
curator status |
한 번도 안 쓴 스킬 목록. 만들 때 이름이나 설명이 틀렸다는 뜻이다 |
MEMORY.md |
틀린 문장이 있나. 기억은 매 세션 프롬프트에 그대로 실린다 |
모르는 점을 찾았으면 그 자리에서 처리한다.
hermes journey list # id 확인
hermes journey edit <노드> # 반쯤 맞으면 고친다
hermes journey delete <노드> # 아니면 치운다경고
스킬을 지우면 보관이지만 기억을 지우면 되돌릴 수 없다. 기억 쪽은 애매하면
지우지 말고edit으로 틀린 문장만 고친다. 자세한 것은
hermes journey 글에 정리해 두었다.
4. 월 1회 치우기#
큐레이터가 알아서 돈다. 놀고 있을 때 깨어나서(기본 7일 주기, 2시간 이상 유휴)
안 쓰는 스킬을 단계적으로 내린다.
curator:
enabled: true
interval_hours: 168 # 7일마다
min_idle_hours: 2
stale_after_days: 30 # 30일 안 쓰면 stale
archive_after_days: 90 # 90일 안 쓰면 보관소로
consolidate: false # 겹치는 것 합치기 — 기본 꺼짐사람이 할 일은 치우면 안 되는 것에 핀을 박는 일뿐이다.
hermes curator run --dry-run # 뭘 할지 먼저 본다
hermes curator pin <스킬> # 분기에 한 번 쓰는 중요한 절차참고
한 번도 안 쓴 스킬은 최소한
stale_after_days가 지나기 전에는 보관되지
않는다. 안 썼다는 게 필요 없다는 증거는 아니니 유예를 준다는 뜻이다.
그리고 큐레이터는 삭제하지 않는다 — 최악이 보관이고,restore로 돌아온다.
겹치는 스킬이 눈에 띄게 늘었으면 그때만 합치기를 돌린다.
hermes curator run --consolidate기본이 꺼져 있는 이유는 돈이 들기 때문이다. LLM 이 스킬 라이브러리를 훑어
우산 스킬로 묶는 작업이라 호출이 많이 나간다. 평소엔 끄고, 분기에 한 번쯤
--dry-run 으로 먼저 본 뒤 돌리는 정도가 맞다.
안 불리는 스킬을 만들지 않는 다섯 가지#
주 점검에서 "한 번도 안 쓴 스킬"이 계속 나온다면 만들 때부터 어긋난 것이다.
다섯 가지만 지키면 대부분 사라진다.
- 한 스킬은 한 가지 일만. 쿠버네티스 전반이 아니라 "파드 재시작 원인 확인".
description에 '언제'를 넣는다. 평소 에이전트에게 보이는 건 그 한 줄뿐이다. 60자 제한이 있으니 기능 설명이 아니라 상황을 적는다.- 분류는 얕게. 세 겹씩 파면 나중에 자기도 못 찾는다.
- 이어지는 스킬은
related_skills로 묶는다. journey 의 선이 여기서 생긴다. 양쪽 다 적어야 이어진다. - 긴 자료는
references/로 뺀다. 본문에 다 넣으면 한 번 불릴 때마다 전부 실린다.
만드는 쪽은 Hermes 스킬 만들기에 단계별로 적어 두었다.
건강한지 숫자로 보기#
감으로 보기 어려우면 숫자 세 개만 본다.
hermes journey --json # 그래프 통계
hermes curator status # 사용 현황
hermes insights --days 30 # 최근 30일 사용 분석| 숫자 | 나쁜 신호 | 뜻 |
|---|---|---|
| 고립된 노드 비율 | 높다 | 배운 것들이 서로 안 이어진다. related_skills 를 아무도 안 적고 있다 |
| 한 번도 안 쓴 스킬 수 | 는다 | 스킬을 만드는 속도가 쓰는 속도를 앞질렀다 |
| 기억 사용률 | 100% 에 붙어 있다 | 곧 저장이 막힌다. 겹치는 항목을 합칠 때다 |
기억은 한도에 닿으면 조용히 밀어내지 않고 에러를 낸다. 그 자리에서 합치거나
지우고 다시 넣게 되어 있다. 그래서 사용률이 높다는 건 고장이 아니라 정리할
때가 됐다는 알림이다.
자주 망가지는 네 가지#
| 증상 | 원인 | 조치 |
|---|---|---|
| 스킬이 수십 개인데 쓰이는 건 다섯 개 | 만들 때 description 이 모호했다 |
안 쓰는 것부터 설명을 고쳐 본다. 그래도 안 불리면 치운다 |
| 비슷한 스킬이 서너 개씩 | 같은 주제로 /learn 을 따로따로 돌렸다 |
--consolidate 로 합친다 |
| 에이전트가 틀린 사실을 우긴다 | 기억에 틀린 문장이 있다 | MEMORY.md 를 열어 그 줄을 고친다 |
| 며칠째 아무것도 안 배운다 | 게이트웨이에서 세션이 안 끊겼다 | /new 를 습관으로. 안 끊기면 학습 고리 자체가 안 돈다 |
마지막 줄이 제일 흔하다. 텔레그램으로 편하게 쓰다 보면 한 세션이 몇 주가 되고,
그동안 새 기억은 프롬프트에 실리지 않는다. 편한 만큼 대가가 있다.
한 달 달력#
| 언제 | 무엇을 | 얼마나 |
|---|---|---|
| 일이 끝날 때마다 | /learn, 그리고 /new |
10초 |
| 주 1회 | journey → curator status → MEMORY.md |
15분 |
| 월 1회 | curator run --dry-run, 핀 정리, insights --days 30 |
30분 |
| 분기 1회 | --consolidate 로 겹치는 스킬 합치기 |
한 번 돌리고 확인 |
| 처음 한 달 | 승인 게이트를 켜고 지켜본다 | — |
정리#
- 성장의 기준은 하나다. 다음 세션이 지난 세션보다 덜 묻는가.
- 기억은 사실, 스킬은 절차,
references/는 두꺼운 자료. 이 세 칸만 지켜도 비용과 정확도가 같이 잡힌다. /learn은 일이 끝난 직후에. 미루면 왜 그 순서였는지가 사라진다./new를 안 하면 학습 고리가 안 돈다. 게이트웨이를 쓴다면 특히.- 주 15분이면 충분하다. journey 에서 모르는 점, 큐레이터에서 안 쓰는 스킬, 기억에서 틀린 문장. 셋만 본다.
- 치우는 일은 큐레이터에게 맡기고, 사람은 핀만 박는다. 삭제가 아니라 보관이라 되돌릴 수 있다.
- 안 불리는 스킬은 대개
description문제다. 기능이 아니라 상황을 적는다.
댓글