plan

계획 수립 명령어 (Plan Command)

이 명령어는 코드를 작성하기 전에 포괄적인 구현 계획을 수립하기 위해 planner 에이전트를 호출합니다.

이 명령어가 하는 일

요구사항 재정의 - 구축해야 할 내용 명확화
리스크 식별 - 잠재적인 문제 및 차단 요소 표면화
단계별 계획 수립 - 구현을 여러 단계로 세분화
확인 대기 - 진행하기 전에 반드시 사용자의 승인을 받아야 함

사용 시점

다음 경우에 /plan을 사용하세요:

새로운 기능 시작 시
중요한 아키텍처 변경 시
복잡한 리팩토링 작업 시
여러 파일/컴포넌트가 영향을 받을 때
요구사항이 불분명하거나 모호할 때

작동 방식

planner 에이전트는 다음을 수행합니다:

요청 분석 및 요구사항을 명확한 용어로 재정의
구체적이고 실행 가능한 단계로 단계별 세분화
컴포넌트 간의 의존성 식별
리스크 평가 및 잠재적 차단 요소 파악
복잡도 추정 (높음/중간/낮음)
계획 제시 및 사용자의 명시적 확인 대기 (WAIT)

사용 예시

User: /plan 마켓이 해결(resolve)될 때 실시간 알림을 추가해야 해

Agent (planner):
# 구현 계획: 실시간 마켓 해결 알림

## 요구사항 재정의
- 사용자가 보고 있는 마켓이 해결될 때 사용자에게 알림 전송
- 여러 알림 채널 지원 (인앱, 이메일, 웹훅)
- 알림이 안정적으로 전송되도록 보장
- 마켓 결과 및 사용자의 포지션 결과 포함

## 구현 단계

### 1단계: 데이터베이스 스키마
- 알림 테이블 추가 (컬럼: id, user_id, market_id, type, status, created_at)
- 채널 선호도를 위한 user_notification_preferences 테이블 추가
- 성능을 위해 user_id 및 market_id에 인덱스 생성

### 2단계: 알림 서비스
- lib/notifications.ts에 알림 서비스 생성
- BullMQ/Redis를 사용한 알림 큐 구현
- 실패한 전송에 대한 재시도 로직 추가
- 알림 템플릿 생성

### 3단계: 통합 포인트
- 마켓 해결 로직에 훅 연결 (상태가 "resolved"로 변경될 때)
- 마켓에 포지션이 있는 모든 사용자 쿼리
- 각 사용자에 대해 알림 큐에 추가

### 4단계: 프론트엔드 컴포넌트
- 헤더에 NotificationBell 컴포넌트 생성
- NotificationList 모달 추가
- Supabase 구독을 통한 실시간 업데이트 구현
- 알림 설정 페이지 추가

## 의존성
- Redis (큐 용도)
- 이메일 서비스 (SendGrid/Resend)
- Supabase 실시간 구독

## 리스크
- 높음: 이메일 도달률 (SPF/DKIM 필요)
- 중간: 마켓당 1000명 이상 사용자 시 성능
- 중간: 마켓이 자주 해결될 경우 알림 스팸
- 낮음: 실시간 구독 오버헤드

## 예상 복잡도: 중간 (MEDIUM)
- 백엔드: 4-6시간
- 프론트엔드: 3-4시간
- 테스팅: 2-3시간
- 총계: 9-13시간

**확인 대기 중**: 이 계획대로 진행하시겠습니까? (yes/no/modify)

중요한 참고 사항

중요 (CRITICAL): planner 에이전트는 당신이 "yes", "proceed" 또는 유사한 긍정적인 응답으로 계획을 명시적으로 확인하기 전까지는 어떠한 코드도 작성하지 않습니다.

변경을 원할 경우 다음과 같이 응답하세요:

"수정: [변경할 내용]"
"다른 접근 방식: [대안]"
"2단계 건너뛰고 3단계 먼저 진행해 줘"

다른 명령어와의 통합

계획 수립 후:

/tdd를 사용하여 테스트 주도 개발로 구현
빌드 에러 발생 시 /build-and-fix 사용
완료된 구현을 리뷰하려면 /code-review 사용

이 명령어가 하는 일​

사용 시점​

작동 방식​

사용 예시​

중요한 참고 사항​

다른 명령어와의 통합​

관련 에이전트​