# 전체 에이전트 미팅: 멀티프로젝트 격리 및 시스템 구조

> 일시: 2026-03-01
> 소집: 아누 (개발실장)
> 참석: 야누스(DevOps), 마아트(QC), 헤르메스(1팀장), 비너스(세컨드오피니언)
> 안건: 개발 시스템(헌법) vs 프로젝트 격리, 폴더 구조, 동시 진행 관리

---

## 핵심 합의사항

### 1. 전원 동의: dispatch.py에 `--project` 파라미터 필수
- 현재 프로젝트 개념 자체가 없어서, 팀이 어디에 코드를 쓸지 모호함
- 최소한 프로젝트 경로를 프롬프트에 명시해야 함

### 2. 전원 동의: 프로젝트별 독립 디렉토리 (`projects/<name>/`)
- `projects/` 하위에 프로젝트별 폴더
- 각 프로젝트에 메타 파일 (CLAUDE.md 또는 manifest.json)

### 3. 의견 분기: 구조화 수준

**야누스+마아트 (적극적 구조화)**:
- system/ 분리, 3계층 CLAUDE.md, 격리 검증 시스템
- project-isolation.py 연동, 파일 락, 사후 검증 자동화
- 근거: "수십 개 프로젝트 동시 진행 시 사고 필연적"

**비너스 (점진적 접근, 과도 구조화 경고)**:
- "아직 실제 프로젝트 0개. 집 짓기 전에 도시계획 세우는 격"
- Phase 0에서는 `projects/<name>/ + CLAUDE.md` + dispatch에 경로 전달만
- 진짜 문제가 발생할 때 최소 해법 추가
- "AI에게는 프롬프트 격리가 파일시스템 격리보다 자연스럽다"

---

## 전문가별 핵심 제안 요약

### 야누스 (DevOps)
- **구조**: system/ + memory/ + projects/ + teams/ 4분할
- **격리**: polyrepo (프로젝트별 독립 git repo)
- **3계층 CLAUDE.md**: 시스템(200줄) + 팀(200줄) + 프로젝트(200줄)
- **마이그레이션**: 4단계 (기반→첫프로젝트→전체전환→검증)

### 마아트 (QC)
- **현재 판정: FAIL** — 다중 프로젝트 운영 준비 안 됨
- **구조적 결함 5건**: 프로젝트 ID 없음, 격리 도구 미연동, memory flat 구조 등
- **동시 진행 리스크 7건**: 컨텍스트 혼동, JSON 파일 경합, task ID 충돌 등
- **3단계 검증 게이트**: 사전(dispatch시) → 실시간(스냅샷) → 사후(QC)
- **긴급**: task-timers.json 파일 락 없음 → 동시 쓰기 시 corruption 가능

### 헤르메스 (1팀장, 실전 관점)
- **위임 시 필수 정보**: project_id, project_root, context_files, 수정금지 영역
- **프로젝트 전환**: `.project-meta.json`을 먼저 읽어 즉시 맥락 파악
- **공유 코드**: `shared/` 디렉토리 + SHARED-REGISTRY.md
- **테스트 격리**: 프로젝트별 venv, pytest.ini, 테스트 명령어 명시

### 비너스 (세컨드오피니언)
- **과도 구조화 경고**: Phase 0(프로젝트 0~1)에서는 최소 구조만
- **AI 특수성**: 세션 리셋 → 프롬프트가 전부 → 프롬프트 격리가 핵심
- **연쇄 수정 경고**: 프로젝트 개념 도입 시 8개 파일 동시 수정 필요
- **권장**: manifest.json 기반 (프로젝트 추가 = 폴더+manifest 하나)
- **핵심 메시지**: "첫 번째 실제 프로젝트를 돌려보는 게 100배 가치 있다"

---

## 아누 종합 분석

### 공통점 (4인 합의)
1. `dispatch.py --project` 필요
2. `projects/<name>/` 디렉토리 구조 필요
3. 프로젝트별 컨텍스트 파일 필요 (CLAUDE.md / manifest.json / .project-meta.json)
4. 프롬프트에 프로젝트 경로 명시 필요

### 쟁점: 지금 당장 vs 나중에

| 항목 | 야누스/마아트 | 비너스 | 아누 판단 |
|------|--------------|--------|-----------|
| system/ 분리 | 지금 | 나중에 | **나중에** (현재 파일 이동 리스크) |
| dispatch --project | 지금 | 지금 | **지금** (전원 합의) |
| project-isolation 연동 | 지금 | 나중에 | **나중에** (첫 프로젝트 후) |
| memory 네임스페이스 | 지금 | 나중에 | **나중에** (현재 연쇄수정 큼) |
| task-timers 파일 락 | 지금 | 나중에 | **지금** (마아트 지적 유효, 실제 리스크) |
| 3계층 CLAUDE.md | 지금 | 나중에 | **프로젝트 CLAUDE.md만 지금** |

### 아누 최종 권고안

**Phase 0 (지금, 첫 프로젝트 시작 전)**:
1. `projects/` 구조 확립 + 프로젝트 manifest 표준 정의
2. `dispatch.py`에 `--project` 파라미터 추가
3. `team_prompts.py`에 프로젝트 경로 + 격리 규칙 주입
4. PROJECT-WORKFLOW.md에 프로젝트 초기화 절차 추가
5. task-timers.json 파일 락 추가

**Phase 1 (첫 프로젝트 완료 후)**:
- 실제 경험 기반으로 구조 보완
- memory 네임스페이스 분리 검토
- project-isolation.py 연동 검토

**Phase 2 (프로젝트 5개 이상)**:
- system/ 물리적 분리
- 공유 라이브러리 관리
- 사후 검증 자동화

---

## 미팅 결론

비너스의 "점진적 접근" 관점을 기본으로 삼되, 마아트가 지적한 **파일 락**과 전원 합의한 **dispatch --project**는 즉시 적용.

**핵심 원칙**:
> "첫 번째 실제 프로젝트를 돌려보고, 진짜 문제가 드러난 후에 구조를 확장한다."
> 다만, 확장할 때 막히지 않도록 **기본 뼈대(projects/ + dispatch --project)**는 지금 세운다.