에이전트의 메모리를 신뢰하기 전에, 그 권한을 먼저 감사해야 한다

이 글은 Hermes Agent Challenge의 Write About Hermes Agent 프롬프트에 따른 제출물입니다.

먼저 명확히 밝혀두겠습니다. 이것은 빌드(build) 제출물이 아닙니다.

저는 이 챌린지를 위해 Hermes Agent 프로젝트를 구축하지 않았습니다. 저는 지난 일주일 동안 공개된 메모리 평가 하네스(memory-evaluation harness)에서 AI 메모리 실패 모드(failure modes)를 테스트해 온 사람의 관점에서 글을 쓰고 있습니다.

그 작업은 제가 에이전트 메모리 시스템을 읽는 방식을 바꾸어 놓았습니다.

그래서 제가 Hermes Agent를 바라볼 때, 제가 관심을 두는 질문은 단지 다음과 같은 것이 아닙니다.

에이전트가 유용한 것을 기억할 수 있는가?

더 어려운 질문은 이것입니다.

메모리가 충돌할 때, 어떤 메모리가 에이전트의 행동을 지배하도록 허용되는가?

그 차이가 중요합니다.

Hermes Agent가 흥미로운 이유는 단순히 채팅 인터페이스가 아니기 때문입니다. 해당 문서에는 도구 사용(tool use), 프로젝트 컨텍스트(project context), 지속성 메모리(persistent memory), 기술(skills), 브라우저 자동화(browser automation), 체크포인트(checkpoints), 위임(delegation), 예약된 작업(scheduled tasks), 그리고 다중 메모리 제공자(multiple memory providers)를 갖춘 오픈 소스 에이전트 시스템(agentic system)이라고 설명되어 있습니다.

이것은 바로 메모리가 단순한 편의 기능(convenience feature)을 넘어 에이전트의 운영 경계(operating boundary)의 일부가 되기 시작하는 바로 그런 종류의 시스템입니다.

만약 에이전트가 도구를 실행하고, 파일을 편집하며, 브라우징을 하고, 작업을 위임하며, 작업을 예약하고, 세션 전반에 걸쳐 기억할 수 있다면, 메모리는 더 이상 단순한 "컨텍스트(context)"가 아닙니다.

메모리는 거버넌스(governance, 통치/관리)가 됩니다.

내가 주의 깊게 살펴볼 메모리 문제

단순한 챗봇에서 잘못된 메모리는 짜증을 유발할 뿐입니다.

에이전트에서 잘못된 메모리는 운영상의 문제가 될 수 있습니다.

실패 모드는 단순히 에이전트가 무언가를 잊어버리는 것만이 아닙니다. 때로는 더 위험한 실패 모드는 에이전트가 잘못된 것을 너무 확신을 가지고 기억하는 것입니다.

메모리는 다음과 같을 수 있습니다:

관련은 있지만 오래된(stale),
관련은 있지만 권한이 낮은(low-authority),
관련은 있지만 대체된(superseded),
관련은 있지만 단지 컨텍스트일 뿐인(only context),
관련은 있지만 행동을 결정하도록 허용되지 않은(not allowed to determine the action).

이것이 제 자체 테스트에서 계속 마주쳤던 차이점입니다.

검색 시스템(Retrieval systems)은 보통 다음 질문에 답하는 데 능숙합니다:

사용자의 요청과 가장 가까운 메모리는 무엇인가?

하지만 안전(Safety)은 종종 다른 질문에 달려 있습니다:

에이전트가 무엇을 해야 할지 결정할 권한이 있는 메모리는 무엇인가?

이 두 질문은 동일한 목적을 가지고 있지 않습니다.

Hermes가 이 논의를 가치 있게 만드는 이유

Hermes Agent는 이 질문을 추상적인 수준이 아닌 실무적인 수준으로 만드는 여러 가지 메모리 및 컨텍text 표면(surfaces)을 가지고 있습니다.

문서에서는 MEMORY.md와 USER.md를 통한 지속적 메모리(persistent memory), AGENTS.md, .hermes.md, CLAUDE.md, SOUL.md, .cursorrules와 같은 파일을 통한 프로젝트 컨텍스트(project context), 그리고 기술(skills)을 통한 재사용 가능한 절차(reusable procedures)를 설명합니다.

프롬프트 조립(prompt assembly) 문서에서는 SOUL.md를 시스템 프롬프트(system prompt)에 로드되는 정체성 계층(identity layer)으로 설명하는 한편, MEMORY.md와 USER.md는 새로운 세션으로 스냅샷(snapshot)되어 제공되는 세션 간 지속적인 사실(durable cross-session facts)을 제공한다고 설명합니다.

팁(tips) 문서에는 매우 중요한 세부 사항이 하나 추가되어 있습니다: 메모리는 세션 동안 동결된 스냅샷(frozen snapshot)이라는 점입니다. 디스크에는 즉시 쓰기(writes)가 발생할 수 있지만, 이러한 변경 사항은 다음 세션이 시작될 때까지 시스템 프롬프트에 나타나지 않습니다.

이는 합리적인 엔지니어링 트레이드오프(engineering tradeoff)입니다. 이는 프롬프트 캐시(prompt-cache)의 안정성을 보호하고 메모리를 제한된 범위 내로 유지합니다.

하지만 이는 또한 실질적인 감사(audit) 질문을 생성합니다:

만약 메모리가 세션 시작 시점에 동결된다면, 운영자는 장기적으로 진행되는 작업 중에 업데이트, 수정 및 대체된 사실(superseded facts)에 대해 어떻게 추론해야 하는가?

일반적인 선호도(preferences)의 경우에는 이것이 그리 중요하지 않을 수 있습니다.

하지만 운영 규칙(operational rules), 자격 증명(credentials), 승인(approvals), 안전 제약 조건(safety constraints) 또는 배포 절차(deployment procedures)의 경우에는 매우 중요합니다.

메모리에는 텍스트뿐만 아니라 역할(Roles)이 필요하다

저의 개인적인 AI 메모리 테스트를 통해 얻은 실질적인 교훈은 간단했습니다:

관련성(Relevance)이 곧 권한(Authority)은 아니다.

메모리가 완벽한 의미론적 일치(semantic match)를 보이더라도, 여전히 준수하기에는 잘못된 메모리일 수 있습니다.

예를 들어:

오래된 Wi-Fi 비밀번호는 "Wi-Fi 비밀번호가 무엇인가?"라는 질문에 매우 관련성이 높습니다.
계약자에게 광범위한 접근 권한을 부여하는 것에 대한 느슨하고 오래된 논의는 "이 직책의 권한 범위는 어디까지인가?"라는 질문에 관련이 있습니다.
컨설턴트가 기부자 데이터가 필요할 수도 있다는 과거의 메모리는 "기부자 목록을 보내도 되는가?"라는 질문에 관련이 있습니다.

하지만 이 중 그 어느 것도 반드시 행동을 지배해서는 안 됩니다.

행동을 지배해야 하는 메모리는 대화상으로는 덜 명확할 수 있습니다:

"현재 Wi-Fi 자격 증명 (credential)은 IT 부서에서 관리한다."
"결제 가능한 액세스 (access)는 현재의 액세스 매트릭스 (access matrix)를 기준으로 확인되어야 한다."
"기부자 데이터 공개는 검증 가능한 명시적 권한 부여 (named authorization)가 필요하다."

이 지점이 바로 에이전트 메모리에 역할 (roles)이 필요한 이유입니다.

기억된 모든 것이 동일한 종류의 객체는 아닙니다.

어떤 메모리는 사실 (facts)입니다.
어떤 것은 선호도 (preferences)입니다.
어떤 것은 절차 (procedures)입니다.
어떤 것은 정책 (policies)입니다.
어떤 것은 자격 증명 (credentials)입니다.
어떤 것은 수정 사항 (corrections)입니다.
어떤 것은 문맥 (context)입니다.

만약 이 모든 것들이 단순히 "에이전트가 기억하는 텍스트"로 뭉뚱그려진다면, 가장 권위 있는 메모리가 행동을 지배해야 할 상황에서 가장 관련성 높은 메모리가 승리하게 될 수 있습니다.

Hermes 사용자를 위한 간단한 권한 체크리스트

만약 제가 진지한 업무를 위해 Hermes 에이전트를 설정한다면, 메모리에 무엇을 넣을지만 묻지 않을 것입니다.

각 메모리가 무엇을 할 수 있도록 허용되는지를 물을 것입니다.

제가 사용할 체크리스트는 다음과 같습니다.

1. 지속적인 사실과 운영 규칙을 분리하십시오

사실은 메모리에 속합니다.

운영 규칙 (operating rules)은 더 강력한 처리가 필요합니다.

만약 어떤 규칙이 에이전트가 파일을 편집할 수 있는지, 배포 (deploy)할 수 있는지, 자격 증명에 접근할 수 있는지, 데이터를 전송할 수 있는지, 또는 외부 행동을 취할 수 있는지를 결정한다면, 저는 그것을 일반 메모리에 섞인 평범한 산문 형태로 남겨두지 않을 것입니다.

저는 그것을 명시적이고 간결하며 감사 (audit)하기 쉬운 곳, 즉 프로젝트의 AGENTS.md, .hermes.md, 또는 컨텍스트 파일 내의 전용 섹션에 둘 것입니다.

2. 오래되거나 대체된 메모리를 공격적으로 표시하십시오

가장 위험한 오래된 메모리는 명백히 틀린 메모리가 아닙니다.

여전히 유용하게 들리는 메모리입니다.

자격 증명 (credentials), 엔드포인트 (endpoints), 배포 단계 (deployment steps), 액세스 규칙 (access rules), 승인 노트 (approval notes) 등에는 명확한 상태 언어를 포함해야 합니다:

Superseded (대체됨).
Do not use (사용 금지).
Current source is X (현재 소스는 X임).
...

이는 에이전트에게 관련성 (relevance)만 있을 때보다 더 강력한 신호를 제공합니다.

3. 메모리를 제한적이고 단조롭게 유지하십시오

Hermes는 제한된 메모리 (bounded memory)를 문서화하며, 저는 이것이 강점이라고 생각합니다.

메모리 파일이 길어지면 의도치 않은 정책 드리프트 (policy drift)를 초래합니다. 메모리가 짧을수록 운영자는 무엇이 실제로 영구 저장될 가치가 있는지 결정해야만 합니다.

지루한 메모리 파일이 종종 더 안전한 메모리 파일입니다.

4. 기술(skills)을 신념(beliefs)이 아닌 절차(procedures)로 취급하라

Hermes의 문서에서는 메모리(memory)와 기술(skills)을 구분합니다. 메모리는 사실(facts)을 위한 것이고, 기술은 절차(procedures)를 위한 것입니다.

이러한 구분은 중요합니다.

만약 어떤 작업이 반복 가능한 워크플로 (workflow)를 가지고 있다면, 그것은 모호하게 기억된 선호도가 아니라 기술 (skill) 또는 프로젝트 지침 (project instruction)이어야 합니다.

절차 (procedures)에는 단계 (steps), 전제 조건 (preconditions), 그리고 종료 조건 (stop conditions)이 필요합니다.

메모리 (memory)만으로는 충분하지 않습니다.

5. 도구 사용을 제어하는 요소를 감사하라

에이전트 (agent)가 도구 (tools)를 사용할 수 있게 되면, 핵심 질문은 다음과 같습니다.

어떤 메모리나 지침이 이 동작을 제어하는가?

에이전트에게 워크플로 (workflow)를 맡기기 전에, 저는 다음과 같은 사례들을 테스트해 볼 것입니다.

오래된 자격 증명 (stale credential) 대 현재 자격 증명 소스 (current credential source),
이전 배포 명령 (old deploy command) 대 현재 배포 절차 (current deploy procedure),
읽기 전용 조회 (read-only lookup) 대 쓰기/실행 동작 (write/execute action),
신뢰도가 낮은 사용자 노트 (low-trust user note) 대 프로젝트 규칙 (project rule),
이전 승인 (previous approval) 대 현재 승인 요구 사항 (current approval requirement).

핵심은 에이전트 (agent)가 완벽하다는 것을 증명하는 것이 아닙니다.

핵심은 관련 메모리 (memories)가 권위 있는 메모리 (authoritative ones)를 무시(override)하는 지점을 찾아내는 것입니다.

동결된 스냅샷 (Frozen Snapshot)의 디테일이 중요하다

제가 주의 깊게 살펴볼 Hermes의 디테일 중 하나는 동결된 메모리 스냅샷 (frozen memory snapshot)입니다.

문서에 따르면 메모리 쓰기 (memory writes)는 즉시 발생하지만, 프롬프트 스냅샷 (prompt snapshot)은 세션 중간에 업데이트되지 않습니다.

이는 에이전트 (agent)가 세션 중에 메모리에 수정 사항을 작성하더라도, 새로운 세션이 시작될 때까지는 여전히 오래된 프롬프트 컨텍스트 (prompt context)를 바탕으로 동작할 수 있음을 의미합니다.

이것이 반드시 버그 (bug)인 것은 아닙니다.

하지만 운영자 (operators)는 이를 이해해야 합니다.

위험도가 낮은 선호도의 경우, 이는 괜찮습니다:

내가 간결한 답변을 선호한다는 것을 기억해줘.

하지만 동작을 제어하는 수정 사항의 경우, 저는 더 주의를 기울일 것입니다:

배포 대상이 변경되었습니다.
이전 자격 증명은 폐기되었습니다.
승인 규칙이 변경되었습니다.
...

이러한 경우에는 세션 재시작 (session restart), 명시적인 컨텍스트 주입 (explicit context injection), 또는 에이전트가 동작하기 전에 반드시 현재 파일을 확인해야 한다는 워크플로 규칙 (workflow rule) 중 하나가 필요할 것입니다.

일반적인 원칙은 다음과 같습니다:

만약 메모리 업데이트가 에이전트에게 허용된 권한을 변경한다면, 이를 일반적인 선호도 업데이트 (preference update)처럼 취급해서는 안 됩니다.

다음에 테스트할 사항

만약 제가 Hermes 메모리를 프로덕션 스타일의 용도로 평가한다면, 권한 충돌 (authority conflicts)을 중심으로 한 작은 테스트 하네스 (harness)를 구축할 것입니다.

일반적인 결과를 주장하는 벤치마크 (benchmark)가 아닙니다.

단순한 진단 도구입니다.

시작하기에는 다섯 가지 시나리오면 충분할 것입니다:

오래된 자격 증명 (stale credential)과 활성화된 자격 증명 정책 (active credential policy).
프로젝트 규칙과 충돌하는 사용자 선호도 (user preference).
더 이상 유효하지 않은 이전 승인 (previous approval).
쓰기/실행 정책 (write/execute policy)과 어휘를 공유하는 읽기 전용 질문 (read-only question).
더 좁은 범위의 현재 지침과 충돌하는 광범위하게 기억된 절차 (broad remembered procedure).

각 시나리오에 대해 저는 두 가지 별도의 지표를 추적할 것입니다:

에이전트가 관련 메모리를 검색하거나 인용했는가?
올바른 메모리가 행동을 제어했는가?

이 둘은 서로 다른 점수입니다.

그 분리가 바로 핵심입니다.

이것이 오픈 에이전트 (Open Agents)에 중요한 이유

오픈 에이전트 시스템의 흥미로운 점은 사람들이 이를 검사하고 형성할 수 있다는 것입니다.

위험한 점 또한 마찬가지입니다.

사용자가 에이전트에게 지속적인 메모리 (persistent memory), 프로젝트 컨텍스트 (project context), 도구 (tools), 예약된 작업 (scheduled tasks), 그리고 기술 (skills)을 부여할 수 있다면, 사용자의 메모리 위생 (memory hygiene) 자체가 안전 모델 (safety model)의 일부가 됩니다.

이것이 사용자가 메모리를 두려워해야 한다는 뜻은 아닙니다.

메모리에 구조 (structure)가 필요하다는 뜻입니다.

Hermes는 이미 그러한 구조를 위한 몇 가지 유용한 인터페이스를 노출하고 있습니다: 지속 가능한 메모리 파일 (durable memory files), 프로젝트 컨텍스트 파일 (project context files), 기술 (skills), 프롬프트 조립 (prompt assembly), 체크포인트 (checkpoints), 그리고 외부 메모리 제공자 (external memory providers).

다음 단계는 규율 (discipline)입니다:

무엇이 메모리에 속해야 하는가,
무엇이 기술 (skills)에 속해야 하는가,
무엇이 프로젝트 규칙 (project rules)에 속해야 하는가,
무엇을 새로 검증해야 하는가,
무엇이 단독으로 행동을 제어해서는 안 되는가.

나의 결론

저는 에이전트 메모리 시스템을 단순히 기억을 하는지 여부만으로 평가하지 않을 것입니다.

대신, 자신의 메모리가 무엇을 할 수 있도록 허용되는지를 알고 있는지 물을 것입니다.

그것이 편의를 위한 메모리와 거버넌스 (governance)를 위한 메모리의 차이입니다.

Hermes Agent 사용자들을 위한 저의 실질적인 조언은 다음과 같습니다:

단순히 메모리를 작성하지 마십시오. 분류하십시오.

무엇이 사실(fact)인지, 무엇이 선호도(preference)인지, 무엇이 절차(procedure)인지, 무엇이 정책(policy)인지, 무엇이 오래된 정보(stale)인지, 그리고 행동하기 전에 반드시 검증되어야 하는 것이 무엇인지를 표시하십시오.

왜냐하면 에이전트 시스템 (agentic system)에서는 가장 관련성 높은 메모리가 항상 승리해야 하는 메모리는 아니기 때문입니다.

주제에 부합하는 것 (being on-topic)이 권위 있는 것 (being authoritative)과 동일한 것은 아닙니다.

그리고 일단 에이전트가 행동할 수 있게 되면, 그 차이가 게임의 전부가 됩니다.

Sources

Hermes Agent Challenge: https://dev.to/challenges/hermes-agent-2026-05-15/
Hermes Agent features overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview/
Hermes Agent prompt assembly docs: https://hermes-agent.nousresearch.com/docs/developer-guide/prompt-assembly
Hermes Agent tips and best practices: https://hermes-agent.nousresearch.com/docs/guides/tips/
Related public memory harness: https://github.com/keniel13-ui/ai-memory-judgment-demo