[캡스톤] RFP 분석 — 요건 분류부터 제안 대응 매트릭스까지

RFP(제안요청서) 대응을 잘한다는 것은 화려한 제안서를 쓰는 것이 아니라, 발주사가 요구한 것을 하나도 빠뜨리지 않고, 우리가 할 수 있는 것과 없는 것을 정직하게 매핑하는 것입니다. 평가자는 미사여구가 아니라 "필수 요건을 충족했는가, 근거가 있는가, 위험을 알고 있는가"를 봅니다.

그래서 RFP 분석은 이 트랙의 세 가지 기술을 한 자리에서 씁니다.

• 요구사항 관리 — 요건을 ID로 식별하고 분류·추적한다(요구 분류표 → 준수 매트릭스).
• AI 활용 분석 — 긴 RFP에서 요건을 빠르게 추출·분류하되, 사람이 검증한다.
• 리스크 관리 — 모호·법적·일정·기술 위험을 미리 목록화해 대응을 설계한다.

이 캡스톤의 산출물은 다섯 가지가 한 세트로 묶입니다. 이 다섯이 서로를 참조하며 하나의 추적 체계를 이룹니다.

그림: 요구 분류표가 모든 산출물의 뿌리이며, 영역별 분석을 거쳐 질의·리스크·준수 매트릭스로 분기하는 추적 가능성 싸움이다.

실제 RFP는 수십~수백 개 요건을 담지만, 여기서는 분석 흐름을 익히기 위해 대표 요건 일부를 가상으로 발췌해 사용합니다. 고객사는 종이 계약을 전자계약 시스템으로 전환하려 합니다.

RFP 원문에서 발췌한 문장 예시는 다음과 같습니다(아직 분류 전, 자연어 그대로).

- 전자서명은 공인전자서명에 준하는 법적 효력을 가져야 한다.
- 계약 문서는 위·변조 방지를 위해 무결성을 보장해야 한다.
- 기존 사내 ERP(계정·조직 정보)와 연동되어야 한다.
- 동시 접속 사용자 500명을 안정적으로 지원해야 한다.
- 모바일(iOS/Android)에서도 서명·열람이 가능해야 한다.
- 시스템 가용성은 연 99.5% 이상이어야 한다.
- 장애 발생 시 4시간 이내 복구(RTO)를 목표로 한다.
- 관리자 화면에서 계약 현황 통계를 제공하면 가점.
- 다국어(영어) 지원 시 가점.

여기서 이미 두 가지 신호가 보입니다. "법적 효력"·"무결성"은 타협 불가 필수이고, "ERP와 연동"은 범위가 모호합니다(어느 시스템과, 어느 수준으로?). 분석은 이 신호를 구조화하는 일입니다.

가장 먼저 자연어 문장을 추적 가능한 항목으로 바꿉니다. 각 요건에 고유 ID(영역 약자 + 번호)를 부여하고, 필수/선택(가점)과 영역(기술/보안/운영)을 분류합니다. 이 표가 이후 모든 산출물의 뿌리가 됩니다.

분류 원칙 세 가지입니다.

• 하나의 ID는 하나의 검증 가능한 요건 — "연동되고 빨라야 한다"처럼 두 가지가 묶이면 둘로 쪼갠다.
• 필수와 가점을 반드시 구분 — 필수 미충족은 탈락 사유, 가점은 더하기. 자원 배분 우선순위가 다르다.
• 영역 분류는 분석 담당자를 정하기 위함 — 보안 요건은 보안 담당이, 운영 요건은 운영 담당이 검토한다.

분류표가 "무엇을 요구했나"라면, 요건 분석은 "우리가 어떻게 충족하며 어디가 어려운가"입니다. 영역별 관점이 다릅니다.

• 기술 분석 — 우리 솔루션·아키텍처로 충족 가능한가, 커스터마이징 규모는, 연동 대상 시스템의 인터페이스는 확인됐는가. (REQ-TEC-01의 ERP는 표준 API가 없으면 큰 위험.)
• 보안 분석 — 법·규제 요건인가, 인증·암호화 수준은. 공인전자서명(REQ-SEC-01)은 관련 법령과 인증서 체계를 충족해야 하므로 타협 불가.
• 운영 분석 — SLA·가용성·RTO를 우리 운영 체계로 보증할 수 있는가. 99.5%(REQ-OPS-01)는 이중화·모니터링 비용을 동반한다.

분석 결과를 한눈에 정리하면 충족 난이도와 위험이 드러납니다.

여기서 REQ-TEC-01이 빨간불입니다. "ERP와 연동"이 어느 ERP·어느 데이터·실시간인지 배치인지에 따라 공수가 몇 배 차이가 납니다. 이건 분석으로 끝낼 게 아니라 질의사항으로 넘겨야 합니다.

준수 매트릭스는 평가자가 "이 제안사가 무엇을, 어떤 근거로 충족하는가"를 한 표로 확인하는 핵심 산출물입니다. 정직함이 곧 신뢰입니다.

이 표의 힘은 모든 필수 요건이 한 줄씩 추적되고, 부분 준수가 질의·리스크 ID와 연결된다는 데 있습니다. REQ-TEC-01을 거짓 '준수'로 적었다면 계약 후 ERP 규격이 드러나는 순간 분쟁이 됩니다. '부분 준수'로 정직하게 적고 가정·질의·리스크를 함께 보인 제안이 결국 신뢰를 얻습니다.