새 세션은 왜 어제의 결정을 읽지 못할까요
먼저 답부터 말하면, MemoryCustodian은 코딩 에이전트에게 대화를 전부 기억시키는 도구가 아닙니다. 프로젝트에서 오래 남아야 할 결정과 제약만 저장소 안에 남겨, 다음 세션이 같은 설명을 다시 듣지 않게 만드는 방식에 가까워요.
코드는 현재 결과를 보여줍니다. 그런데 왜 SQLite를 쓰지 않았는지, 왜 오프라인 동작을 지켜야 하는지, 이미 검토했다가 버린 방법이 무엇인지는 코드만 읽고 알아내기 어렵습니다. 새 에이전트가 합리적으로 보이는 옛 선택을 다시 꺼내는 이유도 여기에 있어요.
MemoryCustodian이 건드리는 불편은 기억력보다 인수인계입니다. 사람이 바뀌지 않아도 채팅이 새로 열릴 때마다 프로젝트의 어제가 사라지니까요. 길게 운영하는 AI 코딩 프로젝트라면 이 재설명 시간이 은근히 크게 쌓입니다.
채팅창에 갇힌 이유를 저장소로 꺼냅니다
MemoryCustodian은 결정과 제약을 일반 Markdown 파일로 보관합니다. `brief`, `decisions`, `constraints`, `do-not-use`, `inbox`처럼 역할을 나눠 두고 Git으로 변경 이력을 확인하는 구조예요.
이 선택이 중요한 이유는 소유권입니다. 특정 AI 서비스의 기억 기능에만 맡기면 도구를 바꾸는 순간 맥락도 갈라질 수 있어요. 저장소 안의 파일이라면 Codex, Claude Code, Gemini처럼 서로 다른 에이전트가 같은 근거를 읽을 수 있습니다.
처음부터 거창한 지식 데이터베이스를 만들 필요도 없습니다. Codex CLI 설치 흐름을 잡은 뒤 프로젝트 결정 몇 개만 파일로 남겨도, 다음 작업에서 설명이 얼마나 줄어드는지 바로 비교할 수 있어요.
MemoryCustodian은 대화를 복사해 쌓는 것보다 `이 결정이 다음 작업에도 영향을 주는가`를 먼저 묻습니다. 이것이 단순 채팅 보관함과 갈리는 지점입니다.
기억이 많아질수록 오히려 다시 느려집니다
프로젝트 기억을 한 파일에 계속 붙이면 언젠가 또 다른 문제가 생깁니다. 로그인 화면을 고치는데 배포 역사와 디자인 논쟁까지 전부 읽히면, 에이전트가 써야 할 문맥만 커져요.
MemoryCustodian은 manifest를 통해 작업에 필요한 기억 파일만 고르는 방식을 택합니다. 계획 작업에는 결정과 제약을, 문서 작업에는 프로젝트 방향과 문체를 불러오는 식이죠.
잠깐 정리하면, 많이 기억하는 것과 지금 필요한 것을 잘 꺼내는 것은 다른 일입니다.
| 흔한 운영 방식 | 저장소 기억 방식 | 줄어드는 낭비 |
|---|---|---|
| 채팅마다 배경을 다시 설명 | 결정 파일을 다시 읽음 | 재설명 시간 |
| 버린 방법이 되살아남 | 거절한 선택을 따로 보존 | 반복 검토 |
| 긴 지침을 매번 통째로 로드 | 작업별 파일을 선택 | 불필요한 문맥 |
MemoryCustodian의 시장성은 기억 용량보다 이 라우팅에 있어요. AI 사용량이 늘수록 모든 과거를 넣는 비용도 커지기 때문에, 작은 문맥으로 정확한 결정을 되찾는 기능이 돈이 됩니다.
진짜 비용은 토큰보다 같은 회의를 다시 하는 시간입니다
에이전트가 과거 결정을 놓치면 코드 몇 줄만 잘못 만드는 데서 끝나지 않습니다. 팀원이 다시 설명하고, 이미 버린 안을 검토하고, 뒤늦게 제품 제약을 발견해 작업을 되돌리게 됩니다.
MemoryCustodian은 이 비용을 `검토 가능한 기억`으로 바꾸려 합니다. 기억 파일도 코드처럼 diff를 보고 리뷰할 수 있으니, 잘못 저장된 설명을 조용히 진실로 굳히는 위험을 줄일 수 있어요.
이 점은 요구사항정의서 예시에서 범위와 완료 기준을 남기는 이유와도 이어집니다. 문서가 많아서 좋은 게 아니라, 다음 사람이 같은 판단을 다시 만들지 않아야 문서가 제값을 합니다.
돈이 되는 구조도 여기서 나옵니다. 여러 에이전트와 긴 프로젝트를 운영하는 팀은 모델 하나의 성능보다 결정이 이어지는 운영 체계에 비용을 낼 가능성이 커요. 설치 도구 자체보다 팀용 검토, 정책, 권한, 기억 품질 점검이 서비스 영역으로 자랄 수 있습니다.
기록하기 전 무엇을 남길지부터 체크합니다
MemoryCustodian이 모든 내용을 자동으로 기억해준다고 기대하면 실망할 수 있습니다. 공식 설명도 초기 파일을 만든 뒤 사람이 프로젝트의 권위 있는 정보로 다듬어야 한다고 안내해요.
아래처럼 구분하면 시작이 조금 편합니다.
- 다음 기능에도 유지돼야 할 제약만 남겨둡니다.
- 이미 버린 접근과 버린 이유를 함께 적어두세요.
- 아직 합의되지 않은 생각은 확정 결정과 섞지 않는 편이 좋습니다.
- 오래된 기억은 코드 변경과 맞는지 주기적으로 확인하면 안전해요.
MemoryCustodian은 기억을 만드는 수고를 없애지 않습니다. 대신 그 수고가 채팅마다 사라지지 않게 해요. 기능정의서 작성방법처럼 기준을 짧고 분명하게 쓰는 습관이 있어야 효과도 커집니다.
자주 묻는 질문에서 도입 범위가 갈립니다
MemoryCustodian은 대화 내용을 자동으로 전부 저장하나요
아닙니다. MemoryCustodian은 모든 대화를 보관하는 기록기가 아니라, 프로젝트 방향과 결정, 제약, 버린 접근처럼 오래 남을 정보만 관리하는 쪽입니다. 무엇이 중요한 기억인지는 에이전트나 사람이 판단하고 CLI는 파일 구조와 작업을 안전하게 적용합니다.
자동 축적보다 검토 가능한 기억을 우선하므로 처음에는 정리할 일이 생겨요. 대신 잡담과 임시 추측이 프로젝트 규칙처럼 굳는 일을 줄일 수 있습니다.
별도 데이터베이스나 임베딩 서버가 필요한가요
공식 설계 기준으로 일상적인 운영은 저장소 안 Markdown 파일과 Git을 중심으로 돌아갑니다. 별도 호스팅 데이터베이스나 전용 임베딩 저장소가 필수인 구조는 아닙니다.
파일이 단순하다는 점은 장점이지만 검색과 자동 분류가 무한히 똑똑해지는 것은 아니에요. 프로젝트가 커지면 manifest와 영역별 기억 파일을 꾸준히 손봐야 합니다.
작은 개인 프로젝트에도 쓸 만한가요
한두 번 끝나는 실험이라면 MemoryCustodian을 관리하는 시간이 더 클 수 있습니다. 반대로 같은 결정을 여러 채팅에서 반복 설명했거나, Codex 오류 해결 과정에서 프로젝트 제약을 자주 놓쳤다면 작은 저장소에서도 시험할 이유가 있어요.
결정 세 개와 금지한 접근 한 개만 기록해 다음 세션의 제안이 달라지는지 확인하면 됩니다. 변화가 없다면 파일을 더 늘리기보다 어떤 기억이 실제 판단에 필요한지부터 다시 보는 편이 낫습니다.
결국 다음 세션이 덜 헤매면 기억은 값을 합니다
MemoryCustodian이 보여주는 흐름은 AI에게 사람처럼 모든 것을 기억시키는 방향과 조금 다릅니다. 프로젝트가 꼭 기억해야 할 사실을 팀 소유의 파일로 만들고, 필요한 작업에만 꺼내 쓰자는 쪽이에요.
이 방식이 잘 맞으면 에이전트는 더 똑똑해 보이기보다 같은 실수를 덜 반복합니다. 팀도 매번 긴 프롬프트를 만드는 대신 결정 하나를 제대로 남기는 데 집중할 수 있고요.
처음에는 거대한 기억 체계를 만들지 않아도 됩니다. 다음 세션에서 다시 설명하기 싫은 결정 하나를 골라 저장하고, 실제 제안이 그 결정을 지키는지 확인해보세요. 그 한 번의 차이가 MemoryCustodian의 가치를 가장 솔직하게 보여줍니다.
