Standard procedure for writing a PR description

요약

메모리와 스킬은 모두 장기적인 축적 수단이지만 근본적으로 다릅니다. 메모리는 선언적 메모리로, 사실·사건·결론·선호도를 짧은 항목에 저장하고 쿼리가 일치할 때 호출됩니다(MEMORY.md + memories/). 스킬은 절차적 메모리로, "상황 X가 발생하면 무엇을 할 것인가"에 대한 표준 절차를 트리거가 선언된 YAML과 실행 단계로 저장하고 상황이 일치할 때 높은 우선순위로 로드됩니다(skills/ 디렉터리 + SKILL.md). 두 요소는 트리거(쿼리 일치 대 상황 일치), 형식(항목 대 단계별 절차), 변화 속도(메모리는 매일 바뀌지만 스킬은 몇 달 동안 그대로 유지될 수 있음)라는 세 가지 엄격한 제약 때문에 분리되어 있습니다. 두 축을 모두 갖춘 에이전트는 사용자를 이해하면서 작업 방법도 알 수 있습니다.

이 두 개념이 계속 혼동되는 이유

Hermes Agent의 설계에서 특히 오해하기 쉬운 부분은 메모리와 스킬을 명확히 분리한 점입니다.

대부분의 사람들의 첫 번째 반응은 세 가지 질문입니다.

• "둘 다 장기 메모리 아닌가요? 왜 분할합니까?"
• "둘 다 Markdown이므로 함께 사용하면 어떨까요?"
• "'에이전트-데모 프런트엔드는 로컬 개발 포트에서 실행된다'를 기억하는 것과 '먼저 요약한 다음 PR 설명을 작성할 때 변경 사항을 나열한다'를 기억하는 것은 같은 것이 아닌가?"

짧은 대답은 다음과 같습니다. 인간의 두뇌도 이를 분할하기 때문입니다.

1. 인지과학의 구분: 선언적 메모리와 절차적 메모리

심리학에서는 오랫동안 두 가지 종류의 장기 메모리를 구별해 왔습니다.

이 두 종류의 메모리는 저장, 호출 및 업데이트 방법에서 다릅니다. 선언적 메모리는 언어화할 수 있는 반면(언어 채널) 절차적 메모리는 대부분 수행됩니다(운동 채널). 심리학 실험에서 해마 손상을 입은 환자는 선언적 메모리가 심각하게 손상되었지만 거울 글씨 쓰기 같은 절차적 작업은 여전히 배울 수 있습니다. 즉, 하나의 경로를 두 방식으로 표현한 것이 아니라 서로 독립된 두 경로입니다.

Hermes Agent는 이 구분을 시스템 설계에 그대로 반영합니다.

• 메모리 (memories/, MEMORY.md): 에이전트의 선언적 메모리.
• 스킬 (skills/): 에이전트의 절차적 메모리.

2. 메모리: 에이전트가 말할 수 있는 것

메모리 시스템은 사실, 사건, 결론 및 선호도를 저장합니다.

• "Jasmin은 agent-demo를 위한 글로벌 사이트에서 작업하고 있습니다."
• "지난 주 영웅 섹션이 애니메이션 그라데이션으로 변경되었습니다."
• "프로젝트는 로컬 개발 포트의 ​​프런트엔드 개발 서버와 함께 Next.js에서 실행됩니다."

그 특성:

• 선언적: 프롬프트에 직접 인용할 수 있는 짧은 문장과 항목으로 존재합니다.
• 요구 시 호출: 관련 주제가 나타나면 FTS5 일치가 관련 항목을 가져옵니다.
• 변경 가능: 새 항목을 추가하고, 이전 항목은 replace 또는 remove 작업으로 갱신합니다.

메모리를 에이전트의 노트북이라고 생각해보세요. 책상 위에 펼쳐져 있고 특정 사실로 가득 차 있습니다.

3. 스킬: 에이전트가 할 줄 아는 것

스킬은 특정 유형의 작업을 처리하는 표준 절차를 저장합니다. 일반적인 Hermes 스킬은 YAML 프런트매터에 트리거 조건과 보조할 도구 세트를 선언한 SKILL.md 형태입니다.

---
name: pr-description-format
trigger:
  when: "user asks to write a PR description"
fallback_for_toolsets: [git, code-review]
---

# Standard procedure for writing a PR description

1. Summarize the goal of the change in one sentence
2. List the changes (grouped by module)
3. Blast radius
4. Testing status
5. Related issue / rollback plan

그 특성:

• 절차적: "트리거 시기 + 수행 방법"으로 존재하며 재사용 가능한 SOP에 가깝습니다.
• 시나리오에 의해 트리거됨: 에이전트가 일치하는 상황을 인식하면 스킬이 해당 작업을 안내하는 우선 순위가 높은 프롬프트로 자동으로 로드됩니다.
• 상대적으로 안정적: 스킬이 한 번 정착하면 대체로 그대로 유지되고, 스킬이 적용되는 상황과 참고 자료가 메모리에서 바뀝니다.

스킬을 에이전트의 근육 메모리라고 생각하면 됩니다. 별도로 사실을 회상하지 않아도 상황이 오면 절차가 실행됩니다.

Hermes 사용자는 /learn를 실행하여 에이전트가 "성문화할 가치가 있는 이 세션의 일부"를 새로운 SKILL.md로 추출하도록 할 수도 있습니다. 이는 멘토가 견습생에게 방법을 전달하는 것과 유사합니다.

4. "왜 병합하지 않나요?" — 세 가지 엄격한 제약

둘 다 Markdown으로 작성되고 장기적으로 유지되는데 하나로 합치면 되지 않느냐는 질문이 나올 수 있습니다.

작동하지 않기 때문입니다. 그 이유는 USER.md와 MEMORY.md를 구분하는 세 가지 제약 조건과 유사하지만 여기서는 더욱 강력합니다.

제약 1: 서로 다른 트리거

• 메모리는 "쿼리가 일치할 때 호출됩니다"(FTS5 및 의미 요약).
• 스킬은 "시나리오가 일치할 때 로드"되며 일반적으로 명시적인 트리거(trigger.when: "user asks to write a PR description")를 사용합니다.

병합된 에이전트는 사실을 인용하고 있는지 아니면 절차를 따르고 있는지 추적하지 못합니다.

제약 2: 서로 다른 형식

• 메모리는 짧은 문장, 사실, 항목("[2026-07-30] agent-demo frontend local dev port")입니다.
• 스킬은 절차, 템플릿, 제약이며 일반적으로 YAML 머리말에 "1/2/3단계" 순서가 추가됩니다.

함께 포장된 에이전트는 "이 배경이 맞는지, 아니면 지금 당장 실행해야 하는 것인지" 알 수 없습니다.

제약 3: 서로 다른 변화 속도

• 메모리는 매일 변경됩니다(단일 세션에 하나 또는 두 개의 항목이 추가될 수 있습니다).
• 스킬은 몇 달 동안 변경되지 않고 그대로 있을 수 있습니다(PR 설명을 위한 SOP는 반년 동안 편집이 필요하지 않습니다).

둘을 한데 섞으면 헌법과 탁상 달력을 같은 노트에 적는 것처럼, 자주 바뀌는 사실 항목이 안정적인 SOP를 밀어낼 수 있습니다.

5. 실제 시나리오: /learn와 메모리가 함께 작동

에이전트에게 다음과 같이 말한다고 가정해 보겠습니다.

"이제부터 우리 팀에서는 한 문장 요약, 변경 사항 목록, 폭발 반경, 테스트 상태 등의 형식으로 PR 설명을 작성합니다. 또한 이 프로젝트의 이름은 agent-demo이고 프런트엔드는 로컬 개발 포트에서 실행된다는 점을 기억하세요."

잘 훈련된 Hermes Agent는 이를 다음과 같이 처리합니다.

• 전반 → /learn 경로, 새 스킬 작성: pr-description-format.md, user asks to write a PR description에 의해 트리거됨.
• 후반 → add 원자 연산, 하나의 메모리 항목 작성: - [2026-07-30] agent-demo: frontend dev server on a local dev port.

다음에 "PR 설명 작성"이라고 말하면 에이전트는 다음을 수행합니다.

1. 시나리오를 일치시키고 스킬을 로드합니다: pr-description-format.md가 우선 순위가 높은 프롬프트에 들어갑니다.
2. 쿼리로 메모리 일치: 현재 프로젝트가 로컬 개발 포트에서 실행 중인 agent-demo라는 것을 알고 있습니다.
3. 둘 다 결합: 팀 표준을 따르고 특정 프로젝트에 맞는 PR 설명을 생성합니다.

사실을 기억하고 절차를 기억하면 부분의 합보다 더 나은 결과를 얻을 수 있습니다.

6. 스킬 번들 및 fallback_for_toolsets

Hermes는 스킬 위에 두 개의 조직 계층을 추가합니다.

• 스킬 번들: 관련 스킬이 그룹으로 패키지되어 있습니다. "릴리스 파이프라인" 번들에는 활성화, 비활성화 또는 하나의 단위로 공유되는 pre-release-checklist, changelog-format 및 deploy-rollback가 포함될 수 있습니다.
• fallback_for_toolsets: 스킬은 ​​해당 도구 세트가 실패할 때 해당 도구 세트를 백업한다고 선언할 수 있습니다. 예를 들어 git 도구 세트에서 오류가 발생하면 수동 리베이스 복구 단계가 포함된 스킬이 실행됩니다.

이를 통해 스킬은 단일 지점 SOP에서 구성 가능한 작업 방법론으로 전환됩니다. 이는 사용자가 공유 가능한 자산으로 캡처된 에이전트에 제공하는 전체 작업 방식입니다.

7. 새로운 개념은 아니지만 제대로 구현된 사례는 드뭅니다

사실 메모리와 절차 메모리를 레이어로 나누는 개념은 AI 분야에서 오래전부터 논의되었습니다. Hermes의 특징은 이를 실제 시스템으로 구현하고 사용자가 확인하고 편집하며 재사용할 수 있게 했다는 점입니다. 각 레이어가 구체적인 디렉터리, 필드, 명령에 대응합니다.

해당 레이어를 제품 컨텍스트에 적용하면 진정한 잠재력을 지닌 형태를 얻을 수 있습니다.

• 메모리는 귀하와 에이전트 간의 공유 아카이브입니다.
• 스킬은 에이전트에 가져온 작업 방법론입니다.

이 두 가지가 합쳐지면 에이전트는 괜찮은 메모리를 갖춘 챗봇이 아니라 당신을 이해하고 작업 방법을 아는 파트너가 됩니다.

8. LightVela: 메모리와 스킬을 모두 사용자 자산으로 전환

Hermes는 메모리와 스킬의 분리를 실제로 사용할 수 있는 엔지니어링 구조로 만들었지만, 기본 형태는 여전히 개발자를 위한 Markdown 파일입니다. LightVela는 이 레이어를 기술 기능에 머물게 하지 않고 사용자가 활용할 수 있는 자산으로 제공하는 방향을 취합니다.

• 개인용 스킬 라이브러리: 사용자는 프롬프트를 수집하는 방식으로 자신의 스킬(워크플로)를 수집, 편집 및 공유하고 이를 트리거 시나리오에 바인딩할 수 있습니다. 귀하의 글쓰기 패턴, 리뷰 SOP 및 번역 표준이 모두 스킬이 될 수 있습니다.
• 개인용 메모리 라이브러리: 에이전트가 귀하에 대해 보유하고 있는 모든 실제 메모리는 투명하고, 보고, 수정 및 삭제할 수 있습니다. ~/.hermes/MEMORY.md를 편집할 필요가 없습니다.
• 팀 수준 재사용: 스킬 및 메모리는 모두 팀 범위에서 캡처할 수 있으므로 새로운 참여자는 입소문에 의존하는 대신 팀의 공유 메모리 및 공유 방법을 자동으로 상속받습니다.
• 최단 경로: "두 다리" 모델이 마음에 들지만 Ollama, SSH, systemd 및 ~/.hermes/ 백업을 처리하고 싶지 않은 경우 LightVela는 ​​완제품인 모델에 대한 최단 경로입니다.

즉, LightVela에서 에이전트를 훈련한다는 것은 두 개의 자산을 동시에 축적하는 것을 의미합니다: 귀하에 대한 메모리와 귀하의 스킬 컬렉션입니다. 이 두 자산은 장기적으로 귀하의 자산입니다. 모델 자체보다 더 중요합니다.

핵심 요약

• 메모리 ≠ 스킬. 첫 번째는 선언적 메모리(설명할 수 있는 사실)이고, 두 번째는 절차적 메모리(수행되는 방법)입니다.
• 세 가지 엄격한 제약으로 인해 서로 분리되어 있습니다. 다른 트리거/다른 형태/다른 변화율
• 성숙한 에이전트에는 사실을 기억하는 능력과 작업 방법을 재사용하는 능력이 모두 필요합니다.
• LightVela는 두 요소를 사용자 자산으로 제공하여 "자신만의 에이전트를 학습시킨다"는 개념을 실제 제품 경험으로 연결합니다.

결론

이 카테고리의 다섯 글은 다음 주제를 차례로 다룹니다.

1. Hermes Agent와 OpenClaw의 차이점(누적 vs 연결)
2. Hermes Agent가 당신을 기억하는 방법(4개의 구조화된 메모리 레이어)
3. Hermes Agent가 메모리를 둘로 분할하는 이유(USER.md 대 MEMORY.md)
4. 더 많은 메모리가 더 좋지 않은 이유: Hermes Agent가 메모리를 장기적으로 필터링, 선별 및 업데이트하는 방법(4가지 철칙)
5. 메모리는 스킬이 아닙니다. 사실적 및 절차적 메모리의 차이점(두 다리로 걷기)

마쳐야 할 한 줄: 차세대 에이전트의 해자는 모델 크기가 아니라 에이전트가 진정으로 사용자를 알고(메모리) 방법이 있는지(스킬) — 그리고 이 두 가지가 장기적으로 안정적으로 실행될 수 있는지 여부는 살아남는 여부에 달려 있습니다. 이것이 바로 LightVela가 존재하는 이유입니다.