한 뱅크에 37일 동안 기록이 759번 들어갔다.
그 기록을 넣은 손은 하나가 아니었다.
같은 게이트웨이를 지나 같은 뱅크에 쓰는 런타임이 다섯이고, 뱅크 상태를 검증하는 작업은 그 다섯 사이에 끼어 선다.
문제
메모리 상태를 검증하는 절차는 대개 세 단계다. 기준선을 잡고, 무언가를 시키고, 다시 재서 차이를 본다.
이 절차는 "내 작업 에이전트가 쓰지 않았으니 아무 쓰기도 없었다"를 조용히 전제한다.
Claude Code와 Codex를 포함한 다섯 런타임이 같은 게이트웨이를 통과하는 환경에서 그 전제는 서지 않는다.
다른 세션의 정상 기록은 기준선과 재측정 사이 어디에든 들어온다.
14:02 기준선을 캡처한다.
14:05 다른 세션이 정상 기록을 하나 남긴다.
14:07 통합이 돌고 정신 모델이 자동으로 갱신된다.
14:09 다시 잰다. 유닛이 늘었고 모델 상태가 전진해 있다.
14:09 검증은 여기서 게이트 실패를 보고한다. 실패한 것은 없다.어긋남을 만든 것은 기준선과 재측정 사이의 시간이다.
쓰는 쪽과 읽는 쪽이 같은 자원을 두고 부딪히는데 막을 지점이 없다는 점에서, 자작 메모리 시절의 상처와 계보가 닿는다.
어긋남은 세 곳에서 조용히 생긴다
쌓인 유닛 2,134건 가운데 1,369건이 관측 유닛이다. 이 기록들은 다른 기록에서 나온 파생물이라 직접 고칠 수 없다.
지우려면 원본 기록을 지목해야 한다. 파생물 자신의 식별자를 넣으면 요청은 성공으로 돌아오고 아무것도 지워지지 않는다.
검증이 "지웠는데 그대로 있다"고 보고하는 순간의 실체가 이것이다.
조회에도 같은 종류의 침묵이 있다. 기본 응답 예산은 4,096토큰이고 결과 목록은 그 선에서 잘린다.
특정 기록이 닿는지 확인하려는 검증에서 순위가 깊은 히트는 목록 밖으로 밀린다.
예산을 올리기 전까지 그 기록은 없는 것처럼 보인다.
세 번째는 데이터 자체가 만든 착시다. 옛 태그를 가진 여섯 행이 청소 누락으로 보였지만 마이그레이션이 의도적으로 남긴 보고 전용 아카이브였다.
재는 동안에는 쓰지 않는다
첫 규율은 계측하는 쪽에 건다. 뱅크나 정신 모델 상태를 재는 동안 검증용 프로브 기록이나 계획에 없는 기록을 만들지 않는다.
새 기록은 언제나 게이트웨이의 정식 경로로 남기고 데이터베이스 직접 쓰기는 금지다.
프로브 한 건은 기록 한 줄로 끝나지 않는다. 통합과 자동 갱신을 태우고 정신 모델을 전진시킨다.
재려던 상태를 재는 행위 자체가 밀어 놓는다.
두 번째 규율은 판정하는 쪽에 건다. 다른 세션의 정상 기록은 실패도 롤백 사유도 아니다.
태그와 시각과 연산 영수증으로 귀속을 먼저 가린 다음에 그 게이트를 판정한다.
이 단계를 건너뛰면 남의 정상 작업이 내 검증의 붉은 등이 된다.
기준선을 다시 잡는 순서
귀속 결과가 나오면 다음 순서로 돈다.
- 새 기록은 게이트웨이의 정식 경로로만 남긴다.
- 기준선 이후 들어온 쓰기를 태그와 시각과 연산 영수증으로 귀속한다.
- 검증 범위와 겹치지 않으면 잡아 둔 기준선 그대로 게이트를 판정한다.
- 겹치면 통합과 자동 갱신이 종단 상태에 이를 때까지 기다린다.
- 새 기준선을 캡처하고 영향받은 검사만 다시 돌린다.
전부 다시 돌리지 않는 것이 5번의 요점이다. 검증 게이트는 아홉 개고 그중 뱅크 상태를 읽는 것은 일부다.
겹친 범위와 무관한 게이트까지 재실행하면 창은 그만큼 더 넓어지고 그 사이에 또 다른 쓰기가 들어온다.
완료 기록에도 순서가 있다. 작업을 끝내며 남기는 기록이 검증 범위와 진짜로 겹치면 최종 상태를 잡기 전에 먼저 남기고, 그로 인한 갱신을 흘려보낸 뒤 영향받은 최종 검사를 다시 통과한다.
겹치지 않는 다른 프로젝트의 기록이면 최종 게이트를 통과한 뒤에 남겨도 된다.
재검증을 피하려고 태그를 거짓으로 붙이는 것만은 금지다.
세마포어는 이 규율을 대체하지 못한다
기각한 대안이 하나 있다. 뱅크마다 요청 세마포어를 두어 쓰기를 직렬화하는 방안이다.
세마포어는 동시 진입을 막는다. 기준선을 잡은 뒤에 정당하게 들어온 쓰기가 그 기준선을 무효화하는 것은 막지 못한다.
줄을 세워도 두 번째 쓰기는 여전히 들어오고, 순서가 정해졌다는 사실이 이미 전진한 상태를 되돌려 주지는 않는다.
이건 동시성 문제가 아니다. 시간 창의 문제라는 뜻이다.
이 판단은 규율을 등재한 커밋 메시지에 제약과 기각 사유로 함께 적혀 있다.
무엇을 골랐는지보다 무엇을 버렸는지가 나중에 더 자주 필요해진다.
결론
이 규율은 운영 문서에 적혀 있고, 다섯 런타임이 공유하는 에이전트 지침 파일에도 상시 규율로 실려 있다.
지침 실물은 한 개이고 나머지 경로는 심링크다. 한 곳을 고치면 다섯 런타임의 규범이 동시에 바뀐다.
검증 절차를 자기 계획서에만 적어 두면 그 계획을 읽지 않는 네 개의 런타임이 남는다.
공유 뱅크에서 검증의 신뢰도는 쓰기를 막는 힘이 아니라 쓰기를 귀속하는 힘에서 나온다.
한계·재검토 트리거
2026-09 기준 / 재검토 트리거: 게이트웨이가 기준선 캡처 이후의 쓰기를 스스로 표시해 검증 절차에 넘겨주게 되거나, 한 뱅크에 동시에 붙는 런타임이 다섯을 넘어 귀속만으로 창을 닫지 못하는 사례가 관측되면 이 절차를 다시 연다.
참고
- 지침을 메모리로 쓰다 실패한 기록 - 쓰는 쪽과 읽는 쪽을 막을 지점이 없던 자작 시절