공공 소프트웨어사업 제안요청서, 요구사항과 평가 기준을 설계하는 법

발주 문서가 사업의 기준선이 되는 이유

제안요청서(RFP: Request For Proposal)는 공공기관이 소프트웨어사업을 발주할 때 입찰참가자에게 요구사항을 전달하는 공식 문서다. 「소프트웨어 진흥법」과 「전자정부법」에 따라 작성·배포되며 법적 구속력을 가진다.

이 문서는 요구사항을 알리는 데서 끝나지 않는다. 공정한 경쟁 환경을 만들고, 계약 이행의 기준을 정하며, 사업 추진의 로드맵 역할도 맡는다. RFP의 품질은 최종 소프트웨어 품질과 직접 연결된다.

사업 범위부터 공고 이후까지 문서에 담을 내용

사업개요에는 사업명, 추진 목적, 시간적·공간적·내용적 범위, 예산 규모와 집행 계획, 주요 마일스톤을 명시한다. 사업을 왜 추진하는지와 어디까지 수행하는지를 같은 맥락에서 읽을 수 있어야 한다.

⤢✕

현행 시스템 설명에는 하드웨어·소프트웨어·네트워크 구성, 업무 처리 흐름, 현재 한계와 개선 과제, 유사 시스템의 성공·실패 사례를 포함한다. 제안사가 기존 환경과 문제를 이해할 수 있어야 현실적인 방안을 제시할 수 있다.

사업 추진방안에서는 발주기관과 사업자 사이의 역할 분담, 사업 전략, 적용할 소프트웨어 개발방법론인 폭포수나 애자일, 품질보증 활동 계획을 다룬다.

요구사항은 성격별로 분리하는 편이 낫다.

• 기능적 요구사항: 시스템이 제공해야 하는 기능
• 비기능적 요구사항: 성능, 보안, 신뢰성 등 품질 조건
• 인터페이스 요구사항: 외부 시스템 연계 방식
• 데이터 요구사항: 데이터 구조와 마이그레이션 계획
• 테스트 요구사항: 검증 방법과 판정 기준

제안서 작성 지침에는 목차와 필수 항목, 페이지 수·서체·편집 규격 같은 양식, 인쇄본과 전자문서 등 제출 매체와 수량을 적는다. 평가 안내에는 기술평가와 가격평가의 비율 및 방식, 배점표와 세부 기준, 입찰참가 자격을 포함한다. 보안 관리, 사용자·운영자 교육, 하자보수와 유지관리의 범위 및 기간도 별도 조건으로 남긴다.

요구사항을 해석 가능한 문장으로 만드는 방법

요구사항은 제안사마다 다르게 해석될 여지를 줄여야 한다. 사용자 스토리는 “~로서, ~하기 위해, ~를 원한다” 형식으로 기록할 수 있고, 유스케이스는 주요 시나리오와 예외상황까지 기술한다. 비기능 요구사항에는 “99.9% 이상의 가용성”처럼 측정 가능한 기준을 둔다. 중요도는 MoSCoW(Must/Should/Could/Won't) 방식으로 구분할 수 있다.

평가 기준도 요구사항과 맞물려야 한다. 정성적 판단을 줄이고 정량적 지표를 중심으로 평가항목을 설계하며, 핵심 요구사항에는 적절한 가중치를 준다. 사업 특성에 따른 중점 평가 영역과 필수 요건 미충족 시 평가에서 제외하는 탈락기준(Knock-out Criteria)도 명시한다.

⤢✕

산출물은 소스코드, 설계서, 매뉴얼처럼 최종 납품물을 상세 목록으로 정리한다. 단계별 검토 문서와 승인 절차를 중간 산출물로 정하고, 문서 완성도 판단 기준 및 산출물의 소유권·활용 범위까지 명확히 한다.

예산, 일정, 기존 인프라와의 통합성, 운영 인력의 기술 수준과 교육 필요성은 요구 범위를 결정하는 제약조건이다. 이 조건을 빠뜨리면 제안 내용과 실제 수행 여건이 어긋날 수 있다.

추적성과 준수 조건을 문서 구조에 연결하기

동일한 개념에는 같은 용어를 사용하고 용어사전을 활용한다. “신속하게”, “적절하게”처럼 주관적으로 해석될 표현은 구체적 수치로 바꾼다. 기술 내용은 최신 기술 동향과 표준을 정확히 반영해야 하며, 여러 이해관계자가 각자 다른 의미로 읽지 않는지 검토한다.

각 요구사항에는 고유 ID를 부여하고, 중요도는 상·중·하로 표기한다. 발생 근거와 담당자를 기록하며, 선후관계와 종속성도 표시한다.

⤢✕

관련 법규와 표준도 요구사항에 반영한다. 개인정보보호법과 정보통신망법 등 정보보호 관련 규정, 장애인차별금지법에 따른 접근성 지침, 전자정부 표준프레임워크 적용 여부, 발주기관의 정보화 전략과 아키텍처 지침이 그 대상이다.

사업 중 발생할 수 있는 위험은 미리 식별하고 대응 방안을 제안 내용으로 요청한다. 미래 요구사항 변화에 대응할 유연성, 사업 완료를 판단할 인수 기준과 검수 방법 역시 초기에 정해 둔다.

현황 조사와 검토를 거쳐 공고로 마무리하는 흐름

작성 준비에서는 요구사항 수집 대상과 검토자를 정하고, 기존 시스템과 업무 프로세스를 조사한다. 유사 사례와 모범 사례를 참고하며 예산·일정·인력 같은 현실적 제약도 확인한다.

요구사항은 핵심 이해관계자 인터뷰와 워크숍, 다수 사용자 대상 설문조사, 실제 업무 현장 관찰, 기존 산출물과 운영 이슈 분석을 통해 수집할 수 있다.

초안에는 수집한 요구사항을 반영하고 IT·업무 전문가에게 내용 적정성을 검토받는다. 조달 관련 법규 준수 여부는 법률 검토로 확인하며, 이해관계자는 요구사항 반영의 정확성을 최종적으로 점검한다.

최종 승인 뒤에는 조달청 나라장터 등록 자료를 준비한다. 예상 질의에 답할 자료를 구성하고, 제안서 평가위원회와 평가표도 공고 전에 마련한다.

공고 전 확인할 문서 품질

내용 면에서는 필수 요구사항이 빠짐없이 들어갔는지, 요구사항끼리 상충하지 않는지, 문장이 명확한지, 달성 여부를 객관적으로 판정할 수 있는지를 확인한다.

형식 면에서는 목차와 본문의 구조, 문서 포맷과 스타일의 일관성, 전문 용어와 약어의 통일성을 살핀다. 맞춤법·문법 오류와 첨부 문서, 도표, 참고 문헌의 표기도 점검 대상이다.

기술 면에서는 요구사항의 구현 가능성, 최신 기술 동향과 표준 반영 여부, 미래 변화에 대응할 확장성, 정보보안 요구사항, 구체적인 성능 명세를 검토한다.

사업 면에서는 예산 범위와 비용 산정 기준, 제시된 일정의 현실성, 발주자와 수주자의 역할과 책임, 납품 산출물과 검수 기준, 계약 조건과 법적 요구사항이 분명한지 확인한다.