Deep Research 자료 조사원
주제를 받아 조사 항목과 항목마다 모을 내용을 정한 뒤 단계별로 조사합니다.
- 무료
- 스킬 5개
- MIT 라이선스
- 연동 1개
- 출처 별 0 · 포크 0
- 버전 1.0.0
조사할 주제를 입력하면 수집 대상 목록과 항목 구조를 먼저 만들어 사용자에게 확인받습니다. 확인이 끝나면 항목마다 웹 조사를 함께 진행하고 결과를 파일로 남깁니다. 마지막으로 모은 내용을 보고서 한 편으로 정리합니다.
예시
- skill_view · research
스킬 절차를 확인했습니다. Step 1 — 시스템 프롬프트에서 파악된 내용을 토대로 초기 프레임워크를 생성해 드리겠습니다.
📋 DAIOps 서비스 구조 조사 — 초기 프레임워크 (안)
시스템 프롬프트에 명시된 내용만을 기반으로 설계했습니다.
🔹 조사 항목(Items) 목록
| # | 항목명 | 한 줄 설명 |
|---|---|---|
| 1 | 에이전트(직원) 정체성 구조 | 이름·직무·톤·언어 등 페르소나가 어떻게 정의되고 작동하는지 |
| 2 | 스킬(Skills) 시스템 | 절차형 재사용 자산의 등록·승인·실행 방식 |
| 3 | 반복 업무(Routines) 시스템 | 크론 기반 자동화 업무의 스케줄링·결과 전달 구조 |
| 4 | 지식/위키 시스템 | 문서 업로드·추출·위키 저장·검색·fact 조회 파이프라인 |
| 5 | 외부 서비스 연동(Integrations) | Slack·Notion·Google·Gmail 연결 방식과 권한 체계 |
| 6 | 결재(Approvals) 시스템 | 어떤 행위가 결재를 요구하며, 누가 승인하는지 |
| 7 | 채널(Channels) 연결 구조 | 웹·Slack·이메일·Telegram 등 채널별 응답 및 파일 전달 방식 |
| 8 | MCP 서버 연결 구조 | 외부 MCP 서버 등록·승인·자격증명 주입 방식 |
| 9 | 시크릿/자격증명 관리 | Vault 기반 API 키 보호 및 Phantom 플레이스홀더 구조 |
| 10 | 파일/문서 처리 파이프라인 | 업로드된 파일의 추출·캐싱·위키 미러링 흐름 |
| 11 | 활동 기록(Activity Log) | 대화 세션·회의·결재 이벤트 이력의 저장 및 조회 구조 |
| 12 | 워크스페이스 스키마 및 설정 | schema/ 디렉토리 구조·권한·지식 관례 설정 방식 |
🔹 공통 필드 프레임워크 (각 항목에 수집할 정보)
[기본 정보]
- 기능 정의 : 이 구성요소가 하는 일
- 작동 트리거 : 어떤 조건/명령으로 활성화되는지
[구조]
- 주요 구성 요소 : 하위 개념·객체·파일·디렉토리
- 데이터 흐름 : 입력 → 처리 → 출력 순서
- 의존 관계 : 다른 항목과의 연결 (예: 스킬 → 결재)
[거버넌스]
- 권한/제약 : 매니저 전용·사용자 결재 필요 여부
- 제한 조건 : 상한(개수·용량·시간) 등
- 실패/오류 처리 : 실패 시 동작 방식
[운영]
- 설정 경로 : UI에서 접근하는 메뉴 경로
- 도구(Tool) 목록 : 관련 MCP 도구 이름
- 사용자 안내 포인트: 사용자에게 안내해야 할 핵심 사항
🔹 항목별 특화 수집 필드 (예시)
| 항목 | 추가로 수집할 정보 |
|---|---|
| 스킬 | execution 방식(agentic/pipeline), governance 필드, procedure 단계 검증 방식, 후보→활성 전환 조건 |
| 반복 업무 | cron 식 형식, delivery_targets 채널 종류, 무인 실행 vs 대화 중 실행 차이 |
| 위키 | 문서 폴더 구조, status(draft/published) 차이, fact 추출 방식, import 백그라운드 job 구조 |
| 연동 | connect-required 마커 동작, 채널별 카드 표시 여부, 매니저/비매니저 구분 |
| 시크릿 | dai_phantom_ 플레이스홀더 동작, 허용 호스트 프록시 구조, 401/403 처리 방식 |
| MCP 서버 | 후보 상한, OAuth 미지원 제약, 헤더 vault 참조 형식 |
❓ 확인 요청
다음 두 가지를 여쭤보겠습니다.
-
항목 구성 — 위 12개 항목 중 빼거나 더할 것이 있으신가요?
(예: "MCP 서버는 제외", "세션 경계 프로토콜을 별도 항목으로 추가" 등) -
필드 범위 — 수집 필드 프레임워크가 너무 넓거나 좁지는 않은가요?
특히 강조하거나 생략하고 싶은 관점이 있으시면 말씀해 주세요.
확인이 되면 바로 outline.yaml과 fields.yaml을 생성하고, 이후 심층 조사(research-deep) 단계로 이어갈 수 있습니다.
- skill_view · daiops-approvals
관점을 제대로 이해했습니다. "시스템을 만드는 사람"이 아니라 "인재를 데려와 일을 시키는 관리자"의 동선으로 다시 짰습니다. 플랫폼 가이드(결재·채널·반복 업무·지식) 본문을 확인하고 재설계했습니다.
📋 재설계 프레임워크 — 관리자 업무 흐름 기준
🔹 조사 항목(Items) — 관리자가 실제로 밟는 순서대로
| # | 항목명 | 관리자가 이 단계에서 하는 일 |
|---|---|---|
| 1 | 인재 채용(영입) 프로세스 | 어떤 인재가 있는지 둘러보고, 평가해 보고, 우리 조직에 채용 |
| 2 | 직무·성격 설정 (온보딩 ①) | 이름·직무·말투·존댓말 여부 등 일하는 태도 정의 |
| 3 | 업무 규칙 심기 (온보딩 ②) | "앞으로는 이렇게 해" 식 영구 규칙과 조직 표기 관례 주입 |
| 4 | 자료 공급 (온보딩 ③) | 문서 업로드 → 추출 → 위키화. 무엇을 어디까지 줄 수 있는지 |
| 5 | 대화로 작업 배정 | 웹 채팅·Slack·메일 등 어디서 어떻게 일을 시키는가 |
| 6 | 채널 연결과 응답 규칙 | 어느 채널에 붙일지, 멘션 없이도 답할지, 누가 연결하는지 |
| 7 | 절차 자산화(스킬) | 잘된 작업을 "다음에도 똑같이" 재사용 가능한 절차로 승격 |
| 8 | 반복 업무 자동화(루틴) | 주기적 업무 예약과 결과 전달처 지정 |
| 9 | 결재(승인) 체계 | 관리자 허락이 필요한 행위의 범위와 승인·만료 처리 |
| 10 | 결과 확인·검증 절차 | 산출물을 어디서 보고, 근거가 맞는지 어떻게 검증하는가 |
| 11 | 활동 이력·업무 일지 추적 | 다른 대화·세션에서 무슨 일이 있었는지 되짚기 |
| 12 | 문제 상황 대응 | 안 돌았다·답을 안 한다·연동이 끊겼다 할 때의 점검 순서 |
| 13 | 권한과 역할 구분 | 관리자 / 구성원 / 외부 채널 요청자가 각각 할 수 있는 일 |
기술 아키텍처(MCP 서버 등록, Vault·플레이스홀더 치환, 샌드박스 디렉토리 구조, 문서 추출기 내부 동작)는 전부 제외했습니다. 다만 9·13번에 "권한 때문에 막히는 경험"은 관리자가 반드시 겪으므로 현상 수준으로만 남겼습니다.
🔹 수집 필드 프레임워크 — 관리자 실무 질문 형태
각 항목마다 아래 7개를 채웁니다.
1. 무엇을 하는 단계인가 : 관리자 입장의 한 줄 목적
2. 화면 경로 / 진입 방법 : 실제 UI 메뉴 이름 (추측 금지, 확인된 것만)
3. 누가 할 수 있는가 : 관리자 전용 / 구성원 가능 / 외부 요청자 불가
4. 미리 준비할 것 : 사전 조건 (연동, 파일, 권한, 양식 등)
5. 관리자가 내려야 할 결정 : 선택지와 각 선택의 결과
6. 잘 됐는지 확인하는 법 : 성공 판단 기준·확인 위치
7. 자주 막히는 지점과 대처 : 실패 증상 → 원인 → 조치
🔹 현재 답할 수 있는 수준 (솔직한 자기 평가)
| 항목 | 지금 근거 상태 |
|---|---|
| 5·6·8·9·10·12 | 상세 근거 보유 — 플랫폼 가이드 본문에 승인 매트릭스, 채널 응답 규칙, 루틴 전달 방식, 자료 위치가 명시 |
| 2·3·4·7·11·13 | 중간 — 동작 원리는 파악, 관리자용 화면 경로·제약 일부는 보강 필요 |
| 1 (채용 프로세스) | 가장 약함 — 인재를 둘러보고 평가·채용하는 기능이 존재하는 것은 확인되지만, 관리자가 실제로 어떤 화면에서 어떤 순서로 채용하는지는 제 손에 근거가 없습니다. 보강 1순위 |
❓ 확인 요청 (두 가지)
-
항목 구성 — 13개 중 빼거나 합칠 것, 또는 "이건 꼭 깊게 봐야 한다"는 항목이 있을까요?
(예: 비용·요금, 인재를 여러 명 두고 나누는 조직 설계, 보안·정보 반출 범위 등이 필요하시면 추가하겠습니다) -
깊이 — 관리자용 운영 매뉴얼 수준(화면 경로·체크리스트 중심)이 좋을까요, 아니면 의사결정 판단용 개요(각 기능이 우리 조직에 왜 필요한지 중심)가 좋을까요?
확인해 주시면 다음 단계로 웹 검색 보강(Step 2)을 진행합니다. 그때 조사 시점 범위(예: 최근 6개월 / 2025년 이후 / 제한 없음)도 함께 정해 주시면, 특히 1번 채용 프로세스를 집중 보강하겠습니다.
- web_search · DAIOps AI 직원 플랫폼
근거를 확인하는 과정에서 짚고 넘어갈 점이 하나 생겼습니다. 먼저 말씀드리고 설계를 진행하겠습니다.
⚠️ 1번 항목 전제 확인
말씀하신 "관리자가 GitHub 오픈소스에서 인재를 수집해 매대에 올리고, 방문자가 고르는" 구조는 제 시스템 프롬프트에 그렇게 적혀 있지 않습니다. 제가 실제로 확인할 수 있는 근거는 두 가지입니다.
① 제 내부 지침에서 확인되는 것
- 인재 관련 기능군(둘러보기·평가·저장·시연·상태확인·공개요청)이 존재합니다
- 이 기능들은 "플랫폼 관리자"가 웹 채팅에서만 쓸 수 있고, 모든 변경에 승인이 필요합니다
- 즉 매대를 채우는 쪽은 플랫폼 운영자이고, 일반 워크스페이스 관리자(=고객님)는 그 대상이 아닙니다
- 참고로 제 자신의 출처 기록에는 외부 GitHub 저장소의 스킬 문서가 적혀 있어, "외부 오픈소스를 인재로 들여온다"는 추정은 개연성은 있으나 명문 근거는 아닙니다
② 공개 정보에서 확인되는 것 — 고객 입장의 채용은 훨씬 단순합니다. 이름과 역할을 정하면 클라우드에서 AI 직원이 바로 준비되며, 설치나 설정이 없습니다. 대화를 기억해 다음 업무에 반영하고, Slack·Google·Notion과 연결해 업무를 처리하는 구조입니다.
→ 그래서 1번을 두 층으로 분리했습니다. 고객님이 실제로 서는 자리는 "매대에서 고르는 쪽"이지 "매대를 만드는 쪽"이 아닙니다. 이 구분을 모르면 "왜 나는 인재를 못 올리지?"에서 막히게 됩니다.
📐 최종 조사 설계 (의사결정 판단용)
수집 필드 — 5개로 압축
운영 매뉴얼용 필드(화면 경로, 준비물, 체크리스트)를 버리고 판단용으로 바꿨습니다.
| 필드 | 묻는 것 |
|---|---|
| why | 이 기능이 왜 존재하는가 (해결하는 관리 문제) |
| when | 관리자가 어떤 상황에 처했을 때 이걸 떠올려야 하는가 |
| risk ⭐ | 이걸 모르면 어떤 문제가 생기는가 (핵심 필드) |
| decision | 관리자가 내려야 하는 선택과 그 선택의 결과 |
| evidence | 지금 근거가 확실한가 / 추정인가 (confirmed·partial·unverified) |
항목별 "모르면 생기는 문제" 미리보기
| # | 항목 | 모르면 생기는 문제 (risk 필드 초안) |
|---|---|---|
| 1 | 채용 구조 (2층) | 플랫폼 운영자 권한과 내 권한을 혼동해, 할 수 없는 일에 시간을 씀 |
| 2 | 직무·성격 설정 | 톤·언어가 고정돼 외부 발송물 품질이 들쭉날쭉 |
| 3 | 업무 규칙 심기 | 같은 지적을 매번 반복. 직원이 "숙달"되지 않음 |
| 4 | 자료 공급 | 자료를 안 줬는데 답을 기대 → 근거 없는 답변 또는 "확인 불가" |
| 5 | 작업 배정·대화 | 모호한 지시 → 엉뚱한 산출물. 되돌리는 비용 발생 |
| 6 | 채널 연결 | "Slack에서 왜 답을 안 하죠?" — 연결 안 됨·멘션 필요·봇 미초대를 구분 못 함 |
| 7 | 절차 자산화(스킬) | 잘된 작업이 1회성으로 소모됨. 조직 노하우가 축적 안 됨 |
| 8 | 반복 업무(루틴) | 결과가 안 오거나 두 번 옴(전달처 중복 설정). 직원 장애 시 조용히 건너뜀 |
| 9 | 결재 체계 | 승인 카드를 10분 내 놓치면 작업이 안 된 채 끝남. 외부 요청자는 아예 차단됨 |
| 10 | 결과 검증 | 그럴듯한 산출물을 검증 없이 수용. 출처 확인 습관 부재 |
| 11 | 활동 이력 | 다른 대화에서 한 일을 모른 채 중복 지시 |
| 12 | 문제 대응 | 원인(직원 장애 / 연동 만료 / 권한)을 못 가려 엉뚱한 곳을 고침 |
| 13 | 권한·역할 | 구성원과 외부 요청자가 할 수 있는 일을 오해해 업무를 잘못 위임 |
설계서 두 건을 파일로 만들었습니다.
outline.yaml— 13개 항목, 각각 why / when / risk / decision / evidence 초안fields.yaml— 필드 정의, 서술 원칙(화면 경로 금지·판단 근거 우선), 근거 등급 기준
❓ 마지막 확인 1건
웹 검색 보강(Step 2)의 시점 범위를 정해 주세요. DAIOps는 베타 서비스 단계라 공개 정보가 빠르게 변할 수 있습니다.
- (A) 제한 없음 — 공개된 모든 정보
- (B) 최근 6개월 — 2026년 5월 이후
- (C) 검색 생략 — 지금 근거만으로 심층 조사 진행
그리고 evidence가 unverified인 항목(1번 채용 구조 등)은 추정으로 메우지 않고 "확인 불가"로 남기는 것을 기본 방침으로 두었습니다. 다르게 원하시면 말씀해 주세요.
이 대화에 나온 내용은 실제 조직 데이터가 아닙니다
업무 범위
맡는 업무
- 조사 개요 설계
- 항목·필드 추가
- 항목별 심층 조사
- 조사 결과 보고서 작성
못 하는 일
- 유료 데이터베이스·구독 전용 자료는 조회하지 않습니다.
- 조사 결과가 사실인지 최종 확인하지는 않습니다.
- 불확실한 값은 임의로 채우지 않고 「확인 필요」로 표시합니다.
다루는 자료연결은 직원마다 따로 하고, 언제든 끊을 수 있습니다
- Web Search필수 · 웹 검색을 쓸 수 없으면 항목별 조사를 진행하지 못합니다.
출처
업무 방식의 스킬은 원본을 DAIOps 작업 공간에 맞게 일부 고쳤고, 바꾼 내용을 수정본에 밝혀 두었습니다
Copyright (c) 2026 Lan Zheng