빠른 확인: 당신의 에이전트 스택 어딘가에 memory.md가 있나요? 아니면 AGENTS.md가 있나요? 에이전트가 보관할 가치가 있다고 판단할 때마다 내용을 추가하는 노트 파일이 있나요?

그럴 것이라 생각합니다. 제 것도 그랬으니까요. 이것은 모두가 수렴하게 되는 패턴이며, 구축하는 데 20분밖에 걸리지 않고, 실제로도 잘 작동합니다 — 3월에 더 이상 사실이 아니게 된 정보를 고객에게 전달하는 그날이 오기 전까지는 말이죠.

이 포스트는 세 가지를 수행합니다: 이 패턴이 왜 부패하는지(우리가 해부할 실제 형태의 샘플 파일을 통해) 정확히 보여주고, 오늘 밤 당신의 파일을 직접 감사할 수 있는 작은 스크립트를 제공하며, 이를 실제로 해결하는 아키텍처 변경 사항을 안내합니다. 이 모든 과정에 특정 벤더(Vendor)는 필요하지 않습니다.

우리 모두가 구축했던 패턴

프레임워크를 걷어내면 모든 자체 관리형 메모리 루프(memory loop)는 다음과 같은 모습입니다:

MEMORY = Path("memory.md")

def run_task(task: str) -> str:
...

먼저 이 방식에 대해 공정하게 평가해 봅시다: 이것은 사람이 읽을 수 있고(human-readable), 버전 관리(versionable)가 가능하며, grep으로 검색(greppable)할 수 있고, 인프라가 전혀 필요 없습니다(zero-infrastructure). **단일 에이전트, 단일 작업, 작은 작업 세트(small working set)**를 위한 것이라면 — 솔직히 이보다 더 나은 방식은 찾기 어렵습니다.

이제 이 방식이 하지 못하는 것을 살펴보겠습니다. 4단계가 전체 라이프사이클(lifecycle)입니다. 이 루프 안에서는 한 번 작성된 줄이 업데이트되거나, 병합(merge)되거나, 만료(expire)되거나, 의문이 제기되는 일이 전혀 없습니다. 이 파일은 정확히 한 가지 동작만 수행합니다: 바로 커지는 것입니다.

6개월 된 메모리 파일 해부하기

다음은 해당 루프가 6개월 차에 생성하는 결과물의 압축된 실제 사례입니다. 검색(retrieval) 시스템이 읽는 방식 그대로 읽어보세요 — 모든 줄이 똑같이 사실인 것처럼 말이죠:

- 고객사 Acme는 us-east1에서 워크로드를 실행함
- Acme는 에스컬레이션(escalations) 시 이메일보다 Slack을 선호함
- Acme의 스테이징(staging) 환경은 레거시 인증 흐름(legacy auth flow)을 사용함
...

아홉 줄입니다. 피해 규모를 계산해 봅시다:

아홉 줄입니다. 피해 규모를 계산해 봅시다:

• 두 개의 실시간 모순(live contradictions). us-east1 대 europe-west2 (라인 1, 6, 9 — 에이전트가 자체 메모리를 신뢰했기 때문에 마이그레이션 후에도 오래된 사실이 _재확인_되었다는 점에 주목하세요). 레거시 인증 흐름(legacy auth flow) 대 새로운 인증 흐름(lines 3, 7).
• 하나의 좀비 항목(zombie). beta_router는 더 이상 존재하지 않는 플래그를 위해 ON 상태로 유지되어야 합니다 (라인 5, 8).
• 하나의 약한 충돌(soft conflict). Slack 대 이메일 선호도 (라인 2, 4) — 둘 다 사실일 수도 있고 아닐 수도 있습니다. 아무것도 결정하지 못할 것입니다.
• 날짜 없음, 출처 없음, 대체 정보 없음. 라인 9가 라인 6보다 더 권위 있어 보입니다. 더 최신이고

맨 위의 루프로 돌아가 봅시다. 3~4단계는 작업 중인 에이전트에게 '메모리 관리자 (memory manager)'라는 두 번째 직업을 조용히 부여합니다. "이것을 유지할 가치가 있는가?"라는 모든 결정은 작업 예산에서 토큰과 주의력 (attention)을 소모하며 치러집니다. 그리고 큐레이터 (curator)는 작업 중간에 중요하다고 느껴지는 것은 무엇이든 유지하며 스스로의 숙제를 채점하고 있는 셈입니다. 각자 자신만의 파일을 가진 에이전트 군단(fleet)으로 이를 곱해본다면, N개의 일기장이 존재하지만 조정 (reconciliation)은 전혀 이루어지지 않으며, 이들이 서로 불일치할 때 이를 감지하는 것이 '직무'인 컴포넌트는 어디에도 없는 상태가 됩니다.

이 직무가 실제로 무엇을 요구하는지 적어보면, 더 이상 파일 API처럼 보이지 않습니다:

다섯 가지 동사가 있지만, 대부분 인력이 배치되지 않은 상태입니다. 이것은 저장 공간의 공백이 아닙니다. 이것은 **인력 (staffing)**의 공백입니다.

아키텍처의 변화

해결책은 분업입니다. 관리 루프를 작업 에이전트로부터 분리하여 전문가에게 맡기는 것입니다. 즉, 다른 에이전트들의 메모리를 관리하는 것이 전체 기능인 **메모리 에이전트 (Memory Agent)**를 도입하는 것입니다. 작업 에이전트의 인터페이스는 다음 두 가지 호출로 축소됩니다:

# 작업 에이전트 — 메모리는 더 이상 에이전트의 문제가 아님
def run_task(task: str) -> str:
    context = memory_agent.brief(agent_id=ME, task=task)  # 관련 있는 부분만 가져옴
...

# 메모리 에이전트 — 자체 예산으로 전체 군단에 대해 자체 루프를 실행함
while True:
    curate(inbox)          # 느낌(vibes)이 아닌 기준을 가지고 유지할 것과 노이즈를 구분함
...

무엇이 변했는지 주목하십시오. 작업 에이전트는 메모리 결정에 토큰을 전혀 사용하지 않습니다. 큐레이션 기준은 N개의 프롬프트 대신 한 곳에 존재합니다. 모순 사항에는 담당자가 생깁니다. 그리고 메모리 자산은 커밋 히스토리가 있는 텍스트 파일 대신, 에이전트별로 범위를 지정하고, 감사(audit)하고, 내보낼 수 있는 일급 시스템 (first-class system)이 됩니다.

솔직하게 시도해 보세요

먼저 솔직하게 짚고 넘어가겠습니다: 에이전트 한 대, 작은 작업 세트(working set), 컴플라이언스 대상(compliance surface) 없음 → 마크다운(Markdown) 파일을 그대로 유지하세요. 진심입니다. 이 아키텍처는 여러 에이전트, 공유 지식, 사용자에게 도달하는 모순(contradictions)이 발생하는 '플릿(fleet)' 규모에서 그 가치를 발휘합니다.

만약 당신이 그 상황에 해당한다면, 두 가지 경로가 있습니다:

1. 직접 루프(loop)를 구축하세요. 위의 의사코드(pseudocode)만으로도 시작하기에 충분합니다. 당신이 맞닥뜨리게 될 어려운 부분들(모순 해결 정책(contradiction resolution policy), 감쇠(decay), 브리핑 관련성(briefing relevance))은 바로 이 기술을 하나의 전문 분야(discipline)로 만드는 핵심 요소들입니다. 어느 쪽이든 배울 점이 많을 것입니다.
2. 기존에 존재하는 것을 실행하세요. 이것이 바로 우리가 해결하고자 하는 문제입니다: Memanto는 당신이 이미 사용 중인 어떤 에이전트나 프레임워크와도 함께 실행될 수 있는 오픈 소스(MIT, 무료) 메모리 에이전트(Memory Agent)입니다. github.com/moorcheh-ai/memanto에서 가져와 당신의 플릿(fleet)을 대상으로 지정하세요. 데이터는 오픈 포맷(OKF)으로 저장되며 memanto migrate CLI가 함께 제공되므로, 이를 시도한다고 해서 반드시 이에 종속되지는 않습니다.

어느 쪽이든, 먼저 감사(audit) 스크립트를 실행해 보세요. 그런 다음 당신의 스택이 답할 수 있어야 하지만 아마도 답하지 못할 질문 하나를 던져보세요:

당신의 플릿(fleet)은 오늘 무엇을 믿고 있는가?

만약 그 답이 3,000줄짜리 파일이라면 — 메모리는 단순한 저장소(dump)가 아니라 하나의 업무(job)입니다. 인력을 투입하세요.