deep-research-pro

name	deep-research-pro
description	출처 있는 심층조사와 판단 브리프가 필요할 때 사용하는 OpenClaw 맞춤 리서치 스킬. 단순 검색 답변이 아니라 정책·시장·기업·기술·제도·문헌·공공기관 보고서 근거를 여러 출처로 교차확인하고, 출처 등급·첨부 PDF 확인·반대검토·합의점/쟁점·의사결정 포인트까지 정리한다. Windows/OpenClaw 환경에서는 web_search, web_fetch, browser, pdf, korean-law 도구를 사용하고, 특정 로컬 환경 전용 검색 스크립트나 저장 경로는 사용하지 않는다.
license	See docs/attribution.md
metadata	{"category":"research","locale":"ko-KR","phase":"v1","origin":"adapted-from-clawhub-deep-research-pro"}

심층 리서치 프로 - OpenClaw판

먼저 읽기: 언제 쓰는 스킬인가

이 스킬은 출처 있는 심층조사와 의사결정용 판단 브리프가 필요할 때 쓴다. 자료를 많이 모으는 것이 목적이 아니라, 질문을 쪼개고, 핵심 출처 본문과 첨부 PDF를 확인하고, 서로 다른 출처를 교차검증한 뒤, 합의점·쟁점·반대논리·결정 포인트까지 정리하는 것이 목적이다.

조사는 깊게 하되, 사용자에게 보이는 최종 답변은 짧고 판단 중심이어야 한다. 검증 로그와 조사 방법은 파일 보고서나 하단 부록에 두고, 대화 답변은 결론과 적용 판단을 먼저 제시한다.

쓰면 좋은 경우

• 정책 방향, 제도 도입, 사업 타당성, 예산·성과 논리처럼 근거 있는 판단이 필요할 때
• 공공기관 보고서에 넣을 배경자료, 유사기관 사례, 법령·지침·통계·보고서 근거가 필요할 때
• 시장·기업·기술·경쟁사·문헌을 여러 출처로 비교해야 할 때
• “출처 달아서 깊게 조사해줘”, “근거 있는 리포트로 정리해줘”, “대안 판단할 수 있게 조사해줘”, “실제 사례를 분석해줘”라는 요청일 때

쓰지 않는 게 좋은 경우

• 단일 사실 확인이나 빠른 웹 검색이면 충분한 경우
• 블로그·책 글감을 넓게 모으는 일반 자료 수집: research 우선
• 공문서·검토보고서 초안 작성 자체: official-report-skillset 우선
• HWPX 한글 파일 생성: hwpxskill 우선

---

OpenClaw 환경 기준

이 스킬은 특정 사용자나 운영환경에 묶인 검색 스크립트·저장 경로를 전제하지 않는다.

사용할 도구

• 일반 검색: web_search
• 웹 본문 확인: web_fetch
• JS·로그인·뉴스/IR·동적 페이지: browser
• PDF 자료 분석: pdf
• 한국 법령·판례·해석례·행정규칙: korean-law 도구군
• 장시간·대규모 조사: 필요 시 sessions_spawn으로 sub-agent 위임

포함 스크립트

아래 스크립트는 first-class 도구가 실패했을 때만 보조로 사용한다.

• scripts/source_fetch.py: PDF·HTML 직접 URL을 로컬 파일로 저장한다. pdf 도구가 URL에서 실패하거나 기관 사이트 첨부파일을 로컬로 재시도할 때 사용한다.
• scripts/pdf_text_extract.py: 네이티브 pdf 도구가 실패할 때 로컬 PDF에서 텍스트를 추출한다. pypdf를 우선 사용하고 실패하면 pdfplumber로 재시도한다.
• scripts/validate_report.py: 생성된 report.md에 핵심 요약, 출처, 조사 방법, 한계 표시가 있는지 빠르게 점검한다.

저장 위치

보고서 파일 저장이 필요하면 아래 경로를 기본으로 한다.

outputs\research\YYYY-MM-DD-<slug>\
  brief.md
  report.md
  sources.jsonl
  quality_report.md
  failed_urls.txt
  extracts\

짧은 대화 답변만 필요한 경우에도, 조사 규모가 크거나 PDF를 내려받았다면 위 경로에 작업 흔적을 남긴다. brief.md는 사용자에게 바로 보여줄 판단 브리프, report.md는 상세 보고서, sources.jsonl은 출처별 확인 로그, quality_report.md는 검증 결과를 담는다.

사용자가 특정 프로젝트 경로를 지정하면 그 경로를 우선한다.

---

조사 절차

기본 절차는 아래 7단계다.

1. 질문 범위 확정
2. 검색 계획 수립
3. 반복 검색과 후보 출처 확보
4. 출처 등급화와 교차확인
5. 핵심 본문·첨부 PDF 확인
6. 사실을 판단으로 종합
7. 품질검토 후 산출물 포장

1단계. 목표 확인

가능하면 먼저 아래를 내부적으로 정리한다. 꼭 필요한 경우에만 사용자에게 1개 질문한다.

• 목적: 학습, 의사결정, 보고서 근거, 콘텐츠 작성, 투자 판단 중 무엇인가
• 독자: 개인 판단, 간부, 조직 내부, 대외 공개, 블로그/책 독자 중 누구인가
• 산출물: 짧은 요약, 심층 리포트, 근거 메모, 표, 보고서 본문 중 무엇인가
• 범위: 국가, 기간, 산업, 기관, 법령, 비교 대상
• 제외 범위: 이번 조사에서 다루지 않을 대상
• 필요한 깊이: 대화 답변, 내부 보고용, 대외 공개용 중 무엇인가

사용자가 “그냥 조사해줘”라고 하면 합리적 기본값으로 진행한다.

내부 범위 정리는 아래 형식을 기준으로 한다. 사용자에게 그대로 노출할 필요는 없다.

{
  "조사목적": "의사결정|보고서근거|정책검토|시장조사|학습",
  "독자": "개인|실무자|간부|대외공개",
  "핵심질문": ["질문1", "질문2", "질문3"],
  "제외범위": ["이번에 다루지 않을 것"],
  "기간": "예: 최근 3년",
  "지역": "예: 한국",
  "최소출처등급": "가|나|다",
  "산출물": "판단 브리프|상세 보고서|근거 메모"
}

2단계. 연구 질문 분해

주제를 3~5개 질문으로 쪼갠다.

예시:

주제: 공공기관 AI 도입 가이드라인
1. 국내 정부·공공기관의 최신 AI 도입 지침은 무엇인가
2. 개인정보·보안·책임성 관련 핵심 제약은 무엇인가
3. 유사기관 사례와 실패 리스크는 무엇인가
4. 성과 측정과 운영체계는 어떻게 잡아야 하는가
5. 보고서에 넣을 실행 권고는 무엇인가

3단계. 출처 우선순위 선택

주제에 따라 출처 우선순위를 다르게 둔다.

공공기관·정책·제도 조사

1. 법령·시행령·고시·행정규칙·지침
2. 정부·부처·공공기관 공식 발표자료와 보도자료
3. 통계청·공공데이터·정부 통계
4. 국회·감사원·예산정책처·입법조사처·연구기관 보고서
5. 유사기관 사례
6. 신뢰 가능한 언론·전문 매체
7. 커뮤니티·블로그는 현장 반응 확인용으로만 제한 사용

공공기관용 출처 등급

• 가등급: 법령, 고시, 행정규칙, 공식 통계, 감사원·국회·정부 공식 보고서, 원문 PDF
• 나등급: 부처·공공기관 보도자료, 공식 가이드라인, 백서, 사업 공고, 공식 설명자료
• 다등급: 국책연구기관·학회·전문기관 보고서, 공신력 있는 국제기구 자료
• 라등급: 언론 기사, 기업 백서, 기술 블로그, 업계 보고서
• 마등급: 커뮤니티, 개인 블로그, SNS, 홍보성 게시물

중요한 판단은 가~다등급 출처를 중심으로 한다. 라등급은 최신 동향 보조, 마등급은 현장 반응이나 논란 확인용으로만 사용한다. 출처마다 등급과 한계를 기록한다.

시장·기업·기술 조사

1. 기업 공식 자료, IR, 공시, 실적 발표
2. 규제기관·정부·국제기구 자료
3. 학술·전문기관 보고서
4. 신뢰 가능한 뉴스·산업 매체
5. 제품 문서·기술 문서
6. 커뮤니티·블로그는 실사용자 반응 확인용으로만 제한 사용

4단계. 검색 실행

각 연구 질문마다 2~3개 검색어 변형을 사용한다.

• 한국어/영어를 함께 쓴다.
• 공식 출처가 필요한 경우 site:go.kr, site:or.kr, site:ac.kr, site:gov, 기관명, 법령명을 조합한다.
• 최신성이 중요한 경우 연도와 “보도자료”, “가이드라인”, “보고서”, “통계”, “annual report”, “white paper”를 함께 쓴다.
• 같은 내용의 중복 기사보다 원출처를 우선한다.

검색 결과는 보통 1025개 후보를 확보하되, 실제 본문 확인은 핵심 37개 출처에 집중한다.

5단계. 핵심 출처 본문·첨부 확인

검색 스니펫만으로 결론을 내리지 않는다.

• 일반 페이지는 web_fetch로 본문 확인
• web_fetch가 401/403, JS 의존, 뉴스/IR/동적 페이지면 browser 사용
• PDF 보고서·논문·보도자료 첨부는 pdf 도구 사용
• 정부·공공기관 게시글에 PDF/HWPX 첨부가 있으면 HTML 본문만 읽고 끝내지 않는다. 최소 1개 핵심 첨부의 본문 또는 첫 3~5쪽을 확인한다.
• pdf 도구가 URL에서 실패하면 web_fetch 또는 browser로 게시글·첨부파일 메타를 먼저 확인하고, 필요 시 scripts/source_fetch.py로 파일을 다운로드한 뒤 로컬 경로로 재시도한다. 로컬 PDF도 실패하면 scripts/pdf_text_extract.py로 필요한 페이지만 텍스트 추출한다.
• 행정안전부·공공기관 사이트처럼 메뉴 텍스트가 과다 추출되면 browser의 evaluate로 document.body.innerText를 확인해 제목·등록일·본문·첨부파일 정보만 추린다.
• 법령·판례·행정규칙은 korean-law 도구군 사용

PDF 심층 확인 기준

아래 중 하나라도 해당하면 PDF 본문 확인을 필수로 한다.

• 제목에 가이드라인, 안내서, 보고서, 백서, 실태조사, 연차보고서, 브리핑문, Q&A가 포함됨
• HTML 본문이 “자세한 내용은 첨부를 참고” 수준으로 짧음
• 수치, 정책 원칙, 절차, 체크리스트, 사례가 첨부파일에 있을 가능성이 큼
• 사용자가 “심층”, “근거 보고서”, “보고서에 넣을 정도”를 요청함

PDF를 확인한 경우 보고서의 조사 방법 또는 출처 확인 로그에 아래 중 하나를 명시한다.

- PDF 본문 확인: [문서명], 확인 쪽수 1-5쪽, 확인 방법 pdf/source_fetch.py/pdf_text_extract.py
- 첨부 PDF 확인 실패: [문서명], 실패 사유, 대체 근거

도구 실패 시 대체 경로

실패 상황	다음 조치
web_fetch가 401/403 또는 fetch failed	같은 URL을 반복하지 말고 browser로 열어 snapshot/evaluate 확인
web_fetch 결과가 메뉴·푸터 위주	browser evaluate로 document.body.innerText 확인 후 제목·본문·첨부파일만 추림
pdf가 URL에서 실패	게시글에서 PDF 직접 URL 확인 → scripts/source_fetch.py로 다운로드 → 로컬 PDF 경로로 재시도
PDF 분석 모델이 계속 실패	scripts/pdf_text_extract.py <file.pdf> --pages 1-5로 목차·핵심 페이지만 텍스트 추출
PDF 텍스트 추출도 실패	PDF 파일명·발행기관·게시글 설명만 근거로 쓰고, 본문 세부항목은 추가 확인 필요 표시
검색 결과가 블로그·언론만 나옴	site:go.kr, site:or.kr, site:ac.kr, 기관명, 문서유형 키워드로 재검색
법령·지침이 쟁점인데 웹 검색만 잡힘	korean-law 도구로 법령명·조문·해석례 직접 확인

출처마다 아래를 기록한다.

- 제목:
- 기관/매체:
- 날짜:
- URL:
- 핵심 내용:
- 신뢰도:
- 보고서에 쓸 수 있는 근거:
- 한계 또는 주의점:

출처 확인 로그는 가능하면 보고서 하단 또는 별도 메모에 남긴다.

| 출처 | 확인 방법 | 본문 확인 여부 | 신뢰도 | 보고서 반영 |
|---|---|---|---|---|
| 기관명/문서명 | web_fetch/browser/pdf/source_fetch.py/pdf_text_extract.py/korean-law | 예/PDF 1-5쪽/부분/실패 | 높음/중간/낮음 | 반영/보류 |

6단계. 교차검증

• 중요한 주장에는 최소 2개 출처를 확인한다.
• 한 출처에만 있는 내용은 단일 출처, 추가 확인 필요로 표시한다.
• 통계 숫자는 기준일, 모집단, 산식, 발표기관을 함께 쓴다.
• 법령·지침은 시행일 또는 개정일을 확인한다.
• 최신 기사와 공식 자료가 충돌하면 공식 자료를 우선하되, 차이를 설명한다.

7단계. 분석 종합과 반대검토

확인한 사실은 그대로 나열하지 않는다. 각 핵심 사실마다 아래 질문을 붙인다.

• 그래서 무엇이 달라지는가
• 누구에게 영향을 주는가
• 실행하면 어디에서 막히는가
• 숨은 비용이나 책임은 무엇인가
• 이 결론이 틀릴 수 있는 가장 강한 이유는 무엇인가

분석은 아래 5층으로 정리한다.

1. 표면 현황: 지금 공개적으로 확인되는 사실
2. 구조와 지형: 이해관계자, 제도, 시장, 운영 구조
3. 깊은 쟁점: 실패 조건, 현장 병목, 숨은 비용, 책임 문제
4. 인접 기회: 다른 분야나 기관에 적용 가능한 확장 가능성
5. 다음 변화: 앞으로 6~24개월 안에 확인해야 할 신호

마지막에는 반드시 반대검토를 한다.

• 이 결론을 반박하는 가장 강한 근거는 무엇인가
• 출처가 한쪽으로 치우쳤는가
• 성공사례만 보고 실패사례를 놓쳤는가
• 최신 자료만 보고 장기 추세를 놓쳤는가
• 숫자가 성과를 제대로 대표하는가

---

결과물 형식

결과물은 두 가지로 나눈다.

1. 대화 답변 기본형: 판단 브리프

사용자에게 바로 답할 때는 아래 구조를 기본으로 한다. 영어 제목을 쓰지 않는다.

## 결론

[가장 중요한 판단 2~4문장]

## 핵심 발견

- [사실 + 의미]
- [사실 + 의미]
- [사실 + 의미]

## 상세 분석

[유형별 또는 쟁점별 분석. 각 항목은 사실보다 판단을 앞세운다.]

## 공통으로 확인된 점

- 여러 출처가 함께 가리키는 합의점

## 엇갈리거나 조심할 점

- 출처 간 차이, 단일 출처 주장, 실패 조건, 반대논리

## 결정 포인트

- 지금 결정할 것:
- 보류할 것:
- 추가 확인할 것:

## 출처

- [핵심 출처](URL)

2. 파일 저장 기본형: 상세 보고서

파일로 저장하는 상세 보고서는 아래 형식을 따른다.

# [주제] 심층조사 보고서

- 생성일: YYYY-MM-DD
- 조사 목적:
- 조사 범위:
- 확인 출처: N개
- 출처 등급: 가/나/다/라/마 요약
- 신뢰도: 높음/중간/낮음

## 1. 핵심 요약

- 핵심 결론 3~5개
- 의사결정에 바로 필요한 판단

## 2. 핵심 발견

- 발견 1:
- 발견 2:
- 발견 3:

## 3. 상세 분석

### 쟁점 1. [제목]
- 사실:
- 의미:
- 근거:
- 판단:

### 쟁점 2. [제목]
...

## 4. 공통으로 확인된 점

- 여러 출처에서 반복 확인되는 내용

## 5. 엇갈리거나 조심할 점

- 단일 출처 내용:
- 반대 근거:
- 실패 조건:
- 최신성 한계:

## 6. 결정 포인트

- 지금 결정할 것:
- 보류할 것:
- 추가 확인할 것:

## 7. 출처 목록

1. [제목](URL) — 기관/매체, 날짜, 한 줄 요약
2. ...

## 8. 조사 방법

- 검색 질문:
- 사용 도구:
- 본문 확인 출처:
- PDF 본문 확인:

출력 원칙

• 대화 답변에서는 조사 로그를 앞세우지 않는다.
• 조사 방법, 본문 확인 출처, PDF 본문 확인은 상세 보고서나 하단에 둔다.
• 모든 핵심 사실은 그래서 무엇이 중요한가까지 연결한다.
• 공공기관 주제에서는 정책 용어보다 운영 판단을 먼저 쓴다.
• 영어식 제목을 쓰지 않는다. 기본 제목은 핵심 요약, 핵심 발견, 결정 포인트처럼 한글로 쓴다.

공공기관 보고서 보조용일 때

official-report-skillset에 넘기기 좋도록 아래 4가지를 먼저 정리한다.

## 보고서 반영용 근거 메모

- 보고서에 넣을 핵심 근거:
- 정책·법령·지침 근거:
- 유사기관 사례:
- 리스크와 반대 논리:
- 추가 확인 필요사항:

---

품질 기준

1. 주요 주장에는 출처를 붙인다.
2. 검색 결과보다 본문 확인을 우선한다.
3. 핵심 공식자료의 첨부 PDF를 최소 1개 이상 확인한다.
4. 공식자료와 원출처를 우선한다.
5. 단일 출처 주장은 단일 출처라고 표시한다.
6. 숫자에는 기준일·출처·산식을 확인한다.
7. 모르는 것은 모른다고 쓴다.
8. 반대 근거와 실패 조건을 숨기지 않는다.
9. 자료를 많이 모으기보다 의사결정에 필요한 근거를 남긴다.
10. 최종 답변은 조사 로그가 아니라 판단 브리프로 쓴다.

완료 전 검증

보고서를 파일로 저장했다면 가능한 경우 아래 스크립트로 최소 구조를 확인한다.

python -X utf8 skills\deep-research-pro\scripts\validate_report.py outputs\research\YYYY-MM-DD-<slug>\report.md --min-sources 3

핵심 출처가 PDF 첨부 중심인 주제라면 아래 옵션까지 사용한다.

python -X utf8 skills\deep-research-pro\scripts\validate_report.py outputs\research\YYYY-MM-DD-<slug>\report.md --min-sources 3 --require-pdf-evidence

보고서에 반대검토와 결정 포인트까지 요구할 때는 아래 옵션을 함께 사용한다.

python -X utf8 skills\deep-research-pro\scripts\validate_report.py outputs\research\YYYY-MM-DD-<slug>\report.md --min-sources 3 --require-pdf-evidence --require-analysis-depth

검증이 실패하면 누락된 섹션, 출처 수, 한계 표시, 반대검토, 결정 포인트를 보완한 뒤 다시 저장한다.

---

Sub-agent 사용 기준

아래 조건이면 sub-agent를 써도 좋다.

• 연구 질문이 4개 이상이고 출처 확인이 많을 때
• 긴 PDF·보고서 여러 개를 읽어야 할 때
• 본 작업과 병렬로 조사만 분리하면 효율적인 때

sub-agent에게는 아래처럼 맡긴다.

주제: [TOPIC]
목적: [의사결정/보고서 근거/시장조사/문헌검토]
범위: [기간/국가/기관/산업]
요구사항:
- deep-research-pro OpenClaw Edition 기준으로 조사
- 연구 질문 3~5개로 분해
- web_search/web_fetch/browser/pdf/korean-law 도구 사용
- 핵심 출처 본문과 첨부 PDF 최소 1개 확인
- 단일 출처 주장은 표시
- 결과는 핵심 요약, 핵심 발견, 공통으로 확인된 점, 엇갈리거나 조심할 점, 결정 포인트, 출처 목록으로 반환

---

스모크 테스트 기준

스킬 수정 후 빠르게 작동 확인이 필요하면 아래 소형 테스트를 수행한다.

주제: 공공기관 생성형 AI 도입 시 핵심 점검사항
목표: web_search → web_fetch/browser → PDF 본문 확인 → korean-law → 반대검토 → 결정 포인트 → report.md 저장 → validate_report.py 검증 경로가 작동하는지 확인
최소 출처:
- NIA 공공부문 초거대 AI 도입·활용 가이드라인
- 개인정보보호위원회 생성형 AI 개인정보 처리 안내서
- 행정안전부 공공부문 AI 윤리원칙 또는 관련 보도자료
- 개인정보 보호법 자동화된 결정 관련 조문
완료 기준:
- 공식 출처 3개 이상 확인
- 법령 도구 1회 이상 확인
- 핵심 PDF 첨부 1개 이상 본문 확인
- PDF URL 실패 시 `source_fetch.py` 또는 `pdf_text_extract.py` 대체 경로 1회 이상 시도하고 결과 기록
- `outputs/research/YYYY-MM-DD-<slug>/report.md` 저장
- 실패한 도구와 대체 경로 기록
- 반대 근거 또는 실패 조건 기록
- 결정 포인트 기록
- `validate_report.py --min-sources 3 --require-pdf-evidence --require-analysis-depth` 통과

예시 요청

- 공공기관 생성형 AI 도입 가이드라인을 출처 달아서 조사해줘
- AI 사후관리 자동화 정책 사례를 심층조사해줘
- 국내외 학자금 대출 회수 전략 사례를 보고서 근거로 쓸 수 있게 조사해줘
- 미국 핀테크 대출 리스크 관리 사례를 깊게 정리해줘
- 특정 기업/산업/기술 동향을 의사결정용 리포트로 정리해줘