AI 제안서 작성 순서: RFP를 받은 뒤 2주 일정표

RFP를 받은 날 가장 먼저 PPT를 열면, 중간에 빠진 요구사항을 발견했을 때 앞 장부터 다시 고치게 된다. AI에게 파일을 넣고 “제안서 만들어줘”라고 부탁해도 어떤 문장이 RFP의 어느 요구에 답하는지 추적하기 어렵다.

운영자는 브런치 글 「대행사 직원이 제안서 작성 모드로 전환했습니다」에서 대행사 제안 업무를 산업 조사, 해결책 설계, 세부 아이디어와 장표 작성의 흐름으로 설명했다. 당시 보통 2~3주의 준비 기간을 받았고, 때로는 일주일 안에 제출해야 했다. 표준 일정이 아닌 한 실무자의 공개 경험이다.

이 글은 그 경험을 AI가 있는 현재의 작업 순서로 바꾼 것이다. 핵심은 RFP의 요구와 사람의 판단을 먼저 고정하고 AI를 추출·반론·초안에 제한적으로 쓰는 데 있다.

30초 답: PPT보다 요구사항 추적표를 먼저 만든다

2주 일정이라면 다음 순서로 나눈다.

1. 제출 형식과 필수 조건을 먼저 확정한다.
2. RFP 문장마다 번호를 붙여 요구사항 추적표를 만든다.
3. 모르는 산업·고객·경쟁 정보를 조사하고 출처를 남긴다.
4. 사람이 문제 정의와 솔루션 초안을 먼저 쓴다.
5. AI로 빠진 요구, 반론과 설명 공백을 찾는다.
6. 목차와 장표를 만들고 요구사항 번호를 다시 연결한다.
7. 사실·숫자·권리·보안·제출 형식을 별도 검수한다.

AI는 RFP를 대신 결정하는 도구가 아니다. 요구사항을 표로 옮기고, 사람이 만든 방향에서 빠진 연결을 찾는 보조자다.

첫날: 참여 여부와 제출 조건부터 결정한다

자료조사에 들어가기 전 첫날에는 다음 질문부터 답한다.

확인 항목	질문	결과
자격	우리가 반드시 충족해야 할 자격·실적 조건이 있는가	참여 가능 / 확인 필요 / 참여 어려움
제출	마감 시각, 파일 형식, 분량, 발표 시간이 무엇인가	제출 체크리스트
범위	포함·제외 업무와 필수 산출물이 무엇인가	작업 범위 초안
평가	어떤 항목이 평가되고 배점·우선순위가 공개됐는가	강조할 근거
인력	현재 프로젝트를 유지하면서 누가 얼마의 시간을 낼 수 있는가	현실적인 작업량
보안	RFP와 내부 자료를 어떤 환경에서 다룰 수 있는가	AI 입력 가능 범위

공개되지 않은 RFP를 외부 AI에 넣기 전에 회사 정책과 계약 조건을 확인한다. AI 사용이 허용되지 않았거나 애매하다면 문서 전체를 올리지 않는다. 공개 가능한 요구사항 구조와 완전한 합성 예제로 먼저 절차를 시험한다.

1~3일차: RFP 요구사항 추적표를 만든다

RFP 요약본만 읽고 시작하면 작은 조건이 사라질 수 있다. 원문 문장에 R1, R2처럼 번호를 붙이고, 답변 위치와 책임자를 연결한다.

번호	RFP 원문 요지	필수 여부	제안서에서 답할 위치	근거·담당	상태
R1	대상 고객과 핵심 문제 제시	필수	2장 상황 분석	조사 담당	조사 중
R2	실행 프로그램 3개 이상	필수	8~14장 실행안	기획 담당	초안
R3	월간 성과 보고 방식	필수	18장 운영 체계	운영 담당	미작성
R4	선택 제안 허용	선택	부록	전체 합의	보류

AI에게 요구사항을 추출하게 했다면 반드시 원문 페이지와 대조한다. 표에 없는 조건은 사라지기 쉽고, AI가 문장 둘을 합치면서 의미를 바꿀 수도 있다. 요구사항별 원문 위치를 남겨야 사람이 다시 확인할 수 있다.

3~5일차: 산업 조사는 ‘알아야 할 것’부터 좁힌다

운영자의 원문에는 처음 접한 산업을 이해하는 데 며칠이 걸렸다는 경험이 나온다. 검색 결과를 한꺼번에 모으면 출처만 많아지고 문제 정의는 흐려질 수 있다.

먼저 조사 질문을 세 묶음으로 나눈다.

• 고객: 누가 어떤 상황에서 불편을 겪는가?
• 시장: 대안은 무엇이고 현재 선택 기준은 무엇인가?
• 발주 과제: RFP가 해결하려는 변화는 무엇인가?

자료마다 발행일, 조사 대상, 표본, 정의와 원문 링크를 남긴다. AI가 요약한 문장을 근거로 쓰지 말고 원자료에서 확인한다. AI 답변 오류 검증 7단계의 방식으로 존재 여부, 최신성, 문맥과 숫자를 따로 본다.

5~7일차: 사람의 문제 정의와 솔루션을 먼저 쓴다

AI에게 먼저 솔루션을 달라고 하면 흔한 채널과 익숙한 표현이 빠르게 나온다. 제안의 핵심은 아이디어 수가 아니라 왜 이 문제를 이렇게 풀어야 하는지 설명하는 논리다.

사람이 먼저 아래 세 문장을 쓴다.

1. RFP가 말한 표면 과제는 무엇인가?
2. 우리가 자료에서 확인한 실제 장애물은 무엇인가?
3. 어떤 변화가 생기면 해결됐다고 볼 것인가?

그다음 서로 다른 방향의 솔루션 세 개를 만든다. AI 브레인스토밍 6단계처럼 AI는 사람의 초안을 없애지 않고, 조건 위반·근거 없는 가정·설명 공백을 찾는 데 쓴다.

8일차: 목차를 ‘읽는 사람의 질문’ 순서로 만든다

RFP가 지정한 목차가 있다면 마음대로 없애지 않는다. 정해진 목차 안에서 각 장이 답해야 할 질문을 한 줄씩 붙인다.

예를 들어 ‘실행 전략’이라는 장에는 “그래서 누구에게 무엇을 어떻게 바꿀 것인가?”가, ‘운영 체계’에는 “누가 언제 확인하고 문제가 생기면 어디로 돌아가는가?”가 들어갈 수 있다.

장표 제목은 내용의 이름보다 결론에 가까워야 한다. “시장 현황”보다 “정보 부족보다 선택 기준의 부재가 이탈을 만든다”가 읽는 사람에게 다음 내용을 예고한다. 단, 근거가 없다면 결론형 제목도 단정이 된다.

9~11일차: 장표를 나누되 논리는 한 사람이 연결한다

여러 사람이 장표를 동시에 만들 때 분량만 나누면 같은 용어와 앞뒤 결론이 달라질 수 있다.

역할	책임	AI를 쓸 수 있는 부분	사람이 확인할 것
제안 리드	전체 논리와 선택 기준	장별 핵심 질문 공백 찾기	최종 주장과 우선순위
조사 담당	출처·데이터·경쟁 자료	공개 자료 분류·표 초안	원문과 수치 대조
솔루션 담당	실행안과 일정	대안·반론 정리	운영 가능성과 고유성
문서 담당	장표 흐름과 표현	제목 길이·중복 점검	시각적 위계와 발표 흐름
검수 담당	제출 조건과 오류	요구사항 누락 후보 표시	최종 파일·권리·보안 확인

AI로 PPT 구성안을 만드는 법을 참고하되, AI가 정한 장표 수를 그대로 목표로 삼지 않는다. 발표 시간, 평가 항목과 전달해야 할 결론에 맞춰 줄인다.

12~13일차: 내용 검수와 제출 검수를 분리한다

마감 직전 검수는 두 번 해야 한다. 내용 검수와 파일 검수는 보는 대상이 다르다.

내용 검수

• 모든 필수 요구사항에 답했는가?
• 주장 옆에 출처·근거 또는 가정 표시가 있는가?
• 숫자, 기간, 단위와 비교 기준이 같은가?
• 솔루션이 문제 정의와 연결되는가?
• 검증되지 않은 효과를 약속하지 않는가?

제출 검수

• 파일명, 형식, 분량과 마감 시각이 맞는가?
• 숨겨진 메모·댓글·변경 기록이 남아 있지 않은가?
• 사용 권리를 확인하지 않은 이미지·폰트가 없는가?
• 고객·직원·계정·내부 시스템 정보가 노출되지 않는가?
• 발표본과 제출본의 버전이 같은가?

최소한 제출 체크는 다른 사람이 원문 조건과 나란히 확인한다.

14일차: 제출 뒤에도 판단 기록을 남긴다

제출 파일만 남기면 다음 제안에서 같은 토론을 반복한다. 다음 내용을 한 장으로 기록한다.

• 끝까지 남긴 문제 정의
• 선택한 솔루션과 버린 후보의 이유
• RFP에서 가장 중요하게 본 조건
• 검증하지 못한 가정
• 다음에는 먼저 확인할 자료
• AI가 유용했던 단계와 오히려 손이 더 간 단계

이 기록은 수주 여부와 별개로 다음 업무의 입력이 된다. AI에게 업무 판단을 인수인계하는 10문항의 형식으로 완료 기준과 예외를 정리하면 반복 작업으로 바꾸기 쉽다.

합성 사례: 교육 서비스 홍보 제안을 2주에 준비한다면

가상의 직무교육 서비스 ‘모노랩’이 신규 과정 홍보 운영사를 찾는다고 가정한다. 아래 조건은 설명용 합성 자료이며 실제 RFP나 고객 사례가 아니다.

• 대상: 첫 이직을 준비하는 3~5년 차 직장인
• 필수: 3개월 콘텐츠 운영안, 신청 전환 경로, 월간 보고 방식
• 제출: 25장 이내 PDF, 20분 발표
• 금지: 취업 성공률처럼 확인되지 않은 결과 약속

1~3일차에는 R1 대상, R2 운영안, R3 전환 경로, R4 보고, R5 금지 표현으로 나눈다. 3~5일차에는 직장인이 신청 전에 묻는 질문과 기존 교육 선택 기준을 공식·공개 자료에서 조사한다.

5~7일차에는 사람이 먼저 “정보가 없어서가 아니라 내 상황에 맞는 과정인지 판단하기 어려워 신청을 미룬다”는 가설을 쓴다. AI에게는 이 가설을 사실로 만들지 말고, 필요한 근거와 반대 가능성을 찾게 한다.

8~11일차에는 ‘상황 질문 → 과정 선택 기준 → 학습 장면 → 신청 전 확인’의 흐름으로 장표를 만든다. 12~13일차에는 취업 결과를 암시하는 문장을 제거하고, 모든 실행안이 3개월 범위 안에 있는지 대조한다.

사용 가능한 시간을 계산하는 법

달력상 2주와 실제 작업 가능 시간은 다르다. 기존 고객 업무가 있다면 먼저 빼야 한다.

제안 가용 시간 = 참여 인원 × 작업일 × 하루 집중 가능 시간 − 기존 업무·회의 시간

4명이 10일 동안 하루 3시간을 낼 수 있다면 120시간이다. 기존 회의와 필수 업무가 총 28시간이라면 실제 가용 시간은 92시간이다. 이 값에 맞춰 조사·솔루션·장표·검수 시간을 배분한다. 야근을 기본값으로 넣어 가용 시간을 부풀리지 않는다.

복사해서 쓰는 RFP 요구사항표 프롬프트

너는 제안서를 대신 쓰는 사람이 아니라 RFP 요구사항 추출 보조자다.

공개 또는 사용 승인을 받은 문장만 입력한다.
[RFP 문장. 페이지나 문단 번호 포함]
아래 열로 표를 만들어라.

요구사항 번호
원문 요지
필수 / 선택 / 확인 필요
제출 형식·분량·기한 조건
평가 항목과 연결되는 문장
제안서에서 답할 위치
사람이 확인해야 할 질문

서로 다른 요구를 임의로 합치지 마라. 원문에 없는 자격·성과·예산 조건을 만들지 마라. 추정은 사실과 분리해 ‘확인 필요’로 표시하라. 각 행 끝에 원문 페이지 또는 문단 번호를 남겨라.</code></pre>
잘못 쓰면 생기는 문제

RFP 전체를 승인되지 않은 외부 AI에 업로드한다.
요약본만 보고 필수 제출 조건을 놓친다.
AI가 만든 산업 수치와 사례를 원문 확인 없이 넣는다.
사람의 문제 정의 없이 아이디어 수부터 늘린다.
PPT 디자인을 먼저 확정해 논리 변경 비용을 키운다.
마지막 날까지 내용 수정과 파일 제출 검수를 함께 한다.

자주 묻는 질문
RFP 전체를 AI에 넣어도 되나요?
공개 문서인지, 회사가 허용한 서비스와 계정인지, 계약상 제한이 없는지 먼저 확인한다. 확실하지 않으면 전체 파일을 넣지 말고 공개 가능한 요구사항 구조와 합성 문장으로 시험한다.
1주밖에 없으면 순서를 생략해야 하나요?
단계를 없애기보다 각 단계의 범위를 줄인다. 요구사항 추적표와 제출 검수는 남기고, 조사 질문·후보 수·장표 수를 줄인다. 무엇을 하지 않을지도 첫날 합의한다.
AI가 제안서 전체를 써주면 더 빠르지 않나요?
문장 생성 시간은 줄 수 있지만 조건 누락, 근거 확인과 표현 통일에 시간이 다시 들 수 있다. AI가 만든 초안을 고치는 시간까지 측정해 AI 업무 자동화 ROI 계산기로 비교한다.
제안서 검수는 몇 명이 해야 하나요?
정답은 없지만 전체 논리를 보는 사람과 제출 형식을 보는 역할을 분리하는 편이 좋다. 인원이 부족하면 같은 사람이라도 시간을 나눠 체크리스트를 바꿔서 본다.
근거와 공식 출처

브런치: 대행사 직원이 제안서 작성 모드로 전환했습니다 — 산업 조사, 솔루션 설계, 장표 작성으로 이어지는 운영자의 대행사 경험.
브런치: AI가 뭉뚝한 게 아니라, 내가 뭉뚝해지고 있었다 — AI를 반론과 구조화에 사용하되 사람의 날것 아이디어를 먼저 남기는 작업 순서의 근거.
Google Cloud: 프롬프트 설계 전략 — 목표·맥락·제약·예시를 구조화하고 반복 평가하는 기술적 참고.
NIST: AI Risk Management Framework — AI 결과의 신뢰성과 위험을 검토하기 위한 자발적 프레임워크.

편집 안내: 공개 브런치 원문의 경험을 검색 질문과 실행 단계로 재구성했으며 문장을 복제하지 않았다. 2주 표, 역할표, 계산식과 ‘모노랩’ 사례는 설명을 위해 새로 만든 합성 자료다. 실제 RFP·고객·수주 결과·비공개 수치는 사용하지 않았다.