feat: 위키 저장소 초기 커밋
- CLAUDE.md 운영 규칙 - wiki/ 정리된 지식 페이지 (Nuxt + Claude Code) - raw/ 원본 자료 - reference/ Nuxt 4.x 공식 문서 Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
147
raw/claude-code-5-agentic-workflow-patterns.md
Normal file
147
raw/claude-code-5-agentic-workflow-patterns.md
Normal file
@@ -0,0 +1,147 @@
|
||||
# Claude Code: 5가지 에이전틱 워크플로우 패턴
|
||||
|
||||
> 출처: https://www.mindstudio.ai/blog/claude-code-agentic-workflow-patterns
|
||||
> 수집일: 2026-05-13
|
||||
|
||||
---
|
||||
|
||||
## 패턴 선택 원칙
|
||||
|
||||
> "단순한 것부터 시작하라 — Sequential — 더 단순한 패턴이 무너질 때만 복잡성을 추가하라."
|
||||
|
||||
---
|
||||
|
||||
## 패턴 1: Sequential (순차)
|
||||
|
||||
### 동작 방식
|
||||
각 단계가 순서대로 실행. 이전 출력이 다음 단계의 입력.
|
||||
"파이프라인: A 완료 → 결과가 B로 전달"
|
||||
|
||||
### 적합한 상황
|
||||
- 명확하고 예측 가능한 작업 순서
|
||||
- 각 단계 출력이 다음 단계 입력이 되는 경우
|
||||
- 1~2개 컨텍스트 윈도우 안에 들어오는 작업
|
||||
|
||||
### 예시
|
||||
```
|
||||
1. 명세 문서 읽기
|
||||
2. 함수 구현 생성
|
||||
3. 단위 테스트 작성
|
||||
4. 테스트 실행 후 결과 보고
|
||||
```
|
||||
|
||||
### 트레이드오프
|
||||
- ✅ 최대 단순성, 예측 가능성
|
||||
- ❌ 독립 작업 시 낮은 처리량
|
||||
- ❌ 긴 작업에서 컨텍스트 윈도우 한계
|
||||
|
||||
---
|
||||
|
||||
## 패턴 2: Operator (오케스트레이터)
|
||||
|
||||
### 동작 방식
|
||||
제어 에이전트가 계획을 세우고 다른 에이전트나 특화된 도구 호출을 지시.
|
||||
"하나가 두뇌, 특화된 subagent나 도구가 실행"
|
||||
|
||||
### 적합한 상황
|
||||
- 전체 작업이 단일 컨텍스트 윈도우를 초과
|
||||
- 컴포넌트마다 다른 전문적 집중이 필요
|
||||
- 작업 우선순위에 대한 중앙 제어 필요
|
||||
- 계획과 실행의 명확한 분리가 필요
|
||||
|
||||
### 예시 (보안 감사)
|
||||
오케스트레이터가 3개 subagent에 위임:
|
||||
- 인증 스캔 담당
|
||||
- DB 쿼리 스캔 담당
|
||||
- 입력 검증 스캔 담당
|
||||
→ 결과를 종합해서 최종 리포트
|
||||
|
||||
### 트레이드오프
|
||||
- ✅ 뛰어난 확장성
|
||||
- ❌ 오케스트레이팅 에이전트가 병목
|
||||
- ❌ 명확한 인터페이스를 위한 세심한 프롬프트 엔지니어링 필요
|
||||
|
||||
---
|
||||
|
||||
## 패턴 3: Split-and-Merge (병렬)
|
||||
|
||||
### 동작 방식
|
||||
코디네이터가 작업을 독립 청크로 분할 → 여러 인스턴스가 동시 작업 → 결과 수집 및 합성
|
||||
|
||||
### 적합한 상황
|
||||
- 상호 의존성 없이 깔끔하게 분리되는 작업
|
||||
- 속도가 중요할 때 (wall-clock time 단축)
|
||||
- 대량의 유사 항목 처리
|
||||
- 격리에 적합한 독립적인 서브태스크
|
||||
|
||||
### 예시
|
||||
함수 50개 문서화 → 5개씩 10 배치로 분할 → 병렬 실행 → docstring 합산
|
||||
|
||||
### 트레이드오프
|
||||
- ✅ 병렬성으로 극적인 성능 향상
|
||||
- ❌ 합병 단계의 복잡성
|
||||
- ❌ 불일관한 출력, 부분 실패 처리
|
||||
- ❌ 동시 실행으로 비용 상승
|
||||
|
||||
---
|
||||
|
||||
## 패턴 4: Agent Teams (다중 에이전트 팀)
|
||||
|
||||
### 동작 방식
|
||||
여러 특화된 에이전트가 지속적인 워크플로우에서 협업. 각 에이전트는 정의된 역할, 특정 범위, 고유 컨텍스트·도구 세트를 갖는다.
|
||||
|
||||
### 적합한 상황
|
||||
- 여러 세션에 걸친 장기 프로젝트
|
||||
- 작업의 다양한 측면에서 진정한 전문화 필요
|
||||
- 범위 분산 없는 집중된 에이전트 작업
|
||||
- 기존 소프트웨어 개발 파이프라인과 유사한 구조
|
||||
|
||||
### 예시 팀 구조
|
||||
- **Planning agent**: 전체 목표 유지
|
||||
- **Code agent**: 구현 작성·수정
|
||||
- **Testing agent**: 동작 검증
|
||||
- **Review agent**: 품질 검사
|
||||
- **Documentation agent**: 문서 업데이트
|
||||
|
||||
### 트레이드오프
|
||||
- ✅ 에이전트당 집중된 컨텍스트로 복잡한 지속 작업에 강력
|
||||
- ❌ 조율 오버헤드
|
||||
- ❌ 오류 전파 — 신중한 설계와 커뮤니케이션 프로토콜 필요
|
||||
|
||||
---
|
||||
|
||||
## 패턴 5: Headless Autonomous (자율 자동화)
|
||||
|
||||
### 동작 방식
|
||||
인간 개입 없이 이벤트, 스케줄, 외부 신호로 트리거. 작업 완료까지 독립 실행.
|
||||
|
||||
### 적합한 상황
|
||||
- 잘 정의된 반복·이벤트 기반 작업
|
||||
- 알려진 실패 모드 + 복구 경로
|
||||
- 실행 후 출력 검증 가능
|
||||
- 반복 작업의 완전 자동화
|
||||
|
||||
### 예시
|
||||
- 야간 저장소 스캔 → 의존성 업데이트 → 자동 PR 생성
|
||||
- CI/CD 트리거 → 실패 진단 → 버그 리포트
|
||||
- 스케줄 실행 → API 사용 로그 감사 → 주간 요약 생성
|
||||
|
||||
### 트레이드오프
|
||||
- ✅ 반복 작업에서 최대 자동화 수익
|
||||
- ❌ 엄격한 안전장치 필요:
|
||||
- 최소 권한 원칙
|
||||
- 가역적 작업 우선
|
||||
- 명확한 종료 조건
|
||||
- 인간 검토 체크포인트
|
||||
|
||||
---
|
||||
|
||||
## 패턴 선택 매트릭스
|
||||
|
||||
| 시나리오 | 최적 패턴 |
|
||||
|---|---|
|
||||
| 명확한 단계의 선형 작업 | Sequential |
|
||||
| 서브 위임 필요한 대규모 작업 | Operator |
|
||||
| 독립적 항목 다량 처리 | Split-and-merge |
|
||||
| 다중 도메인 장기 프로젝트 | Agent teams |
|
||||
| 반복·이벤트 트리거 자동화 | Headless |
|
||||
Reference in New Issue
Block a user