dmnote-app 작업 계획 수립 - 독립 서브에이전트(Opus) 검증
Claude(메인)가 코드를 분석하고 초안 계획을 작성한 뒤, 독립 서브에이전트에게 검증/보완을 받습니다. 대규모 아키텍처 변경이나 고위험 작업은 병렬 분석 모드로 전환합니다.
모드 선택
기본 모드 (순차 협업)
대부분의 작업에 사용합니다.
- 메인이 codebase-memory-mcp 그래프 도구를 우선 사용하여 관련 코드를 분석합니다.
search_graph로 관련 함수/클래스/모듈 탐색trace_call_path로 콜체인 및 영향 범위 추적get_architecture로 구조 파악- 그래프에 없는 정보(문자열 리터럴, 설정값 등)만 Read/Grep/Glob으로 보완
- 코드 구조, 영향 범위, 초안 계획을 정리합니다.
- 서브에이전트에게 사실 정보만 전달하여 독립 검증을 요청합니다.
- 서브에이전트 피드백을 반영하여 최종 계획을 확정합니다.
병렬 모드 (독립 분석)
다음 조건에 해당하면 병렬 모드를 사용합니다:
- 변경 범위가 크고 아키텍처 영향이 넓을 때
- Rust 백엔드와 React 프론트가 강하게 얽혀 있을 때
- 실패 비용이 큰 리팩토링/마이그레이션일 때
메인 분석과 서브에이전트 분석을 동시에 진행합니다:
- 메인: 그래프 도구 우선, 필요시 Read/Grep 보완
- 서브에이전트: 백그라운드로 독립 분석 (
run_in_background기본값) - 두 분석 결과를 종합하여 최종 계획을 작성합니다.
서브에이전트 호출 방법
Agent 도구를 사용합니다:
subagent_type: "general-purpose",model: "opus"(기본)- 에스컬레이션: 아키텍처 전면 개편, 데이터 모델/영속성 설계 등 실패 비용이 큰 계획 검증은
model지정을 생략하여 메인 모델(상위 티어)을 상속시킵니다. - 백그라운드 실행이 기본 — 완료 시 task-notification으로 자동 수신. 대기 중에는 메인 선분석 등 병렬 가능한 작업만 수행합니다.
- 결과가 즉시 필요하면
run_in_background: false로 동기 실행합니다. - 사실 수집(파일 목록·콜체인 정찰)만 필요한 보조 탐색은
Explore에이전트 +model: "sonnet"으로 저비용 병렬 처리할 수 있습니다.
프롬프트 구성 (기본 모드)
사실 정보(파일 목록, 코드 구조, 영향 범위)만 전달하고, 메인의 판단/결론은 포함하지 않습니다 (anchoring bias 방지).
당신은 DmNote 프로젝트(Tauri: Rust + React)의 독립 설계 검증자입니다.
다음 작업의 구현 계획을 독립적으로 수립/검증하세요. 파일은 직접 읽어서 확인하세요.
코드를 수정하지 마세요 — 분석과 계획만 보고합니다.
기술 스택: Tauri(Rust + React), Zustand, Preact Signals, Tailwind CSS, Vite + React Compiler
작업 내용: (사용자 요청)
관련 코드 정보:
- 관련 파일: (파일 경로 목록)
- 코드 구조: (함수/모듈 관계, 콜체인 등 사실 정보)
- 영향 범위: (변경 시 영향받는 파일/함수 목록)
요청:
- 구현 계획을 단계별로 수립
- 누락된 영향 범위나 리스크 지적
- 더 나은 접근 방식이 있으면 제안
출력 형식 (반드시 준수):
## 구현 계획
1. (단계별 작업 - 파일명과 변경 내용)
## 리스크
- (잠재적 문제점과 근거)
## 대안
- (고려한 다른 접근 방식이 있다면)
병렬 모드 프롬프트
초안 없이 작업 내용과 기술 스택만 전달하고, 서브에이전트가 스스로 코드를 읽고 독립 분석하도록 지시합니다.
후속 질문 (멀티턴)
같은 에이전트에 SendMessage(에이전트 ID/이름)로 컨텍스트를 유지한 채 추가 질문합니다.
실패 처리
- 서브에이전트가 종료 에러로 실패(결과 null)하면: → "서브에이전트 실패: [원인]. 메인 단독으로 계획을 수립합니다."를 명시하고 단독 진행합니다.
- 응답이 불충분하면 SendMessage로 1회 보완 요청, 그래도 불충분하면 단독 진행합니다.
피드백 필터링
서브에이전트 피드백을 반영할 때 메인이 자체 판단으로 필터링합니다:
- 방어적 코딩 수준의 제안 (에러 핸들링 강화, 옵셔널 체크 추가 등)이 실질적 버그가 아니라 오버엔지니어링에 해당하면 반영하지 않고 생략합니다.
- 프로젝트 컨벤션(예:
let _ = store.update(...)패턴)에 부합하는 코드에 대한 지적은 무시합니다.
출력 형식
메인 분석
(코드 구조, 영향 범위, 기존 패턴)
서브에이전트 피드백
(검증 결과 및 보완 사항. fallback인 경우 "[서브에이전트 미사용: 사유]" 명시)
최종 실행 계획
- (구체적 단계별 작업 - 파일명과 변경 내용 포함)
제약사항 및 리스크
(양쪽에서 지적된 주의점)