연구 돌파구 발상

핵심 공식: 돌파구 = 기존 맥락 x 새로운 정보

이미 알고 있는 것(로컬 파일, 과거 실패, 확인된 사실)을 발굴하고, 새로운 발견(최신 논문, 코드, 인접 분야)과 결합하여 참신하고 실행 가능한 아이디어를 도출한다.

설계 원칙: 발견과 검증을 분리한다. 아이디어를 제안하는 에이전트와 그것을 반박하는 에이전트는 같은 인지 프레임에서 작동하면 안 된다.

아키텍처 개요

Phase 0: 의도 명확화 (브레인스토밍 게이트, HARD GATE)
    │   └── superpowers:brainstorming 통합 모드 (writing-plans 호출 차단)
    │
Phase 1: 로컬 스캔 (리더 직접 수행)
    │
Phase 2: 파동 A — 발견 (3개 서브에이전트 병렬)
    │   ├── 논문학자 (domain-scholar) ········ Sonnet
    │   ├── 영역횡단자 (cross-domain-scout) ·· Opus
    │   └── 구현사냥꾼 (implementation-hunter)  Codex
    │
Phase 3: 파동 B — 검증 (2개 서브에이전트 병렬)
    │   ├── 인용추적자 (citation-tracer) ······ Haiku
    │   └── 도메인현실검증자 (clinical-physics-realist) · Sonnet
    │
Phase 4: 종합 (리더, Opus)
    │
Phase 5: Codex 독립 검증
    │
최종 출력

입력

사용자가 (명시적 또는 암묵적으로) 제공하는 것:

• 문제: 구체적인 병목이나 질문
• 키워드: 2-5개 검색어 (모호하면 사용자와 함께 다듬기)
• 시도한 것: 실패한 접근법과 그 이유

"X에 대한 논문 찾아줘" 같은 모호한 요청이라도 전체 파이프라인을 실행한다 — 종합 단계에서 진짜 가치가 나온다.

Phase 0: 의도 명확화 (브레인스토밍 게이트)

이 단계는 HARD GATE다. 짧은 "X 논문 찾아줘" 요청이라도 진짜 알고 싶은 것과 결과물 형태를 먼저 확정해야 검색이 표적에 맞는다. 이 게이트가 없으면 literal request와 deeper need 사이의 간극에서 파이프라인이 길을 잃는다. CLAUDE.md "참고 문서 ≠ 확정 사양 — 넘겨짚기 금지" 원칙과 정합한다.

Phase 0-1: 컨텍스트 사전 확인 (리더 직접)

사용자에게 묻기 전에 리더가 다음을 읽는다 (병렬):

• CLAUDE.md (프로젝트 코드 수정 원칙)
• memory/MEMORY.md 및 사용자 키워드와 관련된 domain_*.md, *_analysis.md 파일
• 최근 커밋 (git log --oneline -10) — 사용자가 최근 어떤 실험·작업을 했는지 단서

이 사전 확인은 Phase 1 로컬 스캔의 얕은 미리보기에 해당하며, 사용자 질문에 더 구체적인 컨텍스트를 부여한다.

Phase 0-2: superpowers:brainstorming 통합 호출

Skill 도구로 superpowers:brainstorming을 호출하기 직전에, 다음 통합 오버라이드를 사용자와 모델 모두에게 텍스트로 명시한다:

brainstorming 통합 모드 (research-breakthrough Phase 0)

1. docs/superpowers/specs/에 design doc을 작성하지 않는다. 합의된 결과는 "검색 의도 브리프"로 본 스킬 컨텍스트에만 보존되어 Phase 1~5 전체 흐름의 입력으로 사용된다. 최종 결과물 (Obsidian breakthrough 문서 또는 메모리)에 통합된다.
2. writing-plans / superpowers:writing-plans를 호출하지 않는다. design 승인 게이트 통과 후 즉시 본 스킬의 Phase 1 (로컬 스캔) 으로 복귀한다.

보존되는 brainstorming 행동: 한 번에 한 질문(가능하면 객관식) / 2~3 대안 + 트레이드오프 / HARD GATE — 사용자 승인 없이는 Phase 1 로컬 스캔 진입 금지 / spec self-review.

Phase 0-3: 결정점 체크리스트 (research-breakthrough 전용)

brainstorming 진행 중 다음 결정점이 모두 다뤄져야 한다:

1. 진짜 알고 싶은 것 — 사용자 표현이 literal search ("최신 X 논문 5개")인지 deeper need ("이 문제를 풀 새 방법")인지 구분. 사용자가 후자를 원하면서 전자처럼 표현한 경우가 가장 흔한 함정이다.
2. 왜 알고 싶은가 — 결정용 (의사결정 입력) / 호기심 / 논문작성용 / build-plan의 R-spike. 목적에 따라 검증 강도가 달라진다.
3. 이미 해본 시도 + 실패 사유 — 중복 탐색 방지. 메모리/Obsidian에 이미 있는 자료는 다시 가져오지 않는다.
4. 검증 강도 — quick lit review (Phase 1 + 논문학자만) / standard (Phase 14) / full pipeline (Phase 15 전체, Codex 독립 검증 포함).
5. 인접 분야 탐색 허용 여부 — strictly own domain / cross-domain (영역횡단자 풀가동). 사용자가 "본 도메인만"이라고 명시하지 않는 한 cross-domain은 기본 ON.
6. 결과물 형태 — 논문 list (5개 + 1줄 요약) / breakthrough idea (메커니즘 + 첫 실험) / next experiment design (구체 파라미터 포함) / Obsidian 저장 여부.
7. 시간/토큰 제약 — 사용자가 "빠르게"라고 했는가, 아니면 "철저하게"라고 했는가.

Phase 0-4: 검색 의도 브리프 정리 및 사용자 승인

brainstorming 종료 시점에 다음 형식으로 사용자에게 보여준다:

## 검색 의도 브리프 (research-breakthrough)
- 진짜 알고 싶은 것: {literal vs deeper, 1-2문장}
- 왜: {결정용 / 호기심 / 논문 / R-spike}
- 이미 해본 시도: {목록 — 중복 탐색 회피}
- 검증 강도: {quick / standard / full pipeline}
- 인접 분야 탐색: {ON / OFF + 허용 분야 목록}
- 결과물 형태: {paper list / breakthrough idea / experiment design + Obsidian 저장 YES/NO}
- 검색 키워드 (정제됨): {kw1, kw2, ...}

사용자에게 묻는다: "이 검색 의도 브리프대로 Phase 1 (로컬 스캔)으로 진행해도 될까요?" 승인 있어야만 Phase 1로 진입한다. 승인 없이 진행 금지.

Phase 0-5: 검색 의도 브리프 보존

검색 의도 브리프는:

• Phase 1 로컬 스캔의 키워드/범위 제약으로 사용된다
• Phase 2 파동 A 서브에이전트 프롬프트의 맥락 브리프에 명시적으로 포함된다 (검증 강도, 인접 분야 ON/OFF 등)
• Phase 4 종합 단계에서 결과물 형태(paper list vs breakthrough idea)에 따라 출력 구조가 달라진다
• Phase 4의 최종 출력 상단에 그대로 포함된다

Phase 1: 로컬 스캔

리더가 직접 수행한다. 다음 읽기를 병렬로 실행하여 빠르게 맥락을 구축한다.

프로젝트 메모리

memory/MEMORY.md + 도메인별 토픽 파일을 읽는다. 추출 대상: 확인된 사실, 실패한 방법, 열린 질문.

Obsidian 볼트 (접근 가능 시)

Grep pattern="{keyword}" path="{/path/to/obsidian-vault}" (files_with_matches)

주요 볼트 영역:

• {domain notes folder}/ — 기술 도메인 노트
• {summary folder}/ — 정리 노트

상위 매칭 파일을 읽는다. 추출 대상: 기존 연구, 확인된 결과, 막다른 길.

논문 아카이브 (MD 요약 존재 시)

Glob pattern="**/*.md" path="{/path/to/paper-archive}"

로컬 소스에 접근 불가 시 (경로 없음, 권한 거부) 해당 소스를 건너뛰고 무엇을 건너뛰었는지 기록한다 — 전체 단계를 실패시키지 않는다.

Phase 1 출력: 맥락 브리프

Phase 1 결과를 다음 구조로 정리한다. 이 브리프는 모든 서브에이전트의 프롬프트에 포함된다.

## 맥락 브리프
- 확인된 사실: (우리가 아는 것)
- 확인된 실패: (시도했으나 실패한 것 + 이유)
- 열린 질문: (아직 모르는 것)
- 검색 키워드: {kw1}, {kw2}, ...

Phase 2: 파동 A — 발견

3개 서브에이전트를 동시에 spawn한다. 각 에이전트는 서로 다른 관점에서 검색하며, 리더에게만 결과를 보고한다.

서브에이전트 spawn 방법

단일 메시지에서 3개의 Agent 도구 호출을 병렬로 발행한다:

Agent(
  description: "논문학자 — 본 도메인 논문 검색",
  subagent_type: "general-purpose",
  model: "sonnet",
  prompt: "{논문학자 프롬프트}"
)

Agent(
  description: "영역횡단자 — 인접 분야 탐색",
  subagent_type: "general-purpose",
  model: "claude-opus-4-7",
  prompt: "{영역횡단자 프롬프트}"
)

Agent(
  description: "구현사냥꾼 — 코드 검증",
  subagent_type: "codex:codex-rescue",  # Codex 활용
  prompt: "{구현사냥꾼 프롬프트}"
)

페르소나 1: 논문학자 (domain-scholar)

모델: Sonnet (구조화된 문헌 분류 작업, Opus 불필요)

역할: 사용자 문제의 정확한 도메인에서 최신·최강 논문을 찾는다.

프롬프트 템플릿:

너는 "논문학자"다. 특정 기술 도메인의 최신 학술 논문을 깊이 있게 탐색하는 전문가다.

{맥락 브리프}

## 임무
사용자 문제와 직접 관련된 최신 논문을 찾아라.
- SOTA(최첨단) 지도: 현재 어디까지 왔는가
- 미해결 격차: 아직 풀리지 않은 것
- 반복되는 한계: 여러 논문에서 공통적으로 보고하는 제약

## 검색 방법
1. ArXiv API로 관련 논문 검색:
   WebFetch: https://export.arxiv.org/api/query?search_query=all:{kw1}+AND+{kw2}&start=0&max_results=8&sortBy=relevance

2. 상위 3-5개 논문의 전문을 ar5iv로 읽기:
   WebFetch: https://ar5iv.org/html/{arxiv_id}
   (실패 시 https://arxiv.org/abs/{arxiv_id})

3. Semantic Scholar로 보완 검색:
   WebFetch: https://api.semanticscholar.org/graph/v1/paper/search?query={keywords}&fields=title,abstract,year,citationCount&limit=8

## 출력 형식
각 논문에 대해:
- 제목 + arxiv ID + 연도
- 핵심 기여 (1-2문장)
- 우리 문제와의 연결점
- 한계 또는 열린 질문

최종적으로 "SOTA 지도"를 1단락으로 요약하라.

페르소나 2: 영역횡단자 (cross-domain-scout)

모델: Opus (유용한 유추 vs 얕은 비유를 판단하는 것이 가장 어려운 추론 작업)

역할: 같은 근본 문제를 다른 분야에서 이미 풀었는지 탐색한다. 돌파구는 대부분 여기에서 나온다.

프롬프트 템플릿:

너는 "영역횡단자"다. 인접 분야에서 동일한 근본 문제에 대한 해결책을 찾는 전문가다.

{맥락 브리프}

## 임무
사용자의 문제를 추상화하여 근본적인 수학적/물리적 구조를 파악하고,
다른 분야에서 같은 구조의 문제가 어떻게 풀렸는지 찾아라.

핵심 질문: "이 분야에서는 아무도 시도하지 않은 것 같은데, 저 분야에서는 이미 작동하고 있다"

## 검색할 인접 분야
| 사용자 도메인 | 탐색할 인접 분야 |
|---|---|
| CT 재구성 | MRI 재구성, 전파천문학, 지진 영상, 계산사진학, 신경 렌더링 |
| 딥러닝 아키텍처 | 신호처리, 통계학, 신경과학, 플러그앤플레이 방법 |
| 이미지 품질 / SR | 광학, 센서 설계, 압축 센싱, 확산 사전 |
| 의료 영상 | 위성 영상, 산업 검사, cryo-ET, PET/SPECT |
| 손실 함수 | 정보 이론, 지각 심리학, 자기지도 학습 |

최소 2개 인접 분야를 검색하라.

## 검색 방법
1. WebSearch로 인접 분야 + 핵심 기법 검색
2. ArXiv에서 인접 분야 키워드로 검색
3. 유망한 논문의 전문을 ar5iv로 읽기

## 출력 형식
각 교차 도메인 발견에 대해:
- 원래 분야 + 논문/방법
- 어떤 근본 문제를 풀고 있는가
- 사용자 도메인에 전이 가능한 메커니즘
- 전이 시 주의점 (도메인 차이로 인한 제약)

"아무도 시도하지 않은 것 같다"는 발견에 특히 주목하라.

페르소나 3: 구현사냥꾼 (implementation-hunter) — Codex

모델: Codex (GPT-5.x, 코드 읽기·환경 판단에 특화)

역할: 논문의 주장이 실제 코드로 재현 가능한지 검증한다. 실행 가능한 레포를 찾고, 코드 품질·재현성을 평가한다.

호출 방법: /codex:rescue 스킬을 통해 Codex에 위임한다.

/codex:rescue --wait --effort high

다음 연구 주제와 관련된 GitHub 구현체를 찾고 평가하라:

문제: {사용자 문제}
키워드: {검색 키워드}

## 검색 대상
1. GitHub에서 관련 논문의 공식 구현체
2. 커뮤니티 재구현 (stars, forks, 최근 커밋 확인)
3. 관련 프레임워크/라이브러리
4. 사전학습 모델 가용성

## 각 레포에 대해 평가
- 코드 건강성: 의존성, CUDA 가정, Python 버전
- 재현성: README 품질, 데이터셋 요구사항, 실행 가능 여부
- 논문 주장 vs 실제: 코드가 논문의 주장을 뒷받침하는가
- 실험 비용: GPU 시간, 데이터셋 크기, 이번 주에 테스트 가능한가
- 라이선스: 상업적 사용 가능 여부

## 출력 형식
각 레포에 대해:
- 레포 URL + stars/forks + 마지막 커밋
- 실행 가능성 점수 (상/중/하)
- 핵심 의존성 + 알려진 문제점
- "이번 주에 첫 실험 가능한가?" (예/아니오 + 이유)

파동 A 최소 기준

• 논문학자: 최소 5개 관련 논문 + SOTA 지도
• 영역횡단자: 최소 2개 인접 분야에서 각 1개 이상 전이 가능한 발견
• 구현사냥꾼: 최소 3개 레포 평가

Phase 3: 파동 B — 검증

파동 A의 3개 에이전트가 모두 완료된 후, 그 결과를 입력으로 받아 2개 검증 에이전트를 동시에 spawn한다.

파동 B 에이전트의 프롬프트에는 맥락 브리프 + 파동 A 전체 결과를 포함한다.

Agent(
  description: "인용추적자 — 신뢰성 검증",
  subagent_type: "general-purpose",
  model: "haiku",
  prompt: "{인용추적자 프롬프트}"
)

Agent(
  description: "도메인현실검증자 — 도메인 현실성 검증",
  subagent_type: "general-purpose",
  model: "sonnet",
  prompt: "{도메인현실검증자 프롬프트}"
)

페르소나 4: 인용추적자 (citation-tracer)

모델: Haiku (메타데이터·그래프 추적 위주, 고급 추론 불필요)

역할: 파동 A에서 발견된 논문/방법의 신뢰성을 검증한다. "이거 정말 믿을 만한가?"에 답한다.

프롬프트 템플릿:

너는 "인용추적자"다. 학술 논문의 신뢰성과 참신성을 검증하는 전문가다.

{맥락 브리프}

## 파동 A 결과
{논문학자 결과}
{영역횡단자 결과}
{구현사냥꾼 결과}

## 임무
파동 A에서 발견된 모든 논문/방법에 대해 다음을 검증하라:

1. **인용 신뢰도**: Semantic Scholar에서 인용 수, 인용 추세, 자기인용 비율 확인
   WebFetch: https://api.semanticscholar.org/graph/v1/paper/search?query={title}&fields=title,citationCount,year
   핵심 논문의 참고문헌 추적:
   WebFetch: https://api.semanticscholar.org/graph/v1/paper/{S2PaperId}/references?fields=title,abstract,year&limit=10

2. **참신성**: "이미 다른 사람이 했다"는 선행 연구가 있는가?
3. **재현 기록**: 후속 연구에서 재현 성공/실패 보고가 있는가?
4. **인용 고립도**: 이 논문이 고립된 섬인가, 활발한 연구 흐름의 일부인가?
5. **모순 증거**: 반대 결과를 보고한 논문이 있는가?

## 출력 형식
각 논문/방법에 대해:
- 증거 등급: A(강력) / B(보통) / C(약함) / D(의심)
- 근거: 인용 수, 후속 연구, 재현 기록
- 경고: 특이사항 (인용 수 극히 낮음, 자기인용만, 재현 실패 보고 등)

페르소나 5: 도메인현실검증자 (domain-realist)

모델: Sonnet (도메인 현실성 + 적대적 판단)

역할: 파동 A의 발견이 실제 도메인 제약(데이터, 환경, 비용, 물리적 한계)에서 살아남을 수 있는지 검증한다. 매력적이지만 실행 불가능한 아이디어를 조기에 제거한다.

프롬프트 템플릿:

너는 "도메인현실검증자"다. 사용자의 도메인에서 실제로 통용되는 제약과 현실을
엄격하게 적용하여 연구 아이디어의 실행 가능성을 판단하는 적대적 검토자다.

{맥락 브리프}

## 파동 A 결과
{논문학자 결과}
{영역횡단자 결과}
{구현사냥꾼 결과}

## 임무
파동 A의 각 발견/제안에 대해 다음 체크리스트를 적용하라:

### 데이터/입력 현실성
- 이 방법이 요구하는 입력 데이터가 실제로 가용한가?
- 데이터 취득 비용·조건이 현실적인가?
- 노이즈, 결측값, 분포 편이를 고려했는가?

### 도메인 제약 충족
- 해당 분야의 핵심 불변 조건(물리 법칙, 규정, 인터페이스 계약 등)을 위반하지 않는가?
- 기존 시스템/파이프라인과 통합 가능한가?
- 도메인 전문가가 수용할 수 있는 결과물인가?

### 벤치마크 현실성
- 강한 baseline과 공정하게 비교했는가?
- 데이터셋 누수(leakage) 가능성은?
- 시뮬레이션만인가, 실제 환경에서도 검증했는가?
- 평가 지표가 실질적 성능을 반영하는가?

## 출력 형식
각 발견에 대해:
- 실행 가능성: 가능 / 조건부 가능 / 불가능
- 핵심 우려: 가장 큰 도메인 현실 장벽
- 조건: "만약 X가 해결되면 가능하다"
- 개선 제안: 이 장벽을 어떻게 우회할 수 있는가

파동 B 최소 기준

• 인용추적자: 파동 A의 모든 핵심 논문에 증거 등급 부여
• 도메인현실검증자: 파동 A의 모든 제안에 실행 가능성 판정

Phase 4: 종합

리더(Opus)가 Phase 1~3의 모든 결과를 종합하여 돌파구 아이디어를 생성한다.

종합 원칙

• 단순 나열 금지 — 로컬 맥락과 새 발견의 교차점에서 아이디어를 만든다
• 인용추적자가 C/D 등급을 준 논문에 기반한 아이디어는 해당 위험을 명시한다
• 도메인현실검증자가 "불가능" 판정한 아이디어는 제외하거나 조건부로 포함한다
• 최고의 아이디어는 로컬에서 실패한 것 + 왜 실패했는지를 해결하는 새 기법의 조합이다

아이디어 구조

각 아이디어 (목표 3개, 영향력 x 실현 가능성으로 순위):

아이디어 N: [설명적 이름]

Phase 5: Codex 독립 검증

Phase 4의 종합 결과를 Codex에 전달하여 독립적 적대적 검증을 수행한다. Claude의 추론 과정은 전달하지 않고, 최종 아이디어와 증거만 전달한다.

모델 다양성이 핵심 — 같은 모델의 두 번째 패스보다 다른 모델의 독립 판단이 더 가치있다.

Codex 호출

/codex:rescue --wait --effort high

다음 3개의 연구 돌파구 아이디어를 독립적으로 검증하라.
너는 이 아이디어를 처음 보는 것이다. 편견 없이 평가하라.

## 아이디어
{Phase 4에서 생성된 3개 아이디어 — 메커니즘, 출처, 증거만 포함}

## 각 아이디어에 대해 공격할 것
1. **참신성**: 이미 누군가 했는가? 선행 연구를 놓쳤는가?
2. **실현 가능성**: 첫 실험이 정말 가능한가? 숨겨진 전제 조건은?
3. **논리적 약점**: 메커니즘의 논리에 결함이 있는가?
4. **누락된 인용**: 중요한데 빠진 참고문헌이 있는가?
5. **첫 실험 설계**: 제안된 실험 계획이 이 아이디어를 실제로 검증할 수 있는가?

## 출력 형식
각 아이디어에 대해:
- 판정: 유지 / 수정 필요 / 폐기
- 공격 요약: 가장 강력한 반론 1-2개
- 놓친 것: 추가로 확인해야 할 사항
- 개선안: (수정 필요인 경우) 구체적 수정 방향

Codex 결과 통합

Codex 검증 결과에 따라 최종 아이디어를 조정한다:

• 유지: 그대로 최종 출력에 포함
• 수정 필요: Codex의 개선안을 반영하여 아이디어 수정
• 폐기: 최종 출력에서 제외하고, "폐기된 아이디어" 섹션에 폐기 사유와 함께 기록

최종 출력 형식

1. 로컬 맥락 — 확인된 사실 + 확인된 실패 (각 2-3개 항목)
2. 파동 A 요약 — 각 페르소나가 찾은 핵심 발견 (1-2줄씩)
3. 파동 B 요약 — 인용추적자의 증거 등급 + 도메인현실검증자의 핵심 판정
4. 새 리소스 — 상위 5개 논문/저장소, 1줄 요약 + 링크 + 증거 등급
5. 돌파구 아이디어 — 상위 3개, 위 테이블 구조에 따라 (Codex 검증 결과 반영)
6. 폐기된 아이디어 — Codex 또는 도메인현실검증자에 의해 제거된 아이디어 + 사유 (뭘 시도하면 안 되는지 기록)
7. 다음 실험 — 가장 실행 가능한 단일 단계, 구체적 파라미터 포함 (모델 설정, 하이퍼파라미터, 예상 결과)

품질 게이트

• 각 아이디어는 구체적 출처를 인용해야 한다 ("어떤 논문에서 제안..." 금지)
• 아이디어는 서로 의미 있게 달라야 한다
• "다음 실험"은 즉시 실행할 수 있을 만큼 구체적이어야 한다
• 사용자의 문제가 잘 알려진 것이면, 참신한 제안 전에 기존 해결책을 먼저 인정한다
• 최소 1개 아이디어는 영역횡단자의 교차 도메인 발견에 기반해야 한다
• 인용추적자 등급이 D인 논문에만 의존하는 아이디어는 포함하지 않는다
• "폐기된 아이디어" 섹션이 비어 있으면 검증이 충분히 엄격하지 않았다는 신호다

결과 저장 (선택)

종합 후 저장 제안:

• Obsidian: {/path/to/obsidian-vault}/{domain}/{YYYY-MM-DD}_{topic}_breakthrough.md
  • 상단에 #CLAUDE 태그 추가 (이 볼트의 Claude 생성 파일 필수 태그)
  • 폐기된 아이디어 섹션 포함 (미래 참고용으로 가치있다)
  • 새 파일로만 생성 (기존 파일 수정 금지)
• 프로젝트 메모리: 발견이 현재 프로젝트와 관련 있으면, 핵심 인사이트를 토픽 메모리 파일에 저장 제안