자산 저장소를 제목으로 그룹화했더니 "중복"이 30그룹 나왔다. 콘텐츠 해시로 다시 판정하자 그중 24그룹이 녹아 없어졌다. 진짜는 5개. 남은 1그룹은 판정 불능 — 행의 내용이 비어 있었기 때문이다.
대상은 여러 플랫폼에서 수집한 AI 에이전트 자산(대화·스킬·메모리·지침 파일) 저장소. 2026-08-19에 수행한 라이브 감사의 숫자다.
30그룹은 제목 완전 일치에서 나왔다. 후보를 "찾는" 방법으로는 나쁘지 않다. "결정하는" 방법으로는 최악이다. 각 그룹은 대신 네 가지 축으로 판정했다.
30그룹의 실제 내역은 이랬다.
동일 콘텐츠가 두 번 들어 있었다. 원인은 전부 심심하다. 같은 자산이 언더스코어 슬러그와 하이픈 슬러그로 이중 등록. 같은 메모리가 영문 키와 현지화 키로 두 번 저장. 진짜 중복은 지루하다 — 그리고 그게 핵심이다. 안전하게 접어도 되는 것은 지루한 행뿐이다.
같은 제목의 대화 두 건, 생성 간격 45일, 본문 유사도 8%. 213KB 스레드와 27KB 스레드가 이름만 공유한다. 유사도 85%에 간격이 10개월인 쌍도 있었다 — 거의 확실히, 사람이 옛 대화를 붙여넣고 이어 쓴 것이다. 그것은 한 건이 아니라 두 건의 자산이다. 여기를 접으면 이력이 사라진다. 제목 재사용은 사람의 정상 행동이지 손상이 아니다.
파이프라인을 테스트하려고 기록된 합성 자산은 심어 둔 마커만 다르다. 서로 다른 실행에서 나온 두 프로브는 어떤 퍼지 매처에게도 중복으로 보인다. 하지만 실체는 별개의 "이벤트"이고, 접으면 한쪽 실행 기록이 지워진다. 테스트 산출물을 실제 스토리지에 쓰는 시스템이라면, 중복 판정 로직이 프로브의 생김새를 알고 있어야 한다.
가장 기묘한 발견. 본문이 완전히 빈 — 헤더만 있는 행. 실재 자산과 같은 제목인데 내용이 없다. 전부 같은 날 약 8.7분 구간에서 생성됐고, 한 제목에 최대 5카피, 몇 초 간격.
이것은 중복 문제가 아니다. 쓰기 경로 사고의 화석 기록이다. 교훈은 이렇다 — 손에 쥔 유일한 증거가 "부재"라면 분류할 수 없다. 이 행들이 갈 곳은 병합 큐가 아니라 격리다.
완전히 무관한 콘텐츠를 가진 3쌍이 같은 출처 참조를 공유하고 있었다. 출처만 믿고 "이미 수집됨, 건너뜀"을 판정하는 파이프라인이라면 실재 자산을 조용히 떨어뜨렸을 것이다. 발견된 이유는 콘텐츠 해시가 출처 필드와 어긋났기 때문이다. 두 신호가 다투는 것 — 그것이 감사의 존재 이유다.
| 판정 | 그룹 수 | 안전한 처치 |
|---|---|---|
| 진짜 중복(바이트 동일) | 5 | 한쪽을 보관 |
| 동명의 다른 자산 | 6 | 둘 다 유지 |
| 별개의 테스트 프로브 | 7 | 둘 다 유지·프로브 태그 |
| 내용이 빈 행 | 4(12행) | 격리 후 쓰기 측 조사 |
| 출처 참조 충돌 | 3쌍 | 소스에서 재검증 |
중복으로 보인 것의 8할은 중복이 아니었다. 역도 성립한다 — 제목 기준으로 "중복 제로"인 저장소가 다른 이름의 동일 콘텐츠로 가득할 수 있다. 두 오류의 뿌리는 같다. 가장 싼 키로 동일성을 판정한 것이다.
*untactit — AI 에이전트의 스킬·지침·메모리를 일원 관리하는 기반(프리런치) — 의 개발 메모입니다. 플랫폼 횡단 자산 동일성이 바로 본업이라, 콘텐츠 해시 + 출처 + 되읽기 검증으로 판정하고 제목 단독으로는 결코 판정하지 않습니다.*