제안요청서, 아직도 처음부터 끝까지 읽고 계신가요?

제안요청서 PDF를 업로드하면 웹앱이 사업 정보, 핵심 요구사항, 공식 요구사항 수, AI 중요도, 제안서 목차, 목표 페이지 수, 기준 참고 제안서까지 자동으로 분석해주는 파이프라인을 만든 이야기

제안서를 쓰기 전에 가장 먼저 하는 일은 무엇일까요?

바로 제안요청서, 즉 RFP(Request for Proposal) 분석입니다.

제안요청서를 열고 사업명을 확인합니다. 발주처, 예산, 사업 기간을 찾습니다. 요구사항이 어디에 있는지 살펴보고, 평가기준과 배점을 확인합니다. RFP에서 제시한 제안서 목차가 있는지 확인하고, 페이지 제한이 있다면 목차별로 몇 페이지를 배분해야 할지도 생각해야 합니다.

이 과정은 단순히 문서를 읽는 일이 아닙니다.

제안요청서는 제안서 작성 계획을 만들기 위한 입력 데이터입니다.

그리고 제안서 작성자는 이 데이터를 바탕으로 어떤 내용을 강조할지, 어떤 요구사항을 빠뜨리지 말아야 할지, 몇 페이지 안에 어떤 구조로 제안서를 만들지 결정합니다.

이번 글은 제안요청서 PDF를 업로드하면 웹앱이 자동으로 분석하고, 제안서 작성자가 바로 사용할 수 있는 분석 화면으로 변환하는 기능을 개발한 이야기입니다.

1. 제안서 작성은 RFP 분석에서 시작된다

제안서 작성은 빈 문서에서 시작하지 않습니다.

대부분의 경우 시작점은 RFP입니다.

RFP에는 제안서에 반드시 반영해야 할 정보가 들어 있습니다.

• 사업명

• 발주처

• 사업 예산

• 사업 기간

• 기능 요구사항

• 비기능 요구사항

• 사업관리 요구사항

• 보안 요구사항

• 평가기준

• 배점

• 제안서 작성 지침

• 제출 형식

• 페이지 제한

• 제안서 목차

문제는 이 정보들이 보기 좋게 한곳에 정리되어 있지 않다는 점입니다.

어떤 정보는 표 안에 있고, 어떤 정보는 본문 문장 안에 있습니다.

요구사항 목록은 여러 페이지에 흩어져 있고, 평가기준은 별도 장표에 따로 들어 있는 경우도 많습니다.

제안서 목차가 명확히 제시된 경우도 있지만, 그렇지 않은 경우에는 요구사항과 평가기준을 보고 직접 목차를 설계해야 합니다.

그래서 제안서 작성 전에 하는 RFP 분석은 사실상 하나의 독립된 분석 작업입니다.

핵심은 이것입니다.

제안요청서는 단순히 읽는 문서가 아니라, 제안서 작성 계획을 만들기 위한 입력 데이터다.

2. 사람이 하던 RFP 분석은 왜 오래 걸리는가

RFP 분석이 오래 걸리는 이유는 명확합니다.

문서가 길고, 중요한 정보가 흩어져 있으며, 단순 요약만으로는 제안서 작성에 필요한 판단을 내릴 수 없기 때문입니다.

실제로 사람이 RFP를 분석할 때는 다음과 같은 일을 반복합니다.

• PDF 문서 전체를 훑는다.

• 사업명, 발주처, 예산, 기간을 찾는다.

• 요구사항 표를 찾는다.

• 요구사항 ID와 내용을 하나씩 정리한다.

• 공식 요구사항 수를 센다.

• 중요한 요구사항과 덜 중요한 요구사항을 구분한다.

• 평가기준과 배점을 찾는다.

• RFP에서 제시한 제안서 목차가 있는지 확인한다.

• 페이지 제한이 있는지 확인한다.

• 제한 페이지가 있으면 목차별 분량을 계산한다.

• 기존에 작성했던 유사 제안서가 있는지 찾아본다.

• 참고할 만한 제안서 구조나 디자인을 확인한다.

이 작업은 익숙한 사람에게도 꽤 많은 시간이 걸립니다.

특히 요구사항이 많거나 PDF 품질이 좋지 않은 경우에는 더 오래 걸립니다.

예를 들어 요구사항이 100개 이상인 RFP라면, 단순히 읽는 것만으로 끝나지 않습니다.

각 요구사항이 제안서 어느 파트에 반영되어야 하는지, 어떤 요구사항을 더 강조해야 하는지, 누락되면 감점 위험이 큰 항목은 무엇인지까지 판단해야 합니다.

그래서 이 과정을 자동화하기로 했습니다.

단, 목표는 단순히 “RFP를 요약해주는 기능”이 아니었습니다.

3. 목표는 PDF 요약이 아니라 작성 계획 화면이었다

처음부터 목표를 명확히 잡았습니다.

목표는 RFP를 짧게 줄이는 것이 아니라, 제안서 작성 전에 필요한 판단 항목으로 재구성하는 것이었다.

RFP 요약 기능만 만든다면 결과는 보통 긴 텍스트 요약으로 끝납니다.

하지만 제안서 작성자는 요약문만 보고 바로 작업을 시작하기 어렵습니다.

작성자에게 필요한 것은 다음과 같은 질문에 대한 답입니다.

• 이 사업은 어떤 사업인가?

• 발주처는 어디인가?

• 예산과 기간은 어떻게 되는가?

• 반드시 반영해야 할 요구사항은 몇 개인가?

• 핵심 요구사항은 무엇인가?

• 어떤 요구사항을 우선적으로 다뤄야 하는가?

• 제안서 목차는 어떻게 구성해야 하는가?

• 전체 목표 페이지 수는 몇 페이지가 적절한가?

• 목차별 페이지는 어떻게 배분해야 하는가?

• 참고할 만한 기존 제안서는 무엇인가?

그래서 분석 결과를 다음 단위로 나눴습니다.

| 분석 단위 | 설명 |

|---|---|

| 프로젝트 정보 | 사업명, 발주처, 예산, 기간 등 기본 정보 |

| 핵심 요구사항 | 제안서에 반드시 반영해야 할 주요 요구사항 |

| 요구사항 카테고리 | 기능, 사업관리, 보안, 품질 등 요구사항 분류 |

| 공식 요구사항 수 | RFP에서 확인된 전체 요구사항 규모 |

| AI 중요도 | 작성 전략 관점에서 우선순위를 판단한 값 |

| 제안서 목차 | RFP 기반 또는 자동 생성된 제안서 구조 |

| 목표 페이지 수 | 전체 제안서 분량 기준 |

| 기준 참고 제안서 | 유사 사업 또는 유사 구조의 기존 제안서 |

즉, PDF를 읽기 쉬운 텍스트로 바꾸는 것이 아니라

제안서 작성자가 바로 검토하고 수정할 수 있는 분석 화면으로 바꾸는 것이 목표였습니다.

4. PDF 업로드부터 분석 화면까지의 파이프라인

전체 흐름은 다음과 같습니다.

1. 제안요청서 PDF 업로드

2. 파일 검증 및 저장

3. PDF 텍스트 추출

4. RFP 원문 분석

5. 사업 정보 추출

6. 요구사항 구조화

7. 공식 요구사항 수와 AI 중요도 계산

8. 제안서 목차 및 페이지 제한 분석

9. 기준 참고 제안서 검색

10. 프론트엔드 분석 화면으로 변환

각 단계는 단순히 순서상 존재하는 것이 아니라, 다음 단계의 품질에 직접 영향을 줍니다.

예를 들어 PDF 텍스트 추출이 잘못되면 요구사항 분석이 흔들립니다.

요구사항 분석이 흔들리면 공식 요구사항 수와 AI 중요도도 부정확해집니다.

제안서 목차 분석이 잘못되면 목표 페이지 수와 목차별 페이지 배분도 신뢰하기 어렵습니다.

그래서 이 파이프라인은 단순한 “업로드 → 요약” 구조가 아니라, RFP를 단계적으로 정제하고 구조화하는 흐름으로 설계했습니다.

5. PDF 텍스트 추출: 분석 품질은 입력에서 시작된다

문서 분석에서 가장 먼저 마주한 문제는 PDF였습니다.

PDF는 생각보다 다루기 까다로운 포맷입니다.

겉으로 보기에는 사람이 읽기 좋은 문서처럼 보이지만, 내부적으로는 텍스트가 깔끔하게 정리되어 있지 않은 경우가 많습니다.

특히 RFP PDF에서는 다음과 같은 문제가 자주 발생합니다.

• 표 안의 텍스트 순서가 깨진다.

• 줄바꿈이 문장 중간에 들어간다.

• 페이지 번호가 본문처럼 섞인다.

• 헤더와 푸터가 매 페이지 반복된다.

• 요구사항 ID와 내용이 분리되어 추출된다.

• 스캔 PDF에는 텍스트 레이어가 없을 수 있다.

• 다단 문서에서는 읽는 순서가 꼬일 수 있다.

이 단계가 중요한 이유는 명확합니다.

LLM이 아무리 좋아도 입력 텍스트가 깨져 있으면 분석 결과도 흔들린다.

그래서 PDF 처리 단계에서는 다음과 같은 전략이 필요했습니다.

| 처리 방식 | 목적 |

|---|---|

| 텍스트 레이어 추출 | 일반 PDF에서 빠르게 본문 텍스트 확보 |

| OCR fallback | 스캔 PDF 또는 텍스트 레이어가 없는 문서 처리 |

| 페이지 단위 마커 추가 | 분석 결과가 어느 페이지에서 나온 것인지 추적 |

| 헤더/푸터 정리 | 반복 문구가 분석에 영향을 주지 않도록 제거 |

| 표 구조 보정 | 요구사항 ID, 명칭, 설명이 분리되지 않도록 정리 |

| 불필요한 공백 정리 | 문장 단위 분석 품질 개선 |

문서 분석 기능을 만들 때 AI 모델의 성능만큼 중요한 것이 입력 데이터 품질입니다.

RFP 분석에서도 마찬가지였습니다.

6. 사업 정보를 추출하고 프로젝트 맥락 만들기

PDF 텍스트를 확보한 뒤 가장 먼저 추출한 정보는 프로젝트 정보입니다.

분석 화면에서는 이 정보가 상단 카드에 표시됩니다.

• 사업명

• 발주처

• 예산

• 기간

이 정보는 단순히 화면에 보여주기 위한 값이 아닙니다.

이후 분석 단계에서도 계속 사용됩니다.

예를 들어 사업명과 발주처는 유사 제안서를 검색할 때 중요한 키가 됩니다.

예산과 기간은 사업 규모를 판단하는 기준이 됩니다.

사업 규모는 제안서 목표 페이지 수나 목차 구성에도 영향을 줄 수 있습니다.

즉, 프로젝트 정보는 RFP 분석의 시작점이자 전체 분석 맥락을 잡는 기준입니다.

사업명과 발주처는 화면 상단에 보여주는 정보이기도 하지만, 동시에 유사 제안서 검색과 프로젝트 맥락 판단에 사용하는 핵심 키가 된다.

프로젝트 정보 추출 결과는 다음과 같은 형태로 구조화했습니다.

| 항목 | 예시 |

|---|---|

| 사업명 | 차세대 업무시스템 구축 사업 |

| 발주처 | OO기관 |

| 예산 | 1,200,000,000원 |

| 기간 | 계약일로부터 8개월 |

이렇게 구조화해두면 프론트엔드에서 카드 형태로 보여주기 쉽고, 이후 단계에서 검색 쿼리나 제안서 생성 입력값으로 재사용하기도 쉽습니다.

7. 핵심 요구사항을 구조화 데이터로 바꾸기

RFP 분석 화면에서 가장 중요한 영역은 요구사항입니다.

제안서 작성자가 가장 많이 확인해야 하는 부분이기도 하고, 실제 제안서 내용에 직접 반영되어야 하는 항목이기 때문입니다.

이 기능에서는 RFP의 요구사항을 다음과 같이 구조화했습니다.

• 요구사항을 항목 단위로 분리한다.

• 각 요구사항에 ID를 부여한다.

• 요구사항 카테고리를 분류한다.

• AI 중요도를 계산한다.

• 한 줄 요약을 생성한다.

• 제안서에 반영해야 할 핵심 포인트를 추출한다.

예를 들면 다음과 같은 형태입니다.

| 요구사항 ID | AI 중요도 | 카테고리 | 요약 |

|---|---|---|---|

| SFR-001 | 상 | 공통 기능 | 사용자가 업무 데이터를 등록, 조회, 수정할 수 있는 기본 기능 제공 |

| SFR-002 | 상 | 화면 기능 | 관리자 화면에서 주요 기준정보를 관리할 수 있도록 구성 |

| PMR-01 | 중 | 사업수행 및 관리 | 사업 일정, 산출물, 보고 체계를 포함한 수행관리 방안 제시 |

| SER-01 | 상 | 보안 | 개인정보 보호 및 접근권한 관리 방안 제시 |

| QUR-01 | 중 | 품질 | 테스트 계획과 품질보증 절차 수립 |

기존 방식에서는 긴 RFP 본문을 읽으면서 사람이 직접 요구사항 목록을 만들었습니다.

하지만 웹앱에서는 분석 결과를 바로 체크 가능한 목록으로 보여주도록 했습니다.

핵심은 이것입니다.

긴 RFP 본문을 그대로 보여주는 대신, 작성자가 체크해야 할 요구사항 목록으로 바꿨다.

요구사항을 구조화해두면 이후 단계에서도 활용할 수 있습니다.

• 제안서 목차에 요구사항 매핑

• 요구사항별 작성 카드 생성

• 누락 요구사항 검토

• 페이지별 반영 항목 체크

• AI 중요도 기반 우선순위 정렬

• 평가기준과 요구사항 연결

결국 요구사항 구조화는 단순 분석 결과가 아니라 제안서 작성 자동화의 기반 데이터가 됩니다.

8. 공식 요구사항 수와 AI 중요도를 분리한 이유

구현하면서 중요하게 본 부분 중 하나는 공식 요구사항 수와 AI 중요도를 분리하는 것이었습니다.

처음에는 요구사항을 뽑고 중요도만 붙이면 충분해 보였습니다.

하지만 실제 제안서 작성 흐름에서는 두 값의 역할이 완전히 달랐습니다.

공식 요구사항 수

공식 요구사항 수는 RFP에서 확인된 전체 요구사항 규모를 의미합니다.

이 값은 전략 판단보다는 누락 방지에 가깝습니다.

• RFP에 요구사항이 총 몇 개인가?

• 제안서에 빠짐없이 반영해야 할 항목은 몇 개인가?

• 기능 요구사항, 보안 요구사항, 관리 요구사항은 각각 몇 개인가?

• 제안서 작성 후 누락된 요구사항은 없는가?

즉, 공식 요구사항 수는 “얼마나 중요한가”를 말하는 값이 아니라

“몇 개를 빠짐없이 챙겨야 하는가”를 말하는 값입니다.

AI 중요도

AI 중요도는 작성 전략을 위한 값입니다.

모든 요구사항을 동일한 비중으로 다룰 수는 없습니다.

어떤 요구사항은 평가에서 중요하게 다뤄질 수 있고, 어떤 요구사항은 기본 충족 여부만 보여줘도 되는 경우가 있습니다.

AI 중요도는 다음과 같은 판단에 활용됩니다.

• 어떤 요구사항을 먼저 검토할 것인가?

• 어떤 요구사항을 제안서에서 더 크게 다룰 것인가?

• 페이지 배분 시 어떤 항목에 더 많은 분량을 줄 것인가?

• 제작 카드 생성 시 어떤 요구사항을 우선 반영할 것인가?

• 발표자료나 요약본에서 어떤 내용을 강조할 것인가?

정리하면 다음과 같습니다.

| 구분 | 역할 | 사용 목적 |

|---|---|---|

| 공식 요구사항 수 | RFP 기준 전체 요구사항 규모 | 누락 방지 |

| AI 중요도 | 작성 전략 기준 우선순위 | 강조점 판단 및 페이지 배분 |

핵심 문장은 이렇습니다.

공식 요구사항 수는 누락을 막기 위한 숫자이고, AI 중요도는 작성 우선순위를 잡기 위한 판단값이다.

이 둘을 분리하니 분석 화면도 더 명확해졌습니다.

작성자는 전체 요구사항 규모를 보면서 누락 위험을 관리하고, AI 중요도를 보면서 어디에 집중해야 할지 판단할 수 있습니다.

9. 제안서 목차와 목표 페이지 수 분석

RFP 분석에서 요구사항만큼 중요한 것이 제안서 목차입니다.

제안서 목차는 단순한 목록이 아닙니다.

제한된 페이지 안에서 어떤 내용을 얼마나 담을지 결정하는 설계도입니다.

제안서 목차는 단순한 목록이 아니라, 제한된 페이지 안에서 어떤 내용을 얼마나 담을지 결정하는 설계도다.

이 기능에서는 다음 순서로 제안서 목차를 분석했습니다.

1. RFP에 제안서 목차가 명시되어 있는지 확인한다.

2. 명시된 목차가 있다면 우선 적용한다.

3. 페이지 제한이 있는지 확인한다.

4. 페이지 제한이 있다면 전체 목표 페이지 수로 설정한다.

5. 페이지 제한이 없다면 요구사항 수, 사업 규모, 유사 제안서 기준으로 목표 페이지 수를 산정한다.

6. 목표 페이지 수를 기준으로 목차별 페이지를 배분한다.

7. 사용자가 목표 페이지 수를 수정하면 목차별 페이지 배분을 다시 계산한다.

예를 들어 분석 결과가 다음과 같을 수 있습니다.

| 목차 | 목표 페이지 |

|---|---:|

| 1. 제안 개요 | 2p |

| 2. 사업 이해도 | 3p |

| 3. 수행 전략 | 4p |

| 4. 기능 구현 방안 | 7p |

| 5. 보안 및 품질관리 방안 | 4p |

| 6. 사업관리 방안 | 4p |

| 7. 투입인력 및 일정 | 2p |

전체 목표 페이지가 26p라면, 이 숫자는 단순한 결과값이 아닙니다.

작성자가 제안서 제작을 시작할 때 기준으로 삼는 작성 계획입니다.

특히 목표 페이지 수를 사용자가 수정할 수 있도록 한 점이 중요했습니다.

AI가 계산한 페이지 수는 출발점일 뿐이고, 실제 작성자는 내부 전략이나 제출 형식에 따라 분량을 조정할 수 있어야 하기 때문입니다.

그래서 UI에서는 목표 페이지 수를 조정하면 목차별 페이지 배분이 다시 계산되도록 설계했습니다.

10. 기준 참고 제안서 연결하기

RFP 분석 결과는 그 자체로 끝나지 않습니다.

분석 결과는 기존 제안서 라이브러리에서 어떤 자료를 기준으로 삼을지 결정하는 검색 쿼리가 됩니다.

RFP 분석 결과는 그 자체로 끝나지 않고, 기존 제안서 라이브러리에서 어떤 자료를 기준으로 삼을지 결정하는 검색 쿼리가 된다.

기준 참고 제안서를 찾을 때 단순히 사업명 키워드만 보는 것은 충분하지 않습니다.

비슷한 단어가 들어간 제안서라도 실제 사업 성격이 다를 수 있기 때문입니다.

그래서 다음 정보를 함께 사용했습니다.

• 사업명

• 발주처

• 사업 도메인

• 예산 규모

• 사업 기간

• 요구사항 카테고리

• 핵심 요구사항

• 제안서 목차 구조

• 평가기준

• 페이지 규모

예를 들어 “업무시스템 구축”이라는 키워드만으로 검색하면 너무 많은 후보가 나올 수 있습니다.

하지만 여기에 “공공기관”, “정보시스템”, “보안 요구사항”, “사업관리”, “26p 내외 제안서” 같은 맥락을 함께 보면 더 적절한 참고 제안서를 찾을 수 있습니다.

기준 참고 제안서는 이후 단계에서 다음과 같이 활용됩니다.

• 페이지별 제작 카드 생성

• 제안서 목차 구조 참고

• 유사 사업의 표현 방식 참고

• 디자인 및 레이아웃 참고

• 강조 메시지 구성 참고

• 제안서 분량 기준 참고

이렇게 연결하면 RFP 분석은 단순 분석 화면에서 끝나지 않고, 실제 제안서 제작 단계로 이어집니다.

11. 분석 결과를 웹 UI로 보여주는 방식

AI 분석 결과를 그대로 텍스트로 보여주면 사용자는 다시 읽어야 합니다.

결국 자동화의 효과가 줄어듭니다.

그래서 분석 결과를 사람이 검토하는 순서에 맞춰 화면 모델로 다시 변환했습니다.

AI 분석 결과를 그대로 보여주는 것이 아니라, 사람이 검토하는 순서에 맞춰 다시 화면 모델로 변환했다.

UI는 크게 다음 영역으로 나눴습니다.

• 프로젝트 정보 카드

• 핵심 요구사항 카드

• 제안서 목차 카드

• 목표 페이지 조정 영역

• 기준 참고 제안서 영역

프로젝트 정보 카드

화면 상단에는 사업명, 발주처, 예산, 기간을 배치했습니다.

작성자가 현재 어떤 RFP를 보고 있는지 즉시 파악할 수 있어야 하기 때문입니다.

이 영역은 전체 분석의 컨텍스트 역할을 합니다.

핵심 요구사항 카드

핵심 요구사항은 작성자가 가장 많이 확인하는 영역입니다.

요구사항 ID, 카테고리, AI 중요도, 요약을 함께 보여주고

중요도나 카테고리를 기준으로 빠르게 훑어볼 수 있도록 구성했습니다.

긴 본문을 다시 읽게 하는 것이 아니라, 체크리스트처럼 확인할 수 있게 만드는 것이 목표였습니다.

제안서 목차 카드

제안서 목차는 작성 계획의 중심입니다.

목차별 목표 페이지를 함께 보여주면 작성자가 전체 제안서의 구조와 분량을 동시에 이해할 수 있습니다.

단순히 “목차를 추천합니다”가 아니라

“이 목차에 이 정도 페이지를 배정하는 것이 적절합니다”까지 보여주는 방식입니다.

목표 페이지 조정 영역

AI가 산정한 목표 페이지 수가 항상 최종값일 수는 없습니다.

작성자는 내부 전략, 제출 조건, 디자인 밀도, 포함할 산출물 범위에 따라 목표 페이지를 조정할 수 있어야 합니다.

그래서 목표 페이지 수를 수정하면 목차별 페이지 배분도 다시 계산되도록 했습니다.

기준 참고 제안서 영역

마지막으로 기준 참고 제안서를 연결했습니다.

작성자는 RFP 분석 결과를 확인한 뒤 바로 참고할 만한 기존 제안서를 볼 수 있습니다.

이를 통해 분석에서 제작으로 넘어가는 흐름이 자연스러워집니다.

UI를 카드 단위로 나눈 이유는 간단합니다.

• 분석 결과가 많기 때문에 한 번에 텍스트로 보여주면 읽기 어렵다.

• 작성자가 검토하는 순서대로 배치해야 한다.

• 숫자는 뱃지로 요약하는 것이 빠르다.

• 상세 정보는 카드 내부에서 확인할 수 있어야 한다.

• 사용자가 수정할 수 있는 값과 읽기 전용 값을 구분해야 한다.

결국 중요한 것은 AI가 분석했다는 사실이 아니라

사용자가 그 분석 결과를 빠르게 검토하고 다음 행동으로 넘어갈 수 있느냐였습니다.

12. 구현하면서 배운 점

이번 기능을 만들면서 가장 크게 느낀 점은 RFP 분석 자동화의 본질이 “요약”이 아니라 “구조화”라는 점이었습니다.

단순 요약은 문서를 짧게 만들어줍니다.

하지만 구조화는 다음 작업을 가능하게 만듭니다.

RFP에서 사업 정보를 추출하고, 요구사항을 항목화하고, 공식 요구사항 수를 계산하고, AI 중요도를 붙이고, 목차와 페이지 수를 산정하면 그 결과는 이후 제안서 제작 단계의 입력값이 됩니다.

구현하면서 얻은 교훈을 정리하면 다음과 같습니다.

1. RFP 분석 자동화는 문서 요약보다 구조화가 중요하다

제안서 작성자에게 필요한 것은 멋진 요약문이 아니라

바로 작업에 사용할 수 있는 데이터입니다.

요구사항 목록, 목차, 페이지 수, 중요도, 참고 제안서처럼 다음 단계로 이어지는 구조가 중요했습니다.

2. PDF 텍스트 추출 품질이 전체 분석 품질을 좌우한다

입력 텍스트가 깨져 있으면 좋은 분석 결과를 기대하기 어렵습니다.

PDF 처리 단계에서 텍스트 순서, 표 구조, 페이지 정보, OCR fallback을 신경 써야 했습니다.

3. 공식 요구사항과 AI 판단값은 분리해야 한다

공식 요구사항 수는 누락 방지를 위한 값입니다.

AI 중요도는 작성 전략을 위한 값입니다.

두 값을 섞으면 사용자가 무엇을 기준으로 판단해야 하는지 헷갈릴 수 있습니다.

4. 분석 결과는 다음 단계에서 사용할 수 있어야 한다

분석 화면에서 끝나는 데이터는 가치가 제한적입니다.

사업 정보는 유사 제안서 검색에 쓰이고,

요구사항은 제작 카드 생성에 쓰이며,

목차와 페이지 수는 실제 제안서 구성에 쓰입니다.

분석 결과가 다음 단계의 입력값이 될 때 자동화의 효과가 커집니다.

5. UI는 AI 결과를 검토 가능한 단위로 쪼개야 한다

AI 결과를 긴 텍스트로 보여주면 사용자는 다시 읽어야 합니다.

그래서 프로젝트 정보, 요구사항, 목차, 페이지 수, 참고 제안서처럼 검토 단위를 나누는 것이 중요했습니다.

6. 자동화는 사람의 검토를 없애는 것이 아니라 첫 분석 시간을 줄이는 것이다

이 기능은 제안요청서를 아예 읽지 않아도 되게 만드는 기능은 아닙니다.

대신 처음부터 끝까지 훑으며 요구사항 표를 만들고 목차를 계산하던 시간을 줄여줍니다.

작성자는 더 빨리 판단해야 할 지점에 도달할 수 있습니다.

마무리

제안요청서는 제안서 작성의 출발점입니다.

하지만 지금까지는 많은 시간을 들여 사람이 직접 읽고, 요구사항을 정리하고, 목차를 만들고, 페이지 수를 계산해야 했습니다.

이번에 만든 기능은 이 과정을 웹앱 안에서 자동화하는 시도였습니다.

PDF를 업로드하면 사업 정보를 추출하고, 핵심 요구사항을 구조화하고, 공식 요구사항 수와 AI 중요도를 계산하고, 제안서 목차와 목표 페이지 수를 분석합니다.

그리고 기존 제안서 라이브러리에서 기준 참고 제안서까지 연결합니다.

중요한 것은 단순히 RFP를 요약하는 것이 아니었습니다.

RFP를 제안서 작성자가 바로 사용할 수 있는 작성 계획 화면으로 바꾸는 것이 핵심이었습니다.

이 기능은 제안요청서를 읽지 않아도 되게 만드는 기능은 아닙니다.

대신 처음부터 끝까지 훑으며 요구사항 표를 만들고 목차를 계산하던 시간을 줄여, 작성자가 더 빨리 판단해야 할 지점에 도달하도록 돕는 기능입니다.