Augment Code Intent 완전 가이드 — IDE 다음 단계, 에이전트 함대를 지휘하는 법

Claude Code 터미널 3개, Cursor 창 2개 열고 "어디가 뭐 하고 있지?" 계속 추적하다 충돌납니다. Intent는 그 위에 앉아서 전체를 지휘합니다. 에이전트를 쓰는 게 아니라 에이전트 팀을 운영하는 겁니다.

[핵심 요약]
→ Intent: Augment Code가 만든 에이전트 오케스트레이터 데스크탑 앱 (Mac)
→ BYOA: 기존 Claude Code·Codex·Auggie 구독 그대로 사용 — 대체가 아닌 레이어
→ 핵심 구조: Coordinator → Specialist 병렬 실행 → Verifier → PR
→ Living Spec: 스펙이 에이전트 작업 완료 시 자동 업데이트 — 드리프트 없음
→ Git Worktree 격리: 에이전트마다 별도 워킹 디렉토리 → 충돌 원천 차단
→ Context Engine: 40만개 이상 파일 세만틱 의존성 분석
→ 가격: 무료 티어 / Pro $20/월
→ 설치: Mac 앱, 설정 완료까지 1~2분

---

왜 지금 이게 필요한가

기존 멀티에이전트 직접 조율 (고통):
→ 터미널 창 N개에 Claude Code 따로 실행
→ "지금 어느 에이전트가 어느 파일 수정 중?"
→ 같은 파일 동시 수정 → git conflict 폭탄
→ 스펙 문서 따로, 코드 따로 → 나중에 불일치
→ 에이전트 결과물 하나씩 수동 검토
→ 브랜치 병합도 수동

Intent 적용 후:
→ 자연어로 기능 설명 → Living Spec 자동 생성
→ Coordinator가 작업 분해 + 의존성 정렬
→ 각 에이전트 별도 git worktree에서 병렬 실행
→ Verifier가 스펙 대조 자동 검증
→ 깔끔한 PR 자동 생성
→ 스펙은 작업 완료마다 자동 업데이트

SWE-Bench 데이터가 이걸 뒷받침합니다.

[단일 태스크 vs 멀티파일 태스크 정확도]
단일 함수 수준 태스크: ~87% 정확도
멀티파일 패치 (4개+ 파일): ~19% 정확도
→ 에이전트는 작업이 클수록 급격히 성능 하락
→ 해결책: 큰 작업을 작은 단위로 쪼개서 병렬 실행
→ Intent가 하는 일이 정확히 이것

---

실전 1 — 설치 및 첫 워크스페이스

# Mac 앱 다운로드
# https://www.augmentcode.com/intent
# 설치 후 로그인

# 지원 에이전트 중 하나 연결
# - Claude Code (기존 구독 그대로)
# - OpenAI Codex
# - Augment (자체 Auggie 모델)

# VS Code 익스텐션도 별도 설치 가능
code --install-extension augment.vscode-augment

Intent 시작 화면에서 레포지토리 선택 → 워크스페이스 생성합니다.

[워크스페이스 구조]
workspace/
├── .intent/
│   ├── spec.md          # Living Spec — 자동 업데이트
│   ├── tasks.json       # 작업 분해 및 진행 상태
│   └── context.json     # 코드베이스 의존성 맵
├── worktrees/
│   ├── agent-auth/      # 인증 담당 에이전트 격리 공간
│   ├── agent-api/       # API 담당 에이전트 격리 공간
│   └── agent-test/      # 테스트 담당 에이전트 격리 공간
└── (기존 레포 파일들)

---

실전 2 — Living Spec + Coordinator

자연어로 기능을 설명하면 Coordinator가 스펙을 만들고 작업을 분해합니다.

# Intent 채팅창에 입력
"JWT 기반 인증 시스템 추가해줘.
 - auth-service에서 토큰 발급 (RS256)
 - api-gateway 미들웨어에서 검증
 - 토큰 리프레시 + 만료 처리
 - rate limiting 토큰 엔드포인트에 적용"

Coordinator가 자동으로 생성하는 Living Spec:

# spec.md (자동 생성)

## JWT 인증 시스템

### 목표
api-gateway와 auth-service 전반에 JWT 기반 인증 구현

### 수락 기준
- [ ] auth-service: RS256으로 토큰 발급
- [ ] auth-service: 리프레시 토큰 + 만료 처리
- [ ] api-gateway: JWT 검증 미들웨어
- [ ] rate limiting: 토큰 엔드포인트 적용

### 영향 파일 (Context Engine 분석)
auth-service:
  - src/auth/token.service.ts (수정)
  - src/auth/refresh.service.ts (신규)
  - src/auth/rate-limit.middleware.ts (신규)

api-gateway:
  - src/middleware/jwt.middleware.ts (신규)
  - src/middleware/auth.guard.ts (수정)

### 작업 분해 (의존성 정렬)
Wave 1 (병렬 실행):
  - Task A: auth-service 토큰 발급 로직
  - Task B: api-gateway JWT 검증 미들웨어

Wave 2 (Wave 1 완료 후):
  - Task C: 리프레시 토큰 (Task A 의존)
  - Task D: rate limiting (Task A 의존)

Wave 3:
  - Task E: 통합 테스트

### 상태: 🟡 진행 중

[Living Spec의 핵심]
→ 에이전트가 작업 완료하면 체크박스 자동 업데이트
→ 모든 에이전트가 동일한 스펙 참조 → 방향 이탈 없음
→ 요구사항 중간에 바뀌면 스펙 수정 → 모든 에이전트에 전파
→ 기존 PRD/디자인 문서와 달리 항상 현재 상태 반영
→ 3개월 후 돌아봐도 "왜 이렇게 짰지?" 가 스펙에 있음

---

실전 3 — Git Worktree 격리 + 병렬 실행

Intent의 핵심 기술입니다. 에이전트마다 별도 git worktree에서 실행해서 충돌을 원천 차단합니다.

# Intent가 내부적으로 하는 일 (개념 설명)

# Wave 1: Task A, B 동시 시작
git worktree add .intent/worktrees/agent-auth feature/auth-token
git worktree add .intent/worktrees/agent-api feature/api-jwt

# 각 에이전트가 자기 워킹 트리에서만 작업
# agent-auth → .intent/worktrees/agent-auth/ 에서만
# agent-api  → .intent/worktrees/agent-api/ 에서만
# 물리적으로 분리 → 같은 파일 동시 수정 불가능

# Wave 1 완료 후 Verifier 실행
# → 각 에이전트 결과물을 스펙과 대조

# 검증 통과 시 Wave 2 시작
git worktree add .intent/worktrees/agent-refresh feature/auth-refresh
git worktree add .intent/worktrees/agent-rate feature/auth-rate-limit

# 모든 Wave 완료 후 순차 병합
git merge feature/auth-token
git merge feature/api-jwt
# ... 충돌 최소화된 순차 병합

실제 Intent 사용 흐름:

[Intent UI에서 보이는 것]

워크스페이스: JWT 인증 시스템
────────────────────────────────
🟢 Task A — Auth 토큰 발급     [agent-auth]   완료 ✓
🟢 Task B — JWT 미들웨어        [agent-api]    완료 ✓
🟡 Task C — 리프레시 토큰       [agent-refresh] 진행 중... 67%
🔵 Task D — Rate Limiting       [agent-rate]   대기 (C 의존)
🔵 Task E — 통합 테스트         [agent-test]   대기

Verifier: Task A, B 스펙 검증 완료 ✓
변경 파일: 7개 | 추가 라인: +234 | 삭제: -12
────────────────────────────────
[PR 미리보기] [일시정지] [취소]

---

실전 4 — Verifier + PR 자동 생성

Verifier는 에이전트 결과물이 스펙을 실제로 만족하는지 자동 검증합니다.

[Verifier 검증 항목]

스펙 대조:
✅ auth-service: RS256 토큰 발급 구현됨
✅ api-gateway: JWT 검증 미들웨어 추가됨
⚠️ 리프레시 토큰 만료 처리 누락 — Task C에 재작업 요청
✅ rate limiting 적용됨

코드 품질:
✅ 기존 API 시그니처 변경 없음
✅ 테스트 커버리지 82% (요구사항 80% 이상)
✅ TypeScript strict 모드 통과
⚠️ JWT_SECRET 환경변수 하드코딩 감지 → 수정 요청

아키텍처:
✅ 모듈 경계 침범 없음
✅ auth-service → api-gateway 단방향 의존성 유지

Verifier 통과 후 자동 생성되는 PR:

## PR: JWT 기반 인증 시스템 구현

### 변경 사항
- auth-service: RS256 JWT 발급, 리프레시, 취소
- api-gateway: JWT 검증 미들웨어 + rate limiting

### 스펙 달성률: 5/5 ✅

### 변경 파일
- src/auth/token.service.ts (수정)
- src/auth/refresh.service.ts (신규, +89줄)
- src/middleware/jwt.middleware.ts (신규, +67줄)
- src/middleware/auth.guard.ts (수정)
- src/auth/rate-limit.middleware.ts (신규, +43줄)
- tests/auth.integration.test.ts (신규, +156줄)

### 테스트
- 단위 테스트: 24개 통과
- 통합 테스트: 8개 통과
- 커버리지: 82%

### Living Spec 링크
.intent/spec.md (자동 업데이트됨)

[Intent vs 직접 조율 비교]
구분              직접 조율          Intent
────────────────────────────────────────────
에이전트 추적     수동 (터미널N개)    자동 대시보드
파일 충돌         자주 발생           워크트리 격리
스펙 동기화       수동               자동 업데이트
결과물 검증       수동 코드리뷰       Verifier 자동
PR 생성          수동               자동
컨텍스트 분석     개발자가 제공       Context Engine
에이전트 선택     고정               태스크별 라우팅

---

마무리

✅ Intent 써야 하는 경우
→ Claude Code·Cursor 이미 쓰는데 멀티에이전트로 확장하고 싶을 때
→ 큰 기능을 여러 에이전트에 나눠서 병렬로 처리하고 싶을 때
→ 에이전트 결과물 추적·검증을 자동화하고 싶을 때
→ 스펙과 코드 사이 드리프트 문제를 겪고 있는 팀
→ 멀티레포, 멀티서비스 복잡한 코드베이스 환경

❌ 아직 필요 없는 경우
→ 단일 에이전트로 충분한 단순 태스크
→ 혼자 작업하는 소규모 프로젝트
→ 빠른 탐색적 코딩 (오버헤드)
→ Windows 사용자 (현재 Mac 전용)
→ 에이전트 자체를 처음 시작하는 경우
   (Claude Code나 Cursor 먼저 익숙해지고 나서)

---

관련 글

• AWS Kiro 완전 가이드 — Spec-Driven IDE, Amazon Q Developer가 죽고 나서
• Claude Code Agent Teams 실전 가이드 — 병렬 에이전트 설정부터 실전 시나리오까지