정보시스템 발주에서 RFI와 RFP를 설계하는 방법

발주 문서의 품질이 시스템 도입 결과를 좌우한다

정보시스템은 비즈니스 프로세스와 의사결정, 경쟁력에 직접 영향을 준다. 요구사항과 공급자 선정 기준이 정리되지 않은 상태에서 도입을 시작하면 재무적 손실과 업무 효율 저하로 이어질 수 있다.

RFI(Request For Information)와 RFP(Request For Proposal)는 발주자가 필요한 정보를 얻고, 적합한 공급자를 비교·선정하기 위한 장치다. 비용 효율성, 도입 성공률, 장기적인 시스템 만족도도 이 과정의 설계에 영향을 받는다.

도입 검토부터 유지보수까지 이어지는 발주 흐름

⤢✕

도입 필요성을 검토할 때는 현 시스템의 문제를 분석하고, 비즈니스 요구사항과 시스템 요구사항을 연결해야 한다. ROI와 TCO 분석도 이 단계에서 수행한다.

예산과 일정에는 인력, 하드웨어, 소프트웨어, 컨설팅 비용을 반영하고 단계별 마일스톤과 리스크 관리 계획을 세운다. 이후 RFI와 RFP에서는 요구사항 명세, 공급자 자격 요건, 평가 기준을 구체화한다.

공급자를 고르는 단계에서는 기술·가격 평가와 BMT를 수행하고 계약 조건을 협상한다. 계약 후에는 개발 또는 도입 과정을 모니터링하며 품질 보증과 변경 관리를 이어간다.

RFI로 시장과 후보 공급자를 먼저 파악한다

RFI는 정식 제안요청에 앞서 시장 및 기술 정보를 수집하는 문서다. 발주자는 이를 통해 문제 해결 방식의 선택지를 확인하고, 예산·일정 계획의 근거를 확보하며, 공급자의 경험과 역량을 초기 수준에서 평가할 수 있다.

RFI에는 발주 기관의 비즈니스 모델, 조직 구조, 프로젝트 관련 부서, 현재 시스템 환경을 담는다. 프로젝트 배경과 목적, 개략적인 범위, 예상 일정 및 예산 규모도 함께 제시한다. 공급자에게는 일반 현황, 유사 프로젝트 경험, 기술 역량과 자격증, 제품·서비스 라인업, 대략적인 가격 정보를 요청할 수 있다.

대형 제조기업이 레거시 시스템의 한계로 차세대 ERP를 검토한 사례에서는 5개 주요 ERP 벤더에 RFI를 보냈다. 제조업 특화 기능, 글로벌 구축 경험, 현지화 지원 능력을 수집한 뒤 3개 벤더로 후보를 좁혀 RFP 대상을 정했다.

새로운 규제 대응을 위해 보안 솔루션이 필요했던 금융기관은 10개 공급자에게 RFI를 배포했다. 금융권 레퍼런스, 인증 취득 현황, 규제 대응 기능을 확인해 기술 트렌드와 가격 범위를 파악하고 예산 및 RFP 요구사항을 조정했다.

RFP에는 요구사항과 선정 기준을 함께 명시한다

RFP는 공급자에게 제출할 제안을 공식적으로 요청하는 문서다. 프로젝트 범위, 일정, 예산, 구체적인 요구사항과 공급자 평가 기준을 제시하며, 계약의 기초가 되는 법적 의미도 가진다.

⤢✕

요구사항은 모호한 표현보다 검증 가능한 기준으로 작성해야 한다. 예를 들어 “빠른 처리 속도” 대신 “초당 1,000건 이상 처리 가능”처럼 조건을 분명히 적는다.

필수 요구사항인 Must-Have와 선택 요구사항인 Nice-to-Have를 구분하고, 요구사항별 중요도를 표시하면 공급자가 집중해야 할 영역을 알 수 있다. 기술 평가와 가격 평가의 비중, 세부 항목과 배점도 공개해야 평가 가능한 제안서를 받을 수 있다.

일정과 예산 범위 역시 현실적으로 제시해야 한다. 무리한 일정은 품질 저하와 리스크 증가로 이어질 수 있으며, 예산 범위는 실현 가능한 제안을 유도하는 기준이 된다.

공공 부문은 국가계약법과 전자정부법 등 관련 법규·지침 준수, 투명성, 공정성, 상세한 평가 절차가 중요하다. 금융 부문은 금융 규제, 보안, 업무 연속성, GDPR·SOX 등 해외 규제 대응 필요성을 다룬다. 제조 부문에서는 기존 생산 시스템과의 통합, 글로벌 확장성과 현지화, 실시간 처리 능력과 안정성을 중시한다.

제안서 비교는 문서 검토에서 끝나지 않는다

제안서는 공급자가 RFP에 대응해 작성하는 공식 문서다. 기술 역량, 프로젝트 수행 방법론, 가격이 포함되며, 발주자는 이를 통해 공급자의 비즈니스 및 기술적 이해도를 판단한다. 계약 체결 시에도 법적 구속력의 기초 자료가 된다.

평가위원회에는 IT 부서, 사용자 부서, 경영진 등 이해관계자를 포함하고, 필요하면 외부 전문가를 참여시켜 객관성을 확보한다. 평가위원의 이해충돌을 방지하는 규정도 필요하다.

평가는 기본 요건 충족 여부를 확인하는 적격성 평가로 시작할 수 있다. 이어 기술·가격 평가, 프레젠테이션과 질의응답을 진행하고, 필요 시 BMT를 수행한다.

⤢✕

BMT는 핵심 기능과 성능을 실제로 검증하는 절차다. 발주자 환경과 유사한 테스트 환경을 구성하고, 측정 가능한 항목을 설계해 모든 후보 공급자를 같은 조건에서 평가한다.

계약 협상에서는 제안 내용이 계약에 반영됐는지 확인한다. SLA(Service Level Agreement), 지적재산권과 소스코드 소유권, 단계별 검수와 지불 조건, 유지보수 및 기술지원 조건을 명확히 정리해야 한다.

발주 단계에서 반복되는 실패를 피하는 기준

성공적인 발주는 시스템 도입의 비즈니스 가치를 분명히 하고, 구체적이며 측정 가능한 성공 지표를 세우는 데서 출발한다. 경영진의 지원과 참여도 필요하다.

요구사항 분석에는 충분한 시간을 들여야 하며, 시장 조사와 벤치마킹을 통해 현실적인 기대치를 설정해야 한다. 내부 이해관계자의 의견을 수렴하고 합의하는 과정도 빠질 수 없다. 필요 시 외부 컨설팅을 활용하고, 내부 전문 인력을 양성하거나 유사 프로젝트 경험자를 참여시키는 방법도 있다.

A 공공기관은 RFP에 과도한 요구사항과 비현실적인 일정을 담았다. 공급자의 무리한 수주로 품질 저하와 납기 지연이 발생했고, 최종 시스템 활용도도 낮았다. 핵심 요구사항 중심으로 현실적인 RFP를 설계해야 한다는 교훈을 남긴 사례다.

B 기업의 CRM 시스템 도입에서는 RFI와 RFP 단계의 사용자 요구사항 조사가 부족했다. 도입 후 사용자 저항과 추가 개발이 발생해 예산을 초과했다. RFP를 작성하기 전에 내부 요구사항을 충분히 수집해야 한다.

C 금융기관은 보안 솔루션 RFP에서 성능 요구사항은 상세히 썼지만 호환성 요구사항을 빠뜨렸다. 기존 시스템과의 통합 문제로 추가 비용과 서비스 지연이 발생했다. 기능 요구사항뿐 아니라 비기능적 요구사항도 상세히 포함해야 한다.

디지털 전환 프로젝트에서 달라지는 요청서의 범위

발주 방식은 전통적인 폭포수 모델에서 애자일 방식으로 변화하고 있다. MVP(Minimum Viable Product)를 도입하고 단계적으로 구현한 뒤 피드백에 따라 개선하는 접근이 가능하다. 계약에서는 Time & Material 등 유연한 모델도 고려한다.

클라우드 서비스 RFP는 SaaS, PaaS, IaaS별 특성에 맞춰 요구사항을 구성해야 한다. 구독 기반 가격 모델에 맞는 평가 기준, 데이터 소유권과 보안 요구사항, 클라우드 전환 및 종료 계획(Exit Strategy)이 주요 검토 대상이다.

AI와 빅데이터 프로젝트에서는 데이터 품질과 거버넌스 요구사항, 알고리즘 성능 평가 방법, 윤리적 AI 사용 가이드라인, 지속적 학습과 모델 개선 방안을 RFP에 포함한다.