포스트

Hermes Agent는 무엇을 기억하고 실행하나: 영구 메모리, 스킬, 권한 검증법

Hermes Agent는 세션이 끝난 뒤에도 과거 정보를 검색하고, 반복 작업 절차를 스킬로 남겨 다시 활용하려는 에이전트 프레임워크입니다. 장기 연속성은 매번 배경을 설명하는 비용을 줄일 수 있지만 잘못된 기억과 스킬도 반복될 수 있습니다. 도입 판단은 “기억한다”는 표현보다 무엇을 저장, 검색, 실행하며 사용자가 어떻게 수정하고 중단할 수 있는지에 달려 있습니다.

Hermes Agent는 일반 챗봇과 무엇이 다른가

일반적인 단발 대화는 현재 세션의 메시지 안에서만 문맥을 유지합니다. Hermes Agent가 겨냥하는 차이는 세션 밖의 기억과 실행 절차를 별도 상태로 관리하고, CLI나 메시지 Gateway를 통해 장기 실행 흐름에 연결하는 것입니다. 사용자는 매번 같은 선호와 프로젝트 배경을 다시 설명하지 않고 과거 기록을 검색해 이어 갈 수 있습니다.

이 구조가 모델 자체의 가중치를 계속 학습한다는 뜻은 아닙니다. 저장된 대화, 요약, 사용자 모델과 스킬 문서를 다음 요청의 문맥이나 도구로 재사용하는 애플리케이션 수준의 연속성으로 구분해야 합니다. 기억이 많아졌다는 사실과 답이 더 정확해졌다는 사실도 같지 않습니다. 검색이 틀리면 오래된 정보가 현재 요청을 방해할 수 있습니다.

Hermes Agent 저장소는 실제 구성과 공개 범위를 확인하는 출발점입니다. 기능 이름과 외부 소개 문구만으로 현재 릴리스의 설치, 운영 보장을 추정하지 말고 코드, 설정, 지원되는 연결과 라이선스를 함께 확인해야 합니다.

영구 메모리는 어떤 단계로 동작하나

기존 글에서 소개된 메모리 구조는 SQLite FTS5 기반의 텍스트 검색과 LLM 요약, 사용자에 대한 상위 수준 정보 구성을 결합합니다. 원시 대화를 무조건 전부 다음 세션에 넣는 대신 요청과 관련된 과거 기록을 찾고 작은 문맥으로 압축하려는 접근입니다. 이는 컨텍스트 사용량을 줄일 수 있지만 검색과 요약이라는 두 개의 손실 지점을 만듭니다.

FTS5 검색은 이름, 오류 코드, 프로젝트 용어처럼 명시적인 단어를 찾는 데 유용할 수 있습니다. 표현이 달라진 요청이나 의미적 관련성은 놓칠 수 있고, 같은 단어가 다른 프로젝트에서 쓰이면 잘못된 기억을 가져올 수 있습니다. 요약 모델은 긴 기록을 줄이지만 누가 언제 말했는지, 예외와 철회된 결정을 생략할 수 있습니다.

메모리 항목에는 원문 출처, 세션, 프로젝트, 작성 시각, 신뢰도와 만료 여부가 필요합니다. 검색된 요약에서 원래 메시지로 돌아갈 수 있어야 합니다. 사용자가 “이 규칙은 더 이상 쓰지 않는다”고 정정했을 때 기존 항목을 삭제하거나 새 버전으로 대체하는 동작도 확인해야 합니다.

오염된 기억은 어떻게 발견하고 고칠까

잘못된 기억은 한 번의 오답보다 위험할 수 있습니다. 이후 비슷한 요청마다 검색되어 같은 오류를 강화하기 때문입니다. 예를 들어 임시 우회책을 팀 표준으로 요약하거나 다른 저장소의 설정을 현재 프로젝트 규칙으로 가져오면 그럴듯한 반복 실패가 생깁니다.

테스트 세트에는 오래된 결정, 서로 모순되는 선호, 이름이 같은 두 프로젝트, 사용자가 명시적으로 철회한 정보가 포함되어야 합니다. 각 요청에서 어떤 기억이 검색됐고 최종 답에 어떻게 사용됐는지 로그로 남깁니다. 답이 틀렸을 때 모델 추론과 검색된 기억 중 어느 쪽이 원인인지 구분할 수 있어야 합니다.

수정 UI나 명령은 저장만큼 중요합니다. 사용자는 특정 항목을 보고 편집, 삭제하고, 프로젝트 전체의 기억을 초기화하며, 백업에서 복구할 수 있어야 합니다. 자동 요약이 바뀌면 원문은 보존하되 이전 요약과 새 요약의 차이를 감사할 수 있는 편이 좋습니다. 개인정보와 비밀 정보는 애초에 저장하지 않거나 짧은 보존 기간을 적용합니다.

스킬 생성은 어떤 절차를 재사용하나

Hermes Agent가 소개하는 스킬 생성은 성공한 작업 절차를 문서나 코드 형태로 남겨 비슷한 요청에서 다시 활용하려는 기능입니다. 매번 처음부터 도구 순서를 추론하지 않아도 된다는 장점이 있습니다. 반복 가능한 데이터 변환, 정해진 검사, 보고서 형식처럼 입력과 성공 조건이 분명한 작업에 맞을 수 있습니다.

그러나 한 번 성공했다는 사실은 일반적인 절차가 맞다는 증거가 아닙니다. 우연히 현재 환경에서만 작동한 명령, 하드코딩된 경로, 넓은 권한과 비밀 값이 스킬에 들어갈 수 있습니다. 스킬 문서의 설명이 정확해도 포함된 스크립트가 안전하다는 보장도 없습니다.

스킬에는 지원 입력, 필요한 도구, 수정 가능한 범위, 실패 시 중단 조건과 검증 명령을 명시해야 합니다. 생성 직후에는 자동 활성화하지 않고 코드 검토와 격리된 테스트를 거쳐 승인된 버전으로 승격합니다. 사용 중 오류가 발견되면 해당 스킬을 비활성화하고 어떤 실행에서 사용됐는지 추적할 수 있어야 합니다.

기억과 스킬은 어떻게 구분해야 하나

기억은 “이 프로젝트는 Python 3.11을 사용한다”처럼 상황에 대한 정보를 담고, 스킬은 “테스트 실패를 수집해 보고서를 만든다”처럼 반복 가능한 절차를 담는 것이 자연스럽습니다. 둘이 섞이면 오래된 사실이 코드에 하드코딩되거나 실행 절차가 단순 요약으로만 남아 검증되지 않을 수 있습니다.

기억에서 가져온 값은 스킬 실행 전에 현재 환경과 대조해야 합니다. 프로젝트 경로, 도구 버전과 배포 대상은 세션 사이에 바뀔 수 있습니다. 스킬이 기억을 수정할 수 있다면 어떤 결과를 새 사실로 저장할지 별도 승인 규칙을 둬야 합니다. 실행 실패를 잘못된 성공 경험으로 기록하면 다음 실행이 더 나빠질 수 있습니다.

두 저장소의 버전도 따로 관리합니다. 기억 항목을 지운다고 스킬 코드에서 복제된 값이 사라지지 않을 수 있고, 스킬을 업데이트해도 과거 요약은 그대로 남을 수 있습니다. 검색, 실행, 저장의 경계를 로그에 표시해야 연속성 문제를 진단할 수 있습니다.

Gateway와 서브에이전트는 무엇을 늘리나

Gateway는 CLI나 Telegram, Discord, Slack 같은 인터페이스에서 요청을 받아 코어 에이전트로 전달하는 연결점으로 소개됩니다. 원격에서 작업을 요청할 수 있다는 편리함과 함께 인증, 메시지 위조, 채널별 개인정보와 명령 승인 문제가 생깁니다. 메시지를 보낼 수 있는 사람과 실제 도구를 실행할 수 있는 사람의 권한을 분리해야 합니다.

서브에이전트 위임은 여러 독립 작업을 나눌 수 있지만 호출 수와 실행 환경도 늘립니다. 두 에이전트가 같은 파일을 수정하거나 서로 다른 결론을 내면 충돌을 합치는 규칙이 필요합니다. 각 하위 작업의 입력, 허용 도구, 예산과 결과를 부모 실행 ID에 연결해야 합니다.

병렬화가 유용한 일은 서로 독립적으로 읽고 비교할 수 있는 조사나 테스트입니다. 같은 외부 시스템에 쓰거나 순서가 중요한 변경을 무조건 병렬로 실행해서는 안 됩니다. 최종 합성자는 결과의 근거를 보존하고 실패한 하위 작업을 성공처럼 숨기지 않아야 합니다.

MCP 연결은 보안 경계를 자동으로 만들까

MCP는 외부 자료와 도구를 연결할 수 있지만 연결 자체가 최소 권한을 보장하지는 않습니다. 서버가 제공하는 도구와 데이터, 사용되는 자격 증명, 읽기, 쓰기 범위는 별도로 설정해야 합니다. 사내 데이터베이스 전체를 노출하고 프롬프트에서 “읽기만 하라”고 적는 것은 런타임 통제가 아닙니다.

개발 환경에서는 테스트 데이터와 읽기 전용 계정부터 사용합니다. 허용된 조회와 금지된 조회, 잘못된 인수와 쓰기 시도를 실행해 실제 차단을 확인합니다. 외부 문서와 메시지에는 에이전트 규칙을 바꾸려는 문장이 섞일 수 있으므로 도구 결과를 신뢰할 수 없는 입력으로 취급합니다.

MCP 서버 로그와 에이전트의 도구 호출, 최종 응답을 한 실행으로 연결하면 사고 조사에 도움이 됩니다. 사용하지 않는 연결은 끄고, 운영 데이터 변경은 사람 승인과 별도의 결정론적 검증을 거칩니다. 확장 가능한 도구 수보다 필요한 권한만 좁게 제공하는지가 안전성의 기준입니다.

백그라운드 실행과 Cron은 어떤 위험이 있나

예약 작업은 사용자가 화면을 보고 있지 않을 때도 반복됩니다. 잘못된 스킬이나 오래된 기억이 있으면 같은 오류를 매일 실행할 수 있습니다. 작업마다 최대 실행 시간, 호출 수, 비용, 연속 실패와 중단 조건을 두어야 합니다. 성공, 실패 결과를 알림으로 보내되 비밀과 민감한 원문을 메시지 채널에 그대로 넣지 않습니다.

Cron 작업은 사용하는 모델, 스킬 버전, 자격 증명과 대상 프로젝트를 고정해서 기록합니다. 다음 실행 전에 환경이 바뀌었는지 확인하고 같은 결과를 중복 게시하거나 중복 변경하지 않도록 멱등성을 고려합니다. 예약을 만든 주체와 삭제, 일시중지 방법도 사용자가 알 수 있어야 합니다.

운영 장애 대응처럼 영향이 큰 작업에서는 모니터링과 조치를 분리합니다. 로그 수집과 상태 요약은 읽기 전용으로 자동화할 수 있지만 재시작, 설정 변경과 배포는 사람이 근거를 확인한 뒤 승인하도록 합니다. 과거 조치를 기억한다는 이유만으로 현재 장애에 같은 명령을 반복해서는 안 됩니다.

실제 비용은 어디에서 발생하나

사용자 응답을 만드는 호출 외에도 기억 요약, 검색 결과 정리, 스킬 생성, 검토, 서브에이전트와 예약 작업에서 모델 호출이 발생할 수 있습니다. 메시지 Gateway, 외부 메모리, 음성, 비전 도구와 실행 환경의 저장, 컴퓨팅 비용도 추가됩니다. 서버 가격 하나로 전체 운영비를 표현하기 어렵습니다.

작업별로 사용자 요청, 백그라운드 처리, 도구 호출과 재시도의 비용을 나눠 기록합니다. 메모리 항목 수와 스킬 수가 늘 때 검색 지연과 컨텍스트 양이 어떻게 변하는지도 봅니다. 자동 요약 빈도를 낮추거나 검증된 반복 작업만 스킬로 만드는 식으로 비용을 통제할 수 있습니다.

비용 상한에 도달하면 조용히 품질을 낮추거나 실행을 계속하기보다 작업을 멈추고 사용자에게 상태를 알려야 합니다. 저렴한 모델로 바꾸는 선택도 기억, 스킬 품질의 회귀 테스트를 거쳐야 합니다. 장기 실행 도구의 경제성은 한 번의 데모가 아니라 월간 호출 분포와 사람이 수정한 시간을 포함해 판단합니다.

안전한 PoC는 어떤 순서로 진행할까

첫 단계에서는 비민감 테스트 프로젝트와 읽기 전용 도구만 연결합니다. 사용자가 명시적으로 저장한 소수의 기억을 검색하게 하고, 관련 기억, 오래된 기억, 다른 프로젝트 기억을 구분하는지 평가합니다. 기억을 수정, 삭제한 뒤 검색 결과에서 실제로 사라지는지도 확인합니다.

두 번째 단계에서는 부작용이 없는 변환이나 검사 절차 하나를 스킬로 만듭니다. 사람이 코드와 권한을 검토하고 격리된 환경에서 성공, 실패 입력을 실행합니다. 스킬을 업데이트하거나 비활성화할 때 예약 작업과 과거 실행이 어떤 버전을 사용했는지 추적합니다.

마지막으로 제한된 Gateway와 서브에이전트를 연결해 인증, 동시 작업 충돌, 비용 상한과 중단 알림을 시험합니다. 운영 시스템 쓰기 권한은 별도의 위험 평가와 사람 승인 뒤에도 필요한 최소 범위로 제한합니다. Hermes Agent의 가치는 기억과 실행을 오래 이어 가는 데 있지만, 그 연속성이 신뢰를 얻으려면 사용자가 저장, 권한, 비용을 계속 통제할 수 있어야 합니다.

원문과 버전 확인

함께 읽으면 이해가 이어지는 글

자주 묻는 질문

Hermes Agent는 대화를 모두 정확하게 기억하나요?

그렇지 않습니다. 검색과 요약 과정에서 중요한 맥락이 빠지거나 잘못된 정보가 오래 남을 수 있으므로 기억의 출처, 작성 시점, 수정과 삭제 경로를 검증해야 합니다.

에이전트가 만든 스킬을 바로 자동 실행해도 되나요?

권장하지 않습니다. 잘못된 해결 절차와 과도한 권한이 재사용될 수 있어 코드 검토, 격리된 테스트, 허용 도구와 버전 승격 절차가 필요합니다.

Hermes Agent를 운영 서버 장애 대응에 바로 연결해도 되나요?

안 됩니다. 먼저 읽기 전용 테스트 환경에서 기억 검색과 도구 호출을 평가하고, 운영 변경은 최소 권한, 명령 승인, 감사 로그와 별도 복구 절차를 둬야 합니다.

THE END / OPSOAI

여기까지 읽었습니다

핵심 장면을 한 번 더 떠올려 보세요. 이해가 남았다면 이 책은 제 역할을 다했습니다.

다른 책 고르기
표지 1

키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.

CONTENTS

이 책의 목차

    14개 장 25 분읽는 시간