다각도 조사 (Multi-perspective research)
평면 검색은 "웹이 X에 대해 뭐라고 말하는가"에 답합니다. 이 스킬은 "X의 어떤 부분이 독립적으로 입증되었고, 어떤 부분이 단일 출처에 의존하는가"에 답합니다.
메커니즘은 Stanford의 STORM(stanford-oval/storm 소스에서 확인)에서 추상화되었습니다:
(관점 × 예산) → 검색 → (증거 | 거부) → 기록 → 다시 질문
M 라운드 반복, N+1개의 독립 레인, 마지막에 한 번 수렴
↓
working-report.md (메커니즘 가시, 감사 추적)
↓
reader-report.md (메커니즘 불가시, 최종 결과물)
↓
사용자 응답 = reader-report.md 원문 그대로, 추가 없음
핵심 가치는 대부분의 연구 시도가 놓치는 네 가지 지점에 있습니다: 관점은 모델 외부에서 가져와야 하며, 모든 질문은 실제 검색으로 이어져야 하며, 수렴은 가정이 아닌 점수로 매겨져야 하며, 점수화된 결과는 그 현장에 없었던 사람이 읽어도 이해할 수 있어야 합니다.
트리거 조건
사용자의 표현 중 다음 중 하나라도 있으면 이 스킬을 발동하세요. 사용자가 스킬 이름을 직접 언급할 필요는 없습니다:
- 명시적 토큰: 深度调研 / 深度研究 / 深度分析 / 深入研究 / deep-research / deep research / deep dive / 深入调研.
- 품질 부사 요청: 仔细调研 / 认真调研 / 调研得仔细一点 / 多查几个来源 / 别只给一个来源 / 要确定性结论 / 确定性调研 / 查得踏实一点 / 帮我彻底搞清楚 X / 把 X 查透 / X 到底怎么样 / 不要泛泛而谈.
- 방법론 요청: 多维度调研 / 多视角 / 全景分析 / 正反双方梳理 / 交叉验证 / 多方观点对比 / 交叉比对来源 / 标注"哪些结论有多来源印证、哪些只有单一来源".
- 암시적 형태: 한 번의 답변으로 충분하지 않다고 사용자가 신호를 보내는 모든 연구 요청.
중첩 규칙: anysearch와 agent-reach는 일반적인 调研/搜索/查一下을 담당합니다(이들은 검색 백엔드이며, 이 스킬은 이를 도구로 사용합니다). 요청에 깊이/주의/확실성/교차 검증 수식어가 포함되는 순간, 이 스킬이 요청을 소유하고 해당 백엔드를 레인 내에서 구동합니다. 확실하지 않으면 이 스킬을 선호하세요: 과잉 조사의 비용은 시간이고, 부족 조사의 비용은 확신에 찬 잘못된 답변입니다.
해당 없음: 단일 빠른 사실 확인, "이 API가 뭔지 찾아봐", 또는 한 페이지 조회.
두 가지 산출물
1~5단계는 **작업 보고서(working report)**를 생성합니다: lane, A–E, query, round 및 직교성 문장이 핵심인 메커니즘 가시 산출물입니다. 정확하지만, 직접 실행하지 않은 사람은 읽을 수 없습니다.
6단계는 **읽기 보고서(reader report)**를 생성합니다: 실제로 전달할 결과물입니다. 동일한 증거, 동일한 정직성, 동일한 출처 — 하지만 메커니즘은 사라지고, 구조는 독자가 결정을 내리는 데 필요한 내용을 중심으로 재구성됩니다.
두 산출물을 모두 유지하고, 6단계가 5단계를 대체하지 못하게 하세요.
- 작업 보고서는 감사 추적입니다: 이를 통해 (또는 이후 패스를 통해) 어떤 주장도 표류하지 않고, 어떤 등급도 상향되지 않았으며, 빈 행이 기억에서 채워지지 않았음을 확인할 수 있습니다. 파일(예:
working-report.md)로 작성되며 절대 응답에 붙여넣지 않습니다. - 읽기 보고서는 최종 전달물로 **
reader-report.md**로 저장됩니다: 사람이 용어집 없이 한 번에 실제로 사용할 수 있는 것입니다.
전달 규칙(엄격): 사용자에 대한 최종 응답은 reader-report.md의 내용을 원문 그대로, 완전히 — 추가, 변경, 감싸기 없이 — 포함합니다. 아래 §전달을 참조하세요. 서두("我做完了，下面是报告"), 서명, 요약, 확인 줄, 수행한 작업이나 존재하는 파일에 대한 설명이 없습니다. 파일을 읽고 그 바이트를 메시지 본문으로 정확히 내보냅니다. 추가하고 싶은 모든 내용은 작업 보고서에 속하며 응답에는 속하지 않습니다.
두 문서를 하나로 합치면 두 방향 모두에서 실패합니다. 메커니즘을 유지하면 독자는 거부하고, 6단계 규칙 없이 메커니즘을 제거하면 교차 검증이 조용히 사라집니다 — 독자는 더 이상 "네 개의 독립적인 경로가 여기서 만났다"와 "하나의 운 좋은 히트가 반복되었다"를 구분할 수 없게 되며, 이것이 이 스킬의 핵심 목적이었습니다.
양보할 수 없는 사항
- 관점은 읽어내는 것이지, 발명하는 것이 아닙니다. 반드시 가져온 실제 아티팩트(기존 보고서, 경쟁사 문서, 목차, 포럼 카테고리, 규제 제목)에서 파생해야 합니다. 스스로에게 "이에 대한 세 가지 각도는 무엇일까"라고 묻지 마세요.
- 모든 질문은 검색을 생성해야 합니다. 실제 출처를 조회하는 쿼리로 분해될 수 없는 질문은 연구가 아니라 추측입니다. 그렇게 말하고 중단하세요.
- 실행 중인 레인은 서로 소통하지 않습니다. 독립성만이 일치를 유익하게 만듭니다. 수렴은 마지막에 한 번만 발생합니다.
- 거부는 신호이지, 실패가 아닙니다. 레인의 검색 결과가 비어 있으면 이를 기록하고 다음 질문을 다른 방향으로 유도하세요. 매개변수 메모리로 빈 공간을 채우지 마세요.
- 주장별로 입증 수준을 보고하세요. "세 개의 독립적인 출처가 동의함"과 "한 블로그가 그렇게 말함"은 읽기 보고서에서 절대 동일하게 보여서는 안 됩니다.
- 메커니즘은 읽기 보고서에서 보이지 않지만, 증거는 보여야 합니다. 독자는 레인이 무엇인지 알 필요가 전혀 없어야 하지만, 항상 "누가 그렇게 말했고, 다른 누군가도 그렇게 말했는가"를 물을 수 있어야 합니다.
- 응답은 읽기 보고서이며, 변경되지 않습니다. 사용자에 대한 최종 메시지는
reader-report.md를 전체 복사한 것입니다 — 서두, 서명, 요약, 게이트 라인, 설명이 없습니다. 사용자에게 다른 내용을 보여주고 싶다면 파일을 변경하고 다시 내보내세요. 절대 나가는途中에서 편집하지 마세요.
1단계 — 관점 고정하기
주제부터 시작하지 마세요. 이 주제가 세상에서 이미 어떻게 구조화되어 있는지부터 시작하세요.
구조를 빌릴 수 있는 2~4개의 실제 아티팩트를 가져오세요:
| 주제 종류 | 구조를 읽을 위치 |
|---|---|
| 개체, 제품, 사건 | 위키백과 페이지 섹션 + 2개의 인접/경쟁 페이지 섹션 |
| 시장, 산업 | 두 애널리스트 보고서 목차, 규제 기관 제출 색인, 컨퍼런스 일정 |
| 기술적 접근 방식 | 상위 문서 사이드바, 두 경쟁 프로젝트의 README 제목 |
| 논란의 여지가 있는 문제 | 가장 강력한 찬성 자료의 제목, 가장 강력한 반대 자료의 제목 |
| 사람, 조직 | 자체 사이트 구조 vs. 비판적 보도의 구조 |
그런 다음 3개의 레인(아래 레인 0 추가)을 도출하세요. 각 레인은 주제에 대한 다른 이유여야 하며, 다른 하위 주제가 아닙니다:
- ✅ "이것을 프로덕션에서 운영해야 하는 사람, 실패 모드와 비용에 관심"
- ✅ "이 결정에 재정적으로 노출된 사람, 누가 비용을 부담하는지에 관심"
- ❌ "기술적 측면" / "경제적 측면" / "사회적 측면" — 이것들은 같은 선입견이 세 가지 다른 모자를 쓴 것에 불과합니다.
예산을 사용하기 전에 직교성을 확인하세요. 각 레인 쌍에 대해 한 문장을 작성하세요: "레인 A는 X를 물을 것입니다; 레인 B는 X를 물을까요?" 어떤 쌍에 대해서도 '예'라면 병합하고 다시 도출하세요. 두 레인이 동일한 처음 세 질문을 생성한다면, 그들은 하나의 레인입니다. 이 확인은 전체 절차에서 단일 가장 높은 레버리지 순간입니다 — 건너뛰면 하나의 검색에 대한 네 개의 의역을 얻게 됩니다.
레인 0은 필수입니다: 기본적이고 논란의 여지가 없는 사실, 날짜, 정의, 숫자가 필요한 사람을 위한 일반 레인입니다. 이는 다른 모든 레인이 특수화되어 무의미해지는 것을 막는 적용 범위 바닥입니다.
앵커 아티팩트와 직교성 문장을 기록하세요. 이들은 작업 보고서(5단계)에 관점 집합의 출처로 들어갑니다. 읽기 보고서(6단계)에는 나타나지 않습니다.
2단계 — 사용하기 전에 예산 설정
예산을 명시적으로 작성한 다음, 이를 준수하세요:
| 항목 | 기본값 | 근거 |
|---|---|---|
| 레인 수 | 3 + 레인 0 = 4 | 더 많은 레인은 다양화보다는 희석시킵니다. 4가 경험적 최적점입니다. |
| 레인당 라운드 수 | 3 | 한 번의 후속 질문에 충분합니다. 그 이상은 일반적으로 레인이 길을 잃습니다. |
| 질문당 쿼리 수 | 2–3 | 하나의 쿼리는 복권이고, 다섯 개는 샷건입니다. |
| 쿼리당 결과 수 | 3–5 | 상위 몇 개를 읽고, 비축하지 마세요. |
| 라운드당 증거 단어 수 | ~1000 | 중요한 문장만 유지하도록 강제합니다. |
| 레인 컨텍스트 단어 수 | ~2500 | 최근 세부 정보를 유지하고, 오래된 세부 정보는 제거합니다. |
| 병렬 레인 수 | ≤4 | 동시성이 핵심입니다. 속도 제한이 제약입니다. |
총 검색 예산 ≈ 4 × 3 × 3 = 36개 쿼리. 예산이 소진되면 검색을 중단하고 수렴을 시작하세요. 예산 소진은 설계된 이벤트이지, 사고가 아닙니다.
3단계 — 레인을 병렬로 독립적으로 실행
동시에 모든 레인을 시작하세요 — 가능한 경우 병렬 하위 에이전트(subagent/workflow)를 사용하며, 레인당 하나씩입니다. 각 레인은 다음을 받습니다: 주제, 레인 설명, 예산, 아래 규칙. 각 레인에게 다른 레인에 대한 가시성을 주지 마세요.
레인 내에서 각 라운드에 대해:
- 한 번에 하나의 질문을 레인의 관점에서 하세요. 선택할 수 없는 제약사항:
- 주제에 대해 질문하고, 인접 주제에 대해 질문하지 마세요(표류 방지)
- 이미 질문한 것을 다시 질문하지 마세요(반복 방지)
- 질문할 가치가 있는 것이 더 이상 없으면 레인을 중단하세요 — 라운드를 채우기 위해 질문을 조작하지 마세요
- 질문을 2~3개의 검색 쿼리로 분해하세요. 분해되지 않는 질문은 나쁜 질문입니다. 다시 작성하세요.
- 검색한 다음, 실제로 가져오세요. 스니펫은 실마리일 뿐, 증거가 아닙니다. 중요한 내용이면 페이지를 가져오세요.
- 가져온 내용으로만 답하세요. 모든 문장은 URL로 추적 가능해야 합니다. 출처가 답하지 않으면 거부를 그대로 기록하세요: "이 질문에 대한 출처를 찾을 수 없음".
- 턴을 레인 컨텍스트에 다시 기록하세요 — 질문 뼈대는 항상, 답변 세부 정보는 최근 몇 턴만 유지합니다. 이것이 다음 질문을 재시작이 아닌 후속 질문으로 만듭니다.
가져온 모든 출처에 대해 url, title, 이를 찾은 쿼리, round, 그리고 그 출처가 지원하는 정확한 주장을 포함한 레인별 로그를 유지하세요. query와 round 필드는 모든 사람이 잊어버리고 4단계에서 필요한 필드입니다.
거부 루프: 라운드의 검색이 비어 있거나 쓸모없으면 레인 컨텍스트에 기록되고 다음 질문은 그로부터 멀어져야 합니다. 이미 믿고 있는 것으로 구멍을 메우지 마세요.
4단계 — 수렴하고 수렴 점수 매기기
이제, 오직 이제, 레인을 함께 가져옵니다.
4a. 요약이 아닌 출처로 병합하세요. 모든 증거 조각을 URL(정규화: 추적 매개변수, 조각, 후행 슬래시 제거)로 키를 지정하세요. 두 레인에서 동일한 URL → 하나의 출처, 지원하는 주장의 합집합. 이것은 첫 번째이자 가장 저렴한 수렴이며, 두 레인이 독립적으로 동일한 페이지에 도달했음을 발견하는 지점입니다.
4b. 주장 × 레인 매트릭스를 구축하세요. 추출된 주장을 원자적 진술(행당 하나의 사실)로 클러스터링하세요. 각 주장에 대해 어떤 레인과 몇 개의 고유 출처가 지원하는지 기록하세요:
claim | supporting URLs | distinct sources | lanes that found it | conflicts
4c. 입증 점수를 매기세요. 이것이 전달물의 척추입니다:
| 수준 | 조건 | 표현 방법 |
|---|---|---|
| A — 수렴됨 | ≥2개의 독립적인 레인에서 발견됨, ≥2개의 고유 도메인 | 명확히 진술 |
| B — 확증됨 | ≥2개의 고유 출처, 동일한 레인 | 출처와 함께 진술 |
| C — 단일 출처 | 1개 출처만 | 진술 + 단일-출처 플래그 |
| D — 논쟁 중 | 신뢰할 수 있는 출처가 불일치 | 둘 다 제시, 평균내지 말 것 |
| E — 발견되지 않음 | 검색했으나 찾지 못함 | 명시적으로 말할 것. 기억에서 채우지 말 것. |
주장이 A가 되려면 레인이 진정으로 독립적이어야 합니다 — 두 레인이 모두 주제 이름을 검색하고 모두 위키백과 페이지를 얻었다면, 그것은 두 번의 동일한 레인이지 수렴이 아닙니다.
4d. 가중치를 부여하고, 세지 마세요. URL이 아닌 도메인별로 클러스터링하세요. 동일한 보도 자료를 인용하는 10개 페이지는 하나의 출처입니다. 동일한 조직의 두 페이지는 하나의 출처입니다. 업스트림 종속성(relates to, according to)을 기록하세요 — 메아리로부터의 입증은 입증이 아닙니다.
4e. 명시적으로 충돌을 찾으세요. STORM의 측정된 실패 모드는 환각이 아니라, 단지 함께 발생한 사실들을 연결하는 것입니다. 작성하기 전에, 매트릭스에서 주장을 지원하는 출처가 실제로 연결되는 두 가지를 연결하지 않는 주장을 스캔하세요. 그러한 모든 링크는 me에 의해 추론됨으로 표시하고, 절대 출처가 있다고 표시하지 마세요. D-수준 행을 찾아 각각이 보고서에서 조용히 해결되는 대신 보이도록 하세요.
5단계 — 보고 (작업 보고서, 메커니즘 가시)
Markdown 파일을 작성하세요. 기본 이름: working-report.md (사용자나 호출자가 보고서에 대해 다른 출력 디렉토리나 파일 이름을 지정한 경우 이를 따르세요 — WORKING = <해당 경로> 및 READER = <보고서 경로>를 시작 부분에 설정하고 나머지 실행 동안 이 두 변수를 사용하여 응답이 올바른 파일을 내보내도록 합니다).
필수 구조:
# <주제>
## 입증 요약
<개수: 수렴됨 / 확증됨 / 단일 출처 / 논쟁 중 / 발견되지 않음 주장 수>
## 관점 선택 방법
<실제로 가져온 앵커 아티팩트 + 직교성 문장 + 레인 목록>
## 조사 결과
### <테마>
<본문; 각 주장은 인라인으로 A/B/C/D/E 표시; 인용은 [n]>
## 논쟁 지점
<모든 D-수준 행, 양측, 출처 첨부>
## 단일 출처 주장
<모든 C-수준 행 — 이를 확인해야 할 실마리로 읽고, 사실로 읽지 마세요>
## 검색되었지만 찾지 못한 것
<E-수준 행, 사용된 쿼리 포함>
## 출처
[n] <url> — <lane>에서 찾음, 라운드 <k>, 쿼리 "<q>"을 통해
출처 목록에 발견된 레인 / 라운드 / 쿼리 출처를 유지하세요. 기록하는 데 거의 비용이 들지 않으며, 독자가 "네 개의 독립적인 레인이 여기서 수렴했다"와 "하나의 운 좋은 히트가 반복되었다"를 구분할 수 있게 하는 유일한 것입니다.
이것은 감사 대상 산출물이며, 전달 대상이 아닙니다. 6단계로 진행하세요.
6단계 — 읽기 보고서로 다듬기 (메커니즘 불가시)
결과를 reader-report.md(또는 5단계에서 고정된 <READER>)에 작성하세요. 이것을 새로운 컨텍스트로 별도의 패스로 실행하세요 — 작업 보고서만 받고, 레인 프롬프트, 레인 로그, 또는 추론을 받지 않는 하위 에이전트입니다. 메커니즘을 본 패스는 메커니즘을 누설할 것입니다.
6a. 모든 메커니즘 용어를 독자 언어로 번역
이것은 고정된 매핑이며, 판단의 문제가 아닙니다. 대안을 발명하지 마세요.
| 작업 보고서 | 읽기 보고서 |
|---|---|
| 레인 / 라운드 / 쿼리 | 관점 / 단계 / 검색 흐름 (메커니즘 숨김) |
| 수준 A–E | 명확한 레이블: "여러 독립적인 출처가 동의합니다" / "단일 출처만 이 정보를 가지고 있습니다" (독자가 지도를 배우지 않고도 해석할 수 있도록) |
| 매트릭스 셀 | 출처 그룹: "출처 A, B, C는 모두 이 주장을 하며 서로를 인용하지 않습니다" vs. "출처 D만 이 주장을 합니다" |
| 거부 루프 | "이 특정 질문에 대해 사용 가능한 정보를 찾을 수 없습니다" (메커니즘에 대한 언급 없음) |
6b. 증거를 단계별에서 주제별로 재구성
독자는 "다음 라운드에서 무슨 일이 일어났는가"를 따르지 않습니다. 독자는 "무엇을 결정해야 하는가"를 따릅니다. 이에 맞춰 구조를 변경하세요:
- 작업 보고서는 조사 과정을 따릅니다 (무엇을 먼저 찾았는가).
- 읽기 보고서는 결정 뼈대를 따릅니다 (무엇을 알아야 하는가).
표준 구조를 권장하지만, 강제하지는 않습니다:
# <주제>
## 빠른 요약
<전체 입증 그림을 2~4문장으로 — 가장 많이 수렴된 것, 여전히 알려지지 않은 것>
## 결정 지점 #1 — <질문>
<발견된 것. 각 주장 옆에 수렴 정도 표시>
## 결정 지점 #2 — <질문>
<...>
## 결정 지점 #3 — <질문>
<...>
## 아직 알려지지 않은 것
<레인에서 분명히 요청했지만 사용 가능한 출처에서 답변되지 않은 질문. 가져온 내용만, 추측하지 마세요.>
## 출처
[1] <출처 이름> — <url>
...
각 결정 지점에 대해, 깔끔한 참조를 유지하기 위해 인용을 다시 색인화하세요. 작업 보고서에서 인덱스는 [23]일 수 있지만, 읽기 보고서에서는 [1]이어야 합니다. 6단계 전에 작업 보고서의 원래 인덱스를 유지할 필요는 없습니다; 어떤 작업 보고서 인덱스도 읽기 보고서에 누설되어서는 안 됩니다.
6c. 수렴의 점수는 유지하고, 용어는 제거하세요
6a의 매핑을 초점에 맞게 유지하세요:
- 작업 보고서는 "수렴됨"이라고 말합니다.
- 읽기 보고서는 "네 개의 출처(세 도메인)가 이에 대해 동의합니다"라고 말합니다.
- 작업 보고서는 "단일 출처"라고 말합니다.
- 읽기 보고서는 "한 출처만 이 주장을 합니다"라고 말합니다.
- 작업 보고서는 "논쟁 중"이라고 말합니다.
- 읽기 보고서는 "출처가 이 지점에서 모순됩니다. 저자 K는 X라고 말합니다. 저자 L은 ~X라고 말합니다."라고 말합니다.
6d. 주장의 유령을 떠올리지 마세요
6단계는 보고를 다시 작성하는 것이며, 추측을 생성하는 것이 아닙니다. 공백을 채우기 위해 일반 지식을 사용하지 마세요. 작업 보고서에 주장이 없다면, 읽기 보고서에도 없어야 합니다. 작업 보고서에 "발견되지 않음"으로 표시된 경우, 읽기 보고서에 "증거가 없습니다. 이 질문은 검색되었지만 사용 가능한 출처에서 발견되지 않았습니다."와 같이 매핑하세요.
출처를 확인하는 것을 좋아한다면, 작업 보고서의 증거를 넘어 확인하는 것은 6단계 작업이 아닙니다. "근거 기반 추론"을 추가해야 한다고 느낀다면, 6단계 이전에 작업 보고서에 추가하세요.
6e. 읽기 보고서를 작성한 후, 이미지 확인을 위해 한 번 스캔하세요
작업 보고서에 익숙한 사람이 읽기 보고서를 보고 "이것은 수렴된 주장처럼 보이지만, 여기서는 단일 출처 주장과 동일하게 나타납니다"라고 말할 수 있는 곳이 있습니까? 그렇다면 문구를 조정하세요. 시각적 무게는 의미적 무게를 따라야 합니다.
전달
최종 사용자 응답은 reader-report.md의 전체 내용을 추가, 변경, 또는 감싸지 않은 원문 그대로여야 합니다. 마지막 단계:
reader-report.md가 6단계에서 작성되었는지 확인하세요.cat reader-report.md또는 이와 동등한 작업을 수행하세요.- 그 출력을 정확히 메시지 본문으로 보내세요. 문자 그대로. 그 앞이나 뒤에 아무 것도 없습니다.
특히, 다음을 보내지 마세요:
- 소개 ("다음은..." 또는 "조사가 완료되었습니다")
- 절차 요약 ("저는 4개의 레인과...를 사용했습니다")
- 한계 진술 ("이는 AI 생성이며..." — 이는 전달 바로 앞에 진술해야 하며, 이 스킬 외부에서 해야 합니다)
- 존재하는 파일에 대한 언급 ("reader-report.md 및 working-report.md를 참조하십시오")
- 작업 보고서에서의 변경 또는 추가에 대한 해명
사용자에게 작업 보고서의 내용을 보여주고 싶다면, 읽기 보고서에 넣으세요. 사용자에게 응답을 요약하고 싶다면, 읽기 보고서에 넣으세요. 사용자에게 끝났다고 말하고 싶다면, 읽기 보고서에 넣으세요.
왜? 이 스킬이 존재하는 이유는 조사 불확실성을 가시적으로 만들기 위해서이며, 이 계약을 위반하는 유일한 것은 응답에 대한 신뢰 불확실성을 도입하는 조용한 추가입니다. 읽기 보고서는 산출물입니다. 산출물을 그대로 내보내면 사용자는 심사를 피할 수 없습니다.