내 AI 에이전트 워크플로우 뒤에 숨겨진 제로 예산 메모리 설정: 데이터베이스도, 프레임워크도 없이 오직 파일, 시작 순서, 수정 로그

AI 에이전트(AI agents)를 구축하는 대부분의 사람들은 결국 똑같은 벽에 부딪히게 되는데, 이는 모델이 얼마나 똑똑한지와는 전혀 상관이 없습니다. 그 벽은 바로 '망각'입니다. 당신은 어느 저녁, AI와 함께 실질적인 무언가를 구축하는 데 시간을 보냅니다. 시스템, 계획, 혹은 마침내 당신의 사고방식에 딱 맞는 작업 방식 같은 것 말이죠. 하지만 다음 날 아침, 새로운 세션을 열면 그것은 사라져 있습니다. 파일이 사라진 것이 아닙니다. '이해(understanding)'가 사라진 것입니다. 어제 당신의 약어를 학습했던 모델은 오늘 당신을 낯선 사람처럼 대합니다. 당신은 다시 설명해야 합니다. 모델은 다시 유도(re-derives)해야 합니다. 당신은 똑같은 과정을 다시 밟는 것을 지켜보게 되며, 그때마다 추진력(momentum)은 조금씩 사그라듭니다.

이 문제를 해결하기 위해 하나의 거대한 산업이 형성되고 있습니다. 벡터 저장소(vector stores), 시계열 지식 그래프(temporal knowledge graphs), 관리형 에이전트 메모리 서비스(managed agent-memory services), 그리고 수십 개에 달하는 프레임워크 통합(framework integrations) 등이 그것입니다. 그중 일부는 진정으로 훌륭한 엔지니어링입니다. 하지만 인프라를 구매하기 전에, 규율(discipline)을 먼저 배우십시오. 당신은 단순한 파일, 명확한 시작 순서(startup order), 그리고 정직한 유지보수만으로 메모리 문제의 상당 부분을 해결할 수 있습니다.

이것은 제 자신의 AI 메모리 워크플로우 뒤에 있는 기본적인 설정입니다. 저의 경우, 디스크에 있는 단순한 마크다운(markdown) 파일과 제가 수동으로 편집할 수 있는 구조화된 미러(structured mirror)를 의미합니다. 당신의 버전은 프라이빗 저장소(private repo), Obsidian 보관함(vault), Notion 페이지, 로컬 폴더, 또는 당신이 실제로 유지보수할 수 있는 무엇이든 될 수 있습니다. 이것은 가능한 가장 강력한 메모리 시스템은 아닙니다. 하지만 제가 신뢰할 수 있는 가장 마찰이 적은(lowest-friction) 시스템입니다.

단 하나의 원칙: 메모리는 당신이 기록하는 정도만큼만 지속됩니다. 실시간 대화(live conversation)는 시스템에서 가장 취약한 부분입니다. 그것은 관계, 맥락, 공유된 이해처럼 느껴집니다. 하지만 그것은 RAM과 같습니다. 증발해 버립니다. 대화를 내구성이 있는 메모리로 취급하는 것이 근본적인 실수입니다. 규율은 '더 많이 기억하는 것'이 아닙니다. 규율은 '중요한 것을 외부화(externalize)하는 것'입니다. 중요한 모든 것은 휘발성인 채팅에서 벗어나 세션이 끝나도 살아남는 무언가로 이동해야 합니다. 로컬 파일, 지식 베이스(knowledge base), 저장소(repo), 프로젝트 노트 같은 것 말이죠. 이것은 단순한 노트 필기가 아닙니다.

이것은 AI 에이전트 (AI agent)가 읽고 실행할 수 있도록 설계된 부팅 시퀀스 (boot sequence), 정직 규칙 (honesty rule), 진실의 원천 계층 구조 (source-of-truth hierarchy), 그리고 유지보수 리듬 (maintenance rhythm)을 갖춘 노트 필기입니다. 일단 이를 받아들이고 나면, 패턴은 단순해집니다.

패턴 1: 하나가 아닌 두 개의 거울 (Two Mirrors, Never One)
저는 메모리를 두 곳에 보관합니다. 제가 직접 읽고 편집할 수 있는 구조화된 장소와, 에이전트가 시작 시 읽을 수 있는 일반 텍스트 (plain text) / 마크다운 (markdown) 파일입니다. 왜 두 개일까요? 서로 다른 에이전트가 항상 같은 세상을 보는 것은 아니기 때문입니다. 어떤 에이전트는 지식 베이스 (knowledge base)는 볼 수 있지만 디스크 (disk)는 보지 못할 수 있습니다. 또 다른 에이전트는 로컬 파일 (local files)은 볼 수 있지만 외부 앱 (external app)은 보지 못할 수도 있습니다. 만약 메모리가 단 한 곳에만 존재한다면, 시스템의 일부가 눈이 멀 수 있습니다. 따라서 중요한 결정, 수정 사항, 그리고 현재 상태의 변경 사항은 거울처럼 복제됩니다. 중복처럼 느껴질 수 있습니다. 하지만 그 중복이 핵심입니다. 메모리의 단일 사본은 단 한 번의 장애로도 기억상실에 빠질 수 있습니다. 의도적으로 동기화된 두 개의 사본은 하나의 도구, 스레드 (thread), 또는 노트북이 고장 나더라도 살아남을 수 있습니다. 문제는 드리프트 (drift, 차이 발생)입니다. 두 거울이 서로 일치하지 않을 경우, 충돌이 발생하기 전에 규칙이 필요합니다. 저의 규칙은 간단합니다. 마크다운 메모리 파일이 에이전트 시작을 위한 진실의 원천 (source of truth)입니다. 구조화된 거울은 인간의 가독성과 편집을 위한 것입니다. 만약 두 내용이 일치하지 않는다면, 의도적으로 업데이트될 때까지 파일의 내용이 우선합니다. 동기화는 거창할 필요가 없습니다. 소규모 규모에서는 주간 검토, git 커밋 (git commit), 또는 짧은 수동 비교만으로도 충분합니다. 중요한 것은 두 거울이 조용히 서로 어긋나는 것을 허용해서는 안 된다는 점입니다.

패턴 2: 정체성을 먼저 로드하라 (Identity Loads First)
새로운 세션이 시작될 때, 컨텍스트 (context)를 로드하는 순서는 그 양보다 더 중요합니다. 만약 에이전트가 자신의 역할 (role), 미션 (mission), 규칙 (rules)을 읽기 전에 최근 활동을 먼저 읽는다면, 그것은 척추 없는 똑똑한 도구처럼 행동하게 됩니다. 즉, 유능하지만 일반적이고, 중심이 없는 상태가 됩니다. 만약 정체성을 먼저 읽고, 그다음 현재 상태 (current state), 그다음 수정 사항 (corrections)을 읽는다면, 동일한 사실을 바탕으로도 더 일관성 있는 에이전트가 만들어집니다. 저의 시작 순서는 간단합니다:

1. orientation.md — 역할, 미션, 규칙
2. state.md — 현재의 진실
3. corrections.md — 무엇이 왜 바뀌었는가
4. decisions.md — 선택 사항 및 거부된 대안들

gates.md — 어떤 믿음이나 프로젝트가 틀렸음을 증명할 수 있는 것
6. open_questions.md — 아직 결정되지 않아야 할 것
7. session_log.md — 지난 세션이 끝날 때 무엇이 바뀌었는가

오리엔테이션 파일(Orientation file)은 용골(Keel)입니다. 나머지는 화물일 뿐입니다.

패턴 3: 에이전트가 자신의 메모리를 의심하게 만들기
메모리를 가진 에이전트는 기회만 생기면 메모리를 조작(Fabricate)할 것입니다. 기록이 없는 회의에서 무슨 일이 있었는지 물어보면, 취약한 설정의 에이전트는 그럴듯한 답변을 지어낼 것입니다. 그러한 행동은 모든 것을 오염시킵니다. 이제 그 어떤 것도 신뢰할 수 없게 되기 때문입니다. 그래서 저는 모든 곳에서 한 가지 규칙을 사용합니다: "직접 읽지 않았다면, 당신은 그것을 모르는 것이다."라고 말하십시오. "그에 대한 기록이 없습니다"는 정답입니다. 확신에 찬 허구는 설령 우연히 맞았을지라도 실패입니다. 시스템이 허세를 부르도록 훈련시키기 때문입니다. 메모리 시스템의 테스트는 얼마나 많이 기억하느냐가 아닙니다. 자신이 모르는 것에 대해 진실을 말하느냐입니다.

패턴 4: 컨텍스트(Context)를 예산으로 취급하기
긴 세션은 생산적인 것처럼 느껴지지만, 비용이 많이 들고 노이즈가 심해질 수 있습니다. 컨텍스트 윈도우(Context window)의 상당 부분이 매 턴마다 이전 대화를 다시 읽는 데 소비됩니다. 채팅은 그저 스스로를 따뜻하게 유지하기 위해 토큰을 태워버리는 용광로가 됩니다. 해결책은 화려하지 않습니다: 버퍼가 부풀어 오르기 전에 요약하고 재시작하기, 수정 사항을 계속 쌓아 올리는 대신 오래된 지침을 편집하기, 관련 메모리 파일만 로드하기, 기록이 없다고 가정하기 전에 파일 검색하기, 작업에 모델을 맞추기, 현재 상태를 짧고 신선하게 유지하기 등입니다. 아카이브(Archive)는 시간이 지남에 따라 반복되는 설정 비용을 줄여야지, 어디든 끌고 다니는 또 다른 거대한 프롬프트가 되어서는 안 됩니다. 소규모 규모에서는 파일 이름, 헤딩(Heading), 태그(Tag), 그리고 검색만으로도 충분한 경우가 많습니다. 관련 항목을 빠르게 찾을 수 없다면, 그것은 메모리를 더 추가하기 전에 인덱스(Index)를 개선해야 한다는 신호입니다.

패턴 5: 승리뿐만 아니라 수정 사항도 보존하기
대부분의 사람들은 깔끔한 결과물(Output)을 저장합니다. 그것도 유용하지만 충분하지는 않습니다. 더 가치 있는 기록은 종종 무엇이 변했는가 하는 것입니다: 당신이 무엇을 믿었는지, 무엇이 실패했는지, 무엇이 수정되었는지, 그리고 다음번에는 어떤 행동이 바뀌어야 하는지 말입니다.

그렇기 때문에 저의 기본적인 설정에는 corrections.md가 포함되어 있습니다. 유용한 수정 사항(correction) 항목은 다음과 같은 형태를 띱니다:

2026-05-23 — 배송이 전환(conversion)은 아니다

수정 사항(Claim under correction): "기사와 제품이 라이브되면, 어려운 부분은 끝난 것이다."
변경 사항: 발행(Publishing)은 자산을 만들었지만, 아직 구매한 낯선 이는 없다.
다음 행동: 또 다른 제품을 만들기 전에 다음 작업 블록을 배포(distribution)에 할애할 것.
활성 게이트(Active gate): 타겟 독자 100명 또는 14일 후 검토.

이러한 종류의 메모리는 에이전트가 나중에 당신에게 이의를 제기할 수 있는 근거를 제공합니다.

패턴 6: 아직 열려 있는 상태를 보존하라 (Preserve What Is Still Open)
수정 사항이 시스템의 전부는 아닙니다. 어떤 것들은 해결될 준비가 되지 않았습니다. 그렇기 때문에 저는 open_questions.md도 함께 유지합니다. 이곳은 해결되지 않은 질문, 실시간 해석(live interpretations), 불확실성의 경계, 그리고 검토 트리거(review triggers)를 위한 장소입니다.

예시:
질문: 제안(offer)이 약한 것인가, 아니면 배포가 적절한 독자에게 도달하지 못한 것인가?
실시간 해석: 1. 제안이 약함. 2. 채널 불일치. 3. 포지셔닝(positioning)이 약함.
필요한 다음 증거: 타겟 독자 100명 또는 14일간의 의도적인 배포.
검토 정책: 임계값(threshold) 이후에도 신호가 없다면, 두 번째 제안을 만들기 전에 포지셔닝을 수정할 것.

목표는 질문을 영원히 열어두는 것이 아닙니다. 목표는 증거가 도착하기 전에 부실한 요약이 살아있는 가설(live hypotheses)을 죽이지 않도록 하는 것입니다.

최소 파일 세트 (The Minimal File Set)
오늘 밤 바로 시작하고 싶다면, memory라는 폴더를 하나 만들고 다음 파일들을 추가하세요:
orientation.md, state.md, corrections.md, decisions.md, gates.md, open_questions.md, index.md, session_log.md

그런 다음 에이전트/프로젝트 지침(instructions)에 다음 내용을 넣으세요:

세션 시작 시, orientation.md를 먼저 읽고, 그다음 state.md를 읽으세요. 작업과 관련된 수정 사항(correction), 결정(decision), 게이트(gate), 또는 미결 질문(open question)만 읽으세요. 만약 파일의 내용이 채팅 메모리와 일치하지 않는다면, 파일의 내용이 우선합니다. 파일을 읽지 않았다면, 그것을 알고 있다고 주장하지 마세요. 알려진 것, 추론된 것, 논쟁 중인 것, 그리고 누락된 것을 구분하세요. 로딩 후, 어떤 파일을 읽었는지와 어떤 컨텍스트(context)가 없는지 나에게 말해 주세요.

시작하기에는 그것으로 충분합니다. 완벽한 메모리 시스템을 구축하기에는 충분하지 않지만 말입니다.

제로(zero) 상태에서 시작하는 것을 막기에는 충분합니다. 여러 프로젝트를 진행할 때는 모든 것을 구분되지 않은 하나의 폴더에 섞어두지 마세요. 프로젝트당 하나의 메모리 폴더를 유지하거나, 공유 폴더를 사용한다면 명확한 프로젝트 접두사(prefix)와 태그를 사용해야 합니다. 경계가 없는 공유 메모리는 빠르게 노이즈(noise)가 됩니다.

대상 독자
이 설정은 AI 작업이 한 세션보다 오래 지속되는 경우, 즉 연구, 글쓰기, 코딩, 제품 결정, 클라이언트 작업, 에이전트(agent) 프로젝트, 또는 컨텍스트(context)를 다시 설명하는 비용이 계속 누적되는 모든 스레드(thread)에서 유용합니다. 일회성 프롬프트, 빠른 조회, 또는 잊어버려도 상관없는 단발성 작업에는 아마 과할 것입니다. 핵심은 모든 채팅을 관료주의적으로 만드는 것이 아닙니다. 나중에 재구성하기에 비용이 많이 들거나, 위험하거나, 짜증스러운 작업의 부분들을 보존하는 것이 목적입니다.

여전히 발생할 수 있는 문제들
일반 파일(Plain files)이 마법처럼 좋은 메모리를 만들어주지는 않습니다. 파일은 단지 메모리를 검사 가능하게(inspectable) 만들 뿐입니다. 다음과 같은 상황에서는 여전히 시스템이 실패합니다: 파일이 오래되었거나(stale), 시작 순서(startup order)가 무시되거나, 단일 진실 공급원(source-of-truth) 규칙 없이 두 개의 미러(mirror)가 어긋나거나, 모든 사소한 생각이 저장되거나, 수정 사항이 전혀 검토되지 않거나, 프로젝트가 변경된 후에도 오래된 상태(state)가 남아있거나, 에이전트가 누락된 기록을 임의로 지어내도 된다는 허가로 간주하는 경우입니다. 유지보수(maintenance)가 곧 시스템입니다. 유지보수가 없다면 폴더는 아무도 신뢰하지 않는 또 다른 아카이브(archive)가 될 뿐입니다.

또한 확장성(scaling)의 한계도 있습니다. 일반 파일은 1인 운영자나 소수의 활성 프로젝트를 관리하기에는 탁월합니다. 하지만 활성 파일이 수십 개로 늘어나고, 기여자가 여러 명이며, 무거운 검색(retrieval) 요구사항이 있거나, 수천 개의 메모리 항목이 생기면 인프라(infrastructure)가 제 역할을 할 때가 됩니다. 협업형 RAG(Retrieval-Augmented Generation), 긴 자율 실행(autonomous runs), 권한이 부여된 팀 메모리, 또는 대량의 데이터 수집(ingestion)의 경우, 파일 방식은 첫날부터 열등할 수 있습니다.

주간 유지보수 (Weekly Maintenance) 일주일에 한 번, 15분을 투자하여 메모리를 살아있게 유지하세요: 현재 사실에 맞게 state.md를 업데이트하고, 마지막 세션의 방향이 바뀌었다면 짧은 session_log.md 요약을 추가하며, 오래된 수정 사항은 삭제하는 대신 대체(superseded)된 것으로 표시하고, 더 이상 결정에 영향을 미치지 않는 오래된 질문들은 아카이브(archive)하며, 구조화된 미러(structured mirror)와 마크다운 (markdown) 파일들이 여전히 일치하는지 확인하세요. 시스템이 제대로 작동하는지는 두 가지 간단한 숫자로 측정할 수 있습니다: 동일한 프로젝트 컨텍스트를 얼마나 자주 다시 설명해야 하는지, 그리고 수정 사항이 이미 기록되어 있기 때문에 에이전트가 반복되는 실수를 얼마나 자주 잡아내는지입니다. 만약 이 숫자(빈도)가 개선되지 않는다면, 그 시스템은 메모리가 아닙니다. 그것은 저장소 (storage)일 뿐입니다.

왜 규율 (Discipline)이 인프라 (Infrastructure)를 이기는가
나는 메모리 도구에 반대하는 것이 아닙니다. 시스템이 성장하면 검색 필터 (retrieval filters), 벡터 저장소 (vector stores), 메타데이터 (metadata), 검토 자동화 (review automation), 시간적 메모리 계층 (temporal memory layers)과 같은 실제 인프라가 제 자리를 찾을 수 있습니다. 하지만 도구는 저장 (storage) 문제를 해결할 뿐입니다. 그것들은 판단 (judgment) 문제를 해결하지 못합니다. 검증되지 않고, 수정되지 않았으며, 정체성이 없는 메모리로 가득 찬 벡터 데이터베이스 (vector database)는 그저 자신 있게 틀릴 수 있는 더 빠른 방법일 뿐입니다. 먼저 파일로 규율을 올바르게 잡으세요. 그런 다음 자동화할 권리를 얻으십시오.

이것이 이끄는 방향
이 파일 기반 설정은 기초입니다. 더 깊은 계층은 다음과 같습니다:
수정 메모리 (Correction memory): 당신의 생각이 어디서, 왜 바뀌었는지 보존합니다.
미결 메모리 (Unresolved memory): 아직 결정되지 않아야 할 것을 보존합니다.
진실의 원천 계층 구조 (Source-of-truth hierarchy): 메모리가 충돌할 때 어떤 기록이 승리할지 결정합니다.

대부분의 AI 메모리 조언은 인프라에서 시작합니다. 나는 운영 규율 (operating discipline)에서 시작할 것입니다: 무엇이 지속되어야 하는가? 무엇이 수정되어야 하는가? 무엇이 미결 상태로 남아야 하는가? 어떤 소스가 승리하는가? 에이전트가 지어내는 것을 거부해야 할 것은 무엇인가? 이것이 당신을 기억하는 AI와, 시간이 흐름에 따라 당신의 판단과 함께 실제로 협업할 수 있는 AI 사이의 차이입니다.

선택 사항: 직접 만드는 대신 미리 제작된 파일들을 원하신다면, 저는 이것을 'The Correction-Memory Playbook'으로 만들었습니다. 이 플레이북은 6개의 파일로 구성된 스타터 시스템, 마크다운 (Markdown) 템플릿, 완성된 예시, 복사해서 붙여넣을 수 있는 프롬프트 (Prompts), 토큰 절약형 로딩 규칙 (Token-saving loading rules), 30분 빠른 시작 가이드, 그리고 7일 설정 경로를 포함하고 있습니다. 플레이북은 여기서 받으세요.