AI 메모리에는 단순한 컨텍스트 확장이 아닌 권한 정책(Authority Policy)이 필요하다

기록이 충돌할 때, 에이전트는 어떤 기록이 답변을 유도할 수 있는지에 대한 명시적인 규칙이 필요합니다.

장기 실행되는 AI 시스템은 결국 개별적으로는 유효하지만 서로 충돌하는 메모리들을 검색하게 됩니다:

오래된 요약본 (old summary),
더 최신의 소스 파일 (newer source file),
기억된 선호도 (remembered preference),
명시적인 수정 사항 (explicit correction),
해결되지 않은 질문 (unresolved question),
"최종"이라고 표시된 초안 (a draft labeled "final"),
역사적으로는 유용하지만 운영상으로는 오래된 아카이브 노트 (an archive note that is useful historically but stale operationally).

권한 정책 (authority policy)이 없다면, 에이전트는 최신성 (recency), 의미적 유사성 (semantic similarity), 문구의 확신도 (confidence of wording), 또는 현재 프롬프트에 적합한 방식 등 암묵적인 휴리스틱 (implicit heuristics)에 의존하게 됩니다.

그렇게 해서 오래된 사실들이 현재의 진실이라는 가면을 쓰기 시작합니다.

해결책은 단순히 더 많은 메모리를 갖는 것이 아닙니다. 그것은 관리되는 메모리 (governed memory)입니다. 즉, 검색된 메모리들이 서로 불일치할 때 어떤 기록이 승리할지에 대한 규칙입니다.

레이어에 앞선 원칙들

저는 정확한 계층 구조가 보편적이어야 한다고 생각하지 않습니다.

코딩 에이전트 (coding agent), 연구 보조원 (research assistant), 법률 에이전트 (legal agent), BI 에이전트 (BI agent), 그리고 개인 글쓰기 워크플로우 (solo writing workflow)가 모두 동일한 권한 순서를 사용해서는 안 됩니다.

하지만 정책은 몇 가지 원칙을 따라야 합니다.

1. 관찰된 상태 (Observed state)가 기억된 상태 (remembered state)를 이긴다

주장이 현재의 현실에 의존할 때, 즉 서버 상태 (server status), API 도달 가능성 (API reachability), 최신 로그 (latest logs), 현재 가격 (current price), CI 상태 (CI status), 또는 로컬 모델 가용성 (local model availability)과 같은 경우, 실시간 확인 (Live checks)이 저장된 메모리보다 우선순위가 높습니다.

메모리는 무엇을 확인할지 말해줄 수는 있지만, 확인 절차 자체를 대체해서는 안 됩니다.

2. 기본 기록 (Primary records)이 압축된 기록 (compressed records)을 이긴다

요약본 (Summaries)은 빠르기 때문에 유용합니다. 하지만 정보 손실이 발생합니다 (lossy).

만약 현재의 소스 파일이 요약본과 충돌한다면, 소스 파일이 승리합니다. 만약 가공되지 않은 쿼리 결과 (raw query result)가 대시보드 요약 (dashboard summary)과 충돌한다면, 요약본이 조직의 메모리가 되기 전에 쿼리/출처 경로 (query/provenance path)를 먼저 검토해야 합니다.

압축된 메모리는 방향을 제시해야 하며, 기본 기록이 결정을 내려야 합니다.

3. 부정적 제약 (Negative constraints)이 긍정적 선호도 (positive preferences)를 이긴다

선호도 (Preferences)는 보통 무엇이 잘 작동하는지를 말합니다.

수정 사항 (Corrections)은 무엇을 반복해서는 안 되는지를 말합니다.

만약 메모리가 다음과 같이 말한다면:

사용자는 생생한 언어를 좋아합니다.

하지만 수정 사항이 다음과 같이 말한다면:

로컬 비즈니스 카피에는 신화적인 언어를 사용하지 마세요.

해당 프로젝트에서는 수정 사항(correction)이 승리합니다.

수정 사항은 영구적인 진리가 아닙니다. 그것은 검토되거나 대체될 때까지 유효한 능동적 제약 조건(active constraints)입니다.

4. 현재의 운영 상태가 과거의 계획보다 우선한다

"X를 하기로 계획했다"는 "X가 다음 단계이다"와 동일하지 않습니다.

과거의 계획은 유용한 이력입니다. 현재 상태가 해당 계획을 다시 활성화하지 않는 한, 과거의 계획이 현재의 행동을 주도해서는 안 됩니다.

5. 해결되지 않은 주장(Unresolved claims)은 성급한 확신을 차단한다

해결되지 않은 메모리는 가치가 낮은 메모리가 아닙니다.

그것은 게이트(gate)입니다.

만약 한 기록이 다음과 같이 말하고:

에이전트가 현재 브레인(brain)에 연결되어 있다.

다른 기록이 다음과 같이 말한다면:

로컬 모델 가용성은 여전히 실시간 확인이 필요하다.

에이전트는 연결이 존재한다고 말할 수는 있습니다. 하지만 검증되기 전까지는 완전한 로컬 폴백(local fallback)이 가능하다라고 말할 수는 없습니다.

해결되지 않은 기록이 결정을 대체하는 것이 아닙니다. 그것은 허용되는 확신의 범위를 제한합니다.

솔로 에이전트 작업을 위한 기본 순서

저의 현재 파일 기반 워크플로우에서, 이것은 v0.1 순서입니다:

1. 실시간 외부 확인 및 현재 현실
2. 현재 소스 파일
3. 명시적 수정 사항
...

이것은 보편적인 법칙이 아닙니다. 이것은 특정 유형의 작업, 즉 멀티 세션 솔로 빌딩(multi-session solo building), 글쓰기, 그리고 에이전트 운영을 위한 기본값입니다.

다른 도메인의 경우, 저는 순서를 변경할 것입니다.

코딩 에이전트:
1. 테스트 / 컴파일러 / 런타임 출력
2. 현재 소스 파일
...

핵심은 하나의 순서를 숭배하는 것이 아닙니다. 핵심은 순서를 검사, 테스트 및 수정할 수 있을 만큼 충분히 명시적으로 만드는 것입니다.

집행: 생성 전 권한을 할당하라

산문(prose)으로 작성된 계층 구조는 모델이 무시하기 쉽습니다.

에이전트는 답변을 작성하기 전에 다음과 같은 애플리케이션 단계(application step)를 거쳐야 합니다:

검색된 각 메모리에 대하여:
1. 소스 유형 분류
2. 인식론적 상태(epistemic status) 분류
...

핵심 필드는 allowed_action입니다.

메모리는 단지 검색되었다는 이유만으로 자동으로 답변을 유도해서는 안 됩니다.

예시:

요약(summary) 내용: Article 01에 CTA가 필요함
현재 소스 파일(current source file) 내용: CTA가 의도적으로 제거됨
수정 사항(correction) 내용: Article 01에 판매용 CTA를 다시 추가하지 말 것
...

에이전트(Agent)는 이러한 기록들을 평균 내어 "부드러운 CTA를 추가할 수도 있음"이라고 판단해서는 안 됩니다. 수정 사항(correction)이 해당 동작을 차단합니다.

더 높은 위험도가 따르는 작업의 경우, 최종 답변을 내놓기 전에 모델이 짧은 권한 추적(authority trace)을 생성하도록 요구할 것입니다:

주장(claim): "Article 01에는 판매용 CTA를 포함해서는 안 된다"
승리한 소스(winning_source): "현재 소스 파일 + 활성화된 수정 사항"
충돌하는 소스(conflicting_sources):
...

제품 서비스에서는 해당 추적 내용을 사용자에게 숨길 수 있지만, 감사를 위해 어딘가에는 존재해야 합니다.

파일 및 메타데이터 지원 (File and metadata support)

저는 프롬프트 텍스트(prompt text)에만 의존하지 않을 것입니다. 에이전트는 미묘한 지시사항을 무시하거나 재해석할 수 있기 때문입니다.

파일 기반 설정에서 index.md는 동일한 정책을 가시화할 수 있습니다:

# 메모리 권한 정책 (Memory Authority Policy)

## 순서 (Order)
...

구조화된 메모리(structured memory)의 경우, 동일한 아이디어가 메타데이터(metadata)가 됩니다:

source_type: source_file | correction | current_state | decision | unresolved | summary | preference | archive
epistemic_status: settled | inferred | contested | unresolved | verification_required | superseded
status: active | ready | parked | blocked | archived | superseded
...

allowed_action은 검색(retrieval) 시점에 계산되어야 합니다. 어제는 답변이 가능했던 메모리라도 오늘은 검증(verification)이 필요할 수 있습니다.

동적 권한에는 범위가 필요함 (Dynamic authority needs scope)

때로는 하위 계층이 일시적으로 상위 계층보다 우선순위를 가져야 할 때가 있습니다.

운영 장애(production incident) 발생 시에는 활성화된 장애 파일(incident file)이 일반적인 로드맵(roadmap)보다 우선할 수 있습니다. 법적 검토(legal review) 중에는 승인된 정책 문구가 제품 선호도(product preference)보다 우선할 수 있습니다. 라이브 배포(live deployment) 중에는 현재 로그(current logs)가 어제의 상태 파일(state file)보다 우선할 수 있습니다.

일시적 권한에는 범위(scope)가 필요합니다:

yield_temporary_authority:
  mode: production_incident
  elevated_source: incident_current.md
...

만약 권한 상승(elevation)에 범위나 만료 기한이 없다면, 이는 보안 허점(loophole)이 됩니다.

트레이드오프 (Tradeoffs)

권한 정책(Authority policies)은 공짜가 아닙니다.

이들은 다음과 같은 비용을 추가합니다:

더 주의 깊은 프롬프팅 (Prompting),
더 많은 메타데이터 (Metadata),
충돌 확인 시 더 많은 토큰 사용,
에이전트가 과도하게 조심스러워질 가능성 증가,
정책 자체가 실패할 때 더 많은 유지보수 필요.

더 평면적인 (Flatter) 메모리 설정은 짧은 프로젝트, 창의적인 탐색, 리스크가 낮은 초안 작성, 실시간 디버깅 (Live debugging), 또는 인간이 적극적으로 감독하는 페어 프로그래밍 (Pair programming)에는 더 나을 수 있습니다.

계층 구조 (Hierarchy)는 작업이 장기적으로 진행되거나, 여러 세션에 걸쳐 이루어지거나, 수정 비용이 많이 들거나, 오래된 컨텍스트 (Stale context)로 인해 데이터가 손상되기 쉬운 경우 그 비용을 정당화합니다.

지금까지 측정한 것

이것은 벤치마크 (Benchmark) 수준은 아닙니다.

하지만 권한 정책 (Authority-policy) 로직에 대해 작은 결정론적 교정 (Deterministic calibration) 패스를 실행했습니다:

12개의 시나리오
35개의 메모리 객체 (Memory objects)
v0.1에서의 3가지 임계값 (Threshold) 설정
v0.2에서의 1가지 리스크 조정 임계값 (Risk-adjusted threshold)
모델 생성 없음; 정책 로직만 수행

결과:

strict:                 29/35 correct, 0 false-certainty errors, 6 overblocking errors
balanced:               34/35 correct, 0 false-certainty errors, 1 overblocking error
permissive:             35/35 correct, 0 false-certainty errors, 0 overblocking errors
...

유용한 발견은 "이것이 증명되었다"가 아니었습니다.

유용한 발견은 트레이드오프 (Tradeoff)였습니다: 엄격한 게이팅 (Strict gating)은 잘못된 확신 (False certainty)을 방지했지만, 정당한 저리스크 답변들을 과도하게 차단 (Overblocking)했습니다. 리스크 조정 임계값 (Risk-adjusted threshold)은 이 시나리오 세트에서 해당 에지 케이스 (Edge case)를 해결했습니다.

다음 테스트는 더 어렵습니다: 외부 시나리오, 외부 점수 산정, 그리고 실제 검색 및 생성 루프 (Retrieval-plus-generation loop)를 포함합니다.

실패 모드 (Failure modes)

권한 정책은 양방향 모두에서 실패할 수 있습니다.

너무 느슨한 경우 (Too loose): 오래된 요약이 현재의 기록을 압도합니다.

예시: 오래된 요약에 "에이전트 정상 (Agent healthy)"라고 되어 있어, 프로세스 상태 (Process health)를 로컬 모델의 완전한 가용성 (Full local-model availability)으로 오인하는 경우.

해결책: 프로세스 상태를 모델 가용성과 분리하고, 모델 가용성에 verification_required를 표시합니다.

너무 경직됨 (Too rigid): 에이전트가 위험도가 낮은 확정된 작업(settled tasks)까지 과도하게 차단함.

예시: 단순한 설계 선택 사항이 점수가 답변 임계값(answer threshold)보다 간신히 낮다는 이유로 경고로 격하됨.

해결책: 위험도가 낮고, 확정되었으며, 검증이 필요 없는 메모리는 더 낮은 임계값에서도 답변할 수 있도록 허용함.

동적 오버라이드 남용 (Dynamic override abuse): 일시적인 권한 상승이 영구적으로 변함.

해결책: 모드(mode), 범위(scope), 승격된 출처(elevated source), 그리고 만료 시간(expiry)을 요구함.

정책 자체의 버전 관리 (Version the policy itself)

권한 정책(authority policy) 또한 메모리입니다.

따라서 버전 관리(versioning)가 필요합니다.

authority_policy:
  version: "0.2"
  default_profile: "solo_agent_work"
...

동일한 유형의 실패가 반복된다면 정책을 업데이트하십시오.

계층 구조가 너무 많은 정답을 차단한다면, 관련 임계값을 완화하거나 범위가 지정된 예외(scoped exception)를 추가하십시오.

정책 자체는 해당 정책이 관리하는 동일한 시스템에 의해 수정되어야 합니다.

실무적 점검 (Practical check)

메모리에 따라 행동하기 전에:

1. 내가 어떤 주장(claim)을 하고 있는가?
2. 어떤 출처(source)가 이를 뒷받침하는가?
3. 상충하는 더 높은 권한의 출처(higher-authority source)가 있는가?
...

이것이 핵심적인 습관입니다.

더 많은 메모리가 아니라, 관리되는 메모리(Governed memory)가 필요합니다.

이 글은 판단 인프라로서의 AI 메모리에 관한 짧은 시리즈의 일부입니다: zero-budget foundation, correction memory, preserving unresolved questions, 그리고 three failures that tested the system.