04 - 계획 모드 및 백그라운드 에이전트: 더 빠르지 않고 더 스마트하게 작업
많은 개발자들이 에이전트 모드가 전통적이라는 것을 깨닫는 정확한 순간이 있습니다. 충분하지 않습니다. 프롬프트가 정확하고 컨텍스트가 제공되었지만 에이전트가 즉시 코드 작성을 시작합니다. 문제를 제대로 이해하기도 전에요. 필요하지 않은 파일을 추가하고 필요하지 않은 클래스를 수정합니다. 20분 동안 자율적으로 실행한 후 작동하는 코드베이스를 발견하게 됩니다. 하지만 그것은 잘못된 방향으로 성장했습니다.
이 문제에 대한 커서의 대답은 다음과 같습니다. 계획 모드. 글을 쓰기 전에 한 줄의 코드로 에이전트는 프로젝트를 분석하고, 명확한 질문을 하고, 계획을 생성합니다. Markdown으로 구조화되어 있으며 승인을 요청합니다. 각 단계를 검토하고 검증한 후에만 처형이 시작됩니다. 그리고 근본적으로 다른 철학은 다음과 같습니다. 코딩하기 전에 생각해보세요.
계획 모드와 함께 Cursor 2.0이 도입되었습니다. 백그라운드 에이전트: AI 프로세스 작업 트리를 통해 격리된 git 분기에서 병렬로 작동합니다. 지점에 코드를 작성하는 동안 기본, 최대 8명의 상담원이 서로 다른 작업을 동시에 작업할 수 있습니다. 작업이나 서로를 방해하지 않고 완전히 분리된 환경입니다.
이 고급 문서에서는 두 가지 기능, 즉 작동 방식과 시기를 자세히 살펴보겠습니다. 이를 사용하고 결합하는 방법과 복잡한 개발 워크플로에 가장 효과적인 패턴은 무엇인지 알아보세요.
이 기사에서 배울 내용
- 플랜 모드가 AI 지원 개발의 패러다임을 바꾸는 방법
- 전체 워크플로우: 프롬프트 생성부터 계획 승인까지
- 백그라운드 에이전트란 무엇이며 Cursor에서 git 작업 트리가 어떻게 작동합니까?
- Cursor 2.0으로 최대 8개의 병렬 에이전트를 시작하는 방법
- 임무 제어: 실행 중인 에이전트 모니터링 및 관리
- 실제 사용 사례: 기능 스캐폴딩, 병렬 버그 수정, 마이그레이션 프로젝트
- 장기 실행 에이전트: 한도, 모범 사례 및 비용 관리
- 커서 규칙이 생성된 계획을 안내하는 방법
- 프로덕션 환경에서 테스트된 실제 제한 및 해결 방법
시리즈 내 위치: 커서 IDE 및 AI 기반 개발
| # | Articolo | 수준 |
|---|---|---|
| 1 | 커서 IDE: 개발자를 위한 전체 가이드 | 초보자 |
| 2 | 커서 규칙: 프로젝트에 대한 AI 구성 | 중급 |
| 3 | 에이전트 모드: 명령으로 코드베이스 수정 | 중급 |
| 4 | 계획 모드 및 백그라운드 에이전트(현재 위치) | 고급의 |
| 5 | 커서 후크: 작업 흐름 자동화 | 중급 |
| 6 | MCP 및 커서: IDE를 데이터베이스 및 API에 연결 | 고급의 |
| 7 | Cursor AI를 사용한 디버깅: 3배 더 빨라짐 | 중급 |
| 8 | 2026년 커서 vs 윈드서핑 vs 코파일럿 | 초보자 |
| 9 | 전문적인 작업 흐름: 커서가 있는 Angular 프로젝트 | 고급의 |
계획 모드란 무엇이며 에이전트 모드와 어떻게 다른가요?
계획 모드를 이해하려면 먼저 이 모드가 해결하는 문제를 이해해야 합니다. ~ 안에 에이전트 모드 표준에서는 흐름이 직접적입니다. 사용자가 지시를 하면 에이전트가 관련 파일을 읽고 시작합니다. 즉시 시행합니다. 이 접근 방식은 제한적이고 잘 정의된 작업에 효율적입니다. 하지만 복잡하거나 모호한 문제에서는 체계적으로 실패합니다.
상담원에게 다음과 같이 묻는다고 상상해 보세요. "지원하기 위해 인증 모듈을 리팩터링 Google 및 GitHub를 사용한 OAuth2". 일반 모드의 에이전트가 편집을 시작할 수 있음 JWT를 사용한다는 사실, 사용자 정의 미들웨어가 있다는 사실, 또는 아키텍처에 서버측 세션 관리가 포함되어 있다는 것입니다. 결과는 올바른 코드입니다 추상적이지만 프로젝트의 맥락에서는 잘못된 것입니다.
"코딩하기 전에 생각하라" 철학
계획 모드는 심의층 실행 전. 언제 계획 모드를 활성화하면 에이전트는 코드를 작성하지 않습니다. 즉, 질문하고, 코드베이스를 검색하고, 식별합니다. 그런 다음 종속성과 제약 조건을 정확히 설명하는 구조화된 문서를 생성합니다. 파일별로, 단계별로 하려고 합니다.
계획은 편집 가능한 Markdown 파일입니다. 이를 편집하고 동의하지 않는 단계를 제거할 수 있습니다. 에이전트가 고려하지 않은 제약 조건을 추가하고 잘못된 가정을 수정합니다. 오직 언제 만족스러우면 "빌드"를 클릭하면 승인된 계획에 따라 실행이 시작됩니다.
계획 모드와 에이전트 모드를 사용하는 경우
두 모드 사이의 선택은 주로 작업의 복잡성과 모호성에 따라 달라집니다.
모드 선택 가이드
| 업무특성 | 권장 모드 |
|---|---|
| 간단하고 잘 정의된 작업(버그 수정, 기능 추가) | 직접 상담원 모드 |
| 여러 모듈에 영향을 미치는 복잡한 기능 | 계획 모드 |
| 아키텍처 리팩토링 | 계획 모드 필수 |
| 마이그레이션(프레임워크, 데이터베이스, 라이브러리) | 계획 모드 + 백그라운드 에이전트 |
| 잘 알고 있고 이미 수행한 작업 | 특정 규칙이 있는 에이전트 모드 |
| 알 수 없거나 상속된 코드베이스 | 항상 계획 모드 |
| 구조화된 상용구 생성 | 템플릿이 포함된 계획 모드 또는 에이전트 |
계획 모드 작동 방식: 프롬프트에서 실행 가능한 계획까지
계획 모드는 다음을 눌러 활성화됩니다. Shift + 탭 상담원 입력 필드에서 또는 복잡한 요청을 감지하면 커서가 자동으로 제안합니다. 한 번 활성화되면 흐름이 4개의 개별 단계로 구분됩니다.
1단계: 코드베이스 연구 및 분석
에이전트는 프롬프트에서 시작하지 않고 코드베이스에서 시작합니다. 에이전트 모드와 동일한 도구 사용 (의미론적 검색, 파일 읽기, grep), 프로젝트를 탐색하여 컨텍스트를 이해합니다. 식별 관련 파일, 기존 문서 읽기, 종속성 및 관계 분석 모듈 사이.
이 단계에서 상담원은 다음을 수행할 수 있습니다. 설명 질문. 당신의 경우 요청하고 중요한 사항이 모호한 경우 진행하기 전에 지정하도록 요청합니다. 이러한 질문은 가치가 있습니다. 고려하지 않은 암묵적인 가정을 드러내는 경우가 많습니다.
2단계: 계획 수립
분석이 완료되면 에이전트는 구조화된 마크다운 문서를 생성합니다. 계획 포함 사항: 목표 요약, 관련 파일 분석, 번호가 매겨진 단계 목록 자세한 설명, 생성되거나 수정될 파일의 경로 및 잠재적인 정보가 포함되어 있습니다. 위험이나 의존성을 관리해야 합니다.
Cursor 2.2를 사용하면 계획에 다음이 포함될 수 있습니다. 인어 다이어그램 생성된 구성 요소 간의 흐름, 아키텍처 및 관계를 자동으로 시각화합니다.
다음은 인증 리팩토링을 위해 생성된 계획의 예입니다.
# Piano: Refactoring Autenticazione con OAuth2
## Obiettivo
Aggiungere supporto OAuth2 (Google e GitHub) al sistema di autenticazione esistente,
mantenendo la compatibilità con il flusso email/password attuale.
## Analisi Codebase
- File autenticazione: src/auth/auth.service.ts, src/auth/auth.guard.ts
- JWT gestito in: src/middleware/jwt.middleware.ts
- Session management: server-side (express-session)
- Database: PostgreSQL con tabella `users` (id, email, password_hash, created_at)
## Step da Eseguire
### Step 1: Aggiunta dipendenze OAuth2
- [ ] Installare `passport`, `passport-google-oauth20`, `passport-github2`
- [ ] Aggiornare package.json e package-lock.json
- File: package.json
### Step 2: Configurazione strategy OAuth
- [ ] Creare src/auth/strategies/google.strategy.ts
- [ ] Creare src/auth/strategies/github.strategy.ts
- [ ] Aggiornare src/auth/auth.module.ts per registrare le nuove strategy
- File da creare: 2 nuovi, 1 modificato
### Step 3: Migrazione schema database
- [ ] Aggiungere colonne `oauth_provider` e `oauth_id` alla tabella users
- [ ] Creare migration: db/migrations/20251205_add_oauth_fields.sql
- [ ] Aggiornare User entity per riflettere nuovi campi
- File: User.ts, nuova migration
### Step 4: Aggiornamento route e controller
- [ ] Aggiungere endpoint GET /auth/google e GET /auth/google/callback
- [ ] Aggiungere endpoint GET /auth/github e GET /auth/github/callback
- [ ] Aggiornare auth.controller.ts
- File: auth.controller.ts, app.routes.ts
### Step 5: Test e validazione
- [ ] Aggiornare test esistenti per compatibilità
- [ ] Aggiungere test integrazione per flusso OAuth
- File: auth.spec.ts, nuovi file di test
## Rischi Identificati
- La migrazione DB richiede backup preventivo in produzione
- I callback URL devono essere configurati nelle console Google/GitHub
- I secret OAuth devono essere aggiunti alle variabili d'ambiente
## File NON Toccati
- src/middleware/jwt.middleware.ts (compatibilità preservata)
- Frontend components (fuori scope di questo piano)
3단계: 계획 검토 및 편집
계획은 편집기에서 Markdown 파일로 열립니다. 직접 편집할 수 있습니다. 제거 불필요한 단계, 제약 조건 추가, 파일 이름 수정, 접근 방식 지정 대안. 이것은 가장 중요한 단계입니다. 귀하의 개입이 품질을 결정합니다. 다음 실행의.
피해야 할 일반적인 실수
계획을 읽지 않고 승인하지 마십시오. 즉시 "빌드"를 클릭하고 싶은 유혹이 강합니다. 하지만 이것이 바로 계획 모드가 에이전트 모드와 다른 점입니다. 검토 및 부분 프로세스에 필수적입니다. 검토 없이 승인된 계획은 에이전트 모드보다 나쁩니다. 왜냐하면 그것은 당신에게 잘못된 통제감을 주기 때문입니다.
4단계: 계획 중심 실행
"Build"를 클릭하면 Cursor는 에이전트 모드로 들어가지만 계획은 구조화된 가이드로 사용됩니다. 에이전트는 계획을 "사양"으로 사용하여 정의된 순서대로 단계를 실행합니다. 참조. 진행 상황을 실시간으로 모니터링할 수 있습니다. 완료된 각 단계는 표시되고 상담원은 원래 계획에서 벗어난 사항을 보고합니다.
실행 중 예상치 못한 문제가 발생하면 에이전트는 중지하고 사용자에게 묻습니다. 잠재적으로 잘못된 솔루션을 향해 독립적으로 진행하는 대신 지침을 따르십시오.
백그라운드 에이전트: 아키텍처 및 운영
계획 모드는 실행 품질 문제를 해결하지만, 백그라운드 에이전트 속도와 병렬성 문제를 해결합니다. 11월에 Cursor 2.0과 함께 도입됨 2025, 하나의 환경에서 각각 최대 8개의 에이전트를 동시에 실행할 수 있습니다. 자식이 완전히 격리되었습니다.
Git Worktrees: 기본 기술
백그라운드 에이전트는 다음을 기반으로 합니다. 자식 작업 트리, 기본 기능 동일한 저장소와 연관된 여러 작업 디렉토리를 가질 수 있는 git 다른 지점에. 기존 클론(전체 저장소를 복제함)과 달리 디스크), 작업 트리 및 경량: Git 개체 저장소를 공유하며 공간만 필요합니다. 지점마다 실제로 다른 파일의 경우.
커서의 경우 이는 각 백그라운드 에이전트에 다음이 있음을 의미합니다.
- Un 전용 Git 브랜치 그가 고립되어 일하는 곳
- 에이 별도의 작업 디렉토리 로컬 파일 시스템에서
- Un 별도의 코드베이스 인덱스 의미 검색을 위해
- 간섭 없음 귀하의 업무 또는 다른 대리인과 함께
결과적으로 지점에서 일할 수 있습니다. main 세 명의 상담원이 편집하는 동안
입력하지 않고도 기능/인증, 기능/대시보드 및 수정/성능을 동시에 수행할 수 있습니다.
갈등 중.
Cursor 2.0을 사용하여 백그라운드 에이전트 실행
병렬 에이전트를 시작하려면 두 가지 주요 접근 방식이 있습니다. 첫 번째이자 가장 일반적인 것: 작성기 패널에서 새 에이전트 탭을 열고 특정 작업을 할당합니다. 각 탭은 백그라운드에서 작동할 수 있는 독립 에이전트를 나타냅니다.
Cursor 2.0에 도입된 두 번째 접근 방식을 사용하면 여러 에이전트를 시작할 수 있습니다. 같은 프롬프트에서: 주체가 지시를 받고, 이를 하위 작업으로 분해하고 각 작업에서 병렬로 작동하는 하위 에이전트를 생성합니다. 하위 작업. 이제 하위 에이전트는 비동기식일 수 있으므로 상위 에이전트가 허용됩니다. 아이들이 공연하는 동안 계속하세요.
# Workflow con 3 Background Agents in Parallelo
## Setup iniziale
# Abilita la visualizzazione dei worktrees nel pannello SCM (opzionale)
# Cursor settings.json:
{
"git.showCursorWorktrees": true
}
## Branch principale (il tuo lavoro normale)
$ git branch
* main
feature/auth-oauth
feature/dashboard-redesign
fix/api-performance
## Struttura worktrees (gestita automaticamente da Cursor)
$ git worktree list
/home/user/myproject abc1234 [main]
/tmp/cursor-agent-1/myproject def5678 [feature/auth-oauth]
/tmp/cursor-agent-2/myproject ghi9012 [feature/dashboard-redesign]
/tmp/cursor-agent-3/myproject jkl3456 [fix/api-performance]
## Ogni agente lavora nel suo worktree isolato
# Agent 1 - OAuth2 implementation
# Prompt: "Implementa OAuth2 con Google seguendo il piano auth-plan.md"
# Agent 2 - Dashboard redesign
# Prompt: "Refactoring del dashboard component con nuovi charts per D3.js"
# Agent 3 - Performance fix
# Prompt: "Ottimizza le query N+1 nel modulo ordini identificate dal profiler"
## Al completamento, i branch sono pronti per review e merge
$ git diff main...feature/auth-oauth
$ git diff main...feature/dashboard-redesign
$ git diff main...fix/api-performance
비동기 에이전트 및 재귀 생성
Cursor 2.2의 가장 중요한 혁신 중 하나는 에이전트의 작업 능력입니다. 어떤 면에서는 완전 비동기. 이전 버전에서는 에이전트가 기본 생성된 하위 에이전트는 각 에이전트가 완료될 때까지 기다려야 했습니다. 진행하세요. 이제 하위가 병렬로 작업하는 동안 상위는 계속할 수 있습니다.
훨씬 더 강력한 것은 하위 에이전트가 자신의 하위 에이전트를 생성하는 능력입니다. 만들기 조정 작업 트리. 주 대리인은 다음을 수행할 수 있습니다. 기능 A를 자식에게 위임하면 자식은 손자에게 작업을 분할합니다. 테스트용, 손자 구현용. 커서가 동기화를 처리합니다. 트리의 결과를 일관된 방식으로 제시합니다.
임무 제어: 병렬 에이전트 모니터링
여러 상담원이 동시에 작업하므로 무엇을 하는지 파악하는 것이 중요합니다. 그것은 일어나고 있습니다. 커서 2.0은 패러다임으로 인터페이스를 재설계했습니다. 상담원 중심: 파일을 관리하는 대신 프로세스를 관리합니다.
에이전트 패널
커서 사이드바에는 활성 상담원 패널이 있습니다. 에이전트가 올 때마다 자신을 보여주세요:
- 이름과 임무 할당됨(초기 프롬프트에서 파생됨)
- 브랜치 자식 그가 작업하고 있는 것
- 상태: 실행 중, 입력 대기 중, 완료됨, 오류 발생
- 마지막 단계 수행 상세한 로그와 함께
- 수정된 파일 현재 세션에서
- 소비된 토큰 및 비용 견적
실행 중인 에이전트와 상호 작용
상담원을 클릭하면 채팅 기록을 열고 파일을 볼 수 있습니다. 그가 수정한 내용을 수정하거나 새로운 지시를 내리거나 실행을 중단합니다. 대리인인 경우 막히거나 잘못된 방향으로 가고 있는 경우 클릭 한 번으로 중지할 수 있습니다. 새 메시지로 리디렉션하세요.
Mission Control에 유용한 단축키
| 행동 | 바로가기/방법 |
|---|---|
| 새로운 에이전트 배경 | Composer 패널에서 Cmd+Shift+N |
| 에이전트 간 전환 | 상담원 패널을 클릭하거나 Cmd+Shift+Tab을 클릭하세요. |
| 에이전트당 계획 모드 활성화 | 상담원 입력의 Shift+Tab |
| 에이전트 실행 중지 | 에이전트 헤더에서 중지 버튼을 클릭하세요. |
| 차이점 에이전트 검토 | 에이전트 패널에서 "변경된 파일"을 클릭하세요. |
| SCM 작업 트리 표시 활성화 | git.showCursorWorktrees 설정: true |
실제 사용 사례
사례 1: 계획 모드를 사용한 기능 스캐폴딩
일반적인 시나리오: 기존 애플리케이션에 완전한 모듈을 추가해야 합니다. 계획 모드가 없으면 상담원이 다른 규칙으로 양식을 생성할 수 있습니다. 프로젝트의 나머지 부분에서 벗어나거나 통합된 아키텍처 패턴을 무시하세요.
계획 모드의 흐름은 다음과 같습니다.
- Composer를 열고 다음을 누릅니다. Shift+Tab 계획 모드를 활성화하려면
- 기능을 설명하세요. "WebSocket을 통해 실시간 알림 모듈 추가, 사용자 기본 설정 및 기록 관리"
- 에이전트는 프로젝트를 분석하여 기존 패턴, 명명 규칙, 모듈 아키텍처를 식별합니다.
- 그는 당신에게 다음과 같은 질문을 합니다. "프로젝트에서 상태 관리를 위해 Redux 또는 Context API를 사용합니까?", “테스트를 포함해야 하나요, 아니면 별도로 처리해야 하나요?”
- 프로젝트 규칙을 존중하면서 파일의 정확한 구조로 계획을 생성합니다.
- 단계를 검토하고 제거할 수도 있습니다(예: "스토리북 스토리를 추가하지 마세요. 우리는 그것을 사용하지 않습니다.")
- 빌드를 클릭하면 첫 번째 시도부터 양식이 올바르게 스캐폴딩됩니다.
사례 2: 백그라운드 에이전트와 유사한 버그 수정
애플리케이션의 서로 다른 모듈에 각각 격리된 4개의 버그 목록이 있습니다. 대신에 순차적으로 수정하면 병렬화할 수 있습니다.
# Esempio: 4 bug fix in parallelo
## Agent 1: Fix validazione form
# Branch: fix/form-validation
# Prompt: "Il form di registrazione accetta email non valide.
# File: src/components/RegisterForm.tsx
# Aggiungi validazione RFC 5322 e mostra errore inline"
## Agent 2: Fix query performance
# Branch: fix/slow-dashboard-query
# Prompt: "La dashboard impiega 8s a caricare.
# File: src/api/dashboard.service.ts, line 45
# La query fa N+1 su orders->items. Aggiungi eager loading"
## Agent 3: Fix mobile layout
# Branch: fix/mobile-navbar
# Prompt: "Su viewport < 768px il navbar si sovrappone al content.
# File: src/components/Navbar.css
# Z-index e position sticky si conflittano"
## Agent 4: Fix gestione errori
# Branch: fix/error-boundaries
# Prompt: "L'app crasha senza error boundary.
# Aggiungi React ErrorBoundary al router e ai moduli critici"
## Risultato dopo ~15 minuti:
## 4 branch pronti, ciascuno con il proprio fix isolato
## Review e merge sequenziale o con stacked PRs
장점은 단지 일시적인 것이 아닙니다. 별도의 분기에 수정 사항을 격리하여 검토 훨씬 더 간단합니다. 각 PR은 하나의 문제에만 영향을 미치며 그 차이는 최소화되고 이해할 수 있습니다.
사례 3: 계획 + 백그라운드 에이전트가 포함된 마이그레이션 프로젝트
가장 강력한 사용 사례: 계획이 필요한 복잡한 마이그레이션 정확하고 병렬성. 예를 들어 애플리케이션을 JavaScript에서 TypeScript로 마이그레이션합니다.
최적의 작업 흐름:
- 계획 모드를 사용하여 전체 마이그레이션 전략 생성
- 계획에서는 4개의 종속성 클러스터로 그룹화된 30개의 파일을 식별합니다.
- 클러스터당 하나씩 4개의 백그라운드 에이전트 실행
- 각 에이전트에는 마스터 플랜과 파일 하위 집합이 포함되어 있습니다.
- 에이전트가 작업하는 동안 Mission Control에서 모니터링하고 충돌을 관리합니다.
- 완료되면 4개 브랜치를 검토하고 올바른 순서로 병합하세요.
장기 실행 에이전트: 작동 방식 및 예상 사항
Cursor의 백그라운드 에이전트는 확장된 세션 동안 작업할 수 있습니다. IDE를 닫았습니다. 이 기능은 특히 필요한 작업에 유용합니다. 마이그레이션, 대규모 테스트 생성 또는 심층적인 코드베이스 분석.
세션의 연속성
단순한 채팅창과 달리 백그라운드 에이전트는 자체적으로 세션 사이의 상태. 에이전트를 시작하고 노트북을 닫은 후 다시 돌아올 수 있습니다. 에이전트는 계속 작동했습니다(원격 컴퓨터에서 실행되도록 구성된 경우). 커서는 두 가지 실행을 모두 지원합니다. 현지의 (다음과 같은 경우 프로세스가 중지됩니다. IDE를 닫습니다) 원격 (에이전트는 인프라 클라우드에서 계속됩니다).
토큰 및 비용 제한
장기 실행 에이전트는 많은 토큰을 소비합니다. 소비를 모니터링하는 것이 중요합니다 청구서에 놀라움을 피하기 위해. 커서는 실시간으로 토큰을 보여줍니다. Mission Control 패널의 각 에이전트에 대해 소비됩니다.
병렬 에이전트 비용에 주의하세요.
각 백그라운드 에이전트는 토큰을 독립적으로 사용합니다. 8개 에이전트 출시 동시에 단일 에이전트 토큰의 8배를 소비할 수 있습니다. 기간. Pro 플랜(월 $20)에는 월별 한도가 있습니다. 병렬 처리 관리 조심스럽게. 실제로 이점을 얻는 작업에는 병렬 에이전트를 사용하십시오. 병렬화는 모든 작업에 대한 기본값이 아닙니다.
계획 모드 및 커서 규칙: 강력한 시너지 효과
계획 모드는 독립적으로 작동하지 않습니다. 다음 요소의 영향을 많이 받습니다. 커서 규칙 프로젝트에서 구성됩니다. 에이전트가 생성되면 계획에서 규칙은 내용을 형성하는 제약 및 지침 역할을 합니다.
규칙이 계획을 안내하는 방법
다음과 같은 규칙을 정의한 경우 "항상 3레이어 클린 아키텍처를 사용하세요" o "모든 새로운 기능에는 Jest를 사용한 단위 테스트가 포함되어야 합니다.", 생성된 계획 이러한 제약 조건을 자동으로 반영합니다. 에이전트는 논리를 제안하지 않습니다. 규칙에 우려 사항의 분리가 명시되어 있는 경우 컨트롤러의 비즈니스.
# Esempio: .cursor/rules/architecture.mdc
---
alwaysApply: true
---
# Architettura del Progetto
## Layer Separation (OBBLIGATORIO)
- Controllers: solo routing e validation input
- Services: logica di business e orchestrazione
- Repositories: accesso dati, zero logica business
- DTOs: trasferimento dati tra layer, tipizzati
## Naming Conventions
- Service: `*.service.ts`
- Repository: `*.repository.ts`
- DTO: `*-request.dto.ts`, `*-response.dto.ts`
- Controller: `*.controller.ts`
## Testing Requirements
- Unit test per ogni Service (copertura min 80%)
- Integration test per ogni Repository
- File test: `*.spec.ts` nella stessa directory
## Quando Plan Mode genera un piano con questa rule attiva:
## - Ogni step crea file nel layer corretto
## - I nomi seguono le convenzioni definite
## - I test sono inclusi come step separato nel piano
## - Non viene mai suggerito codice che attraversa i layer erroneamente
계획 최적화 규칙
구조를 안내하는 계획 모드별 규칙을 생성할 수도 있습니다. 구현뿐만 아니라 계획 자체도 마찬가지입니다.
# Esempio: .cursor/rules/planning.mdc
---
alwaysApply: true
---
# Linee Guida per la Pianificazione
## Prima di generare un piano, DEVI:
1. Identificare tutti i file che verranno modificati
2. Verificare se esistono test da aggiornare
3. Controllare se ci sono migrazioni DB necessarie
4. Valutare l'impatto sulle API esistenti
## Struttura del Piano (OBBLIGATORIA)
Ogni piano deve contenere:
- ## Obiettivo (1 paragrafo)
- ## Analisi Impatto (file, dipendenze, rischi)
- ## Step Implementazione (numerati, con file paths)
- ## Testing (unit + integration)
- ## File NON Toccati (elenco esplicito)
- ## Rollback Strategy (come annullare se va male)
## Dimensione degli Step
- Ogni step deve essere atomico (completabile in 10-15 min)
- Step troppo grandi vanno spezzati in sub-step
- Evita step che dipendono dallo stato di step paralleli
실제 제한 및 해결 방법
계획 모드 및 백그라운드 에이전트는 강력한 기능이지만 제한이 없는 것은 아닙니다. 한계를 아는 것은 능력을 아는 것만큼 중요합니다.
계획 모드: 비행기에서의 환각
계획에는 존재하지 않는 파일 경로, 잘못된 가정 등 오류가 포함될 수 있습니다. 아키텍처, 중복되거나 누락된 단계. 상담원이 최선을 다해 프로젝트를 이해하지만 코드베이스가 크거나 문서화 수준이 낮으면 틀릴 수 있습니다.
해결 방법: 분석 중에 에이전트가 정확한 경로를 인용하도록 강제합니다. 프롬프트에 추가: "계획을 생성하기 전에 찾은 파일을 나열하십시오. 귀하의 연구에서 그것이 올바른지 확인하십시오.". 이 "체크포인트" 최종 계획의 오류를 크게 줄입니다.
백그라운드 에이전트: 병합 충돌
두 에이전트가 서로 다른 분기에서 동일한 파일을 수정하는 경우 병합 시 갈등을 겪게 될 것입니다. 커서는 의미 체계 조정을 자동으로 처리하지 않습니다. 병합이 당신의 일입니다.
해결 방법: 병렬 에이전트를 시작하기 전에 계획을 분석하십시오. 작업이 진정으로 독립적인지 확인하세요. 두 명의 상담원이 접촉해야 하는 경우 동일한 파일(예: 중앙 라우팅 파일), 특정 작업의 순서 나머지는 병렬화합니다.
장기 계획의 장기 컨텍스트
대규모 프로젝트의 경우 생성된 계획이 너무 길어져서 실행 중에는 에이전트 컨텍스트 창에 들어가지 않습니다. 결과 그리고 계획의 마지막 단계는 적은 맥락으로 실행되며 덜 정확하세요.
해결 방법: 큰 계획을 깨십시오. 계획 모드를 사용하여 생성 주요 단계를 식별한 다음 계획 모드를 다시 사용하는 "메타 계획" 각 단계에 대한 세부 계획을 수립합니다. 이 폭포수 접근 방식 각 단계마다 컨텍스트를 관리할 수 있도록 유지합니다.
외부 종속성을 차단하는 에이전트
예를 들어 데이터베이스를 쿼리하거나 외부 API를 호출해야 하는 에이전트 이러한 리소스에 액세스할 수 없으면 작업을 완료하기 위해 작업이 차단됩니다. 실행되는 로컬 또는 원격 개발 환경에서.
해결 방법: 커서 규칙을 사용하여 처리 방법 지정 외부 종속성: "DB에서 실제 데이터가 필요한 경우 해당 파일을 사용하세요. Fixtures/sample-data.json을 모의로 사용". 이를 통해 상담원은 다음을 수행할 수 있습니다. 외부 리소스에 직접 접근하지 않고도 진행할 수 있습니다.
계획 모드 및 백그라운드 에이전트에 대한 모범 사례
1. 계획의 체계적 검토
계획을 실행하기 전에 검토하는 프로세스를 수립합니다. 자신을 제한하지 마십시오 빠르게 스크롤하려면: 각 단계가 적절한지, 파일이 적절한지 확인하세요. 실제로 존재하는 것으로 확인되어 실행 순서가 올바른지 확인합니다. 잘 검토된 계획은 거의 항상 성공적인 실행으로 이어집니다.
2. 에이전트를 시작하기 전에 커밋
에이전트를 시작하기 전에(계획 모드 또는 백그라운드에서) 항상 다음을 수행하십시오. 현재 작업의 커밋. HEAD에서 Git 작업 트리 포크 현재: 깨끗한 작업 디렉토리는 에이전트 분기를 보장합니다. 알려지고 안정적인 상태에서 시작합니다.
3. 병렬 에이전트에 대한 세분화된 작업
에이전트는 잘 정의되고 제한된 작업에 가장 잘 작동합니다. 저항하다 에이전트에게 큰 작업을 제공하려는 유혹("모든 전자상거래 모듈 구현"): 병렬화할 수 있도록 더 작은 작업으로 나눕니다. 병렬성 잘 병렬 모놀리식보다 세분화되어 더 안정적입니다.
4. 코드베이스에서 처음으로 계획 모드 사용
당신이 잘 모르는 코드베이스(상속된 프로젝트, 귀하가 기여하는 오픈 소스, 신규 고객), 항상 계획 모드를 사용하십시오 첫 번째 작업을 위해. 생성된 계획을 통해 패턴을 빠르게 확인할 수 있습니다. 프로젝트를 수행하지 않기로 결정한 경우에도 프로젝트의 건축적 측면.
5. 비용 최적화
모든 작업에 계획 모드가 필요한 것은 아닙니다. i에 대해 선택적으로 계획 모드 사용 복잡한 작업. 간단한 작업의 경우(변수 이름 바꾸기, 가져오기 추가, 문서의 오타 수정), 에이전트 모드가 직접적이고 더 효율적이며 저렴합니다. 계획 모드의 비용에는 분석과 실행이 모두 포함됩니다.
6. 병합 전 차이점 검토
백그라운드 에이전트가 작업을 완료한 후 자동으로 병합하지 마세요.
미국 git diff main...feature/agent-branch 각각을 검토하기 위해
편집하다. 상담원 차이점은 일반적으로 깨끗하고 잘 구성되어 있습니다.
그러나 통합 이전에는 사람의 검토가 여전히 필수적입니다.
계획 모드와 기타 AI 계획 접근 방식
계획 모드는 AI 지원 계획에 대한 유일한 접근 방식은 아니지만 다음을 제공합니다. 대안과 비교하여 몇 가지 독특한 특징이 있습니다.
가장 일반적인 대체 접근 방식은 기술 사양을 수동으로 작성하는 것입니다. 문서에 담아 상담원에게 컨텍스트로 제공합니다. 이것은 작동하지만 시간이 걸립니다 훨씬 더 오래 걸리고 에이전트의 분석 능력을 활용하지 못합니다. 관련 파일을 식별하기 위해 코드베이스를 독립적으로 사용합니다.
2024년에 출시되는 GitHub Copilot Workspace는 다음과 유사한 기능을 제공합니다. 계획 모드가 GitHub 문제에 통합되었습니다. Copilot이 문제를 분석하고 계획을 세우고 PR을 자동으로 열 수 있습니다. 커서의 장점과 통합 편집자와 직접: 동일한 환경에서 계획이 생성되고 실행됩니다. 로컬 프로젝트 코드 및 구조에 대한 완전한 가시성을 제공합니다.
결론
계획 모드 및 백그라운드 에이전트는 질적 도약을 나타냅니다. 개발자가 AI와 협업할 수 있는 곳. 그것은 단지에 관한 것이 아닙니다 작업 속도를 높이세요. 위임할 수 있는 작업 유형을 변경하는 것입니다.
계획 모드에서는 이전에 반복 에이전트 모드가 필요했던 복잡한 기능 계획이 먼저 승인되면 많은 감독이 구조화된 프로세스가 됩니다. 실행의. 에이전트가 시작되므로 생성된 코드의 품질이 향상됩니다. 일반적인 프롬프트가 아닌 문제에 대한 깊은 이해를 통해.
백그라운드 에이전트를 사용하면 병렬 처리는 더 이상 대규모 에이전트의 특권이 아닙니다. 대규모 팀이 있는 회사. 한 명의 개발자가 8개의 에이전트를 조율할 수 있습니다. 동시에 일하는 사람들은 생산성을 몇 배로 늘립니다. 이는 전통적인 순차적 개발에서는 생각할 수 없는 일입니다.
두 가지 기능의 결합 - 병렬 에이전트에 의해 실행되는 정확한 계획 조정됨 - 아마도 오늘날 IDE에서 사용할 수 있는 가장 진보된 워크플로일 것입니다. 상업용. 연습과 학습 곡선이 필요하지만 개발자에게는 그것을 마스터하는 데 투자하는 사람은 상당한 수익을 얻습니다.
시리즈의 다음 단계
- 다음: 커서 후크: 작업 흐름 자동화 - 에이전트의 실행 전후 작업을 자동화하는 방법
- 이전 기사: 에이전트 모드: 명령으로 코드베이스 수정 - 에이전트 모드 및 해당 기능에 대한 전체 가이드
- 관련 기사: 커서 규칙: 프로젝트에 대한 AI 구성 - 규칙이 계획 모드와 에이전트를 안내하는 방법
다른 시리즈와의 연결
- MCP 및 커서: 백그라운드 에이전트는 MCP 도구를 사용하여 다음을 수행할 수 있습니다. 실행 중에 외부 데이터베이스 및 API에 액세스합니다. 참조 MCP 시리즈(ID 64-77) 자세한 내용은.
- 바이브 코딩: 계획 모드와 "사양 우선" 접근 방식이 연결되어 있습니다. 바이브 코딩의 원리에 직접적으로 접근합니다. 참조 바이브 코딩 시리즈 보완적인 관점을 위해.
- 현대적인 각도: 커서, 계획 모드 및 이상적인 Angular 워크플로에서 완전한 모듈을 비계하기 위해. 보시다시피 커서를 사용한 각도 작업 흐름(ID 297).