이 노트에 대하여
Steve Yegge의 Beads 구조와 Vibe Coding 책을 함께 읽으며 micro와 macro 기억 시스템을 나눠 설계하는 방향을 정리한다. 우리 과제의 메모리 계층을 구체화하는 노트다.
Beads 분석 및 Macro Memory System 설계
Steve Yegge의 Beads 코드베이스 분석과 Vibe Coding 책 구조 분석을 통해 Macro Memory System 설계 방향을 도출한 세션 기록.
배경: Micro vs Macro
| 영역 | Yegge 솔루션 | 우리 과제 |
|---|---|---|
| Micro | bd (beads) - 리포별 이슈 | 이미 사용 중 |
| Macro | ? (없음) | 만들어야 함 |
Beads 코드베이스 분석
규모
- 총 10만 줄 Go 코드
- 핵심 로직은 작음 (types.go 351줄, ready.go 291줄)
- 대부분 테스트, 엣지케이스, 동기화 처리
아키텍처
beads/
├── cmd/bd/ # CLI (Cobra)
│ ├── main.go # 데몬/다이렉트 모드 전환
│ ├── ready.go # "다음 뭐해?" 핵심 질문
│ └── daemon*.go # RPC 서버
├── internal/
│ ├── types/ # Issue, Dependency, Label
│ ├── storage/ # SQLite + Memory
│ └── rpc/ # 데몬 프로토콜
└── .beads/ # 리포마다 생성
├── beads.db # SQLite (로컬 캐시)
└── issues.jsonl # Git으로 공유 (Source of Truth)핵심 설계 철학
- JSONL = Source of Truth: DB는 캐시, JSONL이 진짜
- Daemon = 에이전트 친화적: RPC로 빠른 응답
- —json = 에이전트 파싱 가능: 모든 명령에 JSON 출력
- AGENTS.md = Convention: Hook 없이 문서로 에이전트 제어
Vibe Coding 책 구조 분석
저자 역할 분담
| Part | 주도 | 특징 |
|---|---|---|
| Part 1: WHY | Yegge | 철학, 일화, Kitchen 메타포 |
| Part 2: THEORY | Yegge | 실전 경험, Context 관리 |
| Part 3: TOOLS | 공동 | Inner/Middle/Outer Loop |
| Part 4: GOING BIG | Gene Kim | 조직 문화, 리더십 |
Gene Kim의 Three Loops
- Inner Loop (개인) = DevOps의 Flow
- Middle Loop (팀/PR) = Feedback
- Outer Loop (조직) = Continual Learning
Claude Code 이후 재구성
- CLI 에이전트가 전면에
- “Head Chef” 메타포 강화
- Chapter 17의 “AI Teams” 개념 추가
- MCP가 핵심 인프라로 등장
멀티 에이전트 동기화
두 가지 레이어
| 레이어 | 지연시간 | 용도 |
|---|---|---|
| Git (JSONL) | 2-5초 | Source of Truth |
| Agent Mail | <100ms | 실시간 예약 |
스케일 단계
- 단일 (OpenCode 서브에이전트) - 충돌 없음
- 로컬 멀티 (터미널 2개) - Agent Mail 필요
- 원격 멀티 (다른 머신) - Agent Mail + Git
- 팀 (여러 사람 + 에이전트) - 완전한 인프라
jj (Jujutsu) vs Git
Jujutsu의 Lock-Free 접근
- Operation Log = Git DAG와 유사
- 각 Operation은 독립적 완료 보장
- 충돌 시 3-way merge 자동
- Lock 없이 concurrent edit 허용
Beads가 Git을 선택한 이유 (추정)
- Git이 이미 충분
- Agent Mail로 실시간 레이어 보완
- JSONL 단순성
- jj는 아직 초기 단계
Macro 도구 설계 스케치
명령어 구조
md context # 오늘 나의 맥락 로드
md capture # 새 정보 저장
md recall # 과거 패턴 검색
md sync # 디바이스 간 동기화핵심 질문
- 데이터 구조: Graph? Timeline? 둘 다?
- 쿼리 언어: 에이전트가 어떻게 물어볼까?
- Memory Decay: 뭘 기억하고 뭘 잊을까?
Beads에서 가져올 패턴
- JSONL = Source of Truth
- Daemon RPC
- —json 출력
- AGENTS.md Convention
기술 로드맵 (bd 이슈 트래킹)
Epic: org-zdm - Macro Memory System 설계
org-zdm (Epic) ─────────────────────────────────────────────
│
├── org-zdm.1 Agent Mail 통합 검토 [P2] open
├── org-zdm.2 MCP Server 패턴 분석 [P2] open
├── org-zdm.3 Git vs jj 백엔드 선택 [P3] open
├── org-zdm.4 md CLI 프로토타입 [P1] open ★
├── org-zdm.5 디바이스 간 동기화 설계 [P2] open
│
├── org-c30 Macro 도구 요구사항 정의 [P1] open ★
├── org-6ro jj/A2A 프로토콜 검토 [P3] open
│
├── org-n73 Beads 코드베이스 분석 [P2] closed ✓
└── org-943 Vibe Coding 책 구조 분석 [P2] closed ✓우선순위 높은 작업 (P1)
-
org-c30: Macro 도구 요구사항 정의
- md context/capture/recall/sync 명령어 스펙
- 에이전트 친화적 인터페이스 설계
-
org-zdm.4: md CLI 프로토타입
- Go로 핵심 명령어 구현
- Beads 패턴 (Cobra + JSONL + Daemon) 적용
Agent Mail 통합 (org-zdm.1)
- 실시간 예약 시스템 (<100ms)
- 충돌 방지 메커니즘
- Git 동기화와 분리된 레이어
- HTTP API: POST /api/reserve, DELETE /api/release
MCP Server 패턴 (org-zdm.2)
{
"macro-memory": {
"command": "md-mcp",
"args": []
}
}- Claude Desktop / OpenCode 연동
- function call: md__context(), md__capture(), md__recall()
백엔드 선택 (org-zdm.3)
| 옵션 | 장점 | 단점 |
|---|---|---|
| Git | 생태계, 익숙함 | Lock 기반 |
| jj | Lock-free, Operation Log | 초기 단계 |
| Hybrid | 점진적 전환 | 복잡성 |
디바이스 동기화 (org-zdm.5)
laptop ──┐
├── Syncthing ──→ memory.jsonl
phone ───┤ │
│ ↓
nuc ─────┘ Git (백업/버전)다음 단계
- org-n73: Beads 코드베이스 분석 완료
- org-943: Vibe Coding 책 구조 분석
- org-c30: Macro 도구 요구사항 구체화
- org-zdm.4: md CLI 프로토타입
- org-zdm.1: Agent Mail 통합 검토
- org-6ro: jj/A2A 프로토콜 심층 검토
참고 자료
- ~/repos/3rd/beads/ - Beads 소스 코드
- ~/org/VibeCoding.org - Vibe Coding 책
- https://jj-vcs.github.io/jj/latest/technical/concurrency/
- ~/org/llmlog/20251122T235553—steve-yegge-beads-생존과-매크로뷰__llmlog_beads_agent_memory.org
- ~/org/llmlog/20251123T103523—steve-yegge-vibe-coding-인터뷰-정리__llmlog_yegge_vibecoding_interview.org
Comments