운영 메모리를 포인터 인덱스로 제한한 구조 — 본문 없는 한 줄 인덱스 운영 기록

시도하고자 했던 것

에이전트 메모리를 운영하면서 저도 같은 실패 패턴을 겪었습니다 — 중요해 보이는 건 전부 메모리에 넣는 것. 접속 명령, 파일 경로, 진행 상황, 교훈 전문까지. 결과는 모든 세션이 무거워지고, 낡은 정보(2주 전 "진행 중"이던 작업)가 매 세션 주입되는 것이었습니다. 그래서 메모리 구조를 뒤집었습니다: 메모리에는 본문 금지, 포인터만.

진행 방법 — 3층 구조

1) 인덱스(매 세션 자동 주입): 한 줄 × N개 세션이 시작하면 읽는 인덱스 파일에는 기억 1개당 딱 한 줄만 둡니다 — [제목](파일링크) — 낚싯바늘 한 문장. 본문은 절대 안 넣습니다. 지금 8줄 정도인데, 이 8줄이 "무엇을 아는지"가 아니라 "어디에 무엇이 있는지"를 알려줍니다. 2) 기억 파일(필요할 때만 열람): 1파일 1사실 각 기억은 별도 파일로, 유형을 넷으로 강제합니다 — 사용자(내가 누군지) / 피드백(교정받은 작업 방식, 반드시 '왜'와 함께) / 프로젝트(진행 맥락, 상대 날짜는 절대 날짜로 변환) / 레퍼런스(외부 자원 위치). 관련 기억끼리는 위키링크로 연결합니다. 3) 최상위 규칙(모든 세션 공통): 5개 상한 행동 규칙은 기억과 분리해 별도 파일에 두고 5개를 넘기지 않습니다. 새 규칙 후보가 생기면 "여기 넣을지, 도메인 문서로 내려보낼지"를 먼저 결정합니다. 규칙이 30개면 아무도 안 지킵니다. 경계선이 헷갈릴 때 쓰는 기준은 커뮤니티 사례글에서 배운 한 줄입니다: "전문을 읽어야 하면 절차 문서로, 어디 있는지만 알면 되면 메모리로."

결과와 배운 점

결과

세션 시작 비용이 고정됐습니다. 지식이 수백 파일로 늘어도 매 세션 주입되는 건 규칙 5개+한 줄 인덱스뿐입니다. 스터디장님의 AKM 사례글에서 "문서 8,591개를 운영하면서 메모리는 4개"라는 대목을 봤을 때, 규모는 달라도 같은 결론에 독립적으로 도달했다는 걸 확인했습니다. 이 구조는 우연이 아니라 수렴인 것 같습니다.

시행착오

저장할 때가 아니라 회수할 때 설계해야 합니다. "나중에 필요할 것 같은 것"을 저장하는 게 아니라 "다음 세션이 어떤 질문으로 이걸 찾을까"를 기준으로 낚싯바늘 문장을 씁니다. 회수 안 되는 기억은 없는 기억입니다. 중복 저장이 최대의 적이었습니다. 같은 사실이 메모리·프로젝트 노트·리서치 폴더에 다른 버전으로 존재하면 어느 게 정본인지 알 수 없게 됩니다. "행동 지침은 메모리에, 사실·이력은 기록 폴더에 — 중복 저장 금지"를 규칙으로 박았습니다. 낡는 정보는 메모리에 안 넣습니다. "진행 중" 상태 같은 건 며칠이면 거짓말이 됩니다. 상태는 프로젝트 노트(날짜 append)에 두고, 메모리에는 그 노트의 위치만. 기억도 삭제가 필요합니다. 틀린 것으로 판명된 기억은 지웁니다. 단, 판단 기록이 필요한 건 삭제 대신 "정정" 줄을 추가합니다.

꿀팁

인덱스 한 줄을 쓸 때 "~에 대한 내용"이라고 쓰면 실패합니다. "다음 단계는 견적·원가표" 같은 행동 가능한 꼬리를 달아야 다음 세션이 뭘 해야 하는지 압니다. 상대 날짜("어제", "지난주")는 저장 순간 절대 날짜로 바꿔 적으세요. 2주 뒤에 읽는 세션에게 "어제"는 독입니다.

도움이 필요한 부분

포인터가 너무 짧으면 에이전트가 못 찾아가고, 길면 인덱스가 비대해집니다. 낚싯바늘 문장의 적정 길이를 잡은 경험이 궁금합니다.

도움 받은 글

스터디장님 AKM 사례글 — "메모리는 지식 창고가 아니라 탐색을 시작하기 위한 작은 지도" AKM 이식 사례글 — "전문을 읽어야 하면 Procedure, 위치만 알면 Memory" 기준선