Where Projects Become Outcomes

"프로젝트를 성과로 전환하다"

IT 인사이트/발주자를 위한 RFP 가이드

RFP는 프로젝트의 첫 산출물이다 (01/08)

hfcconsulting 2026. 7. 27. 16:17

발주자를 위한 RFP 가이드 · Ep.01

그 분쟁의 원본은
계약서가 아니라 RFP였다.

RFP는 프로젝트의 첫 산출물이다 · HFC Consulting


제안요청서(RFP)는 발주자가 만드는 첫 산출물이다. 그런데 많은 조직에서 RFP는 산출물이 아니라 통과 의례로 취급된다. 지난해 문서를 복사하고, 과업 내용에 "등"을 붙이고, 조달 일정에 맞춰 공고한다.

그 대가는 반드시 늦게, 더 비싸게 돌아온다. 검수 회의에서, 협상 테이블에서, 때로는 법정에서.

모든 분쟁에는 원본 문서가 있다

검수를 앞둔 회의실의 풍경은 대개 비슷하다. 발주 담당자가 화면을 가리킨다. "이 기능은 왜 없습니까." 수급인 PM이 제안서를 편다. "제안 범위에 없던 항목입니다." 발주자가 RFP를 편다. "여기 있지 않습니까. 통계 분석 기능 이라고." 회의는 그 한 글자 위에서 두 시간을 돈다.

계약 분쟁의 다수는 계약 협상에서 생기지 않는다. 계약서가 인용하는 원본, 즉 RFP에서 생긴다. 부실한 RFP가 만드는 비용은 세 번에 나눠 청구된다.

RFP의 부실 지점 드러나는 시점 발주자가 치르는 비용
과업범위 모호 구현 단계 범위 분쟁, 추가 과업 협상력 상실
완료 기준 부재 검수 단계 검수 지연, 하자담보책임 공방
활용 조건 누락 운영 단계 데이터 유출 위험, 지식재산권 분쟁

셋 모두 계약서 문구로 다투지만, 계약서는 RFP가 정의하지 않은 것을 만들어내지 못한다. 계약 조항의 설계는 2기 AI 계약 가이드 1화에서 다뤘다. 이번 연재는 그보다 한 걸음 앞, 조항이 태어나는 문서를 다룬다.

좋은 RFP의 3요소: 범위, 기준, 조건

범위는 무엇을 하는가만이 아니라 무엇을 하지 않는가다. 범위 제외 목록이 없는 RFP는 열려 있는 문이다. 열린 문의 통행료는 항상 발주자가 낸다.

기준은 언제 끝난 것인가에 대한 답이다. 기능 목록의 구현 여부만으로 완료를 정의하면, 작동하지만 쓰이지 않는 시스템도 검수를 통과한다. 완료의 정의는 계약이 아니라 RFP에서 태어나야 한다.

조건은 어떤 규칙 아래서 일하는가다. 수급인이 어떤 AI 도구를 쓸 수 있는지, 발주자의 데이터가 어디까지 이동할 수 있는지, 산출물의 지식재산권이 누구에게 귀속되는지. 계약 협상 테이블에서 처음 꺼내면 늦다. 발주 조건으로 먼저 공고되어야 제안 가격에 반영된다.

이것은 태도의 문제만이 아니라 제도의 요구이기도 하다. 공공 소프트웨어사업은 법령이 요구사항의 상세한 작성을 발주기관의 의무로 규정하고, 과업 변경의 심의 절차까지 두고 있다. 요구사항을 명확히 쓰는 일은 선택이 아니라 발주자의 책무라는 뜻이다.

AI 시대, RFP는 더 무거워졌다

AI가 생산 구간을 압축하면서 역설이 생겼다. 만드는 비용은 내려가는데, 무엇을 만들지 정의하는 비용은 그대로다. 프로젝트 원가에서 정의가 차지하는 비중이 커졌다는 뜻이다. 정의의 문서인 RFP의 무게도 그만큼 커졌다.

조건의 목록도 길어졌다. 수급인의 AI 도구 사용, 데이터의 외부 모델 학습 금지, AI 생성 산출물의 권리 관계. 몇 해 전 RFP에는 존재하지 않던 항목들이다. 발주자가 묻지 않으면 아무도 먼저 답하지 않는다. 발주자가 무엇을 알아야 하는지는 1기 완결편, 발주자의 알 권리에서 다뤘다. 이 연재는 그 알 권리를 문서로 만드는 방법이다.

반론 — "발주 조직에는 상세한 RFP를 쓸 인력도 시간도 없다. 그래서 '등'으로 쓰는 것이다."

대응 — 전부를 상세화하라는 요구가 아니다. 확정할 것과 위임할 것을 구분하고, 그 구분 자체를 문서에 남기라는 요구다. 확정하지 못한 요구를 확정된 것처럼 쓰는 순간 분쟁이 예약된다. 구분의 방법은 3화에서 다룬다.

지금 손 안의 RFP를 진단한다

RFP 자가진단 체크리스트 10문항 — "아니오"가 세 개 이상이면 공고 전 보완이 필요하다.

① 과업범위에서 "등", "일체", "최신"과 같은 열린 단어의 개수를 세어 보았는가.

② 하지 않는 일, 즉 범위 제외 목록이 한 줄이라도 있는가.

③ 요구사항마다 확정과 미확정이 구분되어 있는가.

④ 사업기간과 예산의 산정 근거를 제3자에게 설명할 수 있는가.

⑤ 검수기준에 기능 목록 외의 업무 지표가 포함되어 있는가.

⑥ 수급인의 AI 도구 사용 조건(허용·금지·고지)이 있는가.

⑦ 발주자 데이터의 반출·외부 학습 금지 조건이 있는가.

⑧ 산출물의 지식재산권 귀속이 명시되어 있는가.

⑨ 평가 항목이 제안서의 수사가 아니라 검증 가능한 사실을 묻는가.

⑩ RFP의 각 요구가 계약서의 어느 조항으로 이어질지 추적되는가.

열 문항이 이 연재의 지도다. 회차마다 한 영역씩, RFP에 바로 넣을 수 있는 문구와 양식으로 답한다.

이 연재의 지도

회차 다루는 질문 제공물
01 (이 글) RFP는 왜 첫 산출물인가 자가진단 10문항
02 과업범위 "등" 없이 범위를 쓰는 법 범위 기술 원칙 + 제외 목록 양식
03 요구 확정도 어디까지 쓰고 어디부터 맡기나 확정도 구분 기준 + 처리 문구
04 예산과 기간 AI 생산성 시대의 책정 근거 책정 점검표 + 재산정 트리거
05 AI 활용 조건 도구·데이터·지재권을 발주 조건으로 AI 조건 요구 항목표
06 제안 평가 점수표가 사업 방향을 정한다 평가 설계 원칙 + 검증 질문
07 검수기준 완료의 정의를 먼저 쓴다 업무 지표형 요구 문구
08 완결 RFP에서 계약까지의 추적성 RFP-계약 추적 체크리스트

계약서는 프로젝트의 마지막 방어선이다. 그러나 방어선의 위치를 정하는 것은 RFP다. 첫 산출물이 부실하면, 나머지 모든 산출물이 그 부실을 상속받는다.

📎 더 읽을거리

소프트웨어 진흥법 시행령 (국가법령정보센터) — 공공 소프트웨어사업의 요구사항 작성·과업 변경 심의 관련 규정 원문

KOSA, SW사업 대가산정 가이드 2025 개정판 공표 (디지털타임스) — 예산·기간 책정의 공인 기준선. 4화에서 상세히 다룬다

HFC의 관점

공고 전의 RFP 한 번의 검토가, 공고 후의 분쟁 세 번보다 쌉니다. HFC컨설팅은 발주 준비 단계에서 과업범위·검수기준·AI 활용 조건을 점검하는 RFP 리뷰를 수행합니다. 공고를 앞둔 사업이 있다면 문의해 주십시오.

changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

본 연재의 문구·양식 예시는 법률 자문을 대체하지 않으며, 실제 발주·계약 시 법무 검토를 권장합니다.


📚 발주자를 위한 RFP 가이드 (전 8화)

다음 편 ▶ 02 과업범위: "등"이라는 한 글자의 대가

연재 전체 보기 →