RFP 원문에서 평가셋을 만들고, Draft를 공식 Evidence와 분 리한 PMO 검토기
## 📝 한줄 요약
RFP의 AI 관련 5쪽을 요구사항 후보 24건, 부정 사례 10건, 애매 사례 10건으로 나눠 평가 패키지를 만들었다. 이후 45개 후속 문서와 76개 Gap Closure 패키지를 실제 해시·버전·승인·추적성 기준으로 검토했다. 그 과정에서 “파일이 존재한다”와 “공식 Evidence로 사용할 수 있다”는 전혀 다른 상태라는 걸 확인했다.
**바쁘시면 이것만 읽어도 돼요:**
- RFP 107~111쪽을 요구사항·비요구사항·사람 검토 대상으로 분리했다.
- 평가 기준, 분류체계, 출처목록, 비식별화 기준까지 한 패키지로 묶었다.
- 24개 요구사항 후보는 원문 인용을 확인했지만 사람 승인 전이라 Gold Set으로 확정하지 않았다.
- 후속 패키지 45개 파일을 확인하고, 매니페스트 대상 40개의 SHA-256이 모두 일치하는지 검증했다.
- 문서가 있어도 버전, 승인, 요구사항 연결, 시험 Evidence가 없으면 조건부 또는 차단으로 판정했다.
- Gap Closure 팩 76개도 파일 수만 보지 않고 공식·보조근거·Draft·승인대기로 나눴다.
- 결론은 “결손이 모두 닫혔다”가 아니라 “결손을 안전하게 관리하고 승인받을 준비가 됐다”였다.
## 🎯 이런 분들께 도움돼요
- RFP에서 AI 요구사항을 추출하고 평가셋을 만들려는 PMO
- 구축사로부터 많은 문서를 받았지만 무엇을 믿어야 할지 고민하는 검토자
- 문서 개수보다 버전·승인·추적성·Evidence를 확인해야 하는 품질 담당자
- Gold Set, AI 평가기준, 변경관리 원장을 준비하는 프로젝트 팀
## 😫 문제 상황 (Before)
AI 기능을 평가하려면 정답이 필요하다. 그런데 RFP 원문은 사람이 읽기 위한 계약 문서다. 요구사항과 설명, 예시, 제목, 참조 문장이 같은 표 안에 섞여 있다. 이를 그대로 모델에 넣고 “잘 추출했다”고 말하면 정확도를 확인할 방법이 없다.
후속 문서가 들어온 뒤에는 다른 문제가 생겼다. RFP, 요구사항, WBS, 회의록, 보고서, 설계서가 한 폴더에 모였지만, 파일이 많다는 사실이 프로젝트 상태를 설명해주지는 않았다. 어떤 파일이 공식 기준선인지, 버전이 최신인지, 회의 결정이 WBS와 시험까지 연결됐는지 따로 확인해야 했다.
보완 패키지가 들어왔을 때는 더 조심해야 했다. 빈 템플릿이나 AI가 만든 Draft가 실제 변경관리 원장처럼 보일 수 있었고, 설계 흔적이 계약상 승인 근거로 오해될 수도 있었다.
그래서 검토 질문을 세 단계로 나눴다.
```text
원문을 반복 시험할 수 있는 평가 재료로 바꿀 수 있는가?
받은 문서를 실제 PMO Evidence로 사용할 수 있는가?
보완 파일이 공식 결손을 닫았는가, 아니면 승인 준비만 갖춘 것인가?
```
## 🛠️ 사용한 도구
- **Hermes Agent**: 작업 분해, 문서별 판정, 결과 통합
- **로컬 PDF 분석**: 페이지·표·원문 인용·다중 페이지 연결 확인
- **CSV 검증**: 후보 ID, 필수 필드, 상태, 평가 항목 점검
- **SHA-256 대조**: 매니페스트와 실제 파일 무결성 검증
- **문서 추출·OCR 분기**: 텍스트 PDF와 이미지형 PDF를 구분해 확인
- **Markdown·CSV 결과물**: 검토보고서, 인제스트 준비도, 추적성 결함대장, 잔여 요청 목록
내부 문서는 외부 서비스에 올리지 않았고, 원본도 수정하지 않았다. 외부 공유용 사례글에서는 기관명, 사업명, 원문 인용, 로컬 경로를 제외했다.
## 🔧 작업 과정
### 1. RFP 5쪽을 24·10·10 평가 패키지로 바꿨다
첫 번째 작업은 RFP의 AI 관련 페이지를 반복 시험할 수 있는 형태로 바꾸는 일이었다. PDF 107~111쪽을 직접 읽고, 요구사항으로 볼 수 있는 번호형 블록을 후보로 뽑았다. 설명이나 제목처럼 요구사항이 아닌 문장은 부정 사례로, 문맥에 따라 판단이 달라질 수 있는 문장은 애매 사례로 분리했다.
결과는 다음과 같았다.
- 요구사항 정답 후보 24건
- 요구사항이 아닌 부정 사례 10건
- 사람 검토가 필요한 애매 사례 10건
- 프로젝트 맞춤형 분류체계
- Pass·Partial·Fail 평가기준
- 실제 사용 문서와 비교문서 구분
- 외부 실습 전 비식별화 기준
CSV 파일을 채우는 데서 끝내지 않았다. 후보마다 PDF 페이지와 원문 인용을 연결했고, 모든 인용문이 실제 RFP 페이지에 있는지 확인했다. 특히 마지막 요구사항이 다음 페이지로 이어진 뒤 새로운 성능 요구가 시작되는 구간은 다중 페이지 Evidence와 표 읽기 순서를 시험할 사례로 남겼다.
그래도 이 패키지를 Gold Set이라고 부르지 않았다. 24개 부모 블록을 더 작은 원자 요구사항으로 나눌지, 애매 사례를 Yes·No·Review 중 어디에 둘지, 정규화 문장이 원문 의미를 보존하는지는 사람이 결정해야 했기 때문이다.
### 2. 45개 문서에서 “있다”와 “쓸 수 있다”를 분리했다
다음에는 RFP, 요구사항, WBS, 회의록, 변경·위험 자료, 보고서, 대표 산출물이 담긴 후속 패키지를 검토했다.
먼저 파일 45개를 확인했다. 그중 매니페스트 관리대상 40개의 크기와 SHA-256을 실제 파일과 대조했고 모두 일치했다. 나머지 5개는 README, 인제스트 순서, 보안 안내 같은 패키지 제어문서였다.
무결성이 확인됐다고 검토가 끝난 것은 아니었다. RFP를 1차 계약 기준선으로 두고 문서마다 다음을 다시 확인했다.
- 파일명과 본문 버전이 같은가
- 승인본인지 Draft인지 구분되는가
- 요구사항 ID가 중복되지 않는가
- RFP 밖 추가기능에 승인 근거가 있는가
- WBS 변경이 회의 결정과 연결되는가
- AI 평가셋과 품질기준의 선후행이 있는가
- 변경·위험 자료가 실제 운영 원장인가
- PMO finding이 조치·담당·기한·완료 Evidence와 연결되는가
그 결과 14개 주요 finding을 정리했다. 예를 들어 RFP 요구 블록 수와 기능요구 상세 ID 수가 맞지 않았고, 일부 요구사항과 회의록 ID가 재사용된 정황이 있었다. 최신 WBS와 변경승인 연결도 부족했다. 변경·리스크 자료에는 빈 표와 샘플 값이 남아 있어 실제 운영 원장으로 사용할 수 없었다.
그래서 문서를 네 상태로 나눴다.
- 조건부 준비: 원문과 구조는 있지만 승인·ID·추적성 보완 필요
- 차단: 실제 운영 원장이 없어 프로젝트 상태로 사용 불가
- 구조 학습만 가능: 화면이나 템플릿은 참고할 수 있지만 자동화 Evidence로 부족
- 추가 공식자료 필요: 제안서, 최신 WBS, SCR, 리스크 원장, 품질기준, 승인 Gold Set
파일 개수가 많아도 이 구분이 없으면 AI가 Draft를 공식 상태로 학습할 수 있다는 점이 가장 큰 위험이었다.
### 3. 76개 Gap Closure 파일도 곧바로 “결손 해소”로 보지 않았다
첫 검토에서 부족한 자료를 요청하자 Gap Closure 패키지가 들어왔다. 실제 파일은 76개였고, 해시 매니페스트 대상은 75개였다. 등록 대상 75개의 크기와 SHA-256은 모두 일치했다. 매니페스트에 포함되지 않은 한 파일은 자기 자신인 해시 목록이었다.
패키지는 이전보다 훨씬 좋아졌다. 제출 제안서 보조자료, 최신 WBS 요청서, Draft 변경·리스크 후보, LMS 보류 항목 결정대장, AI 품질기준 초안, Gold Set 골격, 추가기능 Evidence 매트릭스가 들어 있었다. 무엇보다 각 자료에 `SUPPORTING_ONLY`, `DRAFT`, `NOT OFFICIAL`, `Pending human approval` 같은 상태가 표시돼 있었다.
하지만 요청했던 8개 핵심 항목은 여전히 공식 확정 상태가 아니었다.
- 실제 제출 제안서 최종본 미확보
- 공식 최신 WBS와 변경승인 기록 미확정
- SCR·변경관리 원장은 Draft
- 이슈·리스크 원장도 Draft
- 보고서는 시험용 템플릿
- LMS 보류 항목은 결정 대기
- AI 품질기준과 Gold Set은 사람 작성·승인 대기
- 추가기능은 설계 흔적과 보조근거만 존재
따라서 이 패키지를 “공식 Evidence 결손이 모두 닫힌 팩”이라고 판정하지 않았다. 대신 Draft를 공식 자료와 병합하고, 승인 상태를 관리하고, 누락 Evidence를 탐지하는 Workflow를 시험할 수 있는 운영·승인 준비 팩으로 분류했다.
## ✅ 결과 (After)
### Before vs After
| 항목 | Before | After |
|---|---|---|
| RFP 활용 | 사람이 읽는 계약 문서 | 후보 24·부정 10·애매 10 평가 패키지 |
| 평가 기준 | 모델 결과를 볼 기준이 없음 | 페이지·인용·분류·Pass/Partial/Fail 기준 확보 |
| Gold Set 상태 | 후보와 정답을 혼동할 위험 | 사람 승인 전 후보로 명확히 유지 |
| 후속 문서 | 45개 파일이 한 폴더에 존재 | 무결성·권위·버전·추적성별 판정 |
| 결함 관리 | 검토 의견이 문서에 흩어짐 | 14개 finding과 조치대상 구조화 |
| 변경·리스크 | 템플릿도 운영자료처럼 보일 수 있음 | 실제 원장 부재로 차단 판정 |
| Gap Closure | 파일이 추가되면 결손이 닫힌 것으로 오해 | 공식·보조근거·Draft·승인대기 분리 |
| 최종 활용 | 막연한 “준비 완료” | 평가, 구조시험, 승인 준비, Baseline 사용 범위를 구분 |
### 실제로 남은 결과물
- RFP 요구사항 추출 평가 패키지
- 후속 문서 패키지 통합 검토보고서
- 문서별 인제스트 준비도
- 구조화된 추적성 결함대장
- Gap Closure 검토보고서
- 잔여 공식자료 요청 목록
검토시간 절감률은 아직 측정하지 않았다. 이 사례에서 확인한 결과는 자동화 성능이 아니라, 원문과 Evidence를 기준으로 문서의 사용 가능 범위를 재현 가능하게 나눴다는 점이다.
## 💬 이 과정에서 배운 AI 활용 팁
### 효과적이었던 것
1. 요구사항 후보뿐 아니라 부정·애매 사례를 함께 만들었다.
2. 모든 후보에 원문 페이지와 인용문을 연결했다.
3. 해시 검증과 내용 검토를 별도 단계로 운영했다.
4. 공식·보조근거·Draft·승인대기를 데이터 상태로 분리했다.
5. “자료가 있는가?” 대신 “어떤 결정에 사용할 수 있는가?”를 물었다.
### 이렇게 하면 안 돼요
1. 후보 CSV가 완성됐다고 Gold Set으로 부르지 않는다.
2. 해시가 일치한다고 내용과 공식성까지 맞다고 판단하지 않는다.
3. 빈 템플릿이나 AI 생성 Draft를 실제 변경·리스크 원장으로 사용하지 않는다.
4. 설계 문서의 흔적을 계약 변경 승인으로 확대 해석하지 않는다.
5. 보완 파일 수가 늘었다는 이유로 기존 finding을 자동 종료하지 않는다.
## 🌍 다른 업무에 적용한다면?
이 흐름은 계약 검토, 감사, 규정 준수, 데이터 품질, 납품 검수에도 적용할 수 있다.
```text
원문 선택
→ 정답 후보·부정·애매 사례 구성
→ 사람 승인
→ 파일 인벤토리·해시 검증
→ 권위·버전·추적성 검토
→ finding·조치 등록
→ 보완자료 재제출
→ 공식/Draft/보조근거 분리
→ 재검증 후 종료
```
AI가 많은 문서를 빠르게 읽는 것보다, 어떤 자료를 어떤 결정에 써도 되는지 구분하게 만드는 편이 현업에서는 더 중요했다.
## 🚀 앞으로의 계획
다음 단계는 RFP 기반 24개 후보를 사람이 승인·수정·반려할 수 있는 Gold Set 승인 화면을 만드는 것이다. 이후 실제 공식 제안서, 최신 WBS, 변경·리스크 원장이 들어오면 기존 Draft와 문서 ID·버전·해시로 자동 매칭하고, 사람 승인 후에만 Baseline으로 승격하도록 구현한다.
또한 requirement→WBS→변경→시험→산출물→승인의 연결률과 finding 종료 Evidence를 대시보드에서 추적할 예정이다.
## 📋 재사용 가능한 프롬프트
### 프롬프트 1: 원문을 평가 패키지로 만들기
> 이 원문에서 [업무 유형]을 평가할 패키지를 만들어줘. 정답 후보, 명확한 부정 사례, 사람 검토가 필요한 애매 사례를 분리하고 각 항목에 원문 페이지와 인용문을 연결해줘. 분류체계, Pass/Partial/Fail 기준, 비식별화 기준도 작성해줘. 사람 승인 전에는 Gold Set으로 표시하지 마.
### 프롬프트 2: 대량 문서 패키지의 Evidence 준비도 검토
> 이 문서 패키지를 재귀적으로 확인하고 파일 인벤토리와 SHA-256을 검증해줘. 그 다음 RFP 또는 계약문서를 기준선으로 두고 문서 ID, 본문 버전, 승인 상태, 요구사항 연결, 변경·시험·산출물 Evidence를 검토해줘. 결과를 공식 사용 가능, 조건부, 구조 학습만 가능, 차단, 미검증으로 분리하고 finding별 조치·담당 역할·완료조건·재검증 방법을 제시해줘.
### 프롬프트 3: Gap Closure 패키지 재검증
> 이전 finding과 요청 목록을 기준으로 보완 패키지를 검토해줘. 새 파일 수만 보고 종료하지 말고 공식 원본, 보조근거, Draft, 템플릿, 사람 승인 대기를 분리해줘. 실제로 닫힌 finding과 승인 준비만 된 finding을 구분하고, Baseline 승격 가능 여부와 추가 Evidence를 알려줘.
---
## 🖼️ 평가 패키지화와 Evidence 검토 흐름
아래 그림은 RFP 원문을 평가 패키지로 바꾸고, 후속 문서와 Gap Closure 패키지를 공식성·무결성·추적성 기준으로 검토한 전체 흐름이다.
*후보를 만드는 것에서 끝나지 않고, 사람 승인과 공식 Evidence가 확인될 때까지 상태를 분리해 관리했다.*
