Claude Code로 진행하던 작업을 다음 날 Codex에서 시작한다. 외출 중에는 스마트폰의 ChatGPT로 확인한다.

이때, 각각의 AI는 어제의 대화를 자동으로 알지 못한다. AI마다 대화 이력과 저장 장소가 다르기 때문이다.

Locus System은 이러한 단절을 메우기 위해 만들고 있는 개인용 기억 시스템이다.

목표는, AI와의 대화나 작업에 대해 「완전한 기억」을 갖는 것이다. 세션이나 AI가 바뀌더라도 마치 하나의 대화가 계속 이어지는 것처럼, 과거의 판단이나 실패를 필요할 때 떠올릴 수 있는 상태를 지향하고 있다.

최종적으로는 이용자가 뒷단의 파일이나 저장 처리를 의식할 필요도 없게 만든다. 평범하게 AI와 대화하고 작업하는 것만으로 기억이 남고, 다른 AI로 옮겨가도 자연스럽게 다음 단계가 시작되는 상태를 목표로 한다.

이는 현재 달성된 상태가 아니라, Locus System이 지향하는 방향이다. 현재의 메커니즘에는 기록의 누락이나 AI에게 한 번에 전달할 수 있는 문장량 등의 제약이 있어, 아직 모든 것을 완전히 남겨서 떠올릴 수 있는 단계는 아니다.

또한, 현재는 주로 클라우드 AI와의 대화나 작업을 기록하고 있다. 클라우드 AI에게 전달하지 않은 정보를 Locus System만이 별도로 수집하는 메커니즘은 아니다.

현재는 다음의 세 가지를 조합하여 구동하고 있다.

• 사람이 읽을 수 있는 Markdown 파일
• AI가 어떤 파일을 읽고 쓸지 결정하는 운용 규칙
• 과거의 기록을 검색하고 변경분을 저장하는 프로그램

즉, Markdown은 Locus System의 최종 형태가 아니다. 모든 기억을 남기고 자연스럽게 떠올린다는 목표를 현재의 기술로 실제로 구동하기 위한 저장 방법이다.

왜 만들었는가

AI와 장기 프로젝트를 진행하면 매번 같은 문제가 발생한다.

• 새로운 대화를 시작하면 이전의 결정을 알지 못함
• AI를 바꾸면 처음부터 다시 설명해야 함
• 작업 로그가 길어지면 매번 전부 읽어들일 수 없음
• 전용 프로젝트 메모가 있어도 AI가 그 존재를 모르면 읽히지 않음
• AI가 제안한 것과 본인이 결정한 것이 뒤섞임

대화창 하나만을 계속 사용하면 일시적으로는 피할 수 있다. 하지만 대화가 길어질수록 다루기 어려워지며, AI나 서비스를 갈아타는 것도 어려워진다.

그래서 대화 외부에 기억을 두기로 했다.

다만 사람이 매번 "이것은 어느 파일에 쓸 것인가"라고 계속 관리하는 것이 목적은 아니다. 현재는 AI가 정해진 규칙에 따라 기록하고, 장래에는 저장소 그 자체를 의식하지 않아도 되는 상태로 다가가고자 한다.

현재 구현은 하나의 폴더

현재의 Locus System에서는 하나의 폴더를 기억의 중심으로 삼고 있다.

locus/
├─ rules.md
├─ history_summary.md
...

각각의 역할을 나누어 두었다.

데이터 형식을 Markdown으로 정한 이유는 단순하다.

• 사람이 그대로 읽을 수 있음
• AI가 특별한 소프트웨어 없이 읽을 수 있음
• 수동으로도 수정할 수 있음
• Git으로 변경 이력을 남길 수 있음
• 특정 AI 회사나 모델에 의존하지 않음

데이터베이스가 망가져도 현재의 기억은 Markdown으로서 남는다.

AI가 기동했을 때 읽는 것

모든 기록을 매번 읽으면 입력값이 너무 커진다.

그래서 기동 시에는 필요도가 높은 정보만 정해진 순서대로 읽는다.

1. rules.md
조작 규칙 확인
2. history_summary.md
...

history_summary.md는 길어진 log.md의 오래된 부분을 짧게 요약하기 위해 만들었다. 하지만 실제로는 2026년 4월을 마지막으로 요약 작업이 멈춰 있으며, 현재는 기동 시 읽히기는 하지만 새로운 사건은 들어있지 않다.

최근의 인계는 주로 ai_handoff.md

、log.md의 끝부분이며, 필요한 경우 RAG (Retrieval-Augmented Generation) 검색을 담당합니다. history_summary.md를 정기적으로 업데이트할지, 아니면 다른 방법으로 대체할지는 현재 남아있는 운영상의 과제입니다.

이것들을 읽음으로써 AI는 "이 시스템을 어떻게 다룰 것인가", "지금 어디까지 진행되었는가", "누구와 대화하고 있는가"를 처음에 파악합니다.

기동 시에 읽는 것은 핵심 파일과 최근 로그뿐입니다.

몇 달 전의 세세한 사건이나 특정 프로젝트의 상세 내용은 필요할 때만 검색합니다.

대화 중에는 무엇을 나누어 쓰는가

하나의 파일에 전부 쓰면 나중에 찾을 수 없게 됩니다.

따라서 내용에 따라 저장소를 나눕니다.

오늘 무엇을 했는가
→ log.md
프로젝트 고유의 결정이나 검증 결과
...

log.md는 추가 전용입니다. 오래된 기록을 삭제하지 않습니다.

또한, 기록에 "결정"이라고 쓸 수 있는 것은 본인이 실제로 결정한 것이거나 검증을 통해 확정된 것뿐입니다. AI의 제안을 이미 실시된 사실로서 저장하지 않도록 하고 있습니다.

여러 AI가 같은 파일을 쓰기 때문에, 각 기록에는 [Codex]나 [CC]와 같은 저자명도 붙입니다.

대화가 끝날 때 무엇을 저장하는가

대화의 구분점에서는 다음 처리를 수행합니다.

이번 작업을 log.md에 추가
↓
ai_handoff.md와 해당 프로젝트를 업데이트
...

이 일련의 처리를 LocusSave라고 부릅니다.

각 AI 도구가 가진 원래의 대화 이력은 저장 형식이 제각각입니다. 대응하는 이력은 사람과 AI의 발언을 추출하여 Markdown으로 변환합니다.

이때 이미지 본체나 긴 기계 출력물은 넣지 않으며, 비밀 정보로 보이는 문자열도 가립니다. 이력 파일 전체를 매번 새로 만드는 것이 아니라, 지난번 저장한 위치보다 뒤에 추가된 부분만 추가합니다.

왜 전부 직접 읽지 않고 검색하는가

log.md나 history/는 계속 사용할수록 커집니다. 모든 것을 AI에게 전달하는 방식으로는 기록이 늘어날수록 기동이 느려지고 입력량도 계속 늘어납니다.

그래서 정보를 두 가지로 나누고 있습니다.

매번 그대로 읽는 것

• 조작 규칙
• 초기 장기 요약 (현재는 업데이트 중단 중)
• 현재의 작업
• 이용자 측의 기본 전제
• 최근 로그

필요할 때만 검색하는 것

• 과거의 상세한 작업 기록
• 프로젝트별 기록
• AI와의 오래된 대화
• 환경 및 장애 대응 기록

예를 들어 "전에 3D 프린터의 치수 보정에서 무엇을 시도했는가"라고 물었을 때만, 그 이야기와 가까운 기록을 찾습니다.

이러한 분류 방식을 통해 기록이 늘어나도 기동 시에 읽는 양을 거의 일정하게 유지할 수 있습니다.

과거의 기록을 어떻게 검색하고 있는가

현재의 검색 부분은 다음과 같은 구성입니다.

RAG는 과거의 기록에서 질문과 유사한 문장을 찾아 그 문장을 현재의 AI에게 전달하는 부분입니다.

원래의 Markdown을 대체하는 것이 아닙니다. 검색용 데이터베이스는 Markdown으로부터 다시 만들 수 있는 인덱스(Index)로서 취급하고 있습니다.

문장을 검색용 수치로 변환한 것을 이 글에서는 벡터(Vector)라고 부릅니다.

현재는 본문 한 줄을 하나의 검색 단위로 합니다. 다만 본문만으로는 무슨 이야기인지 알 수 없게 되므로, 직전의 헤더(Heading)를 검색용 문장에 덧붙입니다.

예를 들어 원본 파일이 다음과 같은 형태라고 가정해 봅시다.

## 3D 프린터의 치수 보정
- 구멍이 설계값보다 작게 나옴
- 다른 재료로도 동일한 시험을 수행함

검색용으로는 다음과 같은 문장을 만듭니다.

3D 프린터의 치수 보정 / 구멍이 설계값보다 작게 나옴
3D 프린터의 치수 보정 / 다른 재료로도 동일한 시험을 수행함

검색 결과에는 원본 파일명과 행 번호도 포함되므로, 필요하다면 앞뒤 문장을 다시 읽을 수 있습니다.

삭제한 문장의 벡터가 검색 결과에 남아 있었다

현재의 RAG는 기록된 문장을 벡터로 변환하여 검색용 DB에 저장하고 있습니다. 벡터는 문장의 의미를 수치로 나타낸 것으로, 질문과 의미가 가까운 문장을 찾기 위해 사용합니다. 이 DB는 원래의 기록을 빠르게 찾기 위한 인덱스 역할을 합니다.

이 검색용 DB의 업데이트 과정에서 한 가지 버그가 있었습니다. 원래의 기록에서 문장을 삭제한 후에도, 그 문장으로 만든 벡터(Vector)가 DB에 남아 있어 검색 시 수정 전의 문장이 나타나는 경우가 있었습니다.

수정 전의 기록: 구멍이 설계치보다 작게 나왔다
수정 후의 기록: （이 문장은 이제 존재하지 않음）
검색 결과: 구멍이 설계치보다 작게 나왔다 ← 삭제한 문장이 나타남

원인은 추가·변경된 문장의 벡터는 DB에 저장했지만, 삭제된 문장의 오래된 벡터를 충분히 정리하지 않았기 때문입니다. 원래의 기록은 올바르게 수정되었더라도, 검색만은 오래된 내용을 기억하고 있었습니다.

그래서 기록을 가져올 때마다 현재의 문장과 DB 내의 벡터를 대조하도록 했습니다. 원래의 기록에 대응하는 문장이 존재하지 않는 벡터는 삭제합니다. 수정 후 모든 기록을 다시 가져온 결과, 631건의 오래된 벡터가 발견되어 삭제되었습니다.

'오래된 벡터가 남는다'는 것은, 원래의 문장은 이미 삭제되었음에도 불구하고 그 문장을 검색하기 위한 수치만 DB에 남아 있었다는 의미입니다.

여러 AI는 어떻게 연결되어 있는가

로컬(Local)에서 작동하는 AI 도구는 동일한 Locus 폴더를 직접 읽고 씁니다.

스마트폰이나 Web 버전 ChatGPT는 로컬 파일을 직접 읽을 수 없기 때문에, 읽기 전용 창구를 마련해 두었습니다.

로컬의 AI
→ 공유 폴더와 검색 커맨드
ChatGPT
...

ChatGPT를 통해서는 현재의 작업, 이용자 측의 기본 전제, 최근 로그를 한 번에 가져올 수 있습니다. 업데이트가 중단된 장기 요약도 가져올 수 있지만, 최근의 상세한 기록은 RAG(Retrieval-Augmented Generation)로 검색합니다.

현시점의 ChatGPT 측은 읽기 전용입니다. 로컬의 AI와 마찬가지로 자유롭게 다시 쓸 수 있는 단계까지는 개방하지 않았습니다.

중요한 점은, 현재의 AI들끼리 보이지 않는 곳에서 직접 통신하고 있는 것이 아니라는 사실입니다.

각각의 AI는 독립적이며, 현재의 구현 방식으로는 Locus에 저장된 기록만을 공유합니다. 저장되지 않은 작업이나 대화는 다른 AI에게 보이지 않습니다.

이는 Locus System의 정의가 아니라, 현재 남아 있는 제한 사항입니다. 목표는 대화나 작업을 놓치지 않고 자동으로 기록하여, 다른 AI가 필요한 부분을 스스로 떠올릴 수 있는 상태를 만드는 것입니다.

망가지지 않게 하기 위한 규칙

여러 AI가 장기간 동일한 기록을 사용하기 때문에, 편리함보다 먼저 지켜야 할 경계를 정해두고 있습니다.

• log.md는 추가 전용이며, 과거를 삭제하지 않는다
• 파일의 삭제나 덮어쓰기는 본인 확인 없이 수행하지 않는다
• AI의 제안을 본인의 결정으로 기록하지 않는다
• 필수 폴더가 보이지 않을 때는 검색 DB의 삭제 처리를 중단한다
• 문자 코드를 고정하여 일본어의 글자 깨짐을 방지한다
• Git으로 변경 이력을 남긴다
• 공개 게시물에는 개인정보, LAN 내의 접속처, 비밀 정보를 노출하지 않는다

검색 DB나 API는 다시 만들 수 있지만, 원래의 Markdown과 이력은 다시 만들 수 없습니다. 따라서 지켜야 할 순서는 항상 "원래 파일이 우선, 편리한 메커니즘은 나중"입니다.

현재 할 수 있는 것과 아직 할 수 없는 것

현재 가능한 것은 다음과 같습니다.

• 다른 AI로도 동일한 현재 위치에서 작업을 재개할 수 있다
• 과거의 결정이나 실패를 필요한 때에만 검색한다
• 프로젝트별 기록을 사람과 AI 모두가 읽는다
• AI나 모델을 교체해도 기억의 형식을 유지한다
• 스마트폰의 ChatGPT에서 로컬의 기억을 읽는다

반면, 현재는 다음과 같은 사항들이 완전히 자동화되지 않았습니다.

• 모든 대화나 작업이 아무것도 하지 않아도 반드시 기록된다
• AI의 내부 상태나 생각이 그대로 다른 AI에게 전달된다
• 기록되지 않은 사건을 떠올린다
• 검색하면 반드시 정답이 나온다
• 본인의 확인 없이 여러 AI가 마음대로 업무를 분담한다

이것들은 목표에서 제외한 것이 아니라, 아직 도달하지 못한 부분입니다.

Locus System이 지향하는 것은 모든 기억이 남고, AI가 필요한 순간에 문맥(Context)으로서 떠올리며, 이용자는 뒷단의 저장 방법을 의식하지 않아도 되는 상태입니다.

Markdown으로의 기록, LocusSave, RAG 검색은 그 목표를 향한 현재의 구현입니다.

요약

Locus System이 지향하는 흐름은 다음과 같습니다.

AI와 대화·작업
→ 모든 기억이 자동으로 남음
→ 필요한 기억을 AI가 스스로 선택
...

이용자는 저장, 검색, 파일명을 의식하지 않습니다.

현재는 그 목표를 다음과 같은 메커니즘으로 실현하고 있습니다.

필요한 전제를 읽고 기동
→ AI와 작업
→ Markdown으로 기록
...

현재 기억의 원본(Source of Truth)은 Markdown입니다.

RAG는 방대한 기록에서 필요한 부분을 찾는 색인 (Index), API는 다른 단말기나 AI가 읽을 수 있는 입구, LocusSave는 이번 변경 사항을 다음번으로 남기는 저장 처리 (Save process)입니다.

미래에 저장 위치나 검색 방법이 바뀌더라도, Locus System의 목표는 변하지 않습니다. 모든 기억을 남기고, 필요한 시점에 자연스럽게 떠올리며, 사용자가 뒷단(Back-end)을 관리할 필요가 없도록 만드는 것이 핵심입니다.

이 전체상을 전제로 하면, RAG의 모델 변경, 문장의 구분 방식, 오래된 검색용 데이터의 삭제와 같은 개선 사항들이 Locus System의 어느 부분을 건드리고 있는지 파악할 수 있게 됩니다.

검색 부분을 실제로 변경 전후로 측정하여 기록한 내용은 다음 기사에 정리해 두었습니다.

Discussion