메모리 alloc/free처럼 열고 닫는 자율 에이전트 워크플로우

Date: 2026-03-18
Author: reode-team
Tags: [worktree, kanban, alloc-free, karpathy, program.md, dumb-platform, hooks, gitflow, autonomous-agent]

목차

1. 도입: 에이전트에게 작업 공간이란 무엇인가
2. 설계 철학: Karpathy P7·P8과 Claude Code Task의 교차점
3. Worktree = malloc, Merge+Remove = free
4. 칸반 보드: progress.md로 구현한 Dumb Platform
5. Hook 시스템: 컴파일러가 해제 누락을 잡듯이
6. 전체 워크플로우: Step 1에서 Step 12까지
7. 병렬 Worktree와 Merge Queue
8. 안티패턴과 누수 탐지
9. 마무리

---

1. 도입: 에이전트에게 작업 공간이란 무엇인가

자율 코딩 에이전트가 코드를 수정할 때, "어디에서" 작업하는지는 "무엇을" 작업하는지만큼 중요합니다.

사람 개발자라면 한 디렉터리에서 git checkout으로 브랜치를 전환해도 큰 문제가 없습니다. uncommitted changes가 있으면 stash하고, 충돌이 나면 손으로 풀면 됩니다. 하지만 에이전트는 다릅니다. 에이전트는 stash를 "기억"하지 못합니다. 브랜치를 전환하는 사이에 이전 작업의 컨텍스트를 잃고, 같은 디렉터리에서 두 작업이 얽히면 어느 변경이 어느 작업에 속하는지 구분할 수 없게 됩니다.

이 문제의 본질은 작업 공간의 수명 관리입니다. 운영체제가 프로세스에게 메모리를 할당하고 해제하듯, 에이전트에게도 격리된 작업 공간을 할당하고, 작업이 끝나면 해제하는 메커니즘이 필요합니다.

이 글에서는 REODE 프로젝트에서 Git Worktree를 malloc/free처럼 운용하고, Markdown 칸반 보드를 멀티 에이전트 공유 상태로 활용하며, Hook 시스템으로 해제 누락을 감지하는 워크플로우를 설명합니다. 설계의 밑바탕에는 Karpathy의 program.md 인터페이스(P7)와 Dumb Platform(P8) 철학이 있습니다.

---

2. 설계 철학: Karpathy P7·P8과 Claude Code Task의 교차점

2.1 두 가지 영감의 출처

이 워크플로우는 서로 다른 두 시스템에서 영감을 받았습니다.

출처	핵심 아이디어	REODE 적용
Karpathy program.md (P7)	에이전트 행동 변경 = 코드 수정이 아닌 지시서 수정	CLAUDE.md + progress.md가 에이전트의 행동을 결정
Karpathy Dumb Platform (P8)	플랫폼은 저장만, 조율은 프롬프트에	progress.md는 상태를 저장할 뿐, 해석과 조율은 에이전트가 수행
Claude Code TaskCreate/TaskUpdate	메모리 내 작업 추적 도구	휘발성 → 영속적 MD 파일로 대체

2.2 왜 Claude Code Task를 그대로 쓰지 않는가

Claude Code에는 TaskCreate, TaskUpdate, TaskGet 같은 내장 작업 추적 도구가 있습니다. 세션 내에서 작업을 분할하고 진행 상태를 관리하는 데 유용합니다. 그러나 두 가지 한계가 있습니다.

첫째, 휘발성입니다. Task 데이터는 세션 메모리에 존재합니다. 세션이 끝나면 사라집니다. 오늘 에이전트가 만든 작업 목록을 내일 다른 에이전트가 이어받을 수 없습니다.

둘째, 단일 에이전트 범위입니다. 병렬로 실행되는 여러 에이전트(또는 여러 세션)가 같은 작업 보드를 공유할 수 없습니다. 에이전트 A가 "칸반 시스템 구현"을 진행 중이라는 사실을 에이전트 B가 알 방법이 없습니다.

셋째, REODE의 시스템 구축입니다. Claude Code로 REODE를 제작하며 구축된 체계(워크플로우)는 REODE의 시스템으로 이식되도록 구현 중입니다. REODE가 마이그레이션 & 코딩 에이전트로서 PR을 최소 단위로 가지는 개발 플로우를 Claude Code -> REODE 구현 작업을 거치며 확보하는 게 주요 동기입니다.

2.3 Karpathy의 답: 파일이 곧 인터페이스

Karpathy의 autoresearch에서 program.md는 에이전트의 행동을 결정하는 유일한 지시서입니다. 코드를 수정하지 않고 program.md만 바꾸면 에이전트의 실험 전략이 달라집니다. AgentHub에서 메시지 보드는 에이전트 간 조율의 유일한 채널입니다. 플랫폼은 메시지를 저장하고 전달할 뿐, 해석하지 않습니다.

이 철학을 REODE의 작업 관리에 적용하면 이렇게 됩니다:

Claude Code Task (메모리 내, 휘발, 단일 세션)
         ↓ Karpathy P7 + P8 적용
progress.md (파일 내, 영속, 멀티 에이전트 공유)

progress.md는 데이터베이스가 아닙니다. Markdown 테이블일 뿐입니다. 하지만 그것으로 충분합니다.
Karpathy P8의 핵심은 "Dumb Platform일수록 에이전트가 똑똑해진다"는 것입니다.
추가로 복잡한 상태 관리 시스템을 만드는 대신, 에이전트가 텍스트 파일을 읽고 쓸 수 있으면 됩니다.
Karpathy가 Git을 가드레일로 사용하는 논리와 동일합니다. 결정론적인 보조 도구는 가능한 LLM에게 "학습된" 도구로 제한합니다.

---

3. Worktree = malloc, Merge+Remove = free

3.1 메모리 관리 비유

운영체제에서 메모리 관리의 핵심 원칙은 단순합니다. 할당한 것은 반드시 해제해야 합니다. 해제하지 않으면 메모리 누수(memory leak)가 발생합니다. Git Worktree를 같은 패턴으로 운용합니다.

OS 메모리 관리              Git Worktree 관리
─────────────────────      ─────────────────────────────
void *p = malloc(size);    git worktree add .claude/worktrees/<name>
// ... 작업 수행 ...        // ... 코드 변경, PR, merge ...
free(p);                   git worktree remove .claude/worktrees/<name>
p = NULL;                  git branch -d feature/<name>

개념	OS	REODE Worktree
할당	malloc()	git worktree add
격리	프로세스 가상 주소 공간	물리적으로 분리된 디렉터리
해제	free()	git worktree remove + git branch -d
누수 탐지	Valgrind, AddressSanitizer	git worktree list, Stop Hook
이중 해제	double free → crash	worktree remove 실패 (이미 제거됨)

3.2 왜 checkout이 아닌 worktree인가

git checkout feature/xxx는 같은 디렉터리에서 브랜치를 전환합니다. 이는 같은 메모리 공간을 두 프로세스가 공유하는 것과 같습니다.

# 위험한 패턴: 같은 디렉터리에서 브랜치 전환
/workspace/reode/
  ├── (main 작업 중 uncommitted changes)
  ├── git checkout feature/kanban  ← stash 충돌 위험
  └── (feature 작업 시작... 이전 컨텍스트 혼재)

Worktree는 물리적으로 독립된 디렉터리를 생성합니다. 각 작업이 자신만의 주소 공간을 갖습니다.

/workspace/reode/                          ← 본 레포 (develop/main만)
  └── .claude/worktrees/
        ├── kanban-workflow/                ← feature/kanban-workflow
        │     └── (격리된 작업 공간)
        ├── cli-port/                      ← feature/cli-port
        │     └── (격리된 작업 공간)
        └── release-v014/                  ← release/v0.14.0
              └── (격리된 작업 공간)

.claude/worktrees/는 .gitignore에 포함되어 있습니다. 작업 공간 자체는 버전 관리 대상이 아닙니다. 오직 그 안에서 만들어진 커밋만이 의미를 갖습니다. 이는 힙 메모리의 주소 자체가 아닌, 그 안에 저장된 값이 중요한 것과 같은 원리입니다.

3.3 alloc — 작업 공간 할당

# Step 1: Worktree Open (alloc)

# 1. develop 최신화 (본 레포에서)
git checkout develop && git pull origin develop

# 2. worktree 생성 = 작업 공간 할당
git worktree add .claude/worktrees/<작업명> -b feature/<브랜치명> develop

# 3. 작업 디렉터리 이동
cd .claude/worktrees/<작업명>

# → 이후 모든 작업은 이 worktree 안에서 수행

세 줄입니다. malloc이 한 줄인 것처럼, 작업 공간 할당도 최소한의 의식(ceremony)이어야 합니다.
에이전트가 매번 "worktree를 어떻게 만들지" 고민하지 않도록, 이 패턴을 gitflow 스킬의 Step 1로 고정했습니다.

3.4 free — 작업 공간 해제

# Step 12: Worktree Close (free)

# 1. 본 레포로 복귀
cd /Users/mango/workspace/reode

# 2. develop/main 최신화
git checkout develop && git pull origin develop

# 3. worktree 제거 = 작업 공간 해제
git worktree remove .claude/worktrees/<작업명>

# 4. 브랜치 정리 (로컬 + 리모트)
git branch -d feature/<브랜치명>
git push origin --delete feature/<브랜치명>

# 5. 누수 점검
git worktree list   # 닫히지 않은 worktree 없어야 함

free() 후에 포인터를 NULL로 설정하는 것처럼, worktree 제거 후에 브랜치도 삭제합니다. 브랜치가 남아 있으면 "해제된 메모리를 참조하는" dangling pointer와 같습니다. git worktree list는 Valgrind와 같은 역할을 합니다.

---

4. 칸반 보드: progress.md로 구현한 Dumb Platform

4.1 5컬럼 칸반 구조

docs/progress.md는 Markdown 테이블로 구성된 칸반 보드입니다.

# REODE Progress Board

> 멀티 에이전트 공유 칸반 보드. 모든 세션/에이전트가 이 파일을 읽고 갱신한다.

## Kanban

### Backlog
| task_id | 설명 | 우선순위 | plan | 비고 |

### In Progress
| task_id | 설명 | 담당 | 브랜치 | 시작일 | 비고 |

### In Review
| task_id | PR | 담당 | CI | 비고 |

### Done (날짜별 그룹)
| task_id | 설명 | PR | 담당 | 완료일 |

### Blocked
| task_id | 차단 사유 | blocked_by | 비고 |

이것이 전부입니다. 데이터베이스도, API 서버도, 웹 UI도 없습니다. Dumb Platform, Claude Code의 MD + 파일구조 중심 컨택스트 관리 원칙을 그대로 따릅니다. 플랫폼(MD 파일)은 상태를 저장할 뿐이고, 해석과 조율은 에이전트(Claude Code)가 CLAUDE.md의 규칙을 읽고 수행합니다.

4.2 읽기/쓰기 프로토콜

칸반 보드의 일관성은 프로토콜로 보장합니다. CLAUDE.md에 다음 규칙이 명시되어 있습니다:

세션 시작 시: 읽기 → 현재 보드 상태 파악 → 이미 할당된 작업 회피
세션 종료 시: 쓰기 → 변경 사항 반영
  - 완료 작업: In Progress/In Review → Done (날짜별 그룹)
  - 신규 작업: Backlog에 추가 (task_id, 우선순위, plan 연결)
  - Blocked: 차단 사유 기록 (blocked_by task_id)
  - Metrics: Version, Modules, Tests 수치 갱신

이 프로토콜은 데이터베이스의 트랜잭션과 유사합니다. 세션 시작 시 SELECT(읽기)로 현재 상태를 확인하고, 세션 종료 시 UPDATE(쓰기)로 변경을 반영합니다. 다만 동시성 제어는 없습니다. 두 에이전트가 동시에 같은 행을 수정하면 Git merge conflict로 드러납니다. 이것이 의도된 설계입니다. 충돌 해결을 플랫폼이 아닌 에이전트에게 맡깁니다.

4.3 Claude Code Task와의 비교

특성	Claude Code Task	progress.md
저장소	세션 메모리 (휘발)	Git 추적 파일 (영속)
수명	세션 종료 시 소멸	커밋으로 이력 보존
공유 범위	단일 세션	모든 에이전트/세션
조회 방식	TaskGet API	파일 읽기 (Read)
갱신 방식	TaskUpdate API	파일 편집 (Edit)
동시성 제어	단일 세션이므로 불필요	Git merge conflict
인간 가독성	도구 출력으로만 확인	Markdown → GitHub 렌더링
시각화	없음	GitHub에서 테이블 렌더링

progress.md의 가장 큰 장점은 인간도 에이전트도 같은 인터페이스로 접근한다는 점입니다. 사람이 GitHub에서 docs/progress.md를 열면 현재 프로젝트 상태를 즉시 파악할 수 있습니다. 별도의 대시보드를 만들 필요가 없습니다. Karpathy의 program.md가 인간과 에이전트의 공유 인터페이스인 것과 같은 원리입니다.

---

5. Hook 시스템: 컴파일러가 해제 누락을 잡듯이

5.1 문제: 사람은 잊고, 에이전트도 잊는다

C 프로그래머가 malloc 후 free를 잊듯이, 에이전트도 세션을 종료할 때 progress.md 갱신을 잊을 수 있습니다. 커밋은 했는데 칸반 보드에 반영하지 않으면, 다음 세션의 에이전트가 이미 완료된 작업을 중복 시작할 수 있습니다.

이 문제를 Claude Code의 Hook 시스템으로 해결합니다. Hook은 특정 이벤트(세션 시작, 도구 실행, 세션 종료)에 자동으로 실행되는 셸 스크립트입니다. C의 atexit() 핸들러나, Rust의 Drop 트레잇과 같은 역할입니다.

5.2 Stop Hook: check-progress.sh

# .claude/hooks/check-progress.sh
#!/bin/bash
# Hook: Stop — progress.md 갱신 + develop→main 격차 리마인드

set -euo pipefail

TODAY=$(date +%Y-%m-%d)
PROGRESS_FILE="docs/progress.md"
MESSAGES=()

# --- Check 1: progress.md 갱신 여부 ---
COMMITS_TODAY=$(git log --since="$TODAY 00:00:00" --oneline 2>/dev/null \
  | wc -l | tr -d ' ')

if [ "$COMMITS_TODAY" -gt 0 ]; then
  if [ ! -f "$PROGRESS_FILE" ] || ! grep -q "## $TODAY" "$PROGRESS_FILE"; then
    MESSAGES+=("[progress] 오늘 ${COMMITS_TODAY}건 커밋이 있지만 \
docs/progress.md에 ${TODAY} 섹션이 없습니다.")
  fi
fi

# --- Check 2: develop→main 격차 감지 ---
AHEAD=$(git rev-list --count origin/main..origin/develop 2>/dev/null \
  || echo "0")

if [ "$AHEAD" -gt 0 ]; then
  MESSAGES+=("[gitflow] develop이 main보다 ${AHEAD}커밋 앞서 있습니다. \
develop → main PR + merge를 진행하세요.")
fi

# --- Output ---
if [ ${#MESSAGES[@]} -eq 0 ]; then
  echo '{"continue": true}'
else
  MSG=$(printf '%s ' "${MESSAGES[@]}")
  cat <<EOF
{
  "continue": true,
  "message": "${MSG}"
}
EOF
fi

이 스크립트는 두 가지를 검사합니다.
(1) 오늘 커밋이 있는데 progress.md에 오늘 날짜 섹션이 없으면 경고합니다. 칸반 보드 갱신 누락을 잡습니다.
(2) develop이 main보다 앞서 있으면 머지를 상기시킵니다. 이 두 검사는 free() 후 메모리 누수를 잡는 것과 같은 역할입니다.

5.3 Hook 등록

// .claude/settings.json
{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/check-progress.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

Stop 이벤트에 등록합니다. 세션이 끝날 때마다 자동 실행됩니다. "continue": true이므로 세션 종료를 차단하지 않고, 메시지로 리마인드만 합니다. 이는 컴파일러 경고(warning)와 같습니다. 오류(error)로 차단하지 않되, 무시하면 안 되는 신호입니다.

5.4 검사 흐름

에이전트 세션 종료 요청
        │
        ▼
┌───────────────────────────────┐
│  Stop Hook 자동 실행           │
│  check-progress.sh            │
│                               │
│  ① 오늘 커밋 > 0?             │
│     AND progress.md에          │
│     오늘 날짜 없음?            │
│     → "[progress] 리마인드"   │
│                               │
│  ② develop ahead of main?    │
│     → "[gitflow] 리마인드"    │
│                               │
│  ③ 메시지 있으면 반환          │
│     없으면 조용히 통과         │
└───────────────────────────────┘
        │
        ▼
  에이전트가 메시지를 수신
  → 칸반 갱신 or 머지 수행

---

6. 전체 워크플로우: Step 1에서 Step 12까지

전체 워크플로우를 하나의 다이어그램으로 정리합니다.

Worktree alloc/free가 전체를 감싸고, 그 안에서 코드 변경 → 래칫 검증 → PR → 머지 → 칸반 갱신이 순차적으로 진행됩니다.

 Step 1: alloc ─────────────────────────────────────────────── Step 12: free
 ┌──────────────────────────────────────────────────────────────────────────┐
 │  git worktree add                                    git worktree remove│
 │  .claude/worktrees/<name>                            + branch delete    │
 │      │                                                        ▲        │
 │      ▼                                                        │        │
 │  Step 2: 코드 변경 (worktree 안에서)                          │        │
 │      │                                                        │        │
 │      ▼                                                        │        │
 │  Step 3: ★ Pre-PR Quality Gate ◄──────┐                      │        │
 │      │  ruff check ✓                   │ 실패                 │        │
 │      │  ruff format ✓                  │  시                  │        │
 │      │  mypy ✓                         │ 수정                 │        │
 │      │  bandit ✓                       │ 후                   │        │
 │      │  pytest ✓                       │ 재실행               │        │
 │      │  docs-sync ✓                  ──┘                      │        │
 │      ▼                                                        │        │
 │  Step 4: 커밋 (코드 + docs 함께)                              │        │
 │      │                                                        │        │
 │      ▼                                                        │        │
 │  Step 5: PR 생성 (feature → develop)                          │        │
 │      │                                                        │        │
 │      ▼                                                        │        │
 │  Step 6: ★★ Post-PR CI 래칫 ◄─────┐                          │        │
 │      │  gh pr checks --watch        │ 실패                   │        │
 │      │                              │ 시                     │        │
 │      ├── pass ──→ Step 7            │ 수정→push              │        │
 │      └── fail ──→ 수정 루프 ───────┘                          │        │
 │      ▼                                                        │        │
 │  Step 7: merge (feature → develop)                            │        │
 │      │                                                        │        │
 │      ▼                                                        │        │
 │  Step 8-10: develop → main (동일 래칫)                        │        │
 │      │                                                        │        │
 │      ▼                                                        │        │
 │  Step 11: ★★★ Docs-Sync 최종 검증                             │        │
 │      │  README/CHANGELOG/CLAUDE.md 수치 정합성                │        │
 │      │                                                ────────┘        │
 │      ▼                                                                 │
 │  ★ Step 6b: progress.md 칸반 갱신 (세션 종료 시)                       │
 │      In Progress → Done, 새 작업 → Backlog                            │
 └──────────────────────────────────────────────────────────────────────────┘
                              │
                              ▼
                   Stop Hook: check-progress.sh
                   ① progress.md 갱신 여부 확인
                   ② develop→main 격차 확인

전체 흐름에서 가장 중요한 것은 alloc과 free가 반드시 쌍을 이루는 것입니다. Step 1 없이 Step 2를 시작할 수 없고, Step 7(merge) 없이 Step 12(free)를 수행하면 작업이 소실됩니다. 그리고 Step 12를 수행하지 않으면 worktree 누수가 발생합니다.

---

7. 병렬 Worktree와 Merge Queue

7.1 동시에 여러 작업 공간 운용

실제 개발에서는 하나의 작업만 진행하지 않습니다. 버그 수정, 기능 개발, 릴리스 준비가 동시에 진행될 수 있습니다. 이때 각 작업에 독립된 worktree를 할당합니다.

/workspace/reode/
  └── .claude/worktrees/
        ├── fix-u27/          ← Pipeline None guard (4줄)
        ├── fix-u20/          ← prompt_toolkit SIGINT 해소
        └── release-v014/     ← v0.14.0 릴리스 준비

이것은 멀티프로세스 환경에서 각 프로세스가 독립된 메모리 공간을 갖는 것과 같습니다.
fix-u27의 변경이 release-v014에 영향을 주지 않습니다.

7.2 Merge Queue: 순차 해제

여러 worktree가 동시에 존재할 때, develop으로의 merge는 큐 방식으로 관리합니다. 한 번에 하나만 merge하고, 다음 worktree는 rebase 후 merge합니다.

Worktree A (fix/u27)  ──→ PR → CI pass → merge #1 ──┐
                                                      │ develop 갱신
Worktree B (fix/u20)  ──→ PR → CI pass ──→ rebase ──→ merge #2 ──┐
                                                                   │
Worktree C (fix/u22)  ──→ PR → CI pass ──→ rebase ──→ merge #3 ──┘
                                                                   │
                                              develop → main PR (배치)

OS의 메모리 해제는 순서가 자유롭지만, 코드 merge는 순서가 중요합니다. 이전 merge의 결과가 다음 merge의 base가 되기 때문입니다. rebase는 "이전에 해제된 메모리 공간의 변화를 반영"하는 작업입니다.

7.3 배치 머지: develop → main

feature → develop merge는 하나씩 수행하지만, develop → main은 여러 feature를 모아서 배치로 수행할 수 있습니다. 릴리스 단위를 묶는 것입니다.

# 여러 feature가 develop에 merge된 후
gh pr create --base main --head develop \
  --title "develop → main: v0.14.0 릴리스 머지" \
  --body "$(cat <<'EOF'
## 포함된 변경
- #92 칸반 보드 시스템 도입
- #94 CLI 시스템 GEODE 동기화
- #96 v0.14.0 릴리스
EOF
)"

---

8. 안티패턴과 누수 탐지

8.1 안티패턴 카탈로그

안티패턴	메모리 비유	증상	올바른 방식
본 레포에서 git checkout feature/*	같은 주소 공간에서 두 프로세스 실행	stash 충돌, uncommitted 혼재	git worktree add
worktree 생성 후 merge 없이 삭제	malloc 후 데이터 쓰고 free (작업 소실)	코드 변경 사라짐	merge 완료 후 remove
merge 후 worktree 미삭제	free 누락 = 메모리 누수	.claude/worktrees/에 좀비 디렉터리 누적	Step 12 필수 수행
merge 후 브랜치 미삭제	free 후 포인터 미초기화 = dangling pointer	git branch -a에 좀비 브랜치 누적	git branch -d + git push --delete
progress.md 미갱신	자원 사용 후 로그 미기록	다음 에이전트가 중복 작업 시작	세션 종료 시 반드시 갱신
"병렬 작업이 아니면 worktree 불필요"	"메모리 적게 쓰면 관리 안 해도 됨"	단일 작업에서도 checkout 사고 발생	단일 작업도 worktree

8.2 누수 탐지

# 1. 현재 열린 worktree 확인
git worktree list
# /Users/mango/workspace/reode                      abc1234 [develop]
# /Users/mango/workspace/reode/.claude/worktrees/... def5678 [feature/xxx]

# 2. 이미 merge된 브랜치 중 남아있는 것 확인
git branch --merged develop | grep feature/

# 3. 리모트에 남아있는 좀비 브랜치
git branch -r --merged origin/develop | grep feature/

이 세 명령을 주기적으로 실행하는 것은 valgrind --leak-check=full을 실행하는 것과 같습니다. 닫히지 않은 worktree나 삭제되지 않은 브랜치가 있으면 누수입니다.

---

9. 마무리

핵심 정리

항목	값/설명
핵심 비유	Worktree = malloc/free, progress.md = shared memory
설계 철학	Karpathy P7(program.md) + P8(Dumb Platform)
대체 대상	Claude Code Task (휘발, 단일 세션)
칸반 구조	5컬럼 Markdown 테이블 (Backlog → Done + Blocked)
격리 단위	.claude/worktrees/<name> 디렉터리
안전장치	Stop Hook (check-progress.sh) — 갱신 누락 + 격차 감지
병렬 운용	Merge Queue — 한 번에 하나씩, rebase 후 merge
누수 탐지	git worktree list + git branch --merged

설계 원칙 체크리스트

• 모든 작업은 worktree로 시작하고 worktree로 끝나는가 (alloc/free 쌍)
• 본 레포에서 git checkout feature/*를 사용하지 않는가
• progress.md를 세션 시작 시 읽고, 세션 종료 시 갱신하는가
• Stop Hook이 등록되어 갱신 누락을 감지하는가
• 병렬 worktree의 develop merge가 큐 방식으로 순차 처리되는가
• merge 후 worktree remove + branch delete를 수행하는가
• git worktree list로 주기적 누수 점검을 하는가

Ref. autoresearch

P7 program.md ──→ CLAUDE.md (워크플로우 규칙) + progress.md (상태 저장)
P8 Dumb Platform ──→ MD 파일 = 저장만, 조율 = 에이전트 프롬프트
P4 래칫 ──→ CI 래칫 (gh pr checks --watch) + Stop Hook
P5 Git State Machine ──→ Worktree = 격리된 실험 공간, commit = checkpoint

이 워크플로우의 핵심은 복잡한 도구를 만들지 않는 것입니다.
Git Worktree, Markdown 파일, 셸 스크립트는 모두 이미 존재하면서도 LLM이 Tool-use로 학습한 결정론적 경량 도구입니다.
새로운 것은 이 도구들을 메모리 관리의 프레임으로 조합한 사고방식뿐입니다. autoresearch가 파일 3개로 100+개의 ML 실험을 자율 수행한 것처럼 REODE는 Markdown 파일 하나와 셸 스크립트 하나로 멀티 에이전트 칸반 시스템을 수행합니다.