A06
RFP · 과업지시서 해체
RFP 원문을 요구 항목표로 분해하고, 적혀 있지 않은 사항을 질의 목록으로 도출.
- 형식
- 프롬프트
- 붙이는 곳
- 대화창에 붙여넣기
- 분량
- 74줄
- 업무 단계
- 기회 해체
- 버전
- v0.1 · 2026. 8. 10.
언제 쓰나
- 수십 쪽 분량의 RFP를 접수하고 단기간에 참여 여부를 결정해야 할 때
- 사전 질의 마감이 임박했으나 질의 항목이 정리되지 않을 때
- 여러 담당자가 RFP를 분담해 검토한 뒤 해석이 상이할 때
안 쓰는 경우
요구사항이 정리된 문서나 자체 작성한 제안 요청 초안에는 적합하지 않습니다. 구조화된 문서를 재구조화하는 비용만 발생합니다.
입력
RFP 또는 과업지시서 원문입니다. 보유 역량 목록이 있으면 대응 가능성 등급까지 산출되며, 없으면 해당 칸은 미확인으로 남습니다. 이 경우에도 질의 목록은 산출됩니다.
사용법
- 전문을 대화창에 붙여넣고 맨 아래 입력 3줄을 채웁니다.
- 산출된 질의 목록을 사전 질의 마감 전에 발주처로 발송합니다.
- 대응 가능성이 미확인인 행부터 내부 확인을 진행합니다.
본문
<!-- RFP·과업지시서 해체 프롬프트 v0.1 · https://namtank96.github.io/assets/a06-rfp-decompose -->
# RFP · 과업지시서 해체
원문을 요구 항목표로 분해하고, **적혀 있지 않은 것**을 질의 목록으로 뽑는다.
## 지시
너는 제안 준비 담당자다. 아래 순서를 그대로 따른다.
### 1. 항목표로 분해
원문을 문장 단위로 훑으며 다음 표를 채운다. **한 행 = 한 요구**다.
| # | 원문 인용 | 유형 | 우리 해석 | 근거 | 확신도 | 대응 가능성 | 확인질문 |
|---|---|---|---|---|---|---|---|
- **원문 인용은 다듬지 않는다.** 요약하면 배점 근거가 사라진다. 길면 잘라서 인용하되 문장을 고치지 않는다.
- **원문과 해석을 같은 칸에 넣지 않는다.** 두 칸이 붙어 있어야 나중에 무엇이 발주처 말이고 무엇이 우리 추측인지 구분된다.
- **유형**: `요구` / `제약` / `평가` / `전제` 중 하나.
- `요구` = 만들어야 하는 것
- `제약` = 못 하게 하는 것 (기간·예산·환경·인증)
- `평가` = 점수가 매겨지는 것
- `전제` = 발주처가 당연하다고 가정하고 적지 않은 것
- **확신도**: `낮음`/`중간`/`높음`. 근거가 원문이면 높음, 업종 관행이면 중간, 추측이면 낮음.
- **대응 가능성**: `기구현` / `구성가능` / `신규개발` 3등급.
근거가 없으면 `미확인`으로 둔다. 이 칸이 나중에 견적의 기초가 되므로 추정으로 등급을 매기지 않는다.
- **확인질문**: 확신도가 `낮음`이면 반드시 채운다.
### 2. 평가 항목을 따로 뽑는다
`평가` 유형만 모아 배점표를 만든다. 배점이 명시되지 않았으면 `배점 미공개`로 적는다.
각 평가 항목마다 **우리가 지금 제시할 수 있는 근거**를 한 줄 단다. 없으면 "근거 없음"이라고 적는다.
### 3. 누락 점검: 5축
원문 전체를 훑고 **적혀 있지 않은 것**을 찾는다.
| 축 | 확인 |
|---|---|
| **누가** | 사용자·운영 주체·승인 권한이 명시됐는가 |
| **무엇을** | 대상 데이터·산출물 범위가 명시됐는가 |
| **왜** | 도입 배경·성공 기준·측정 지표가 명시됐는가 |
| **어떻게** | 연동 대상·기존 시스템·마이그레이션 방식이 명시됐는가 |
| **언제** | 단계·마일스톤·검수 시점이 명시됐는가 |
**미기재는 갭이 아니라 질의 대상이다.**
발주처가 말하지 않은 것을 "없는 것" 또는 "우리 마음대로 해도 되는 것"으로 처리하지 않는다.
질의 목록으로 뽑아 사전 질의나 현설에서 확인한다.
### 4. 산출
```
① 요구 항목표 (전체)
② 평가 배점표 + 우리 근거
③ 질의 목록 — 5축별. 각 질문에 "왜 물어야 하는가" 한 줄
④ 리스크 3개 — 제약 유형 중 우리가 못 맞출 소지가 큰 것
⑤ 참여 판단에 필요한 미확인 정보 목록
```
## 입력
- 원문: `{RFP 또는 과업지시서 전문}`
- 우리 보유 역량: `{있으면. 대응 가능성 등급 판단에 씀. 없으면 전부 미확인으로 둔다}`
- 마감: `{사전 질의 마감이 언제인지. ③의 우선순위가 달라진다}`
## 금지
- 원문 문장 수정·요약
- 근거 없는 대응 가능성 등급 부여
- 미기재 항목을 우리에게 유리하게 해석하기
- 질의 목록 없이 항목표만 내기. 그건 그냥 필사다
- "전반적으로 대응 가능" 같은 총평. 행 단위로만 판정한다
<!-- RFP·과업지시서 해체 프롬프트 v0.1 · https://namtank96.github.io/assets/a06-rfp-decompose -->
# RFP · 과업지시서 해체
원문을 요구 항목표로 분해하고, **적혀 있지 않은 것**을 질의 목록으로 뽑는다.
## 지시
너는 제안 준비 담당자다. 아래 순서를 그대로 따른다.
### 1. 항목표로 분해
원문을 문장 단위로 훑으며 다음 표를 채운다. **한 행 = 한 요구**다.
| # | 원문 인용 | 유형 | 우리 해석 | 근거 | 확신도 | 대응 가능성 | 확인질문 |
|---|---|---|---|---|---|---|---|
- **원문 인용은 다듬지 않는다.** 요약하면 배점 근거가 사라진다. 길면 잘라서 인용하되 문장을 고치지 않는다.
- **원문과 해석을 같은 칸에 넣지 않는다.** 두 칸이 붙어 있어야 나중에 무엇이 발주처 말이고 무엇이 우리 추측인지 구분된다.
- **유형**: `요구` / `제약` / `평가` / `전제` 중 하나.
- `요구` = 만들어야 하는 것
- `제약` = 못 하게 하는 것 (기간·예산·환경·인증)
- `평가` = 점수가 매겨지는 것
- `전제` = 발주처가 당연하다고 가정하고 적지 않은 것
- **확신도**: `낮음`/`중간`/`높음`. 근거가 원문이면 높음, 업종 관행이면 중간, 추측이면 낮음.
- **대응 가능성**: `기구현` / `구성가능` / `신규개발` 3등급.
근거가 없으면 `미확인`으로 둔다. 이 칸이 나중에 견적의 기초가 되므로 추정으로 등급을 매기지 않는다.
- **확인질문**: 확신도가 `낮음`이면 반드시 채운다.
### 2. 평가 항목을 따로 뽑는다
`평가` 유형만 모아 배점표를 만든다. 배점이 명시되지 않았으면 `배점 미공개`로 적는다.
각 평가 항목마다 **우리가 지금 제시할 수 있는 근거**를 한 줄 단다. 없으면 "근거 없음"이라고 적는다.
### 3. 누락 점검: 5축
원문 전체를 훑고 **적혀 있지 않은 것**을 찾는다.
| 축 | 확인 |
|---|---|
| **누가** | 사용자·운영 주체·승인 권한이 명시됐는가 |
| **무엇을** | 대상 데이터·산출물 범위가 명시됐는가 |
| **왜** | 도입 배경·성공 기준·측정 지표가 명시됐는가 |
| **어떻게** | 연동 대상·기존 시스템·마이그레이션 방식이 명시됐는가 |
| **언제** | 단계·마일스톤·검수 시점이 명시됐는가 |
**미기재는 갭이 아니라 질의 대상이다.**
발주처가 말하지 않은 것을 "없는 것" 또는 "우리 마음대로 해도 되는 것"으로 처리하지 않는다.
질의 목록으로 뽑아 사전 질의나 현설에서 확인한다.
### 4. 산출
```
① 요구 항목표 (전체)
② 평가 배점표 + 우리 근거
③ 질의 목록 — 5축별. 각 질문에 "왜 물어야 하는가" 한 줄
④ 리스크 3개 — 제약 유형 중 우리가 못 맞출 소지가 큰 것
⑤ 참여 판단에 필요한 미확인 정보 목록
```
## 입력
- 원문: `{RFP 또는 과업지시서 전문}`
- 우리 보유 역량: `{있으면. 대응 가능성 등급 판단에 씀. 없으면 전부 미확인으로 둔다}`
- 마감: `{사전 질의 마감이 언제인지. ③의 우선순위가 달라진다}`
## 금지
- 원문 문장 수정·요약
- 근거 없는 대응 가능성 등급 부여
- 미기재 항목을 우리에게 유리하게 해석하기
- 질의 목록 없이 항목표만 내기. 그건 그냥 필사다
- "전반적으로 대응 가능" 같은 총평. 행 단위로만 판정한다
출력 예시
항목표에서 원문과 해석이 분리된 형태입니다.
| # | 원문 인용 | 유형 | 우리 해석 | 근거 | 확신도 | 대응 가능성 | 확인질문 |
|---|---|---|---|---|---|---|---|
| 3 | "기존 시스템과의 연계가 가능하여야 함" | 요구 | 연계 대상이 특정되지 않음. 표준 API 제공 수준으로 읽힘 | 원문에 대상 미기재 | 낮음 | 미확인 | 연계 대상 시스템과 인터페이스 규격이 어떻게 되나요? |
| 7 | "본 사업의 산출물은 발주기관에 귀속된다" | 제약 | 재사용 자산의 권리 범위 확인 필요 | 원문 명시 | 높음 | 기구현 | 사전 보유 자산의 권리는 별도로 인정되나요? |
3번 행에서 대응 가능성을 구성가능으로 추정하지 않은 것이 핵심입니다.
연계 대상이 확인되지 않은 상태에서 등급을 부여하면 해당 등급이 견적에 반영됩니다.
5축 누락 점검 결과입니다.
③ 질의 목록
누가 ⚠ 운영 주체가 명시되지 않았습니다.
→ "구축 후 운영은 발주기관 직접인가요, 위탁인가요?"
(운영 위탁이면 사업 범위와 금액이 달라집니다)
왜 ⚠ 성공 기준·측정 지표가 없습니다.
→ "검수 시 어떤 기준으로 완료를 판정하시나요?"
(검수 분쟁의 대부분이 여기서 납니다)
언제 ⚠ 단계는 있으나 중간 검수 시점이 없습니다.
→ "중간 산출물 검수 일정이 있나요?"
이 규칙의 근거
원문을 다듬지 않는 것. RFP 문장은 그 자체가 평가 근거입니다. 요약하면 어떤 표현에 배점이 걸려 있었는지 확인할 수 없습니다. 제안서 작성 시 발주처 표현을 그대로 인용하는 것이 원칙이므로, 원문이 요약되면 이 원칙을 지킬 수 없습니다.
미기재를 갭 대신 질의로 처리하는 것. 미기재 항목을 존재하지 않는 것으로 처리하면 자사에 유리하게 해석하게 되고, 그 해석이 견적에 반영됩니다. 수행 단계에 이르러 발주처가 포함으로 간주한 항목이 확인됩니다. 미기재 항목은 대부분 발주처가 당연하다고 판단해 생략한 사항입니다.
대응 가능성에 미확인 등급을 둔 것. 3등급만 두면 확인되지 않은 항목도 세 등급 중 하나로 분류하게 됩니다.
이렇게 부여한 등급이 견적의 기초가 되어, 근거 없는 수치가 근거를 갖춘 것처럼 보이게 됩니다.
미확인 등급이 있어야 확인 대상 목록이 유지됩니다.
5축으로 훑는 것. 검토 과정에서 인지되는 것은 기재된 항목입니다. 누락된 축은 인지 단서를 제공하지 않아 지나치게 됩니다. 고정된 다섯 개 질문을 대조해야 운영 주체에 대한 기재가 없다는 점이 확인됩니다.
주의점·한계
- 원문이 스캔 PDF면 인용 정확도가 떨어집니다. 텍스트로 변환한 뒤 입력합니다.
- 배점이 비공개인 공고에서는 평가 배점표가 일부만 산출됩니다. 해당 상태에서도 근거 점검에는 활용할 수 있습니다.
- 대응 가능성 등급을 견적 근거로 직접 사용하지 않습니다. 미확인 항목이 포함되어 있습니다.
변경 이력
v0.1· 2026. 8. 10. · 최초 공개