rnd-policy-research-orchestrator · git:20260719.adbf53c · 2026-07-19 · sha256 4f65358f88a4cda7
rnd-policy-research-orchestrator git:20260719.adbf53cA
Immutable. This exact content never changes and is served at /api/v1/blob/4f65358f88a4cda7.
---
name: rnd-policy-research-orchestrator
description: "실제 정책연구를 수행하고 정책연구보고서를 작성하는 에이전트 팀 오케스트레이터. 연구주제·메모·기존자료를 받아 연구설계→설계검토 게이트→근거조사→집필→초안검수→한글 hwpx 변환까지 5인 팀(policy-research-designer, policy-research-investigator, policy-report-writer, policy-report-reviewer, hwpx-exporter)을 조율한다. OmO식 2단계 검증(집필 전 설계 게이트 + 집필 후 초안검수)이 핵심. 표준 보고서(50p+)와 단형 정책브리프(4~8p) 두 산출 모드를 지원한다. '정책연구', '정책연구보고서', '정책분석', '정책과제', '정책연구과제', '현안분석', '정책대안 연구', '정책 보고서 작성', '정책브리프', '이슈페이퍼', '단형 정책보고서', 'R&D Brief', '정책 이슈 브리프', '요약 브리프' 요청 시 반드시 사용. 후속 작업: 정책연구 수정, 부분 재실행, 업데이트, 보완, 다시 작성, 특정 장만 다시, 설계 다시, 목차 검토·승인, 분량 늘리기·줄이기, 브리프로 압축, 참고문헌 정리·출처 검증, 검수 다시, 근거 보강, 기존 보고서 초안·자료 기반 작성/개정, hwpx만 다시 생성, 이전 결과 기반 개선 요청 시에도 반드시 이 스킬을 사용. ※ 정부 R&D '제안서/연구개발계획서' 작성은 이 스킬이 아니라 rnd-proposal-orchestrator를 사용."
---
# 정책연구 오케스트레이터
실제 정책연구를 5인 에이전트 팀으로 수행해 정책연구보고서(.hwpx)를 산출한다. OmO(oh-my-openagent)의 핵심 패턴인 **2단계 검증 게이트**(집필 전 설계 검토 + 집필 후 초안 검수)를 이식했다.
## 실행 모드: 에이전트 팀
## 산출물 모드 — 표준 보고서 vs 단형 브리프
같은 5인 팀·같은 2단계 게이트를 쓰되, 산출물 규모에 따라 **두 모드**로 매개변수만 달리한다. Phase 1에서 사용자 요청·분량 단서로 모드를 판별한다.
| 구분 | 표준 보고서 모드 (기본) | 단형 브리프 모드 |
|------|------------------------|------------------|
| 트리거 | "정책연구보고서", 분량 명시 없음·"자세히" | "브리프", "이슈페이퍼", "R&D Brief", "단형", "요약", "4~8쪽", "짧게" |
| 분량 | 본문 최소 50p | 본문 4~8p (사용자 지정 우선) |
| 목차 | 서론→이론→해외→국내→대안→로드맵→제언→참고문헌(8장) | **압축 목차**: ① 배경·문제제기 → ② 핵심 현황·쟁점 진단 → ③ 핵심 근거(해외·국내 요점만) → ④ 정책제언(우선순위 3~5) → (요약 박스·참고문헌) |
| 설계 게이트 | 정식(reviewer 모드1 + 사용자 목차 승인) | **경량 게이트**: designer가 핵심 메시지·압축 목차만 설계, reviewer 모드1은 "핵심 쟁점·제언이 명확하고 근거가 확보 가능한가"만 빠르게 점검, 사용자 목차 승인 1회 |
| 조사 | 전면 조사(통계·문헌·해외·국내) | 핵심 근거만 표적 조사(제언을 떠받칠 최소 근거 + 출처) |
| 검수 | 5축 정식 검수 | 핵심 3축(논리·근거/출처·정책타당성) 압축 검수 |
| 참고문헌 | 정식 일괄 정리 | 핵심 출처만 간결 정리(본문 인용 1:1 유지) |
**핵심 원칙(공통):** 브리프 모드도 "근거 없는 주장 금지·출처 병기·제언은 실행 수준"은 그대로 지킨다. 짧다고 근거를 빼지 않는다 — 분량만 줄이고 밀도는 유지한다. 브리프는 결정자가 5분 안에 핵심과 제언을 잡도록 **두괄식·요약 박스 우선**으로 쓴다.
아래 워크플로우는 표준 모드 기준이며, 브리프 모드는 위 표대로 각 Phase의 분량·목차·게이트·검수 축을 경량화해 적용한다(에이전트 프롬프트에 "브리프 모드: 본문 N쪽, 압축 목차" 명시).
## 에이전트 구성
| 팀원 | 타입 | 역할 | 스킬 | 출력 |
|------|------|------|------|------|
| policy-research-designer | policy-research-designer | 의도분석 + RQ·분석틀·목차·연구방법 설계 | policy-research-design | `01_research_design.md` |
| policy-report-reviewer | policy-report-reviewer | (모드1) 설계 게이트 / (모드2) 초안 검수 | policy-report-review | `02_design_review.md`, `05_draft_review.md` |
| policy-research-investigator | policy-research-investigator | 통계·문헌·국내외사례·정책배경 조사, 출처 병기 | policy-research | `03_evidence.md` |
| policy-report-writer | policy-report-writer | 본문 집필 (서론→이론적 배경→해외 동향→국내 현황→정책 대안→제언) + 참고문헌 정리 | policy-report-writing | `04_report_draft.md` |
| hwpx-exporter | hwpx-exporter | 한글 hwpx 변환 (공용 재사용) | rnd-hwpx-export | `06_report.hwpx` |
모든 팀원은 기본적으로 세션 모델을 상속해 스폰한다(품질 우선 시 `model: "opus"` — 공개판 실행 노트 참조). 검토관(reviewer)은 파이프라인에서 **두 번** 등판한다(설계 후·초안 후).
## 워크플로우
### Phase 0: 컨텍스트 확인 (후속 작업 지원)
작업 디렉토리의 `_workspace/` 존재 여부로 실행 모드를 결정한다:
- **`_workspace/` 미존재** → 초기 실행. Phase 1로.
- **`_workspace/` 존재 + 부분 수정 요청** (예: "설계 다시", "5장만 다시", "근거 보강", "검수 다시", "hwpx만 재생성") → 부분 재실행. 해당 에이전트만 재호출하고 그 산출물만 갱신한다. 의존 산출물(설계 변경 시 → 조사·집필·검수도 영향)을 함께 갱신할지 판단한다.
- **`_workspace/` 존재 + 새 주제/새 입력 제공** → 새 실행. 기존 `_workspace/`를 `_workspace_{YYYYMMDD_HHMMSS}/`로 이동 후 Phase 1로.
부분 재실행 시 이전 산출물 경로를 해당 에이전트 프롬프트에 포함해, 기존 결과를 읽고 피드백을 반영하도록 지시한다.
### Phase 1: 준비 (입력 수집 + 자료 라우팅)
1. 사용자 입력 분석 — 연구 주제, 정책 맥락, 메모, **기존 보고서 초안·관련 자료·통계·논문**, 산출물 수준·분량(기본 **최소 50p**), 출력 경로, 지정 양식 유무를 파악한다.
2. `_workspace/` 생성 (새 실행이면 기존 것을 타임스탬프 디렉토리로 이동 후 재생성).
3. **입력 자료 저장 + 인덱싱** — 사용자가 준 모든 자료를 `_workspace/00_input/`에 저장하고, `_workspace/00_input/_index.md`에 "파일명 — 성격(초안/통계/논문/메모) — 어느 단계·에이전트가 쓸지"를 한 줄씩 기록한다. **이 인덱스가 라우팅의 핵심**: 오케스트레이터가 각 에이전트 스폰 프롬프트에 "읽을 입력 파일 경로 + 용도"를 명시해 배분한다.
- **자료 라우팅 규칙:** 정책 방향·범위 단서 → designer / 통계·문헌·사례·출처 → investigator / **기존 초안** → writer(베이스로 개정) + reviewer(검수 대상) / 양식 → hwpx-exporter.
- **사용자가 기존 초안을 제공한 경우:** 백지 집필이 아니라 그 초안을 출발점으로 삼는다. designer는 초안의 구조를 분석해 목차를 역설계·보완하고, investigator는 초안 주장의 출처를 검증·보강하며, writer는 초안을 개정한다. 이 분기를 각 에이전트 프롬프트에 명시한다.
4. 주제가 막연하면 Phase 3의 설계자가 사용자 확인 질문을 만들 것이므로, 여기서는 명백한 누락만 짚는다.
### Phase 2: 팀 구성
1. `TeamCreate(team_name: "policy-research-team", members: [...])` — 위 5개 팀원을 각 에이전트 정의(custom type)로로 스폰한다. 각 프롬프트에 담당 스킬명·`_workspace/` 경로·입출력 파일·hwpx 입출력 경로(`04_report_draft.md`→`06_report.hwpx`)를 명시한다.
2. `TaskCreate`로 의존성 있는 작업을 등록한다:
- T1 연구설계 (designer)
- T2 **설계 검토 게이트** (reviewer 모드1) — `depends_on: [T1]`
- T3 근거조사 (investigator) — `depends_on: [T2 승인]` (승인된 목차의 필요근거를 조사)
- T4 집필 (writer) — `depends_on: [T2 승인, T3]`
- T5 초안검수 (reviewer 모드2) — `depends_on: [T4]`
- T6 hwpx 변환 (exporter) — `depends_on: [T5 승인]`
### Phase 3: 설계 + 게이트 (생성-검증 루프 ①)
**실행 방식:** designer ↔ reviewer(모드1) 피드백 루프
1. designer가 의도분석 + RQ·분석틀·목차·연구방법을 설계해 `01_research_design.md`를 작성한다.
- **사용자 확인 질문이 나오면** 리더는 이를 사용자에게 전달하고 답을 받아 designer에 반영시킨다(조사·집필 착수 전에).
2. designer가 reviewer에게 "설계 검토 요청"을 SendMessage로 보낸다.
3. reviewer(모드1)가 `01`을 검토해 `02_design_review.md`에 판정(승인/조건부/반려)을 쓴다.
4. 반려·조건부면 designer가 `01`을 개정 → 재검토. **최대 2회.** 2회 후에도 미승인 항목은 "설계 잔여 리스크"로 기록하고 진행한다.
5. **★ 목차 사용자 승인 게이트 (필수)** — 설계 게이트를 통과하면, 리더는 **목차(장·절) + 핵심 RQ + 분석틀 요약**을 사용자에게 제시하고 승인을 받는다. (검토관의 내부 게이트는 "실행 가능성"을, 이 게이트는 "사용자 의도 부합"을 본다.)
- 사용자가 목차를 수정·추가·삭제하면 designer가 `01`에 반영 후 다시 제시한다.
- **사용자 승인(또는 명시적 "그대로 진행") 전에는 Phase 4(조사)로 넘어가지 않는다.** 50p급 보고서는 목차 한 줄이 며칠치 조사·집필을 좌우하므로 이 게이트가 비싼 헛작업을 막는다.
6. **설계 게이트 통과 + 사용자 목차 승인 후에만** Phase 4로 넘어간다.
### Phase 4: 근거조사
**실행 방식:** investigator 단독 (병렬 조사 가능)
1. designer가 승인 목차의 항목별 "조사 우선순위·필요근거"를 investigator에게 전달한다.
2. investigator가 통계·문헌·국내외사례·정책배경을 조사해 `03_evidence.md`에 출처와 함께 정리한다. 미확보 항목은 명시한다.
3. 완료 시 writer에게 알린다.
### Phase 5: 집필 + 검수 (생성-검증 루프 ②)
**실행 방식:** writer ↔ reviewer(모드2) 피드백 루프
1. writer가 `01`(승인 설계)·`03`(근거)·`00_input/`의 사용자 자료(기존 초안 있으면 베이스로)를 종합해 `04_report_draft.md`를 작성한다.
- **표준 목차:** 1.서론 → 2.이론적 배경 → 3.해외 동향 분석 → 4.국내 현황 분석 → 5.정책 대안 → 6.정책 우선순위·추진 로드맵 → 7.정책제언·결론 → **참고문헌**(말미). (사용자 승인 목차가 우선)
- **분량: 본문 최소 50p.** 분량 미달 시 각 장 심도를 보강한다(분야별 심화·근거 추가·대안 정교화). 빈 말로 늘리지 말고 근거·분석으로 채운다.
- **참고문헌 필수:** 본문에서 인용한 모든 출처를 말미에 일관 형식(기관·문서명·연도·URL/페이지)으로 정리하고, 본문 인용과 1:1 대응시킨다.
2. reviewer(모드2)가 `04`를 `01`·`03`과 교차검증해 **5축(논리/근거/정책타당성/정량성 + 참고문헌·출처 검증)**으로 `05_draft_review.md`에 수정 요청을 쓴다.
- **출처 검증:** 본문 인용 ↔ 참고문헌 목록 일치, 각 출처의 실재·접근가능성, 인용 수치와 출처 내용 일치, 미검증·불일치 출처 플래그. 분량 50p 충족 여부도 점검한다.
3. writer가 [필수]·[권고] 지적을 반영해 `04`를 개정한다. **최대 2회 반복.** 동일 항목 2회 미해결은 "잔여 리스크"로 기록하고 진행.
> **운영 유의(검증된 사항):** 백그라운드로 재개(SendMessage)된 서브에이전트는 Write/Edit 권한이 거부될 수 있다. 따라서 writer 수정 루프는 **전경(foreground) Agent 호출**로 실행하거나, reviewer가 승인한 비창작성 수정안을 **오케스트레이터(리더)가 직접 Edit로 반영**한다. 사용자 입력이 필요한 항목(예: 미확보 통계)은 `[보강 필요]`로 남긴다.
4. 검수 통과 시 reviewer가 "초안 승인"을 리더와 hwpx-exporter에게 알린다.
### Phase 6: 변환
**실행 방식:** 승인 후 변환
1. hwpx-exporter가 승인된 `04_report_draft.md`를 입력으로 받는다.
2. `00_input/`에 지정 양식이 있으면 폼 채우기, 없으면 표준 생성으로 .hwpx를 만든다.
3. 변환 후 재파싱 자체검증, 분량·양식 점검.
4. 최종 산출물을 사용자 지정 경로에, 사본을 `_workspace/06_report.hwpx`에 저장한다.
### Phase 7: 정리·보고
1. 팀원에게 종료 요청(SendMessage) 후 `TeamDelete`.
2. `_workspace/`는 보존한다 (사후 검증·재실행용).
3. 사용자에게 요약 보고: 최종 hwpx 경로, RQ에 대한 답 요약, 핵심 정책제언, 잔여 리스크·`[보강 필요]`·미확보 근거, 입력 자료 한계.
4. 피드백을 요청한다 ("수정하거나 보완할 부분이 있나요?").
## 데이터 흐름
```
[리더] TeamCreate + TaskCreate
policy-research-designer ──01_research_design.md──┐
▲ │ SendMessage(설계 검토 요청) │
(개정,최대2회) ▼ ▼
policy-report-reviewer(모드1) ──02_design_review.md (게이트)
│ "설계 승인"
▼ (승인 후에만 진행)
policy-research-investigator ──03_evidence.md──┐
▼
policy-report-writer ──04_report_draft.md──┐
▲ │ │
SendMessage(수정요청) │ (최대 2회 루프) ▼
policy-report-reviewer(모드2) ──05_draft_review.md
│ "초안 승인" │
▼ │
hwpx-exporter ◀──────────04 승인본───────────┘
│
▼
06_report.hwpx → 사용자 지정 경로
```
## 에러 핸들링
| 상황 | 전략 |
|------|------|
| 팀원 1명 실패/중지 | 리더가 감지 → SendMessage로 상태 확인 → 재시작. 실패 시 해당 산출물 없이 진행하고 보고서에 누락 명시 |
| 설계 게이트 무한 반려 | 동일 항목 2회 초과 미해결 → "설계 잔여 리스크"로 기록 후 진행(완전 차단 방지) |
| 근거 미확보 | investigator가 "미확보"로 명시 → writer가 `[보강 필요]` 표시 → 보고서·최종보고에 명시 |
| 초안 검수 무한 루프 | 동일 항목 2회 초과 미해결 → 잔여 리스크로 기록 후 진행 |
| 상충 근거 | 출처 병기, 삭제 금지. reviewer가 판단·권고 |
| 사용자 확인 질문 미응답 | 합리적 기본값으로 가정하고 "가정 사항"으로 명시, 진행 |
| 지정 양식 파싱 실패 | 표준 hwpx 생성으로 전환, 수동 확인 권장 안내 |
| 백그라운드 Write/Edit 거부 | writer 수정 루프를 전경 호출로 전환 또는 리더가 직접 Edit 반영(위 Phase 5 유의 참조) |
## 테스트 시나리오
### 정상 흐름
1. 사용자가 "청년 1인가구 주거비 부담 완화 정책 연구" 주제 + 메모 제공
2. Phase 1: `_workspace/` 생성, 입력 저장
3. Phase 2: 5인 팀 + 6개 작업(게이트 의존성 포함) 등록
4. Phase 3: designer가 RQ 2개·분석틀(현황→쟁점→대안 비교)·목차 설계 → reviewer 모드1이 "3장 근거 확보 난이도" 지적 → designer 개정 → 승인
5. Phase 4: investigator가 주거실태조사·RIR 지표·해외사례(독일·일본) 조사
6. Phase 5: writer 초안 → reviewer 모드2가 [필수]2·[권고]3 지적 → writer 반영 → 승인
7. Phase 6: 표준 hwpx 생성, 재파싱 검증 통과
8. Phase 7: 데스크탑에 `청년주거_정책연구보고서.hwpx` + RQ 답·핵심 제언 보고
9. 예상 결과: 지정 경로에 hwpx, `_workspace/`에 01~06 산출물 보존
### 에러 흐름
1. Phase 3에서 설계 게이트가 "RQ가 너무 광범위"로 조건부 승인 → designer가 RQ 범위 축소 → 승인
2. Phase 4에서 investigator가 2024년 잠정통계 미공표로 일부 미확보 → `03`에 "미확보" 기록
3. writer가 해당 부분 `[보강 필요]` 표시 후 진행
4. Phase 5 검수에서 해당 항목 확인, 잔여 리스크로 수용
5. 최종 보고에 "2024년 잠정치 미확보 — 공표 후 갱신 권장" 명시
## 공개판 실행 노트 (플러그인 배포판)
- **에이전트 이름 네임스페이스** — 플러그인으로 설치하면 에이전트 타입이 `<플러그인명>:<에이전트명>`(예: `policy-research-kit:policy-research-designer`)으로 표시될 수 있다. 이 문서의 에이전트명은 접미 이름 기준이며, 실제 스폰 시에는 현재 세션의 에이전트 목록에 표시되는 이름을 그대로 쓴다.
- **팀 API 폴백 (중요)** — `TeamCreate`/`TaskCreate`/팀 `SendMessage`(에이전트 팀 실험 기능)가 없는 환경에서는 같은 파이프라인을 **전경(foreground) `Agent` 호출의 순차 실행**으로 수행한다. Phase 순서(설계→게이트→조사→집필→검수→변환)와 산출물 파일 계약은 동일하며, 이 폴백은 실전 검증된 방식이다. 특히 수정 루프는 전경 실행을 권장한다(백그라운드로 재개된 서브에이전트는 Write/Edit가 거부될 수 있음 — 이 경우 리더가 승인된 수정안을 직접 반영).
- **모델** — 기본은 세션 모델 상속(`model: inherit`). 품질을 우선하려면 스폰 시 `model: "opus"` 등 상위 모델을 명시한다.
- **한글(.hwpx) 변환 의존성** — hwpx 산출은 kordoc MCP(제3자, `npx kordoc@latest mcp`)에 의존한다. 미설치 환경에서는 마크다운/docx 산출까지 진행하고 변환 단계만 보류하면 된다.