RFP : Request For Proposal = 제안요청서
RFP는 비단 IT업계뿐만 아니라 입찰제를 통해 사업을 계약하는 대부분의 곳에서 쓰인다. 공공기관의 경우 사업 예산(추정 가격)이 2000만 원 이상의 건인 경우* 반드시 입찰을 통해 계약을 진행하게 되는데, 이때 RFP(제안요청서)를 통해 과업 요구사항을 정의한다. 지금부터 이 김춘삼이가 RFP에 대해 쉽게 이야기해보겠다.
* 국가계약법 시행령 제30조 2항에서는 추정 가격이 2000만 원을 초과하는 수의계약에 대해서는 전자조달시스템을 이용하여 견적서를 제출(여성기업 또는 장애인기업과 계약을 체결하는 경우에는 5천만 원)
1. 상상을 현실로 만들어주는 계획표
누구나 살면서 한 번쯤은 "이런 제품(또는 행위)이 있었으면 좋겠다"는 상상을 해본 적 있을 것이다. 하지만 대부분의 사람들은 상상에서 그치지, 그 상상을 문서로 구체화해본 경험을 매우 드물 것이다.
그렇다면.. 하늘에서 갑자기 돈다발이 떨어져 누군가 당신이 상상한 그것을 실현해 준다고 가정해보자.
우선 본인이 원하는 것이 무엇인지 구체화해서 나열하고, 그 결과로 얻을 수 있는 내용들(기대효과)과 작업에 필요한 기간도 산정해야 할 것이다. 무엇보다도 적정한 예산계획을 수립해야 할 것이다. 예산이 너무 적다면, 낮은 품질의 결과물이 나올 확률이 높기 때문이다.
이러한 내용을 정리하며 체계화된 문서로 정리한다면 RFP 된다. 즉, RFP는 "수요자"가 특정 과제의 수행에 필요한 내용을 체계적으로 명시한 문서이다.
이렇게 수요기관이 RFP(제안요청서)를 공고하면 공급자(사업자)는 RFP의 내용을 토대로 "제안서"를 작성한다.
"내가 원하는 것을 이렇게 이렇게 만들어 주세요"라고 운을 띄우는 것이 제안요청서(RFP)라면, "네, 내용을 봤는데 이렇게 하는 것은 어떻까요?"라고 제시하는 것이 "제안서"의 역할이다.
2. RFP는 너와 나의 연결고리
만약에 김춘삼이가 "따듯한 햇살이 스며드는 아름다운 집"을 짓는 계획이 있다고 가정하자. 업자는 "따듯한 햇살이 집 곳곳을 감싸주는 아름다운 집을 지어드리죠."라고 답하였고, 이내 계약서를 쓴다.
그렇게 사업기간 1년, 3억 원의 예산이 소요된 결과물이 비닐하우스라면..? 여기에 업자는 예산을 정확하게 소모하였고, 심지어 정말 성실하게 임했다면..? 과연 이것이 잘못된 결과물일까..? 또 누구의 잘못일까..? (정말 꼭지가 돌겠지만..)
분명 비닐하우스도 따듯한 햇살이 매우 잘 스며든다. 하지만 분명 수요자가 원하는 결과물은 아닐 것이다. 마치 서로 같은 것을 만지며, 다른 대상을 이야기하는 장님과 코끼리 이야기(문맹 무상)와 같다. 여기서 문제의 원인은 "추상적인 표현"이다. 추상적 표현은 서로 다른 해석을 만들고, 서로 다른 해석이 결국 서로 다른 목표를 만들었기 때문이다.
RFP는 공급자와 수요자 상호 간에 공통의 목표 의식을 갖게 해주는 일종의 기본(based) 매개체의 역할을 한다.
때문에 반드시 공급자는 수요자의 의중을 정확하게 파악해야만 하며, 수요자 역시 공급자에게 구체적이고 명확한 요구사항*을 정의해야 한다.
*가능하면 계량화가 가능한 내용을 정확한 숫자를 제시하면 좋다.
위와 같은 일이 실제로 일어날 수 없을 것이라 생각하겠지만 빗대어 놓은 대상만 집으로 표현했을 뿐.. 짧은 내 IT 경력에도 이런 황당한 경우를 2-3번은 본 것 같다. 아 물론 실제로 업체가 담당자의 의도를 몰랐던 것은 아니고.. 마진을 더 챙기려 꼼수를 부린..
생각보다 많은 정보화 담당자들이 이러한 내용을 간과해.. 소위 말하는 눈퉁이 맞는 상황이 종종 생긴다. 그렇다 보니 실제 현업 기술자 출신이 담당자가 되거나, 한번 이상당해본 사람들의 경우 RFP를 정말 꼼꼼히 작성하고 철저하게 관리 감독한다. (사실 당연한 건데.... 대부분 그렇지 않은 것이 현실이고.. 나도 그들처럼 루팡이 되고 싶다)
이 같은 문제는 업체(공급사)에서도 종종 나타나는데.. 분명 RFI단계*부터 영업을 했는데.. 이 따위(내용이 없어서 개나 소나 넘 볼) RFP가 나오는 건가 싶은 경우가 많다... 역시 진짜 적은 내부에 있나 보다.
(*RFI 내용은 별도 작성 예정)
3. 전략적 SIMPLE RFP도 존재한다.
물론, 담당자의 의도로 RFP상에 과업 정보 노출을 최소화한 경우도 존재한다. 이 역시도 여러 경우의 수가 있지만 간략하게 다루어 보면 아래와 같다.
| 1) 입찰 참여업체가 담당자를 직접 대면하게 만들어, 경쟁 수준을 상향 평준화하고싶은 경우(일종의 필터링) |
| 2) RFI 단계에서 담당자에게 많은 기술적 제언을 준 업체가 있는 경우(소위 영업이 되었다고 표현) |
| 3) 담당자가 기술에 대해 잘 모르는 상태에서 주변에서 리스크 가능성에 대해 들었을 경우(들어보고 결정함) |
| 4) 업체 영업대표가 멍청한 경우(?????) |
(자세한 내용은 별도의 포스팅으로 다룰 예정)
4. RFP는 천차만별, 그래서 네 할 일도 천차 만별.
RFP의 기본 역할과 목적은 모두 동일하지만, 사업의 규모, 종류와 유형, 그리고 수요기관의 성격에 따라 천차만별이다.
조달청에서 제공하는 정보화사업 표준RFP 패턴만 16종류이며, 내용은 아래와 같다.
| ISP | PMO | 정보시스템 감리 | 패키지 도입 |
| 정보시스템 개발 | 인터넷 지원 개발 | 정보 인프라 구축 |
컴퓨터 네트워크/ 인터넷 보안 서비스 |
| 정보시스템 운영 위탁 | 정보시스템 유지관리 | 소프트웨어 유지 및 지원 | 전산장비 유지보수 |
| 데이터 | 공간정보 DB 구축 | 온라인홍보방송콘텐츠 | 디지털콘텐츠 |
이 외에도 과기부에서 배부하는 "공공 SW사업 제안요청서 작성을 위한 요구사항 상세화 실무 가이드라인"도 존재한다. (가이드라인 다운로드 링크)
RFP는 사실, 수요기관 담당자의 몫이고.. 그냥 제안서 작성자 관점에서는 글쓴이의 의중을 잘 파악하면 된다. 사실.. 그런 표준 템플릿이나 가이드라인 만들어도 소용없는 것 같다. 대충 여기저기 짜집기하는 것인지(눈에 훤하지만) 연차별로 발생하는 사업의 경우에는 작년 RFP에 잘못 작성된 내용(과업과 맞지 않는 내용 등)이 올해, 내년까지 똑같이 나오는 경우도 있다.(그러면서도 눈탱이 맞기는 싫은가보다..^^ 하..)
또한 RFP는 수요기관이 갖는 특수성에 따라 여러 서식들이 추가되고 빠지게되는데.. 단적인 예로 군사업의 경우.. 사업이 시작될 때 빈몸으로 들어가.. 또 다시 빈몸으로 나올 정도로 보안이 엄격하다. 따라서 보안에 관련된 많은 제약사항이 RFP에 담겨있으며, 사업자는 해당 내용을 이행해야만 한다. 즉, 사업자의 할일 또는 수행에 따른 제약사항이 늘어남에 따라 효율성이 달라진다는 이야기다. = 제안서에 담겨져야할 내용이 많아진다.
4. RFP <= 제안서 = 사실상 계약서와 동일한 효력을 갖는다
제안서는 결국 RFP를 토대로 작성되는데, 아무리 부당한 내용(독소 조항)이라도 RFP에 명시된 이상 관련 내용을 제안서에 명시해야만 한다. 기피할 내용이 제안서에 반영하지 않으면 묵시적으로 RFP가 과업 기준이되며, 설령 사업자가 RFP 내용을 수용하지 못할 경우엔 제안 규격에 맞지 않으므로 스펙아웃(Spec out)되는 상황이 발생될 수 있다. (물론, 부당한 내용은 사전규격 단계에서 이의 신청이 가능하다. 입찰경쟁은 굉장히 훌륭한 제도이다.)
이러한 이유로 결국 RFP(제안서에 준하는) = 제안서(사실상 계약서) = 계약서(기술협상 포함)라는 것이 사실상 성립된다. 이 같은 내용은 기술협상 혹은 과업기간 중 협의할 수 있지만, 감사를 생각한다면 쉽지 않을 것이다.
포스팅을 마치며.. 본인이 RFP를 작성해야하는 담당자 입장이든, 제안서를 작성해야하는 입장이든 그 목적과 중요성을 분명하게 인지하고 사업에 임하였으면 한다.
※ 상위 내용은 참고문서나 자문 없이, 김춘삼이의 개인적인 경험을 토대로 작성된 내용으로 지극히 개인적인 의견임을 알려드립니다.
추신. 세상엔 훌륭한 사람도 많습니다. 다만, 그 동안 제가 그렇지 못한 사람들만 만났나봅니다....
댓글