NVIDIA가 2026년 9월 4일 공개한 이 글은 NemoClaw 위에 올린 업무 비서 에이전트가 사람과 프로젝트에 대한 기억을 자기 모델(self model) 이라는 마크다운 지식 계층으로 유지하고, 그 기억으로 답변 정확도를 82.8%에서 90.9%로 끌어올린 과정을 정리한 설계 기록입니다. 핵심 주장은 저장 공간을 늘리는 것이 아니라 구조, 선별적 검색, 거버넌스(governance) 를 갖춰야 에이전트 메모리가 쓸모 있어진다는 것입니다.
문제 설정 자체는 익숙합니다. 에이전트에게 업무를 맡기려면 그 사람이 누구와 일하고, 무엇을 책임지고 있고, 어떤 결정을 이미 내렸고, 무엇을 습관적으로 무시하는지를 알아야 합니다. 대화 기록(conversation history)은 세션 안에서만 이어지고, 그 안에서 현재의 우선순위와 지나간 결정과 일회성 요청이 뒤섞입니다. 검색 증강 생성(Retrieval-Augmented Generation, RAG)은 관련 원문을 찾아 주지만, 시간에 걸쳐 흩어진 정보를 이어 붙이는 일은 여전히 모델의 몫으로 남습니다.
이 글에서 다루는 스택의 층위를 먼저 정리해 두면 뒤가 읽기 쉽습니다. NemoClaw는 Hermes, LangChain Deep Agents, OpenClaw 같은 에이전트를 OpenShell 샌드박스 안에서 관리형 추론(managed inference)과 함께 돌려 주는 TypeScript 런타임이고, OpenShell은 그 아래에서 파일 시스템, 프로세스, 네트워크 접근을 통제하는 Rust 런타임(runtime)입니다(NVIDIA Build 페이지에서도 소개하고 있습니다). 이번 레시피는 그 위에 얹히는 Hermes 프로필 배포본이며, PyTorchKR에서 앞서 정리한 NVIDIA NemoClaw 샌드박스 환경 가이드를 먼저 읽어 두면 설치 맥락이 훨씬 선명해집니다.
대화 기록으로는 왜 부족한가: 시간에 걸쳐 변하는 사실
원문은 프로젝트 상태를 묻는 평범한 질문 하나로 문제를 설명합니다. 정답은 앞선 회의에서 내린 결정, 그 뒤 메시지에서 나온 정정, 아직 답하지 않은 의무, 그리고 서로 다른 두 이름이 같은 프로젝트를 가리킨다는 사실에 동시에 걸려 있습니다. 네 조각 중 하나만 놓쳐도 답이 틀립니다.
이것이 단순 검색과 갈라지는 지점입니다. 검색은 "이 문서에 무엇이 적혀 있는가"를 잘 찾지만, "이 값이 그동안 두 번 바뀌었고 지금 유효한 것은 마지막 것"이라는 판단은 검색 결과 안에 들어 있지 않습니다. 자기 모델은 이 파생된 해석을 원문과 별도로 저장합니다. 원문 증거를 대체하지 않고 그 위에 얹히는 층이라는 뜻인데, 원문은 이 분리의 실용적 효용을 이렇게 설명합니다.
"둘을 분리해 두면 개발자는 잘못된 답이 증거에서 왔는지, 메모리 유지 과정에서 왔는지, 검색에서 왔는지, 아니면 모델의 최종 판단에서 왔는지를 가려낼 수 있습니다."
디버깅 관점에서 보면 이 분리가 실용적입니다. 메모리를 모델 가중치나 불투명한 임베딩에 넣어 두면 틀린 답의 책임 소재를 나눌 방법이 없습니다.
자기 모델: 스키마를 가진 마크다운 위키
먼저 짚어 둘 것은 이 위키가 Hermes의 내장 메모리를 대체하지 않는다는 점입니다. 내장 메모리인 USER.md와 MEMORY.md는 "에이전트가 나에 대해 무엇을 알아야 하는가" 에 답하는 짧은 개인화 노트이고, 이 레시피의 운영 메모리는 "내 업무 주변에서 무엇이 바뀌었고, 그 근거는 무엇이며, 지금 내 주의가 필요한 곳은 어디인가" 에 답합니다. 앞의 것은 작게 유지되고, 뒤의 것은 업무와 함께 자라되 연결과 출처와 스키마 검사를 유지합니다.
자기 모델은 workspace/memory/ 아래에 쌓이는 마크다운 파일 묶음이고, profile/schema.md라는 계약 문서에 그 형식이 고정되어 있습니다. NVIDIA 저자들은 이 문서의 도입부에서 레시피의 전제를 그대로 드러냅니다. "여기 적힌 규칙을 어기는 페이지는 용인할 변형이 아니라 복구 작업이 고쳐야 할 결함입니다."
페이지 종류는 여섯 가지입니다.
사람(people/): 이름, 역할, 관계, 중요도, 마지막 상호작용 날짜를 YAML 프론트매터로 갖고, 관계, 소통 방식, 핵심 맥락, 참여 프로젝트, 최근 상호작용 순서로 본문을 씁니다.
프로젝트(projects/<slug>/): 폴더 하나가 프로젝트 하나이고, 현재 그림을 담은 <slug>.md, 추가 전용 log.md, 회전된 log.archive.md로 이뤄집니다. 개요는 다섯 문장 이내이고 날짜가 붙은 사건은 절대 넣지 않습니다. 프로젝트가 살아 있다는 판정에 규칙이 따로 있어서, updated가 30일 이내이고 건강 상태가 종료 상태가 아닐 때만 활성으로 봅니다. 순위 작업이 정확히 이 검사를 쓰기 때문에, 방치된 프로젝트는 누가 정리해 주지 않아도 스스로 우선순위를 주지 못하게 됩니다.
패턴(patterns/): 무엇을 하는지가 아니라 어떻게 일하는지를 communication_style.md, work_habits.md, decision_making.md로 나눠 적습니다. 스키마가 이 페이지에만 따로 경고를 붙여 두었는데, "패턴은 아첨으로 흘러가기 가장 쉬운 페이지" 이므로 모든 주장에 관찰된 행동을 가리키는 출처 각주나 명시적인 (inferred) 표시가 있어야 하고, 둘 다 없는 패턴 페이지는 그 자체로 결함입니다.
개념(concepts/): 내부 시스템 이름이나 팀 은어처럼 신입은 알아듣지 못할 용어를 정리합니다. 등재 조건이 따로 있어서, 서로 다른 출처 두 곳 이상에 나타난 용어만 페이지를 얻습니다. 한 번 본 용어는 잡음으로 두고 건드리지 않습니다.
목표(goals/): monthly.md, quarterly.md, vision.md 세 페이지로 나뉘고, 측정 가능한 목표와 그 목표를 뒷받침하는 프로젝트 링크를 함께 적습니다. 단기 우선순위에서는 월간 목표가 분기 목표를 앞서고, vision.md는 그 자체로 순위를 움직이지 않습니다.
주의(attention/): 지금 무엇을 하고 있는지를 담는 짧은 수명의 계층으로, current_priorities.md, active_threads.md, event_triggers.md 세 페이지로 나뉩니다.
다만 여섯 종류가 전부 자동으로 채워지는 것은 아닙니다. 스키마는 여섯 가지를 모두 정의하고 검사기도 여섯 가지를 모두 검사하지만, 지금 배포된 작성기가 쓰는 것은 사람과 주의 두 가지뿐입니다. 나머지의 현황은 아래 "무엇을 아직 못하는가" 절에서 따로 다룹니다.
스키마가 흥미로운 것은 페이지 목록 자체가 아니라 그 목록에 붙은 규칙들입니다.
출처 표기(provenance) 는 선택이 아닙니다. 자명하지 않은 모든 주장에는 각주가 붙습니다.
Prefers async review over meetings.^[source: slack, 2026-08-11, trust: high]
trust: high는 당사자가 직접 말한 것, medium은 반복된 행동에서 추론한 것, low는 모호한 신호 하나뿐인 것을 뜻합니다. 날짜는 페이지를 쓴 날이 아니라 증거의 날짜입니다. 스키마는 여기에 한 문장을 덧붙여 두었는데, 이 문서에서 가장 강한 금지 조항입니다. "추론을 출처 있는 사실로 승격시켜서는 절대 안 됩니다." 하위 계층 전부가 이 페이지들을 사실로 읽기 때문입니다.
감쇠(decay) 창도 페이지마다 정해져 있습니다. current_priorities.md는 daily라서 매일 갱신되지 않으면 낡은 것으로 간주되고, active_threads.md는 weekly로 약 7일, 그 밖에 monthly는 30일, quarterly는 90일입니다. 복구 작업은 창을 넘긴 페이지를 지우지 않고 표시만 합니다. 스키마의 표현을 빌리면 "낡았다고 표시된 편이 조용히 틀린 것보다 낫습니다" 입니다.
성장 상한(ceiling) 도 숫자로 박혀 있습니다. 사람 페이지의 최근 상호작용은 30개 불릿까지이고, 그것을 넘으면 오래된 것들이 ## Relationship Arc 절로 요약되어 사라집니다. 프로젝트 페이지의 현재 상태는 워크스트림 8개, 블로커 5개, 미결 결정 5개, 사용자 액션 12개, 마일스톤 7개까지이고, 프로젝트 로그는 1000개 항목에서 회전합니다. 주의 계층 페이지는 "한 화면"이 상한입니다. 압축은 잘라내기가 아니라 요약이며, 미해결 약속과 살아남은 주장의 출처 각주는 어떤 경우에도 지우지 않습니다.
교차 참조(cross-reference) 도 검사 대상입니다. 프로젝트 페이지에서 언급된 사람은 반드시 그 사람의 페이지로 상대 경로 링크가 걸려야 하고, 페이지가 아직 없으면 importance: low 스텁을 만들어서라도 이름만 덩그러니 남기지 않습니다. index.md는 모든 읽기의 진입점이고, 인덱스에 없는 페이지와 페이지가 없는 인덱스 항목은 둘 다 결함으로 처리됩니다.
규칙 가운데 특히 눈에 띄는 것은 동일인 판정 규칙입니다. 사람 페이지의 identities 목록은 slack:U01EXAMPLE처럼 연결원본:식별자 형태로 쌓이고, 여기에 항목을 추가하는 것은 오직 사용자뿐입니다. 그것도 profile/scripts/link_identity.py를 통해서만 가능합니다. 스키마는 그 이유를 이렇게 적어 두었습니다. "이름이 같다는 것은 증거가 아닙니다." 표시 이름이 겹친다는 이유로 두 사람을 한 페이지에 합쳐 버리면, 나중에 이름을 바꿔 분리해야 하고 그렇게 이름이 바뀐 페이지는 이력을 잃습니다. 메모리 작업은 손을 대는 대신 identity_candidates로 후보를 보고만 합니다.
원문의 아키텍처 도식은 일상 업무(이메일, 캘린더와 회의, Slack과 Teams, 문서와 작업)가 자기 모델을 채우고, 그 지식 위에서 NemoClaw가 정책과 안전 경계 안에서 계획하고 행동하며, 결과와 증거가 다시 자기 모델로 되먹임되는 흐름을 보여 줍니다. 다만 이 그림은 지향점에 가깝습니다. 설계 제안 이슈는 캘린더, 회의, 회의록, 사용자를 대신한 발송을 1차 버전의 범위 밖으로 명시했고, 실제로 지금 배포된 연결원본은 Slack과 Microsoft Graph를 통한 Outlook 메일함 둘뿐입니다.
지식과 판단을 갈라놓는 이유
레시피가 저장하는 정보는 두 종류인데, 성격이 전혀 다릅니다.
지식(Knowledge) 은 사람, 프로젝트, 우선순위, 업무 습관처럼 세상에 대한 사실입니다. 위에서 본 마크다운 위키가 이것을 담습니다.
판단(Judgment) 은 어떤 항목이 주의를 요하는지, 이번 주에 몇 번째로 중요한지, 사용자가 그것을 무시했는지에 대한 에이전트의 의견입니다. 이쪽은 $HERMES_HOME/workspace/ledger/state.db에 있는 SQLite 의무 원장(obligation ledger) 이 담습니다.
둘을 왜 갈라놓아야 하는지는 판단을 어디에 쓸지 생각해 보면 분명해집니다. 판단은 메일함에도 Slack 워크스페이스에도 들어갈 자리가 없습니다. 억지로 넣으려면 읽음 표시나 라벨, 폴더를 쓰게 되는데, 이는 에이전트의 의견을 담자고 사용자의 실제 데이터를 바꾸는 일입니다. 설계 제안 이슈는 기존 레시피들을 표로 비교하면서 이 지점을 짚었습니다. 예컨대 developer-community-chief-of-staff 레시피는 항목별 처리 상태를 원본 메일함에 isRead 값을 PATCH하는 방식으로 기록했고, 그래서 원본 시스템이 정의한 필드 안에 갇혔습니다.
그리고 지식은 행동을 정당화하지 않습니다. 원문은 이 절을 다음 문장으로 마무리합니다.
"맥락은 행동에 정보를 줄 수는 있어도, 행동을 승인할 수는 없습니다."
"Context can inform an action, but it cannot authorize one."
메모리 페이지에 어떤 동료가 Slack을 선호한다고 적혀 있으면 에이전트는 Slack을 추천할 수 있습니다. 그러나 실제로 메시지를 보내는 일은 자격 증명, 도구 권한, 런타임 정책, 사용자 승인에 달려 있고, 그 넷 중 어느 것도 메모리가 결정하지 않습니다.
긴급함이 아니라 사용자가 고른 일: 의도 게이트
들어오는 요청은 대체로 스스로를 긴급하다고 소개합니다. 하지만 발신자가 주장하는 긴급함은 수신자의 우선순위와 무관합니다. 레시피는 이 간극을 의도 게이트(intent gate) 로 막습니다. 최상위 등급은 사용자가 스스로 하겠다고 밝힌 일과 연결된 의무에만 열립니다.
공개된 레시피의 오프라인 예제가 이 동작을 그대로 보여 줍니다. 마감이 임박한 경비 정책 확인 요청은 목록에서 사라지지 않지만, 사용자가 우선순위로 적어 둔 조용한 요청보다 아래에 놓입니다.
여기서 설계상 중요한 구분이 하나 더 있습니다. 무엇이 더 중요한지를 정하는(order) 것은 판단이 필요하므로 모델이 하고, 누가 어느 등급(tier) 을 갖는지는 산수이므로 결정론적 코드가 합니다. ranking.py의 주석이 그 이유를 직설적으로 적어 두었습니다.
"""Deterministic priority assignment.
The model decides ORDER (which row matters more) because that needs judgment.
This module decides TIER (who gets high / medium / low) because that is
arithmetic, and arithmetic in a prompt is advisory rather than enforced.
"""
HIGH_CAP = 10
MEDIUM_CAP = 10
"프롬프트 안의 산수는 강제되는 것이 아니라 권고에 그친다" 는 문장은 프롬프트로 상한을 지시했을 때 겪는 실패를 가리킵니다. 그래서 상한은 코드에 들어 있고, 규칙은 다음과 같습니다.
상위 등급은 최대 10건, 중간 등급도 최대 10건입니다.
상위 등급은 의도 게이트를 통과한 항목에만 열립니다. 마감, 중요한 발신자, 전체 공지 같은 외부 긴급함만으로는 부족합니다.
게이트를 통과하지 못한 채 상위 10위 안에 든 항목은 버려지지 않고 중간 등급 경쟁으로 내려갑니다(cascade).
사용자가 직접 고정(pin)한 항목은 게이트보다 우선하지만 상한에는 그대로 걸립니다. 11건을 상위로 고정하면 10건만 상위에 남고 한 건은 다른 초과분과 똑같이 내려갑니다.
두 상한을 넘어선 나머지는 전부 하위 등급입니다.
핀이 상한을 뚫지 못하게 한 이유도 코드 주석에 적혀 있습니다. 목록이 짧다는 성질을 지시가 아니라 구조로 보장하려는 것인데, 핀 개수만큼 늘어나는 등급은 결국 지시로만 짧은 목록입니다. 상한을 항목 식별자가 아니라 위치로 세는 것도 같은 맥락으로, 호출자가 넘긴 값이 중복되면 열 칸짜리 등급에 열한 건이 조용히 들어올 수 있기 때문입니다.
교정이 남는 자리: 감사 기록과 선호 정책
지속되는 메모리는 옳은 판단만큼 틀린 판단도 성실하게 보존합니다. 그래서 사용자가 고칠 길이 없으면 메모리는 시간이 갈수록 부담이 됩니다.
같은 교정을 반복하면 아무 일도 일어나지 않고(no-op), 이미 완료된 항목이나 상태가 맞지 않는 항목에 교정을 걸면 종료 코드 3과 함께 어떤 상태 전이가 필요한지를 알려 줍니다. 모든 변경은 추가 전용(append-only) 감사 기록에 한 번씩 남고, actor='user' 이벤트로 표시되어 나중에 사람이 한 일과 에이전트가 한 일을 구분할 수 있습니다.
여기까지는 흔한 설계인데, 그다음 단계가 이 레시피의 성격을 잘 보여 줍니다. 같은 방향의 교정이 임계값을 넘으면 그 패턴이 작고 사람이 읽을 수 있는 선호 정책(preference policy) 문서로 승격됩니다. 임계값은 프롬프트가 아니라 preferences.py에 THRESHOLD = 3으로 박혀 있고, 정책 자체도 MAX_POLICY_ENTRIES = 20으로 스무 항목에서 잘립니다. 세는 대상은 ignored와 priority_override 두 종류의 교정뿐입니다.
여기서도 앞의 순위 매김과 똑같은 분업이 반복됩니다. 세 번이 실제로 일어났는지 세는 것은 코드가 하고, 나중 실행이 실제로 따를 수 있게 선호 문장을 쓰는 일은 판단이 필요하므로 스킬이 합니다. 임계값을 고정한 이유도 코드 주석에 그대로 적혀 있습니다. "임계값은 일부러 고정해 두었습니다. 무엇을 선호로 볼지 스스로 기준을 낮출 수 있는 시스템은 결국 전부를 받아들이게 됩니다."
설계 제안 이슈의 표현도 분명합니다. "학습되는 것은 없습니다. 정책은 사람이 읽고, 고치고, 지울 수 있는 파일이며, 지우면 시스템은 기본 판단으로 돌아갑니다."
즉 되먹임 고리 전체가 눈에 보이는 형태로 남습니다.
에이전트 판단 → 사용자 교정 → 감사 이벤트 → 선호 정책 갱신
선호를 모델 상태 안에 숨겨 두는 방식과 비교하면 차이가 분명합니다. 파인튜닝이나 잠재 벡터로 사용자 선호를 흡수한 시스템에서는 "왜 이걸 자꾸 위로 올리지"라는 질문에 답할 방법이 없고, 되돌리려면 다시 학습시키는 수밖에 없습니다. 에이전트 메모리를 다루는 다른 접근들, 예컨대 ReasoningBank나 Memora와 견줘 보면 이 레시피는 자동 일반화보다 검사 가능성 쪽으로 확실히 기울어 있습니다.
일곱 개의 예약 작업과 깨우기 게이트
이 레시피가 "메모리 라이브러리"가 아니라 "운영되는 시스템"인 이유는 예약 작업에 있습니다. scripts/register-jobs.sh가 Hermes cron에 등록하는 작업은 일곱 개이고, 같은 이름의 작업은 덮어쓰기 때문에 여러 번 실행해도 중복되지 않습니다.
작업
주기
선행 단계
스킬
intake (수집 판정)
30분마다
select_intake.py
inbound-judging
review (재판정)
6시간마다
select_review.py
obligation-review
memory writing (메모리 작성)
매일 01:00
select_memory.py
memory-writing
retention (보존 기간 정리)
매일 02:00
retention.py
없음
memory repair (메모리 복구)
매일 03:00
없음
memory-repair
memory consolidation (메모리 압축)
매일 04:00
없음
memory-consolidation
preference update (선호 갱신)
매일 04:30
없음
preference-update
위 표에서 두 가지를 짚어 볼 수 있습니다. 첫째, 재판정이 메시지 도착과 무관하게 6시간마다 돌아갑니다. 조용한 한 주에도 순위는 다시 매겨집니다. 둘째, 메모리 작성이 복구와 압축보다 앞선 시각에 배치되어, 밤사이 새로 쓰인 페이지가 같은 순서 안에서 검사와 압축까지 마칩니다.
깨우기 게이트(wake gate) 는 비용 설계로 볼 만합니다. intake, review, memory writing 세 작업은 에이전트 턴 전에 선택기(selector) 스크립트를 먼저 돌립니다. 처리할 일이 없으면 선택기가 마지막 비어 있지 않은 줄에 게이트 신호를 남기고, Hermes는 추론을 아예 건너뜁니다. retention 작업은 에이전트를 한 번도 깨우지 않습니다. 30분마다 도는 작업이 매번 모델을 호출하지 않는다는 뜻이고, 이는 상시 구동 에이전트에서 곧바로 비용 차이로 이어집니다.
모델이 SQL을 쓰지 않는다는 점도 같은 결의 결정입니다. 모델은 버전이 붙은 JSON 결정 봉투(decision envelope) 를 반환하고, apply_decisions.py가 그것을 검증한 뒤 하나의 트랜잭션으로 적용합니다.
허용되는 결정은 CREATE, KEEP_OPEN, MARK_DONE, SKIP 네 가지뿐이고, 생성이나 유지 결정에는 순위, 제목, 의도 게이트 판정이 반드시 따라와야 합니다.
실행 경계는 메모리가 정하지 않는다
앞에서 인용한 "맥락은 행동을 승인할 수 없다" 는 원칙이 런타임에서 어떻게 강제되는지가 이 절의 내용입니다. NemoClaw가 레시피와 OpenShell을 연결하고 생애 주기를 관리하며, OpenShell은 에이전트를 샌드박스 안에서 실행하면서 파일 시스템, 프로세스, 네트워크 접근에 대한 거버넌스와 정책 집행을 담당합니다. 관리형 추론과 MCP(Model Context Protocol) 연결에 쓰이는 자격 증명은 샌드박스 밖에 남습니다.
이 구조가 필요한 이유를 원문은 위협 모델의 언어로 설명합니다.
"메모리와 검색된 콘텐츠는 모델에 들어가는 입력이지, 신뢰할 수 있는 보안 정책이 아닙니다."
에이전트가 맥락을 잘못 해석하거나 악의적인 지시를 따르더라도, 운영자가 정의한 런타임 경계 안에서만 움직입니다. 자기 모델은 결국 외부에서 들어온 메시지로 채워지므로, 그 안의 문장을 권한으로 취급하는 순간 프롬프트 인젝션이 그대로 권한 상승이 됩니다.
실제 자격 증명 처리도 이 원칙을 따릅니다. 설치 스크립트는 프로필을 만들 때 model.default, model.provider, model.base_url만 복사하고 자격 증명은 절대 복사하지 않습니다. NemoClaw 경로에서는 진짜 키 대신 sk-OPENSHELL-PROXY-REWRITE라는 재작성 표식(sentinel)을 넣는데, Hermes가 sk- 접두사를 요구하기 때문에 형식만 맞춘 값이고, OpenShell이 송출 경계에서 이 표식을 지우고 관리형 추론 자격 증명을 주입합니다.
연결원본 쪽 권한도 좁게 잡혀 있습니다. Slack은 봇이 아니라 사용자 토큰을 쓰는데, 봇으로는 사용자 본인의 DM을 볼 수 없기 때문입니다. 대신 요청하는 권한 범위는 channels:read, channels:history, im:read, im:history, mpim:read, mpim:history, users:read 일곱 개로 제한되고, 비공개 채널은 의도적으로 제외해 groups:read와 groups:history를 아예 요청하지 않습니다. 공개 채널도 운영자가 slack_channels.json에 채널 ID를 직접 적은 것만 읽습니다. Outlook 쪽은 위임된 Mail.Read와 offline_access뿐이고, 애플리케이션 권한은 쓰지 않으며 운영자가 자기 Microsoft Entra 애플리케이션을 직접 등록합니다.
Slack의 속도 제한을 다루는 방식도 눈여겨볼 만합니다. 영향을 받는 비마켓플레이스 앱은 분당 1회 요청, 응답당 메시지 15건으로 묶이는데, 이는 재시도로 넘길 수준이 아니라 설계를 바꿔야 하는 제약입니다. 그래서 커넥터는 워크스페이스 전체를 훑는 대신 한정된 채널 집합만 보고, 429 응답에는 Retry-After를 존중해 물러나며, 예산이 소진되면 커버리지가 불완전했다는 사실을 명시적으로 보고합니다. 확보하지 못한 범위를 "없음" 으로 조용히 처리하지 않습니다.
얼마나 좋아졌나: Agent Memory Benchmark
성능 주장은 같은 저장소에 공개된 Agent Memory Benchmark의 실행 결과로 제시됩니다. 벤치마크의 자체 소개 문장이 목적을 잘 요약합니다. "메모리 시스템이 이메일과 채팅을 수집한 뒤 무엇에 답할 수 있는지, 그리고 수집과 응답에 얼마가 드는지를 측정한다." 품질과 비용을 절대 합치지 않고 따로 보고하는 것이 이 하네스의 기본 방침입니다.
말뭉치는 둘입니다. 코퍼스 A는 소프트웨어 플랫폼 엔지니어링 팀을 배경으로 한 425개 문서(이메일 200건, 채팅 225 채널일, 메시지 559건)이고 기간은 2026년 4월 16일부터 5월 27일까지입니다. 코퍼스 B는 세 개 현장을 관리하는 건설 프로그램 매니저를 배경으로 한 173개 문서로, 도메인과 생성 모델을 바꿔 결과를 교차 확인할 수 있게 했습니다. 둘 다 완전한 합성 데이터입니다.
코퍼스 A에서 특히 중요한 것은 절반으로 나뉜 구조입니다. part_a(4월 16일부터 5월 11일)와 part_b(5월 12일부터 5월 27일)를 순서대로 수집하는데, part_b는 곳곳에서 part_a의 내용을 뒤집습니다. 나중에 들어온 정보가 앞선 주장을 대체할 때 메모리가 제대로 따라가는지를 보는 장치입니다.
질문은 기본 155개와 하드 31개를 합쳐 186개입니다.
기본 세트는 단일 문서에 적힌 사실(single_hop, 30개), 여러 문서에서 교차 확인되는 사실(multi_source, 73개), 비슷해 보이는 둘을 합치거나 하나를 둘로 쪼개는 실수(disambiguation, 15개), 말뭉치가 말한 적 없는 것에 대한 자신만만한 답변(abstention, 13개), 이미 갱신된 값을 현재 값처럼 보고하는 실수(freshness, 12개), 한 문서에만 있는 세부 정보(citation, 12개)를 봅니다.
하드 세트는 기본 세트가 시스템들을 더 이상 구분하지 못하게 되자 추가된 것으로, 그럴듯한 집합에서 어느 항목이 속하지 않는지(set_difference, 6개), 지금이 아니라 특정 시점에 무엇이 참이었는지(as_of, 6개), 각각으로는 여러 후보에 걸리는 조건 두세 개를 동시에 거는 문제(constraint, 5개), 값이 두 번 움직였을 때 출발점과 도착점(chain_freshness, 5개), 제안한 사람과 실행한 사람의 구분(attribution, 5개), 사건들의 상대적 순서(ordering, 4개)를 봅니다.
채점에는 모델이 전혀 개입하지 않습니다. 186개 문항 모두 결정론적으로 채점되며, 대소문자, 문장 부호, 공백, 날짜 표기, 천 단위 구분자를 정규화한 뒤 각 채점 모드의 명시적 규칙을 적용합니다. 대신 그 대가도 함께 적어 두었는데, 허용 표현 집합 밖으로 표현된 정답은 맞아도 오답 처리됩니다. 그래서 문항별 판정이 실행마다 함께 배포되어 이의를 확인할 수 있게 해 두었습니다. 회피(abstention) 문항에는 정답이 없어서, 예정만 되어 있고 아직 일어나지 않은 일을 자신 있게 서술하면 오답이고 "말뭉치에 그런 내용이 없습니다" 라고 답하면 정답입니다.
하네스가 제대로 도는지는 정답을 미리 아는 오프라인 픽스처로 확인합니다. selftest/oracle 어댑터는 정확히 1.0을, selftest/wrong 어댑터는 채점 모드마다 다른 방식으로 틀려서 정확히 0.0을 받습니다. 이 값들이 테스트에 고정되어 있어 러너와 리포트 사이에 어긋남이 생기면 곧바로 드러납니다.
먼저, 표의 자기 모델이 이 레시피는 아닙니다
숫자를 보기 전에 짚어야 할 것이 있습니다. 블로그는 표를 "메모리 기반 Chief of Staff를 NemoClaw에 더했더니 여러 작업에서 측정 가능한 개선이 나왔다" 는 문장으로 소개하지만, 저장소에 들어 있는 그 실행의 산출물은 더 좁게 적혀 있습니다. 자기 모델 실행의 summary.md 첫 줄은 이렇습니다.
"여기에 어댑터가 함께 배포되지 않는 통합형 설계를 측정한 것이며, 이 행은 데이터 한 점이지 이 저장소가 다시 실행할 수 있는 것이 아닙니다."
"Measures a consolidating design that does not ship an adapter here; the row is a data point, not something this repository can re-run."
같은 실행의 report.json도 adapter.revision.note에 "이 시스템의 어댑터는 여기에 배포되지 않으며 이 저장소에서 재현할 수 없다" 고 적어 두었습니다. 저장소가 배포하는 기준선 어댑터는 naive_rag, agentic_rag, ledger_rag 셋인데, 그중 실제로 이 레시피의 원장을 구동하는 ledger_rag에는 별도 경고가 붙어 있습니다. "ledger_rag는 레시피 자체를 채점하지 않습니다." 이 어댑터는 원장 위에 후보 선별과 답변 생성을 얹었을 뿐, 레시피 자체는 수정하지 않았습니다.
정리하면 90.9%를 낸 자기 모델은 이 레시피와 같은 계열의 설계이되 공개되지 않은 별개 시스템이고, 공개된 두 실행 중 재현 가능한 쪽은 기준선뿐입니다. 아래 숫자는 그 전제 위에서 읽어야 합니다.
코퍼스 A, NVIDIA Nemotron 3 Ultra 기준 결과
두 설정 모두 425개 문서를 읽고 186개 질문에 답했으며, 같은 정답 키와 채점기, 같은 기반 모델(NVIDIA Nemotron 3 Ultra)을 썼습니다. 차이는 주로 추론이 언제 일어나는가입니다. 에이전틱 RAG 기준선은 질문 시점에 스스로 검색 질의를 쓰고 최대 3라운드까지 반복하고, 자기 모델은 수집 시점에 추론을 몰아 둡니다.
지표
문항 수
에이전틱 RAG
자기 모델
차이
전체 정확도
186
82.8%
90.9%
+8.1%p
하드 문항
31
67.7%
87.1%
+19.4%p
시간에 따라 바뀐 사실 추적 (chain_freshness)
5
60.0%
100.0%
+40.0%p
특정 시점 기준 추론 (as_of)
6
33.3%
66.7%
+33.3%p
개체 구분 (disambiguation)
15
66.7%
86.7%
+20.0%p
다중 출처 종합 (multi_source)
73
87.7%
94.5%
+6.8%p
말뭉치에 근거해 회피 (abstention)
13
100.0%
92.3%
-7.7%p
단일 조회 (single_hop)
30
86.7%
83.3%
-3.3%p
출처 인용 커버리지
186
92.5%
97.8%
+5.4%p
표에서 두 가지 방향을 확인할 수 있습니다. 자기 모델이 크게 이기는 항목은 전부 시간축에 걸린 것들입니다. 값이 두 번 바뀐 경우와 특정 시점 기준 질문에서 각각 40.0%p, 33.3%p를 벌었고, 같은 사람이나 프로젝트를 가리키는 서로 다른 이름을 구분하는 문제에서도 20.0%p를 앞섭니다. 자기 모델이 유지하는 것이 바로 이런 관계이므로 예상대로의 결과입니다.
반대로 정확도가 낮아지는 항목이 둘 있습니다. 말뭉치가 말하지 않은 것에 대해 회피해야 하는 문항에서 에이전틱 RAG는 13개를 모두 맞혀 100.0%인 반면 자기 모델은 92.3%로 내려갑니다. 단일 문서 조회에서도 86.7% 대 83.3%로 뒤집힙니다. 파생된 해석을 미리 만들어 두는 접근이 원문을 그때그때 확인하는 접근보다 "없는 것을 없다고 말하기" 에 불리하다는 신호로 읽힙니다. 블로그의 표가 이 두 줄을 지우지 않고 실은 점은 밝혀 둘 만합니다.
다만 블로그의 표는 실행 리포트에 있는 항목의 일부입니다. 두 실행의 summary.md를 나란히 놓으면 표에 없는 행이 여덟 개 더 나오는데, 그중 절반은 자기 모델에 유리하고 나머지는 그렇지 않습니다.
지표 (블로그 표에 없는 행)
문항 수
에이전틱 RAG
자기 모델
차이
기본 세트 전체
155
85.8%
91.6%
+5.8%p
사건 순서 (ordering)
4
75.0%
100.0%
+25.0%p
경쟁하는 낡은 값이 있을 때의 최신값 판정
freshness의 하위 분할
66.7%
88.9%
+22.2%p
복합 조건 (constraint)
5
80.0%
100.0%
+20.0%p
최신값 반영 (freshness)
12
75.0%
91.7%
+16.7%p
한 문서에만 있는 세부 정보 (citation)
12
91.7%
100.0%
+8.3%p
제안자와 실행자 구분 (attribution)
5
80.0%
80.0%
0%p
집합에서 빠지는 항목 (set_difference)
6
83.3%
83.3%
0%p
그리고 정확도에는 들어가지 않지만 리포트가 함께 내는 증거 진단 지표가 있는데, 여기서는 방향이 반대입니다.
진단 지표 (정확도 계산에 미포함)
에이전틱 RAG
자기 모델
차이
증거 재현율 (evidence recall)
63.4%
40.2%
-23.3%p
증거 정밀도 (evidence precision)
75.4%
46.0%
-29.4%p
즉 자기 모델은 인용을 더 자주 달지만(출처 인용 커버리지 97.8% 대 92.5%), 그 인용이 정답 키가 지목한 문서와 겹치는 비율은 기준선보다 낮습니다.
다만 이 두 숫자를 곧바로 "출처 관리가 부실하다"로 읽으면 안 됩니다.방법론 문서에 증거 재현율의 정의가 이렇게 적혀 있기 때문입니다. 이 지표는 시스템이 스스로 답변 행에 적어 넣은source_ids를 말뭉치의 doc_id와 대조한 값이고, 시스템이 실제로 무엇을 검색하고 읽었는지는 아무것도 관측하지 않습니다. 그래서 자기 청크나 노드 식별자를 내놓는 저장소는 그것을 말뭉치 doc_id로 매핑하기 전까지 0점이며, 방법론 문서 스스로 "이 측정은 그 매핑을 해 줄 의향이 있는 시스템 사이에서만 아키텍처 중립적" 이라고 적었습니다. 파생 페이지를 만들어 두는 자기 모델은 정확히 그 매핑이 어긋나기 쉬운 쪽입니다.
애초에 이 지표가 있는 이유도 따로 있습니다. 방법론 문서는 알려진 한계 항목에서 "수집이 약하고 검색이 강한 시스템도 좋은 점수를 받을 수 있다" 고 인정하면서, 증거 재현율을 그 경우를 드러내려고 따로 보고한다고 밝힙니다. 정확도에서 떼어 놓은 진단 지표로만 두는 이유가 여기 있습니다.
자기 모델은 수집 단계에서 모델 호출 1,603회와 1억 8,276만 토큰을 씁니다. 425개 문서를 읽는 데 걸린 시간이 5,960초, 약 1시간 40분입니다. 기준선의 수집은 임베딩만 하므로 출력 토큰이 0이고 총 17만 토큰에 25초입니다. 응답 단계도 52분 대 6분으로 갈립니다. 자기 모델은 전체 토큰의 80%를 수집에, 기준선은 94%를 응답에 씁니다. 다만 결과 문서는 이 두 열을 비율로 읽지 말라고 명시합니다. 어느 리포트에도 두 시스템이 같은 사건을 셌다는 것을 입증할 전달 호출 기록이 없고, 양쪽 모두 comparable_on_cost를 false로 표시해 두었기 때문입니다.
배수로 읽지 않더라도 표에서 한 가지 방향은 분명합니다. 방법론 문서는 수집 시점 추론과 질문 시점 검색의 손익분기를 total = ingest_tokens + N × per_question_tokens 라는 식으로 정리하고, "둘 중 어느 쪽이 이길지는 그 메모리가 앞으로 몇 개의 질문을 받게 되느냐에 달렸다" 고 설명합니다. 그런데 이 실행에서 자기 모델은 수집만 비싼 것이 아니라 질문당 토큰에서도 24만 대 1.5만으로 더 큽니다. 두 항이 모두 크면 N을 아무리 키워도 교차점이 생기지 않으므로, "한 번 비싸게 만들어 두고 두고두고 싸게 쓴다"는 통상의 논거는 적어도 이 두 산출물 사이에서는 성립하지 않습니다.
기반 모델이 하나뿐이라는 한계도 방법론 문서가 스스로 무겁게 다룹니다. 제출은 (시스템 × 모델) 쌍이어야 하고 행은 모델별로 묶어 읽으라고 안내하면서, 이렇게 적었습니다. "한 모델에서 나타났다가 다른 모델에서 사라지는 아키텍처 우위는 아키텍처 우위가 아닙니다."
벤치마크 관리자들이 결과 문서에 밝혀 둔 한계는 네 가지 더 있습니다. 실행은 코퍼스 A에서만 이뤄졌고 코퍼스 B는 돌리지 않았습니다. 기반 모델도 하나뿐인데, 정작 이 벤치마크의 방법론은 제출자에게 최소 두 개를 요구합니다. 게다가 자기 모델 어댑터는 저장소에 포함되어 있지 않아서, 공개된 것은 출력물뿐이고 그 메모리가 어떻게 생겼는지는 확인할 수 없습니다. 마지막으로 공개 과정에서 식별자 20개와 문항 ID 4개의 이름이 바뀌어 답변에 치환이 적용되었고, 치환 전 원래 채점으로는 80.1% 대 87.6%였습니다. 결과 문서는 여기에 한 줄을 덧붙여 두었습니다. "변환된 결과는 새로 실행한 결과보다 약한 증거로 남습니다."
말뭉치 자체의 성격도 같이 봐야 합니다. 코퍼스 A 문서는 "실제 이메일은 더 지저분하다. 인용된 전달 메일, 죽은 스레드, 복도에서 나눈 대화에 의미가 걸려 있는 메시지" 라고 스스로 적으면서, 여기서 나온 결과는 "가상의 엔지니어링 팀 한 곳의 6주" 에 대한 결과라고 못 박았습니다.
정리하면 이 표는 잘 만들어진 측정이지만 순위표가 아닙니다. 벤치마크 관리자들은 결과 문서에 "측정을 확립할 뿐 원인이나 아키텍처적 결론을 확립하지는 않는다" 고 적어 두었습니다.
크레덴셜 없이 먼저 돌려보기
이 레시피는 오프라인 워크스루를 함께 제공합니다. NemoClaw도, 샌드박스도, 자격 증명도, 네트워크 접근도 없이 순위 매김, 의도 게이트, 교정의 지속성, 메모리 자체 검사를 로컬에서 그대로 돌려 볼 수 있습니다. 필요한 것은 macOS, Linux, WSL(Windows Subsystem for Linux) 위의 Python 3.10 이상뿐입니다.
수집이 멱등(idempotent)한지도 직접 확인할 수 있습니다. 새 프로필 홈을 만들고 load_fixtures.py를 두 번 실행하면 첫 실행은 "added": 8, 두 번째는 "added": 0을 보고합니다.
여기서 한 가지는 분명히 해 둘 필요가 있습니다. 오프라인 워크스루는 추론이 필요한 두 지점에만 녹화된 결정 봉투를 끼워 넣고, 그 아래로는 예약 실행과 완전히 같은 코드를 씁니다. 즉 이 실행이 검증하는 것은 워크플로우이지 모델의 판단 품질이 아닙니다. 저장소의 한계 절도 "녹화된 판단 턴은 워크플로우를 테스트하는 것이지 모델 품질을 테스트하는 것이 아니다" 라고 같은 말을 적어 두었습니다.
의존성 이야기도 덧붙일 만합니다. 이 레시피의 파이썬 모듈은 전부 표준 라이브러리만 씁니다. 별도 패키지 매니페스트가 없고, 프로필 매니페스트가 Hermes 0.19.0 이상을 요구할 뿐입니다. 레시피 자체의 버전은 0.1.0, 상태는 reference-example로 선언되어 있고, 테스트는 14개 파일에 640건이 들어 있어 스키마 마이그레이션, 메모리 불변식, 동시성과 크래시 복구, 결정론적 순위, 선호 임계값, 깨우기 게이트, 수집기 회전 동작까지 덮습니다. 벤치마크 하네스도 마찬가지로 서드파티 임포트가 없고, 오프라인 검사에만 pytest와 tesseract가 필요합니다. tesseract가 필요한 이유는 README에 실린 실행 결과 이미지를 OCR로 읽어서 문서가 실제 검증된 실행을 보여 주는지 검사하기 때문입니다.
무엇을 아직 못하는가
저장소의 한계 절은 이 레시피가 무엇이 아닌지를 구체적으로 적어 두었습니다. 도입을 검토한다면 이 목록을 먼저 읽는 편이 낫습니다.
예약 작업은 NemoClaw가 관리하는 Hermes 샌드박스 안의 Linux 환경을 요구합니다. 연결원본 설정 헬퍼 스크립트는 사용자 머신에서도 Linux나 WSL을 요구하는데, 이는 헬퍼 스크립트의 제약이지 런타임 요구사항은 아닙니다.
연결원본은 Slack과 Microsoft Graph 기반 Outlook 메일함 둘뿐입니다. 다른 메신저를 붙이려면 자체 커넥터와 OpenShell 프로바이더 정책을 직접 만들어야 합니다.
Graph 자격 증명의 출처가 런타임에 검증되지 않습니다.ingest_graph.py는 MS_GRAPH_ACCESS_TOKEN을 제공하는 프로바이더가 무엇이든 그대로 신뢰하며 이름이나 타입, 정책을 확인하지 않습니다. 설치 시점의 거부를 우회할 수 있으므로 전용 샌드박스를 쓰거나 충돌하는 프로바이더를 떼어 내라고 안내합니다.
Slack의 삭제는 즉시 관측되지 않습니다. 한정된 페이지 단위 조회에서 메시지가 사라진 것은 삭제인지 조회 창 밖으로 밀려난 것인지 구분되지 않습니다. Outlook은 델타 질의가 삭제를 명시적으로 보고하므로 즉시 본문을 지우지만, Slack은 보존 기간 정리로 자연스럽게 사라지기를 기다립니다. 양쪽에 같은 보장이 있는 것처럼 적는 대신, 실제로 지킬 수 있는 약한 보장을 그대로 밝혀 두었습니다.
예약 작성기는 사람과 주의 페이지만 관리합니다. 프로젝트, 패턴, 개념, 목표 페이지는 스키마는 있지만 자동 작성기가 없습니다. 특히 목표 페이지는 의도적인 공백입니다. 스키마 문서는 그 이유를 이렇게 설명합니다. 목표는 순위의 최상위 등급을 여는 조건이므로, 받은 편지함에서 유추한 목표는 "사용자가 고른 적 없는 일을 승격시킵니다." 목표는 사람이 말해야 합니다.
메모리 압축은 모델이 이끕니다.memory_check.py는 불변식과 상한 위반을 결정론적으로 검출하지만, 안전한 압축 방법을 만들어 내지는 않습니다.
재순위 이벤트는 압축되지 않고 계속 쌓입니다.
이것은 참조 레시피이지 호스팅 서비스나 프로덕션 준비 완료 선언이 아닙니다. 한 사람이 직접 통제하는 머신에서 자기 업무 흐름을 다루는 것을 전제로 합니다.
지금 설치하면 실제로 무엇이 쌓이는가
여섯 종류 중 둘만 쓰인다는 사실이 실제로 어떤 결과를 낳는지는, 이 레시피의 후속 이슈인 메모리 쓰기 파이프라인 완성(#156)이 계정에 직접 붙여 본 결과로 정리해 두었습니다. 블로그만 읽고 도입을 검토한다면 이쪽이 더 중요한 문서입니다.
개체 추출이 전혀 없습니다. 이슈의 표현으로는 프로젝트, 슬러그, 별칭, 건강 상태, 마일스톤, 주제, 용어, 약어를 계산하는 코드가 레시피 어디에도 없고, select_memory는 발신자를 셀 뿐입니다. 아직 작성기가 없는 페이지 유형이 전부 개체 위에 세워지는 것들이라, 이 하나가 여러 빈칸의 공통 원인입니다.
들어온 메시지만 수집합니다.ingest_graph.py는 /me/mailFolders/inbox/messages/delta 하나만 읽어서 보낸 편지함도, 임시 보관함도, 하위 폴더도 보지 않습니다. Slack 쪽 worth_judging()은 토큰 소유자가 쓴 메시지를 전부 떨어뜨립니다. 사용자가 쓴 것은 저장소에 하나도 없습니다. 이 두 가지는 2026년 9월 7일 기준 main에서도 그대로입니다.
이슈가 요약한 결론이 도입 판단에는 가장 정확한 한 줄입니다. "지금 이것을 설치한 사람은 누가 자기에게 썼고 자기가 무엇을 빚지고 있는지는 아는 메모리를 얻지만, 그 메시지들이 무엇에 관한 일이었는지는 아무것도 얻지 못합니다."
이슈가 함께 보고한 검사기 결함 세 건(구조적으로 참이 될 수 없는 페이지 등재 규칙, 회전된 로그를 계속 미등재로 신고하는 문제, concepts/를 넣을 인덱스 절이 없는 문제)은 그 뒤 1단계로 처리되어 #158에 병합되었습니다. 실제로 오늘자 main의 profile/seed/index.md에는 ## Concepts 절이 있고, memory_check.py는 log.archive.md를 사이드카로 면제하며, 문제의 등재 규칙 문구는 사라졌습니다. 개체 추출과 사용자 발신 메시지 수집은 아직 열린 단계로 남아 있습니다.
여기에 개인 정보 처리 관련 성질도 함께 봐야 합니다. 수신자 목록은 수집 시점에 direct, mentioned, broadcast 셋 중 하나로 축약되어 누가 함께 참조되었는지는 저장되지 않습니다. 메시지 본문은 기본 30일 뒤 지워지고 메타데이터, 의무 상태, 감사 이력만 남습니다. 첨부 파일은 어떤 커넥터도 가져오지 않고 이를 담을 스키마 컬럼도 없습니다. 발신자, 도메인, 채널 단위 제외 목록은 표시 단계가 아니라 저장 직전 삽입 경계에서 적용됩니다.
한편 NVIDIA 저자들은 소유자 전용 권한(0700)이 암호화가 아니라는 점을 문서 여러 곳에서 반복해 강조합니다. 같은 머신의 다른 계정을 막을 뿐 디스크를 통째로 읽을 수 있는 사람에게는 아무 소용이 없으므로, 실제 메시지 본문이 저장되는 커넥터를 붙이기 전에 HERMES_HOME 아래 볼륨의 암호화를 먼저 확인하도록 요구합니다. 그리고 원본 시스템에 쓰지 않는다는 성질은 약속이 아니라 테스트로 강제되는데, 모든 모듈을 훑어 쓰기 동사와 원본 변경 호출을 찾는 검사가 들어 있어서 나중에 코드가 바뀌어도 이 속성이 살아남습니다.
다만 이 보장의 범위도 저장소가 직접 좁혀 두었습니다. 그것은 배포된 수집기 코드에 대한 서술이지, 같은 샌드박스에 붙은 무관한 읽기 쓰기 프로바이더가 다른 코드의 쓰기까지 거부한다는 주장이 아닙니다. FAQ는 한 발 더 나가서, Graph 수집기가 MS_GRAPH_ACCESS_TOKEN을 누가 넣어 줬는지 확인하지 못하므로 외부의 읽기 쓰기 프로바이더가 붙으면 플랫폼 수준의 쓰기 거부 주장 자체가 거짓이 된다고 적었습니다. 앞의 한계 목록에 있던 Graph 자격 증명 출처 미검증 문제와 같은 뿌리입니다.
수집기가 실패했을 때의 처리도 같은 방향입니다. 수집 배치는 실패한 수집기의 이름과 종료 코드, 오류 분류만 기록하고 수집기 출력을 모델 프롬프트에도 스케줄러 로그에도 넣지 않습니다. 그 출력에 메시지 본문이나 인증 정보가 섞여 있을 수 있기 때문이며, 전체 오류를 보려면 수집기를 직접 실행해야 합니다.
정리
이 글에서 반복해 확인하게 되는 원칙은 하나입니다. 모델에게는 판단을 맡기고, 계약과 상한과 경계는 코드에 둔다는 것입니다. 순위의 순서는 모델이 정하지만 등급의 크기는 ranking.py가 정하고, 선호 문장은 모델이 쓰지만 교정이 세 번 일어났는지는 preferences.py가 세며, 페이지에 무엇을 쓸지는 모델이 정하지만 그 페이지가 스키마를 지키는지는 memory_check.py가 봅니다. 메모리가 무엇을 권할지는 모델이 정하지만 무엇을 실행할 수 있는지는 OpenShell이 정합니다.
한국의 팀에 이 레시피를 그대로 옮기기는 쉽지 않습니다. 연결원본이 Slack과 Outlook뿐이라 사내 메신저를 쓰는 환경이라면 커넥터부터 만들어야 하고, 예약 실행에는 Linux 샌드박스가 필요합니다. 그러나 옮겨 쓸 만한 것은 커넥터가 아니라 설계 결정 쪽입니다. 출처 각주를 강제하는 스키마, 감쇠 창과 성장 상한, 지시가 아니라 코드로 지켜지는 등급 상한, 파일로 남아 사람이 지울 수 있는 선호 정책, 그리고 추론을 건너뛰게 해 주는 깨우기 게이트는 어떤 에이전트 메모리 구현에도 그대로 적용됩니다.
정확도 숫자는 조심해서 읽는 편이 좋습니다. 코퍼스 하나, 기반 모델 하나, 재현할 수 없는 실행이고, 무엇보다 그 90.9%를 낸 자기 모델은 지금 내려받을 수 있는 이 레시피가 아니라 어댑터가 공개되지 않은 별개 시스템입니다. 수집 단계에서 1억 8천만 토큰과 1시간 40분을 쓴 실행에서 나온 8.1%p이기도 합니다. 정작 이 벤치마크에서 가치가 큰 쪽은 결과 표가 아니라 하네스 자체일 수 있습니다. 186개 문항을 모델 없이 결정론적으로 채점하고, 시간에 따라 뒤집히는 말뭉치를 순서대로 수집시키고, 비용과 품질을 절대 섞지 않는 설계는 자기 메모리 시스템을 평가하려는 팀이 바로 가져다 쓸 수 있는 도구입니다.
Building a Memory-Driven Agent with NVIDIA NemoClaw 소개 블로그
NemoClaw, OpenShell, nemoclaw-community 저장소는 모두 Apache License 2.0으로 배포되고 있어, 연구 목적은 물론 상업적 용도로도 자유롭게 사용 및 수정이 가능합니다. 벤치마크 쪽은 코드뿐 아니라 말뭉치와 질문, 정답 키까지 같은 Apache 2.0 이라고 명시되어 있습니다. 두 말뭉치 모두 합성 데이터이고 예약 도메인(.example)과 지어낸 신원만 쓰므로, 실제 계정에서 나온 내용은 들어 있지 않습니다.
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.
Building a Memory-Driven Agent with NVIDIA NemoClaw 소개 블로그
Memory-Driven Chief of Staff 레시피
레시피 설계 제안 및 리뷰 이슈
NVIDIA NemoClaw 공식 문서
파이토치 한국 사용자 모임
은 이런 글들을 한국어로 정리해 나누고 있습니다. 회원으로 가입하시면 주요 글들을 이메일
로 보내드리고, 텔레그램(Telegram)과 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다. 
아래
쪽에 좋아요
를 눌러주시면 다음 글을 정리하는 데 힘이 됩니다~ 