Nova 진화 제안 — 탐색 품질 강화 (2026-04-24 meshcore_db 사후 분석)

[givepro91]

배경

2026-04-24 외부 프로젝트(meshcore_db) 세션 사후 분석에서 Nova 룰 우회 문제가 보고됨.
한 세션에서 --emergency 4회, Plan 미수립, Evaluator 1회만 실행.
결과적으로 사전 예방되지 못한 실수 4건:

1. docs/schema/auto/*.md가 Staging 기준임을 독자가 모르고 PROD 복제 설계에 사용 → 재작업
2. pg_dump 결과 sed 's/public\./gis./g' 전역 치환이 PostGIS 타입 참조까지 변경 → 3 테이블 DDL 실패
3. VPC peering 유무·NAT 확인 없이 FDW 설계 → Phase 전면 블록
4. restart_mkdocs.sh 실행만으로 DataLab 반영된다고 가정(실제로는 React SPA 별도 배포) → 사용자 사이트 404

외부 진단 (원본)

Agent 회피의 구조적 원인으로 6가지 제시:

원인	현상	Agent가 회피하는 이유
탐색적 대화 모드 부재	Plan은 "결정 확정" 전제, 실제 세션은 결정 변화 빈번	Plan 유지 비용 → 절차 건너뛰는 게 rational
Hard Gate 획일성	문서 전용 변경에도 Evaluator PASS 강제	정상 우회 경로 없음 → --emergency 남용
파일 수 기준 경직성	3파일+ = 무조건 Plan (md/py 동일 취급)	리스크 낮은 변경에도 Plan 부담
--emergency 이분법	정상/긴급 둘뿐	"편의 우회"로 변질, 남용 감지 불가
사전 실측 강제 없음	"RDS 생성" 등 키워드 감지 시 자동 체크리스트 없음	docs만 믿고 설계 진행
배포 경로 신뢰 부재	구버전 스크립트와 새 배포 경로 공존	파일명으로 임의 판단

제안된 개선 (원본 P0~P2)

• P0.1 /nova:explore 탐색 모드 신설
• P0.2 커밋 파일 셋 분류 기반 차등 Hard Gate (docs-only / full / infra)
• P0.3 --emergency 4분화 + 사용 이력 추적
• P1.4 복잡도 점수 자동 계산 (비가역 +3, DB +1, 외부 연결 +2, UI +1)
• P1.5 키워드 기반 사전 실측 체크리스트 (새 RDS/FDW/peering/DNS/스키마 복제)
• P1.6 배포 경로 단일 진입점 강제 + 구식 스크립트 경고
• P2.7 Incidents DB (docs/nova-incidents/{YYYY-MM-DD}-{slug}.md)
• P2.8 대화 중 미니 Plan 자동 제안

내부 토론에서 나온 관점 (가정/추론 단계)

1. /nova:explore 신설은 과한 것일 수 있음

• 기본 Claude Code 대화 자체가 이미 탐색
• 별도 커맨드 신설 시 "탐색인지 아닌지" 선언 부담 추가
• 진짜 문제는 탐색 → 구현 전환 타이밍이 아닌가 (P2.8 "미니 Plan 자동 제안"과 같은 메커니즘)

2. "탐색 품질" 자체가 근본 문제일 가능성

사용자 의견: "이번 문제(DB 타입 불일치 등)는 탐색을 제대로 못한 것 아닌가"

• 실수 4건 공통 패턴: "확인 가능한 것을 확인하지 않고 진행"
• 전부 1~3개 tool call이면 검증 가능했던 사안
• 토큰/모델 한계보단 탐색 방법론 부재로 보임

3. 가정 레지스터 아이디어 (미검증)

탐색 중 Agent가 사용하는 가정을 명시적으로 추적, 비가역 작업 전 미검증 가정 차단하는 방식 — 내부 토론 중 떠올랐으나 검증 전.

레퍼런스 조사 (현역 오픈소스/표준, 2025~2026)

같은 문제를 다루는 기존 패턴:

레퍼런스	핵심 패턴	관련성
Cline Plan/Act Mode	Plan mode는 read-only 탐색, Act mode로 명시적 토글 후 실행	★★★ 탐색/실행 격리
systematic-debugging skill	Investigation → Analysis → Hypothesis → Implementation 4단계. "NO FIXES WITHOUT ROOT CAUSE FIRST". 성공률 40%→95%	★★★ 가정/검증 방법론
Ultra Plan — 3 Explorers + 1 Critic	병렬 탐색 agent 3 + 비평 1 (Anthropic 공식)	★★★ deepplan과 유사
Claude Code Explore subagent	built-in, thoroughness 3단계 조절	★★ 이미 활용 가능
Agent Skills 표준 (2025.12)	progressive disclosure, hot-reloading	Nova 스킬 기반 표준
Addy Osmani LLM workflow 2026	Specs, skills, MCPs, small chunks, always review, AI-on-AI reviews	업계 합의 방향

업계 합의

• 이번 실수는 모델 한계 아님. 실측 명령 몇 줄이면 해결됐을 사안.
• Cline, Anthropic, Addy Osmani 모두 "AI는 pair programmer, autonomous judgment 아님" 명시.
• 탐색을 격리·강제하는 구조가 해법이라는 합의.

현재 상태

모든 제안이 아직 가정/추론 단계. 구현 전 추가 검증 필요:

• 원본 제안서의 측정 기준(주당 --emergency 5→1회 등)이 Nova 텔레메트리로 검증 가능한가
• Cline Plan/Act 패턴이 Claude Code 환경에서 /nova:plan 활성 시 read-only 강제로 실제 구현 가능한가
• systematic-debugging skill 흡수/fork 시 Nova 스킬 철학과 정합성
• P1.4 복잡도 점수 가중치를 실제 세션 데이터 없이 정할 때 gaming 리스크
• P2.7 Incidents DB의 유사 상황 매칭 기준 (소음 누적 방지)

다음 단계 후보 (결정 안 됨)

1. 최소 실험: P0.2 차등 게이트만 먼저 1~2주 운영, 효과 측정 후 확장
2. 전체 P0 묶음: explore + 차등 게이트 + emergency 4분화 한 릴리스
3. 레퍼런스 흡수 우선: Cline Plan/Act, systematic-debugging 패턴을 Nova 스킬로 먼저 채택
4. /nova:evolve 사이클: 본 이슈를 근거로 Plan → Design → 구현 사이클에 태움

참고

• 외부 진단 출처: meshcore_db 프로젝트 (2026-04-24 세션)
• 토론 맥락: Opus 4.7 세션 (2026-04-24)

[givepro91]

추가 관찰 — Memory 남용 구조 (2026-04-24 실사 기반)

본 이슈 논의 중 발견한 별도 문제: Claude auto-memory가 프로젝트 차원 지식을 로컬에 가둬 팀 공유를 막는다.

구조 측면 — 잘 되어있는 것

레포에 팀 공유 지식 구조가 이미 존재:

docs/
├── nova-rules.md              # 규칙 소스
├── nova-antipatterns.md       # 안티패턴 축적용
├── context-chain.md
├── rules-changelog.md
├── decisions/ designs/ plans/ proposals/ verifications/
NOVA-STATE.md                  # 세션 간 맥락 (레포 안)
hooks/session-start.sh          # 팀 전체 주입

NOVA-STATE.md를 레포에, nova-antipatterns.md를 docs/에 둔 것 — 팀 공유 전제가 설계에 들어가 있음.

운영 측면 — 새고 있는 것

~/.claude/projects/-Users-jay-develop-nova/memory/ 실사 결과, 프로젝트 차원 지식이 로컬에 남아 있음:

파일	원래 가야 할 곳
project_evolve_github_actions.md	docs/proposals/ 또는 GitHub Issue
feedback_nova_bypass_patterns.md	docs/nova-antipatterns.md에 병합
feedback_skill_contract_enforcement.md	마찬가지 (안티패턴)
feedback_evaluator_validated.md	docs/decisions/ (ADR 성격)

→ 다른 팀원이 Nova 레포에서 Claude를 돌리면 이 맥락을 전혀 모름. 같은 우회 패턴·같은 실수를 반복할 조건.

그리고 본 이슈 P2.7 Incidents DB (docs/nova-incidents/) 는 실사 결과 미구현 (ls 로 부재 확인). 실수 자동 축적 경로가 레포에 없으니 memory로 흘러가는 게 자연스러운 결과.

원인 (구조적)

1. Claude auto-memory 시스템 프롬프트가 project 타입 저장을 적극 독려
2. memory 파일 쓰기 < CLAUDE.md 수정 < PR/Issue — 저항이 가장 낮은 경로 선택
3. "에이전트의 기억" ↔ "프로젝트 기억" 혼동

요약

항목	상태
레포 기반 지식 구조	✓ 있음
memory → 레포 이전 규칙	✗ 없음 (사람이 판단해야)
Incidents 자동 축적 경로	✗ 미구현 (P2.7)
기존 memory의 project/feedback 성격	✗ 일부 로컬에 갇힘

개선 후보

• memory 쓰기 가드 훅: project_*, feedback_* 저장 시 "레포 후보 경로" 자동 제안 (docs/nova-antipatterns.md, docs/proposals/, Issue)
• P2.7 Incidents DB 우선 구현: memory로 흘러가는 가장 큰 카테고리(실수·회고) 흡수
• 기존 로컬 memory 마이그레이션: 위 4개 파일부터 레포로 이전

본 이슈와 같은 뿌리(프로젝트 지식의 구조적 관리)이므로 함께 검토.