---
name: cross-verified-research
description: "교차 검증 리서치: 최소 5회 검색 + 5개 소스 교차검증으로 환각 방지, 90% 신뢰도 게이트 적용"
triggers:
  - "cross-verify"
  - "교차검증"
  - "교차 검증"
usage: "/cross-verified-research <리서치 주제>"
---

# Cross-Verified Research 스킬

> 이 스킬은 프레이야(프론트엔드 개발자)가 주어진 주제를 체계적으로 리서치하고, 교차 검증을 통해 환각을 방지하며, 신뢰도 게이트를 통과한 정보만을 결과로 제공하는 절차를 정의한다.

---

## 적용 범위 (작업 레벨 시스템 연동)

작업 레벨 기준: `memory/specs/work-level-system.md` 참조

| 작업 레벨 | 적용 여부 | 비고 |
|---------|---------|------|
| **Lv.3 이상** | **의무 적용** | 아키텍처 결정, 주요 기술 선택, 비즈니스 임팩트 큰 작업 |
| **Lv.1 ~ 2** | 선택 적용 | 빠른 참조, 단순 확인 작업 |

Lv.3+ 작업에서 교차 검증 없이 단일 소스 인용은 환각 위험으로 간주한다.

---

## 6개 절대 규칙

이 규칙 중 하나라도 위반하면 리서치 결과를 출력하지 않는다:

1. **소스 조작 금지**: URL, 저자명, 출판일 위조 또는 변형 절대 금지
2. **90% 신뢰도 게이트**: 교차 검증 소스 간 일치율이 90% 미만이면 "검증 불충분" 판정 후 추가 검색
3. **추측 언어 금지**: "아마도", "~인 것 같다", "추측컨대" 표현 사용 금지. 불확실한 경우 명시적으로 "미확인" 표기
4. **BLUF 형식 필수**: Bottom Line Up Front — 결론부터 제시, 근거는 후술
5. **최소 5회 검색 + 5개 검증 소스**: 단일 소스 결론 도출 절대 금지
6. **교차 검증 의무**: 동일 사실을 독립적인 2개 이상의 Tier A/S 소스에서 확인해야 사실로 인정

---

## 소스 등급 체계

### Tier S (최고 신뢰도)
- 학술 논문 (동료 심사 완료)
- IEEE, ACM, Nature, arXiv (preprint 명시)
- 국제 표준 기구 문서 (W3C, IETF, ISO)

### Tier A (높은 신뢰도)
- 정부 기관 공식 문서
- 대학/연구소 공식 보고서 (.edu, .ac 도메인)
- 메이저 오픈소스 프로젝트 공식 문서 (MDN, React, TypeScript 공식 docs)
- 주요 기술 기업 공식 엔지니어링 블로그 (Vercel, Google Developers 등)

### Tier B (보통 신뢰도)
- 신뢰할 수 있는 테크 미디어 (Stack Overflow, Dev.to 상위 랭킹)
- GitHub Issues/PR 공식 논의
- 커뮤니티 위키 (교차 검증 필수)

### Tier C (낮은 신뢰도 — 단독 인용 금지)
- 소셜 미디어 게시물 (Twitter/X, LinkedIn)
- 무서명 블로그, 개인 포럼 게시글
- 날짜 미확인 문서, 업데이트 이력 없는 페이지

**규칙**: Tier C 소스는 단독 인용 불가. 반드시 Tier A/S 소스로 교차 검증 필수.

---

## 4단계 실행 파이프라인

### Stage 1: Deconstruct (주제 분해)
```
목적: 리서치 주제를 검색 가능한 하위 질문으로 분해한다.

출력:
- 핵심 질문 목록 (최소 3개, 최대 7개)
- 검색 키워드 조합
- 예상 소스 유형 (어떤 Tier를 우선 탐색할지)
- 범위 제한 (이번 리서치에서 다루지 않을 것)
```

## 검색 깊이 조절 (Scaled Effort)

질문 범위에 따라 검색 깊이를 조절한다. 모든 리서치에 동일한 노력을 투입하는 것은 비효율적이다.

- **좁은 사실 확인** (단일 사실, 날짜, 스펙): 검색 2-3회, 소스 2개 이상
- **기술 비교** (A vs B): 검색 5회 이상, 소스 5개 이상 (기본값)
- **광범위 조사** (시장 분석, 최신 기술 동향): 검색 8회 이상, 소스 8개 이상

범위 불명확 시 상위 등급으로 기본 설정한다.

**독립 소스 판별 기준**: 두 문서가 동일한 원본(보도자료, 블로그, 연구)을 인용하면 1개 소스로 카운트한다. 원본까지 추적하여 독립성을 확인한다.

---

### Stage 2: Search & Collect (검색 및 수집)
```
최소 5회 독립 검색 실행:

검색 1: <키워드 조합 1>  → 소스: <URL/제목>, Tier: <등급>
검색 2: <키워드 조합 2>  → 소스: <URL/제목>, Tier: <등급>
검색 3: <키워드 조합 3>  → 소스: <URL/제목>, Tier: <등급>
검색 4: <반론/대안 관점 검색> → 소스: <URL/제목>, Tier: <등급>
검색 5: <최신 업데이트 확인> → 소스: <URL/제목>, Tier: <등급>

수집 기준:
- Tier S/A 소스 최소 3개 이상 포함
- 검색 날짜 및 소스 최종 업데이트 날짜 기록
- 상충하는 정보 발견 시 별도 플래그 처리
```

### Stage 3: Cross-Verify (교차 검증)
```
검증 매트릭스:
- 수집된 각 핵심 주장에 대해 동의/반박 소스 목록 작성
- 일치율 계산: (동의 소스 수 / 전체 소스 수) × 100

판정:
- 일치율 90% 이상 → 사실로 인정, 출력 가능
- 일치율 70~89% → "높은 개연성" 표기 후 출력
- 일치율 70% 미만 → 추가 검색 실행 (Stage 2 반복) 또는 "검증 불충분" 판정

상충 정보 처리:
- 두 Tier A 소스가 상충 → 양측 입장 모두 출력, 판단 유보
- Tier S vs Tier B 상충 → Tier S 우선, Tier B 견해 별도 명시
```

### Stage 4: Synthesize (BLUF 합성)
```
BLUF (결론 먼저):
→ <핵심 결론 1~2문장>

근거:
- [Tier S/A] <소스명>: <지지하는 내용>
- [Tier S/A] <소스명>: <지지하는 내용>
- [Tier B] <소스명>: <보조 정보>

미확인/불확실:
- <검증 불충분한 항목>: 미확인 (추가 조사 필요)

신뢰도 요약:
- 핵심 주장 신뢰도: <일치율>%
- 검색 횟수: <N>회
- 사용 소스: <N>개 (Tier S: N, Tier A: N, Tier B: N, Tier C: N)
```

---

## Telegram 출력 최적화

Telegram 환경에서는 목록 기반 출력을 사용한다.

**단계 분할 규칙:**
- Stage 1~2 결과는 요약만 출력 (검색 과정 로그는 요청 시에만 상세 출력)
- Stage 3 교차 검증 결과는 별도 메시지로 분리
- Stage 4 최종 합성만 기본 출력 (나머지는 "상세 보기" 요청 시)
- 소스 목록이 5개 초과 시 Tier S/A만 기본 노출, Tier B/C는 접어서 "추가 소스 N개" 안내

**Telegram 출력 형식 예시:**
```
[Cross-Verified Research]
주제: <리서치 주제>

결론 (BLUF):
<핵심 결론 1~2문장>

주요 소스:
- [Tier S] <소스명>
- [Tier A] <소스명>
- [Tier A] <소스명>

신뢰도: <N>% | 검색 <N>회 | 소스 <N>개

미확인: <있으면 명시, 없으면 생략>

→ 상세 근거 보려면 "상세" 입력
```

---

## 환각 방지 게이트

다음 상황에서는 출력을 중단하고 경고를 발행한다:

- 검색 횟수 5회 미만인 상태로 결론 도출 시도
- Tier A/S 소스 3개 미만으로 결론 도출 시도
- 교차 검증 없이 단일 소스 인용
- "아마도", "~것 같다" 등 추측 언어 사용

경고 형식:
```
[환각 방지 게이트 작동]
사유: <위반 규칙>
조치: <추가 검색 또는 "검증 불충분" 판정>
```

---

## 빠른 참조

- **적용 기준**: Lv.3+ 의무 / Lv.1~2 선택 (`memory/specs/work-level-system.md`)
- **소스 등급**: Tier S > Tier A > Tier B > Tier C
- **신뢰도 게이트**: 90% 이상 = 사실, 70~89% = 개연성, 70% 미만 = 검증 불충분
- **최소 요건**: 검색 5회 + 검증 소스 5개 + Tier A/S 3개 이상
- **BLUF**: 결론 먼저, 근거 후술

---

## 품질 기준 (Quality Calibration)

### BAD 예시 (이렇게 하지 말 것)
```
리서치 주제: Rust가 Go보다 웹 서버에 빠른가?

결론 (BLUF): Rust는 제로 코스트 추상화 덕분에 일반적으로 Go보다 빠릅니다.

주요 근거:
- [Tier A] Rust가 2-5배 빠름
- [Tier A] Rust가 메모리 50% 적게 사용
```

문제점:
- 소스 URL 없음 — 추적 불가능
- "2-5배 빠름"을 1개 소스만으로 "검증됨" 처리
- 뉘앙스 있는 주제에서 반론 섹션 부재
- 내부 지식을 가짜 인용으로 포장

### GOOD 예시 (이 수준을 목표)
```
리서치 주제: Rust가 Go보다 웹 서버에 빠른가?

결론 (BLUF): Rust는 TechEmpower 벤치마크에서 처리량 기준 Go를 1.5-3배 능가하나, 실제 I/O 워크로드에서는 격차가 크게 줄어든다. Go의 GC 일시 중지(Go 1.19 이후 서브밀리초)는 일반적 웹 서비스에서 병목이 아니다.

주요 근거:
- [Tier S] TechEmpower Round 22 (2024): Rust 프레임워크(Actix-web, Axum) 상위 10위, Go(stdlib, Gin) 20-40위대
- [Tier A] Go Blog "Getting to Go" (2022): p99 GC 일시 중지 < 500μs
- [Tier A] Discord Engineering Blog (2020): Go→Rust 전환으로 tail latency 개선 (다만 수백만 동시 연결의 비전형적 워크로드)

미확인/불확실:
- ⚠️ "Rust가 메모리 50% 적게 사용" — Reddit/HN에서 자주 반복되나 독립 벤치마크에서 일관된 수치 미확인. Unverified.

신뢰도 요약: 핵심 주장 80% | 검색 5회 | 소스 5개 (Tier S: 1, Tier A: 3, Tier B: 1)
```

문제점과 GOOD 예시의 차이:
- 모든 소스가 실재하는 검증 가능한 출처
- 소스 부족한 주장은 명시적으로 "Unverified" 표기
- 검증 매트릭스가 정직하게 검증됨/미검증을 구분
- 독립 소스 추적 (TechEmpower는 자체 벤치마크, 상호 인용 아님)

---

**스킬 버전**: v1.1
**작성일**: 2026-03-17
**작성자**: 프레이야 (프론트엔드 개발자)
**참조**: cross-verified-research 원본, 작업 레벨 시스템, 소스 등급 체계