세션을 넘겨도 유지되는 기억 계층, 자동 메모리 추출, 팀 공유, 어시스턴트 일지까지 한 번에 정리합니다.
메모리 시스템은 "무엇을 오래 기억할지"를 분리해 다루는 계층형 구조입니다. 자동 메모리는 대화에서 반복되는 선호와 규칙을 뽑아 장기 기억으로 남기고, 세션 메모리는 긴 대화를 압축하며, 팀 메모리는 여러 팀메이트가 공유해야 하는 규칙을 동기화합니다.
memory/index.ts → memory/extraction.ts → memory/recall.ts → memory/session.ts → memory/team.ts → MEMORY.md
MEMORY.md는 모든 토픽 파일의 짧은 인덱스입니다. 여기에는 각 메모리의 이름, 설명, 연결된 파일 경로가 요약되고, 실제 내용은 개별 토픽 파일에 들어갑니다.
토픽 파일은 name, description, type 세 필드를 중심으로 구성됩니다. 이전 예시처럼 scope나 날짜 필드를 핵심 모델처럼 두는 설명은 맞지 않습니다.
# 토픽 파일 프론트매터 예시
---
name: testing-conventions
description: Use the real database for integration tests unless the user asks for a lighter path.
type: feedback
---
# 테스트 관례
실제 DB를 기본값으로 사용합니다. 목은 속도를 위해 예외적으로만 허용합니다.
name은 토픽을 안정적으로 식별하는 짧은 키이고, description은 리콜 단계에서 빠르게 판단할 수 있게 만드는 한 줄 요약입니다. type은 이 기억이 개인 취향인지, 팀 피드백인지, 프로젝트 사실인지 구분하는 분류 축입니다.
메모리는 저장 위치보다 먼저 내용의 성격으로 분류됩니다. 이 타입이 리콜과 병합의 기준이 됩니다.
"항상 실제 DB를 써 달라"는 요청은 project가 아니라 feedback입니다. 프로젝트 구조가 아니라 사용자가 반복해서 준 작업 규칙이기 때문입니다.
자동 메모리는 사용자가 매번 다시 설명하지 않아도 될 정보를 대화에서 골라 저장하는 층입니다. 핵심 기준은 "반복 가치가 있는가"와 "다음 세션에서도 도움이 되는가"입니다.
# 자동 메모리의 판단 예시
# 저장 적합
사용자는 문서 설명을 한국어로, 코드 주석은 영어로 유지하길 원한다.
# 저장 부적합
오늘은 src/api/user.ts를 먼저 고쳤다.
# 경계 사례
이번 주에 병합한 PR 목록은 보통 저장하지 않고,
그 안에서 반복되는 규칙이나 놀라운 제약만 추려서 기억한다.
자동 메모리는 대화와 분리된 백그라운드 흐름으로 추출됩니다. 응답 자체를 늦추지 않으면서, 새로 생긴 턴만 커서 기반으로 훑어 메모리 후보를 만들고 필요한 경우 토픽 파일을 갱신합니다.
MEMORY.md에 새 요약을 반영합니다메인 에이전트가 같은 범위에서 메모리 파일을 직접 수정했다면, 자동 추출기는 그 범위를 다시 쓰지 않고 건너뜁니다. 명시적 기억 쓰기가 자동 추출보다 우선합니다.
# 추출 파이프라인의 핵심 흐름
cursor -> new conversation turns -> extract candidates -> classify
-> merge into topic files -> refresh MEMORY.md
# 예외
if main-agent wrote memory files in this range:
skip range
advance cursor
새 세션이 시작되면 관련 메모리만 골라 주입합니다. 모든 메모리를 무조건 다시 넣지 않고, 현재 작업과 맞는 토픽만 선택해 컨텍스트 낭비를 줄입니다.
세션 메모리는 긴 대화에서 이미 지나간 부분을 짧게 압축해 두는 내부 요약입니다. 자동 메모리가 장기 기억이라면, 세션 메모리는 현재 세션 안에서 문맥 손실을 막는 압축 계층에 가깝습니다.
팀 메모리는 개인 인스턴스를 넘어서 여러 팀메이트가 같은 규칙을 공유할 수 있게 만듭니다. 변경 감지와 비밀 스캐닝이 함께 들어가며, 로컬 파일만 지운다고 서버의 팀 기억이 사라지지는 않습니다.
팀 메모리 파일을 로컬에서 지워도 다음 동기화 때 서버의 최신 상태가 다시 내려올 수 있습니다. 영구 삭제는 서버 쪽에서도 반영되어야 합니다.
어시스턴트 모드의 일일 로그는 자동 메모리와 다른 층입니다. 토픽별 장기 기억을 만들기보다, 최근 며칠의 작업 흐름을 날짜 단위로 이어 두는 작업 일지에 가깝습니다.
일일 로그는 매 세션 종료마다 독립 파일을 하나씩 찍는 식의 단순 이벤트 로그가 아닙니다. 또한 사용자가 별도 공개 커맨드로 강제 생성하는 개념으로 설명하면 과장됩니다. 핵심은 어시스턴트 모드에서 최근 작업 흐름을 날짜별로 유지하고, 리콜 시 최근 로그를 보조 자료로 함께 본다는 점입니다.
# 일일 로그의 개념적 예시
2026-03-28.md
## 진행 중인 흐름
- 인증 모듈 리팩터링 계속 진행 중
- 테스트 전략은 실제 DB 우선
## 다음에 바로 이어갈 점
- flaky 테스트 2건 재현 필요
- PR 설명 문구를 한국어로 다듬기
일일 로그는 시간 흐름을 보존하는 작업 일지이고, 자동 메모리는 시간이 지나도 다시 쓸 가치가 있는 규칙과 선호를 정리한 토픽 기억입니다. 둘을 섞으면 최근 진행 상황이 영구 기억처럼 굳어 버리기 쉽습니다.
메모리 기능은 제품 설정과 관리 정책의 조합으로 제어됩니다. 이전 설명처럼 공개된 CLAUDE_MEMORY=0, --no-memory, 혹은 단일 불리언 설정 하나로 전체 시스템을 끄는 식으로 이해하면 맞지 않습니다.
메모리 계층은 하나로 뭉친 단일 스위치가 아닙니다. 장기 토픽 메모리, 세션 압축, 팀 동기화, 어시스턴트 일지는 목적이 다르므로 켜짐과 꺼짐의 경계도 다르게 봐야 합니다.
name, description, type입니다MEMORY.md는 인덱스이며 200줄/25KB 제한을 넘기면 잘라내고 경고합니다Q1. 토픽 파일 프론트매터의 핵심 3필드는 무엇인가요?
name, description, type를 중심으로 식별, 요약, 분류를 수행합니다. 범위나 날짜를 핵심 모델처럼 두는 설명은 맞지 않습니다.Q2. 자동 메모리가 기본적으로 피해야 하는 것은?
Q3. 자동 추출기가 메인 에이전트의 메모리 쓰기를 같은 범위에서 발견하면?
Q4. 어시스턴트 모드의 일일 로그를 가장 잘 설명한 것은?
Q5. 메모리 기능의 제어 방식에 대한 올바른 설명은?