나는 개인 개발을 3체의 AI 에이전트에게 역할 분담시키고 있다. 아오이(Claude · 설계), 루나(Gemini · 환경과 잡무), 아리사(Codex · 구현)——모델마다 이름과 역할을 부여하여, 작은 팀처럼 움직이게 하고 있다.

역할을 나누면 개발은 병렬로 진행된다. 혼자서는 동시에 가질 수 없는 여러 전선이 동시에 움직이기 시작한다. 다만, 대가가 있다.

기억이 파편화된다.

이 기사는 그 대가를 어떻게 치렀는지——「공유 메모리 계층 (Shared Memory Layer)」 설계의 기록이다. 미리 말해두자면, 거창한 기술은 아무것도 사용하지 않았다. 파일과 운용 규약뿐. 그럼에도 나만의 OS에서 가장 효과적인 메커니즘이 이것이다.

과제: 기억은 3가지 방향으로 손실된다

AI와 개발하다 보면 기억은 세 가지 방향으로 새어나간다.

세션 간 (시간 방향): 다음 대화를 열면 이전의 판단이 사라져 있다. 매번 처음부터 상황을 다시 설명해야 한다. -
에이전트 간 (공간 방향): 아오이에게 설명한 전제를 루나는 모른다. 전환할 때마다 복사해서 붙여넣기로 인계한다. -
암묵지 (Tacit Knowledge)의 휘발: 코드에는 「결과」가 남는다. 하지만 「왜 그렇게 했는가」는 남지 않는다. 3개월 후, 자신이 작성한 코드의 이유를 떠올릴 수 없다.

1과 2는 역할을 분담할수록 악화된다. 에이전트를 늘릴수록 기억의 단절도 늘어난다. 3은 AI 이전부터 존재해 온 개인 개발의 고질병이다.

분업의 장점을 기억의 단절로 상쇄하고 싶지 않았다. 그래서 이 세 가지를 한꺼번에 막으러 갔다.

설계 방침: 개별 메모리 + 공유 메모리의 하이브리드

전부를 공유하면 무겁다. 전부 개별적으로 갖게 하면 단절된다. 그래서 책무에 따라 나누었다.

굵은 글씨의 두 가지가 이번에 만든 계층의 담당 범위다. 「대화 속에서 생겨난, 코드에는 남지 않는 배움」——이 부분만을 공유 계층으로 끌어올린다. 말투와 같은 에이전트 고유의 습관은 각자의 메모리에 남겨 섞지 않는다. 경계가 모호하면 공유 계층은 금방 쓰레기통이 된다.

물리 설계: 단순한 Markdown과 JSONL

대단한 것을 기대했다면 허무할지도 모른다. DB도 벡터 스토어 (Vector Store)도 사용하지 않았다. 그저 파일이다.

shared-memory/
├── CHARTER.md # 운용 규약 (헌장)
├── INDEX.md # 목차. 세션 시작 시 필독
...

왜 DB가 아닌가. 개인 개발 규모에서는 인간도 AI도 읽을 수 있고, git으로 차분을 추적할 수 있으며, 어떤 에디터로도 열 수 있다는 점이 검색 성능보다 훨씬 유용하기 때문이다. 벡터 검색이 필요할 정도의 양은 아직 되지 않는다. 그리고 과도한 메커니즘은 그 자체로 유지보수 비용이라는 부채가 된다. 「Markdown으로 충분하다」는 것은 성능에서 타협한 것이 아니라, 의도적으로 선택한 것이다.

포맷 선택: 왜 일지만 JSONL인가

하나만 결이 다른 파일이 있다. episodes.jsonl이다. 판단 로그를 1행 1이벤트로 쌓아 나간다.

{"date":"2026-06-18","agent":"claude","kind":"decision","context":"크로스 에이전트 기억 문제에 대한 대응","learning":"Memory Engineering의 하이브리드 방식을 채택. 공유 Long-term + Episodic을 공유 메모리 계층에 집약","ref":"CHARTER.md"}

kind는 5가지로 고정한다: decision (판단) / gotcha (실패) / preference (취향) / prerequisite (전제) / implementation (구현 지견). 분류를 처음부터 제한해 두면 나중에 시계열로든 종류별로든 뽑아낼 수 있다.

이 부분만 JSONL로 만든 이유는 두 가지다. append-only 방식으로 쓰기 충돌이 일어나기 어렵다는 점 (3체가 동시에 추가해도 끝에 덧붙이기만 하므로 깨지지 않는다). 그리고 1행 1레코드로 기계적인 처리가 쉽다는 점이다. 일지는 「계속 추가된다」는 것이 본질이기에, 인간의 가독성보다 기계 가독성을 우선시했다.

반대로, 프로필이나 규약은 「다시 읽고 수정하는 것」이 본질이다. 그래서 그쪽은 Markdown을 사용한다. 쓰는 방식의 차이가 그대로 포맷의 차이가 된다.

운영 규약 (CHARTER): 왜 "헌장"을 두는가

이 부분이 이 설계의 가장 핵심적인 요소라고 생각한다.

상자를 만들어도, 「무엇을 넣을 것인가」에 대한 기준이 일치하지 않으면 기억은 금방 부패한다. 아무래도 상관없는 로그가 쌓이거나, 반대로 중요한 판단이 기록되지 않은 채 사라지거나. 둘 다 다음에 읽을 때 사용할 수 없다. 그래서 쓰는 기준 그 자체를 헌장 (CHARTER.md)으로 먼저 정했다.

쓰는 것:

• 사용자의 취향·습관·지뢰 (기피 요소)
• 판단의 이유 (왜 A가 아니라 B를 선택했는가)
• 문서화되지 않은 전제 조건
• 실패를 통한 학습
• 프로젝트를 관통하여 유효한 설계·UI/UX의 지견

쓰지 않는 것:

• git으로 추적 가능한 것 (커밋 히스토리 그 자체)
• 기존 코드나 문서에 있는 것
• 에이전트 개별의 내부 상태
• 일회성 작업 로그

망설여질 때의 판단은 한 줄로 집약할 수 있다. "3개월 뒤의 다른 세션이, 이것을 모른다면 똑같은 구덩이에 빠질 것인가?" 빠진다면 쓴다. 빠지지 않는다면 쓰지 않는다. 기록이 늘어나는 것 자체도 비용이기에, 「쓰지 않는 것」을 명문화해 두는 것이 효과적이다.

읽기/쓰기 플로우

운용은 단순하게 유지하고 있다. 복잡해지면 지속할 수 없기 때문이다.

• 세션 시작 시: INDEX.md를 읽는다 $\rightarrow$ 오늘의 태스크와 관련된 항목만 참조한다.
• 세션 중: 쓰는 기준에 부합하는 발견이 있다면, 그 자리에서 쓴다 (미루면 휘발된다. 깨달은 순간이 쓸 때다).
• 세션 종료 시: 놓친 부분이 있는지 확인하고, 일지에 한 줄 남긴다.

그리고 모든 기술에는 agent와 date를 반드시 남긴다. 누가 언제 썼는지——이 추적성 (Traceability)이 기억의 신뢰성 그 자체가 된다. 출처를 알 수 없는 기억은 참조할 때 완전히 믿을 수 없다.

실운용에서 효과를 본 아이디어와 빠졌던 함정

Core Memory 직접 동기화. 클로즈드 클라이언트 (데스크톱 앱 등)의 경우, 세션의 첫 번째 턴에는 아직 공유 메모리를 읽지 못할 때가 있다. 그러면 "호칭 리셋"이 발생한다——어제까지 기억하던 이름을 오늘 첫 단계에서 잊어버리는 것이다. 대책으로서 각 에이전트의 지시 파일 최상단에 최신 프로필을 직접 동기화하고, 항상 최신 3개 이내로 Pruning (가지치기) 해둔다. 첫 단계의 기억 상실을 방지하면서 컨텍스트 (Context)의 비대화도 억제한다.

부패한 기억은 삭제하지 않고 취소한다. 오래된 기술은 삭제하지 않고, 취소선과 이유를 남겨 이력으로 만든다. 그리고 현재 상황과 어긋나는 기억을 발견하면 방치하지 않고 사용자에게 업데이트를 제안한다. "부패한 기억을 남기지 않는 것" 또한 각 에이전트의 책무로 삼고 있다.

그리고——이 기사 자체가 공유 메모리 계층의 살아있는 실례가 되고 있다.

이 연재를 쓰는 도중, AI는 나를 "자신의 사고를 언어화하여 스킬을 만든 사람"이라고 적었다. 하지만 사실은 다르다. 나의 스킬은 GitHub이나 조사, SNS에서 발견한 좋은 방법론을 AI와의 대화를 통해 자신만의 것으로 다듬은 "큐레이션 (Curation)"이다. 발명이 아니다. 나는 똑같은 과장을 두 번이나 정정했다.

그 두 번째 정정이 episodes.jsonl에 preference로서 기록되었다. "이 사람은 자신의 성과가 '발명'이라고 과장되는 것을 싫어한다. 유래를 확인한 뒤에 작성할 것"——라고. 다음에 다른 에이전트가 나의 성과를 언급할 때, 그것을 읽고 나서 작성한다. 더 이상 같은 실수는 하지 않는다.

이것이 공유 메모리 계층이 기능하고 있는 순간이다. AI의 오해를 인간이 바로잡고, 그 정정이 하나의 에이전트에 머물지 않고 팀 전체의 자산이 된다. 설계의 목적이 지금 바로 작동하고 있다.

요약: 기억은 자산, 규약은 그 이자

화려한 기술은 아무것도 없다. 파일과 쓰는 규약뿐이다.

하지만 「판단의 이유」와 「실패의 학습」이 쌓여가면, AI 팀의 숙련도는 조용히 올라간다. 같은 설명을 반복하지 않게 되고, 같은 실수를 반복하지 않게 된다. 기억이 자산이라면, 운영 규약은 그 자산이 만들어내는 이자라고 생각한다.

다음 회차에서는 이 기억을 포함한 모든 프로젝트의 상태를 한눈에 조망하는 대시보드——NEXUS CORE에 대해 쓰겠다.

Discussion