RFP 분석, 제안의 언어를 읽는 법 — 조달청 RFP를 예시로
"RFP를 제대로 읽지 못한 팀은, 결국 발주처가 원하지 않는 시스템을 완성한다."
1. RFP란 무엇인가
RFP(Request for Proposal) 는 _제안 요청서_다.
RFI가 "이런 사업을 하려는데, 어떻게 생각하세요?"라는 탐색의 언어라면,
RFP는 "이렇게 하겠습니다. 당신들은 어떻게 해결할 수 있습니까?"라는
제안하는 공식 문서다.
발주 기관은 RFP를 통해 사업의 범위, 기술 요건, 평가 기준을 명시하고,
참여 기업은 이를 분석해 제안서(Proposal) 를 제출함으로써 사업자 선정 경쟁에 뛰어든다.
RFP는 이후 계약의 기초가 되기 때문에, RFI와 달리 법적 구속력의 전 단계에 해당한다.
문서에 적힌 내용은 곧 계약 이행의 기준선이 된다.
| 구분 | RFI | RFP |
|---|---|---|
| 목적 | 시장 조사 / 기술 동향 파악 | 제안 요청 / 사업자 선정 |
| 구속력 | 없음 | 계약의 기초 |
| 응답 형태 | 의견서, 기술 자료 | 제안서 (기술 + 가격) |
| 이후 단계 | RFP 작성 | 계약 및 착수 |
2. RFP를 분석하는 목적
RFP 분석은 단순히 "무엇을 만들어야 하는가"를 파악하는 행위가 아니다.
그것은 전쟁 전 지형을 읽는 것에 가깝다.
- 사업 범위를 정확히 확정하여 개발 공수와 일정을 산정한다.
- 평가 항목과 배점을 분석하여 제안서의 전략적 강조점을 결정한다.
- 기술 요건의 실현 가능성을 검토하여 리스크를 사전에 식별한다.
- 모호한 요구사항을 찾아내어 질의서(Q&A)를 통해 명확화한다.
- 경쟁사 대비 우리의 강점을 어디에 배치할지 결정한다.
3. 조달청 RFP 구조 이해
나라장터(G2B)에 게시되는 공공 RFP는 대체로 아래의 구조를 따른다.
구조를 먼저 체화하면, 수백 페이지의 문서도 빠르게 항법할 수 있다.
## 작성 방법(목차)
1. 사업 개요
- 사업명 및 추진 목적
- 사업 범위 및 기간
- 예산 규모
2. 현황 및 문제점
- 현행 시스템 구성
- 개선 필요 사항
3. 제안 요청 사항
- 기능 요구사항 (FR)
- 비기능 요구사항 (NFR)
- 기술 요건 및 표준
4. 사업 수행 방법
- 추진 일정
- 산출물 목록
- 품질 보증 방안
5. 제안서 작성 기준
- 제안서 목차 및 분량
- 제출 서류 목록
6. 평가 기준 및 배점
- 기술 평가 항목
- 가격 평가 방식
7. 계약 조건
- 하자 보수 기간
- 지체 상금 조항4. 실전 RFP 분석 방법 — 6단계 프레임
Step 1. 사업 범위 확정 — "어디까지가 내 일인가"
RFP 분석에서 가장 먼저, 가장 냉정하게 읽어야 할 부분이 사업 범위다.
범위가 불명확한 채로 착수하면, 프로젝트 종반에 반드시 범위 분쟁(Scope Dispute) 이 발생한다.
예시: 조달청 전자조달시스템 고도화 RFP
"현행 입찰/낙찰 업무 전반에 대한 기능 개선 및 UI/UX 개선을 포함하며,
연계 기관과의 인터페이스 재설계를 포함한다."
이 한 줄에서 파악해야 할 것들:
### [범위 분석]
1. "기능 개선" → 기존 기능의 수정인가, 신규 기능 추가인가?
2. "UI/UX 개선" → 디자인 시스템 신규 구축인가, 부분 리뉴얼인가?
3. "인터페이스 재설계" → 연계 기관 수는? 프로토콜은?
4. "전반" → 이 단어 하나가 범위를 무한히 확장할 수 있는 함정어다."전반", "등", "포함하되 이에 한정하지 않음" 같은 표현은
반드시 질의서로 명확화해야 한다.
Step 2. 예산 역산 — "현실적으로 가능한가"
RFP에 명시된 예산은 곧 사업의 물리적 한계다.
요구사항의 볼륨과 예산 규모 사이의 괴리를 초기에 파악하지 못하면,
수익성 없는 사업에 뛰어드는 실수를 저지른다.
### [예산 역산 공식 (간략)]
AI가 작성해준 내용(1)
- 투입 가능 인월(MM) = 총예산 × (1 - 간접비율) ÷ 단가/MM
- 예) 총예산: 10억 간접비율: 30% MM단가: 700만원
- → 투입 가능 인월 = 10억 × 0.7 ÷ 700만 ≈ 100MM
- PM 1명 × 12개월 + 개발자 6명 × 12개월 = 84MM → 빠듯하다.예산 대비 요구사항이 현저히 많다면, 제안 전략 자체를 바꾸거나 불참을 결정하는 것도 실력이다.
Step 3. 기능 요구사항 분해 — "실제로 무엇을 만드는가"
RFI 분석과 마찬가지로, RFP의 기능 요구사항은 반드시 기능 트리(Function Tree) 로
분해해야 한다.
단, RFP는 RFI보다 구체적이므로 분해 수준도 더 깊어야 한다.
예시 요구사항: "입찰 참가자격 사전심사(PQ) 시스템 구축"
### 입찰 참가자격 사전심사 (PQ)
AI가 작성해준 내용(2)
입찰 참가자격 사전심사
├── 공고 관리
│ ├── PQ 공고 등록 / 수정 / 삭제
│ └── 공고 상태 관리 (접수중 / 마감 / 심사중 / 결과공개)
├── 신청서 접수
│ ├── 업체 정보 자동 연동 (사업자등록증, 면허)
│ ├── 첨부 서류 업로드 (PDF, HWP)
│ └── 접수 확인증 발급
├── 심사 처리
│ ├── 심사 기준 항목 설정
│ ├── 심사위원 배정
│ └── 점수 산정 및 합산
├── 결과 통보
│ ├── 합격 / 불합격 통보 (SMS, 이메일)
│ └── 이의신청 접수 / 처리
└── 통계 / 리포트
├── 심사 결과 통계
└── 연도별 집계 리포트이 분해 결과가 곧 WBS(Work Breakdown Structure) 의 초안이 된다.
Step 4. 비기능 요구사항 리스크 분석 — "보이지 않는 지뢰"
공공 RFP에서 비기능 요구사항은 선택이 아닌 의무다.
특히 아래 항목들은 검수 단계에서 반려의 원인이 되는 고위험 항목이다.
| 항목 | 공공 RFP 일반 기준 | 리스크 수준 |
|---|---|---|
| 응답시간 | 일반 조회 3초 이내 | ★★★☆☆ |
| 동시접속 | 500명 ~ 2,000명 | ★★★★☆ |
| 가용성 | 99.5% 이상 | ★★★☆☆ |
| 보안 취약점 점검 | 사업 완료 전 필수 수행 | ★★★★★ |
| 개인정보처리 | 개인정보보호법, ISMS-P | ★★★★★ |
| 접근성 | 웹 접근성 인증 마크(WA) | ★★★☆☆ |
| 소스코드 품질 | 정적 분석 도구 적용 | ★★☆☆☆ |
보안 취약점 점검은 특히 납품 전 외부 기관 점검 의무가 붙는 경우가 많다.
일정 계획 시 이 기간을 반드시 별도 확보해야 한다.
Step 5. 평가 기준 역분석 — "어디서 점수를 따는가"
RFP에서 가장 전략적으로 읽어야 할 부분이 바로 평가 기준표다.
발주처가 중요하게 생각하는 것이 배점에 그대로 반영되어 있기 때문이다.
예시: 기술 평가 배점 (총 100점)
### [기술 평가 항목 예시]
- 사업 이해도 및 추진 전략 (20점)
- 기능 요구사항 구현 방안 (30점)
- 기술 수준 및 개발 방법론 (20점)
- 프로젝트 관리 계획 (15점)
- 유지보수 및 기술 이전 계획 (10점)
- 유사 실적 (5점)이 배점표에서 읽어야 할 것:
### 리딩 포인트(배점표) → 중요함
- 30점짜리 "기능 구현 방안" → 제안서의 핵심축, 가장 두껍게 써야 한다.
- 20점짜리 "사업 이해도" → 현황 분석과 문제 정의를 얼마나 정확히 했는지 보여야 한다.
- 5점짜리 "유사 실적" → 레퍼런스가 없다면 보완 전략이 필요하다.배점이 낮다고 소홀히 하면 안 된다. 경쟁이 치열할수록 1
2점 차이로 당락이 갈린다.
(실제 사업에서 10
20점차 이상 나는 경우는 적다)
Step 6. 계약 조건 검토 — "리스크를 계약서에서 읽는다"
많은 개발팀이 계약 조건을 법무팀 영역으로만 여기고 기술 분석에서 제외하는 경향이 있다.
그러나 다음 항목들은 프로젝트 수행 방식에 직접적인 영향을 준다.
### [반드시 확인할 계약 조건]
1. 하자 보수 기간 → 통상 1년. 이 기간 내 결함 발생 시 무상 보수 의무. → 보안 취약점, 성능 저하 등이 하자로 간주되는 범위를 확인해야 한다.
2. 지체 상금 (납기 지연 패널티) → 통상 계약금액의 1/1000 × 지연일수. → 예: 10억 계약, 30일 지연 → 3,000만원 패널티.
3. 산출물 목록 및 기준 → 요구분석서, 설계서, 소스코드, 운영 매뉴얼 등 납품 목록 확인. → 산출물 표준 양식이 지정된 경우 별도 확인 필요.
4. 저작권 귀속 → 공공 사업은 대부분 발주 기관 귀속. → 자사 프레임워크, 라이브러리 사용 시 사전 협의 필요.5. 질의서(Q&A) 전략 — RFP의 빈틈을 메우는 법
모든 RFP에는 불명확한 지점이 존재한다.
그것을 그냥 넘기는 팀과, 질의서로 해소하는 팀의 사업 결과는 다르다.
좋은 질의 항목의 조건:
### 좋은 인터뷰 만들기
1. 범위가 모호한 항목 → "A 기능의 범위에 B가 포함되는지 확인 요청"
2. 기술 충돌 항목 → "Java 17 요건과 기존 레거시 Java 8 연동 방안"
3. 일정 비현실 항목 → "외부 연계 시스템 테스트 환경 제공 시점"
4. 기준 불명확 항목 → "성능 테스트 기준 시나리오 및 데이터 규모"단, 질의서는 경쟁사도 볼 수 있다는 점을 명심해야 한다.
우리만 알고 싶은 전략적 질문은 비공개 채널로 별도 문의하는 것이 현명하다.
6. RFP 분석 정리 템플릿
[사업명] RFP 분석 요약
기본 정보
- 발주 기관:
- 사업 기간:
- 예산 규모:
- 제안서 제출 마감:
사업 범위 요약
- 신규 개발 항목:
- 기능 개선 항목:
- 연계 시스템 목록:
기술 스택 요건
- 필수 기술:
- 권장 기술:
- 금지 기술 (OSS 라이선스 등):
비기능 요구사항 핵심
- 성능 기준:
- 보안 요건:
- 접근성 요건:
평가 배점 요약 및 전략
- 고배점 항목:
- 공략 포인트:
리스크 항목
질의 예정 항목
마치며
RFP는 발주 기관이 내미는 계약의 언어이자 평가의 기준이다. 이 문서를 표면적으로 읽는 팀은 기능 목록만 보고, 깊이 읽는 팀은 발주처의 불안과 기대, 그리고 사업의 숨겨진 맥락까지 읽어낸다.
그러나 RFP 역시 완전하지 않다. 문서는 발주 기관 담당자의 언어로 쓰인 것이고, 그 담당자조차 현업의 실제 고통을 온전히 담아내지 못하는 경우가 대부분이다.
결국 개발자는 RFP를 분석하는 것에서 멈추지 않고, 직접 현업 사용자를 인터뷰하여 "문서에 적히지 않은 진짜 요구사항"을 발굴하고, 이를 바탕으로 요구사항 정의서(SRS) 를 스스로 작성할 줄 알아야 한다.
'사업관리' 카테고리의 다른 글
| RFI 란 무엇인가? - 공공사업 (0) | 2026.04.18 |
|---|