TeamSPWK/field-test

Nova Field Test

실제 프로젝트에 서브에이전트를 파견하여 Nova 커맨드를 사용하게 하고, 마찰 포인트를 수집한다.

핵심 원칙

• 오케스트레이터는 코드에 개입하지 않는다. 관찰자 역할만 한다.
• 서브에이전트에게 자연어로 지시한다. 실제 팀원에게 말하듯이.
• 워크트리로 격리한다. 테스트 후 삭제하여 흔적을 남기지 않는다.
• Nova 개선 포인트 수집이 목적이다. 코드 품질 자체가 목적이 아니다.

Execution

Phase 1: 프로젝트 설정 (인터랙티브)

사용자에게 순서대로 질문한다:

Q1: "몇 개 프로젝트로 필드 테스트를 진행할까요?"

사용자가 개수를 답하면, 각 프로젝트별로 반복:

Q2: "프로젝트 {N}/{총개수}의 경로를 알려주세요."

Q3: "이 프로젝트에서 어떤 작업을 시켜볼까요? 아래에서 골라도 되고, 자유롭게 말씀해도 됩니다."

시나리오 메뉴를 제시한다:

1. 탐색 + 리뷰 — "코드 전체적으로 훑어보고 개선점 찾아봐"
2. 레거시 정리 — "오래된 코드 찾아서 리팩토링해봐"
3. 기능 구현 — "TODO/FIXME 하나 골라서 구현해봐"
4. 검증 — "기존 코드 테스트 돌리고 갭 분석해봐"
5. 설계 — "새 기능 하나 기획해서 plan → design까지"
6. 자유 — 직접 지시 입력
7. 알아서 — 프로젝트 상태 보고 자동 판단

모든 프로젝트 설정이 끝나면 확인 요약을 보여주고 승인을 받는다:

━━━ Field Test 설정 확인 ━━━
  1. zippit/ — 레거시 정리
  2. ccm-hub/ — 탐색 + 리뷰
  3. planreview/ — 기능 구현

  진행할까요? (y/n)
━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 2: 워크트리 생성

각 대상 프로젝트 레포에서 워크트리를 생성한다.

기존 워크트리 재사용: EnterWorktree 도구의 path 파라미터를 활용하여, 이전 필드 테스트에서 생성한 워크트리가 남아있으면 새로 생성하지 않고 재사용한다.

# 기존 워크트리 확인
EXISTING=$(git -C {프로젝트_경로} worktree list | grep "nova-field-test" | awk '{print $1}')

if [ -n "$EXISTING" ]; then
  # 기존 워크트리 재사용 (EnterWorktree path 파라미터 활용)
  cd "$EXISTING"
else
  # 새 워크트리 생성
  cd {프로젝트_경로}
  git worktree add /tmp/nova-field-test-{프로젝트명}-{timestamp} -b nova-field-test-{timestamp}
fi

워크트리 생성 실패 시 해당 프로젝트는 건너뛰고 사유를 기록한다.

Phase 3: 서브에이전트 파견

각 프로젝트별로 서브에이전트를 생성한다. 병렬 실행한다.

서브에이전트 지시 원칙

1. 자연어로 말한다 — 커맨드를 나열하지 않는다
2. 목적을 설명한다 — "Nova 커맨드 써봐"가 아니라 "코드 좀 봐줘"
3. 자유도를 준다 — 구체적 파일/라인을 지정하지 않는다
4. Nova 사용을 유도하되 강제하지 않는다 — "필요하면 리뷰도 돌려봐" 정도

시나리오별 지시 템플릿

각 시나리오에 대해 아래 템플릿을 기반으로 자연어 지시를 생성한다. 그대로 복사하지 말고, 프로젝트 상태에 맞게 변형한다.

탐색 + 리뷰:

"{프로젝트명} 프로젝트를 맡게 됐어. 전체 구조를 파악하고 코드 품질이 어떤지 봐줘. 개선할 점이 보이면 리뷰 돌려서 정리해줘. 큰 문제 있으면 알려주고."

레거시 정리:

"이 프로젝트에 오래된 코드가 좀 있을 거야. 훑어보고 레거시 느낌나는 부분 찾아줘. 정리할 수 있는 건 정리하고, 큰 건 계획만 세워줘. 끝나면 리뷰 한번 돌려봐."

기능 구현:

"코드에 TODO나 FIXME가 있을 텐데, 하나 골라서 구현해봐. 너무 큰 거 말고 적당한 거로. 끝나면 검증까지 해줘."

검증:

"이 프로젝트가 제대로 돌아가는지 확인 좀 해줘. 테스트 있으면 돌려보고, 설계 문서가 있으면 실제 코드랑 맞는지도 봐줘."

설계:

"이 프로젝트에 추가하면 좋을 기능 하나 생각해봐. 기획부터 설계까지 해보고, 구현은 하지 마. 문서만 만들어줘."

알아서:

"이 프로젝트 처음 보는 거야. 코드 파악하고, 네가 보기에 가장 필요한 작업을 해줘. 버그 수정이든, 정리든, 새 기능이든 판단은 네 몫이야."

서브에이전트에 반드시 포함할 컨텍스트

작업 디렉토리: {워크트리_경로}
주의사항:
- 이 프로젝트에는 Nova Quality Gate가 설치되어 있어. Nova 커맨드(/plan, /review, /check, /ask 등)를 적극 활용해.
- 작업 완료 시 반드시 아래 형식으로 피드백을 보고하라. 이 보고가 없으면 작업 미완료로 간주한다.

## 피드백 보고 형식 (필수)

### 작업 요약
어떤 작업을 했는지 3~5줄로 요약한다.

### Nova 커맨드 사용 경험
- 잘 된 점: (사용한 커맨드와 효과)
- 불편했던 점: (구체적 상황과 기대와 다른 점)
- 안 먹힌 점: (커맨드가 반응하지 않거나 오작동한 경우)

### 아쉬운 기능
"이런 기능이 있었으면" 하는 점을 구체적으로 기술한다.

### 과잉/부족 개입 순간
Nova가 과도하게 개입하거나 부족했던 구체적 순간을 기술한다.

Phase 4: 결과 수집

각 서브에이전트의 보고를 수집하고, 다음 관점에서 분석한다:

마찰 포인트 분류

| 분류 | 설명 | 예시 | |------|------|------| | Blocker | Nova가 작업을 방해함 | 불필요한 Plan 강제, 과도한 검증 | | Missing | Nova에 없어서 아쉬운 기능 | 특정 시나리오 미지원 | | Friction | 되긴 하는데 불편함 | 커맨드 출력 과다, 판정 기준 모호 | | Positive | 잘 작동한 부분 | 확인된 강점, 유지할 것 |

P-레벨 분류

| 레벨 | 기준 | |------|------| | P0 | 2개+ 프로젝트에서 동일 마찰 발생, 또는 Blocker | | P1 | 1개 프로젝트에서 Blocker, 또는 2개+에서 Friction | | P2 | 단일 프로젝트 Friction, 또는 Missing 제안 |

Phase 5: 워크트리 정리

모든 서브에이전트 완료 후:

# 각 프로젝트별
cd {프로젝트_경로}
git worktree remove /tmp/nova-field-test-{프로젝트명}-{timestamp} --force
git branch -D nova-field-test-{timestamp}

정리 실패 시 수동 정리 명령을 사용자에게 안내한다.

Phase 6: 종합 리포트

━━━ Nova Field Test Report ━━━━━━━━━━━━━━━━━

테스트 프로젝트: {개수}개
서브에이전트 파견: {성공}/{총}

## P0 — 즉시 수정
- {마찰 포인트} ({발생 프로젝트들})

## P1 — 다음 릴리스
- {마찰 포인트} ({발생 프로젝트})

## P2 — 백로그
- {마찰 포인트}

## Positive — 유지
- {잘 작동한 점}

## 권장 다음 액션
- {구체적 개선 작업 목록}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

리포트 출력 후, 사용자가 원하면 P0 항목부터 바로 수정 작업에 돌입할 수 있다.

Input

$ARGUMENTS