질문
8월에 158종으로 접은 개인 메모리 뱅크 태그가
한 달 남짓 만에 389종으로 불어났다.
늘어난 태그 대부분은 정상 주제어였고
실제 피해는 접두를 잘못 찾아간 태그와 kind가 빠진 기억이었다.
태그를 다시 접을지, 쓰는 시점에 서버가 고치게 할지가 갈림길이었다.
나는 후자가 맞다고 판정한다. 2주 재측정에서 새 문서의 문제 유형 태그는 0건이었다.
이 뱅크는 여러 코딩 에이전트가 게이트웨이 Hindsight-Crew를 거쳐
기억을 저장하는 곳이다.
기억마다 project kind topic user 네 접두의 태그를 달고
kind는 결정·발견·운영처럼 기억의 종류를 적는 접두다.
8월 대청소와 별칭 맵의 경위는
태그 어휘를 158종으로 접은 기록에 있다.
판정
막았다.
기준선 뒤 새로 생긴 문서 387건에서
합쳐진 태그, 칸 오배정, user 분열이 모두 0건이었고 kind 누락도 0건이었다.
합격 규칙은 측정 전에 코드로 고정해 둔 그대로다.
해법은 두 갈래였다.
쓰는 시점에는 게이트웨이가 붙어 온 태그를 쪼개고
접두 없는 낱말과 접두를 잘못 찾은 태그를 선언된 어휘로 고치며
kind가 없는 기억은 거부한다.
이미 쌓인 문제 태그는 같은 규칙으로 120문서를 재태깅했다.
핵심 판단은 닫을 접두와 열어 둘 접두을 가른 일이다.
kind와 user만 닫힌 목록으로 두고 project와 topic은 새 값을 받는다.
설계 이슈에 적어 둔 이유는 하나다.
정상 주제어가 대부분이므로, 새 값을 거부하면 retain 실패만 늘어난다.
같은 이유로 "태그 총수가 늘지 않음"이라는 완료 기준은 버렸다.
주제어가 열려 있으면 어떤 방식으로도 통과할 수 없는 기준이다.
0건은 에이전트들이 태그를 바르게 보냈다는 기록이 아니다.
틀리게 보낸 태그 일부를 서버가 고쳐 저장한 결과가 섞여 있다는 뜻이다.
기준선 뒤 14일 동안 retain 401줄 중 37줄이 쓰는 시점에 고쳐져 저장됐다.
근거
| 주장 | 실측 | 측정 조건 |
|---|---|---|
| 대청소 뒤 피해는 총수보다 유형이었다 | 합쳐진 slug 3문서, 칸 오배정 53문서(태그 70건), user 분열 10문서, kind 누락 43문서 | 대청소 이후 문서 1,163건, 10월 1일 새벽, 새 규칙 코드로 저장 태그 재평가 |
| 쓰는 시점 규칙이 운영에서 동작했다 | 쉼표로 이은 태그 문자열이 3개로 분리 저장, gotcha가 kind:gotcha로 저장, kind 없는 retain은 422 RULE:tags-missing-prefix 거부 | 10월 1일 배포 직후 운영 라이브 샘플 셋 |
| 재태깅이 쌓인 문제를 비웠다 | 120문서 적용, 미해결 0. 기준선 이전 1,763건에서 세 유형과 kind 누락 모두 0문서 | 10월 15일 내보내기를 같은 측정 명령으로 재측정 |
| 새 문서도 깨끗했다 | 387건에서 세 유형 0건, kind 누락 0건 | 기준선 이후, 10월 16일 02:09 KST 내보내기, 사전 고정 규칙 |
| 깨끗함의 일부는 서버 교정이다 | 401줄 중 37줄 교정 저장(별칭 31줄, 칸 교정 6줄), 태그 규칙 거부 3건 | 기준선 이후 14일 감사 로그, retain 호출 단위라 새 문서 수와 다른 단위 |
| 참고값 | project 없는 문서 51건(13.2%), 재태깅 직후 전체는 117건(6.6%) | 판정 기준 밖 |
APPLY complete=120 already=0 drift=0 missing=0 skipped_checkpoint=0 planned=120 unresolved_untouched=0
2026-10-16T02:09:43.321448+09:00 PASS재태깅은 dry-run 단계에서 한 번 멈췄다.
기본안은 88문서를 고치고 32문서를 미해결로 남겼고
기억 앞머리 라벨 표를 19항목 넓힌 안은 118문서를 고치고 2문서를 남겼다.
나는 넓힌 안을 고르고 라벨 디자인을 kind:decision으로 두게 했다.
최종 적용은 120문서, 미해결 0이었다.
합격 규칙은 재태깅 직후 점검 스크립트에 고정했다.
새 문서가 있고, 세 유형의 문서 수가 모두 0이며, kind 누락이 0일 때만 통과로 본다.
재측정 이슈에 적힌 제약 문구는 이렇다.
"절대 판정 뒤 기준을 풀어 통과로 바꾸지 않는다 - 판정 규칙은 사전에 고정한다."
kind 목록도 관찰 기간에는 손대지 않았고
통과한 뒤에야 reference를 더해 27종으로 늘렸다.
서버가 고친 37줄은 대부분 별칭이었다.
kind:finding을 kind:discovery로 바꾼 것이 26줄이고
topic:ops를 kind:ops로 옮긴 칸 교정이 3줄이다.
태그 규칙 위반으로 거부된 retain은 3건뿐이었다.
기각한 접근은 넷이고, 그중 총수 기준은 위에 적었다.
별칭만 늘리는 방식은 이미 아는 동의어만 막기 때문에 태그가 다시 흩어진다.
접두별 허용 목록을 전면에 걸면 정상 주제어 약 180종이 거부된다.
칸 오배정을 항상 고치면 다른 프로젝트의 기억이 섞인다.
그래서 project로 옮기는 교정은
그 기억에 project가 없고 후보가 정확히 하나일 때만 한다.
한계·재검토 트리거
이 판정은 2주짜리 측정 한 번에 근거한다.
10월 15일 아침의 자동 재측정은 맥이 잠자기 상태에서 잠깐 깨어난 사이에 실행됐고
Wi-Fi가 연결되기 전이라 보고 단계와 알림이 DNS 오류로 함께 실패했다.
판정은 다음 날 새벽 수동 실행으로 났다.
그 뒤 점검 예약을 해제해서 10월 20일 기준으로 다시 잴 예약은 없다.
project는 필수 접두가 아니어서 project 없는 문서도 저장된다.
그 비율이 재태깅 직후 6.6%에서 새 문서 13.2%로 올랐다.
태그 종류 수는 보고마다 389, 405, 407, 388로 달랐고
판정에는 쓰지 않았다.
2026-10 기준 / 재검토 트리거: 같은 측정 명령으로 다시 잰 새 문서에서
문제 유형 태그나 kind 누락이 1건이라도 나오거나,
project 없는 새 문서 비율이 13.2%를 넘을 때