Compass v1.1.0 출시, 출시 12시간 만에 Recall 소비 오류 수정

Nautilus-Compass v1.1.0은 에이전트가 파일 제목은 보지만 본문은 읽지 못했던 Recall (회상) 소비 실패 문제를 수정하였으며, 상위 3개 검색 결과(top-3 hits)에 본문 텍스트를 임베딩하고 소비되지 않은 Recall을 위한 Drift Detector (표류 탐지기)를 추가했습니다.

v1.0.0 출시 12시간 만에 Nautilus-Compass v1.1.0이 출시되었으며, 출시 5시간 만에 발견된 Recall 소비 실패 문제를 해결했습니다. 버그의 내용은 다음과 같습니다: Claude Code 에이전트가 메모리 Recall을 통해 파일 제목은 확인했으나 파일 본문을 읽지 못해, 이전의 실수들을 그대로 재현했습니다.

주요 사실

v1.1.0은 v1.0.0 출시 12시간 만에 배포되었습니다.
상위 3개 검색 결과(Top-3 hits)에 본문의 처음 800자를 임베딩합니다.
Drift Detector (표류 탐지기)에 의해 35개의 부정적 앵커(negative anchors)가 추적됩니다.
130MB 세션 테스트 결과: 41회의 Recall 히트 발생, 0회 소비됨.
재현 비용: 엔드 투 엔드(end-to-end) 기준 $3.50.

Recall 소비 버그

Compass v1.1.0 릴리스 포스트에 따르면, Claude Code 대화의 자매 버전은 교차 세션 메모리(cross-session memory)에 기록된 6단계 품질 파이프라인을 사용하여 WeChat에 긴 글의 기사를 게시해야 했습니다. Compass의 Recall은 올바르게 작동하여, 파일이 에이전트의 UserPromptSubmit 훅 출력에 나타났습니다. 하지만 에이전트는 제목과 80자 분량의 설명만 확인한 뒤 바로 행동에 나섰습니다. 파일 본문을 읽지 않은 것입니다. 감사 게이트(audit-gate)를 통과하는 방법, 어떤 wxid를 사용할지, xhs-cards-embed 구조가 어떻게 생겼는지와 같은 실제 규칙들은 에이전트의 작업 컨텍스트(working context)에 전혀 들어오지 못했습니다.

그 결과, 에이전트는 해당 파일이 방지하기 위해 작성되었던 실패 모드를 정확히 재현했습니다: 임시 _tmp_publish_v8.cjs 스크립트 사용, 비평(critic) 단계 누락, 잘못된 로그인 경로 사용 등입니다. 사용자의 진단은 날카로웠습니다: "Compass가 Recall(회상)은 했지만, 내가 소비(consumption)하지 않았다. 이것은 에이전트 계층의 인격 표류(personality drift)이지, Compass 자체의 실패가 아니다." 릴리스 포스트는 이것이 구조적인 문제라고 언급했습니다. 제목과 120자의 설명을 반환하는 방식은 인덱스만 읽었을 뿐인데도 파일을 다 읽었다고 가정하고 훑어보기 쉽게 만들었습니다.

3계층 수정 사항

v0 — 상위 3개 히트(hits)에 본문 포함. 이제 상위 3개의 Recall 히트 시, 포스트 프론트매터(frontmatter) 본문의 처음 800자를 들여쓰기된 │ 블록 내에 임베딩합니다. 이를 통해 에이전트는 추가적인 Read 도구 호출 없이도 작업 컨텍스트(working context) 내에서 규칙을 파악할 수 있습니다. 하위 4..K 히트는 전체 응답 크기를 약 3KB로 제한하기 위해 헤더 정보만 유지합니다.

v1 — 안티 앵커(anti-anchor) 경고에 과거 실수 본문 포함. Compass의 드리프트 탐지기(drift detector)는 현재 프롬프트를 이전 실수로부터 학습된 35개의 부정적 앵커(negative anchors)와 대조합니다. 이전에는 경고 시 앵커 레이블만 표시되었습니다. v1.1.0은 2단계 매칭 방식을 사용하여 가장 관련성이 높은 과거 레슨 세션의 본문을 임베딩합니다. 매칭 방식은 앵커에 대한 부분 문자열 6-gram(substring 6-gram)과 레슨 유형 프론트매터(lesson-type frontmatter)를 대조하며, 실패 시 최근의 drift!=green 세션으로 대체(fallback)합니다.

v2 — 'Recall은 발생했으나 소비되지 않음' 감지. 새로운 모듈인 recall_consumption.py는 라이브 세션 jsonl 파일을 역추적하여 최근의 Recall 블록을 찾고, 메모리 파일 경로를 추출한 다음, 이후 어시스턴트 턴(assistant turns)에서 일치하는 Read 도구 호출이 있는지 확인합니다. 만약 Recall을 통해 N개의 경로가 나타났음에도 0개가 읽혔다면, 이는 실패 시그니처(failure signature)로 간주됩니다. 이 기능은 drift_check MCP 도구 결과 및 25회의 도구 호출마다 실행되는 mid_session_hook에 연결되어 있으며, 미소비된 항목이 3개 이상이고 비율이 0.3 미만일 때만 경고를 보냅니다. 130MB / 32k-라인 세션에서 테스트한 결과, 41개의 Recall 히트가 나타났으나 소비된 것은 0개였습니다.

거버넌스 플랜(Governance Plan)은 템플릿 없이 확장 가능

v1.1.0에는 두 개의 파일로 내보내진 레지스트리(registry)를 읽는 새로운 governance_plan MCP 도구가 포함되어 있습니다: agents_capabilities.json(각 실행기(executor)가 수행할 수 있다고 선언한 내용) 및 anchor_packs_phases.json(도메인별 단계의 DAG). 각 단계에 대해 V7은 역량 점수(역량 일치 +10, 도메인 일치 +5, 앵커 팩 일치 +3)에 따라 실행기의 순위를 매기고, 가장 높은 점수를 받은 실행기를 선택하여 depends_on_phase_ids가 포함된 큐(queue) 파일을 생성합니다. marketing/dev-tools 및 caishen-finance/audit 도메인에서 검증되었습니다. 새로운 도메인을 추가하려면 각 레지스트리에 행을 하나 추가하기만 하면 되며, V7 소스 코드는 변경할 필요가 없습니다.

평가 수치(Eval Numbers) 변동 없음

평가 수치(Eval numbers)는 2026-05-08 기준으로 고정되어 있습니다: LongMemEval-S 56.6% (n=500), EverMemBench-Dynamic Run 1 44.4% (n=500), Run 2 47.3% (n=497), drift detector ROC AUC 0.83, end-to-end 재현 비용 $3.50. v1.1.0은 평가 수치를 변경하지 않습니다. 대신 소비 수치(consumption numbers), 즉 회상 히트(recall hits)의 본문이 에이전트의 작업 컨텍스트(working context)에 실제로 안착하는 비율을 개선합니다.

주목해야 할 점

회상 소비 비율(recall consumption ratio)에 대한 깔끔한 벤치마크를 주목하십시오. 이 프로젝트는 명시적으로 제안을 요청하고 있습니다. 만약 채택률이 높아진다면, 향후 90일 이내에 경쟁 에이전트 메모리 시스템(Zep, MemOS)에서 유사한 소비 감사(consumption-audit) 기능을 찾아보시기 바랍니다.

출처: dev.to

원문은 gentic.news에 게시되었습니다.