앞선 두 글에서는 GitHub-first 방식의 도구 간 인계와 Local-first / GitHub-first의 데이터·실행 경계를 다뤘다. 이제 남은 질문은 저장소에 엔지니어링 맥락이 남아 있을 때 별도의 Agent Memory가 무엇을 더해 주느냐는 것이다.

먼저 결론부터 말하면, 코딩 속도가 빨라질 거라는 기대만으로 독립 메모리 계층을 추가하지는 말자. Agent가 README, AGENTS.md, Makefile과 테스트에서 추론할 수 있는 규칙은 그곳에 둔다. 별도 메모리는 현재 저장소만으로 알 수 없는 과거 의사결정에 한해 검토할 만하다. 이번 세 차례 실험에서 Harness를 넘는 메모리 읽기는 실제로 발생했지만, 소비 작업의 독립 검수 결과는 나아지지 않았다.

저장소가 이미 답을 알고 있다면 메모리의 공으로 돌리지 말자

1차 실험은 macOS arm64의 Local endpoint에서 Beacon 1.3.46(build f8177a68)과 Codex CLI 0.162.1로 진행했다. 합성 프로젝트에는 API 정의, 생성 코드가 저장소에 들어 있다는 README, Makefile 대상, 일관성을 확인하는 테스트가 있었다.

처음에는 메모리 없는 대조군 A0가 실패하고 Beacon 경로는 테스트 3/3을 통과한 것처럼 보였다. 하지만 사후 점검에서 A0가 파일을 수정할 수 없는 읽기 전용 샌드박스에서 실행됐고, 첫 라운드 오류 출력에는 make gen 힌트까지 노출된 사실을 확인했다. 유효하지 않은 대조군과 힌트 유출은 메모리 효과의 증거가 아니다.

2차 실험에서는 샌드박스를 쓰기 가능하게 바꾸고 힌트 유출을 막았다. 메모리 없는 A0는 README, Makefile, 테스트를 읽고 생성 규칙을 추론해 1/1 테스트를 통과했다. 나는 “메모리가 저장소 규칙 재사용을 유발했다”는 주장을 지웠다. 저장소에 답이 적혀 있다면 Memory의 공으로 돌리는 건 과장이다.

실험	관찰 결과	말할 수 있는 범위
1차 A0 / Beacon	A0의 읽기 전용 샌드박스는 무효. Beacon 후보는 승인 후 Skill로 물화되고 새 세션에서 읽힌 뒤 3/3 통과	메모리의 인과 효과를 추론할 수 없음
2차 A0, 메모리 없음	저장소에서 규칙을 추론해 1/1 통과	이 작업은 저장소 정보만으로 가능
수동 Checkpoint	CHECKPOINT.md를 읽고 2/2 통과	명시적이고 Git으로 검토 가능한 인계도 작동함. 공정한 속도 비교는 없음
3차 TRAIN	TSV 공개 테스트 3/3 PASS, 컨트롤러 숨은 검사 PASS	자동 증류나 크로스 Harness 재사용 성공을 뜻하지 않음
3차 소비 그룹	Antigravity A0와 MCP 모두 CSV 공개 테스트 3/3 PASS, 숨은 검사는 모두 FAIL	메모리 읽기는 발생했지만 작업 개선은 입증되지 않음

각 라운드는 서로 다른 합성 fixture를 사용했으므로 1/1, 2/2, 3/3, 4/4를 하나의 누적 테스트 묶음처럼 비교하면 안 된다.

Checkpoint와 Agent Memory는 역할이 다르다

수동 Checkpoint와 Beacon 경로의 시간이나 Token을 같은 기준으로 측정하지 않았고, 수정 절차도 달랐다. 사후에 비교 가능한 숫자를 만들어 내면 정밀해 보이는 허위 수치가 된다.

차이는 분명하다. Checkpoint는 Git을 따라 이동하고 검토할 수 있는 명시적 인계서다. Agent Memory는 자동으로 쌓이는 노트에 가깝다. 노트는 과거 결정의 배경을 보존하지만 오래된 판단까지 남길 수 있다.

지식	우선 저장 위치	별도 메모리가 필요한가?
현재 제약, 빌드 단계, 불변 조건	README, AGENTS.md, Makefile, 테스트	대개 불필요. 저장소가 기준이어야 함
진행 상황, 검증된 SHA, 차단 요소, 다음 단계	Issue, PR, Checkpoint, CI 기록	세션 간 복구에 실제 공백이 있을 때만
저장소에 없는 과거 의사결정	검토 가능한 결정 기록 또는 승인된 메모리	출처와 적용 범위를 붙인다면 고려 가능
변경된 규칙과 임시 예외	현재 저장소 사실을 갱신하고 이전 규칙 폐기	메모리만 계속 덧붙이면 안 됨
데이터 경계를 넘으면 안 되는 맥락	승인된 로컬 경계 안에 유지	기억하려고 클라우드에 복사하지 말 것

3차 실험: 메모리는 읽었지만 작업은 실패했다

이번에는 저장소만으로 추론하기 어려운 과거 호환성 규칙을 테스트했다. CSV와 TSV 출력에서 Python None은 문자 그대로 \N으로 직렬화하고, 빈 문자열은 빈 필드로, 문자열 NULL은 그대로 유지해야 한다는 규칙이다.

Codex 학습 트레이스에서 후보를 만들고 검토·승인해 물화했다. 이후 Antigravity는 Beacon Local MCP를 통해 승인된 메모리를 읽었다. 로컬 실행 요약에는 get_memory 한 번과 search_memory 두 번이 기록돼 있다. 이는 이번 실행에서 읽기가 발생했다는 뜻이지, 올바르게 재사용했다는 뜻은 아니다.

Antigravity 소비 그룹	메모리 읽기	공개 CSV 테스트	독립 숨은 검사
A0, 메모리 없음	아니요	3/3 PASS	FAIL
MCP, 메모리 있음	예	3/3 PASS	FAIL

핵심 단서는 적용 범위의 불일치다. 메모리 본문은 CSV와 TSV를 모두 언급하지만 applicability 메타데이터는 render_tsv / TSV 호환성만 지정한다. 실행 요약에 따르면 Antigravity는 두 내보내기 함수를 별도 구현으로 보고 TSV 범위의 규칙을 CSV에 적용하지 않았다.

유력한 설명이지만 근본 원인이 확정된 것은 아니다. 숨은 검사기는 전체 FAIL만 반환했고 어떤 assertion이 실패했는지 알려주지 않았다. 두 소비 그룹이 모두 실패했으므로 메모리가 결과를 악화했다고 말할 수도 없다. 그룹당 합성 작업은 한 번뿐이며 기반 모델 설정도 통제 비교로 기록되지 않았다.

실패를 본 뒤 사람이 적용 범위를 넓혀 PASS가 나올 때까지 조정한다면, 측정 대상은 자연스러운 과거 기억 재사용이 아니라 내가 답을 보고 메모리를 튜닝하는 능력이 된다. 그래서 억지로 성공 결말을 만들지 않고 실험을 멈췄다.

오래된 메모리, 로컬 로그, 소스 경계

별도 fixture에서는 Makefile 대상을 gen에서 generate로 바꿨지만 예전 Skill은 여전히 make gen을 지시했다. Agent는 오류를 만난 뒤 Makefile을 다시 읽고 make generate로 바꿔 4/4 테스트를 통과했다. 이전 Skill은 그대로 남아 있었다. 이는 Agent가 현재 저장소를 확인해 복구할 수 있음을 보여줄 뿐, Beacon이 오래된 메모리를 자동 갱신하거나 폐기했다는 증거는 아니다.

Local runtime 로그에서는 합성 마커 PLUMOTTER9917이 그대로 나타났고 일치 행은 7개에서 25개로 늘었다. Token처럼 보이는 canary sk-canaryfake는 0에서 4, REDACTED는 1에서 6으로 바뀌었다. 하지만 그 네 행의 내용을 확인하지 않아 테스트 값인지, 남은 접두사인지, 로그에 기록된 검색·테스트 문자열인지 알 수 없다. 마스킹 결과는 미확정이다. Beacon Cloud에는 연결하지 않았으므로 로컬 로그는 클라우드 전송의 증거가 아니다.

소스 점검은 Beacon commit d7a3a72에 고정했다. 마스킹 구현은 필드명과 알려진 패턴에 의존하며 모든 자연어 비밀을 알아서 찾는 기능은 아니다. 고정된 소스 스냅샷의 Codex 수집 매트릭스와 OTLP 변환 코드에서는 Codex File/MCP 이벤트 매핑을 찾지 못했다. 이는 소스 점검이지 실행 중 패킷 캡처가 아니다. Jev 평가기도 소스만 확인했고 실행하지 않았으므로 점수나 증류 정확도 측정치는 없다.

메모리는 저장소의 빈틈을 채워야 한다

이번 실험은 Agent Memory가 전반적으로 효과적이라고도, 쓸모없다고도 증명하지 않는다. 현재 검증 가능한 사실은 저장소에 두고, 명시적 인계에는 Checkpoint를 쓰며, 저장소에서 알 수 없는 과거 결정만 출처와 범위를 붙여 독립 메모리에 남기는 것이 합리적이다. 오래되거나 충돌하는 메모리는 발견·제한·폐기할 수 있어야 한다. 로컬 로그, MCP, 호스팅 평가, 클라우드 전달은 각각 따로 검증해야 한다.

결론은 간단하다. 크로스 Harness 읽기는 확인됐지만 추가 작업 효과는 입증되지 않았다. 다음 실험은 실패를 본 뒤 메타데이터를 손보는 대신 숨은 assertion을 공개하고 재현 가능한 통제 작업으로 검증해야 한다.

실험 날짜: 1·2차는 2026년 10월 26일, Antigravity MCP 소비자 실험은 2026년 10월 27일.