기업 AI의 기억은 쌓기보다 꺼내는 길이 먼저입니다 — 에이전트 기억 509개 중 39%가 한 달 내내 잠들어 있던 기록과 4층 기억 설계

PART 01 · Evidence쌓기만 하고 꺼내지 못하고 있었습니다

제 하네스의 기억은 작은 마크다운 파일입니다. 피드백, 프로젝트, 참고 사실이 한 파일에 하나씩 들어갑니다. 그리고 색인 파일 하나가 매 세션 시작 때 통째로 실립니다. 모델은 그 색인의 한 줄 설명을 보고 필요한 기억을 열어 읽습니다.

10월 20일, 지난 30일 세션 299개를 다시 읽었습니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

‘건드림’은 읽기·쓰기·인용 중 하나라도 있었다는 뜻이고, ‘열어 본’은 읽기만 셉니다. 그래서 열어 본 비율과 건드리지 않은 비율을 더해도 100%가 되지 않습니다.

기억은 두 달 만에 71% 늘었고, 열어 본 비율은 제자리였습니다. 그래서 쓰이지 않는 기억의 절대 수가 늘었습니다. 색인은 상한 25,000B에 거의 닿아 있었습니다. 색인 꼬리가 잘리면 그 아래 기억은 존재 자체가 보이지 않게 됩니다.

쓰는 쪽도 기대와 달랐습니다. 세션이 끝날 때 모델에게 기억 정리를 요구하는 장치가 있었는데, 30일 동안 강제로 정리한 것이 7건(2.3%)이었고 스스로 정리를 선언한 것은 0건이었습니다. 세션 안에서 모델에게 기억 관리를 맡기는 방식은 거의 돌지 않았습니다.

PART 02 · Benchmark옆 도구는 4KB만 싣고 나머지는 찾아 썼습니다

같은 시기 저는 Aside라는 브라우저 에이전트 도구를 함께 쓰고 있었습니다. 그 도구의 기억 구조를 읽어 보니 방향이 반대였습니다.

Aside는 매 세션 1.1KB의 운영 규칙과 3KB의 사용자 프로필만 싣습니다. 나머지는 주제별 페이지와 날짜별 관찰에 두고, 청크 949개의 색인으로 필요할 때 찾습니다. 날짜별 관찰을 주제 페이지로 올리는 정리는 사람 개입 없이 비동기로 돕니다. 제 하네스의 색인은 그 두 파일을 합친 4.2KB의 약 6배였습니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

공개 기억 엔진 40여 개도 함께 조사했습니다. 성능 상위권은 모두 서버나 그래프·벡터 데이터베이스, 호스팅 계정을 요구했습니다. 그래서 엔진은 들이지 않고 값싼 장부 패턴만 가져오기로 했습니다.

PART 03 · Recall꺼내는 길을 붙였습니다

10월 20일, 네 가지를 바꿨습니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

회수 장치는 기억 내용을 싣지 않습니다. 경로와 한 줄 설명만 싣고, 모델이 필요할 때 읽게 합니다. 시리즈 두 번째 글의 교훈과 같은 원리입니다. 문맥에는 좌표만 두고, 본문은 필요할 때 읽습니다.

정리하면 기억을 네 층으로 나눈 셈입니다. 층마다 싣는 방식과 넣는 기준이 다릅니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

색인 크기도 계속 봤습니다. 10월 30일 기준 색인은 16.9KB로 줄어 있었습니다. 지금 색인은 항목을 지우지 않고 주제별 허브 파일로 옮겨 두는 방식입니다. 제 목표는 4.2KB를 그대로 따르는 것이 아니라, 상한에 닿지 않고 매 세션 꼭 필요한 줄만 남기는 것입니다.

PART 04 · Two Weeks2주 뒤, 접근한 세션은 늘고 열어 본 비율은 줄었습니다

11월 3일, 같은 도구로 지난 30일을 다시 쟀습니다.

기억 파일은 568개로 늘었습니다. 기억을 건드린 세션은 304개 중 164개로 53.9%였습니다. 48.5%보다 올랐습니다. 그런데 열어 본 기억의 비율은 53.0%에서 47.2%로 내려갔습니다.

30일 동안 한 번도 건드리지 않은 기억은 249개(43.8%)가 됐습니다. 기억을 근거로 말한 세션도 26개(8.7%)에서 24개(7.9%)로 줄었습니다. 다만 기억을 건드린 세션은 회수 장치 이전에도 24.1%에서 48.5%로 늘던 추세였습니다. 53.9%를 장치의 효과로만 읽지 않습니다.

이 결과를 두 가지로 읽습니다. 첫째, 기억이 2주 만에 59개 늘었습니다. 늘어나는 속도가 꺼내 쓰는 속도보다 빨랐습니다. 둘째, ‘열어 본 비율’이 회수 효과의 맞는 잣대가 아닐 수 있습니다. 회수 장치는 경로와 한 줄 설명을 실어 주므로, 모델이 파일을 열지 않고 설명만으로 충분했을 수도 있습니다. 어느 쪽인지는 아직 모릅니다.

그래서 다음 잣대를 바꿨습니다. 필요한 기억이 상위 세 개 안에 들어왔는지를 재는 회수 적중률입니다. 10월 20일 기준 34%였고, 목표는 60%를 거쳐 80%입니다. 이 값은 한 차례 잰 내부 평가이고, 평가 질문 구성은 아직 공개할 만큼 정리하지 못했습니다. 방향을 보는 값으로만 씁니다.

PART 05 · Hosts세 엔진과 두 컴퓨터, 한 저장소가 아니라 한 원장으로 묶기로 했습니다

처음 장면으로 돌아가겠습니다. 기억이 9월 23일에서 멈춘 이유는 컴퓨터가 둘이었기 때문입니다. 10월 31일, 기억이 어디에 있는지 전부 펴 봤습니다.

Mac의 Claude와 Codex는 이미 같은 기억과 같은 회수 장치를 쓰고 있었습니다. 저장소의 훅을 함께 쓰기 때문입니다. 빈 곳은 다른 데 있었습니다. Aside의 기억 133개 파일은 회수 밖에 있었습니다. 원격 PC의 Claude 기억 15개와 세션 기록 23개는 Mac에서 보이지 않았습니다. 과거 작업 원장 10,413행 중 엔진 표시가 없는 행이 3,591행이었고, 어느 컴퓨터에서 했는지 적는 칸은 아예 없었습니다.

통합 방법은 고민 끝에 이렇게 정했습니다. 세 엔진의 기억을 한 저장소로 합치지 않고, 한 원장으로 묶습니다. 각 엔진의 기억 파일은 그 엔진이 계속 소유합니다. 대신 호스트와 엔진을 가리지 않는 원장 하나, 회수 하나, 인계 규약 하나를 둡니다.

세 엔진에는 각자 기억을 정리하는 자동 장치가 있습니다. 한 저장소에 몰면 그 장치들이 같은 파일을 고치게 될 것으로 예상했습니다. 실제로 부딪힌 사례는 아직 없고, 설계 단계의 판단입니다. 지금 회수에 연결된 것은 Mac의 Claude와 Codex뿐입니다.

원격 PC는 그날 기준 Mac보다 코드가 151커밋 뒤처져 있었습니다. 그래서 Mac을 주 작업 공간으로 두고, 원격 PC에는 점진적으로 백업하고, 필요할 때 옮겨 가며 쓰는 순서로 정했습니다.

PART 06 · Deltas기억은 다시 쓰지 않고 덧붙입니다

기억을 정리하는 방식도 바꾸고 있습니다. 피드백 기억 172개를 업무 유형 12개의 플레이북으로 묶습니다. 이때 기존 문장을 요약해 다시 쓰지 않습니다. 새 교훈을 항목으로 덧붙이고, 도움이 됐는지 해가 됐는지 횟수만 갱신합니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

다시 쓰지 않는 이유가 있습니다. 에이전트 문맥 공학(ACE) 논문은 두 가지 실패를 보고합니다. 간결하게 요약하다 도메인 통찰을 버리는 편향, 그리고 반복 재작성으로 세부가 깎이는 문맥 붕괴입니다. 제 하네스에도 정본을 제자리에서 덮어쓰다 생긴 장애가 있었고, 그 뒤 덮어쓰기 금지는 장애 교훈이 됐습니다. 이 플레이북은 11월 13일까지 그림자 모드로 돌고, 승격은 사람이 정합니다.

PART 07 · Limits이 숫자가 말하지 않는 것

열어 본 비율은 기억이 쓸모 있었는지를 직접 재지 않습니다. 회수 적중률은 10월 20일에 한 번 쟀을 뿐입니다. 2주 전후 비교도 같은 업무 구성에서 잰 통제 비교가 아닙니다. 이 기록은 한 사람의 사용 기록입니다.

원격 PC와 Aside 기억의 통합은 아직 하지 않았습니다. Aside의 기억에는 메일과 고객 작업 맥락이 들어 있어, 회수에 연결하기 전에 가림 처리가 먼저 필요합니다.

PART 08 · Closing이번 주에 시작할 수 있는 일

세 줄로 다시 정리합니다. 기억은 쌓기보다 꺼내기가 병목으로 보였습니다. 매 세션 싣는 기억은 작게 두고, 나머지는 경로를 주고 필요할 때 읽게 합니다. 여러 엔진과 컴퓨터의 기억은 한 저장소가 아니라 한 원장으로 묶기로 했습니다.

이번 주에는 에이전트의 기억 색인이나 지침 파일을 열어 크기를 재 보십시오. 그리고 기억 열 개를 무작위로 골라 두 가지를 표시합니다. 하나는 지난달 읽혔는지입니다. 세션 기록에서 그 기억 파일의 경로를 검색해 읽힌 적이 있으면 읽힌 것으로 봅니다. 다른 하나는 층입니다.

여러 업무에 공통으로 필요한 규칙이면 상시 후보, 특정 업무에서만 참고하는 사례면 검색 후보로 표시합니다. 30분이면 됩니다. 첫 입력은 한 줄입니다.

매 세션 싣는 기억: ____KB · 10개 중 지난달 읽힌 기억: ____개 · 상시 후보 ____개 · 검색 후보 ____개

읽힌 기억이 3개 미만이면, 상시로 싣는 색인을 줄이고 검색 후보에는 경로와 한 줄 설명만 남기십시오. 6개 이상이면 지금 구조를 유지해도 됩니다. 분류한 열 줄이 이 글의 산출물입니다.

함께 읽으면 좋은 글은 대규모 언어 모델(LLM)로 개인 노트를 운영한 기록인 Obsidian × LLM 2년 운영 실측 — 4만 노트 개인 RAG의 최종 아키텍처 5층과 에이전트의 지능과 기억을 한 파일로 — 하네스×RAG 최소 구현 myDNA.md입니다.

경험으로 배운 하네스 운영 교훈

1. AI 에이전트가 느리다는 불만, 모델보다 왕복 수부터 세십시오
2. AI 에이전트 비용은 토큰 총량이 아니라 성공 작업당 비용으로 봅니다
3. AI 가드레일은 지침 문장이 아니라 집행 장치입니다
4. AI 운영 대시보드를 늘리기 전에 ‘끄면 무엇이 달라지는가’를 물으십시오
5. 기업 AI의 기억은 쌓기보다 꺼내는 길이 먼저입니다 (이 글)
6. 특별편: AI가 코드를 쓰는 회사에 필요한 개발 하네스

짝 시리즈 · 기업 RAG 운영 교훈

• 입구 글: 사내 RAG는 벡터 DB보다 ‘다시 찾는 고리’가 먼저입니다
• 1편: 사내 RAG는 근거를 먼저 넣고, 모자랄 때만 찾으러 보내십시오
• 2편: 사내 RAG를 늘리기 전에 인용 점검기와 퇴역 기준부터 다십시오
• 3편: 사내 RAG 근거는 사실을 더할 뿐 권한을 더하지 않습니다 — 이 글의 짝