본문으로 건너뛰기
Mephify
작성 가이드

운영자가 엮은 글

제안요청서(RFP) 작성 프롬프트 — 아직 안 정해진 것을 다루는 법

예산도 기간도 미정인 상태에서 RFP를 써야 할 때, 빈칸을 어떻게 남겨야 문서가 성립하는지.

글: 메피파이 운영자읽는 시간 2분

Read the English edition

무엇이 어려운가

제안요청서를 쓰기 시작하는 시점에는 대개 아직 안 정해진 것이 정해진 것보다 많습니다. 예산은 부서 협의 중이고, 사업 기간은 예산이 나와야 정해지고, 컨소시엄 허용 여부는 아무도 묻지 않았습니다.

이 상태로 AI에게 맡기면 미정인 것이 정해진 것처럼 채워집니다. '총 사업비 2억 원 이내', '계약일로부터 6개월' 같은 문장이 자연스럽게 들어가는데, 그 숫자의 출처는 없습니다. 문서를 받은 사람은 그것이 확정값인지 예시인지 알 수 없고, 그대로 공고가 나가면 그 숫자가 사실이 됩니다.

항목마다 확정 상태를 표기하게 한다

해법은 빈칸을 없애는 것이 아니라 빈칸에 이름을 붙이는 것입니다. 항목마다 셋 중 하나를 달게 합니다.

  • CONFIRMED — 확정된 값. 근거가 있습니다
  • PROVISIONAL — 잠정값. 검토 중이며 바뀔 수 있습니다
  • [입력 필요] — 아직 없는 값. 여기에 더해 무엇으로 채우는지 한 줄을 같이 답니다

세 번째의 '무엇으로 채우는지'가 실무에서 가장 유용합니다. [입력 필요: 총 사업비]만 있으면 누가 언제 채울지 아무도 모르지만, '예산부서 확정 후 기재'가 붙어 있으면 그것이 곧 할 일 목록이 됩니다.

이렇게 적습니다

예산이랑 컨소시엄 허용 여부는 아직 미정이야. 추측해서 채우지 말고 미정 항목으로 표시한 다음, 각각 무엇으로 채우는지 한 줄씩 달아줘.

법령은 이름만 지목하고 해석하지 않게 한다

공공 발주라면 국가계약법이, 미국이라면 FAR이 걸릴 수 있습니다. 그런데 AI에게 그 내용을 설명하게 하면 안 됩니다. 조문 해석을 지어내는 것이 이 문서에서 가장 위험한 실패입니다.

요청에 이렇게 적습니다: 어느 규정이 걸릴 수 있는지 이름으로 지목하고, 적용 여부는 담당 부서에 확인하도록 표시해줘. 그러면 문서가 '이 조항에 따르면…'이 아니라 '국가계약법 적용 여부 확인 필요'로 나옵니다. 후자가 맞습니다.

완성 지시문이 요구하는 아홉 부

미정 표기와 법령 지목은 문장의 규칙입니다. 그 위에 이 서비스의 제안요청서 지시문은 문서의 뼈대 아홉 부를 요구합니다. 하나라도 빠지면 실무에서 그대로 쓸 수 없는 문서가 되기 때문입니다.

  • ① 사업 개요 — 사업명·발주기관·목적·배경·예산·계약 조건. 항목마다 확정 상태 표기
  • ② 과업 범위 — 현황·목표 구조·구축·연계·시험·전환·교육·운영지원, 그리고 범위 밖(Out)의 명시
  • ③ 요구사항 명세 — 문서의 심장입니다. 아래에서 따로 설명합니다
  • ④ 사업 관리 요구사항 — 추진 체계와 보고 주기, 일정·진척, 품질 보증, 위험, 형상·변경, 인력 투입과 교체, 하자보수와 유지관리. 이 부가 통째로 빠진 RFP가 가장 흔합니다
  • ⑤ 산출물 목록 — 단계별 산출물·제출 시점·검수 주체·승인 절차. 승인자가 없는 산출물이 남지 않게
  • ⑥ 제안서 작성 지침과 제출 서류 — 제안서 목차, 필수 기술 내용, 제출 형식
  • ⑦ 평가 기준표 — 평가 항목·세부 관점·평가 방식은 잠정 초안으로 제시하고, 배점 칸만 비웁니다. 배점을 지어내지 말라는 것이지 표를 만들지 말라는 것이 아닙니다
  • ⑧ 추적성 표 — 사업 목표 → 과업 범위 → 요구사항 → 산출물 → 검수 → 평가 항목이 한 줄로 이어지는지. 이어지지 않는 고아 항목을 따로 모읍니다
  • ⑨ 추진 일정과 계약·조달 확인 사항 — 날짜는 빈칸, 적용 법령·조달 절차·컨소시엄·하도급은 확인 항목

요구사항 한 줄에 의무 하나

요구사항 명세가 심장인 이유는 제안사가 무엇을 약속하고 발주자가 무엇을 검수할지가 여기서 정해지기 때문입니다. 지시문은 기능·비기능·인터페이스·보안·데이터·운영으로 갈라 FR-01처럼 번호를 붙이고, 한 문장에 하나의 의무만 담게 합니다.

이렇게 갈립니다

'사용자 인증과 권한 관리, 로그 기록을 지원해야 한다'는 요구사항 하나가 아니라 셋입니다. 검수할 때 로그만 빠져 있으면 통과인지 실패인지 갈리지 않습니다.

인증·권한·로그를 각각 한 줄로 나누면 항목마다 검수 방법이 붙습니다.

요구사항마다 다섯이 따라붙습니다. 근거 상태(확정/잠정/미정), 산출물, 검수 방법, 증빙, 책임 주체입니다. 이 다섯이 없는 요구사항은 검수할 수 없는 요구사항이고, 계약 분쟁이 나는 자리입니다. 지시문의 마지막에는 남은 빈칸을 번호로 모아 누가 결정하는지까지 적고, 기관 표준 양식이 있으면 파일을 받아 그 목차에 맞춰 다시 정리하겠다고 제안하게 합니다.

직접 쓸 때의 체크리스트

  1. 1확정된 값과 미정인 값을 요청에서 먼저 갈랐는가
  2. 2미정인 것을 '추측해서 채우지 마'라고 명시했는가
  3. 3빈칸마다 '무엇으로 채우는지'를 요구했는가
  4. 4법령을 해석하지 말고 이름만 지목하라고 적었는가
  5. 5발주 주체가 공공인지 민간인지 밝혔는가 — 이것 하나로 문서 구조가 바뀝니다