Claude Code 최신 업데이트: Opus 4.6 & Agent Teams
작성일: 2026-02-06 | Claude Opus 4.6 출시일: 2026-02-05
목차
- Claude Opus 4.6 주요 특징
- Agent Teams (팀 기능)
- Subagents vs Agent Teams 비교
- Agent Teams 설정 및 사용법
- 효과적인 팀 활용 전략
- 실전 활용 예시
- 제한사항 및 주의점
- 우리 프로젝트 적용 방안
1. Claude Opus 4.6 주요 특징
1.1 모델 성능
| 항목 | 내용 |
|---|---|
| 모델 ID | claude-opus-4-6 |
| 컨텍스트 윈도우 | 1M 토큰 (베타, Opus급 최초) |
| 최대 출력 | 128K 토큰 |
| 벤치마크 | Terminal-Bench 2.0 최고점, GDPval-AA에서 GPT-5.2 대비 144 Elo 우위 |
1.2 핵심 신기능
Adaptive Thinking (적응형 사고)
- 기존: Extended Thinking ON/OFF 수동 토글
- 신규: 모델이 문맥을 파악하여 자동으로 사고 깊이 결정
- 개발자용 Effort Control 4단계:
low,medium,high,max - 단순 질문에는 빠르게, 복잡한 문제에는 깊게 사고하여 비용/속도 최적화
Context Compaction (컨텍스트 압축)
- 긴 대화 중 오래된 컨텍스트를 자동 요약
- 컨텍스트 윈도우 한계에 도달하지 않고 장시간 에이전트 작업 가능
- API 베타 기능으로 제공
대규모 코드베이스 지원 강화
- 더 큰 코드베이스에서 안정적으로 동작
- 코드 리뷰 및 디버깅 능력 향상
- 자체 실수를 발견하고 수정하는 능력 개선
- 더 신중한 계획 수립 후 실행
Agent Teams
- 여러 Claude 인스턴스가 팀으로 협업하는 기능 (아래에서 상세 설명)
2. Agent Teams (팀 기능)
2.1 개요
Agent Teams는 여러 Claude Code 인스턴스가 하나의 팀으로 병렬 협업하는 실험적 기능이다. 기존 Subagent가 메인 에이전트에게만 결과를 보고하는 단방향 구조였다면, Agent Teams는 팀원 간 직접 소통이 가능한 양방향 구조다.
2.2 아키텍처
┌──────────────────────────────────────────────┐ │ 사용자 │ │ (메인 터미널) │ └─────────────────┬────────────────────────────┘ │ ┌───────▼───────┐ │ Team Lead │ ← 메인 Claude Code 세션 │ (조율 담당) │ └───┬───┬───┬───┘ │ │ │ ┌────────┘ │ └────────┐ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │Teammate │ │Teammate │ │Teammate │ ← 독립 Claude 인스턴스 │ A │ │ B │ │ C │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ └─────┬─────┘─────┬────┘ ▼ ▼ ┌────────────┐ ┌────────────┐ │ Shared │ │ Mailbox │ │ Task List │ │ System │ └────────────┘ └────────────┘
4가지 핵심 구성요소:
| 구성요소 | 역할 |
|---|---|
| Team Lead | 메인 세션. 팀 생성, 작업 분배, 결과 종합 |
| Teammates | 독립 Claude 인스턴스. 각자의 컨텍스트 윈도우에서 작업 |
| Shared Task List | 공유 작업 목록. pending → in_progress → completed 상태 관리 |
| Mailbox System | 에이전트 간 메시징 인프라 |
2.3 데이터 저장 위치
~/.claude/teams/{team-name}/config.json # 팀 설정 (멤버 목록, ID 등) ~/.claude/tasks/{team-name}/ # 공유 작업 목록
3. Subagents vs Agent Teams 비교
| 특성 | Subagents | Agent Teams |
|---|---|---|
| 컨텍스트 | 자체 윈도우, 결과만 메인에 반환 | 자체 윈도우, 완전 독립 |
| 통신 | 메인 에이전트에게만 보고 (단방향) | 팀원 간 직접 메시징 (양방향) |
| 조율 | 메인 에이전트가 모든 작업 관리 | 공유 작업 목록으로 자율 조율 |
| 적합한 작업 | 결과만 필요한 집중 작업 | 토론과 협업이 필요한 복잡한 작업 |
| 토큰 비용 | 낮음 (결과 요약만 메인에 반환) | 높음 (각 팀원이 별도 인스턴스) |
| 중첩 | 불가 (subagent가 subagent 생성 불가) | 불가 (teammate가 team 생성 불가) |
판단 기준:
- 팀원 간 소통이 필요 없으면 → Subagents
- 팀원 간 발견 공유, 토론, 상호 검증이 필요하면 → Agent Teams
4. Agent Teams 설정 및 사용법
4.1 활성화
환경 변수:
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
settings.json:
{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }
4.2 팀 생성
자연어로 팀 구성을 요청하면 Claude가 알아서 생성한다:
CLI 도구의 UX를 여러 관점에서 탐색할 에이전트 팀을 만들어줘. - 한 팀원은 UX 분석 - 한 팀원은 기술 아키텍처 - 한 팀원은 반대 의견 제시 역할
4.3 디스플레이 모드
| 모드 | 설명 | 설정 |
|---|---|---|
| In-process (기본) | 모든 팀원이 메인 터미널에서 실행 | "teammateMode": "in-process" |
| Split-pane | 각 팀원이 별도 패인에서 실행 (tmux/iTerm2 필요) | "teammateMode": "tmux" |
| Auto | tmux 세션 내면 split, 아니면 in-process | "teammateMode": "auto" |
4.4 키보드 단축키 (In-process 모드)
| 키 | 기능 |
|---|---|
Shift+Up/Down | 팀원 선택 |
Enter | 선택한 팀원 세션 보기 |
Escape | 현재 팀원의 작업 중단 |
Ctrl+T | 작업 목록 토글 |
Shift+Tab | Delegate 모드 전환 |
Ctrl+B | 현재 작업을 백그라운드로 전환 |
4.5 Delegate 모드
Lead가 직접 코드를 작성하지 않고 조율에만 집중하게 하는 모드:
Shift+Tab 을 눌러 Delegate 모드 활성화
Lead는 팀원 생성, 메시징, 작업 관리만 수행하고 코드 수정은 팀원에게 위임한다.
4.6 Plan Approval 워크플로우
위험한 작업에 대해 팀원이 계획을 먼저 제출하도록 요청 가능:
인증 모듈을 리팩토링할 아키텍트 팀원을 생성해줘. 코드 변경 전에 계획 승인을 받도록 해줘.
- 팀원이 읽기 전용 plan mode에서 작업
- 계획 승인 요청을 Lead에 제출
- Lead가 승인/거부 (거부 시 피드백과 함께 재작업)
- 승인 후 구현 시작
4.7 팀원과 직접 대화
각 팀원은 독립된 Claude Code 세션이므로 직접 대화 가능:
- In-process:
Shift+Up/Down으로 선택 후 메시지 입력 - Split-pane: 해당 패인 클릭 후 직접 상호작용
4.8 팀 종료
팀을 정리해줘 (Clean up the team)
- 먼저 각 팀원에게 종료 요청
- 모든 팀원 종료 확인 후 팀 리소스 정리
- 반드시 Lead를 통해 정리 (팀원이 직접 정리하면 불완전할 수 있음)
5. 효과적인 팀 활용 전략
5.1 팀 활용이 효과적인 경우
| 상황 | 이유 |
|---|---|
| 병렬 코드 리뷰 | 보안/성능/테스트 등 관점별 독립 리뷰 |
| 경쟁 가설 디버깅 | 여러 원인을 동시에 조사하여 빠른 근본 원인 파악 |
| 새 모듈/기능 개발 | 각 팀원이 독립적인 모듈을 담당 |
| 크로스레이어 변경 | 프론트엔드, 백엔드, 테스트를 각 팀원이 담당 |
| 리서치 & 탐색 | 다양한 라이브러리/접근법을 동시에 조사 |
5.2 팀 활용을 피해야 하는 경우
| 상황 | 대안 |
|---|---|
| 순차적 작업 | 단일 세션 |
| 같은 파일 수정 | 단일 세션 또는 Subagent |
| 의존성이 높은 작업 | 단일 세션 |
| 단순/루틴 작업 | 단일 세션 (토큰 절약) |
5.3 핵심 베스트 프랙티스
1) 팀원에게 충분한 컨텍스트 제공
팀원은 CLAUDE.md, MCP 서버, Skills는 로드하지만 Lead의 대화 히스토리는 상속하지 않는다. 생성 시 구체적인 정보를 제공해야 한다:
보안 리뷰어 팀원을 생성해줘. 프롬프트: "src/auth/ 의 인증 모듈을 보안 취약점 관점에서 리뷰해줘. JWT 토큰 처리, 세션 관리, 입력 검증에 집중해. 앱은 httpOnly 쿠키에 JWT를 저장해. 심각도 등급과 함께 이슈를 보고해."
2) 작업 크기를 적절하게
- 너무 작으면: 조율 오버헤드가 이점을 초과
- 너무 크면: 팀원이 너무 오래 체크인 없이 작업하여 낭비 위험
- 적정 크기: 함수 하나, 테스트 파일 하나, 리뷰 하나 등 명확한 산출물 단위
- 팀원당 5-6개 작업이 적정
3) 파일 충돌 방지
두 팀원이 같은 파일을 수정하면 덮어쓰기 발생. 각 팀원에게 다른 파일 세트를 할당해야 한다.
4) 팀원 완료 대기
Lead가 팀원을 기다리지 않고 직접 구현하는 경우가 있다:
팀원들이 작업을 완료할 때까지 기다려줘
5) 리서치/리뷰부터 시작
처음 사용할 때는 코드 작성 없이 PR 리뷰, 라이브러리 조사, 버그 탐색 등 읽기 전용 작업부터 시작하는 것이 좋다.
6) 주기적 모니터링
팀원의 진행 상황을 확인하고, 잘못된 방향으로 가면 즉시 리다이렉트한다. 방치하면 토큰 낭비로 이어진다.
6. 실전 활용 예시
6.1 병렬 코드 리뷰
PR #142를 리뷰할 에이전트 팀을 만들어줘. 3명의 리뷰어를 생성: - 보안 취약점에 집중하는 리뷰어 - 성능 영향을 체크하는 리뷰어 - 테스트 커버리지를 검증하는 리뷰어 각자 리뷰 후 결과를 보고해줘.
6.2 경쟁 가설 디버깅
사용자가 메시지 하나 보낸 후 앱이 종료된다고 보고했어. 5명의 에이전트 팀원을 생성해서 서로 다른 가설을 조사해줘. 팀원들이 서로 대화하면서 상대방의 이론을 반증하도록 해줘, 과학적 토론처럼. 합의된 결론을 문서에 업데이트해줘.
6.3 다중 모듈 기능 개발
에이전트 팀을 만들어서 이 모듈들을 병렬로 리팩토링해줘. - 팀원1: 사용자 인증 모듈 (src/auth/) - 팀원2: 데이터베이스 레이어 (src/db/) - 팀원3: API 라우팅 (src/routes/) - 팀원4: 테스트 작성 (tests/) 각 팀원은 Sonnet 모델을 사용해줘.
6.4 리서치 탐색
상태 관리 라이브러리를 조사할 팀을 만들어줘: - 팀원1: Redux Toolkit 분석 - 팀원2: Zustand 분석 - 팀원3: Jotai 분석 각 팀원이 장단점, 번들 크기, 학습 곡선을 조사한 후 서로 토론해서 우리 프로젝트에 최적인 것을 추천해줘.
7. 제한사항 및 주의점
7.1 현재 제한사항 (실험적 기능)
| 제한 | 설명 |
|---|---|
| 세션 복원 불가 | /resume, /rewind로 팀원 복원 불가 |
| 작업 상태 지연 | 팀원이 완료 표시를 누락하여 의존 작업이 블로킹될 수 있음 |
| 느린 종료 | 현재 도구 호출 완료까지 대기 |
| 세션당 1팀 | 한 Lead가 동시에 1개 팀만 관리 |
| 중첩 불가 | 팀원이 하위 팀 생성 불가 |
| Lead 고정 | 리더십 이전 불가 |
| 권한 고정 | 생성 시 Lead 권한 상속, 이후 개별 변경 가능하나 생성 시 지정 불가 |
| Split-pane 제한 | tmux 또는 iTerm2만 지원 (VS Code, Windows Terminal, Ghostty 미지원) |
7.2 비용 고려
Agent Teams는 단일 세션보다 훨씬 많은 토큰을 소비한다. 각 팀원이 독립 인스턴스이므로:
- 팀원 3명 = 약 3배 이상의 토큰 사용
- 리서치, 리뷰, 신규 기능 개발에는 가치 있음
- 루틴 작업에는 비효율적
7.3 트러블슈팅
| 문제 | 해결 |
|---|---|
| 팀원이 안 보임 | Shift+Down으로 순회 확인 / 작업이 팀을 필요로 할만큼 복잡한지 확인 |
| 권한 프롬프트 과다 | settings.json에서 자주 쓰는 작업 미리 승인 |
| 팀원 에러 중단 | 직접 메시지로 지시 또는 대체 팀원 생성 |
| Lead가 조기 종료 | "팀원들이 끝날 때까지 기다려줘"로 지시 |
| 고아 tmux 세션 | tmux ls → tmux kill-session -t <name> |
8. 우리 프로젝트 적용 방안
8.1 현재 프로젝트와의 연계
우리 프로젝트(FullStackFamily)는 이미 다양한 Subagent를 활용 중이다:
| 현재 Subagent | 역할 |
|---|---|
backend-tdd | 백엔드 TDD 개발 |
frontend-developer | 프론트엔드 구현 |
frontend-tester | 빌드/테스트 |
code-reviewer | 코드 리뷰 |
db-migrator | DB 마이그레이션 |
deployer | 배포 |
8.2 Agent Teams 적용 시나리오
시나리오 1: Phase 개발 병렬화
에이전트 팀으로 Phase 80 (배너관리시스템) 개발: - 팀원1: 백엔드 API 개발 (backend-tdd 역할) - 팀원2: 프론트엔드 구현 (frontend-developer 역할) - 팀원3: 테스트 및 리뷰 (tester/reviewer 역할)
단, 파일 충돌 방지를 위해 각 팀원의 작업 영역을 명확히 분리해야 한다.
시나리오 2: 코드 리뷰 강화
PR을 3가지 관점에서 병렬 리뷰: - 보안 (OWASP Top 10) - 성능 (N+1, 쿼리 최적화) - 코드 품질 (패턴 준수, 재사용성)
시나리오 3: 버그 조사
프로덕션 이슈를 여러 가설로 동시 조사: - 팀원1: 백엔드 로그 분석 - 팀원2: 프론트엔드 네트워크 요청 분석 - 팀원3: DB 쿼리/데이터 정합성 확인
8.3 도입 권장 단계
- 1단계: settings.json에 환경 변수 추가하여 활성화
- 2단계: 읽기 전용 작업(코드 리뷰, 리서치)으로 연습
- 3단계: 독립 모듈 병렬 개발에 적용
- 4단계: Phase 전체 워크플로우에 통합
댓글
댓글을 작성하려면 이 필요합니다.