세션 분리 자동화 및 오케스트레이션.
A-JADM v1.3의 계약 파일 철학과 순환논리 방지 원칙을 유지하면서 subagent 레이어와 Agent Teams 고급 패턴을 도입합니다.
본 문서는 A-JADM v1.3의 확장 문서로, Claude Code의 subagent 기능을 A-JADM 파이프라인에 통합하는 전략을 다룹니다.
A-JADM v1.3은 세션 간 상태 전달을 계약 파일로 해결했지만, 세션 간 전환 자체는 개발자가 수동으로 수행해야 했습니다.
대규모 프로젝트에서 이것이 새로운 병목이 됩니다.
본 전략을 정확히 이해하려면 subagent의 핵심 동작을 파악해야 합니다.
부모 Claude 세션 ↓ Agent tool 호출 (prompt 문자열만 전달) ↓ 자식 Agent (독립 컨텍스트 윈도우) - 부모 대화 이력 상속 안 됨 - 자신의 도구 호출·파일 읽기는 자체 컨텍스트에 쌓임 - 작업 완료 후 최종 메시지만 부모에 반환 ↑ 부모 Claude (요약만 수신, 중간 과정은 섞이지 않음)
prompt 문자열 하나뿐. | 측면 | 물리적 세션 분리 (현재) | Subagent 위임 (제안) |
|---|---|---|
| 격리 수준 | 100% 물리적 | 논리적 (자체 컨텍스트) |
| 사람 개입 | 터미널 수동 전환 | 부모가 자동 위임 |
| 상태 전달 | 파일시스템 | 파일시스템 + prompt 문자열 |
| 디버깅 | 터미널별 독립 로그 | Ctrl-O로 자식 내부 확인 |
| 병렬 실행 | 가능 (터미널 N개) | 가능 (subagent N개) |
| 오버헤드 | 사람 수동 작업 | 부모↔자식 조정 비용 |
A-JADM의 13개 커맨드·8개 스킬에 대해 subagent 도입 적합성을 판정합니다.
핵심은 gen-test의 순환논리 위험 차단입니다.
ddd-modelerusecases/ 디렉토리 여러 파일을 읽어 분석 domain-context.md 파일 하나 --bc 증분 갱신도 subagent 단위로 깔끔
usecase-by-example과의 수렴 루프는 여전히 필요 bc-implementerinventory와 purchase를 부모가 병렬로 2개 subagent 호출 가능 (BC 경계가 다르므로 파일 충돌 없음)
Subagent는 자체 컨텍스트를 갖긴 하지만 부모의 지시를 받아 실행됩니다. 부모 세션이 implement-bc subagent의 결과물을 받은 직후 같은 부모 세션에서 gen-test subagent를 호출하면, 부모 세션이 "방금 구현한 내용이 맞다는 암묵적 가정"을 prompt에 담아 전달할 위험이 있습니다.
| 방안 | 설명 | 권장도 |
|---|---|---|
| (1) 엄격 분리 | gen-test는 완전히 별도 부모 세션에서 실행. 메모리 규칙 유지 |
✅ 권장 |
| (2) 제약된 subagent | agent.md에 "구현 코드는 스펙 대조용으로만 참조, 기대값은 오직 계약 파일에서 도출" 강제 | △ 조건부 |
| 스킬 | 판정 | 이유 |
|---|---|---|
usecase | 부적합 | 대화형 도메인 파악 필요 |
usecase-by-example | 경량 subagent | 결정적 변환이지만 수렴 루프로 부모 직접이 편리 |
arch-design | 부적합 | 스택 선택, 모듈 구조 등 사람 결정 多 |
nfr-spec | 부적합 | 성능/보안 요구사항 대화형 도출 필수 |
uc-to-skeleton | 경량 subagent 가능 | 결정적이고 짧음. 부모 직접도 무방 |
gen-schema | 경량 subagent 가능 | 결정적 변환, 산출물 2개 파일 |
check-spec | 적합 | 읽기 전용, 리포트만 반환, 전형적 subagent 용도 |
migrate-module | 부적합 | 3-Gate 사람 승인 필요 |
A-JADM에 subagent를 도입한 후의 프로젝트 구조입니다.
스킬과 에이전트는 다른 층위이며, 둘 다 유지합니다.
project-root/ ├── CLAUDE.md # 슬래시 커맨드 정의 (기존) ├── .claude/ │ ├── skills/ # 기존 — 무상태 오케스트레이터 │ │ ├── ddd-modeling/SKILL.md │ │ ├── implement-bc/SKILL.md │ │ ├── gen-test/SKILL.md │ │ └── ... │ └── agents/ # 신규 — 실행 격리 단위 │ ├── ddd-modeler.md │ ├── bc-implementer.md │ └── spec-checker.md # check-spec용 │ ├── usecases/ # 계약 입력 ├── features/ # 계약 입력 ├── domain-context.md # 계약 파일 ├── arch-decisions.md # 계약 파일 ├── bc-plan.md # 계약 파일 └── src/
gen-test는 .claude/agents/에 두지 않음. 각 agent는 YAML frontmatter + 마크다운 본문으로 구성됩니다.
핵심은 사전 조건 확인 엄격 명시 · 반환 요약 형식 고정 · 금지 사항 명확화입니다.
--- name: ddd-modeler description: usecases/ 디렉토리를 분석해 domain-context.md를 생성하거나 증분 갱신한다. BC 식별, Aggregate 설계, Command/Event 매핑 작업이 필요할 때 사용. tools: Read, Write, Glob, Grep --- 당신은 A-JADM의 ddd-modeling 스킬을 실행하는 전담 에이전트입니다. ## 작업 절차 1. .claude/skills/ddd-modeling/SKILL.md를 읽어 절차를 파악한다 2. usecases/*.md 전체를 읽어 BC 후보를 식별한다 3. features/*.feature가 있으면 Gherkin 용어와 UL 정합성을 대조한다 4. Step 1 BC 식별 → Step 2 Aggregate 설계 → Step 3 Command/Event 매핑 → Step 4 UL 사전 + 수렴 검증 순서를 엄수한다 5. domain-context.md를 생성·갱신한다 (Meta 헤더 content-version 증가 규칙 준수) ## 부모에게 반환할 요약 (최대 300단어) - 식별된 BC 목록과 개수 - 각 BC의 Aggregate 수 - 수렴 게이트 통과 여부 (PASS/FAIL/WARN) - FAIL인 경우: 실패 원인과 재실행 권장 스킬 ## 금지 사항 - 계약 파일 없이 추론으로 모델링하지 말 것 - usecases/가 비어 있으면 즉시 중단하고 부모에게 /usecase 실행을 안내 - domain-context.md에 이미 없는 새 BC를 자의적으로 추가 금지 (--bc new 명시 시만 허용)
--- name: bc-implementer description: 지정된 BC의 코드를 구현한다. domain-context.md, arch-decisions.md를 읽어 레이어 순서대로 생성. "order BC의 domain 레이어 구현" 같은 요청에 사용. tools: Read, Write, Edit, Bash, Glob, Grep --- 당신은 A-JADM의 implement-bc 스킬을 실행하는 전담 에이전트입니다. ## 사전 조건 확인 (없으면 즉시 중단) - domain-context.md 존재 - arch-decisions.md 존재 - bc-plan.md 존재 (멀티 BC일 때) - 대상 BC가 계약 파일에 정의되어 있음 ## 작업 절차 1. .claude/skills/implement-bc/SKILL.md를 읽어 절차를 파악한다 2. 대상 BC와 레이어를 부모의 prompt에서 파악한다 3. arch-decisions.md의 architecture, persistence 값을 읽는다 4. 레이어 순서 엄수: domain → application → adapter (Hexagonal) 5. Lombok 사용 금지, Java Records + 정적 팩토리 패턴 적용 6. 각 레이어 완료 후 mvn compile 통과 확인 7. 컴파일 실패 시 즉시 중단하고 부모에게 보고 ## 부모에게 반환할 요약 (최대 300단어) - 생성/수정한 파일 경로 목록 - 각 레이어별 클래스 수 - mvn compile 결과 (PASS/FAIL) - FAIL인 경우: 첫 번째 에러 위치와 원인 ## 금지 사항 - 추론으로 인터페이스 추가 금지 (계약 파일에 없는 것) - **같은 세션에서 테스트 코드 생성 금지** (gen-test는 별도 부모 세션) - 다른 BC의 코드 수정 금지 (depends-on 범위 내 포트 정의만 허용) - 순환 의존 발생 시 즉시 중단
--- name: spec-checker description: check-spec 스킬을 실행해 domain-context.md와 실제 코드의 정합성을 대조하고 드리프트 리포트를 반환한다. 읽기 전용. tools: Read, Glob, Grep --- 당신은 A-JADM의 check-spec 스킬을 실행하는 읽기 전용 에이전트입니다. ## 작업 절차 1. .claude/skills/check-spec/SKILL.md를 읽어 절차를 파악한다 2. domain-context.md YAML과 실제 코드를 정적 대조한다 3. 정방향(구현 누락) + 역방향(미등록 항목) 양방향 스캔 ## 부모에게 반환할 요약 (최대 500단어, 정형화된 리포트) - PASS / WARN / FAIL 총괄 - 누락 항목 목록 (FAIL) - 미등록 항목 목록 (WARN) - 파일:라인 위치 포함 ## 금지 사항 - 파일 수정 금지 (Read/Glob/Grep만 사용) - 리포트 외 부가 설명 최소화
모든 스킬을 subagent로 바꾸지 않습니다.
대화형은 부모 · 무거운 반복은 subagent · 순환논리 위험은 별도 세션이라는 원칙을 따릅니다.
| 작업 특성 | 위치 |
|---|---|
| 대화형 · 사람 결정 필요 | 부모 직접 |
| 읽기 많고 산출물 큼 | subagent 위임 |
| 반복 실행 (BC N개) | subagent 위임 |
| 순환논리 위험 (구현 ↔ 테스트) | 별도 부모 세션 |
| 짧고 결정적 | 부모 직접 (오버헤드 회피) |
inventory와 purchase BC 병렬 실행 — 독립 디렉토리(src/inventory/, src/purchase/)를 수정하므로 파일 충돌 없음
shared/ 디렉토리 수정 시 병렬 금지 → 순차 실행 bc-plan.md의 depends-on을 확인하도록 agent.md에 명시해야 합니다.
도입 효과와 함께 잠재 위험을 명확히 인식하고 완화책을 설계해야 합니다.
.claude/agents/ 파일을 프로젝트 간 복사. A-JADM 배포 자산 포함 가능gen-test는 별도 부모 세션 유지 (엄격 분리 원칙)migration-log.md 또는 agent-log/에 남김bc-implementer 직후 gen-test subagent 호출 arch-design을 subagent로 위임 (대화형 결정 손실) 실전 검증 없이 전면 도입하지 않습니다.
컨설팅 레퍼런스를 통한 점진적 확장이 원칙입니다.
bc-implementer 시험 도입.claude/agents/bc-implementer.md 작성/implement-bc 커맨드와 병행 운영ddd-modeler, spec-checker 추가gen-test 제약된 subagent 방안 안전성 실측.claude/agents/를 표준 배포 자산에 포함Claude Code v2.1.32+에서 실험적으로 제공되는 Agent Teams는 subagent의 다음 단계로, 여러 Claude Code 세션이 공유 task list와 직접 메시징으로 협업합니다.
본 장은 A-JADM 관점에서 Agent Teams의 도입 가능성을 분석합니다.
| 측면 | Subagent (§1~10) | Agent Teams (§11) |
|---|---|---|
| 소통 경로 | 부모 ↔ 자식만 (리드 중개) | 팀원끼리 직접 메시지 교환 |
| 작업 공유 | 없음 (각자 받은 prompt만) | 공유 task list (lock-and-claim) |
| 파일 충돌 방지 | 없음 (부모가 수동 관리) | git worktrees로 물리적 격리 |
| 계층 | 부모 → 자식 1단계만 | 리드 → 팀원, 중첩 불가 |
| 최대 팀원 수 | 제한 없음 | 2~4명 권장 |
| 상태 | 안정 | 실험적 (Opus 4.6 이상) |
| 토큰 비용 | 중간 | 매우 높음 |
| 디버깅 | Ctrl-O로 자식 확인 | 각 터미널에서 teammate 직접 대화 |
| 활성화 | 기본 제공 | CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 |
현재 한계: Wave에 BC가 4개 있으면 subagent 4개를 병렬 호출 가능하지만, 서로 정보를 주고받으려면 부모를 거쳐야 함. shared/ 수정 시 충돌 방지를 부모가 수동 관리.
sales 팀원이 inventory 팀원에게 "InventoryPort 최종 시그니처 뭐야?" 직접 메시지Wave 2 병렬 구현 팀을 구성해줘. - inventory-implementer: inventory BC 전담 - purchase-implementer: purchase BC 전담 - sales-implementer: sales BC 전담 - accounting-implementer: accounting BC 전담 각 팀원은 .claude/agents/bc-implementer.md의 규칙을 따르되, 자신의 BC 디렉토리만 수정. 팀원끼리는 OutputPort 시그니처가 필요하면 서로 직접 문의. 리드는 전체 진행 상황을 bc-plan.md의 depends-on 기준으로 조율.
현재 한계: ddd-modeling과 usecase-by-example은 병렬 실행 후 수렴 체크가 필요. UL과 Gherkin 용어가 일치하지 않으면 재실행. 이 루프는 현재 사람이 오케스트레이션.
도메인 모델링 수렴 팀을 구성해줘.
- ddd-modeler: BC·Aggregate·Command·Event·UL 도출
- gherkin-converter: usecases/*.md를 features/*.feature로 변환
- convergence-judge: 두 산출물의 용어 정합성 검증,
불일치 시 구체적 재작업 지시
세 팀원이 직접 메시지로 협업하여 수렴 게이트 통과까지 반복.
리드는 최종 domain-context.md와 features/ 산출을 확정 발표.
현재 한계: arch-design 단계에서 persistence 옵션(순수 JPA vs jpa+jdbc vs jpa+jooq) 같은 선택지를 검토할 때, 순차 분석은 한 가지 관점에 빠지기 쉬움.
아키텍처 검토 팀을 구성해줘. - jpa-advocate: 순수 JPA가 최선인 이유와 구현 부담 분석 - hybrid-advocate: jpa+jdbc가 최선인 이유와 CQRS 비용 분석 - jooq-advocate: jpa+jooq가 최선인 이유와 codegen 부담 분석 - devils-advocate: 세 입장 모두의 약점 지적 domain-context.md의 Query 복잡도를 기반으로 각자 주장. 최종 권고는 리드가 합성하여 arch-decisions.md 초안에 반영.
Agent Teams 도입 시 반드시 피해야 할 패턴입니다. 일반 Agent Teams 안티패턴에 더해 A-JADM 고유 제약이 있습니다.
gen-test 팀원 포함 bc-implementer 팀원과 gen-test 팀원이 같은 팀에 있으면 구현 의도가 테스트 기대값에 그대로 투영됨. A-JADM 핵심 원칙인 "Correctness 검증의 순환논리 방지"를 즉시 무너뜨림. /gen-test로 실행.
domain-context.md, arch-decisions.md, bc-plan.md)은 프로젝트 루트에 있어 worktree 간 공유됨. 여러 팀원이 동시 수정하면 last-write-wins로 손실 발생. bc-implementer.md의 "계약 파일 수정 금지" 규칙과 일관.
bc-implementer.md의 "계약 파일에 없는 것 추가 금지" 규칙을 동일하게 주입.
Agent Teams를 A-JADM에 도입할 때 반드시 지켜야 할 다섯 가지 원칙입니다.
| 원칙 | 설명 |
|---|---|
| 1. gen-test 팀원 금지 | 어떤 팀 구성에서도 테스트 생성 팀원을 포함하지 않음 |
| 2. 계약 파일은 리드만 수정 | 팀원은 읽기 전용 |
| 3. 각 팀원에 agent.md 규칙 주입 | bc-implementer.md의 금지 사항을 팀원마다 일관 적용 |
| 4. 리드의 직접 구현 금지 | 명시적 prompt 지시로 강제 |
| 5. 최대 팀원 수 4명 | 조율 비용 관리 |
bc-implementer 시범 도입)의 실측 데이터가 먼저 필요본 문서는 설계 초안이며, 실전 검증을 거쳐야 할 항목들이 있습니다.
gen-test subagent의 순환논리 방지 가능성본 전략이 A-JADM의 핵심 원칙을 깨뜨리지 않는지 최종 확인합니다.
| A-JADM 원칙 | Subagent 도입 후 유지 여부 |
|---|---|
| 계약 파일이 스킬 간 1:1 트레이서빌리티 보장 | ✅ 유지 (agent도 계약 파일 참조) |
| 추론 구간 최소화, 결정론적 매핑 강제 | ✅ 유지 (agent.md 금지 규칙 엄격) |
| 1 프로젝트 = 1~소수 BC | ✅ 유지 (agent는 BC 경계 존중) |
| 스킬 파일명 = 커맨드명 통일 | ✅ 유지 (agent는 별도 네이밍) |
| 구현과 테스트의 세션 분리 | ✅ 유지 (gen-test 별도 부모 세션) |
| 비결정론적 추론 방지 | ⚠️ 조건부 (agent.md 품질에 의존) |