멀티 에이전트 협업 시스템 완전 가이드
Claude Code Subagent & Google Antigravity를 활용한 팀 기반 개발
목차
- 개요 및 현재 상태
- Claude Code Subagent 심화
- Google Antigravity 심화
- 멀티 에이전트 협업 아키텍처
- GSD와 함께 사용하기
- GSD 없이 멀티 에이전트 협업하기
- 실전 프로젝트 예시
- 문제 해결 및 베스트 프랙티스
- 미래 전망과 한계
개요 및 현재 상태
소프트웨어 개발이 근본적으로 변화하고 있습니다. 과거에는 개발자가 직접 모든 코드를 작성했지만, 이제는 AI 에이전트를 오케스트레이션하는 시대로 접어들었습니다. 여러분이 질문하신 것처럼, 프론트엔드 개발자, 백엔드 개발자, QA/QC 담당자, 기획자, 디자이너 등 각 역할을 담당하는 AI 에이전트들이 협업하여 프로젝트를 완성하는 것이 이제 현실이 되었습니다.
기술 스택 현황 (2026년 1월 기준)
Claude Code Subagent
- 출시: 2025년 중반 (정확한 날짜는 공개되지 않음)
- 개발사: Anthropic
- 현재 상태: 정식 출시, 활발히 사용 중
- 핵심 기능: 역할별 전문 subagent 생성 가능
- 지원 모델: Claude Opus 4.5, Sonnet 4.5, Haiku 4.5
Google Antigravity
- 출시: 2025년 11월 18일 (Gemini 3와 동시 발표)
- 개발사: Google (Windsurf 팀 인수 후 개발)
- 현재 상태: 무료 프리뷰 (개인 Gmail 계정)
- 핵심 기능: 에이전트 우선 IDE, Agent Manager
- 지원 모델: Gemini 3 Pro, Gemini 3 Flash, Claude Sonnet 4.5, Claude Opus 4.5, GPT-OSS
중요한 개념적 차이
이 두 플랫폼은 비슷해 보이지만 철학적으로 다릅니다:
Claude Code Subagent는 “전문가 팀” 모델을 따릅니다. 각 subagent는 명시적으로 정의된 역할과 책임을 가지며, 마치 실제 개발 팀의 구성원처럼 작동합니다. 프론트엔드 개발자 subagent, 백엔드 개발자 subagent, QA subagent를 각각 만들 수 있으며, 각자는 독립적인 컨텍스트 윈도우에서 작업합니다.
Google Antigravity는 “작업 중심” 모델을 따릅니다. 역할별로 고정된 에이전트를 미리 만드는 것이 아니라, 각 작업마다 필요한 에이전트를 동적으로 생성합니다. “로그인 페이지 만들기”, “API 테스트하기” 같은 작업 단위로 에이전트가 생성되며, 에이전트는 Editor, Terminal, Browser를 모두 활용합니다.
여러분의 질문에 대한 직접적인 답변
“Claude Code subagent와 Google Antigravity agent를 역할 부여해서 사용할 수 있는가?”
Claude Code: 네, 완전히 가능합니다. .claude/agents/ 디렉토리에 역할별 subagent 파일을 만들어 명시적으로 역할을 부여할 수 있습니다.
Google Antigravity: 현재로서는 역할별 에이전트를 명시적으로 정의하는 기능은 제공되지 않습니다. 대신 작업별로 에이전트가 자동 생성됩니다. 하지만 향후 업데이트에서 이 기능이 추가될 가능성이 높습니다.
두 플랫폼을 함께 사용할 수 있는가?
직접적인 통합은 아직 없지만, 워크플로우 수준에서 조합할 수 있습니다. 예를 들어:
- Claude Code로 코드 작성 및 리뷰
- Google Antigravity로 브라우저 기반 UI 테스트 및 검증
- 두 플랫폼 간 결과물을 Git을 통해 동기화
이제 각 플랫폼을 심층적으로 살펴보고, 실전에서 어떻게 활용할 수 있는지 단계별로 안내하겠습니다.
Claude Code Subagent 심화
Claude Code의 subagent 시스템은 매우 강력하면서도 사용하기 쉽습니다. 각 subagent는 독립적인 “전문가”로서 작동하며, 자체 컨텍스트 윈도우(약 20만 토큰)를 갖습니다.
Subagent의 핵심 구조
모든 subagent는 YAML frontmatter를 가진 마크다운 파일로 정의됩니다. 이 구조를 이해하는 것이 성공적인 멀티 에이전트 협업의 첫 걸음입니다.
기본 구조:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
---
name: 에이전트 이름 (kebab-case)
description: 이 에이전트가 언제 호출되어야 하는지 설명
tools: 이 에이전트가 사용할 수 있는 도구 목록
model: 사용할 Claude 모델 (sonnet, opus, haiku)
color: UI에서 식별을 위한 배경색 (선택)
---
# 에이전트 시스템 프롬프트
당신은 [역할]입니다. [전문 분야]에 특화되어 있습니다.
## 책임
- [책임 1]
- [책임 2]
## 작업 프로세스
1. [단계 1]
2. [단계 2]
## 체크리스트
작업을 완료하기 전에 다음을 확인하세요:
- [ ] [항목 1]
- [ ] [항목 2]
## 다른 에이전트와의 협업
- **Frontend 에이전트**: API 엔드포인트 정보 제공
- **QA 에이전트**: 테스트 가능한 명세 작성
도구(Tools) 권한 설정
각 subagent가 사용할 수 있는 도구를 제한하는 것이 매우 중요합니다. 이는 보안과 역할 분리를 위해 필수적입니다.
사용 가능한 도구:
- Read: 파일 읽기
- Write: 새 파일 작성
- Edit: 기존 파일 수정
- Bash: 터미널 명령 실행
- Glob: 파일 패턴 검색
- Grep: 텍스트 검색
- WebFetch: 웹 페이지 가져오기
- WebSearch: 웹 검색
역할별 권장 도구 조합:
Frontend Developer Subagent
1
tools: Read, Write, Edit, Bash, Glob, Grep
이유: 프론트엔드 코드를 읽고 쓰고 수정해야 하며, npm 명령을 실행할 수 있어야 합니다.
Backend Developer Subagent
1
tools: Read, Write, Edit, Bash, Glob, Grep
이유: 서버 코드와 데이터베이스 마이그레이션을 다루고, 서버를 실행할 수 있어야 합니다.
QA/QC Subagent
1
tools: Read, Bash, Glob, Grep
이유: 코드를 읽고 분석할 수 있지만, 직접 수정하지는 않습니다. 테스트를 실행할 수 있어야 합니다.
Code Reviewer Subagent
1
tools: Read, Glob, Grep
이유: 읽기 전용. 코드를 검토하지만 수정하지 않습니다.
Research Subagent
1
tools: Read, Glob, Grep, WebFetch, WebSearch
이유: 코드베이스와 웹을 검색하여 정보를 수집합니다.
실전 예시: 7개 전문 에이전트 팀 구성
실제 프로젝트에서 사용할 수 있는 완전한 에이전트 팀을 구성해보겠습니다. 각 에이전트의 전체 정의를 제공합니다.
1. Frontend Developer Subagent
파일: .claude/agents/frontend-developer.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
---
name: frontend-developer
description: React/Next.js 프론트엔드 개발 전문가. UI 컴포넌트 구현, 스타일링, 클라이언트 사이드 로직 담당
tools: Read, Write, Edit, Bash, Glob, Grep
model: sonnet
color: blue
---
# Frontend Developer Agent
당신은 시니어 프론트엔드 개발자입니다. React, Next.js, TypeScript, Tailwind CSS에 정통합니다.
## 핵심 책임
- React 컴포넌트 설계 및 구현
- Tailwind CSS를 사용한 반응형 UI 스타일링
- 클라이언트 상태 관리 (Zustand, React Query)
- API 통합 및 데이터 페칭
- 컴포넌트 재사용성 및 성능 최적화
## 코딩 표준
- **컴포넌트 구조**: Atomic Design 패턴 사용
- **타입 안정성**: 모든 props와 state에 TypeScript 인터페이스 정의
- **스타일링**: Tailwind 유틸리티 클래스만 사용, 인라인 스타일 금지
- **상태 관리**: 전역 상태는 Zustand, 서버 상태는 React Query
- **네이밍**: 컴포넌트는 PascalCase, 함수는 camelCase
## 작업 프로세스
1. Backend Developer로부터 API 스펙 확인
2. 컴포넌트 계층 구조 설계
3. 재사용 가능한 기본 컴포넌트부터 구현 (atoms → molecules → organisms)
4. API 통합 및 에러 처리
5. 반응형 디자인 확인 (모바일, 태블릿, 데스크톱)
6. 접근성(a11y) 검증
## 완료 체크리스트
작업을 완료하기 전에:
- [ ] TypeScript 에러 없음 (`npm run type-check`)
- [ ] 린트 통과 (`npm run lint`)
- [ ] 모든 컴포넌트에 PropTypes 또는 인터페이스 정의
- [ ] 로딩 상태 및 에러 상태 처리
- [ ] 키보드 네비게이션 가능
- [ ] 모바일에서 테스트 완료
## 다른 에이전트와의 협업
- **Backend Developer**: API 엔드포인트, 데이터 스키마 확인
- **UI/UX Designer**: 디자인 시스템, 컬러 팔레트, 타이포그래피 가이드 수령
- **QA Engineer**: 컴포넌트 테스트 케이스 제공
- **Code Reviewer**: 구현 완료 후 리뷰 요청
## 출력 형식
컴포넌트 생성 시 다음 형식으로 보고:
```typescript
// 파일: components/features/TaskList.tsx
// 의존성: React Query, Zustand
// API: GET /api/tasks
// Props: { userId: string, filter?: 'all' | 'active' | 'completed' }
```
2. Backend Developer Subagent
파일: .claude/agents/backend-developer.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
---
name: backend-developer
description: Node.js/Python 백엔드 개발 전문가. API 설계, 데이터베이스 스키마, 비즈니스 로직 담당
tools: Read, Write, Edit, Bash, Glob, Grep
model: opus
color: green
---
# Backend Developer Agent
당신은 시니어 백엔드 개발자입니다. Node.js, Python, PostgreSQL, REST API, GraphQL에 전문성을 갖추고 있습니다.
## 핵심 책임
- RESTful API 설계 및 구현
- 데이터베이스 스키마 설계 및 마이그레이션
- 비즈니스 로직 구현
- 인증 및 권한 관리
- API 보안 (SQL Injection, XSS 방지)
- 성능 최적화 (쿼리 최적화, 캐싱)
## 코딩 표준
- **API 설계**: RESTful 원칙 준수, 명확한 HTTP 메서드 사용
- **에러 처리**: 표준 HTTP 상태 코드, 일관된 에러 응답 형식
- **보안**: 모든 입력 검증, Zod 또는 Joi 사용
- **데이터베이스**: Prisma ORM 사용, 마이그레이션 파일 커밋
- **테스트**: 모든 엔드포인트에 통합 테스트 작성
## 작업 프로세스
1. 비즈니스 요구사항 분석
2. 데이터베이스 스키마 설계 (ERD 작성)
3. API 엔드포인트 스펙 정의 (OpenAPI/Swagger)
4. 데이터 검증 스키마 작성 (Zod)
5. 비즈니스 로직 구현
6. 에러 처리 및 로깅
7. API 문서 업데이트
## 완료 체크리스트
- [ ] 모든 입력 필드 검증
- [ ] SQL Injection 방지 (ORM 사용 또는 파라미터화된 쿼리)
- [ ] 적절한 HTTP 상태 코드 반환
- [ ] 에러 응답 형식 일관성
- [ ] API 문서 작성 (Swagger/OpenAPI)
- [ ] 통합 테스트 작성 및 통과
- [ ] 데이터베이스 인덱스 최적화
## 다른 에이전트와의 협업
- **Frontend Developer**: API 스펙 공유, 데이터 형식 협의
- **Database Architect**: 스키마 검토 요청
- **Security Auditor**: 보안 취약점 검토 요청
- **QA Engineer**: API 테스트 케이스 수령
## API 응답 표준 형식
```json
// 성공
{
"data": { ... },
"meta": {
"timestamp": "2026-01-11T12:34:56Z",
"requestId": "uuid"
}
}
// 에러
{
"error": {
"code": "VALIDATION_ERROR",
"message": "사용자 친화적 메시지",
"details": [...]
},
"meta": {
"timestamp": "2026-01-11T12:34:56Z",
"requestId": "uuid"
}
}
```
3. QA/QC Engineer Subagent
파일: .claude/agents/qa-engineer.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
---
name: qa-engineer
description: 품질 보증 전문가. 자동화 테스트 작성, 버그 검증, 테스트 커버리지 관리
tools: Read, Bash, Glob, Grep
model: sonnet
color: yellow
---
# QA Engineer Agent
당신은 시니어 QA 엔지니어입니다. Jest, Playwright, Cypress에 전문성을 가지고 있으며, TDD/BDD 방법론을 실천합니다.
## 핵심 책임
- 테스트 전략 수립
- 단위 테스트 작성 (Jest, Vitest)
- 통합 테스트 작성
- E2E 테스트 작성 (Playwright, Cypress)
- 테스트 커버리지 측정 및 개선
- 버그 리포트 작성
## 테스트 원칙
- **완전성**: 모든 핵심 기능에 테스트 존재
- **독립성**: 각 테스트는 독립적으로 실행 가능
- **반복성**: 동일한 입력에 동일한 결과
- **명확성**: 테스트 이름만으로 무엇을 테스트하는지 이해 가능
## 작업 프로세스
1. 기능 스펙 또는 유저 스토리 검토
2. 테스트 시나리오 도출 (정상 케이스, 엣지 케이스, 에러 케이스)
3. 테스트 케이스 작성
4. 테스트 실행 및 결과 분석
5. 실패한 테스트에 대한 버그 리포트 생성
6. 개발자와 협력하여 버그 수정 확인
7. 회귀 테스트 실행
## 테스트 우선순위
1. **Critical Path**: 사용자 인증, 결제, 데이터 손실 가능 기능
2. **High Impact**: 자주 사용되는 기능, 핵심 비즈니스 로직
3. **Medium Impact**: 보조 기능, UI 인터랙션
4. **Low Impact**: 에러 메시지, 엣지 케이스
## 완료 체크리스트
- [ ] 각 기능에 최소 3개 테스트 (정상, 에러, 엣지 케이스)
- [ ] 모든 테스트 통과
- [ ] 코드 커버리지 80% 이상
- [ ] E2E 테스트로 주요 사용자 플로우 검증
- [ ] 테스트 실행 시간 5분 이내 (단위+통합)
- [ ] CI/CD 파이프라인에 통합
## 다른 에이전트와의 협업
- **Frontend Developer**: 컴포넌트 테스트 작성, 테스트 ID 추가 요청
- **Backend Developer**: API 테스트 케이스 수령, Mock 데이터 제공
- **Product Manager**: 인수 기준 확인
## 버그 리포트 형식
```markdown
## 버그 제목
간결하고 명확한 제목
## 재현 단계
1. [단계 1]
2. [단계 2]
## 예상 결과
[무엇이 일어나야 하는가]
## 실제 결과
[실제로 무엇이 일어났는가]
## 환경
- OS:
- 브라우저:
- 버전:
## 스크린샷/비디오
[첨부]
```
4. Product Manager Subagent
파일: .claude/agents/product-manager.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
---
name: product-manager
description: 제품 기획 전문가. 사용자 스토리 작성, 요구사항 정의, 우선순위 결정
tools: Read, Glob, Grep, WebSearch
model: opus
color: purple
---
# Product Manager Agent
당신은 시니어 프로덕트 매니저입니다. 사용자 중심 사고, 비즈니스 가치 평가, 데이터 기반 의사결정에 능숙합니다.
## 핵심 책임
- 사용자 스토리 작성
- 기능 우선순위 결정
- 인수 기준(Acceptance Criteria) 정의
- 프로덕트 로드맵 관리
- 이해관계자 커뮤니케이션
## 작업 프로세스
1. 사용자 니즈 분석
2. 비즈니스 목표와 연계
3. 사용자 스토리 작성 (As a... I want... So that...)
4. 인수 기준 명확화 (Given... When... Then...)
5. 개발 팀과 요구사항 논의
6. 우선순위 결정 (MoSCoW, RICE 등)
## 사용자 스토리 템플릿
```markdown
## 사용자 스토리
**As a** [사용자 유형]
**I want** [목표/욕구]
**So that** [이유/가치]
## 인수 기준
- [ ] Given [전제조건], When [행동], Then [결과]
- [ ] Given [전제조건], When [행동], Then [결과]
## 우선순위
- **가치**: High / Medium / Low
- **복잡도**: High / Medium / Low
- **의존성**: [다른 스토리 참조]
## 디자인 노트
[UI/UX 요구사항, 참고 이미지]
## 기술 노트
[성능 요구사항, 보안 고려사항]
```
## 완료 체크리스트
- [ ] 사용자 스토리가 INVEST 원칙 준수 (Independent, Negotiable, Valuable, Estimable, Small, Testable)
- [ ] 인수 기준이 측정 가능
- [ ] 우선순위가 명확
- [ ] 개발 팀과 합의 완료
## 다른 에이전트와의 협업
- **UI/UX Designer**: 와이어프레임, 프로토타입 요청
- **Frontend/Backend Developer**: 기술적 실현 가능성 논의
- **QA Engineer**: 인수 기준 공유
5. UI/UX Designer Subagent
파일: .claude/agents/uiux-designer.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
---
name: uiux-designer
description: UI/UX 디자인 전문가. 사용자 경험 설계, 디자인 시스템 구축, 접근성 검증
tools: Read, Write, Glob, Grep, WebFetch
model: sonnet
color: pink
---
# UI/UX Designer Agent
당신은 시니어 UI/UX 디자이너입니다. 사용자 중심 디자인, 디자인 시스템, 접근성(a11y)에 전문성을 갖추고 있습니다.
## 핵심 책임
- 와이어프레임 및 프로토타입 설계
- 디자인 시스템 구축 및 유지
- 컬러 팔레트, 타이포그래피 정의
- 반응형 디자인 가이드라인
- 접근성 검증 (WCAG 2.1 AA 이상)
## 디자인 원칙
- **일관성**: 모든 화면에서 동일한 패턴 사용
- **명확성**: 사용자가 다음 행동을 쉽게 예측 가능
- **피드백**: 모든 인터랙션에 시각적 피드백
- **접근성**: 모든 사용자가 접근 가능 (색맹, 스크린리더 사용자 등)
## 작업 프로세스
1. 사용자 리서치 (페르소나, 사용자 여정 지도)
2. 정보 아키텍처 설계
3. 와이어프레임 작성 (저해상도)
4. 프로토타입 제작 (고해상도)
5. 사용자 테스트
6. 디자인 시스템에 컴포넌트 추가
7. 개발자 핸드오프 (Figma, Zeplin 등)
## 디자인 시스템 구조
```markdown
# Design System
## Colors
- Primary: #3B82F6 (Blue-500)
- Secondary: #10B981 (Green-500)
- Error: #EF4444 (Red-500)
- Warning: #F59E0B (Amber-500)
- Neutral: Gray-50 ~ Gray-900
## Typography
- Headings: Inter (Bold)
- H1: 36px / 44px line-height
- H2: 30px / 38px line-height
- H3: 24px / 32px line-height
- Body: Inter (Regular)
- Large: 18px / 28px line-height
- Regular: 16px / 24px line-height
- Small: 14px / 20px line-height
## Spacing
- 4px 단위 사용 (4, 8, 12, 16, 20, 24, 32, 40, 48, 64...)
## Components
- Button
- Input
- Card
- Modal
- Tooltip
```
## 완료 체크리스트
- [ ] 색상 대비 4.5:1 이상 (텍스트), 3:1 이상 (UI 요소)
- [ ] 키보드만으로 모든 기능 접근 가능
- [ ] 포커스 상태 명확하게 표시
- [ ] 터치 타겟 최소 44x44px
- [ ] 에러 메시지가 색상에만 의존하지 않음
- [ ] 반응형 breakpoint 정의 (모바일, 태블릿, 데스크톱)
## 다른 에이전트와의 협업
- **Product Manager**: 사용자 스토리, 우선순위 확인
- **Frontend Developer**: 디자인 토큰, 컴포넌트 스펙 전달
- **Accessibility Auditor**: a11y 검증 요청
6. Database Architect Subagent
파일: .claude/agents/database-architect.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
---
name: database-architect
description: 데이터베이스 설계 전문가. 스키마 최적화, 인덱싱, 마이그레이션 전략 수립
tools: Read, Write, Bash, Glob, Grep
model: opus
color: orange
---
# Database Architect Agent
당신은 시니어 데이터베이스 아키텍트입니다. PostgreSQL, MySQL, MongoDB에 전문성을 가지며, 정규화, 인덱싱, 쿼리 최적화에 능숙합니다.
## 핵심 책임
- 데이터베이스 스키마 설계 (ERD)
- 정규화 및 반정규화 결정
- 인덱스 전략 수립
- 마이그레이션 스크립트 작성
- 쿼리 성능 최적화
## 설계 원칙
- **정규화**: 3NF까지 기본, 성능 이슈 시 의도적 반정규화
- **네이밍**: 명확하고 일관된 테이블/컬럼명
- **제약조건**: FK, UNIQUE, CHECK 적극 활용
- **인덱스**: 자주 조회되는 컬럼에 인덱스, 쓰기 성능 고려
## 작업 프로세스
1. 비즈니스 요구사항 분석
2. 엔티티 및 관계 파악
3. ERD 작성 (개념적 → 논리적 → 물리적)
4. 정규화 적용
5. 인덱스 설계
6. 마이그레이션 스크립트 작성
7. 성능 테스트
## ERD 표준
```
[User] 1 ----< N [Post]
|
| 1
|
< N
[Comment]
```
## 마이그레이션 체크리스트
- [ ] 롤백 스크립트 작성
- [ ] 기존 데이터 마이그레이션 경로 확인
- [ ] 인덱스 생성 (CONCURRENTLY 옵션 사용)
- [ ] 프로덕션 데이터 백업 확인
- [ ] 다운타임 최소화 전략
- [ ] 마이그레이션 후 데이터 검증 쿼리 준비
## 다른 에이전트와의 협업
- **Backend Developer**: 스키마 변경사항 공유, ORM 모델 업데이트 요청
- **Performance Engineer**: 느린 쿼리 최적화 협력
7. Security Auditor Subagent
파일: .claude/agents/security-auditor.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
---
name: security-auditor
description: 보안 전문가. 코드 보안 검토, 취약점 스캔, 보안 가이드라인 준수 검증
tools: Read, Bash, Glob, Grep
model: opus
color: red
---
# Security Auditor Agent
당신은 시니어 보안 전문가입니다. OWASP Top 10, GDPR, SOC2 컴플라이언스에 정통합니다.
## 핵심 책임
- 코드 보안 검토
- OWASP Top 10 취약점 검증
- 인증/권한 로직 검증
- 민감 데이터 처리 검증
- 보안 가이드라인 작성
## 검증 항목
1. **인증 및 세션 관리**
- 비밀번호 해싱 (bcrypt, Argon2)
- 세션 만료 시간 적절성
- CSRF 토큰 사용
2. **입력 검증**
- SQL Injection 방지
- XSS 방지 (입력 이스케이프)
- 파일 업로드 검증
3. **권한 관리**
- 수평적 권한 상승 방지
- 수직적 권한 상승 방지
- API 엔드포인트 권한 검증
4. **데이터 보호**
- 전송 중 암호화 (HTTPS)
- 저장 시 암호화 (AES-256)
- 민감 데이터 로깅 금지
## 완료 체크리스트
- [ ] 모든 API 엔드포인트 인증 확인
- [ ] SQL 쿼리 파라미터화 확인
- [ ] 사용자 입력 검증 확인
- [ ] 비밀번호 평문 저장 없음
- [ ] 환경 변수에서 secrets 로드
- [ ] CORS 설정 적절성
- [ ] Rate limiting 구현
## 보안 이슈 보고 형식
```markdown
## [심각도] 보안 이슈 제목
**발견 위치**: 파일:줄번호
**CWE**: CWE-79 (XSS)
**CVSS 점수**: 7.5 (High)
**취약점 설명**
[상세 설명]
**재현 방법**
1. [단계]
**영향**
[공격자가 이를 악용할 경우 어떤 일이 발생하는가]
**해결 방법**
[코드 예시 포함]
```
## 다른 에이전트와의 협업
- **Backend Developer**: 보안 패치 적용 요청
- **DevOps Engineer**: 인프라 보안 설정 검토
Subagent 생성 방법
위의 파일들을 .claude/agents/ 디렉토리에 저장하면 자동으로 로드됩니다. 또는 /agents 명령을 사용하여 대화형으로 생성할 수도 있습니다.
방법 1: 수동 파일 생성
1
2
mkdir -p .claude/agents
# 위의 파일들을 해당 디렉토리에 저장
방법 2: /agents 명령 사용
1
2
# Claude Code 내에서
/agents create "frontend-developer" "React 및 Next.js 전문가" "Read,Write,Edit,Bash"
방법 3: AI 생성
1
2
3
4
5
# Claude Code 내에서
/agents
# 프롬프트 입력
"프론트엔드 개발자 에이전트를 생성해줘. React, TypeScript, Tailwind CSS 전문가로, 컴포넌트 작성과 API 통합을 담당해."
Subagent 호출 방법
자동 호출: Claude가 작업 내용을 파악하고 적절한 subagent를 자동으로 선택합니다.
1
2
3
사용자: "로그인 페이지를 만들어줘. React와 Tailwind를 사용해서."
Claude: [frontend-developer subagent 자동 호출]
수동 호출: @ 멘션을 사용하여 특정 subagent를 명시적으로 호출합니다.
1
병렬 호출: 여러 subagent를 동시에 실행합니다.
1
Google Antigravity 심화
Google Antigravity는 Claude Code와는 다른 접근 방식을 취합니다. 역할별 고정 에이전트가 아닌, 작업별 동적 에이전트를 생성하는 “작업 중심” 모델입니다.
Antigravity의 핵심 컴포넌트
1. Agent Manager (미션 컨트롤) Agent Manager는 Antigravity의 핵심입니다. 전통적인 IDE의 파일 탐색기 대신, 여러 에이전트의 작업 상태를 한눈에 볼 수 있는 대시보드를 제공합니다.
Agent Manager에서 할 수 있는 작업:
- 새 에이전트 생성 및 작업 할당
- 진행 중인 에이전트 모니터링
- 완료된 작업의 Artifacts 검토
- 에이전트 간 우선순위 조정
- 일시 중지/재개/취소
2. Artifacts (작업 증거물) Antigravity의 가장 혁신적인 기능 중 하나입니다. 에이전트가 “작업을 완료했다”고 주장만 하는 것이 아니라, 실제로 무엇을 했는지 시각적으로 증명합니다.
Artifacts의 종류:
- Task Plan: 에이전트가 작업을 어떻게 분해했는지
- Implementation Plan: 어떤 파일을 수정했는지, 왜 그렇게 했는지
- Screenshots: 에이전트가 브라우저에서 본 화면
- Browser Recordings: 에이전트가 수행한 브라우저 인터랙션 (클릭, 입력, 스크롤) 영상
- Test Results: 테스트 실행 결과
- Code Diffs: 변경된 코드의 diff
이를 통해 개발자는 에이전트가 한 작업을 “신뢰”할 수 있게 됩니다. 마치 Google Docs에 댓글을 다는 것처럼 Artifacts에 피드백을 남길 수 있으며, 에이전트는 이를 반영하여 작업을 수정합니다.
3. Editor, Terminal, Browser 통합 Antigravity 에이전트는 세 가지 표면에 모두 접근할 수 있습니다:
- Editor: 코드 작성 및 수정
- Terminal: 명령 실행 (npm, git, test 등)
- Browser: 실제 애플리케이션 테스트 및 검증
이는 Claude Code보다 더 완전한 자율성을 제공합니다. 에이전트는 코드를 작성한 후 터미널에서 앱을 실행하고, 브라우저에서 직접 테스트하여 작동하는지 확인할 수 있습니다.
Antigravity 사용 가이드
설치 및 초기 설정
- 다운로드
- https://antigravity.google/download 방문
- 운영체제에 맞는 버전 다운로드 (Windows, macOS, Linux)
- 설치 및 로그인
- 설치 프로그램 실행
- 개인 Gmail 계정으로 로그인 (현재 프리뷰는 무료)
- 개발 모드 선택
- Agent-driven development: 에이전트가 대부분의 결정을 자동으로 처리
- Review-driven development (권장): 에이전트가 주요 작업 전에 승인 요청
- Agent-assisted development: 개발자가 주도하되 에이전트가 보조
- 에디터 설정
- Keybinding 선택 (VS Code, Vim, Emacs 등)
- 추천 확장 프로그램 설치
- CLI 도구 설치 (
agy명령)
- 모델 선택
- 주 모델: Gemini 3 Pro (권장) 또는 Claude Sonnet 4.5
- 보조 모델: Gemini 3 Flash (빠른 작업용)
첫 번째 프로젝트: 에이전트 생성
Antigravity를 실행하면 Agent Manager가 나타납니다.
시나리오: Todo 앱 만들기
Playground 선택 Agent Manager 왼쪽 사이드바에서 “Playground” 선택
- 에이전트에게 작업 지시
1 2 3 4 5 6 7 8
Next.js와 Tailwind CSS를 사용해서 간단한 Todo 앱을 만들어줘. 기능: - Todo 추가, 완료 표시, 삭제 - 완료된 항목은 회색으로 표시 - localStorage에 저장 다크 모드도 지원해야 해.
에이전트 작업 관찰 에이전트는 다음 순서로 작동합니다:
Plan 생성 (Artifact)
1 2 3 4 5 6
1. Next.js 프로젝트 생성 2. Tailwind CSS 설정 3. Todo 컴포넌트 구현 4. localStorage 연동 5. 다크 모드 구현 6. 브라우저에서 테스트
Implementation (자동 실행)
- Editor에서 파일 생성 및 수정
- Terminal에서
npx create-next-app,npm install실행 - Browser에서
http://localhost:3000열고 테스트
Artifacts 생성
- 각 단계마다 스크린샷
- 브라우저 인터랙션 비디오
- 최종 결과물 스크린샷
결과 검토 및 피드백 Artifacts 패널에서 에이전트가 만든 결과물을 확인합니다.
Google Docs 스타일 댓글로 피드백:
1
"Todo 항목을 드래그해서 순서를 바꿀 수 있게 해줘."
에이전트는 즉시 이 피드백을 반영하여 코드를 수정합니다.
병렬 에이전트 실행
Antigravity의 강력한 기능 중 하나는 여러 에이전트를 동시에 실행하는 것입니다.
시나리오: 프론트엔드와 백엔드 동시 개발
- 에이전트 1: 백엔드 API ``` Express.js로 REST API를 만들어줘. 엔드포인트:
- GET /api/todos
- POST /api/todos
- PUT /api/todos/:id
- DELETE /api/todos/:id
PostgreSQL을 사용하고, Prisma로 연결해줘. ```
- 에이전트 2: 프론트엔드 UI
1 2 3
React로 Todo 앱 UI를 만들어줘. 백엔드 API (http://localhost:3001/api)를 사용해. React Query로 데이터 페칭하고, 낙관적 업데이트도 구현해줘.
두 에이전트가 동시에 작업하며, Agent Manager에서 각각의 진행 상황을 실시간으로 볼 수 있습니다.
Antigravity의 한계와 현재 미지원 기능
역할별 고정 에이전트 부재 현재 Antigravity는 “프론트엔드 개발자”, “백엔드 개발자” 같은 역할별 에이전트를 명시적으로 정의할 수 없습니다. 각 작업마다 새로운 에이전트가 생성됩니다.
해결 방법: 작업 지시에 역할을 명시
1
2
"프론트엔드 개발자로서, React 컴포넌트를 만들어줘.
백엔드 API는 이미 준비되어 있고, 엔드포인트는..."
이렇게 하면 에이전트가 프론트엔드 역할에 집중하게 됩니다.
Claude Code와의 직접 통합 없음 두 플랫폼은 독립적으로 작동하며, 직접적인 통합 기능은 없습니다. Git을 통한 간접 협업만 가능합니다.
멀티 에이전트 협업 아키텍처
여러 에이전트가 효과적으로 협업하려면 명확한 아키텍처와 커뮤니케이션 프로토콜이 필요합니다. 이 섹션에서는 실전에서 사용할 수 있는 협업 패턴을 소개합니다.
협업 패턴 1: 순차적 핸드오프 (Sequential Handoff)
가장 간단한 패턴입니다. 각 에이전트가 순서대로 작업을 수행하고, 다음 에이전트에게 결과물을 전달합니다.
흐름:
1
Product Manager → UI/UX Designer → Frontend Developer → Backend Developer → QA Engineer
실전 예시:
- Product Manager: 사용자 스토리 작성
1 2 3 4 5 6 7 8
## 사용자 스토리 As a user, I want to see my task list sorted by priority, So that I can focus on the most important tasks first. ## 인수 기준 - [ ] Tasks are displayed in priority order (High, Medium, Low) - [ ] User can change priority by clicking a dropdown - [ ] Order updates immediately without page refresh
- UI/UX Designer: 와이어프레임 생성
1 2 3 4 5 6 7 8 9 10 11
## 컴포넌트: TaskList ### 레이아웃 [TaskItem] [TaskItem] <- 각 항목에 Priority 드롭다운 [TaskItem] ### 컬러 - High: Red-100 background, Red-600 text - Medium: Yellow-100 background, Yellow-600 text - Low: Gray-100 background, Gray-600 text
- Frontend Developer: 컴포넌트 구현
1 2 3
// TaskList.tsx 생성 // API: GET /api/tasks?sort=priority // 상태 관리: Zustand
- Backend Developer: API 구현
1 2
// GET /api/tasks?sort=priority // 쿼리: SELECT * FROM tasks ORDER BY priority DESC
- QA Engineer: 테스트 작성 및 실행
1 2 3
test('tasks are sorted by priority', async () => { // ... });
Claude Code에서 구현:
1
2
3
4
5
6
7
# 1단계
# 2단계 (Product Manager 완료 후)
# 3단계 (Designer 완료 후)
# 이하 계속...
협업 패턴 2: 병렬 작업 (Parallel Execution)
독립적인 작업들을 동시에 수행하여 시간을 절약하는 패턴입니다.
흐름:
1
2
3
4
5
6
7
8
┌─ Frontend Developer (UI 컴포넌트)
Product Manager ──┼─ Backend Developer (API 엔드포인트)
└─ Database Architect (스키마 설계)
↓
┌─ QA Engineer (테스트)
통합 ────┼─ Security Auditor (보안 검토)
실전 예시: 사용자 인증 시스템
동시에 실행:
- Frontend: 로그인/회원가입 UI
- Backend: JWT 인증 로직
- Database: users 테이블 설계
- Security: 비밀번호 정책 검토
Claude Code에서 구현:
터미널 1:
1
터미널 2 (새 세션):
1
터미널 3 (새 세션):
1
모든 작업이 완료된 후 통합:
1
협업 패턴 3: 반복적 개선 (Iterative Refinement)
에이전트들이 여러 차례에 걸쳐 서로의 작업을 검토하고 개선하는 패턴입니다.
흐름:
1
Developer → Code Reviewer → Developer (수정) → Code Reviewer (재검토) → 완료
실전 예시:
- Frontend Developer: 초기 구현
1
// UserProfile.tsx - 첫 번째 버전 - Code Reviewer: 리뷰 ```markdown
리뷰 의견
- PropTypes 누락
- 에러 처리 없음
- 접근성 문제 (aria-label 없음) ```
- Frontend Developer: 수정
1
// UserProfile.tsx - 수정 버전 - Code Reviewer: 재검토
1
✅ 모든 문제 해결됨. 승인.
Claude Code에서 구현:
1
2
3
4
5
6
7
# 1차 구현
# 리뷰
# 수정
# 재검토
협업 패턴 4: Hub-and-Spoke (중앙 조정자)
하나의 “오케스트레이터” 에이전트가 여러 전문 에이전트를 조율하는 패턴입니다.
구조:
1
2
3
4
5
┌─ Frontend Developer
├─ Backend Developer
Orchestrator ───────┼─ Database Architect
├─ QA Engineer
└─ Security Auditor
실전 예시: 오케스트레이터 에이전트 정의
파일: .claude/agents/orchestrator.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
---
name: orchestrator
description: 프로젝트 전체를 조율하는 마스터 에이전트. 작업을 분해하고 적절한 전문가 에이전트에게 할당
tools: Read, Write, Bash, Glob, Grep
model: opus
color: gold
---
# Orchestrator Agent
당신은 프로젝트 오케스트레이터입니다. 복잡한 작업을 분해하고, 각 부분을 적절한 전문가 에이전트에게 할당하는 역할을 합니다.
## 작업 분해 원칙
1. 독립적으로 실행 가능한 최소 단위로 분해
2. 의존성 파악 (어떤 작업이 먼저 완료되어야 하는가)
3. 병렬 실행 가능한 작업 식별
4. 각 작업에 가장 적합한 에이전트 선택
## 의사결정 트리
- UI/UX 관련? → @uiux-designer
- React/Vue 컴포넌트? → @frontend-developer
- API/서버 로직? → @backend-developer
- 데이터베이스 스키마? → @database-architect
- 테스트 작성? → @qa-engineer
- 보안 검토? → @security-auditor
## 출력 형식
```markdown
## 작업 분해 계획
### Phase 1: 기초 작업 (병렬 가능)
- Task 1.1: @database-architect - users 테이블 스키마 설계
- Task 1.2: @uiux-designer - 로그인 페이지 와이어프레임
### Phase 2: 구현 (Phase 1 의존)
- Task 2.1: @backend-developer - 인증 API 구현
- Task 2.2: @frontend-developer - 로그인 UI 구현
### Phase 3: 검증
- Task 3.1: @qa-engineer - E2E 테스트
- Task 3.2: @security-auditor - 보안 검토
```
사용 예시:
1
2
3
로그인, 회원가입, 비밀번호 재설정까지 모두 포함해서."
[Orchestrator가 작업을 분해하고 각 에이전트에게 할당]
에이전트 간 커뮤니케이션 프로토콜
에이전트들이 서로 효과적으로 정보를 주고받으려면 표준화된 커뮤니케이션 프로토콜이 필요합니다.
방법 1: 공유 문서 .claude/shared/ 디렉토리에 에이전트 간 공유 문서를 만듭니다.
1
2
3
4
5
6
7
8
9
10
.claude/
├── agents/
│ ├── frontend-developer.md
│ ├── backend-developer.md
│ └── ...
├── shared/
│ ├── API_SPEC.md # Backend → Frontend 스펙 공유
│ ├── DESIGN_SYSTEM.md # Designer → Frontend 디자인 토큰
│ ├── DATABASE_SCHEMA.md # DB Architect → Backend 스키마 정보
│ └── TEST_CASES.md # QA → All 테스트 요구사항
API_SPEC.md 예시:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# API Specification
## Authentication Endpoints
### POST /api/auth/login
**Request:**
```json
{
"email": "string",
"password": "string"
}
```
**Response (200):**
```json
{
"data": {
"user": { "id": "string", "email": "string" },
"token": "string"
}
}
```
**Response (401):**
```json
{
"error": {
"code": "INVALID_CREDENTIALS",
"message": "이메일 또는 비밀번호가 올바르지 않습니다."
}
}
```
---
**Updated by**: @backend-developer
**Date**: 2026-01-11
에이전트는 작업 시작 전 이 문서를 참조하여 최신 스펙을 확인합니다.
방법 2: Git 커밋 메시지 각 에이전트는 작업 완료 시 명확한 커밋 메시지로 변경사항을 전달합니다.
1
2
3
4
5
6
7
8
feat(auth): implement JWT authentication [by @backend-developer]
- Added POST /api/auth/login endpoint
- Implemented password hashing with bcrypt
- JWT token expires in 7 days
- See .claude/shared/API_SPEC.md for details
Related agents: @frontend-developer (please update login form)
방법 3: 작업 완료 리포트 각 에이전트는 작업 완료 후 간단한 리포트를 남깁니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
## Task Completion Report
**Agent**: @frontend-developer
**Task**: Implement login page
**Status**: ✅ Completed
**Date**: 2026-01-11
### What was done
- Created LoginPage.tsx with email/password fields
- Integrated with POST /api/auth/login
- Added form validation (Zod schema)
- Implemented error handling
### Files changed
- `pages/login.tsx` (new)
- `components/LoginForm.tsx` (new)
- `lib/api/auth.ts` (new)
### Next steps
- @qa-engineer: Please test login flow
- @security-auditor: Please review CSRF protection
### Notes
- Using httpOnly cookies for token storage (as per security guidelines)
- Redirect to /dashboard on successful login
GSD와 함께 사용하기
GSD(Get Shit Done)는 멀티 에이전트 협업을 체계적으로 관리할 수 있는 강력한 프레임워크입니다. GSD의 계층적 구조(Milestone → Phase → Plan → Task)와 subagent 시스템을 결합하면 대규모 프로젝트도 효율적으로 진행할 수 있습니다.
GSD + Subagent 통합 아키텍처
GSD는 “무엇을 해야 하는가”를 관리하고, subagent는 “누가 어떻게 할 것인가”를 담당합니다.
통합 구조:
1
2
3
4
5
6
7
8
GSD Layer Subagent Layer
─────────────────────────────────────────────
Milestone: v1.0 → [Orchestrator]
└─ Phase 1: Auth → [Planning Agent]
└─ Plan 1-1 → [Execution Agents]
├─ Task 1: DB → @database-architect
├─ Task 2: API → @backend-developer
└─ Task 3: UI → @frontend-developer
단계별 통합 가이드
1단계: GSD 프로젝트 초기화 + Subagent 준비
1
2
3
4
5
6
7
8
9
10
11
12
# GSD 설치
npx get-shit-done-cc --global
# 프로젝트 디렉토리 생성
mkdir my-app && cd my-app
git init
# Claude Code 실행
claude --dangerously-skip-permissions
# GSD 프로젝트 초기화
/gsd:new-project
GSD가 질문하면 답변:
1
2
3
4
5
6
7
8
9
10
11
12
프로젝트: "Todo 앱 with 팀 협업"
기능:
1. 사용자 인증 (Google OAuth)
2. Todo CRUD
3. 실시간 동기화 (WebSocket)
4. 공유 및 권한 관리
기술 스택:
- Frontend: Next.js 15, React, TypeScript, Tailwind
- Backend: Node.js, Express, PostgreSQL
- Real-time: Socket.io
PROJECT.md가 생성되면, 이제 subagent들을 준비합니다:
1
2
3
# 7개 전문 에이전트 설정 (위에서 정의한 파일들 사용)
mkdir -p .claude/agents
# frontend-developer.md, backend-developer.md 등 복사
2단계: GSD 로드맵 생성
1
/gsd:create-roadmap
GSD가 생성한 로드맵:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Roadmap: Todo 앱 v1.0
## Phase 1: 인증 시스템
- Google OAuth 통합
- 세션 관리
- 보호된 라우트
## Phase 2: Todo CRUD
- 데이터베이스 스키마
- API 엔드포인트
- UI 컴포넌트
## Phase 3: 실시간 동기화
- WebSocket 서버
- 클라이언트 통합
- 충돌 해결
## Phase 4: 공유 및 권한
- 초대 시스템
- 권한 관리 (Owner, Editor, Viewer)
- 알림
## Phase 5: 테스트 및 배포
- E2E 테스트
- 보안 검토
- Vercel 배포
3단계: Phase 계획 시 Subagent 할당
각 Phase를 계획할 때, 어떤 subagent가 어떤 작업을 할지 명시합니다.
1
/gsd:plan-phase 1
GSD가 Phase 1의 계획을 생성할 때, 프롬프트에 다음을 추가:
1
2
3
4
5
6
7
8
9
10
11
"Phase 1을 계획할 때, 각 작업에 적절한 subagent를 할당해줘.
사용 가능한 subagent:
- @product-manager
- @uiux-designer
- @frontend-developer
- @backend-developer
- @database-architect
- @qa-engineer
- @security-auditor
각 작업에 '@에이전트명'을 명시해서 PLAN.md에 포함시켜줘."
생성된 PLAN.md:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
<plan phase="1" title="인증 시스템">
<task type="auto" agent="database-architect">
<n>users 테이블 스키마 설계</n>
<files>prisma/schema.prisma, prisma/migrations/</files>
<action>
users 테이블 생성.
필드: id, email, name, avatar, google_id, created_at, updated_at
인덱스: email (UNIQUE), google_id (UNIQUE)
@database-architect가 담당.
</action>
<verify>prisma migrate dev 실행 시 성공</verify>
<done>users 테이블 생성 완료, 마이그레이션 파일 커밋됨</done>
</task>
<task type="auto" agent="backend-developer">
<n>Google OAuth 인증 API 구현</n>
<files>
src/routes/auth.ts
src/middleware/auth.ts
src/lib/google-oauth.ts
</files>
<action>
passport-google-oauth20 사용.
GET /api/auth/google - OAuth 시작
GET /api/auth/google/callback - 콜백 처리
JWT 토큰 생성 및 반환 (httpOnly cookie)
@backend-developer가 담당.
</action>
<verify>Postman으로 OAuth 플로우 테스트 성공</verify>
<done>Google 로그인 완전히 작동</done>
</task>
<task type="auto" agent="frontend-developer">
<n>로그인 페이지 UI 구현</n>
<files>
app/login/page.tsx
components/GoogleLoginButton.tsx
</files>
<action>
"Google로 로그인" 버튼 구현.
로그인 성공 시 /dashboard로 리디렉션.
로딩 상태 및 에러 처리.
@frontend-developer가 담당.
</action>
<verify>브라우저에서 Google 로그인 버튼 클릭 시 OAuth 플로우 시작</verify>
<done>로그인 페이지 완성, Google OAuth 연동 확인</done>
</task>
</plan>
4단계: Plan 실행 시 Subagent 명시적 호출
1
/gsd:execute-plan
GSD가 첫 번째 작업을 시작할 때:
1
2
3
4
5
PLAN.md의 Task 1 (users 테이블 스키마 설계)을 수행해줘.
작업 완료 후 다음 사항을 리포트:
- 생성한 파일 목록
- 마이그레이션 실행 결과
- 다음 에이전트를 위한 주의사항
Database Architect가 완료하면, 다음 작업:
1
2
PLAN.md의 Task 2 (Google OAuth API)를 수행해줘.
.claude/shared/API_SPEC.md에 API 스펙을 문서화해줘.
Backend Developer가 완료하면:
1
2
PLAN.md의 Task 3 (로그인 페이지)를 수행해줘.
API 스펙은 .claude/shared/API_SPEC.md를 확인해.
5단계: 검증 및 다음 Phase
모든 작업이 완료되면 검증:
1
2
Phase 1의 모든 작업이 완료되었어.
E2E 테스트를 작성하고 실행해서 Google 로그인이 완전히 작동하는지 확인해줘.
QA가 통과를 확인하면:
1
/gsd:plan-phase 2
이 과정을 반복합니다.
GSD 명령어와 Subagent 매핑
GSD의 각 명령어에서 어떤 subagent를 사용하는 것이 적절한지 정리한 표:
| GSD 명령어 | 호출할 Subagent | 이유 |
|---|---|---|
/gsd:new-project | @product-manager | 프로젝트 비전과 요구사항 정의 |
/gsd:create-roadmap | @product-manager | 단계별 계획 수립 |
/gsd:discuss-phase N | @product-manager, @uiux-designer | Phase 상세 논의 |
/gsd:plan-phase N | @orchestrator | 작업 분해 및 에이전트 할당 |
/gsd:execute-plan | 각 Task의 할당된 Agent | 실제 구현 |
/gsd:consider-issues | @product-manager, @orchestrator | 이슈 우선순위 결정 |
/gsd:complete-milestone | @qa-engineer, @security-auditor | 최종 검증 |
실전 팁: GSD + Subagent 워크플로우
매일 아침:
1
2
3
4
/gsd:progress
오늘 집중해야 할 작업 3가지를 추천해줘.
의존성과 우선순위를 고려해서.
작업 시작 전:
1
2
3
4
/gsd:discuss-phase 3
Phase 3 (실시간 동기화)를 시작하기 전에
기술적 결정사항과 UX 플로우를 논의해줘.
작업 중:
1
2
3
4
/gsd:execute-plan
Phase 3의 Task 1과 2를 병렬로 수행해줘.
Frontend는 WebSocket 클라이언트, Backend는 Socket.io 서버.
작업 완료 후:
1
2
Phase 3 작업이 완료됐어.
실시간 동기화가 제대로 작동하는지 테스트해줘.
주말 정리:
1
2
3
4
/gsd:progress
이번 주 진행 상황을 요약하고,
다음 주 계획을 세워줘.
GSD 없이 멀티 에이전트 협업하기
GSD는 강력하지만, 모든 프로젝트에 필수는 아닙니다. 간단한 프로젝트나 빠른 프로토타이핑에서는 GSD 없이도 subagent들을 효과적으로 활용할 수 있습니다.
수동 오케스트레이션 패턴
GSD의 자동화 대신, 개발자가 직접 에이전트를 조율하는 방식입니다.
방법 1: 체크리스트 기반 관리
파일: PROJECT_PLAN.md (수동 작성)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 프로젝트: Blog Platform
## 완료 체크리스트
### Phase 1: 기본 설정 ✅
- [x] Next.js 프로젝트 초기화 - @frontend-developer
- [x] Supabase 설정 - @database-architect
- [x] 디자인 시스템 정의 - @uiux-designer
### Phase 2: 글 작성 기능 🚧
- [x] posts 테이블 스키마 - @database-architect
- [x] 글 작성 API - @backend-developer
- [ ] 마크다운 에디터 UI - @frontend-developer (진행 중)
- [ ] 이미지 업로드 - @backend-developer
- [ ] E2E 테스트 - @qa-engineer
### Phase 3: 댓글 시스템 ⏸️
- [ ] comments 테이블 스키마 - @database-architect
- [ ] 댓글 API - @backend-developer
- [ ] 댓글 UI 컴포넌트 - @frontend-developer
## 다음 작업
1. @frontend-developer: 마크다운 에디터 완성
2. @backend-developer: 이미지 업로드 S3 통합
3. @qa-engineer: 글 작성 플로우 테스트
개발자가 직접 이 체크리스트를 업데이트하고, 각 에이전트에게 명시적으로 작업을 할당합니다:
1
2
PROJECT_PLAN.md를 보고, Phase 2의 "마크다운 에디터 UI"를 구현해줘.
완료되면 체크리스트를 업데이트해줘.
방법 2: Kanban 보드 스타일
파일: KANBAN.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 작업 보드
## To Do
- [ ] 이미지 최적화 기능 (@frontend-developer)
- [ ] 검색 API 구현 (@backend-developer)
- [ ] 다크 모드 추가 (@frontend-developer)
## In Progress
- [ ] 마크다운 에디터 UI (@frontend-developer) - 70% 완료
- [ ] S3 이미지 업로드 (@backend-developer) - 진행 중
## Review
- [ ] 댓글 컴포넌트 (@code-reviewer가 리뷰 중)
## Done
- [x] posts 테이블 생성
- [x] 글 작성 API
- [x] 기본 레이아웃
작업 이동:
1
마크다운 에디터를 완성했으면 KANBAN.md에서 "Done"으로 옮기고,
방법 3: 일일 스탠드업 미팅 시뮬레이션
매일 동일한 시간에 모든 에이전트에게 상태 보고를 요청합니다.
파일: STANDUP_2026-01-11.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Daily Standup - 2026년 1월 11일
## @frontend-developer
**어제 한 일:**
- 마크다운 에디터 UI 80% 완료
- 이미지 드래그앤드롭 추가
**오늘 할 일:**
- 에디터 완성 및 테스트
- 미리보기 기능 추가
**블로커:**
- 없음
## @backend-developer
**어제 한 일:**
- S3 이미지 업로드 API 구현
- 이미지 리사이징 추가 (Sharp 라이브러리)
**오늘 할 일:**
- 이미지 업로드 테스트
- 검색 API 시작
**블로커:**
- S3 버킷 권한 설정 필요 (DevOps 팀 요청함)
## @qa-engineer
**어제 한 일:**
- 글 작성 플로우 E2E 테스트 작성
**오늘 할 일:**
- 이미지 업로드 테스트 시나리오 작성
- 기존 테스트 실행 및 버그 리포트
**블로커:**
- 없음
이를 생성하려면:
1
2
Google Antigravity 단독 사용 패턴
Antigravity는 작업 중심이므로, GSD 없이도 자연스럽게 사용할 수 있습니다.
패턴 1: 작업 단위 에이전트 생성
Agent Manager에서 새 에이전트 생성
에이전트 1: “프론트엔드 개발”
1
2
3
4
5
6
7
8
9
10
11
Next.js로 블로그 글 목록 페이지를 만들어줘.
요구사항:
- Supabase에서 글 목록 가져오기
- 페이지네이션 (페이지당 10개)
- 각 글은 제목, 요약, 날짜, 작성자 표시
- Tailwind로 반응형 디자인
완료 기준:
- 브라우저에서 localhost:3000/posts 접속 시 글 목록 표시
- 모바일에서도 잘 보임
Antigravity 에이전트는:
- 코드 작성 (Editor)
- 개발 서버 실행 (Terminal:
npm run dev) - 브라우저에서 테스트 (Browser: http://localhost:3000/posts)
- Artifacts로 스크린샷 및 비디오 제공
에이전트 2: “백엔드 API 개발”
1
2
3
4
5
6
7
8
9
10
11
12
13
Express.js로 블로그 검색 API를 만들어줘.
엔드포인트: GET /api/search?q=검색어
요구사항:
- PostgreSQL 전체 텍스트 검색 사용
- 제목과 본문에서 검색
- 결과는 관련도 순으로 정렬
- 페이지네이션 지원 (limit, offset)
완료 기준:
- curl로 테스트 시 검색 결과 반환
- 성능: 10만 개 글 중 검색 시 1초 이내
패턴 2: 병렬 에이전트로 시간 절약
Agent Manager에서 동시에 여러 에이전트를 실행합니다.
동시에 3개 에이전트:
- UI 컴포넌트 개발
1 2
React로 댓글 컴포넌트를 만들어줘. (상세 요구사항...)
- API 개발
1 2
댓글 CRUD API를 만들어줘. (상세 요구사항...)
- 데이터베이스 마이그레이션
1 2
comments 테이블을 생성하는 마이그레이션을 작성해줘. (상세 요구사항...)
각 에이전트가 독립적으로 작업하며, Agent Manager에서 진행 상황을 실시간으로 확인합니다.
패턴 3: Artifacts로 품질 보증
Antigravity의 Artifacts를 적극 활용하여 품질을 검증합니다.
에이전트 작업 완료 후:
- Task Plan Artifact 확인
- 에이전트가 작업을 어떻게 분해했는지 확인
- 누락된 단계가 있는지 체크
- Screenshots Artifact 확인
- UI가 요구사항대로 구현되었는지 시각적 확인
- 반응형 디자인 확인 (모바일, 태블릿 스크린샷)
- Browser Recording Artifact 확인
- 에이전트가 어떻게 테스트했는지 비디오로 확인
- 사용자 인터랙션이 제대로 작동하는지 검증
- Code Diff Artifact 확인
- 어떤 파일이 변경되었는지 확인
- 변경 사항이 합리적인지 검토
- Google Docs 스타일 댓글로 피드백
1 2
"댓글 컴포넌트의 타임스탬프가 상대 시간으로 표시되어야 해. 예: '5분 전', '2시간 전'"
에이전트는 즉시 피드백을 반영하여 코드를 수정합니다.
하이브리드 접근: Claude Code + Antigravity 조합
두 플랫폼의 장점을 결합하여 사용하는 방법입니다.
역할 분담:
- Claude Code: 코드 작성, 리뷰, 리팩토링
- Antigravity: UI 테스트, 브라우저 인터랙션 검증
워크플로우:
- Claude Code로 코드 작성
1 2
@frontend-developer 로그인 페이지를 만들어줘.
- Git 커밋
1 2 3
git add . git commit -m "feat: implement login page" git push
- Antigravity로 UI 테스트 Antigravity Agent Manager에서:
1 2 3 4 5 6 7 8 9
Git 저장소를 클론하고, 로그인 페이지를 브라우저에서 테스트해줘. 테스트 시나리오: - 유효한 이메일/비밀번호로 로그인 → 대시보드로 리디렉션 - 잘못된 비밀번호 → 에러 메시지 표시 - 이메일 형식 오류 → 검증 에러 - 모바일에서도 테스트 모든 시나리오를 브라우저 녹화로 증거를 남겨줘.
결과 확인 및 수정 Antigravity의 Browser Recording에서 문제 발견: “모바일에서 로그인 버튼이 잘림”
- Claude Code로 수정
1 2 3
@frontend-developer Antigravity 테스트에서 모바일 버튼이 잘린다는 피드백이 있어. 수정해줘.
- 재검증 다시 Antigravity에서 테스트하여 문제가 해결되었는지 확인
실전 프로젝트 예시
이론을 실제 프로젝트에 적용하는 완전한 예시를 제공합니다.
프로젝트: 실시간 협업 Todo 앱
요구사항:
- 사용자 인증 (Google OAuth)
- Todo CRUD
- 실시간 동기화 (WebSocket)
- 공유 및 권한 관리
- 모바일 반응형
- 다크 모드
기술 스택:
- Frontend: Next.js 15, React, TypeScript, Tailwind CSS, Zustand, Socket.io-client
- Backend: Node.js, Express, Socket.io, Prisma, PostgreSQL
- Auth: Passport, JWT
- 배포: Vercel (Frontend), Railway (Backend)
Week 1: 기초 설정 및 인증
Day 1: 프로젝트 초기화
Claude Code (GSD 사용)
1
2
3
4
5
6
# GSD 프로젝트 초기화
/gsd:new-project
"실시간 협업 Todo 앱을 만들 거야. (요구사항 상세 설명...)"
/gsd:create-roadmap
생성된 로드맵:
1
2
3
4
5
6
7
8
# Roadmap: 협업 Todo v1.0
## Phase 1: 프로젝트 설정 (Day 1-2)
## Phase 2: 인증 시스템 (Day 3-4)
## Phase 3: Todo CRUD (Day 5-7)
## Phase 4: 실시간 동기화 (Week 2)
## Phase 5: 공유 및 권한 (Week 2)
## Phase 6: 테스트 및 배포 (Week 3)
Subagent 설정:
1
2
# 7개 에이전트 파일 생성
# (위에서 정의한 에이전트들)
Phase 1 실행:
1
2
/gsd:plan-phase 1
Day 2-3: 데이터베이스 설계
1
2
3
4
5
6
7
8
/gsd:discuss-phase 2
인증과 Todo를 위한 데이터베이스 스키마를 설계해줘.
요구사항:
- users 테이블 (Google OAuth)
- todos 테이블
- todo_shares 테이블 (공유 및 권한)
Database Architect 출력:
// schema.prisma
model User {
id String @id @default(uuid())
email String @unique
name String
avatar String?
googleId String @unique @map("google_id")
createdAt DateTime @default(now()) @map("created_at")
updatedAt DateTime @updatedAt @map("updated_at")
todos Todo[]
sharedTodos TodoShare[]
@@map("users")
}
model Todo {
id String @id @default(uuid())
title String
description String?
priority Priority @default(MEDIUM)
status Status @default(TODO)
dueDate DateTime? @map("due_date")
createdAt DateTime @default(now()) @map("created_at")
updatedAt DateTime @updatedAt @map("updated_at")
userId String @map("user_id")
user User @relation(fields: [userId], references: [id], onDelete: Cascade)
shares TodoShare[]
@@index([userId, status])
@@map("todos")
}
model TodoShare {
id String @id @default(uuid())
role ShareRole @default(VIEWER)
createdAt DateTime @default(now()) @map("created_at")
todoId String @map("todo_id")
todo Todo @relation(fields: [todoId], references: [id], onDelete: Cascade)
userId String @map("user_id")
user User @relation(fields: [userId], references: [id], onDelete: Cascade)
@@unique([todoId, userId])
@@map("todo_shares")
}
enum Priority {
LOW
MEDIUM
HIGH
}
enum Status {
TODO
IN_PROGRESS
DONE
}
enum ShareRole {
VIEWER
EDITOR
OWNER
}
1
Day 3-4: 인증 시스템
1
2
3
4
5
6
7
8
9
/gsd:plan-phase 2
/gsd:execute-plan
Google OAuth 인증을 구현해줘.
Passport.js를 사용하고, JWT 토큰은 httpOnly 쿠키에 저장해.
.claude/shared/API_SPEC.md에 API 문서를 작성해줘.
로그인 페이지를 만들어줘.
"Google로 로그인" 버튼을 추가하고, 성공 시 /dashboard로 리디렉션해.
병렬 작업 (두 개의 터미널):
터미널 1 (Backend):
1
터미널 2 (Frontend):
1
Antigravity로 검증: Antigravity Agent Manager에서:
1
2
3
4
5
6
7
8
9
10
Git 저장소를 클론하고, 로그인 플로우를 브라우저에서 테스트해줘.
1. npm run dev로 프론트엔드 실행
2. 백엔드도 실행 (npm start)
3. /login 페이지 접속
4. "Google로 로그인" 클릭
5. OAuth 플로우 진행
6. /dashboard로 리디렉션 확인
모든 과정을 브라우저 녹화로 기록해줘.
Week 2: 핵심 기능 구현
Day 5-7: Todo CRUD
1
2
3
/gsd:plan-phase 3
# 병렬 작업
UI/UX Designer 출력:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Todo Item Design
## 컴포넌트 구조
```
┌─────────────────────────────────────┐
│ [✓] 회의 자료 준비 [🔴 High] │
│ Due: 2026-01-15 │
│ [편집] [공유] [삭제] │
└─────────────────────────────────────┘
```
## 우선순위 색상
- High: bg-red-100, text-red-600, border-red-300
- Medium: bg-yellow-100, text-yellow-600, border-yellow-300
- Low: bg-gray-100, text-gray-600, border-gray-300
## 상태별 스타일
- TODO: 기본
- IN_PROGRESS: 왼쪽 파란색 border (4px)
- DONE: 회색 배경, 취소선
Frontend Developer 작업:
1
2
// components/TodoItem.tsx
// 디자인 시스템에 맞춰 구현
QA 검증:
1
2
3
4
5
6
7
8
9
10
11
12
Todo CRUD 기능을 테스트해줘.
테스트 케이스:
1. 새 Todo 추가
2. 제목 수정
3. 우선순위 변경
4. 완료 표시
5. 삭제
6. 필터링 (전체/진행중/완료)
7. 정렬 (우선순위/날짜)
E2E 테스트 코드를 작성하고 실행해줘.
Day 8-10: 실시간 동기화
1
2
3
4
5
6
7
8
9
10
11
/gsd:plan-phase 4
Socket.io 서버를 설정하고, todo 변경 이벤트를 브로드캐스트해줘.
이벤트:
- todo:created
- todo:updated
- todo:deleted
Socket.io 클라이언트를 통합하고, 실시간 업데이트를 반영해줘.
Zustand 스토어를 WebSocket 이벤트와 동기화해.
테스트:
1
2
# 두 개의 브라우저 창 열기
# 창 1에서 Todo 추가 → 창 2에서 즉시 표시 확인
Week 3: 마무리
Day 11-12: 공유 및 권한
1
2
3
4
5
6
7
8
9
10
11
/gsd:plan-phase 5
Todo 공유 API를 만들어줘.
POST /api/todos/:id/share
- 이메일로 사용자 초대
- 권한 설정 (VIEWER, EDITOR, OWNER)
공유 모달을 만들어줘.
- 이메일 입력
- 권한 선택 드롭다운
- 현재 공유 목록 표시
Day 13-14: 테스트 및 보안
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
전체 애플리케이션 E2E 테스트를 작성하고 실행해줘.
주요 사용자 플로우:
1. 회원가입/로그인
2. Todo 생성
3. Todo 공유
4. 실시간 동기화 확인
5. 권한 검증
보안 검토를 수행해줘.
체크리스트:
- OWASP Top 10
- CSRF 방지
- XSS 방지
- SQL Injection 방지
- 권한 검증 (수평/수직 권한 상승)
- Rate limiting
Security Auditor 발견 이슈:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
## [High] Insufficient Authorization Check
**위치**: src/routes/todos.ts:45
**문제**: Todo 삭제 시 소유자 확인 없음
**현재 코드:**
```javascript
app.delete('/api/todos/:id', async (req, res) => {
await prisma.todo.delete({ where: { id: req.params.id } });
res.json({ success: true });
});
```
**수정 코드:**
```javascript
app.delete('/api/todos/:id', async (req, res) => {
const todo = await prisma.todo.findUnique({
where: { id: req.params.id },
include: { shares: true }
});
if (!todo || (todo.userId !== req.user.id &&
!todo.shares.find(s => s.userId === req.user.id && s.role === 'OWNER'))) {
return res.status(403).json({ error: 'Unauthorized' });
}
await prisma.todo.delete({ where: { id: req.params.id } });
res.json({ success: true });
});
```
1
Security Auditor가 발견한 권한 이슈를 수정해줘.
Day 15: 배포
1
2
3
4
5
6
7
/gsd:complete-milestone
Vercel 배포 설정을 해줘.
환경 변수 설정 방법을 README에 문서화해.
Railway 배포 설정을 해줘.
PostgreSQL 연결 및 환경 변수 설정.
최종 검증 (Antigravity):
1
2
3
4
5
6
7
8
9
10
11
12
프로덕션 환경 (https://my-todo-app.vercel.app)에서
전체 사용자 플로우를 테스트해줘.
1. 회원가입
2. Todo 10개 생성
3. 친구와 공유 (두 번째 브라우저 창)
4. 실시간 동기화 확인
5. 모바일 디바이스 에뮬레이션
6. 다크 모드 전환
모든 과정을 비디오로 녹화하고,
발견된 버그를 리포트해줘.
프로젝트 완료
최종 통계:
- 총 작업 기간: 15일
- 생성된 파일: 87개
- Git 커밋: 124개 (에이전트 자동 커밋)
- 테스트 커버리지: 87%
- 보안 이슈: 3개 발견 및 수정
- 배포: 성공
팀 기여도:
1
문제 해결 및 베스트 프랙티스
멀티 에이전트 협업에서 자주 발생하는 문제와 해결 방법을 정리합니다.
자주 발생하는 문제
문제 1: 에이전트 간 충돌
증상: 두 에이전트가 동일한 파일을 동시에 수정하여 Git 충돌 발생
해결 방법:
- 명확한 파일 소유권 정의
1 2 3 4 5 6 7 8 9 10
# FILE_OWNERSHIP.md ## Frontend - app/*, components/*, lib/client/* → @frontend-developer ## Backend - src/routes/*, src/middleware/* → @backend-developer ## Shared - types/* → Both (조정 필요)
- 순차적 작업 강제
1 2 3 4 5
@frontend-developer 먼저 types/todo.ts를 정의해줘. [완료 대기] @backend-developer 이제 types/todo.ts를 사용해서 API를 만들어줘.
- 브랜치 전략
1 2 3 4 5 6 7
# 각 에이전트마다 별도 브랜치 git checkout -b frontend/todo-ui git checkout -b backend/todo-api # 나중에 통합 git merge frontend/todo-ui git merge backend/todo-api
문제 2: 컨텍스트 손실
증상: 에이전트가 이전 에이전트의 결정사항을 모르고 다시 물어봄
해결 방법:
- 공유 문서 활용 모든 결정사항을
.claude/shared/DECISIONS.md에 기록1 2 3 4 5 6 7 8 9 10 11
# 프로젝트 결정사항 ## 2026-01-11: 상태 관리 **결정**: Zustand 사용 (Redux 대신) **이유**: 보일러플레이트 감소, TypeScript 지원 우수 **담당**: @frontend-developer ## 2026-01-12: 인증 방식 **결정**: httpOnly 쿠키에 JWT 저장 **이유**: XSS 공격 방지 **담당**: @backend-developer
- 에이전트 호출 시 컨텍스트 제공
1 2 3 4 5 6 7
@frontend-developer 컨텍스트: - 상태 관리는 Zustand 사용 (DECISIONS.md 참조) - 인증 토큰은 쿠키에서 자동 전송 이제 로그인 후 사용자 정보를 가져오는 로직을 구현해줘.
문제 3: 일관성 없는 코드 스타일
증상: 각 에이전트가 다른 스타일로 코드 작성 (들여쓰기, 네이밍 등)
해결 방법:
- 공통 CLAUDE.md 작성
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
# 프로젝트 코딩 표준 ## 모든 에이전트 준수 사항 ### 네이밍 - 변수/함수: camelCase - 컴포넌트/클래스: PascalCase - 상수: UPPER_SNAKE_CASE - 파일: kebab-case ### 포맷팅 - 들여쓰기: 2 스페이스 - 최대 줄 길이: 80자 - 세미콜론: 사용 ### TypeScript - any 타입 금지 - 모든 함수에 반환 타입 명시 - Strict mode 활성화
- Prettier/ESLint 설정
1 2 3 4 5 6 7
// .prettierrc { "semi": true, "singleQuote": true, "tabWidth": 2, "printWidth": 80 }
- 커밋 전 자동 포맷팅
1 2 3 4 5 6 7 8 9 10 11 12 13 14
// package.json { "husky": { "hooks": { "pre-commit": "lint-staged" } }, "lint-staged": { "*.{js,jsx,ts,tsx}": [ "prettier --write", "eslint --fix" ] } }
문제 4: 에이전트가 요청을 잘못 이해
증상: 에이전트가 예상과 다른 결과물 생성
해결 방법:
구체적이고 명확한 지시
나쁜 예:
1
@frontend-developer 로그인 페이지 만들어줘.
좋은 예:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
@frontend-developer 로그인 페이지를 다음 스펙대로 만들어줘: 파일: app/login/page.tsx UI 요소: - 이메일 입력 필드 (type="email", required) - 비밀번호 입력 필드 (type="password", required, 최소 8자) - "로그인" 버튼 - "Google로 로그인" 버튼 - "회원가입" 링크 검증: - 이메일 형식 검증 (Zod 사용) - 비밀번호 길이 검증 - 에러 메시지는 필드 아래에 빨간색으로 표시 API: - POST /api/auth/login - 요청: { email, password } - 응답: { token } → 쿠키에 자동 저장 성공 시: /dashboard로 리디렉션 실패 시: 에러 메시지 표시 ("이메일 또는 비밀번호가 올바르지 않습니다") 스타일: - Tailwind CSS 사용 - 중앙 정렬 카드 레이아웃 - 모바일 반응형- 예시 제공
1 2 3 4 5 6 7 8 9 10 11
@frontend-developer 다음과 비슷한 스타일로 버튼을 만들어줘: ```tsx <button className="bg-blue-500 hover:bg-blue-600 text-white px-6 py-3 rounded-lg"> 클릭 </button> ``` 하지만 크기는 더 크게, 그림자 효과도 추가해.
- 반복적 개선
1 2 3 4 5 6 7 8 9
@frontend-developer 로그인 페이지 만들어줘. [결과 확인] 거의 좋은데, 버튼 색상을 파란색으로 바꿔줘. [결과 확인] 좋아! 이제 "비밀번호 찾기" 링크도 추가해줘.
베스트 프랙티스
1. 에이전트 역할 명확화
각 에이전트의 시스템 프롬프트에 명확한 책임 범위를 정의합니다.
1
2
3
4
5
6
7
8
9
## 당신이 하는 일
- React 컴포넌트 작성
- Tailwind CSS 스타일링
- API 통합
## 당신이 하지 않는 일
- 백엔드 로직 (→ @backend-developer에게 요청)
- 데이터베이스 스키마 (→ @database-architect에게 요청)
- 보안 검토 (→ @security-auditor에게 요청)
2. 정기적인 동기화
매일 또는 각 Phase 후 모든 에이전트의 작업을 동기화합니다.
1
2
현재까지 모든 에이전트의 작업을 요약하고,
다음 단계로 진행하기 전에 확인해야 할 사항을 알려줘.
3. 문서화 강제
모든 에이전트는 작업 완료 후 문서를 업데이트해야 합니다.
1
2
3
4
5
6
7
# 에이전트 체크리스트 (모든 에이전트 공통)
작업 완료 후:
- [ ] 변경 사항을 README.md에 반영
- [ ] API 변경 시 .claude/shared/API_SPEC.md 업데이트
- [ ] 새로운 환경 변수 추가 시 .env.example 업데이트
- [ ] 의존성 추가 시 package.json 및 README 업데이트
4. 테스트 주도 개발 (TDD)
QA 에이전트가 먼저 테스트를 작성하고, 개발 에이전트가 테스트를 통과시키는 방식:
1
2
3
4
5
6
7
8
9
# 1단계: QA가 테스트 작성
로그인 기능에 대한 E2E 테스트를 작성해줘.
테스트는 실패해야 해 (아직 기능 미구현).
# 2단계: 개발자가 구현
위 테스트를 통과하도록 로그인 페이지를 구현해줘.
# 3단계: 확인
테스트를 다시 실행하고 통과하는지 확인해줘.
5. 코드 리뷰 문화
모든 중요한 변경사항은 Code Reviewer를 거치도록 합니다.
1
2
3
4
5
6
7
8
9
10
결제 페이지를 구현해줘.
[구현 완료]
위 구현을 리뷰하고, 보안 및 품질 이슈를 확인해줘.
특히 결제 관련이니 민감 데이터 처리를 집중적으로 봐줘.
[리뷰 완료, 수정사항 발견]
리뷰 피드백을 반영해서 수정해줘.
미래 전망과 한계
현재 한계
기술적 한계
직접 통신 불가 에이전트들은 서로 직접 통신할 수 없습니다. 모든 커뮤니케이션은 파일이나 사용자를 통해 이루어집니다.
컨텍스트 공유 제한 각 subagent는 독립적인 컨텍스트 윈도우를 가지므로, 다른 에이전트가 방금 한 작업을 즉시 알 수 없습니다.
플랫폼 간 격차 Claude Code와 Google Antigravity는 직접 통합되지 않으며, Git을 통한 간접 협업만 가능합니다.
개념적 한계
창의성 한계 에이전트는 지시받은 작업은 잘 수행하지만, 스스로 혁신적인 아이디어를 제안하는 능력은 제한적입니다.
맥락 이해 부족 비즈니스 전략, 사용자 경험, 시장 상황 같은 고차원적 맥락을 완전히 이해하지 못합니다.
책임 소재 에이전트가 만든 코드에 버그나 보안 취약점이 있을 때, 최종 책임은 여전히 인간 개발자에게 있습니다.
다가올 미래
단기 (2026-2027)
1. 에이전트 간 직접 통신
1
에이전트들이 파일을 거치지 않고 직접 메시지를 주고받을 수 있게 될 것입니다.
2. 역할 학습 (Role Learning) 에이전트가 과거 작업을 학습하여 점점 더 그 역할에 특화됩니다.
1
완전히 이해하고 있어서, 새 컴포넌트도 자동으로 일관된 스타일로 만들어.
3. 크로스 플랫폼 통합 Claude Code와 Antigravity가 서로 통신할 수 있는 표준 프로토콜 등장:
1
2
3
4
# Claude Code에서
/export-to-antigravity
# Antigravity에서 브라우저 테스트 결과를 다시 Claude Code로 전송
중기 (2027-2028)
1. 자율 에이전트 팀 개발자가 초기 요구사항만 제공하면, 에이전트 팀이 스스로:
- 역할 분담 결정
- 작업 일정 수립
- 문제 발견 시 스스로 해결
- 필요 시 새로운 에이전트 추가
2. 멀티모달 협업 에이전트가 텍스트뿐만 아니라:
- 음성으로 회의 참여
- 화면 공유 및 시연
- 손으로 그린 스케치를 코드로 변환
3. 인간-에이전트 혼합 팀 실제 인간 개발자와 AI 에이전트가 구분 없이 협업:
1
2
3
4
5
6
7
팀 구성:
- Product Manager: Alice (인간)
- Senior Frontend: @frontend-developer (AI)
- Senior Backend: Bob (인간)
- QA Lead: @qa-engineer (AI)
- Junior Developer: Charlie (인간)
- DevOps: @devops-engineer (AI)
장기 (2029+)
1. 에이전트 생태계 수천, 수만 개의 전문 에이전트가 마켓플레이스에서 거래:
1
# 특화된 에이전트 다운로드
2. 자가 진화 에이전트 에이전트가 스스로 능력을 향상:
- 새로운 프레임워크 학습
- 베스트 프랙티스 업데이트
- 동료 에이전트로부터 학습
3. 완전 자율 개발 개발자의 역할이 “코더”에서 “프로덕트 아키텍트”로 전환:
1
2
3
4
5
6
7
8
9
10
11
12
사용자: "Netflix 같은 스트리밍 서비스 만들어줘. 예산 10만 달러."
[6개월 후]
에이전트 팀: "완성했습니다.
- 100만 MAU 지원
- 99.9% 가동률
- AWS 비용 월 2,500달러
- 전체 테스트 커버리지 92%
- GDPR, CCPA 완전 준수
배포하시겠습니까?"
개발자의 역할 변화
현재 (2026):
- 코드 작성: 70%
- AI 도구 사용: 20%
- 전략/기획: 10%
미래 (2030):
- 코드 작성: 10% (복잡한 알고리즘만)
- AI 에이전트 오케스트레이션: 40%
- 전략/기획: 30%
- 비즈니스 이해 및 사용자 공감: 20%
개발자는 “코드를 작성하는 사람”에서 “AI 팀을 이끄는 엔지니어링 리더”로 진화할 것입니다.
결론
멀티 에이전트 협업은 이미 현실이 되었습니다. Claude Code의 subagent 시스템과 Google Antigravity의 에이전트 우선 플랫폼은 소프트웨어 개발 방식을 근본적으로 변화시키고 있습니다.
핵심 요점
역할 분담이 핵심: 각 에이전트에게 명확한 책임과 권한을 부여하세요.
커뮤니케이션이 성공의 열쇠: 공유 문서, Git, 표준 프로토콜로 에이전트 간 정보 흐름을 원활하게 만드세요.
GSD는 선택사항: 간단한 프로젝트는 수동 관리로도 충분하지만, 복잡한 프로젝트는 GSD가 필수입니다.
하이브리드 접근이 현명: Claude Code와 Antigravity의 장점을 결합하여 사용하세요.
인간의 역할은 여전히 중요: 에이전트는 도구일 뿐, 최종 결정과 책임은 인간 개발자에게 있습니다.
시작하기
오늘 바로 시작할 수 있습니다:
- Claude Code 설치
1
# (설치 가이드 참조) - 첫 번째 Subagent 만들기
1 2
mkdir -p .claude/agents # frontend-developer.md 생성
- 간단한 프로젝트로 실험
1
@frontend-developer 간단한 카운터 앱을 만들어줘.
- 점진적으로 확장
- 더 많은 에이전트 추가
- GSD 도입
- Antigravity 실험
마지막 조언
멀티 에이전트 협업은 마법이 아닙니다. 실제 인간 팀과 마찬가지로:
- 명확한 커뮤니케이션
- 표준화된 프로세스
- 정기적인 동기화
- 지속적인 개선
이 모든 것이 필요합니다. 하지만 제대로 설정하고 나면, 여러분은 24시간 쉬지 않고 일하는 전문가 팀을 갖게 됩니다. 그리고 그 팀은 여러분이 전략과 비전에 집중할 수 있도록 해줄 것입니다.
미래는 이미 여기에 있습니다. 이제 여러분 차례입니다. 🚀
작성 일자: 2026-01-11