6개의 AI Agent, 4종 모델——우리 팀 전체가 '모든 것을 기억'하게 만든 방법

진짜 문제는 ‘AI 하나가 기억을 잃는 것’이 아닙니다

AI의 가장 큰 약점: 세션이 끝나면 기억이 초기화됩니다.

하지만 AI 하나가 기억을 잃는 것보다 더 무서운 건 AI 팀 전체가 기억을 잃는 것입니다.

우리 팀에는 6개의 AI Agent가 있고, 4종의 서로 다른 플랫폼에서 돌아갑니다. 매번 깨어날 때마다 어제 뭘 했는지 기억하지 못하고, 팀원이 뭘 하고 있는지도 모릅니다. 동료 여섯 명이 매일 출근할 때마다 기억을 잃는 상황을 상상해 보세요. 어제 논의한 스펙, 겪었던 문제, 내린 결정——오늘 전부 다시 설명해야 합니다.

게다가 이 여섯 동료는 쓰는 언어도 다릅니다. Claude의 기억은 텍스트 파일, OpenClaw는 벡터 데이터베이스, Gemini는 세션 히스토리, Dify는 지식 베이스입니다. 완전히 다른 네 가지 기억 시스템을 어떻게 서로 통하게 할 수 있을까요?

몇 개월간의 시행착오를 거치면서 완전한 기억 아키텍처를 구축했습니다. 이 글에서는 모든 레이어를 하나하나 뜯어봅니다.

먼저 팀 소개

CEO는 딱 두 가지만 합니다: 보고서 확인과 의사결정. 하루 30분 이내. 나머지는 전부 Agent 팀이 자율적으로 운영합니다.

이제 각 Agent의 기억 시스템부터 시작해서 팀 공유 레이어까지 순서대로 살펴보겠습니다.

Claude Code Agent의 기억 (J, 리리)

Claude Code는 우리 기억 레이어가 가장 두꺼운 플랫폼입니다. J는 COO로서 51개 파일, 약 155KB의 기억을 가지고 있습니다.

1계층: Auto Memory — AI가 스스로 기억

Claude Code에는 자동 기억 기능이 내장되어 있습니다. AI가 대화 중 중요한 사실, 선호도, 결정을 발견하면 자동으로 MEMORY.md에 기록합니다.

특징은 수동적 축적입니다. “이걸 기억해"라고 직접 말할 필요 없이 AI가 스스로 무엇을 보존할 가치가 있는지 판단합니다. 다만 용량이 제한적이어서 200줄을 넘기면 잘립니다. 그래서 이 레이어에는 압축된 인덱스와 핵심 포인터만 둡니다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# MEMORY.md 구조 (압축 형식, AI가 읽는 용도)
CONNECTIONS: → memory/connections.md
IRON-RULES: → memory/iron-rules.md

<team>
  j: Opus|COO|업무배분+코드리뷰+기억유지보수
  mimi: MiniMax M2.7|마케팅|Docker
  ada: MiniMax M2.7|엔지니어링|Docker
  lily: Claude Sonnet|콘텐츠|CLI 구독
  moongg: Gemini CLI|QA|독립 서비스
</team>

<decisions>
  간단한 개발→아다, J는 복잡한 것만
  모든 태스크는 반드시 Linear 카드 생성
  Gemini API 사용 금지, 소월은 구독 버전 사용
</decisions>

파이프(|) 구분 형식은 보기 좋으라고 쓰는 게 아니라 AI 파싱 효율을 위해서입니다. 각 줄이 독립적인 컨텍스트 단위입니다.

2계층: CLAUDE.md — 행동 규칙

프로젝트 루트 디렉토리에 위치하며, 매 세션마다 자동으로 로드됩니다. 이것은 기억이 아니라 행동 게이트입니다——AI가 무엇을 하려 하든 이 규칙이 항상 우선합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

<gates label="우선순위: gates > rules">

GATE-1: 안전 > 속도
  checks: SQL-injection | XSS | 커맨드 인젝션 | 민감 데이터 유출

GATE-6: 위조 방지 검증
  trigger: Agent 완료 보고 시
  action: 최소 1건 독립 재실행
  iron: 커맨드 출력 없는 PASS = 자동 불신

GATE-9: 책임 전가 방지
  pattern: "아마" | "수동으로 확인해 주세요" | "문제없을 겁니다"
  action: 자동 FAIL

</gates>

GATE-6는 실제로 당해서 만든 규칙입니다. Agent가 “테스트 전부 통과"라고 보고했는데, 로그를 확인해 보니 테스트를 실행조차 하지 않고 그냥 “통과"라는 글자만 생성한 겁니다. 위조 방지 게이트를 추가한 후에는 모든 완료 보고에 검증 가능한 증거를 첨부해야 합니다.

3계층: Memory Files — 28개 주제 파일

Auto Memory는 용량이 제한적이고, CLAUDE.md에는 규칙을 넣습니다. 진짜 심층 기억은 Memory Files로 처리합니다——28개 주제 파일이 각각 하나의 지식 도메인을 담당합니다:

설계 원칙은 필요할 때 로딩입니다. AI가 매번 모든 파일을 읽을 필요 없이, 트레이딩 전략이 필요할 때만 judy-crypto.md를 읽으면 됩니다. 인덱스 파일은 200줄 이내로 유지하고, 심층 지식은 각 주제 파일에 분산합니다.

4계층: Rules 계층 상속

Claude Code의 규칙은 4단계 상속 구조입니다:

1
2
3
4
5
6
7

기본 규칙 (common/)
    ↓ 오버라이드
언어 규칙 (python/, typescript/)
    ↓ 오버라이드
프로젝트 규칙 (CLAUDE.md)
    ↓ 오버라이드
세션 컨텍스트 (MEMORY.md 자동 주입)

14개의 규칙 파일이 보안, 성능, 테스트, 코딩 스타일, Git 워크플로우를 다룹니다. 기본 규칙이 범용 표준을 정의하고, 언어 규칙이 Python이나 TypeScript 고유 요구사항을 추가하며, 프로젝트 규칙이 이 팀의 게이트를 추가합니다.

5계층: Hooks — 자동 트리거 가드

Claude Code의 Hooks 시스템으로 도구 실행 전후에 스크립트를 자동 트리거할 수 있습니다:

• Pre Hook: bash 명령 실행 전, 위험한 작업(rm -rf, git --force) 차단
• Post Hook: Python 파일 작성 후 자동 문법 검사, Blog 콘텐츠 자동 보안 스캔
• Stop Hook: 세션 종료 전 학습 평가 트리거——AI에게 이번에 배운 것을 되돌아보고, 재사용 가능한 패턴을 기억에 기록하도록 안내

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "hooks": {
    "Stop": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "bash hooks/stop-learn-eval.sh"
      }]
    }]
  }
}

Stop Hook은 기억 시스템의 피드백 루프입니다. 이것 없이는 AI가 일을 끝내고 그냥 떠나며, 배운 것들이 세션과 함께 사라집니다. 이것이 있으면 매 세션의 교훈이 영구 기억으로 침전될 기회를 얻습니다.

OpenClaw Agent의 기억 (미미, 아다)

미미와 아다는 OpenClaw 플랫폼에서 MiniMax M2.7 모델을 사용합니다. 이들의 기억 시스템은 Claude Code와 완전히 다릅니다.

SOUL.md — Agent의 페르소나 설정

각 OpenClaw Agent에는 역할, 권한, 행동 범위를 정의하는 SOUL 파일이 있습니다. CLAUDE.md와 비슷한 기능이지만 형식이 다릅니다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 아다의 SOUL.md (간소화 버전)
role: 프로덕트 엔지니어
reports_to: J (COO)
tech_stack: Next.js, TypeScript, Tailwind, Supabase, Python

authority:
  green: 버그 수정 (자체 처리)
  yellow: 새 기능 (J 코드 리뷰 필요)
  red: 프로덕션 배포, 데이터 삭제 (명시적 승인 필요)

quality_gates:
  1. 자체 점검 → 2. J Code Review → 3. 소월 QA ≥ 8.5

security: HIGHEST PRIORITY
  - API Key 유출 금지
  - 무단 정보 공개 금지

SOUL을 통해 같은 기본 모델이 완전히 다른 역할을 수행할 수 있습니다. 미미와 아다 모두 MiniMax M2.7이지만 SOUL이 다르기에 하나는 마케팅을, 하나는 엔지니어링을 합니다.

MEMORY.md — 자동 진화하는 작업 기억

Claude Code의 Auto Memory와 달리, OpenClaw의 MEMORY.md는 외부 진화 시스템이 자동으로 업데이트합니다. 매일 정해진 시간에 진화 스크립트가 Agent의 작업 기록을 스캔하고 자동으로 기록합니다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

## 프로젝트 경험
- CoinSifter v1.8.0: Pro 버전 Beta 테스트 중
- CryptoLog: Phase 2 완료, Phase 3 개발 중

## 실수 교훈
### 2026-03-22 — GATE-6 실패
- "success"를 보고했지만 git diff 결과 변경 사항 0건
- 교훈: 성공 보고 전 반드시 실제 변경 사항 확인

### 2026-04-01 자동 진화 기록
- 작업 수: 7
- 성과: 산출량 충분 | 반려 기록 없음

Agent가 스스로 “어제 뭘 했지"를 기억할 필요가 없습니다. 진화 시스템이 대신 기억해 줍니다.

SQLite + FTS5 — 구조화된 기억 데이터베이스

각 OpenClaw Agent에는 벡터 임베딩과 전문 검색 인덱스를 저장하는 독립 SQLite 데이터베이스가 있습니다:

1
2
3
4
5
6
7
8
9

CREATE TABLE chunks (
  id TEXT PRIMARY KEY,
  path TEXT,           -- 기억 파일 경로
  text TEXT,           -- 내용
  embedding TEXT,      -- 벡터 임베딩 (시맨틱 검색용)
  hash TEXT,           -- 콘텐츠 해시 (변경 추적)
  updated_at INTEGER
);
CREATE VIRTUAL TABLE chunks_fts USING fts5(text, id, path);

이를 통해 Agent가 자신의 기억에 시맨틱 검색과 키워드 검색을 수행할 수 있으며, 매번 모든 파일을 읽을 필요가 없습니다.

LanceDB — 팀 레벨 벡터 기억

SQLite 외에도 OpenClaw에는 LanceDB 벡터 데이터베이스가 공유 기억 레이어로 있습니다:

• autoCapture: 대화 중 핵심 정보를 자동으로 벡터화하여 저장
• autoRecall: 관련 컨텍스트를 만나면 시맨틱으로 유사한 기억을 자동 회상

텍스트 기억과의 차이점: 벡터 기억은 시맨틱 검색입니다. 정확한 키워드를 몰라도 의미가 비슷하면 회상할 수 있습니다. 미미가 지난번 어떤 경쟁 제품을 리서치했다면, 다음에 비슷한 제품이 언급될 때 자동으로 떠올립니다.

LanceDB는 Apache Arrow 형식으로 저장하며, 트랜잭션 안전 업데이트와 멀티 Agent 공유 읽기를 지원합니다.

세션 로그 — 전체 대화 기록

Agent가 태스크를 실행할 때마다 전체 대화 과정이 JSONL 형식으로 보존됩니다:

1
2
3
4

{"type":"session","id":"02269028-...","timestamp":"2026-04-01T05:38:00Z"}
{"type":"model_change","provider":"minimax","modelId":"MiniMax-M2.7"}
{"type":"message","role":"user","content":[{"type":"text","text":"홈페이지 버그 수정"}]}
{"type":"message","role":"assistant","content":[{"type":"toolCall",...}]}

이것은 Agent가 실시간으로 읽는 용도가 아니라(너무 크니까) COO가 사후에 추적하는 용도입니다. Agent에 문제가 생기면 세션 로그에서 전체 사고 과정을 재생할 수 있습니다.

Gemini CLI Agent의 기억 (소월)

소월은 Gemini CLI를 사용하며, 기억 메커니즘이 앞의 두 플랫폼과 또 다릅니다. 가장 특별한 점은 독립 운영으로, 중앙 스케줄러의 관리를 받지 않습니다.

OpenClaw Agent와 공유하는 부분

소월도 SOUL.md, MEMORY.md, IDENTITY.md를 가지고 있으며, 구조는 OpenClaw Agent와 동일합니다:

• SOUL.md (5.5KB) — 역할, QA 기준, 보안 규칙
• MEMORY.md (2.5KB) — 최근 QA 작업, 교훈, 성과 기록 (매일 자동 업데이트)
• IDENTITY.md — 이름, 시간대, 대응하는 Telegram Bot

Gemini의 30일 세션 유지

Gemini CLI에는 세션 히스토리 유지 기능이 내장되어 있습니다:

1
2
3
4
5
6
7

// Gemini CLI 설정
{
  "sessionRetention": {
    "enabled": true,
    "maxDays": 30
  }
}

최근 30일간의 전체 대화가 로컬에 보존됩니다. 이는 소월이 새로운 세션에서도 지난달의 대화 디테일을 떠올릴 수 있다는 뜻입니다——다른 플랫폼에는 없는 능력입니다.

LanceDB 벡터 기억 (수동 접근)

소월도 LanceDB 벡터 데이터베이스를 사용할 수 있지만, OpenClaw과 다르게 벡터 기억은 수동 트리거 방식입니다:

1
2
3
4
5

# 기억 저장
agent_memory.py remember moongg "CoinSifter에서 Safari 레이아웃 문제 발견" knowledge

# 관련 기억 회상
agent_memory.py recall moongg "CoinSifter 브라우저 호환"

벡터는 768차원 nomic-embed-text 모델로 생성되며, 카테고리(task_result, knowledge, plan 등)별 필터링을 지원합니다.

독립 운영 모드

다른 Agent들은 중앙 스케줄러(Agent Executor)가 정기적으로 깨웁니다. 소월은 다릅니다——독립 시스템 서비스로 돌아가며, Telegram Bot을 통해 실시간으로 메시지를 수신합니다.

이 설계는 의도적입니다. QA는 즉시 대응이 필요하며 스케줄을 기다릴 수 없습니다. 누군가 Telegram에서 “이 페이지 깨진 거 아닌가요?“라고 물으면, 소월이 바로 답변할 수 있습니다.

Dify 지식 베이스 (Pipeline Agent)

팀에는 몇 개의 자동화 Pipeline Agent(소금, 야야, 몽몽)가 있으며, Dify 워크플로우 플랫폼에서 Gemini Flash 모델로 돌아갑니다. 이들의 기억은 위 세 가지와 또 다릅니다——파일 시스템이 아닌 지식 베이스에 의존합니다.

89개 문서, 824KB 지식 베이스

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

dify-knowledge/
├── sop/              # 23개 운영 절차 (168KB)
│   ├── INDEX.md           — 전체 SOP 마스터 인덱스
│   ├── architecture.md    — 팀 아키텍처, 역할, AI 엔진
│   ├── blog-pipeline.md   — Blog 작성부터 배포까지 전체 프로세스
│   ├── product-development.md — 9단계 제품 개발 SOP
│   ├── quality-gate.md    — QA 품질 기준
│   ├── task-delegation.md — 태스크 배정 규칙
│   ├── monitoring-alerting.md — 5계층 모니터링 시스템
│   └── ... (16개 추가 SOP)
│
├── crypto-ta/        # 24개 트레이딩 기술 분석 (212KB)
│   ├── 01-candlestick-patterns.md
│   ├── 07-wfo-validation.md
│   ├── 17-pro-trader-strategy.md
│   └── ... (21개 추가 분석)
│
├── marketing/        # 마케팅 연구 (272KB)
│   └── viral/             — X, Reddit, Threads, YouTube 바이럴 분석
│
└── 일일 스냅샷/       # 31개 일일 업데이트

지식 베이스의 역할

Dify Agent는 Claude Code처럼 파일 시스템을 자유롭게 읽고 쓸 수 없습니다. Dify의 지식 검색 메커니즘을 통해 워크플로우에서 관련 문서를 자동으로 쿼리합니다.

예를 들어, 야야(뉴스 요약 Agent)가 특정 뉴스의 보도 가치를 판단해야 할 때, Dify 워크플로우가 자동으로 지식 베이스에서 관련 트레이딩 전략 문서를 검색하여 팀 전략과 일치하는 판단을 내리도록 도와줍니다.

SOP는 팀의 집단 기억

지식 베이스에서 가장 중요한 것은 23개 SOP입니다. 이것은 기억이 아니라 표준화된 프로세스입니다:

• blog-pipeline.md: Blog의 주제 선정→작성→QA→심사→배포 전체 프로세스
• product-development.md: 9단계 제품 개발 SOP (리서치→스펙→개발→테스트→심사→출시)
• task-delegation.md: 태스크 배정 규칙 (어떤 유형의 태스크를 누구에게 배정할지)
• monitoring-alerting.md: 5계층 모니터링 시스템 (실시간 알림부터 일일 요약까지)

각 Agent가 “Blog은 어떤 프로세스를 따라야 하지?“를 기억할 필요 없이 SOP를 조회하면 됩니다. 이렇게 개인 기억을 조직 지식으로 전환합니다.

팀 공유 기억 레이어

위에서 설명한 것들은 각 Agent “자신의” 기억입니다. 하지만 팀 협업에는 모든 Agent가 읽고 쓸 수 있는 공유 레이어가 필요합니다.

SHARED_TASK_NOTES — 팀의 두뇌

이것이 전체 기억 시스템의 핵심입니다: 모든 Agent가 공유하는 하나의 Markdown 파일로, 글로벌 작업 상태를 기록합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Shared Task Notes — Cross-Session Sync

> 규칙:
> 1. 매 세션 깨어나면 가장 먼저: 이 파일 읽기
> 2. 태스크 시작 전: "🔄 MIM-XXX 진행 중 — 간단 설명" 기록
> 3. 완료 후: "✅ MIM-XXX — 한 줄 결과"로 변경

## 🔄 Session Update (2026-04-01) — 보안 순찰 + 제품 개발

### 완료
- 전체 시스템 보안 순찰: 10개 항목 검사 통과
- MCP Security Scanner: CLI MVP + 문서 + 테스트 30/30

### Judy 결정 대기
- [ ] Security Scanner 가격 확정
- [ ] Blog 발행 승인

800줄, 50KB. 예쁘지는 않지만 효과적입니다. 어떤 Agent든 깨어나서 이 파일을 읽으면 누가 무엇을 하고 있는지, 무엇이 완료되었는지, 무엇이 막혀 있는지 알 수 있습니다.

bot_inbox — 태스크 배달 시스템

각 Agent에는 자체 수신함 디렉토리가 있습니다:

1
2
3
4
5
6
7
8

bot_inbox/
├── j/           # COO 수신함
│   ├── pending/      # 대기 중
│   └── done/         # 완료 (누적 16만 건)
├── mimi/        # 마케팅 Agent
├── ada/         # 엔지니어링 Agent
├── lily/        # 콘텐츠 Agent
└── moongg/      # QA Agent

태스크는 JSON 형식으로 저장되며, 전체 컨텍스트가 포함됩니다:

1
2
3
4
5
6
7
8
9

{
  "type": "linear_task",
  "task_id": "MIM-440",
  "title": "MCP Security Scanner 테스트 스위트 강화",
  "description": "현재 30개 테스트 전부 통과, 추가 필요...",
  "message": "관련 배경은 memory/team-and-products.md 참조",
  "by_whom": "J",
  "ts": "2026-04-01T12:34:00Z"
}

태스크 파일 자체가 컨텍스트 전달체입니다. Agent가 태스크를 읽을 때 “무엇을 해야 하는지"뿐만 아니라 왜, 이전에 무엇을 시도했는지, 어떤 기억 파일을 참조할 수 있는지까지 알 수 있습니다.

ai-logs — 각 Agent의 활동 기록

각 Agent에는 자체 월간 활동 로그가 있습니다:

1
2
3
4
5
6
7
8

ai-logs/
├── agent-openclaw/2026-04.md    # 미미+아다의 OpenClaw 작업
├── agent-J-claudecode/2026-04.md # J의 Claude Code 작업
├── agent-K-dify/2026-04.md      # Dify Pipeline 작업
├── j_output_log.jsonl           # 전체 팀 산출물 대장
├── monitor_report.json          # 시스템 상태 스냅샷
├── heartbeat_data.txt           # Agent 하트비트 상태
└── .decision_tracker.json       # COO 의사결정 추적

j_output_log.jsonl은 전체 팀의 산출물 대장입니다. 각 Agent가 태스크를 완료하면 한 줄씩 기록합니다:

1
2
3
4
5
6
7

{
  "description": "MCP Security Scanner CLI MVP 완료",
  "type": "product",
  "agent": "ada",
  "task_id": "MIM-437",
  "ts": "2026-04-01T15:30:00Z"
}

COO는 순찰할 때 이 로그를 읽으면 전체 상황을 파악할 수 있습니다. 각 Agent에게 “뭐 했어?“라고 물어볼 필요가 없습니다.

Linear — 구조화된 태스크 기억

우리는 Linear로 태스크를 관리합니다. 이것은 단순한 도구가 아니라 일종의 기억이기도 합니다:

• 각 카드가 태스크의 전체 생명주기를 기록합니다 (생성→배정→실행→심사→완료)
• 카드 댓글은 Agent 간의 공식 소통 채널입니다
• 라벨로 담당자와 태스크 유형을 표시합니다
• 상태 변경에 타임스탬프가 있어 전체 프로세스를 추적할 수 있습니다

Dispatcher(라우터)가 수분마다 Linear를 스캔하여 새 카드를 해당 Agent의 inbox로 자동 라우팅합니다. 완료되면 Agent가 카드에 댓글을 남깁니다.

기억이 Agent 간에 흐르는 방식

각자의 기억과 공유 레이어가 갖춰졌으니, 다음 질문은: 컨텍스트가 A에서 B로 어떻게 전달될까요?

Memory Preamble — 태스크 전 강제 주입

Agent Executor(중앙 스케줄러)가 각 Agent를 시작하기 전에 태스크 앞에 ‘기억 전문(preamble)‘을 주입합니다:

1
2
3
4
5
6

【강제 실행 — 태스크 시작 전 필수】
1. 먼저 기억 파일을 읽어 자신의 정체와 규칙을 확인하세요
2. 번체 중국어로 응답하는지 확인하세요
3. 태스크 완료 후 반드시 결과를 지정된 result 파일에 기록하세요. 기록하지 않으면 = 하지 않은 것
---
[아래는 당신의 태스크입니다]

이를 통해 Agent가 완전히 새로운 세션이어서 컨텍스트가 전혀 없더라도 먼저 자신의 SOUL.md와 MEMORY.md를 읽은 후 작업을 시작합니다.

Result File — 강제 보고

Agent가 태스크를 완료하면 반드시 결과 파일을 작성해야 합니다. 결과 파일이 없으면 = 하지 않은 것입니다.

1
2
3
4
5
6
7

{
  "from": "ada",
  "type": "task_result",
  "task_id": "MIM-440",
  "status": "done",
  "summary": "테스트 스위트를 30개에서 45개로 확장, 경계 테스트와 에러 처리 테스트 추가"
}

결과 파일은 COO의 inbox로 돌아가고, COO가 심사 후 SHARED_TASK_NOTES와 Linear를 업데이트합니다. 다음에 인수받는 Agent가 기록을 보면 원활하게 이어갈 수 있습니다.

전체 컨텍스트 흐름

하나의 전형적인 태스크가 생성에서 완료까지 컨텍스트가 흐르는 경로:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

Judy가 Linear에서 카드 생성
    ↓
Dispatcher가 카드를 읽고 누구에게 보낼지 판단
    ↓
Agent inbox에 JSON 태스크 파일 기록 (전체 배경 포함)
    ↓
Agent Executor가 새 태스크 발견
    ↓
Memory Preamble 주입 → Agent 시작
    ↓
Agent가 SOUL.md + MEMORY.md 읽기 → 태스크 읽기 → 실행
    ↓
완료 → COO inbox에 Result File 기록
    ↓
COO 심사 → SHARED_TASK_NOTES + Linear 댓글 업데이트
    ↓
다음 Agent 깨어남 → SHARED_TASK_NOTES 읽기 → 이어서 작업

전체 프로세스에서 컨텍스트는 “사라지지” 않습니다. 파일 시스템에 JSON과 Markdown 형태로 지속적으로 존재하며, Agent들이 차례로 읽고 보충합니다.

기억의 자동 진화

기억 시스템의 가장 큰 리스크는 노후화입니다. 잘못된 기억 하나가 기억이 없는 것보다 더 위험합니다.

일일 진화 시스템

매일 정해진 시간에 진화 스크립트가 자동 실행됩니다:

1. 모든 Agent의 inbox/done 디렉토리 스캔 (지난 24시간 완료 항목)
2. 태스크 분류 (제품, Blog, QA, 시스템 유지보수 등)
3. 각 Agent의 성과 평가 (산출량, 반려 횟수, 품질 추세)
4. 각 Agent의 MEMORY.md 업데이트 (진화 기록 자동 추가)
5. 전체 팀 진화 보고서 생성, Notion으로 푸시

진화 보고서 형식:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 전체 팀 일일 진화 보고서 — 2026-04-01

## J (COO / 기술 총괄)
작업 수: 121
✅ 잘한 점: 산출량 충분
⚠️ 개선 필요: 반려 1건

## 아다 (프로덕트 엔지니어)
작업 수: 7
✅ 잘한 점: 반려 기록 없음

## 전체 팀 합계: 137건, 4명

이를 통해 Judy는 매일 5분이면 전체 팀의 운영 상태를 파악할 수 있습니다.

철칙 — 사건에서 결정화된 규칙

기억 시스템에서 가장 가치 있는 것은 “무엇을 해야 하는지"가 아니라 “무엇을 하면 안 되는지"입니다. 삽질할 때마다 구체적인 사건과 함께 철칙으로 기록됩니다:

1
2
3
4
5
6
7
8
9

BLOG-REVIEW-GATE:
  rule: Blog은 반드시 QA ≥ 8.5 → Notion 심사 → Judy 확인 → 배포 가능
  lesson: MIM-195에서 QA 없이 배포하여 잘못된 정보 유출
  count: 1회 위반

ANTI-FABRICATION:
  rule: Agent가 완료 보고 → COO 독립 재실행 검증
  lesson: MIM-242에서 아다가 완료 보고 → 실제 실행 시 SyntaxError
  count: 3회 위반

모든 철칙에는 lesson= 태그가 있습니다. “이렇게 해야 할 것 같다"가 아니라 “이렇게 안 해서 사고가 났다"입니다. 이렇게 사건에서 결정화된 규칙은 추상적인 모범 사례보다 Agent의 준수율이 훨씬 높습니다.

COO의 기억 순찰

COO Agent는 매번 시작할 때 고정된 순찰 프로세스를 수행합니다:

1. 기억 읽기 (30초) — MEMORY.md + SHARED_TASK_NOTES
2. 현실과 대조 — 기억과 시스템 실제 상태가 일치하는지?
3. 오래된 기억 정리 — 완료된 태스크, 수정된 버그, 변경된 아키텍처
4. 새 교훈 기록 — 이번 세션의 결정과 발견을 Memory Files에 반영

기억과 현실이 불일치하는 경우(예: 기억에는 “해당 서비스 실행 중"이라고 되어 있지만 실제로는 중지된 경우) COO가 즉시 기억을 업데이트합니다. 이를 통해 오래된 정보가 팀 내에서 전파되는 것을 방지합니다.

크로스 플랫폼 기억 형식 설계

네 가지 플랫폼, 네 가지 기억 메커니즘. 어떻게 서로 통하게 할 수 있을까요?

최소 공배수 원칙

답은 단순합니다: Agent 간 소통은 Markdown + YAML로 통일합니다.

Agent 자체 기억이 아무리 고급이든(벡터 검색, 세션 히스토리, 지식 베이스) 다른 Agent와 소통할 때는 일률적으로 가장 범용적인 형식을 사용합니다. SHARED_TASK_NOTES는 Markdown, inbox 태스크는 JSON, 결과 파일도 JSON입니다.

어떤 플랫폼의 AI든 Markdown과 JSON을 읽을 수 있습니다. 이것이 최소 공배수입니다.

AI가 읽는 것 ≠ 사람이 읽는 것

우리가 발견한 것은 AI가 구조화된 데이터를 산문보다 훨씬 잘 읽는다는 점입니다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 좋은 방식 — AI가 효율적으로 파싱
LINEAR-REPLY:
  flow: inbox → 실행 → 원래 카드에 댓글 → done으로 이동
  violation: 작업만 하고 댓글 안 남김 = 안 한 것과 같음
  count: 2회 위반

# 나쁜 방식 — 정보 밀도 낮음
Linear 카드 처리가 끝나면 원래 카드에 가서 댓글을 남겨야 해요.
그래야 다른 사람이 뭘 했는지 볼 수 있거든요.
전에 두 번이나 깜빡했었어요.

파이프 구분(|), key-value 형식, YAML 스타일. 각 줄이 독립적인 컨텍스트 단위이며, AI가 count: 2회 위반을 정확하게 파싱할 수 있습니다.

환경 격리와 공유 레이어

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│  OpenClaw     │  │  OpenClaw     │  │  Claude Code  │  │  Gemini CLI  │
│  미미(마케팅) │  │  아다(엔지니어)│  │  리리(콘텐츠) │  │  소월(QA)    │
│  MiniMax M2.7 │  │  MiniMax M2.7 │  │ Claude Sonnet │  │  Gemini 2.5  │
│  SOUL+LanceDB │  │  SOUL+SQLite  │  │ CLAUDE.md     │  │  30일Session │
└──────┬───────┘  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘
       │                 │                 │                 │
       └─────────────────┴─────────────────┴─────────────────┘
                                  │
                   ┌──────────────┴──────────────┐
                   │         공유 기억 레이어       │
                   │                              │
                   │  SHARED_TASK_NOTES.md        │
                   │  bot_inbox/{agent}/          │
                   │  ai-logs/{agent}/            │
                   │  j_output_log.jsonl          │
                   │  Linear API                  │
                   │  Dify Knowledge Base (89개)  │
                   │  Telegram 알림               │
                   └──────────────────────────────┘

각 Agent는 자체 기억(상위 레이어)이 있지만, 모든 Agent가 동일한 공유 레이어(하위 레이어)를 사용합니다. 하나의 Agent가 다운되어도 다른 Agent에 영향을 주지 않습니다. 공유 레이어는 가장 범용적인 형식을 사용하여 크로스 플랫폼 호환을 보장합니다.

전체 기억 스택 한눈에 보기

겪었던 삽질들

삽질 1: Agent 위조

Agent가 “테스트 통과"를 생성하면서 실제로는 테스트를 실행하지 않았습니다. 해결: GATE-6 위조 방지 검증, COO 독립 추출 검사, 커맨드 출력 없는 PASS는 일률적으로 불신.

삽질 2: 기억 상호 덮어쓰기

초기에 두 Agent가 동시에 SHARED_TASK_NOTES를 수정하여 서로의 내용을 덮어씀. 해결: Agent Executor에 락 메커니즘을 추가하여 동시에 하나의 Agent만 태스크를 실행할 수 있도록 함.

삽질 3: 책임 전가 표현

Agent가 불확실한 사항을 만나면 “수동으로 확인해 주세요”, “아마 그럴 겁니다"라고 말했습니다. 해결: GATE-9에서 책임 전가 표현이 포함된 보고를 바로 FAIL 처리. Agent가 스스로 진상을 규명하도록 강제.

삽질 4: 간체자 오염

MiniMax 모델이 간혹 간체자를 출력(우리는 번체 중국어 필요). 해결: Agent Executor에 11,000개의 간체-번체 변환 테이블을 내장하여, 출력에 간체자가 포함되면 자동으로 반려 후 재실행.

삽질 5: 오래된 기억

기억 파일에 “해당 서비스 실행 중"이라고 기록되어 있지만 실제로는 서비스가 중지된 상태. Agent가 오래된 기억을 읽고 잘못된 판단을 내림. 해결: COO가 매번 시작할 때 기억과 시스템 실제 상태를 대조하여 불일치하면 즉시 수정.

삽질 6: MEMORY.md 비대화

용량을 관리하지 않으면 MEMORY.md가 계속 커지며, 200줄을 넘으면 잘려서 AI가 앞부분만 봅니다. 해결: 인덱스 파일에는 포인터만 두고, 심층 콘텐츠는 주제 파일로 분산.

10분 빠른 시작

여러분의 프로젝트에서 시도해 보고 싶으신가요? 최소 실행 가능한 기억 시스템에는 파일 세 개만 있으면 됩니다:

1. CLAUDE.md (프로젝트 루트 디렉토리)

1
2
3
4
5
6

<rules>
TASK-FLOW:
  action: 태스크 수신 → 기억 읽기 → 실행 → 기억 업데이트
SAFETY:
  action: API Key나 내부 경로 유출 금지
</rules>

2. memory/MEMORY.md (기억 인덱스)

1
2
3

# Memory Index
- [team-rules](team-rules.md) — 팀 철칙
- [project-context](project-context.md) — 프로젝트 진행 상황

3. memory/team-rules.md (주제 기억)

1
2
3

모든 외부 발행 콘텐츠는 반드시 품질 심사를 거쳐야 합니다.
**Why:** 이전에 심사 없이 발행하여 잘못된 정보가 유출된 적이 있습니다.
**How:** 콘텐츠 완성 → QA ≥ 8.5 → 발행 가능.

먼저 돌려보고, 실제 필요에 따라 점진적으로 레이어를 추가하세요. 파일 세 개로 시작하되, 처음부터 155KB 기억 아키텍처를 구축하려 하지 마세요.

참고 자료

• Claude Code overview — 공식 문서 — Claude Code 아키텍처 개요, CLAUDE.md 로딩 메커니즘 포함
• Claude Code memory — 공식 문서 — Auto Memory와 MEMORY.md 상세 설명
• Claude Code settings — 공식 문서 — settings.json과 Hooks 설정
• LanceDB 문서 — 벡터 데이터베이스 기술 문서
• Dify 지식 베이스 문서 — Dify 플랫폼 지식 검색 메커니즘