A-JADM AGENTS · VERSION 0.2 · APRIL 2026

Subagent & Agent Teams
통합 전략

세션 분리 자동화 및 오케스트레이션.
A-JADM v1.3의 계약 파일 철학과 순환논리 방지 원칙을 유지하면서 subagent 레이어와 Agent Teams 고급 패턴을 도입합니다.

3
도입 대상 스킬
2
세션 유형
1
절대 금지 조합
4
도입 Phase

개요

본 문서는 A-JADM v1.3의 확장 문서로, Claude Code의 subagent 기능을 A-JADM 파이프라인에 통합하는 전략을 다룹니다.

결론 요약

ddd-modeling
적합 ✅
읽기 많고 산출물은 파일 하나
implement-bc
매우 적합 ✅✅
반복 실행, 파일 I/O 부담 큼
gen-test
조건부 ⚠️
순환논리 위험, 별도 부모 세션 권장
arch-design · nfr-spec
부적합 ❌
대화형 결정 필요
핵심 원칙 — 모든 스킬을 subagent로 바꾸지 않습니다.
대화형은 부모 직접 · 무거운 반복은 subagent · 순환논리 위험은 별도 세션이라는 세 가지 원칙을 따릅니다.

왜 subagent인가

A-JADM v1.3은 세션 간 상태 전달을 계약 파일로 해결했지만, 세션 간 전환 자체는 개발자가 수동으로 수행해야 했습니다.
대규모 프로젝트에서 이것이 새로운 병목이 됩니다.

현재 방식의 한계

1
BC별 터미널을 N개 열어야 함
대형 ERP에서 10개 세션 동시 유지 부담
2
Wave 순서 수동 전환
어느 터미널에서 무엇을 할지 전적으로 사람 책임
3
실수 위험
같은 세션에서 /implement-bc와 /gen-test 실행 위험

Subagent가 제공하는 것

1
자체 컨텍스트 윈도우
자식 agent는 부모 대화 이력 없이 시작
2
도구 접근 권한 제한
agent별로 허용 도구를 YAML로 선언 가능
3
자동 위임
부모가 description을 보고 적절한 agent 선택
4
결과 요약 반환
자식의 중간 도구 호출은 부모에 섞이지 않음
이것은 A-JADM의 "세션 분리" 원칙과 메커니즘은 다르지만 의도는 일치합니다. 물리적 터미널 분리 대신 논리적 컨텍스트 격리로 동일한 효과를 얻되, 사람 개입을 줄일 수 있습니다.

Claude Code subagent 동작 원리

본 전략을 정확히 이해하려면 subagent의 핵심 동작을 파악해야 합니다.

컨텍스트 격리 모델

부모 Claude 세션
  ↓ Agent tool 호출 (prompt 문자열만 전달)
  ↓
자식 Agent (독립 컨텍스트 윈도우)
  - 부모 대화 이력 상속 안 됨
  - 자신의 도구 호출·파일 읽기는 자체 컨텍스트에 쌓임
  - 작업 완료 후 최종 메시지만 부모에 반환
  ↑
부모 Claude (요약만 수신, 중간 과정은 섞이지 않음)

통신 채널

부모 → 자식
Agent tool의 prompt 문자열 하나뿐.
파일 경로, 에러 메시지, 결정 사항을 모두 이 안에 담아야 함
자식 → 부모
자식의 최종 메시지 하나(verbatim).
중간 도구 호출 흔적은 전달되지 않음
세션 간 지속
파일시스템만 가능.
A-JADM 계약 파일과 동일 원리

물리적 세션 분리 vs Subagent 위임

측면물리적 세션 분리 (현재)Subagent 위임 (제안)
격리 수준100% 물리적논리적 (자체 컨텍스트)
사람 개입터미널 수동 전환부모가 자동 위임
상태 전달파일시스템파일시스템 + prompt 문자열
디버깅터미널별 독립 로그Ctrl-O로 자식 내부 확인
병렬 실행가능 (터미널 N개)가능 (subagent N개)
오버헤드사람 수동 작업부모↔자식 조정 비용

Subagent가 맞지 않는 경우

Anthropic 공식 가이드의 안티패턴:
① 순차적 강한 의존 (단계 2가 단계 1의 전체 출력 필요)
② 같은 파일 동시 편집 (두 subagent 간 파일 충돌)
③ 작은 작업 (위임 오버헤드가 실익 초과)
④ 대화형 탐색 (사람이 중간에 결정 필요)

A-JADM 파이프라인별 적합성 판정

A-JADM의 13개 커맨드·8개 스킬에 대해 subagent 도입 적합성을 판정합니다.
핵심은 gen-test의 순환논리 위험 차단입니다.

ddd-modeling

적합 ✅ — 권장 agent: ddd-modeler

적합 이유
· usecases/ 디렉토리 여러 파일을 읽어 분석
· 파일 내용이 부모 컨텍스트에 누적될 필요 없음
· 산출물은 domain-context.md 파일 하나
· 부모는 "완료" 요약만 수신
· --bc 증분 갱신도 subagent 단위로 깔끔
주의 사항
· usecase-by-example과의 수렴 루프는 여전히 필요
· 수렴 체크는 subagent 내부에서 끝내거나, 부모가 두 subagent 결과를 받아 게이트 판정
implement-bc

매우 적합 ✅✅ — 권장 agent: bc-implementer

적합 이유
· BC 하나 구현에 읽어야 할 파일이 많음 (계약 파일 3종 + 기존 코드)
· 모든 파일을 자식 컨텍스트에 담고, 부모는 "domain 레이어 완료" 요약만 수신
· 동일한 레시피 반복 실행 (BC 이름만 바꿔 N번 호출)
· 레이어별 호출(domain → application → adapter)을 순차 subagent로 분리 가능
핵심 이점
· 부모는 전체 Wave 진행 상태만 보유 → 오케스트레이션 역할에 집중
· Wave 2의 inventorypurchase를 부모가 병렬로 2개 subagent 호출 가능 (BC 경계가 다르므로 파일 충돌 없음)
gen-test

조건부 ⚠️ — 별도 부모 세션 권장

핵심 문제: A-JADM의 "Correctness 검증의 순환논리 위험" 원칙 충돌.
"Claude Code가 동일 세션에서 구현과 테스트를 모두 생성하면 검증이 무의미해짐"

Subagent의 잠재 위험

Subagent는 자체 컨텍스트를 갖긴 하지만 부모의 지시를 받아 실행됩니다. 부모 세션이 implement-bc subagent의 결과물을 받은 직후 같은 부모 세션에서 gen-test subagent를 호출하면, 부모 세션이 "방금 구현한 내용이 맞다는 암묵적 가정"을 prompt에 담아 전달할 위험이 있습니다.

방안설명권장도
(1) 엄격 분리 gen-test는 완전히 별도 부모 세션에서 실행. 메모리 규칙 유지 ✅ 권장
(2) 제약된 subagent agent.md에 "구현 코드는 스펙 대조용으로만 참조, 기대값은 오직 계약 파일에서 도출" 강제 △ 조건부
권장안 (1) 엄격 분리 유지. A-JADM의 핵심 원칙을 지킬 수 있는 안전한 방법입니다.
실전 검증 후 방안 (2)의 안전성이 입증되면 v2.0에서 완화 검토.

기타 스킬 판정

스킬판정이유
usecase부적합대화형 도메인 파악 필요
usecase-by-example경량 subagent결정적 변환이지만 수렴 루프로 부모 직접이 편리
arch-design부적합스택 선택, 모듈 구조 등 사람 결정 多
nfr-spec부적합성능/보안 요구사항 대화형 도출 필수
uc-to-skeleton경량 subagent 가능결정적이고 짧음. 부모 직접도 무방
gen-schema경량 subagent 가능결정적 변환, 산출물 2개 파일
check-spec적합읽기 전용, 리포트만 반환, 전형적 subagent 용도
migrate-module부적합3-Gate 사람 승인 필요

.claude/agents/ 디렉토리 구조

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/

핵심 원칙

층위 분리
SKILL.md는 "무엇을 하는가"를 정의
agent.md는 "어떤 컨텍스트에서 실행하는가"를 정의
스킬 참조
Agent는 system prompt 안에서 해당 SKILL.md를 읽고 절차를 따르도록 지시합니다.
스킬의 절차는 단일 진실 원천 유지
gen-test 제외
gen-test.claude/agents/에 두지 않음.
별도 부모 세션 운영 원칙 유지

Agent 정의 템플릿

각 agent는 YAML frontmatter + 마크다운 본문으로 구성됩니다.
핵심은 사전 조건 확인 엄격 명시 · 반환 요약 형식 고정 · 금지 사항 명확화입니다.

ddd-modeler

DDD 모델링 에이전트

---
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 명시 시만 허용)
bc-implementer

BC 구현 에이전트

---
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 범위 내 포트 정의만 허용)
- 순환 의존 발생 시 즉시 중단
spec-checker

명세 드리프트 검증 에이전트 (읽기 전용)

---
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 · 순환논리 위험은 별도 세션이라는 원칙을 따릅니다.

세션 역할 분담

부모 세션 A

설계 + 오케스트레이션

Phase 1 (부모 직접)
· /usecase → usecases/UC*.md
· /usecase-by-example → features/*.feature
Phase 2 (혼합)
· ddd-modeler [subagent] → domain-context.md
· /arch-design (부모 직접) → arch-decisions.md
· /nfr-spec (부모 직접) → NFR 섹션 보완
· /uc-to-skeleton (부모 직접) → 스켈레톤
Phase 3 (subagent 주도)
· bc-implementer [subagent × N] → BC 코드
  Wave 순서로 호출
  같은 Wave 내 병렬 가능
Phase 3.5 (검증)
· spec-checker [subagent] → 드리프트 리포트
SEPARATE
부모 세션 B

테스트 전담 (별도 터미널)

테스트 생성
· /gen-test (부모 직접)
· domain-context.md + features/ 참조
· 구현 코드는 "대조용"으로만 읽음
절대 금지:
부모 세션 A와 같은 터미널에서 실행 금지
세션 A의 대화 이력이 없는
새 터미널에서만 실행

위임 판정 기준

작업 특성위치
대화형 · 사람 결정 필요부모 직접
읽기 많고 산출물 큼subagent 위임
반복 실행 (BC N개)subagent 위임
순환논리 위험 (구현 ↔ 테스트)별도 부모 세션
짧고 결정적부모 직접 (오버헤드 회피)

병렬 실행 규칙

허용
Wave 2에서 inventorypurchase BC 병렬 실행 — 독립 디렉토리(src/inventory/, src/purchase/)를 수정하므로 파일 충돌 없음
금지
두 BC 모두 shared/ 디렉토리 수정 시 병렬 금지 → 순차 실행
같은 BC의 서로 다른 레이어 병렬도 금지 (domain → application → adapter 의존성)
부모 세션이 병렬 호출을 결정하기 전에 bc-plan.md의 depends-on을 확인하도록 agent.md에 명시해야 합니다.

장단점 및 리스크 관리

도입 효과와 함께 잠재 위험을 명확히 인식하고 완화책을 설계해야 합니다.

장점

부모 컨텍스트 보존
ERP 대형 프로젝트에서 부모 세션이 오케스트레이터 역할에 집중
병렬 실행 자동화
수동 터미널 전환 없이 Wave 내 BC 병렬 구현
재사용성
.claude/agents/ 파일을 프로젝트 간 복사. A-JADM 배포 자산 포함 가능
사람 개입 감소
터미널 수동 전환 → 자동 위임
도구 권한 제한
spec-checker 같은 읽기 전용 agent에서 보안 강화

리스크와 완화책

!
Prompt 전달 손실
agent.md에 "계약 파일 없으면 중단" 룰 엄격 명시, prompt 템플릿 표준화
!
테스트 검증 순환논리
gen-test는 별도 부모 세션 유지 (엄격 분리 원칙)
!
병렬 충돌
BC 경계로만 병렬 허용, depends-on 확인 의무화
!
디버깅 어려움
실행 로그를 migration-log.md 또는 agent-log/에 남김
!
지연 증가
Subagent 시작 오버헤드. 작은 작업 부적합 → BC 전체 단위에만 적용
!
환각 증가 위험
agent.md 지시 부족 시 추론 모드 폴백 → 금지 규칙 강하게 명시
!
계약 파일 우회
사전 조건 확인을 agent.md 상단에 필수 배치

안티패턴 — 하지 말아야 할 조합

❌ 부모 세션 A에서 bc-implementer 직후 gen-test subagent 호출
arch-design을 subagent로 위임 (대화형 결정 손실)
❌ 같은 파일을 수정하는 두 subagent 동시 호출
❌ agent.md에 "계약 파일 없으면 추론으로 진행" 같은 완화 규칙
❌ agent가 다른 agent를 호출 (2단계 위임 — 디버깅 악몽)

도입 로드맵

실전 검증 없이 전면 도입하지 않습니다.
컨설팅 레퍼런스를 통한 점진적 확장이 원칙입니다.

0
사전 검증
지금 시점
  • Claude Code subagent 공식 문서 정독
  • 작은 예제 프로젝트에서 bc-implementer 시험 도입
  • 컨텍스트 사용량 비교 (부모 직접 vs subagent 위임)
1
시범 도입
컨설팅 레퍼런스 1건
  • .claude/agents/bc-implementer.md 작성
  • 기존 /implement-bc 커맨드와 병행 운영
  • 품질·속도·컨텍스트 사용량 실측
  • 병렬 실행 시 파일 충돌 사례 수집
2
확장
레퍼런스 2~3건
  • ddd-modeler, spec-checker 추가
  • 하이브리드 오케스트레이션 실전 검증
  • gen-test 제약된 subagent 방안 안전성 실측
3
A-JADM v2.0 정식 통합
공식 배포
  • .claude/agents/를 표준 배포 자산에 포함
  • CLAUDE.md 템플릿에 agent 호출 예시 반영
  • 에이전트 레이어 문서화 (본 문서 확장)
  • v2.0 마이그레이션 가이드 제공
4
고급 패턴 탐색
v2.0 이후
  • Agent Teams 시나리오 1 실험 (Wave 병렬 BC 구현) — § Agent Teams 참조
  • Agent Teams 시나리오 2 실험 (DDD 수렴 루프 자동화)
  • Agent Teams 시나리오 3 실험 (Competing Hypotheses 아키텍처 평가)
  • Wave 전체 자동 오케스트레이션 (부모가 Wave 0→1→2→3 자동 진행)
  • 실패 복구 패턴 (subagent 실패 시 부모의 재시도 전략)

Agent Teams 고급 패턴

Claude Code v2.1.32+에서 실험적으로 제공되는 Agent Teams는 subagent의 다음 단계로, 여러 Claude Code 세션이 공유 task list와 직접 메시징으로 협업합니다.
본 장은 A-JADM 관점에서 Agent Teams의 도입 가능성을 분석합니다.

도입 시점: Agent Teams는 Phase 4(고급 패턴 탐색)의 주제로, Phase 1~3 완료 후 검토합니다.
본 섹션은 미래 방향성 제시이며, 현 단계 실전 도입을 권장하지 않습니다.

Subagent vs 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
핵심 이점 두 가지:
git worktrees 자동 격리 — 각 teammate가 독립 작업 디렉토리를 가지므로 파일 충돌이 물리적으로 불가능
peer-to-peer 메시징 — 팀원끼리 직접 질문/응답 가능. 리드를 거치지 않음

A-JADM에서 유용한 세 가지 시나리오

시나리오 1

Wave 내 대규모 병렬 BC 구현 — 가장 유망

현재 한계: Wave에 BC가 4개 있으면 subagent 4개를 병렬 호출 가능하지만, 서로 정보를 주고받으려면 부모를 거쳐야 함. shared/ 수정 시 충돌 방지를 부모가 수동 관리.

Agent Teams 이점:
  • 각 BC가 독립 git worktree에서 작업 → 파일 충돌 원천 차단
  • sales 팀원이 inventory 팀원에게 "InventoryPort 최종 시그니처 뭐야?" 직접 메시지
  • 공유 task list로 "inventory domain 완료" 같은 상태가 실시간 공유
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 기준으로 조율.
시나리오 2

DDD 수렴 루프 자동화

현재 한계: ddd-modelingusecase-by-example은 병렬 실행 후 수렴 체크가 필요. UL과 Gherkin 용어가 일치하지 않으면 재실행. 이 루프는 현재 사람이 오케스트레이션.

Agent Teams 이점: 팀원끼리 직접 "이 용어 우리가 다르게 쓰고 있네, 어느 쪽에 맞출까?" 대화가 가능.
도메인 모델링 수렴 팀을 구성해줘.
- ddd-modeler: BC·Aggregate·Command·Event·UL 도출
- gherkin-converter: usecases/*.md를 features/*.feature로 변환
- convergence-judge: 두 산출물의 용어 정합성 검증,
                    불일치 시 구체적 재작업 지시

세 팀원이 직접 메시지로 협업하여 수렴 게이트 통과까지 반복.
리드는 최종 domain-context.md와 features/ 산출을 확정 발표.
시나리오 3

경쟁 가설 기반 아키텍처 대안 평가

현재 한계: arch-design 단계에서 persistence 옵션(순수 JPA vs jpa+jdbc vs jpa+jooq) 같은 선택지를 검토할 때, 순차 분석은 한 가지 관점에 빠지기 쉬움.

Agent Teams 이점: 공식 가이드가 권장하는 "Competing Hypotheses" 패턴. 각 팀원이 독립 컨텍스트에서 각자의 입장을 주장하고, 리드가 합성.
아키텍처 검토 팀을 구성해줘.
- jpa-advocate: 순수 JPA가 최선인 이유와 구현 부담 분석
- hybrid-advocate: jpa+jdbc가 최선인 이유와 CQRS 비용 분석
- jooq-advocate: jpa+jooq가 최선인 이유와 codegen 부담 분석
- devils-advocate: 세 입장 모두의 약점 지적

domain-context.md의 Query 복잡도를 기반으로 각자 주장.
최종 권고는 리드가 합성하여 arch-decisions.md 초안에 반영.

A-JADM 특화 안티패턴

Agent Teams 도입 시 반드시 피해야 할 패턴입니다. 일반 Agent Teams 안티패턴에 더해 A-JADM 고유 제약이 있습니다.

❌ 안티패턴 1: gen-test 팀원 포함
위험: 팀원끼리 직접 소통하므로, bc-implementer 팀원과 gen-test 팀원이 같은 팀에 있으면 구현 의도가 테스트 기대값에 그대로 투영됨. A-JADM 핵심 원칙인 "Correctness 검증의 순환논리 방지"를 즉시 무너뜨림.
규칙: 어떤 팀 구성에서도 테스트 생성 팀원을 포함하지 않음. 테스트는 팀 실행 완료 후, 별도 부모 세션에서 /gen-test로 실행.
❌ 안티패턴 2: 계약 파일 동시 수정
위험: git worktrees는 코드 파일을 격리하지만, 계약 파일(domain-context.md, arch-decisions.md, bc-plan.md)은 프로젝트 루트에 있어 worktree 간 공유됨. 여러 팀원이 동시 수정하면 last-write-wins로 손실 발생.
규칙: 계약 파일은 리드만 수정. 팀원은 읽기 전용. bc-implementer.md의 "계약 파일 수정 금지" 규칙과 일관.
❌ 안티패턴 3: 팀원의 잘못된 가정 전파
위험: 한 팀원이 API 시그니처·자료 구조·공유 유틸에 대해 잘못된 가정을 하면, 다른 팀원들이 그 위에 빌드. A-JADM에서는 더 심각 — 한 팀원이 계약 파일에 없는 Command를 추가하면 다른 팀원들이 그걸 참조하기 시작.
규칙: 각 팀원의 system prompt에 bc-implementer.md의 "계약 파일에 없는 것 추가 금지" 규칙을 동일하게 주입.
❌ 안티패턴 4: 리드의 직접 구현
위험: 공식 가이드 언급 — 때때로 리드가 위임하지 않고 직접 구현을 시작함 (실험적 기능의 아티팩트). A-JADM 관점에서는 리드가 직접 구현하면 세션 분리 원칙이 교란됨.
규칙: 팀 생성 prompt에 "리드는 오케스트레이션만, 구현은 팀원에게 위임" 명시 필수.
❌ 안티패턴 5: 5명 이상의 대규모 팀
위험: 공식 가이드 권장치 2~4명. 5명 이상은 조율 비용이 급증하고 토큰 소비가 비례 이상으로 증가. A-JADM의 "Lean over Comprehensive" 원칙과 충돌.
규칙: 팀 크기는 최대 4명. 5개 이상 BC를 동시 구현해야 하면 두 팀으로 분할하거나 Wave 재조정.

도입 제약 사항

Agent Teams를 A-JADM에 도입할 때 반드시 지켜야 할 다섯 가지 원칙입니다.

원칙설명
1. gen-test 팀원 금지어떤 팀 구성에서도 테스트 생성 팀원을 포함하지 않음
2. 계약 파일은 리드만 수정팀원은 읽기 전용
3. 각 팀원에 agent.md 규칙 주입bc-implementer.md의 금지 사항을 팀원마다 일관 적용
4. 리드의 직접 구현 금지명시적 prompt 지시로 강제
5. 최대 팀원 수 4명조율 비용 관리

검토 시점 판단

조기 도입을 말려야 하는 이유
  • Phase 1(bc-implementer 시범 도입)의 실측 데이터가 먼저 필요
  • Agent Teams는 현재 실험적 기능, 안정화 대기
  • A-JADM의 핵심 가치(결정론성, 순환논리 방지)와 Agent Teams의 자유도 높은 협업 특성이 긴장 관계
  • 비즈니스 관점에서 Max 플랜 전제는 고객 진입 장벽
예외적 조기 실험 케이스
1
대규모 ERP 컨설팅 레퍼런스
고객이 Max 플랜 사용 중일 때, 시나리오 1 (Wave 병렬 BC) 1회 실험
2
아키텍처 컨설팅 의뢰
아키텍처 대안 평가 요청 시, 시나리오 3 (Competing Hypotheses) 실험
두 경우 모두 본 파이프라인과 독립적으로 실험하고, 결과를 Phase 4 로드맵에 피드백합니다.
실전 데이터 누적 후 A-JADM v2.0 또는 v2.1에서 정식 통합 여부를 결정합니다.

미해결 과제

본 문서는 설계 초안이며, 실전 검증을 거쳐야 할 항목들이 있습니다.

기술적

검증 필요 항목

  • 제약된 gen-test subagent의 순환논리 방지 가능성
  • 부모 세션의 prompt 편향이 결과에 미치는 영향 실측
  • 병렬 실행 시 계약 파일 동시 수정 충돌 — Lock 메커니즘 필요성
방법론

설계 결정 필요

  • 에이전트와 스킬의 경계 — 둘 다 유지인가, 일부는 agent로 대체인가
  • A-GADM, A-FADM으로의 확장 가능성
  • 계약 파일의 버전 관리 — subagent의 content-version 증가 강제 방법
비즈니스

선결 조건

  • 컨설팅 레퍼런스 확보 — 실전 1~2건 없이 정식 통합 위험
  • 교육 자료 변화 — A-JADM 강의에 agent 레이어 추가 시점
  • Claude Code subagent 기능 안정화 시점에 맞춘 통합

A-JADM 원칙과의 정합성 체크

본 전략이 A-JADM의 핵심 원칙을 깨뜨리지 않는지 최종 확인합니다.

A-JADM 원칙Subagent 도입 후 유지 여부
계약 파일이 스킬 간 1:1 트레이서빌리티 보장 ✅ 유지 (agent도 계약 파일 참조)
추론 구간 최소화, 결정론적 매핑 강제 ✅ 유지 (agent.md 금지 규칙 엄격)
1 프로젝트 = 1~소수 BC ✅ 유지 (agent는 BC 경계 존중)
스킬 파일명 = 커맨드명 통일 ✅ 유지 (agent는 별도 네이밍)
구현과 테스트의 세션 분리 ✅ 유지 (gen-test 별도 부모 세션)
비결정론적 추론 방지 ⚠️ 조건부 (agent.md 품질에 의존)
결론: 하이브리드 방식은 A-JADM 원칙을 해치지 않으면서 개발자의 수동 부담을 줄이는 방향입니다.
단, agent.md의 품질이 방법론 전체의 결정론성을 좌우하므로 agent.md 작성 가이드 자체를 표준화하는 것이 차기 과제입니다.