📚FOS Study
홈카테고리
홈카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • agents 페이지로 이동
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code 멀티 에이전트 — Teams
    • 멀티모달 LLM (Multimodal Large Language Model)
  • architecture 페이지로 이동
    • 캐시 설계 전략 총정리
    • 디자인 패턴
    • 분산 트랜잭션
  • css 페이지로 이동
    • FlexBox 페이지로 이동
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • monitoring 페이지로 이동
  • go 페이지로 이동
    • Go 언어 기본 학습
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • 210812 페이지로 이동
    • 뱅크샐러드 AI Native Server Engineer
    • CJ 올리브영 지원 문항
    • CJ 올리브영 커머스플랫폼유닛 Back-End 개발 지원 자료
    • 마이리얼트립 - Platform Solutions실 회원주문개발 Product Engineer
    • NHN 서비스개발센터 AI서비스개발팀
    • nhn gameenvil console backend 직무 인터뷰 준비
    • 면접을 대비해봅시다
    • Tossplace Node.js Developer
    • 토스플레이스 Node.js 백엔드 컬처핏
  • java 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • OpenTelemetry 란 무엇인가?
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • Data_Structures_and_Algorithms 페이지로 이동
    • Heap 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node.js
    • npm vs pnpm 선택기준은 무엇인가요?
    • `setImmediate()`
  • kafka 페이지로 이동
    • Kafka 기본
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • 메시지 전송 신뢰성
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • react 페이지로 이동
    • JSX 페이지로 이동
    • VirtualDOM 페이지로 이동
    • v16 페이지로 이동
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • the-future-company 페이지로 이동
📚FOS Study

개발 학습 기록을 정리하는 블로그입니다.

바로가기

  • 홈
  • 카테고리

소셜

  • GitHub
  • Source Repository

© 2025 FOS Study. Built with Next.js & Tailwind CSS

목록으로 돌아가기
🤖AI

Claude Code 멀티 에이전트 — Teams

약 4분
2026년 3월 24일
GitHub에서 보기

Claude Code 멀티 에이전트 — Teams

Claude Code는 단일 에이전트로 동작하는 것 외에, 여러 전문화된 에이전트를 조율해서 복잡한 작업을 병렬로 처리하는 팀 구조를 지원한다.


기본 개념: Agent 도구

Claude Code는 Agent 도구로 하위 에이전트(서브프로세스)를 생성할 수 있다. 각 에이전트는 독립된 컨텍스트를 갖고, 자신에게 할당된 도구 셋과 역할로 동작한다.

오케스트레이터 (메인 Claude)
    ├─ Agent 1: 코드 탐색 (Explore)
    ├─ Agent 2: 구현 (Executor)
    └─ Agent 3: 검증 (Verifier)

단일 에이전트가 긴 작업을 처리하면 컨텍스트 한계에 부딪힌다. 팀 구조는 각 에이전트가 제한된 범위의 작업만 담당하게 해서 이 문제를 우회한다.


전문화된 에이전트 타입

에이전트역할특징
executor구현 작업코드 작성, 수정
verifier검증완성도 확인, 테스트 통과 여부
code-reviewer코드 리뷰품질, 스타일, 잠재 버그
debugger디버깅근본 원인 분석, 스택 트레이스
explore코드베이스 탐색파일 찾기, 패턴 검색
architect아키텍처 설계구조 분석, 트레이드오프 검토
test-engineer테스트 전략커버리지, 엣지 케이스
writer문서 작성README, API 문서, 주석
security-reviewer보안 검토OWASP, 취약점 탐지

팀 워크플로우

복잡한 작업은 단계별로 나눠서 각 단계에 맞는 에이전트를 배치한다.

team-plan  → 작업 계획 수립
team-prd   → 요구사항 문서화
team-exec  → 구현
team-verify → 검증
team-fix   → 실패 시 수정 (verify → fix 루프)

병렬 실행 패턴

독립적인 작업은 동시에 실행해서 시간을 줄인다.

오케스트레이터
    ├─ [병렬] Explore: "인증 관련 파일 탐색"
    ├─ [병렬] Explore: "API 엔드포인트 목록 파악"
    └─ [병렬] Explore: "테스트 커버리지 현황 파악"
         ↓ 결과 합산
    Executor: 구현 작업 시작

리뷰 파이프라인

구현 완료 후 자동으로 리뷰와 검증을 붙이는 패턴.

Executor → 코드 작성 완료
    ↓
Code Reviewer → 스타일, 품질 검토
    ↓
Security Reviewer → 보안 취약점 검토
    ↓
Verifier → 테스트 통과 확인
    ↓
완료

에이전트 간 통신

SendMessage

이미 실행 중인 에이전트에 메시지를 보내서 대화를 이어갈 수 있다. 에이전트는 자신의 전체 컨텍스트를 유지한다.

Agent 생성 → name: "my-researcher"
나중에 → SendMessage(to: "my-researcher", message: "추가 조사해줘")

백그라운드 실행

run_in_background: true로 에이전트를 백그라운드에서 실행하고, 완료 통보를 받을 때까지 다른 작업을 계속할 수 있다.

빌드 검증 에이전트 → 백그라운드 실행
    ↓ 기다리는 동안
문서 작성 에이전트 → 포그라운드 실행
    ↓
빌드 검증 완료 알림 수신

Worktree 격리

에이전트를 isolation: "worktree" 옵션으로 실행하면 임시 git worktree에서 독립된 환경으로 작업한다. 메인 브랜치에 영향 없이 실험적 변경을 시도할 수 있다.

메인 브랜치
    ├─ worktree-A: 기능 A 구현 에이전트
    ├─ worktree-B: 기능 B 구현 에이전트
    └─ worktree-C: 리팩터링 에이전트

변경이 없으면 worktree는 자동 삭제된다.


tmux와 함께 사용하기

tmux의 멀티 페인 구조와 Claude Code 팀을 함께 쓰면 각 에이전트의 진행 상황을 시각적으로 확인할 수 있다.

#!/bin/bash
# 에이전트별 tmux 페인 구성

tmux new-session -d -s agents

# 오케스트레이터
tmux send-keys -t agents "claude" Enter

# 백그라운드 에이전트들
tmux split-window -h
tmux send-keys -t agents "# executor agent pane" Enter

tmux split-window -v
tmux send-keys -t agents "# verifier agent pane" Enter

tmux capture-pane으로 다른 페인의 에이전트 출력을 읽어서 오케스트레이터에게 전달하는 자동화도 가능하다. (tmux 정리 참고)


실무 활용 패턴

대규모 리팩터링

한 에이전트가 전체 코드베이스를 분석하면 컨텍스트가 부족해진다. 모듈 단위로 에이전트를 분배해서 병렬 리팩터링 후 통합한다.

PR 리뷰 자동화

PR이 생성되면 코드 리뷰, 보안 검토, 테스트 커버리지 분석을 각각 전문 에이전트에게 위임하고 결과를 종합한다.

문서화 파이프라인

코드를 탐색하는 에이전트와 문서를 작성하는 에이전트를 분리해서, 탐색 결과를 바탕으로 정확한 문서를 생성한다.


관련 문서

  • tmux — 멀티 에이전트 환경 구성
  • Claude Code 스킬 시스템
AI 카테고리의 다른 글 보기수정 제안하기

댓글

댓글을 불러오는 중...
목차
  • Claude Code 멀티 에이전트 — Teams
  • 기본 개념: Agent 도구
  • 전문화된 에이전트 타입
  • 팀 워크플로우
  • 병렬 실행 패턴
  • 리뷰 파이프라인
  • 에이전트 간 통신
  • SendMessage
  • 백그라운드 실행
  • Worktree 격리
  • tmux와 함께 사용하기
  • 에이전트별 tmux 페인 구성
  • 오케스트레이터
  • 백그라운드 에이전트들
  • 실무 활용 패턴
  • 대규모 리팩터링
  • PR 리뷰 자동화
  • 문서화 파이프라인
  • 관련 문서