Standard procedure for release notes

요약

에이전트가 사용할수록 나아지는 이유는 백그라운드에서 알 수 없는 방식으로 스스로 업그레이드되기 때문이 아니라, 두 종류의 정보를 구조화해 남기기 때문입니다. 안정적인 사실은 메모리로, 재사용할 방법은 스킬로 축적되며 관련 상황에서 다시 불러옵니다. 메모리는 무슨 일이 있었는지 알려 주고 질문이 일치할 때 회상됩니다. 스킬은 다음번에 무엇을 해야 하는지 알려 주고 상황이 일치할 때 로드됩니다. 트리거, 형식, 변화 속도가 서로 다르므로 둘은 하나로 합칠 수 없습니다. Hermes는 /learn으로 현재 세션에서 검증한 절차를 SKILL.md로 추출하고 /skills pending에서 검토하게 하므로, 자기 개선이 통제되지 않는 자기 수정으로 번지는 것을 막습니다. 잘 설계된 스킬은 사용 시점, 실행 단계, 성공 기준, 넘지 말아야 할 경계를 명시해야 합니다. 많이 축적하는 것보다 제품이 바뀌어도 검토·재사용·업데이트할 수 있게 유지하는 것이 중요합니다.

재사용할 수 없는 경험은 일회성 대화에 머뭅니다

유난히 잘 풀렸던 세션을 떠올려 보세요. 사용자와 에이전트가 함께 문제를 디버깅하거나 완성도 높은 릴리스 노트를 만들었을 수 있습니다. 그 과정에서 "범위를 좁혀라", "형식을 통일하라", "이 검사는 반드시 거쳐라"처럼 서너 번 교정했고, 결과도 만족스러웠습니다.

일주일 뒤 같은 종류의 작업이 다시 들어옵니다. 앞서 한 교정이 지난주 채팅 기록에만 남아 있다면 똑같은 지시를 반복해야 합니다. 그 조정 과정은 재사용할 자산이 되지 못하고 일회성 비용으로 끝난 셈입니다.

"사용할수록 좋아진다"는 말의 핵심은 에이전트가 저절로 더 똑똑해진다는 뜻이 아닙니다. 실제로 검증된 내용을 구조화된 형태로 남긴다는 뜻입니다. 무엇을 어떤 방식으로 어디에 보관하는지에 따라 경험이 자산으로 축적될지, 매 세션을 처음부터 다시 시작할지가 결정됩니다.

1. 합칠 수 없는 두 종류의 축적

에이전트는 근본적으로 다른 두 가지를 축적합니다.

일치하는 예시 쌍:

• "이 사용자는 결론을 먼저 선호합니다." → 메모리. 그것은 당신에 관한 사실입니다.
• "릴리스 노트를 작성하기 전에 버전 번호와 모든 링크가 해결되는지 확인하세요." → 스킬. 그런 작업이 나타날 때마다 실행하는 절차입니다.

둘을 합칠 수 없는 이유는 적어도 세 가지입니다. 트리거가 다르고(질문 일치와 상황 일치), 형식이 다르며(짧은 항목과 순서가 있는 단계), 변화 속도도 다릅니다(매일과 매월). 자주 바뀌는 사실 목록에 안정적인 절차를 섞으면 오래 유지해야 할 내용이 묻힙니다. 자세한 설명은 "메모리는 스킬이 아닙니다: Hermes Agent가 사실 메모리와 절차 메모리를 구분하는 방법"을 참조하세요.

이 구분은 실무에서도 바로 도움이 됩니다. 같은 유형의 행동을 반복해서 교정하고 있다면 메모리에 사실을 하나 더 넣을 것이 아니라 스킬로 절차를 남겨야 합니다.

2. 스킬의 구성

Hermes의 스킬은 보통 트리거와 실행에 필요한 정보를 YAML 프런트매터에 선언한 SKILL.md 파일입니다. 기본 형태는 다음과 같습니다.

---
name: release-note-format
trigger:
  when: "user asks to write release notes"
---

# Standard procedure for release notes

1. Confirm the version number and release date
2. Group entries as Added / Fixed / Changed
3. Verify every external link resolves
4. Check for internal project names or ports; replace with placeholders
5. Confirm length fits the publishing channel's limits

trigger가 중요합니다. 이는 스킬을 수동으로 호출하지 않는다는 의미입니다. 일치하는 상황이 인식되면 스킬은 해당 실행을 안내하는 우선 순위가 높은 명령으로 자동으로 로드됩니다.

Hermes는 두 가지 조직 계층을 추가합니다.

• 스킬 번들 — 그룹으로 활성화, 비활성화 또는 공유할 수 있는 스킬 관련 패키지입니다. "릴리스 파이프라인" 번들에는 출시 전 검사, 변경 로그 형식 및 롤백 단계가 포함될 수 있습니다.
• fallback_for_toolsets — 스킬은 특정 도구 세트 호출이 실패할 때 자체적으로 폴백을 선언할 수 있으므로 실패 경로에도 정의된 절차가 있습니다.

이를 통해 스킬은 격리된 SOP에서 구성 가능한 작업 방법론으로 전환됩니다.

3. /learn: 성공한 실행을 재사용 가능한 방법으로 전환

스킬을 남기려고 대화를 끝내고 직접 파일을 작성할 필요는 없습니다. Hermes의 /learn을 사용하면 에이전트가 현재 세션에서 재사용할 가치가 있는 절차를 새 SKILL.md로 추출할 수 있습니다.

이 디자인의 가치는 메모리가 가장 신선할 때 캡처가 이루어진다는 것입니다. 성공적인 협업 직후 귀하와 에이전트는 어떤 단계가 중요했고 어떤 수정이 필수적인지 알게 됩니다. 일주일 후에 작성하면 세부 사항이 이미 사라졌습니다.

그러나 자동 증류는 해결해야 할 문제를 야기합니다. 에이전트가 마음대로 자체적으로 동작 규칙을 추가할 수 있는 경우 동작을 예측할 수 없게 됩니다. Hermes는 검토 단계로 이를 처리합니다. /skills pending를 통해 보류 중인 스킬을 검사하고 채택 여부를 결정합니다. 이는 메모리 측의 /memory pending를 미러링합니다.

자기 개선은 무한한 자체 수정이 아닙니다. 신뢰할 수 있는 경로는 새로운 방법이 먼저 검토 가능한 규칙이 되어 확인 후에만 적용되는 것입니다. 이것이 바로 역량 성장을 설명 가능하고 재사용 가능하며 수정 가능하게 만드는 것입니다.

4. 잘 설계된 스킬이 명시해야 할 네 가지

다음 네 가지가 유용한 스킬과 문제를 일으키는 스킬을 가릅니다. 하나라도 빠지면 실제 작업에서 잘못 실행될 수 있습니다.

첫째, 언제 사용할 것인가. 트리거 상황은 구체적이어야 합니다. "문서를 처리할 때"는 너무 광범위하며 속하지 않는 컨텍스트에서 로드됩니다. "사용자가 릴리스 노트를 요청할 때"는 충분히 구체적입니다. 지나치게 광범위한 스킬은 관련 없는 작업을 방해하기 때문에 스킬이 없는 것보다 더 나쁩니다.

둘째, 따라야 할 단계입니다. 단계는 순서가 지정되고 실행 가능해야 합니다. "품질에 주의"는 한 단계가 아닙니다. "모든 외부 링크가 확인되는지 확인하십시오"입니다. 테스트: 다른 사람이 이 스킬을 따르고 광범위하게 일관된 결과를 생성할 수 있습니까?

셋째, 성공의 모습. 성공 기준이 없으면 에이전트는 자체 점검을 할 수 없으며 실행이 허용되는지 여부를 판단할 수 없습니다. 예를 들어 "세 그룹이 모두 존재하며 각각에는 적어도 하나의 항목이 있거나 그룹이 비어 있다는 명시적인 메모가 있습니다."와 같이 이를 검증 가능하게 만듭니다.

넷째, 경계를 넘어서는 안 됩니다. "예제에는 실제 내부 프로젝트 이름이나 포트가 없습니다."와 같이 금지 사항을 명시적으로 명시합니다. 경계는 스킬에서 가장 자주 생략되는 부분이자 가장 일반적인 사고 원인입니다.

네 가지 모두를 갖춘 스킬은 하나의 특성을 공유합니다. 인간과 에이전트 모두에게 똑같이 잘 읽혀집니다. 그것이 무엇을 하는지 이해할 수 있기 때문에 문제가 발생했을 때 정확하게 수정할 수 있습니다. 이것이 바로 수정 가능을 위한 전제 조건입니다.

5. 축적이 성과를 거두는 세 가지 단계

스킬로 남기는 작업은 한 번의 동작이 아니라 순서가 있는 과정입니다. 어느 단계든 건너뛰면 품질이 떨어집니다.

1단계: 먼저 실제 작업에서 절차를 증명하십시오. 스킬을 상상으로 작성하지 마십시오. 실제 작업에 대해 실행되지 않는 절차는 캡처된 경우에만 실수를 확증할 뿐입니다. 한 번만 수행하고 도중에 수정 사항을 기록해 두십시오.

2단계: 안정적이고 재사용 가능한 단계만 기록합니다. 여기서 안정적은 다음 주에도 바뀌지 않는다는 뜻이고, 재사용 가능은 현재 사례 외에도 적용할 수 있다는 뜻입니다. 일회성 절차는 유지관리 비용이 얻는 이익보다 크므로 스킬로 남길 가치가 없습니다.

3단계: 제품, 도구 또는 정책이 변경되면 스킬을 업데이트합니다. 가장 자주 건너뛰는 단계입니다. 이동된 진입점 또는 이후 조정된 한도를 참조하는 6개월 전에 작성된 스킬은 계속해서 오래된 지침을 발행합니다. 오래된 경험을 무한정 재사용하는 것은 아무것도 없는 것보다 더 위험합니다. 왜냐하면 "증명"되었다는 신뢰성을 지니고 있기 때문입니다.

실용적인 유지 관리 습관: 스킬의 출력을 수동으로 반복적으로 수정하면 해당 출력이 만료됩니다. 문제를 해결하기보다는 업데이트하세요.

6. 일반적인 함정

4행은 강조할 가치가 있습니다. 스킬 라이브러리의 가치는 크기에 비례하지 않습니다. 만료된 스킬 하나는 자동으로 로드되고 신뢰할 수 있어 보이기 때문에 하나의 만료된 스킬이 좋은 라이브러리를 반환하는 것보다 더 많은 비용이 들 수 있습니다.

7. LightVela의 접근 방식: 작업 방법도 사용자 자산으로 관리

Hermes는 메모리와 스킬을 분리한 엔지니어링 구조를 제공하지만, 기본적으로 Markdown을 직접 편집하는 사용자를 전제로 합니다. LightVela는 클라우드 호스팅 방식이며 사용자에게 파일 시스템 작업을 노출하지 않으므로 두 종류의 축적을 다음과 같이 다룹니다.

• 스킬은 공개 마켓플레이스에서 나옵니다 — 모든 스킬은 OpenClaw 및 Hermes가 공유하는 스킬 마켓플레이스인 Skills.sh 및 ClawHub에서 나오므로 처음부터 작성하지 않습니다.
• 대화를 통해 설치 및 제거 — Hermes에게 설치할 스킬을 알려주면 이를 처리합니다. 제거는 같은 방식으로 작동합니다. 나중에 채팅에서 가용성을 확인하세요. 콘솔 패널 설치가 곧 제공될 예정입니다.
• 메모리는 콘솔에서 볼 수 있습니다 — 메모리 페이지에는 에이전트가 유지한 내용이 표시되고 용량 제한을 조정할 수 있습니다. 추가 및 제거는 대화를 통해 이루어집니다.
• 모델 및 채널에서 안정적 — 모델을 전환해도 스킬이나 자동 작업이 삭제되지 않으며 연결된 모든 채널은 동일한 스킬과 메모리를 공유합니다.
• 실패 추적 가능 — 스킬이 오작동하는 경우 진단(1, 3, 6, 12 또는 24시간 범위 선택 가능)에서 최근 로그를 보고 내보내 문제를 찾습니다.

즉, LightVela에서 에이전트를 사용한다는 것은 귀하에 대한 메모리와 설치되고 검증된 스킬 세트라는 두 가지를 축적한다는 것을 의미합니다. 둘 다 특정 모델보다 더 오래 서비스를 제공합니다.

핵심 요약

• 사용할수록 좋아지는 것은 신비한 자가 업그레이드가 아니라 구조화된 축적에서 나옵니다.
• 두 종류는 구분해야 합니다. 메모리는 사실을 저장하고 쿼리가 일치할 때 호출되며, 스킬은 방법을 저장하고 상황이 일치할 때 로드됩니다.
• 동일한 동작을 계속 수정하는 경우 다른 사실을 추가하기보다는 스킬을 캡처하세요.
• /learn는 세부 내용이 생생할 때 작업 방법을 기록하고, /skills pending는 검토 단계를 제공하므로 자기 개선은 무제한 자기 수정이 아닙니다.
• 잘 설계된 스킬은 사용 시기, 단계, 성공 기준, 경계라는 네 가지 사항을 명시합니다.
• 스킬은 실제 작업에서 절차 검증 → 안정적이고 재사용 가능한 단계 기록 → 변경 시 업데이트의 세 단계로 관리합니다. 낡은 스킬은 스킬이 없는 것보다 더 위험할 수 있습니다.