Hermes 0.12 Curator 실전 사용법

Hermes Agent 0.12의 Curator는 “스킬을 알아서 정리해주는 기능” 정도로 쓰면 위험합니다. 정확히는 오래 운영되는 에이전트의 작업 습관을 점검하고, 낡은 지침과 중복된 절차를 발견하며, 사람이 승인할 수 있는 보고서로 만들어주는 운영 도구에 가깝습니다. 잘 쓰면 Hermes가 시간이 지날수록 더 안정적인 동료가 되고, 잘못 쓰면 중요한 운영 절차를 너무 가볍게 합치거나 지워버리는 문제가 생길 수 있습니다.

이 글의 목표는 Curator를 켜는 법만 알려주는 것이 아닙니다. 어떤 스킬은 자동 정리해도 되는지, 어떤 스킬은 제안만 받아야 하는지, 보고서에서 무엇을 먼저 봐야 하는지, self-improvement loop가 스킬을 바꿀 때 어디서 멈춰야 하는지를 실제 운영 절차로 정리합니다.

Curator를 쓰기 전에 먼저 정해야 할 것

Curator를 실행하기 전에는 스킬 라이브러리를 세 종류로 나눠야 합니다. 이 분류 없이 자동 정리를 맡기면, 사용자는 “정리가 됐다”고 느끼지만 실제로는 에이전트의 판단 기준이 갑자기 바뀔 수 있습니다.

예를 들어 Hermes로 사이트 콘텐츠를 운영한다면 “DB 업로드 후 revalidate한다” 같은 최신 게시 절차는 보호 스킬에 가깝습니다. 반면 “예전 실험용 이미지 프롬프트 작성법”처럼 실패해도 서비스 영향이 없는 것은 정리 가능 스킬이 될 수 있습니다. “뉴스 기사 구조를 어떻게 잡을 것인가” 같은 콘텐츠 품질 스킬은 중간입니다. 자동 변경보다는 제안을 보고 사람이 승인하는 편이 좋습니다.

핵심은 위험도가 아니라 되돌리기 비용입니다. 잘못 정리해도 바로 다시 만들 수 있는 스킬은 Curator에게 맡길 수 있습니다. 하지만 잘못 정리하면 배포 사고, 데이터 손상, 공개 정보 노출, 품질 저하로 이어지는 스킬은 보호해야 합니다.

기본 사용 흐름: 상태 확인, 실행, 보고서 읽기

Hermes 0.12 릴리스에 따르면 Curator는 gateway cron ticker 위에서 기본 7일 주기로 동작할 수 있고, hermes curator status로 사용 빈도 기반 상태를 확인할 수 있습니다. 실제 운영에서는 바로 자동 실행부터 시작하지 말고, 먼저 현재 스킬 상태를 보는 습관을 들이는 것이 좋습니다.

첫 단계는 상태 확인입니다. 가장 많이 쓰인 스킬은 에이전트의 핵심 습관입니다. 여기에 오래된 내용이 있으면 영향이 큽니다. 가장 적게 쓰인 스킬은 삭제 후보일 수 있지만, 장애 복구처럼 드물게 쓰이는 중요한 절차일 수도 있습니다. 따라서 “least-used”를 곧바로 삭제 대상으로 보면 안 됩니다.

두 번째 단계는 수동 실행 또는 낮은 위험도의 주기 실행입니다. 처음부터 모든 스킬을 대상으로 정리하지 말고, 실험용·개인용·낮은 위험도 그룹부터 시작하는 편이 좋습니다. 운영 스킬이 많은 환경에서는 첫 실행을 “제안 생성용”으로 보고, 실제 변경은 보고서 검토 뒤에 반영해야 합니다.

세 번째 단계는 보고서 읽기입니다. 보고서는 성공 여부만 보는 것이 아니라 다음 네 가지를 봐야 합니다. 어떤 스킬이 통합 후보가 되었는가, 어떤 스킬이 삭제 후보가 되었는가, 어떤 스킬이 너무 자주 쓰이는가, 어떤 스킬이 거의 쓰이지 않는가입니다. 특히 너무 자주 쓰이는 스킬은 중요도가 높다는 뜻이므로, 오히려 더 엄격하게 검토해야 합니다.

보고서에서 가장 먼저 볼 항목

Curator 보고서를 받으면 삭제 후보보다 통합 후보를 먼저 보세요. 삭제는 눈에 띄지만, 실제 사고는 통합에서 자주 납니다. 두 스킬이 비슷해 보여도 하나는 “글쓰기 품질”을 다루고 다른 하나는 “배포 전 검증”을 다룰 수 있습니다. 이 둘을 합치면 에이전트가 글을 쓰다가 불필요한 배포 판단까지 끌고 들어올 수 있습니다.

두 번째로 볼 것은 보호 스킬 침범 여부입니다. 보고서가 배포, 계정, 보안, 데이터, 복구와 관련된 스킬을 바꾸려 한다면 자동 반영하지 않는 편이 안전합니다. 이런 스킬은 잘못 고치면 당장 편해 보이지만, 사고가 났을 때 복구 기준을 잃게 됩니다.

세 번째로 볼 것은 “왜 안 쓰였는가”입니다. 어떤 스킬이 거의 쓰이지 않았다면 세 가지 가능성이 있습니다. 정말 필요 없거나, 이름과 설명이 나빠서 에이전트가 찾지 못했거나, 특정 상황에서만 쓰는 비상 절차입니다. 예를 들어 “복구 리허설” 스킬이 한 달간 안 쓰였다고 삭제하면, 실제 장애 때 가장 필요한 절차를 잃을 수 있습니다.

네 번째로 볼 것은 새로 보강된 내용의 품질입니다. self-improvement loop가 방금 사용한 스킬을 적극적으로 업데이트한다면, 실제 경험이 스킬에 반영되는 장점이 생깁니다. 하지만 그 경험이 특정 상황에만 맞는 임시 해결책인지, 앞으로도 반복 가능한 절차인지 구분해야 합니다.

상황별 사용 예시 1: 콘텐츠 운영 Hermes

Vive Coding 365 같은 콘텐츠 사이트를 Hermes가 운영한다고 가정해보겠습니다. 이때 Hermes는 뉴스 기사, Hermes 팁, VIBE 코딩 글, GitHub 프로젝트 큐레이션, 품질 감사 같은 스킬을 갖고 있을 수 있습니다. 스킬이 많아지면 각 코너의 톤과 검증 기준이 섞이기 쉽습니다.

이 환경에서 Curator를 쓰는 좋은 방식은 코너별 경계를 보존하는 것입니다. 뉴스 스킬은 공식 출처, 사실 검증, 저작권 안전성을 중시해야 합니다. Hermes 팁 스킬은 실전 사용법, 예시, 운영 절차를 중시해야 합니다. GitHub 프로젝트 큐레이션은 별점, 최근 활동, 실용성, VIBE 코딩 적합성을 봐야 합니다. 이 세 가지를 “콘텐츠 작성 스킬” 하나로 합치면 편해 보이지만 품질 기준이 흐려집니다.

따라서 Curator 보고서에서 콘텐츠 관련 스킬 통합 제안이 나오면 먼저 질문해야 합니다. 이 통합이 코너별 품질 기준을 보존하는가? 뉴스의 공식 출처 원칙과 팁 글의 실전 예시 원칙이 서로 섞여 약해지지 않는가? 독자가 읽기 좋은 글을 만드는 기준이 살아 있는가? 이런 질문에 답이 애매하면 통합하지 않는 편이 낫습니다.

상황별 사용 예시 2: 개발·배포 Hermes

개발 프로젝트에서 Hermes를 쓰면 테스트, lint, build, commit, deploy, live smoke 같은 스킬이 쌓입니다. 이 영역에서는 Curator가 특히 조심스럽게 다뤄져야 합니다. 개발 스킬은 대부분 실제 파일 변경과 외부 서비스 상태에 영향을 주기 때문입니다.

예를 들어 “테스트를 빠르게 돌리는 법”과 “배포 전 전체 검증”은 비슷해 보여도 목적이 다릅니다. 빠른 테스트 스킬은 개발 중 피드백 속도를 높이기 위한 것이고, 배포 전 검증 스킬은 공개 서비스 안전을 위한 것입니다. Curator가 둘을 합치면 에이전트가 배포 전에도 빠른 테스트만 돌리고 넘어가는 나쁜 습관을 배울 수 있습니다.

개발·배포 환경에서는 Curator의 자동 반영 범위를 낮게 잡는 것이 좋습니다. 문장 보강, 누락된 주의사항 추가, 명령 순서 설명 개선은 허용할 수 있습니다. 하지만 검증 단계를 줄이거나, 승인 절차를 생략하거나, 배포 조건을 완화하는 변경은 반드시 사람이 확인해야 합니다.

상황별 사용 예시 3: 개인 생산성 Hermes

개인 생산성 환경에서는 Curator를 비교적 적극적으로 쓸 수 있습니다. 예를 들어 회의 요약, 일정 정리, 글 초안 작성, 아이디어 브레인스토밍 같은 스킬은 실패 비용이 낮은 편입니다. 이런 스킬은 Curator가 중복을 줄이고 표현을 개선하고 오래된 예시를 정리해도 큰 문제가 생기지 않습니다.

다만 개인 생산성에서도 계정 연결, 외부 공유, 메신저 전송이 들어가면 위험도가 올라갑니다. Google Meet 회의록을 요약하는 스킬은 괜찮아 보여도, 그 요약을 Teams나 Slack에 자동 전송하는 순간 공개 범위 문제가 됩니다. Spotify 같은 개인 계정 통합도 OAuth와 기기 제어가 들어가므로, 단순한 메모 스킬과 같은 위험도로 보면 안 됩니다.

따라서 개인 생산성 Hermes에서도 “내가 보는 결과물”과 “외부로 보내는 결과물”을 나눠야 합니다. Curator가 내 메모 정리 방식을 바꾸는 것은 허용할 수 있지만, 외부 채널 전송 규칙을 바꾸는 것은 승인 후 반영해야 합니다.

self-improvement loop를 안전하게 쓰는 법

Hermes 0.12의 self-improvement loop는 방금 사용한 스킬을 더 적극적으로 업데이트하는 방향으로 개선됐습니다. 이 기능은 아주 유용합니다. 실제 작업에서 실패한 지점이 바로 스킬에 보강되면, 다음 작업에서 같은 실수를 줄일 수 있기 때문입니다.

하지만 좋은 자기 개선에는 세 가지 조건이 필요합니다. 첫째, 관찰이 구체적이어야 합니다. “글을 더 잘 쓰기”가 아니라 “릴리스 기사에서는 변경점, 개선점, 실제 사용법, 위험을 각각 설명한다”처럼 다음 작업에서 바로 적용 가능한 문장이어야 합니다. 둘째, 범위가 좁아야 합니다. 한 번의 실패를 모든 글쓰기나 모든 배포에 적용하면 과잉 일반화가 됩니다. 셋째, 검증 방법이 있어야 합니다. 스킬이 바뀐 뒤에는 실제 결과물이 나아졌는지 확인해야 합니다.

예를 들어 Hermes 팁 글이 너무 얕았다는 피드백을 받았다면, 좋은 자기 개선은 “Hermes 팁은 기능 소개만 쓰지 말고, 언제 쓰는지, 어떤 순서로 쓰는지, 실패하면 어디서 멈추는지, 상황별 예시를 포함한다”입니다. 나쁜 자기 개선은 “항상 글을 길게 쓴다”입니다. 길이는 품질이 아닙니다. 독자가 바로 써먹을 수 있는 구조가 품질입니다.

승인 경계와 중단 기준

Curator와 self-improvement loop에는 명확한 중단 기준이 있어야 합니다. 다음 조건에 걸리면 자동 반영하지 말고 사람이 보고 판단하는 편이 안전합니다.

운영자는 Curator에게 “정리해줘”라고만 맡기면 안 됩니다. “보호 스킬은 건드리지 말고, 검토 스킬은 제안만 하고, 낮은 위험도 스킬만 자동 정리하라”는 경계를 줘야 합니다. Hermes가 똑똑해질수록 이런 경계가 더 중요해집니다.

주간 운영 루틴으로 만들기

Curator는 매일 들여다볼 필요는 없습니다. 공식 기본 주기가 7일이라는 점을 생각하면 주간 루틴이 자연스럽습니다. 추천 루틴은 다음과 같습니다.

중요한 것은 한 번에 많이 정리하는 것이 아닙니다. Curator의 목표는 스킬 수를 줄이는 것이 아니라 Hermes의 행동 기준을 선명하게 만드는 것입니다. 스킬이 줄었는데 결과물이 나빠졌다면 실패입니다. 스킬이 그대로여도 설명이 선명해지고 중복이 줄고 보호 경계가 생겼다면 성공입니다.

좋은 Curator 운영의 체크리스트

마지막으로 실제 운영 전에 이 체크리스트를 확인하세요.

• 보호 스킬 목록을 정했는가?
• 통합해도 되는 스킬과 분리해야 하는 스킬을 구분했는가?
• 삭제 후보를 “안 쓰임”만 보고 판단하지 않았는가?
• self-improvement가 방금 작업의 실패를 너무 넓게 일반화하지 않았는가?
• 변경 뒤 실제 결과물을 확인할 방법이 있는가?
• 외부 채널 전송, 계정 연결, 배포, 데이터 변경은 승인 경계 안에 있는가?
• Curator 보고서를 읽는 주간 루틴이 있는가?

Hermes 0.12의 Curator는 에이전트를 마법처럼 똑똑하게 만드는 버튼이 아닙니다. 오래 일하는 에이전트의 습관을 정리하고, 잘못된 반복을 줄이고, 사람이 더 좋은 운영 판단을 하도록 돕는 장치입니다. 제대로 쓰려면 자동화보다 경계가 먼저이고, 정리보다 검토가 먼저이며, 속도보다 되돌릴 수 있음이 먼저입니다.

참고한 공식 출처

• Hermes Agent v0.12.0 release
• NousResearch/hermes-agent releases
• NousResearch/hermes-agent repository

적용 전 확인

먼저 작업 범위와 성공 기준을 한 문장으로 적는다. Hermes가 무엇을 바꿀 수 있고 무엇을 바꾸면 안 되는지, 공개 반영 전에 어떤 검증을 통과해야 하는지 정하지 않으면 자동화는 속도보다 혼란을 만든다.

실행 중 관찰

실행 중에는 로그의 성공 메시지만 보지 말고 변경 파일, 데이터 반영 위치, 예상 marker, 브라우저 콘솔, 사용자에게 보이는 문구를 함께 확인한다. 이상 신호가 보이면 범위를 넓히지 말고 현재 단계에서 멈춘다.

완료 후 기록

완료 보고에는 변경 내용, 검증 명령, 공개 확인 결과, 남은 위험, 다음 운영자가 이어받을 조건을 남긴다. 이 기록이 있어야 장기 운영에서 같은 실수를 반복하지 않고 Hermes의 판단 기준도 안정된다.