Claude Agent Teams는 2026년 2월 5일 Anthropic이 Claude Opus 4.6과 함께 출시한 다중 에이전트 협업 기능으로, 여러 Claude Code 인스턴스가 팀을 이뤄 병렬 작업을 수행합니다. 공식적으로는 Claude Code CLI 전용이지만, Cursor IDE에서도 Task 기반 병렬 패턴으로 유사한 효과를 낼 수 있습니다.
다들 에이전트 팀 좋다고 하잖아요.
“5명이 동시에 일한다”, “비용 86% 절감”, “시간 50% 단축”.
솔직히 저도 처음엔 “이거 진짜인가?” 싶었어요. 그리고 한 가지 의문이 더 있었어요.
“나 Cursor 쓰는데… 이거 Cursor에서도 되는 거야?”
Claude Code CLI에서만 된다는 말이 있고, Cursor에서도 비슷하게 할 수 있다는 말이 있고. 뭐가 맞는 건지 헷갈리더라고요.
그래서 직접 돌려봤습니다. 에이전트 5명을 병렬로 돌리는 모닝 브리핑 팀을 Cursor에서 실행해봤어요.
결과부터 말하면 — 5명 전원 성공. 근데 “되는 것”과 “안 되는 것”이 확실히 나뉘더라고요.
에이전트 팀이 뭔데? 30초 정리
에이전트 팀… 뭔 소린지 모르겠죠? 쉽게 말할게요.
“AI 여러 명이 한 팀으로 동시에 일하는 것.”
끝. 이게 전부예요.
에이전트 팀(Agent Teams)이란? Anthropic이 2026년 2월 5일 Claude Opus 4.6과 함께 발표한 실험적 기능으로, 여러 Claude Code 인스턴스가 팀을 이뤄 병렬로 작업을 수행합니다. 팀 리드가 전체를 조율하고, 팀원들이 독립적으로 태스크를 실행합니다. Claude Code CLI에서
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1환경변수로 활성화합니다.
기존에는 AI한테 일 시키면 한 명이 처음부터 끝까지 순차적으로 했잖아요. 시장 데이터 검색하고, 뉴스 찾고, 블로그 분석하고, 트레이딩 체크하고… 하나씩.
에이전트 팀은 이걸 동시에 합니다.
기존 (순차): 시장 검색 → 뉴스 검색 → 블로그 분석 → 트레이딩 체크 → 종합 ⏱️ 약 5분 에이전트 팀 (병렬): 시장 검색 ─┐ 뉴스 검색 ─┤ 블로그 분석 ┤ → 종합 트레이딩 ──┘ ⏱️ 약 1~2분
시간이 반으로 줄어요. 근데 여기서 중요한 게 있어요.
이 “에이전트 팀”이라는 단어가 두 가지 의미로 쓰이고 있다는 겁니다.
핵심: “에이전트 팀”은 두 가지가 있다
이거 모르면 혼동이 생겨요. 저도 처음엔 헷갈렸어요.
1번: 공식 Agent Teams (Claude Code CLI 전용)
Anthropic이 만든 진짜 에이전트 팀 기능. Claude Code 터미널에서만 됩니다.
# 이 환경변수를 켜야 활성화 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
이걸 켜면 팀원끼리 직접 메시지를 주고받을 수 있어요. “야 내가 찾은 데이터 좀 봐봐” 같은 실시간 협업이 가능. 공유 태스크 리스트에서 워커가 스스로 할 일을 가져가는 자율적 구조.
tmux 분할 화면으로 팀 전체 상태를 실시간으로 볼 수도 있어요. 꽤 멋집니다.
문제: Cursor에서는 이게 안 됩니다.
2번: Task 기반 병렬 패턴 (Cursor에서도 됨)
Cursor의 Task 도구로 여러 서브에이전트를 동시에 spawn하는 패턴.
메인 에이전트 (sonnet급) ├── Task 1 (fast 모델) → 시장 검색 ← 동시 실행 ├── Task 2 (fast 모델) → 뉴스 검색 ← 동시 실행 ├── Task 3 (fast 모델) → 블로그 분석 ← 동시 실행 ├── Task 4 (fast 모델) → 트레이딩 체크 ← 동시 실행 └── 메인이 결과 종합
이건 공식 Agent Teams가 아닙니다. Cursor 자체 기능으로 비슷한 효과를 내는 것.
그리고 이게 — 실제로 돌아갑니다.
실행 증거: Cursor에서 에이전트 5명 병렬로 돌려봤습니다
말로만 하면 안 믿으시잖아요. 직접 돌린 결과를 보여드릴게요.
실험 세팅
모닝 브리핑 팀을 만들었어요. 매일 아침 시장/크립토/뉴스/블로그/트레이딩 데이터를 수집해서 하나의 브리핑으로 만드는 워크플로우.
Orchestrator (메인 에이전트, sonnet급) ├── market-scanner (fast 모델) ← 병렬 ├── crypto-scanner (fast 모델) ← 병렬 ├── news-analyst (fast 모델) ← 병렬 ├── blog-analyst (fast 모델) ← 병렬 ├── trading-coach (fast 모델) ← 병렬 └── report-writer (sonnet급) ← 순차 (워커 완료 후)
5개 워커를 하나의 메시지에서 동시에 Task로 호출. 각 워커는 fast 모델(haiku급)로 실행.
실행 결과
Generated: 2026-02-10 07:30 (KST) Workers: 5/5 성공
5명 전원 복귀.
시장 데이터, 크립토 가격, 뉴스 TOP 5, 블로그 글감, 트레이딩 코치까지. 5개 워커가 동시에 돌아가서 각자 결과를 가져왔고, report-writer가 이걸 합쳐서 하나의 브리핑으로 만들었어요.
전체 소요 시간? 약 2분. 기존에 단일 에이전트로 순차 실행하면 5분 걸리던 걸.
실제 실행 과정 (트랜스크립트에서 확인)
[Tool call] Task ← market-scanner 출발 [Tool call] Task ← crypto-scanner 출발 [Tool call] Task ← news-analyst 출발 [Tool call] Task ← blog-analyst 출발 [Tool call] Task ← trading-coach 출발 (5개가 동시에 실행됨) [Tool result] Task ← market-scanner 복귀 [Tool result] Task ← crypto-scanner 복귀 [Tool result] Task ← news-analyst 복귀 [Tool result] Task ← blog-analyst 복귀 [Tool result] Task ← trading-coach 복귀 [Tool call] Task ← report-writer 실행 (5개 결과 합성)
5개 [Tool call] Task가 한 번에 나가고, 5개 [Tool result] Task가 돌아온 거 보이시죠?
이게 Cursor에서 일어난 일이에요. Claude Code CLI가 아니라 Cursor IDE 안에서요.
되는 것: Cursor에서 확인된 기능들
항목별로 체크해봤습니다.
✅ 5개 Task 병렬 실행
하나의 메시지에서 Task 5개를 동시에 호출하면 실제로 병렬 실행됩니다. 이건 Cursor 2.4에서 도입된 Subagent 기능 덕분이에요.
✅ 모델 라우팅 (fast vs 기본)
워커는 model: fast (haiku급, 저렴), report-writer는 기본 모델 (sonnet급, 고성능). 이 구분이 Cursor에서도 정확하게 작동해요.
| 역할 | 모델 | Cursor에서 |
|---|---|---|
| 5개 워커 | fast (haiku급) | ✅ 정상 |
| report-writer | 기본 (sonnet급) | ✅ 정상 |
✅ 변수 치환
에이전트 설정 파일에 {오늘 날짜}, {YYYY-MM} 같은 변수를 넣으면, 오케스트레이터가 실제 값으로 치환해서 워커에게 전달합니다.
md 파일: "오늘 날짜는 {오늘 날짜}이다"
실제 전달: "오늘 날짜는 2026-02-10 (화요일)이다"
대부분의 변수 치환이 잘 됩니다. 대부분.
✅ 상대 경로 → 절대 경로 변환
이건 좀 놀랐어요. md 파일에 상대 경로로 적어놨는데:
Read: '2. 🛠 Areas/blog/blog-ideas.md'
오케스트레이터가 알아서 절대 경로로 바꿔서 전달했어요:
Read tool로 이 파일을 읽어라: '/Users/jtpark/Library/Mobile Documents/.../blog-ideas.md'
서브에이전트가 절대 경로가 없으면 파일을 못 찾을 수 있는데, 메인 에이전트가 이걸 자동으로 처리해준 거죠. 꽤 똑똑합니다.
✅ 호칭 등 세부 지시
“트레이딩 코치 섹션에서 ‘형’으로 호칭” 같은 세부 지시도 정확하게 전달되고 실행됐어요.
✅ 결과 합성 + 파일 저장
5개 워커 결과를 모아서 하나의 마크다운으로 합성하고, 지정된 경로에 저장. 이 과정이 깔끔하게 진행됐습니다.
안 되는 것: Cursor에서 확인된 한계
여기서부터가 좀 아쉬운 부분이에요.
❌ 오케스트레이터가 프롬프트를 “맘대로” 줄인다
이거 솔직히 좀 당황했어요.
시장 스캐너(Worker 1)에 꽤 상세한 지시를 적어뒀거든요.
# md 파일에 적어둔 지시 (요약) - 날짜 검증 필수 (4개 조건) - 직전 거래일(영업일) 종가 확인 - 날짜가 안 맞으면 site:marketwatch.com 등으로 추가 검색 - Dow Jones 포함 - 기준 날짜를 제목에 표시
근데 실제로 워커에게 전달된 프롬프트는? 상당 부분이 잘려 있었어요.
| md에 적은 것 | 실제 전달 여부 |
|---|---|
| 날짜 검증 필수 (⚠️ 블록) | ❌ 전달 안 됨 |
| 직전 거래일 계산 | ❌ 생략됨 |
| Dow Jones 행 | ❌ 누락 |
| 추가 검색 폴백 | ❌ 전달 안 됨 |
| 기준 날짜 표시 | ⚠️ 누락 |
결과적으로 ETF 가격 데이터가 N/A 투성이였어요. QQQ, NVDY 가격을 못 찾아온 거죠. 날짜 검증 로직이 빠졌으니 오래된 데이터도 그냥 가져왔고.
교훈: 프롬프트는 짧고 핵심적일수록 잘 전달된다.
실제로 뉴스 워커(Worker 3)나 트레이딩 코치(Worker 5)처럼 간결한 프롬프트를 준 워커들은 거의 완벽하게 동작했어요.
근데 시장 스캐너처럼 조건이 많고 복잡한 프롬프트는 오케스트레이터가 “이건 너무 길어” 하면서 자기 맘대로 요약해버린 거예요.
❌ 팀원 간 직접 메시지 불가
공식 Agent Teams에서는 워커 A가 워커 B에게 “야 이거 봐봐” 하고 직접 메시지를 보낼 수 있어요.
Cursor에서는? 모든 통신이 부모(메인 에이전트)를 거칩니다. 워커끼리 직접 대화 불가.
솔직히 말하면, 모닝 브리핑 같은 독립 병렬 태스크에서는 이 제한이 거의 문제가 안 돼요. 워커끼리 대화할 필요가 없거든요. 각자 검색하고 결과만 보고하면 되니까.
근데 “코드 리뷰어 A가 보안 이슈를 발견해서 성능 리뷰어 B한테 알려줘야 하는” 같은 복잡한 협업 시나리오에서는 이 차이가 크게 느껴질 수 있어요.
❌ 공유 태스크 리스트 없음
Agent Teams에서는 공유 태스크 보드가 있어요. 리드가 태스크를 올려놓으면 워커가 스스로 가져가는(claim) 구조.
Cursor에서는 메인 에이전트가 태스크를 직접 배분합니다. 워커가 자율적으로 태스크를 선택하는 구조는 없어요.
❌ tmux 분할 뷰 없음
Claude Code CLI에서는 tmux로 팀 전체 상태를 한 화면에서 실시간으로 볼 수 있어요. 꽤 멋있죠.
Cursor에서는 IDE 내에서 Task 진행 상태를 보는 정도. 시각적으로 팀 전체를 조망하는 건 불가.
❌ opus 모델 지정이 안 먹는 경우
md 파일에 모델: opus라고 적어놨는데, 실제 실행에서는 기본 모델(sonnet급)로 돌아갔어요. Cursor의 Task 도구에서 모델 옵션이 fast와 기본 두 가지만 있어서 opus 지정이 제대로 먹히지 않는 케이스가 있었습니다.
비교표: 공식 Agent Teams vs Cursor Task 패턴
| 구분 | Agent Teams (CLI) | Cursor Task 패턴 |
|---|---|---|
| 플랫폼 | 터미널(CLI) 전용 | IDE(에디터) |
| 활성화 | 환경변수 필요 | 별도 설정 없음 |
| 병렬 실행 | ✅ | ✅ |
| 모델 라우팅 | haiku/sonnet/opus 자유 지정 | fast / 기본 (2단계) |
| 팀원 간 대화 | ✅ 직접 메시지 | ❌ 부모를 거침 |
| 공유 태스크 | ✅ claim 방식 | ❌ 부모가 배분 |
| 모니터링 | tmux 분할 뷰 | IDE 내 상태 |
| 설정 | AGENTS.md 팀 설정 | .claude/agents/ 개별 파일 |
작업별 효과 비교
실제로 같은 작업을 양쪽에서 돌리면 얼마나 차이가 날까요?
| 작업 유형 | Cursor에서의 방법 | Agent Teams 대비 효과 |
|---|---|---|
| 모닝 브리핑 / 리서치 | Task(fast) 5개 병렬 | 95% 유사 ✅ 검증 완료 |
| 코드 리뷰 | Task 3개 (보안/성능/품질) | 80% 유사 |
| 개발 병렬화 | Worktree + 각각 에이전트 | 70% 유사 (조율 수동) |
| 글쓰기 | 단일 에이전트 유지 | 동일 (팀 불필요) |
독립 병렬 태스크는 95% 유사해요. 이건 직접 검증한 수치입니다.
이걸 보고 내가 느낀 것: 생각보다 많이 된다
솔직히 처음 실험할 때는 “Cursor에서 에이전트 팀? 반쯤만 되겠지” 했거든요.
근데 5/5 성공으로 돌아온 결과를 보고 생각이 바뀌었어요.
내가 “에이전트 팀”이라고 부르던 것의 핵심은 “병렬 실행”이었고, 그건 Cursor에서 이미 되고 있었다.
공식 Agent Teams의 화려한 기능들 — 팀원 간 직접 메시지, 공유 태스크 보드, tmux 모니터링 — 이런 건 확실히 멋있어요. 근데 실무에서 이게 꼭 필요한 케이스가 많은가?
제 경험상, 대부분의 워크플로우는 “독립적인 태스크를 동시에 돌리고 결과를 모으는” 구조예요.
시장 데이터 검색은 뉴스 검색과 독립적이잖아요. 블로그 분석은 트레이딩 체크와 독립적이고. 이런 독립 병렬 태스크에서는 Cursor의 Task 패턴으로 충분합니다.
Cursor에서 에이전트 팀을 세팅하는 방법
그렇다면 실제로 어떻게 만드는 건지 알려드릴게요.
1단계: 에이전트 설정 파일 작성
.claude/agents/ 폴더에 md 파일을 만듭니다.
# my-research-team.md ## 팀 구성 Orchestrator (이 에이전트) ├── researcher-1 (fast, 병렬) ├── researcher-2 (fast, 병렬) ├── researcher-3 (fast, 병렬) └── report-writer (기본, 순차) ## 실행 순서 ### STEP 1: 3개 워커 병렬 실행 (Task, fast) 모든 워커를 동시에 Task로 spawn. ### STEP 2: 결과 수집 3개 워커의 결과가 모두 돌아오면 다음 단계. ### STEP 3: report-writer 실행 결과를 합성하여 최종 보고서 생성.
2단계: 워커별 프롬프트 작성 (중요!)
여기서 핵심은 — 프롬프트를 짧고 명확하게 작성하는 거예요.
#### Worker 1: market-researcher
모델: fast
프롬프트:
"WebSearch로 S&P 500, NASDAQ, 금 가격을 검색해라.
오늘 날짜는 {오늘 날짜}이다.
결과를 마크다운 테이블로 정리. 못 찾으면 N/A."
제 실험에서 확인된 팁:
| 프롬프트 길이 | 전달 정확도 | 결과 품질 |
|---|---|---|
| 5줄 이하 | ✅ 거의 완벽 | 높음 |
| 10줄 내외 | ⚠️ 대부분 전달 | 보통 |
| 20줄 이상 | ❌ 일부 잘림 | 낮음 (N/A 다수) |
오케스트레이터가 긴 프롬프트를 요약해버리는 현상이 있으니, 핵심만 넣으세요.
3단계: 호출
@my-research-team 오늘 리서치 시작
메인 에이전트가 md 파일을 읽고, “아 Task를 3개 동시에 쏴야 하는구나” 이해한 다음, Cursor의 Task 도구로 실행합니다.
그러면 언제 Claude Code CLI를 써야 하나?
Cursor에서 대부분 되지만, 확실히 Claude Code CLI가 필요한 순간이 있어요.
CLI로 가야 하는 경우
- 에이전트끼리 실시간 토론이 필요한 복잡한 개발
- “보안 리뷰어가 발견한 이슈를 성능 리뷰어한테 바로 알려야 하는” 케이스
- 워커 간 직접 메시지가 없으면 번거로운 작업
- 10명 이상의 대규모 팀
- Cursor Task를 10개 이상 동시에 돌리는 건 현실적으로 부담
- CLI의 Agent Teams는 이런 대규모 구성에 최적화
- 팀 상태를 실시간으로 모니터링하고 싶을 때
- tmux 분할 뷰는 CLI만의 킬러 피처
Cursor에서 충분한 경우
- 데이터 수집 / 리서치 — Task(fast) 3~5개 병렬로 충분
- 코드 리뷰 — Task 3개 (보안/성능/품질)
- 일상적인 병렬 작업 — 모닝 브리핑, 글감 수집, 웹 스크래핑
- 글쓰기 — 이건 아예 팀이 필요 없음. 단일 에이전트가 최고
솔직한 마음: 불안하지만 방향은 보인다
에이전트 팀을 실험하면서 솔직히 좀 복잡한 감정이 들었어요.
“AI 5명이 동시에 일한다”는 게 처음엔 신기하고 재미있었는데, 점점 “이거 어디까지 가는 거지?” 하는 생각이 들더라고요. 혼자서 5명분의 일을 시키고 결과를 받아보는 건 효율적이지만, 동시에 묘한 불안감도 있어요.
근데 방향은 보여요.
도구는 도구일 뿐이에요. CLI든 Cursor든, 공식 Agent Teams든 Task 패턴이든 — 중요한 건 “이걸로 뭘 만드느냐”예요.
제 경우엔 매일 아침 모닝 브리핑을 2분 만에 받는 것. 이 하나만으로도 에이전트 팀의 가치는 충분했어요.
앞으로 내가 할 것들
- Worker 1(시장 스캐너) 프롬프트 리팩토링 — 길고 복잡한 지시를 5줄 이내로 줄여서 전달 정확도 높이기
- 코드 리뷰 팀 실험 — 보안/성능/가독성 3명 병렬 리뷰를 Cursor에서 구현
- Cursor Worktree 병렬도 테스트 — 개발 작업은 Task보다 Worktree가 나을 수 있음
- CLI Agent Teams와 정식 비교 — 같은 작업을 양쪽에서 돌려서 실측 비교 데이터 수집
FAQ
Q: Claude 에이전트 팀을 Cursor에서 그대로 쓸 수 있나요?
A: 공식 Agent Teams 기능(CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1)은 Claude Code CLI 전용이라 Cursor에서 직접 활성화할 수 없습니다. 하지만 Cursor의 Task 도구로 여러 서브에이전트를 병렬 실행하면 95% 유사한 효과를 낼 수 있습니다. 2026년 2월 10일 기준, 5개 워커 병렬 실행이 성공적으로 검증됐습니다.
Q: Cursor에서 에이전트 팀을 만들려면 뭐가 필요한가요?
A: 별도 설정이나 환경변수는 필요 없습니다. .claude/agents/ 폴더에 팀 구성 md 파일을 만들고, @에이전트명으로 호출하면 됩니다. Cursor 2.4 이상이면 Subagent(Task 도구)를 지원합니다.
Q: 워커를 몇 개까지 병렬로 돌릴 수 있나요?
A: 제 실험에서는 5개가 안정적으로 돌아갔습니다. Cursor 2.0 기준으로 최대 8개 병렬 에이전트를 지원하지만, 병렬 수가 늘수록 토큰 사용량이 증가합니다(8개 병렬 시 약 25~35% 오버헤드). 실용적으로는 3~5개가 적정선입니다.
Q: 공식 Agent Teams와 Cursor Task 패턴의 가장 큰 차이는 뭔가요?
A: 팀원 간 직접 대화 가능 여부입니다. Agent Teams에서는 워커 A가 워커 B에게 직접 메시지를 보낼 수 있지만, Cursor에서는 모든 통신이 메인 에이전트를 거쳐야 합니다. 독립 병렬 태스크(리서치, 데이터 수집)에서는 이 차이가 거의 느껴지지 않습니다.
Q: 에이전트 팀이 필요한 작업과 필요 없는 작업은?
A: 데이터 수집, 리서치, 코드 리뷰처럼 독립적으로 쪼갤 수 있는 작업에 팀이 효과적입니다. 반면 블로그 글쓰기, 디버깅 같은 순차적이고 맥락이 이어지는 작업은 단일 에이전트가 낫습니다. “병렬화 가능 비율”이 높을수록 팀이 유리합니다.
참고 자료
- Anthropic Claude Opus 4.6 with Agent Teams 발표 (2026.02.05)
- Claude Code Agent Teams 공식 문서
- Cursor 2.4 Subagents 기능
- Cursor 2.0 Parallel Agents (2025.10.29)
🏷️ 태그: #Claude #에이전트팀 #AgentTeams #Cursor #AI자동화 #병렬실행 #Subagent