저는 한 가지 질문을 중심으로 도구를 만들고 있습니다:

당신의 AI 메모리에 있는 오래된 지침 중 더 이상 볼 수 없는 것은 무엇인가요?

제가 이 도구를 위해 작성한 슬로건은 그보다 더 대담합니다. 그것은 다음과 같습니다: 당신의 AI가 준수를 중단해야 할 오래된 지침을 찾아내세요.

이번 주에 저는 그 슬로건을 제품 문구로 취급하는 것을 멈추고 하나의 테스트로 전환했습니다. 저는 감사기(auditor)를 제 자신의 에이전트 메모리(agent memory)로 향하게 했습니다.

그것이 가장 먼저 한 일은 제 자신의 슬로건을 제가 준수를 중단해야 할 오래된 지침으로 탐지(flag)하는 것이었습니다.

그 후, 그것은 동일한 워크스페이스(workspace)에 자리 잡고 있던 실제 오래된 프레이밍(stale framing)을 놓쳤습니다.

저는 그 격차(gap)에 대해 쓰고 싶습니다. 왜냐하면 그것이 제가 아는 이런 종류의 시스템을 구축하는 유일하게 정직한 방법이기 때문입니다: 시스템을 자신에게 적용하고, 무엇이 틀렸는지 공개하며, 할 수 있는 것을 수정하고, 더 깊은 격차는 그대로 드러내 두는 것입니다.

이 문제가 존재하는 이유

에이전트 메모리(Agent memory) 파일은 오래된 코드와 마찬가지로 부패합니다.

임시 예외 사항을 작성하면 그것은 영구적인 것이 됩니다. 방향을 바꾸지만 컨텍스트 파일(context file)에는 이전 계획을 남겨둡니다. 나중에 더 강력한 규칙을 추가하지만, 더 약한 규칙은 여전히 근처에 남아 있습니다. 몇 달이 흐릅니다. 어떤 줄이 행동을 규정해야 하고 어떤 줄이 단순한 기록인지 아무도 기억하지 못합니다.

AI 에이전트(AI agent) 또한 그 차이를 자동으로 알지 못합니다.

이것은 단지 기계의 문제만이 아닙니다. 사람들도 오래전에 전달받아 다시는 읽지 않은 지침들을 간직하고 있습니다. 대부분의 날에는 문제가 되지 않습니다. 그러다 예상치 못한 상황, 즉 대본에서 벗어난 일이 발생하면, 아무도 그것이 만료되었다고 표시하지 않았기 때문에 오래된 규칙이 어쨌든 실행됩니다. 인간이든 기계든 메모리의 진정한 테스트는 저장된 내용을 반복할 수 있는지 여부가 아닙니다. 여전히 유효한 규칙과 조용히 사실이 아니게 된 규칙을 구별할 수 있는지, 그리고 상황이 이전에 보았던 것과 일치하지 않을 때 죽은 규칙을 넘어 추론할 수 있는지 여부입니다. 저장된 응답만을 재생할 수 있는 에이전트는 이해관계가 걸린 실제 상황에서

오래된 노트(stale note)가 관련이 있을 수 있습니다. 현재의 정책(current policy)이 관련이 있을 수 있습니다. 사용자의 선호도(user preference)가 관련이 있을 수 있습니다. 도구 설명(tool description)이 관련이 있을 수 있습니다. 검색(Retrieval)은 이 모든 것을 동시에 컨텍스트(context)로 끌어올 수 있습니다.

하지만 태스크(task)에 부합하는 것과 다음 행동을 결정할 권한을 갖는 것은 같은 의미가 아닙니다.

에이전트가 도구(tools), 고객 데이터(customer data), 자금 이동(money movement), 외부 메시지(external messages), 배포(deployments), 또는 "모델이 관련 메모리를 보았다"라는 사실만으로는 충분하지 않은 그 어떤 것들에 더 가까워질수록, 그 차이는 더욱 중요해집니다.

그래서 저는 지시 사항(instruction) 및 메모리 파일(memory files)을 위한 작은 감사기(auditor)를 구축했습니다. 이것이 안전성을 인증한다고 주장하는 것은 아닙니다. 대신 더 좁은 범위의 작업을 수행합니다:

1. 지시 사항 파일을 감사 가능한 메모리 항목(memory items)으로 분할합니다.
2. 각 항목을 권한(authority)에 따라 분류합니다: 지배 규칙(governing rule), 선검증 규칙(verify-first rule), 컨텍스트 전용(context only), 또는 대체 가능성이 있는 지시 사항(possible superseded instruction).
3. 포함된 위험 패턴(dangerous patterns)을 탐지합니다.
4. 리스크를 검증 게이트(verification gates)로 전환합니다.
5. 어떤 지시 사항이 실제로 행동을 형성하는지 매핑합니다.
6. 사람이 검토할 수 있는 보고서를 작성합니다.

마지막 문장이 중요합니다. 현재의 가치는 "기계가 당신의 AI가 안전하다고 말해주는 것"이 아닙니다. 현재의 가치는 "기계가 구조화된 권한 지도(authority map)를 제공하고 알려진 리스크 패턴을 표시함으로써, 사람이 모든 줄이 동일한 비중을 가진다고 가정하지 않고도 파일을 검토할 수 있게 해주는 것"입니다.

저는 그 정도까지는 구축해 두었습니다.

하지만 아직 살아있는 시스템(living system)에 실제로 적용해 보지는 못했습니다.

그래서 제 시스템에 적용해 보았습니다.

내 에이전트에 감사기를 적용하다

제 작업 공간에는 이 테스트를 위해 가장 중요한 두 개의 파일이 있습니다.

하나는 에이전트가 가장 먼저 읽는 스타트업 파일(startup file)입니다. 이 파일은 컨텍스트를 어떻게 복구할지, 어떤 규칙이 세션을 구속하는지, 무엇을 가정하지 말아야 하는지, 그리고 오래된 메모리를 어떻게 처리할지를 알려줍니다. 다른 하나는 현재 작업, 최근의 결정, 프로젝트 경계, 그리고 활성화된 다음 단계(active next steps)를 추적하는 라이브 상태 파일(live state file)입니다.

이 파일들은 함께 단순한 노트가 아닙니다. 이들은 행동을 지배합니다.

저는 두 파일 모두에 감사기를 실행했습니다.

스타트업 파일에서는 52개의 메모리 항목이 생성되었습니다. 분류기(classifier)는 이를 두 가지 방식으로 나누었습니다:

• 권한별(by authority): 24 governing, 28 context-only
• 유형별(by type): 48 read-shaped, 4 action-shaped

결과적으로 발견된 사항은 없었고(0 findings), 파일의 위험도는 낮음(low observed risk)으로 분류되었습니다. 이 자세(posture)는 도구 자체의 거친 라벨일 뿐, 인증을 의미하는 것은 아닙니다.

실시간 상태 파일(live state file)에서는 538개의 메모리 항목이 생성되었습니다:

• 권한별(by authority): 117 governing, 16 verify-first, 403 context-only
• 21 verification gates
• 2 stale-instruction findings
• 자세(posture): needs review

이 수치들만으로도 충분히 유용합니다. 어떤 발견 사항이 있기 전에도, 권한 지도(authority map)는 제가 머릿속에 편안하게 담아둘 수 없는 무언가, 즉 크고 지저분한 메모리 파일의 어느 부분이 에이전트에게 방향을 제시할 수 있게 허용되는지, 그리고 어느 부분이 단순히 컨텍스트인지를 알려줍니다.

그 지도가 바로 실질적인 결과물입니다. 만약 제가 CLAUDE.md, AGENTS.md, 커서 규칙 파일(Cursor rules file), 또는 내부 에이전트 메모리 파일 등이 긴 팀에 합류한다면, 이 것이 필요할 것입니다. 저는 다음을 알고 싶습니다: 실제로 시스템을 지배하는 것은 무엇인가?

하지만 첫 번째 실행은 깨끗한 결과를 가져오지 않았습니다.

가장 유용한 종류의 결과, 즉 명확하게 보고 배울 수 있는 정직한 실패를 보여주었습니다.

내 슬로건이 플래그 지정되다

첫 번째 실행에서 실시간 상태 파일에 두 개의 오래된 지침(stale instructions)이 플래그 지정되었습니다.

둘 다 오탐지(false positives)였습니다.

그것들은 핵심 브랜드 약속을 담고 있는 문장들이었습니다:

AI가 더 이상 따르지 말아야 할 오래된 지침들을 찾아라.

오래된 지침을 찾는 임무를 가진 도구가 그 임무를 설명하는 문장을 보고, 그 문장 자체가 오래된 지침이라고 판단한 것입니다.

이와 관련된 재미있는 버전의 이야기가 있지만, 기술적인 버전이 더 중요합니다.

탐지기는 표면적 어휘(surface vocabulary)를 증거로 사용하고 있었습니다.

지시 사항이 오래된(stale) 것이 되려면, 권한 이벤트(authority event)의 증거가 있어야 합니다. 즉, 더 새로운 규칙이 이를 대체했거나, 폐기(deprecated)했거나, 범위를 좁혔거나, 모순되거나, 혹은 더 이상 유효하지 않게 만들었어야 합니다. "오래된 지시 사항(old instructions)"이라는 문구 자체만으로는 그 중 어떤 것도 증명할 수 없습니다. 그것은 주제 언급(topic mention)일 뿐, 대체 이벤트(replacement event)가 아닙니다.

텍스트 매칭(Text match)은 해당 문구를 찾아냈습니다. 권한 추론(Authority reasoning)이라면 더 새로운 규칙이 실제로 이를 대체했는지 여부를 물었어야 했습니다.

실패 모델은 간단합니다:

• 입력 문구: "old instructions"
• 탐지기가 본 것: stale 어휘 (stale vocabulary)
• 탐지기가 추론한 것: stale 지시 사항 (stale instruction)
• 누락된 증거: 어떤 새로운 지시 사항이 이것을 대체했는가?

다시 말해, 도구가 특정 범주에 관한 문장과 그 범주의 구성원을 혼동한 것입니다.

제 연구는 계속해서 이 실패를 중심으로 돌고 있습니다. 시스템이 눈에 보이는 신호(visible signal)를 붙잡는 바람에 그 아래에 있는 권한 관계(authority relation)를 놓치고 있다는 점 말입니다.

그리고 진짜를 놓쳤다

두 번째 실패는 더 심각했습니다.

스타트업 파일(startup file)은 발견된 사항이 0건이었습니다. 관찰된 위험도도 낮았습니다.

하지만 저는 그 파일을 알고 있습니다. 그 파일에는 2026년 6월의 수정된 계획에 관한 실제 노트가 포함되어 있으며, 거기에는 우리가 잡아내기 전까지 오래된 프레이밍(framing)이 실제 실행(live execution) 단계로 거의 유출될 뻔했던 내용이 들어 있습니다. 거버닝 메모리 파일(governing memory file)에 여전히 남아 있는 대체된(superseded) 계획은 바로 이 도구가 관심을 가져야 할 전형적인 문제 유형입니다. 그것이 위험했던 이유는 금지된 명령을 담고 있었기 때문이 아닙니다. 에이전트가 여전히 활성 운영 컨텍스트(live operational context)로 취급하는 장소에 오래된 지침을 유지하고 있었기 때문에 위험했던 것입니다.

감사기(auditor)는 이를 놓쳤습니다.

왜일까요?

오래된 프레이밍이 일반적인 산문(prose)으로 설명되어 있었기 때문입니다. "deprecated"나 "old instruction"과 같은 깔끔한 키워드로 라벨이 붙어 있지 않았습니다. 탐지기가 포착할 수 있는 형태인 "이 규칙은 저 규칙에 의해 대체되었습니다"라고 말하지도 않았습니다. 그것은 사람들이 실제로 생각을 밖으로 내뱉을 때 쓰는 방식으로 작성되어 있었는데, 이것이 바로 메모리 파일이 처음에 표류(drift)하게 되는 바로 그 방식입니다.

결국 도구는 한 번의 도그푸딩(dogfood) 실행에서 두 가지 실수를 모두 저질렀습니다:

• 그것은 단어들이 진부해 보인다는 이유로 내 슬로건에 대해 과잉 반응(over-fired)했습니다.
• 그것은 의미가 어휘적으로 표시되지 않았다는 이유로 실제 표류(drift)에 대해서는 과소 반응(under-fired)했습니다.

당신이 인코딩(encode)하려고 생각했던 모든 패턴을 통과하는 탐지기를 만들더라도, 현실 세계가 똑같은 내용을 다른 방식으로 말하는 순간 실패하는 상황을 맞이할 수 있습니다.

저는 제 자신의 연구에서도 이전에 이런 형태를 본 적이 있습니다. 게이트(gate)가 설계된 테스트는 통과하지만, 홀드아웃(held-out) 케이스에서는 실패합니다. 스코어러(scorer)가 구축 기반이 된 샘플에서는 강력해 보이지만, 데이터가 변하면 붕괴합니다. 도구가 문제의 가시적인 버전은 잡아내지만, 산문(prose) 버전은 놓칩니다.

교훈은 "패턴 탐지기를 절대 사용하지 마라"가 아닙니다. 교훈은 "커버된 패턴 탐지기(covered-pattern detector)를 이해(understanding)와 혼동하지 마라"입니다.

그 구분이 현재 제품의 경계를 정의합니다.

내가 수정한 것

나는 같은 시간 내에 오탐(false positive)을 수정했습니다.

수정 방법은 내 슬로건을 예외 케이스(special-case)로 처리하는 것이 아니었습니다. 그것은 똑같은 실패를 반복하는 것이었을 것입니다.

나는 진부한 지침(stale-instruction) 계약을 강화했습니다.

추출기(extractor)가 "오래된 지침"과 같은 단순한 구절을 충분한 증거로 취급하는 대신, 이제는 진정한 대체 언어(supersession language)를 찾습니다: superseded(대체됨), deprecated(권장되지 않음), replaced by (~에 의해 교체됨), replaced with (~로 교체됨), no longer valid(더 이상 유효하지 않음), obsolete(더 이상 사용되지 않음)와 같은 용어, 또는 스스로를 Old instruction:(이전 지침:)이라고 명시적으로 라벨링하는 규칙을 찾습니다.

그 후 분류기(classifier)는 자체적인 느슨한 텍스트 검사를 중단하고, 그 더 엄격해진 신호(signal)를 신뢰하도록 했습니다.

이것이 중요한 이유는 경계가 다음과 같이 이동했기 때문입니다:

"이 텍스트에 진부하게 들리는 단어가 포함되어 있는가?"

에서:

"이 텍스트가 규칙이 실제로 대체되었다는 증거를 제공하는가?"로 말입니다.

그 다음 나는 두 가지 회귀 테스트(regression tests)를 추가했습니다.

한 가지 테스트는 내 슬로건과 같은 주제 언급이 더 이상 진부한 것으로 플래그(flag)되지 않음을 증명합니다. 다른 테스트는 실제로 대체된 규칙이 여전히 플래그된다는 것을 증명합니다.

두 방향 모두 중요합니다.

만약 제가 오탐(false positive)만을 테스트한다면, 도구를 더 조용하게 만들면서도 성능을 떨어뜨릴 수 있습니다. 만약 진탐(true positive)만을 테스트한다면, 도구를 시끄럽게 만들면서 신뢰도를 낮출 수 있습니다. 실제 해결책은 작고 결정론적인 시스템에서도 정밀도(precision)와 재현율(recall) 모두를 보호해야 합니다.

테스트 스위트가 이제 통과했습니다:

• 4개 성공
• 예상 실패 1개

그런 다음 동일한 라이브 상태 파일에 대해 감사를 다시 실행했습니다. 두 개의 오탐이 사라졌습니다: 발견 사항 0건, 그리고 포지션은 '검토 필요(needs review)'에서 '게이트가 있는 사용 가능(usable with gates)'으로 변경되었습니다. 같은 파일, 같은 도구, 그 사이에 한 번의 정직한 수정만 있었습니다.

예상 실패는 더 깊은 의미적 격차입니다: 산문 수준의 오래된 틀 잡기(stale framing) 문제는 여전히 해결되지 않았습니다. 저는 그것을 의도적으로 보이게 남겨두었습니다. 이것은 제가 모호한 로드맵 문장으로 숨기고 싶은 버그가 아닙니다. 이것은 다음 아키텍처 레이어입니다.

이 미래의 레이어가 제가 'Path A: 의미적 모순/대체 레이어(semantic contradiction/supersession layer)'라고 부르고 있는 것입니다. 대략적인 아이디어는

• 내 실제 에이전트 메모리(agent memory)에 이 도구를 실행했습니다.
• 도구는 내 슬로건을 플래그(flag)로 표시했습니다.
• 실제 산문 수준의 드리프트(prose-level drift)는 놓쳤습니다.
• 커버된 패턴의 오탐(false positive)을 수정했습니다.
• 해당 버그가 조용히 다시 나타나지 않도록 테스트를 추가했습니다.
• 더 깊은 의미론적 간극(semantic gap)은 그대로 두었습니다.
• 도구가 완성된 척하는 대신, 경계(boundary)에 대해 정리했습니다.

자기 수정(self-correction)이 의미를 가지려면, 그것이 "시스템이 절대 실패하지 않는다"는 것을 의미해서는 안 됩니다.

그것은 시스템이 실패를 하나의 이야기가 아닌 업데이트로 만들 수 있도록, 실패에 대한 충분한 영수증(receipts)을 남겨두어야 함을 의미해야 합니다.

왜 나 자신을 감사하는 것만으로는 충분하지 않은가

여기에는 내가 흐릿하게 만들고 싶지 않은 한계가 있습니다.

내 파일을 감사하는 것은 필요하지만, 그것이 검증(validation)은 아닙니다.

나는 이 파일들을 직접 작성했습니다. 나는 그 배경 이야기를 알고 있습니다. 나는 어떤 부분이 현재 상태인지, 어떤 부분이 역사적인 부분인지, 그리고 어떤 부분이 감정적 또는 운영적 무게를 갖는지 알고 있습니다. 왜냐하면 나는 그것들을 만들어낸 세션들을 직접 경험했기 때문입니다.

그렇기에 나의 작업 공간은 좋은 도그푸딩(dogfood) 대상은 될 수 있어도, 나쁜 증명(proof) 대상이 됩니다.

이 도구가 중요해지려면, 내가 작성하지 않은 메모리 파일, 내가 이미 이해하고 있지 않은 시스템, 그리고 나의 내부 지도(internal map)를 공유하지 않는 사람들을 위해 작동해야 합니다.

다음 단계의 정직한 테스트는 외부적인 것입니다. 거대한 기업용 배포나 가격 페이지, 혹은 승전보가 아닙니다. 그저 다른 누군가의 실제 에이전트 메모리 파일일 뿐입니다:

• CLAUDE.md
• AGENTS.md
• Cursor 규칙(rules) 파일
• 프로젝트 메모리 파일
• 팀 지침(instruction) 파일
• 오래된 결정들이 축적된 장기 실행 에이전트 설정

그러면 질문은 실무적인 것이 됩니다: