Hermes Agent는 세션을 넘어 남는 메모리와, 필요할 때 불러오는 스킬 체계를 제공하는 자율형 에이전트입니다. 공식 문서에 따르면 메모리는 환경·프로젝트 관례·사용자 선호를 저장하는 제한된 크기의 파일로 관리되고, 스킬은 작업 시점에 불러오는 지식 문서로 제공됩니다.
이런 기능은 반복적인 개발·운영 업무에서 유용합니다. 그러나 업무 지식이 “에이전트가 기억한 내용”으로만 존재하기 시작하면, 최신 기준이 무엇인지와 누가 이를 승인했는지가 모호해질 수 있습니다. AX에서 기억은 편의 기능이고, 기준 데이터와 공식 절차는 DX 플랫폼 또는 승인된 지식 저장소에 있어야 합니다.
기억에는 무엇을 남기고, 무엇을 남기지 않을까
Hermes의 영속 메모리는 프로젝트 관례, 환경 정보, 작업 중 발견한 주의사항을 다음 세션에 이어 주는 용도에 적합합니다. 예를 들면 다음 정보입니다.
- 이 저장소의 빌드·테스트 명령
- 배포 전 반드시 확인할 점검 항목
- 특정 시스템 연동에서 자주 발생하는 오류와 확인 순서
- 팀이 합의한 코드 스타일 또는 문서 구조
반대로 아래 내용은 에이전트 메모리에만 두면 안 됩니다.
- 승인된 품질 기준의 원문
- 법규·절차의 최신 해석
- 고객사 식별 정보, 자격 증명, 민감 데이터
- 승인 책임과 변경 이력 자체
메모리는 빠른 맥락 복원에 쓰고, 공식 기준은 버전·권한·검토 이력이 관리되는 시스템에 둡니다.
스킬은 ‘자동화 코드’가 아니라 ‘업무 절차 문서’입니다
Hermes의 스킬은 필요한 시점에 에이전트가 읽는 지식 문서입니다. 따라서 스킬 하나를 만들 때도 업무 절차처럼 관리할 필요가 있습니다.
| 관리 항목 | 확인 내용 |
|---|---|
| 목적 | 어떤 업무의 어떤 판단을 보조하는가 |
| 입력 | 허용된 데이터 출처와 필요한 최소 정보는 무엇인가 |
| 출력 | 요약, 체크리스트, 초안 중 무엇을 만드는가 |
| 제한 | 에이전트가 하면 안 되는 결정·실행은 무엇인가 |
| 책임자 | 업무 기준과 스킬 내용을 검토·승인하는 사람은 누구인가 |
| 갱신 | 기준이 바뀌었을 때 누가 언제 수정하고 검증하는가 |
예를 들어 변경관리 검토 준비 스킬은 관련 변경 건과 기준 문서를 찾아 체크리스트 초안을 만들 수 있습니다. 그러나 변경의 허용 여부를 확정하거나, 승인자를 대신해 서명하는 절차가 되어서는 안 됩니다.
‘학습’과 ‘공식화’를 분리합니다
에이전트가 업무 중에 좋은 방법을 발견했더라도, 곧바로 표준 절차가 되는 것은 아닙니다. 다음과 같이 두 단계로 나누는 편이 안전합니다.
- 학습 후보: 에이전트가 발견한 반복 패턴, 실패 원인, 개선 아이디어를 임시로 기록합니다.
- 공식화: 담당자가 출처·적용 범위·예외를 검토한 뒤, 승인된 스킬 또는 절차 문서로 등록합니다.
이 분리는 규제산업의 문서 관리뿐 아니라 일반 개발 운영에도 유용합니다. 개인의 기억과 팀의 표준을 구분해야 담당자가 바뀌어도 같은 품질로 일을 이어갈 수 있기 때문입니다.
하나의 에이전트 프로필에 모든 업무를 섞지 않습니다
Hermes 문서는 여러 프로세스가 하나의 홈 디렉터리를 공유하지 않도록 안내합니다. 메모리와 설정을 자동으로 읽고 쓰는 에이전트라면, 업무 목적별 프로필과 데이터 범위를 분리하는 것이 기본입니다.
예를 들어 다음처럼 나눌 수 있습니다.
- 개발 지원: 코드베이스, 테스트, 개발 문서
- 운영 분석: 익명화된 로그와 운영 지표
- 규제 문서 검토 준비: 승인된 문서 저장소의 읽기 전용 범위
프로필 분리는 편의상 여러 봇을 만드는 일이 아니라, 지식·도구·자격 증명의 영향 범위를 작게 만드는 운영 설계입니다.
도입 검증에서 확인할 질문
Hermes Agent의 기억과 스킬 기능을 AX 검증 과제에 적용한다면 다음을 확인해야 합니다.
- 메모리가 없어도 업무 기준을 공식 출처에서 다시 확인할 수 있는가
- 스킬이 참조하는 문서는 버전과 접근 권한이 관리되는가
- 스킬 변경은 누가 검토하고, 언제 배포되는가
- 장기 실행 중 발견한 지식이 어떤 검토를 거쳐 표준이 되는가
- 다른 업무·고객의 맥락이 섞이지 않도록 프로필과 권한을 분리했는가
가상의 업무 예시: 점검 기준이 바뀐 경우
반복 점검 스킬의 기준을 바꾸는 가상 상황을 보겠습니다. 운영 팀이 새 확인 항목을 추가하려 할 때 담당자는 메모리에 문장을 덧붙이는 대신, 공식 기준 문서의 버전과 변경 사유를 먼저 검토합니다. 스킬은 그 문서를 어디서 읽고 어떤 체크리스트 초안을 만들지 연결할 뿐, 승인 기준의 원본이 되지 않습니다. 변경 뒤에는 이전 기준을 참조하던 작업이 없는지 확인하고, 책임자가 새 스킬의 출력과 제한을 승인합니다. 이 흐름을 두면 장기 대화에서 얻은 ‘기억’이 검증되지 않은 조직 규칙으로 굳는 일을 줄일 수 있습니다.
관리 체크리스트
- 메모리와 스킬이 참조하는 공식 출처·버전·책임자가 분명하다.
- 고객 식별 정보, 자격 증명, 승인 판단을 장기 기억에 남기지 않는다.
- 스킬의 입력·출력·금지 행동·갱신 절차를 문서로 관리한다.
- 변경된 스킬은 실제 업무 예시로 검증한 뒤 배포한다.
현재 쓰는 메모리나 프롬프트 하나를 골라 “공식 기준인가, 편의를 위한 힌트인가”를 표시해 보세요. 갱신이 필요한 항목은 담당자와 기한을 지정해 공식 기준의 변경 절차로 되돌려야, 편의를 위해 남긴 지식이 오래된 규칙으로 작동하는 일을 막을 수 있습니다.
기억의 오류는 조용히 누적됩니다
장기 기억은 틀린 사실을 한 번 저장했을 때 특히 위험합니다. 오래된 담당자 이름, 폐기된 승인 단계, 예외적으로 허용했던 처리 방법이 다음 작업의 기본값처럼 다시 사용될 수 있기 때문입니다. 그래서 기억 항목에는 출처 링크, 확인일, 적용 범위, 소유자를 붙이고, 일정 기간이 지나면 재확인 없이 사용하지 않는 만료 규칙을 둡니다. 출처가 없는 기억은 답변의 단서로만 쓰고, 업무 결정을 위한 근거로 승격하지 않습니다.
가상의 점검 스킬 개정 흐름을 보겠습니다. 현장 담당자가 점검 항목 하나를 자주 묻는다는 이유로 에이전트가 메모리에 답을 저장합니다. 담당자는 이를 공식 절차로 옮기기 전에 기준 문서의 최신 버전, 적용 설비 범위, 예외 처리, 검토자를 확인합니다. 스킬에는 원문을 복제하기보다 공식 문서의 위치와 필요한 입력·출력·금지 행동을 등록합니다. 변경 후에는 이전 버전으로 만든 초안과 새 버전의 차이를 표본 검토하고, 문제가 있으면 스킬을 비활성화해 기준 문서만 보게 합니다.
이 방식은 지식을 덜 쓰자는 뜻이 아닙니다. 기억은 빠른 맥락 복원에, 스킬은 반복된 절차 안내에, 승인된 지식 저장소는 판단의 원본에 쓰는 역할 분리가 핵심입니다. Hermes Agent의 메모리·스킬 기능을 적용할 때도 이 구분을 공식 문서와 조직의 보존 정책에 맞춰 검증해야 합니다.
스킬의 변경도 일반 업무 변경처럼 검토해야 합니다. 작성자는 새 지식의 출처와 적용 범위를 제시하고, 기준 책임자는 내용과 예외를 확인하며, 운영자는 실제 입력에서 위험한 답을 만들지 않는지 시험합니다. 오류가 발견되면 메모리만 조용히 고치지 말고 해당 스킬을 중지하거나 이전 승인 버전으로 되돌린 뒤, 이미 생성된 결과의 영향을 확인합니다. 이런 복구 경로가 있어야 지식의 편의성이 통제 불가능한 규칙으로 변하지 않습니다.
어떤 지식이 충돌할 때 무엇을 우선해야 할까
에이전트가 읽는 정보는 늘 한 방향으로 일치하지 않습니다. 메모리에는 지난달의 처리 관례가 남아 있고, 스킬은 올해 초 절차를 설명하며, 공식 저장소에는 어제 승인된 개정본이 있을 수 있습니다. 이때 더 구체적이거나 최근에 대화한 내용을 자동으로 우선하면 안 됩니다. 조직은 공식 원본, 승인된 스킬, 검토되지 않은 학습 후보, 개인 선호의 순서를 정하고, 상위 출처와 충돌하는 정보는 사용을 멈추도록 해야 합니다.
충돌을 발견한 에이전트의 역할은 어느 한쪽을 임의로 고르는 것이 아니라 차이를 보여 주는 것입니다. 문서 식별자와 버전, 유효일, 적용 업무를 제시하고 담당자에게 판단을 요청합니다. 기준 책임자는 새 문서가 해당 업무에 실제로 적용되는지 확인하고, 스킬 소유자는 영향을 받는 단계와 예시를 갱신하며, 운영자는 이미 생성된 초안이 어느 버전을 참조했는지 찾습니다. 개정 전후를 설명할 수 있어야 잘못된 결과의 범위도 좁힐 수 있습니다.
스킬 배포는 일반 코드보다 결과 비교가 더 중요합니다
문장 몇 줄을 고친 스킬도 에이전트의 검색 순서와 판단 준비 방식을 크게 바꿀 수 있습니다. 배포 전에는 대표적인 정상 입력만 보지 않고, 정보가 부족한 요청, 서로 충돌하는 문서, 권한 없는 출처, 이전 기준으로 작성된 업무 건을 함께 넣어 봅니다. 기대 결과는 정답 문구 하나가 아니라 참조해야 할 출처, 멈춰야 할 조건, 사람에게 넘길 이유로 정의합니다.
새 스킬은 먼저 제한된 업무와 사용자에게 적용하고 이전 버전과 결과를 비교합니다. 현업 담당자는 초안의 실용성과 누락을, 지식 소유자는 기준의 정확성을, 보안 담당자는 불필요한 데이터 접근을 확인합니다. 편리하다는 평가만으로 전면 배포하지 않고, 사람이 수정한 내용과 사용하지 않은 제안의 이유를 모아 적용 범위를 결정합니다. 평가 자료에 고객 식별 정보나 민감한 원문을 그대로 남기지 않는 보존 기준도 필요합니다.
잘못된 지식을 사용한 결과까지 복구해야 합니다
스킬 오류를 발견해 이전 버전으로 되돌려도 이미 만들어진 체크리스트와 업무 결정은 남아 있습니다. 운영자는 오류가 존재한 기간, 해당 버전을 호출한 작업, 사람이 확정한 결과를 구분해 영향 목록을 만듭니다. 모든 결과를 무효화하기보다 기준 변경과 관련된 항목을 우선 재검토하고, 수정이 필요한 건에는 원래 결과와 정정 사유를 함께 남깁니다. 기록을 삭제하면 당시 판단의 경로를 설명할 수 없습니다.
재개 승인은 지식 소유자가 수정 내용을 확인하고, 스킬 운영자가 대표 입력의 결과를 검증한 뒤에 이뤄져야 합니다. 메모리에 같은 오류가 복제됐는지, 다른 프로필이 해당 스킬을 참조하는지도 확인합니다. Hermes Agent의 메모리와 스킬은 업무 지식을 다루는 참고 기능이며, 현재 동작과 저장 범위는 공식 문서와 실제 환경에서 확인해야 합니다. 기능이 있다는 사실만으로 지식의 최신성, 승인 적합성, 보존 정책 충족이 보장되지는 않습니다.
빠른 답변과 정확한 기준은 누가 각각 책임지는가
현업은 자주 묻는 답을 빠르게 받고 싶고, 기준 책임자는 오래된 정보가 공식 판단으로 쓰이는 것을 막아야 합니다. 따라서 메모리의 편의성을 이유로 승인 문서의 갱신 절차를 생략해서는 안 됩니다. 지식 소유자는 원본과 적용 범위를 관리하고, 스킬 작성자는 입력과 출력의 한계를 명시하며, 운영자는 실제 사용 결과에서 오래된 참조를 발견합니다. 출처가 확인되지 않는 답은 확정 안내 대신 원문 확인이 필요한 초안으로 표시해야 합니다.