CLAUDE.md 가볍게 쓰는 법에서 덜어낸 것들이 갈 곳 중 하나로 메모리를 꼽았습니다. 이번 편은 그 메모리 층을 다룹니다.

시작 전에 밝혀둘 것이 있습니다. 저는 AI 에이전트 메모리 플랫폼 Monet을 만들고 있습니다. 그리고 이번 주, 우리는 이 제품의 방향을 뒤집었습니다. 제네릭 메모리, 그러니까 뭐든 저장하고 뭐든 꺼내주는 층을 버리기로 한 겁니다. 이 글은 그 결정까지의 실패 기록입니다.

같은 설명을 세 번째 하고 있다면

세션이 끝나면 에이전트는 전부 잊습니다. 어제 함께 정한 설계 방향도, 그 라이브러리를 왜 기각했는지도 다음 세션에는 없습니다. 같은 맥락을 세 번째 설명하는 자신을 발견하면 누구나 같은 결론에 도달하죠. 메모리를 붙이자.

우리도 그랬습니다. 붙여보면 다음 문제가 옵니다.

전부 저장하는 메모리는 왜 실패하는가

메모리를 처음 붙이면 저장할 것이 넘칩니다. 세션 요약, 작업 상태, 진행 중인 태스크, 결정, 대화 조각. 잊는 게 문제였으니 많이 기억할수록 좋을 것 같고, 그래서 전부 넣게 됩니다.

몇 주 지나면 세 가지가 무너집니다.

검색이 죽습니다. “왜 이 구조를 택했더라"를 찾으면 활동 로그 열 개가 먼저 나옵니다. 결정의 이유 한 줄이 “오늘 A 파일을 고치고 B를 테스트했다” 더미에 묻히는 겁니다. 저장을 늘릴수록 꺼내는 일이 어려워지는 역설입니다.

상태가 거짓말을 합니다. “다음 할 일: X"를 저장해두면 다음 세션이 열릴 때 X는 이미 끝나 있기 일쑤입니다. 사람이 직접 처리했거나, 우선순위가 바뀌었거나. 작업 상태는 하루만 지나도 현실과 어긋나는데, 메모리는 그 낡은 스냅샷을 확신을 갖고 다음 세션에 건넵니다.

낡은 기억이 현재를 이깁니다. 한번 저장된 내용은 틀린 것으로 판명나도 검색에 계속 걸립니다. 새 결정을 추가해도 옛 결정이 사라지지 않으면, 다음 세션은 먼저 찾은 쪽을 믿습니다.

셋 다 저장이 부족해서 생긴 문제가 아닙니다. 아무거나 다 저장해서 생긴 문제입니다.

세 갈래 라우팅

그래서 방향을 뒤집었습니다. 무엇이든 받아주는 메모리 하나 대신, 정보를 종류별로 다른 곳에 보냅니다.

코드·깃·파일에서 다시 얻을 수 있는 것은 저장하지 않습니다. 디렉토리 구조, 함수 목록, 지난 커밋. 다음 세션이 직접 읽으면 되고, 직접 읽은 쪽이 항상 최신입니다. 전편의 리트머스(“이 줄을 지우면 다음 세션에서 실제로 무엇이 나빠지는가”)가 여기서도 그대로 작동합니다.

작업 상태와 결정 기록은 트래커·PR·코드 옆 문서로 보냅니다. 어디까지 했고 다음이 뭔지는 이슈의 일입니다. 왜 B 대신 A를 택했고 어떤 대안을 기각했는지는 티켓, PR 설명, ADR이 받습니다. 결정은 그것을 만든 작업의 맥락 안에서 읽혀야 하고, 나중에 코드를 고치러 온 사람이 찾아보는 곳도 거기니까요. 메모리 속 상태 스냅샷은 저장되는 순간부터 늙기 시작하지만, 트래커의 이슈는 닫히는 순간까지 현재형입니다.

메모리에는 에이전트의 행동을 조절하는 기록만 남깁니다. 반복해서 바로잡은 실수, 하지 말라고 한 것, 이 사용자가 일하는 방식. 그리고 그 기록이 쌓여 만들어진 원칙과 규칙. 코드에도 트래커에도 없는 것은 이제 이것뿐이고, 시간이 지나도 낡지 않고 쌓일수록 값이 오릅니다.

메모리에 남는 것: 원칙과 규칙

라우팅이 끝나면 메모리는 얇아집니다. 얇아진 만큼 강해집니다. 남는 건 두 층입니다. 행동을 바로잡은 기록들, 그리고 그 기록이 쌓여 나온 원칙과 규칙. 같은 교정이 세 번 반복되면 그건 사건이 아니라 규칙입니다.

규칙을 저장할 때는 두 가지를 함께 넣어야 합니다. 언제 발동하는지, 왜 존재하는지. “강제 푸시 금지"만 저장하면 다음 세션은 그 규칙을 언제 꺼내볼지 모릅니다. “git push –force를 치기 직전에 발동, 지난달 main 히스토리를 날린 사고가 이유"까지 있어야 규칙이 제때 나타나고, 이유를 아는 에이전트가 규칙을 지킵니다.

교정도 일급 기능이어야 합니다. 틀린 것으로 판명난 기억은 새 기억을 옆에 추가하는 게 아니라 명시적으로 덮어야 합니다. 덮지 않으면 옛 버전과 새 버전이 나란히 검색에 걸리고, 다음 세션은 아무거나 집습니다.

도구는 무엇으로 시작하나

  • 마크다운 파일부터. 리포에 lessons.md 하나 두고 반복된 교정과 거기서 나온 규칙만 적어도 절반은 해결됩니다. 설정 비용 제로, 검색은 grep. 대부분 여기서 시작하면 됩니다. 결정의 기록은 이 파일이 아니라 PR과 ADR에 남기세요.
  • 에이전트 내장 메모리. Claude Code의 메모리 디렉토리처럼 도구가 제공하는 층이 있다면 그걸 씁니다. 단, 위의 라우팅은 스스로 지켜야 합니다. 내장 메모리는 뭘 넣어도 막지 않으니까요.
  • 전용 메모리 도구. 규칙에 발동 시점을 붙이고, 교정을 일급으로 다루고, 상태 저장을 거절하는 층이 필요해지면 그때 전용 도구입니다. Monet이 지금 가는 방향이고, 그래서 저는 이해관계자입니다. 감안하고 읽어주세요.

실패는 몇 주간 직접 겪으며 검증했습니다. 새 방향이 정답인지는 아직 검증 중입니다. 지금 말할 수 있는 건 실패의 모양뿐이라, 이 글도 거기까지만 씁니다.

체크리스트

메모리 층을 이미 쓰고 있다면 다섯 가지만 확인해보세요.

  1. 활동 로그나 세션 요약이 메모리에 쌓이고 있지 않은가
  2. “다음 할 일"이나 결정의 이유가 메모리에 있지 않은가 (트래커와 PR이 제자리입니다)
  3. 저장된 규칙에 발동 시점과 이유가 붙어 있는가
  4. 틀린 기억을 명시적으로 덮는 교정 절차가 있는가
  5. 아무거나 검색했을 때 첫 결과가 정말 원하던 그 기억인가