28시간 동안 4개의 Claude Code 대화(Dialogs)를 실행했습니다. 메모리 레이어(Memory Layer)가 포착한 것(그리고

요약 (TL;DR)

2026년 5월 30일과 31일에 걸쳐 28시간 동안, 저는 공유 파일 시스템 매개 프로토콜(filesystem-mediated protocol) 상에서 4개의 Claude Code 대화(dialogs)를 동시에 실행했습니다. 이들은 계약을 협상하고, 결과를 게시하며, 서로의 실수를 잡아냈습니다. 여기에는 "22/22 테스트 통과"라는 인계(handoff) 주장 중 하나가 포함되었는데, 이 글을 작성하며 1줄의 수정 사항을 반영하기 전까지는 실제로는 11/22가 깨져 있는 상태였습니다.

이것이 현장 로그(field log)의 모습입니다. 폐쇄형 파이프라인(closed pipelines)의 벤치마크 수치만이 아닌, 구체적인 오픈 소스(OSS) 멀티 에이전트 신뢰성 데이터를 발표하는 것을 본 적이 없기에 이를 공유합니다.

리포지토리(Repo): github.com/chunxiaoxx/nautilus-compass
· 7가지 패턴이 모두 포함된 전체 사례 연구(case study):
docs/case_study_4dialog_compass.md.

왜 4개의 대화인가

각 Claude Code 세션은 고유의 현재 작업 디렉토리(cwd), git 리포지토리(repo), 그리고 메모리(memory) 디렉토리를 가집니다. 제가 사용한 것은 다음과 같습니다:

compass — 메모리 레이어(memory layer) + 드리프트 탐지(drift detection) + 대화 간 계약 스캐너(cross-dialog contract scanner)
Soul — PR을 제출하고 NAU(플랫폼의 평판 토큰)를 획득하는 자율 엔진(autonomous engine)
V5 — 작업을 공급하고 가격을 책정함
nautilus-core — 전략적 앵커(strategic anchors)와 안티 패턴(anti-patterns)을 유지함

이들은 한 명의 인간 운영자(저)를 공유하지만, 그 외에는 오직 세 가지 파일 시스템 채널을 통해서만 통신합니다:

마크다운(Markdown) 파일 (session_*.md, feedback_*.md, inbound_*.md, outbound_*.md)
계약 프론트매터(Contract frontmatter) 블록 (제공자, 수신자, 마감일, 인도물, 상태)
쿼리 임베딩(query embedding) + 계약 ID(contract ID)에 의해 일치하는 대화의 프롬프트(prompt)에 해당 파일들을 노출시키는 리콜 훅(recall hook)

웹훅(webhooks)은 없습니다. 이벤트 버스(event bus)도 없습니다. 공유 API도 없습니다. 오직 파일 시스템(filesystem)과 스캐너(scanner)뿐입니다.

수치

28시간의 시간 범위 동안 발생한 사항은 다음과 같습니다:

측정 항목	기간	값
drift fires (세션 텍스트에서 자동 감지)	7d	314
...

7d(9.87%)와 24h(40.79%) 사이의 격차는 하나의 훅(hook) 배포(ship)에 관한 이야기입니다. PDT 기준 5월 30일 14:26 이전에는 드리프트 감지(drift detection)가 오픈 루프(open loop)였습니다. 즉, 경고를 읽는 자동화된 프로세스가 아무것도 없었습니다. 24h 체제는 클로즈드 루프(closed loop)를 반영합니다. 7d 수치는 여전히 오픈 루프의 잔여 데이터(tail)에 의해 희석된 상태입니다.

이것이 중요한 이유는, 그보다 사흘 전 제가 "드리프트 루프는 오픈 상태입니다: 감지는 25,000번 측정했지만 개입은 0번이었습니다"라는 제목의 사후 분석(postmortem) 글을 썼기 때문입니다. 5/27의 발견이 5/30의 첫 번째 측정된 클로즈드 루프로 이어졌습니다. 이것이 바로 제가 오픈 소스 소프트웨어(OSS) 멀티 에이전트(multi-agent) 분야의 모든 이들이 보길 원하는 배포 주기(shipping cadence)입니다. 왜냐하면 감지(detection), 개입(intervention), 그리고 개입이 효과가 있었는지에 대한 테스트를 동일한 사람이 모두 담당할 때 실제로 달성 가능한 주기이기 때문입니다.

17.92시간 만에 체결된 계약

compass-dialog는 Soul이 자신의 자율 사이클(autonomous-cycle) 결과를 compass의 메모리(memory)로 다시 밀어 넣을 수 있는 방법이 필요했습니다. 우리는 이를 계약(contract)을 통해 수행했습니다:

contract:
  id: cnt_compass_soul_sub_a1
  giver: compass-dialog
...

Soul은 자신의 세션 프롬프트-프리(prompt-pre) 블록에서 이를 확인했습니다(compass-dialog가 파일을 작성했고, Soul의 회상 훅(recall hook)이 이를 표면화했습니다). 17.92시간 후, Soul의 세션은 승인(ack), 스키마(schema), 그리고 명시적인 주의 사항(gotchas)이 포함된 인바운드(inbound) 파일을 작성했습니다:

cycle_id는 두 가지 형식이 혼재된 스플릿 브레인(split-brain) 상태임 (초기 행에는 문자열, 이후에는 정수)
fitness_delta는 대부분 NULL임
5/30의 모든 행에서 composite_score가 0.000임 (데이터가 아직 채워지지 않음)
goal_source는 NULL을 포함하여 4가지 가능한 값을 가짐

이러한 선제적인 주의 사항 공개는 수신 에이전트가 (a) 자신의 데이터를 잘 알고, (b) 관계에 이해관계가 있으며, (c) 마감 타이머가 돌아가는 프롬프트 내에서 계약을 확인할 때만 발생합니다. 이 세 가지를 모두 선택하십시오. 파일 시스템(filesystem) 계약은 별도의 오케스트레이션 런타임(orchestration runtime) 없이도 이를 수행합니다.

이 포스트가 포착한 검증 격차(verify-gap)

여기에 메타적인 순간(meta moment)이 있습니다. 5/30 세션을 위한 저의 인수인계(handoff) 문서에는 다음 내용이 포함되어 있었습니다:

Phase 2.I done · I.1 tier_promotion calculator + I.2 driver idempotent
  · 22 tests GREEN

이 글을 쓰면서 저는 그 수치를 인용해야 했습니다. 그래서 스팟 체크(spot-check)를 실행했습니다:

PYTHONPATH=. python -m pytest tests/proof/test_tier_promotion.py \
                              tests/scripts/test_tier_promotion_driver.py -q

11 failed, 11 passed in 0.51s
ModuleNotFoundError: No module named 'scripts.tier_promotion_driver'

22개 중 11개는 어떤 깨끗한 환경(clean environment)에서도 한 번도 그린(GREEN, 통과) 상태로 실행된 적이 없었습니다. 드라이버 모듈 파일(scripts/tier_promotion_driver.py)은 존재했고 커밋(commit)되어 있었지만, scripts/__init__.py가 없어서 Python이 scripts/를 패키지(package)로 취급하지 않았습니다. 테스트의 임포트(import) 라인이 수집(collection) 단계에서 실패한 것입니다. 인수인계 문서의 GREEN이라는 주장은 검증되지 않은 상태였습니다.

해결책:

touch scripts/__init__.py
# 재실행
PYTHONPATH=. python -m pytest ... -q
...

파일 하나, 0바이트, 주장과 발견 사이의 시간은 12시간이었습니다.

이 사례 연구(case study) 커밋은 수정 사항과 포스트를 하나의 변경 사항으로 배포하므로, 인용 자체가 구조적으로 정직합니다. (전체 사례 연구에서 패턴 #f로 나열한) 이 패턴은 다음과 같습니다: 하위 아티팩트(downstream artifact)에서 재사용하기 전에, 작성자가 주장한 지표(metric)를 최소한 하나는 스팟 체크(spot-check)할 것. 테스트 인프라가 갖춰져 있을 때 이는 매우 정교한 방법이며, 과거의 자신이 말한 "X개 통과"라는 거짓말을 잡아낼 수 있는 유일한 메커니즘입니다.

어떤 OSS 멀티 에이전트 스택에도 구축할 7가지 패턴

한 줄 요약과 함께 패턴을 추출합니다 (전체 산문 및 사례 연구 문서의 사건 발생 내용 포함):

a. 교차 대화 계약 프로토콜 (Cross-dialog contract protocol) — 프론트매터(frontmatter) 블록을 프롬프트(prompt)로 스캔하여, 에이전트 간의 $N^2$ 규모의 grep 작업을 $O(N+K)$ 규모의 유향 그래프(directed graph)로 대체합니다.

b. 드리프트 루프 측정 삼각측량 (Drift-loop measurement triad) — 독립적으로 계측된 세 가지 카운터: 탐지(detection), 사용자 CLI 개입(user CLI intervention), 에이전트 자체 확인(agent self-ack). alert_id로 결합됩니다. 목표 act_on_rate는 70% 이상입니다.

c. Plan-dup audit cascade (계획 중복 감사 캐스케이드) — 모든 계획 작업(plan task)은 이전의 기술(skills)/에이전트(agents)/메모리(memory)/잠금(locks)에 대해 인벤토리 체크를 수행합니다. 이번 스프린트에서 13번의 감사가 수행되었으며, 각각 평균 3~4시간을 절약했습니다.

d. Surgical settings.json redirect (정밀한 settings.json 리다이렉트) — 릴리스 엔지니어링 사이클(버전 업그레이드 → 재설치 → 캐시 삭제)을 1줄의 훅(hook) 경로 변경 + sys.path.insert(0, script_dir)로 대체합니다.

e. Impact-based tier promotion (영향도 기반 티어 승격) — 액세스 횟수(access-count) 기반 승격과 병행하여 cumulative_impact (누적 영향도) 델타를 사용합니다. 두 메커니즘의 공존은 의도된 것이며, 이들은 서로 다른 것(수요 vs 결과)을 측정합니다.

f. Honest verify caveat (정직한 검증 주의사항) — 세션 시작 시 하류(downstream)에서 재사용될 주장(claims)을 1~2개씩 무작위 점검(spot-check)합니다. 실제 명령어를 실행하고, 그 결과를 주장과 비교(diff)하십시오. 이 포스트가 그 실시간 예시입니다.

g. Plan refactor align prior framework lock (이전 프레임워크 잠금과 일치하는 계획 리팩토링) — 잠금 파일(lock files)을 참조(references)가 아닌 제약 조건(constraints)으로 명명하십시오. 새로운 계획이 이를 무시할 경우, 병렬로 중복 작업을 배포하기보다 리팩토링을 수행하십시오.

포착하지 못하는 것 (What it doesn't catch)

마찬가지로 중요한 점은 시스템 자체에 존재하는 간극(gaps)입니다.

배포 시 자동 테스트 검증 부재 (No auto-test-verify on ship). 패턴 f가 존재하는 이유는 제가 수동으로 무작위 점검을 했기 때문입니다. 차기 후보 패턴은 세션 종료 시 수정된 파일에 대해 pytest --collect-only를 실행하는 스톱-훅(stop-hook)입니다.
Compass-dialog의 위임 지연 (Compass-dialog slipped a delegation by 10 hours). Nautilus-core 대화(dialog)가 compass-dialog에게 Soul의 NAU 결제 내용을 저에게 노출하도록 요청했으나, 제가 요청을 읽기까지 10시간이 걸렸습니다. 인바운드 스캐너(Inbound scanner)의 조리개(aperture)가 너무 좁습니다.
Drift target ≥70% / 7d 수치가 9.87%임. 24시간 체제는 40.79%이지만, 지난 6일간의 오픈 루프(open-loop) 이력이 윈도우(window)에서 완전히 제외되려면 14일이 걸릴 것입니다. 지속 가능성을 테스트하기 위해 2026년 6월 13일에 재측정하십시오.

성공 사례와 함께 간극을 공개하는 이유는, 이것이 유사한 시스템을 구축하는 다른 사람들에게 유용할 수 있는 유일한 방법이기 때문입니다. 이 패턴들은 이 구성(configuration)에서 작동합니다. 마케팅 문구로서 작동하는 것이 아니라, 시작점으로서 작동할 것입니다.

재현 방법 (How to reproduce)

git clone https://github.com/chunxiaoxx/nautilus-compass
cd nautilus-compass
git checkout v3-full-fusion
...

4개의 대화(dialog) 설정을 위해, Claude Code에 compass 플러그인을 설치하세요:

/plugins marketplace add chunxiaoxx/nautilus-compass
/plugins install nautilus-compass

메시(mesh)에 참여시키고자 하는 각 리포지토리(repo)는 플러그인이 설치된 자체적인 Claude Code 세션이 필요합니다. 계약 스캐너(contract scanner)는 동일한 머신 내의 모든 ~/.claude/projects/*/memory/ 디렉토리에 걸쳐 파일을 찾아냅니다.

제가 요청하는 것

이번 주는 compass를 오픈 소스(OSS) 멀티 에이전트 신뢰성 인프라(multi-agent reliability infrastructure)로 포지셔닝하기 위한 공개적인 추진의 첫 번째 주입니다. 사례 연구(case study), 패턴(patterns), 그리고 발행 주기(publishing cadence)가 그 진입점(wedge)이 될 것입니다.

만약 여러분이 이와 유사한 것 — 즉, 오케스트레이터(orchestrator) 없이 협업이 필요한 여러 에이전트를 실제로 실행하는 것 — 을 구축하고 있다면, 대화를 나누고 싶습니다. GitHub 이슈는 위의 리포지토리에 열려 있습니다. 프로젝트 간 필드 로그(Cross-project field logs)도 환영합니다.

만약 일곱 가지 패턴 중 어느 하나에서 결함을 발견하신다면 — 특히 제가 작동한다고 주장하는 패턴들에서 — 부디 반례(counterexample)를 제출해 주세요. 패턴은 반례를 견뎌내거나, 아니면 사라집니다. 그것이 규칙입니다.

— Chunxiao
nautilus.social · 오픈 에이전트 생태계 (open agent ecosystem)