동기화 대장은 조용히 망가진다. 데이터베이스는 763건이라고 말하고 있었다. 그 말을 믿는 것을 그만두고, 21개 AI 플랫폼에 브라우저로 직접 들어가 각 플랫폼 자신의 API를 페이지 안에서 호출해 ID 단위로 대조했더니, 실재하는 것은 약 400건이었다.
그 간극의 감사 기록이다. 숫자는 2026-08-18에 실제 계정에서 측정한 것이고, 가정은 하나도 없다.
대상은 실사용 계정에서 수집한 AI 에이전트 자산 — 대화·프로젝트·스킬·지침 파일·메모리 — 의 대장 763행. Claude, ChatGPT, Gemini, Grok, Perplexity, Kimi, Qwen 등 21개 플랫폼.
검증 방법이 도구보다 중요하니 먼저 적는다.
fetch(credentials: 'include')로 그 플랫폼 자신의 목록 API를 호출한다. 페이지네이션은 끝까지 돈다건수가 일치해도 내용은 다른 목록일 수 있다. 무엇이 실제로 있는지 알려주는 것은 ID 차분뿐이다.
763과 400의 차이는 버그 하나가 아니었다. 독립된 세 가지 고장 모드였고, 어느 쪽이든 대시보드에서는 건강해 보인다.
| 고장 모드 | 무슨 일이 일어나는가 | 확인된 행수 |
|---|---|---|
| 유령 | 플랫폼에서 지워진 것이 DB에 계속 남는다 | 최소 173 |
| 수집 누락 | 실재하는데 DB에 들어오지 않았다 | 최소 63 |
| 오탐 | 모두에게 제공되는 기본물·예시문을 사용자 자산으로 계상 | 최소 109 |
구조에 주목해야 한다. 유령과 오탐은 대장을 부풀리고, 누락은 줄인다. 부분적으로 상쇄된다. 즉 합계 건수는 세 가지 고장을 전부 숨기는 것이 보장된 유일한 지표다.
페이지 크기 상한이 건수가 되어 있었다. 한 플랫폼의 스킬 칸은 대장에서 100건. 사용자가 실제로 설치한 것은 4건이었다. 나머지 96은 전체 사용자에게 보여주는 공용 카탈로그였고, 100이라는 숫자 자체가 목록 API의 page_size 상한이 그대로 계정의 사실처럼 기록된 것이었다.
설정 화면의 예시문이 메모리로 저장돼 있었다. 실제로는 저장 정보가 8건 있는데 수집기는 8건을 전부 놓쳤고, 대신 설정 화면의 플레이스홀더("예: ~" 두 줄)를 사용자 데이터로 담았다. 대시보드만 보면 이 셀은 잘 되는 쪽으로 보였다.
처음부터 존재하지 않는 파일이 42행. 로컬 룰 디렉터리를 가리키는 지침 파일 42행의 참조 경로가 이 기계에 아예 없었다. 삭제된 것이 아니다. 한 번도 존재한 적이 없다. 그런데도 수집기는 42행을 썼다.
이 모든 행이 성공을 보고한 작업에 의해 쓰였다. 여기가 본론이다.
수집기 개선이 아니다. 되읽기 감사(read-back audit)를 일급 작업으로 만드는 것이다. 동기화 후에 대상을 다시 읽어 ID를 양방향으로 diff한다. "플랫폼이 모두에게 배포하는 기본물"을 매처가 알아야 하는 범주로 다룬다. 그리고 한 번이 아니라 스케줄로 돌린다.
여러 도구에서 에이전트를 운용하고 있다면 한번 세어 보길 권한다. 플랫폼 하나를 골라 대장의 주장을 적어 두고, 그 플랫폼 자신의 API를 마지막 페이지까지 넘겨 본다. 첫 diff는 대개 10분이면 나오고, 비어 있는 경우는 드물다.
*이 감사는 untactit — AI 에이전트의 스킬·지침·메모리를 일원 관리하는 기반(프리런치) — 의 개발 과정에서 수행한 것입니다. 여기 적은 되읽기 검증은 그대로 제품의 설계 원칙이 되었습니다. 배포처를 다시 읽지 않는 배포가 곧 대장이 썩는 경로이기 때문입니다.*