IT 프로젝트 실무에서 마주한 RFI, RFQ, RFP

기업과 정부 조직이 새로운 IT 시스템을 도입하려고 할 때, 그 시작점은 대부분 문서다.

낯설게 느껴질 수 있는 RFI, RFQ, RFP 같은 용어는 단순한 서류를 넘어 프로젝트의 운명을 좌우하는 핵심 단계이기도 하다.

나 역시 IT 담당자로 일하면서 이런 문서들을 작성하고 검토하며 수많은 고민과 작성과 수정하며 많은 것을 배울수 있었다.

오늘은 이 세 가지 개념과 함께, 실제 프로젝트에서의 경험을 풀어보고자 한다.

“이 시스템은 누가, 어떻게 만들 것인가?” – 입찰의 시작점

기업이든 정부든, 새로운 IT 시스템이 필요하다고 판단되면 가장 먼저 움직이는 건 ‘입찰’이다. 정부는 '나라장터'라는 공공 조달 플랫폼을 통해 입찰 공고를 띄우고, 일반 기업은 자사 홈페이지나 협력사 전용 포털을 통해 공고를 진행한다.

내가 있는 회사에서도 마찬가지였다. 얼마 전 기존에 사용하던 ERP 시스템을 전면 교체하기로 결정했었는데, 인사, 재무, 회계, 구매까지 모든 부서를 하나로 통합 관리하는 시스템이니만큼 신중할 수밖에 없었다.

이때 가장 먼저 내가 했던 일은 내부의 요구사항을 정리하고, 그것을 문서화하는 일이었다. 물론 요구사항을 여러 이해관계들을 만나 서로 협의하고 체계를 다시 그리고 하는 그 과정은 고통의 연속임은 틀림없다.ㅡㅡ.

이런 과정에서 가장 처음 활용되는 문서가 바로 RFI이다. RFI(Request For Information) – 말 그대로 정보 요청서다.

“요즘 시장에 어떤 솔루션이 있나요?” “이런 기능은 구현 가능할까요?” 하는, 공급업체들에 대한 탐색 단계라고 보면 된다.

RFI를 보내면, 여러 업체들이 자신들의 기술력과 제품에 대한 정보를 간단히 요약해서 회신해 온다.

이 정보들을 바탕으로 우리는 “어느 정도 수준의 시스템이 가능한지”, “예산은 어느 정도가 현실적인지” 등을 판단할 수 있었다.

사실 이 단계에서 가장 중요한 건, 우리 쪽이 얼마나 구체적이고도 현실적인 요구사항을 정리해 주느냐에 달려 있다. 물론 해당 PM의 역량의 문제일수도 있고, 현업 담당자의 실력 일수도 있다. 현장에는 늘 100% 정해진 완벽한 해답은 없다는 걸 추가로 알려주고 싶다. 모호하거나 이상적인 요구사항만 잔뜩 나열하면, 업체들도 적절한 답변을 주지 못한다.

이건 실제 프로젝트에서 많이 겪는 일인데, 한 번은 담당자 중 한 명이 “우리 회사는 미래 지향적이고 혁신적인 시스템이 필요해요”라고만 적어놓은 문서를 RFI로 제출한 적이 있었다.

결국 모든 업체로부터 “구체적인 내용이 부족하다”는 피드백만 돌아왔던 기억이 있다.

RFQ, 그리고 RFP – 현실로 들어온 제안의 무게감

RFI가 탐색이라면,

다음 단계인 RFQ(Request For Quotation)는 견적 요청서다. 이제 구체적으로 “이런 기능, 이런 조건의 시스템을 이 정도 규모로 만들고 싶은데, 얼마에 해주실 수 있나요?” 하고 묻는 단계다.

여기서 중요한 건, 수량과 스펙이 명확해야 한다는 것이다.

예를 들어 “서버 2대, 백업 장비 1대, 클라우드 계정 30개, 구축 기간 3개월” 등 아주 구체적으로 정리해야만 현실적인 견적이 나온다. 실제로 우리는 ERP 교체 프로젝트에서 RFQ를 통해 약 4개의 업체로부터 견적을 받았다.

그런데 놀랍게도 가격 차이는 최저가와 최고가가 2배 이상 차이가 났다. 기술 스펙은 비슷해 보여도, 유지보수 조건이나 확장성, 클라우드 라이선스 포함 여부 등에 따라 총액이 크게 달라졌다.

이쯤 되면 슬슬 피로가 엄청나게 몰려온다. 마치 쓰나미 처럼...

선택지가 너무 많아지면 선택이 어려워지는 법이다. 그래서 최종 결정 단계에서 등장하는 문서가 바로 RFP(Request For Proposal)이다. 제안 요청서, 즉 “우리 요구사항에 맞춰 구체적인 솔루션과 계획을 제안해 주세요”라는 의미다.

이 단계에서는 단순 견적이 아니라, 프로젝트 일정표, 인력 구성안, 상세 기술 제안서, 유지보수 계획서 등 ‘실행 가능한 계획 전체’를 제출받는다. 나는 이 과정에서 업체들의 PT 발표를 수차례 들어야 했고, 때로는 기술력보다는 설득력 있는 설명과 태도가 더 인상 깊을 때도 많았다.

업계에서는 “RFP는 회사의 철학까지 담겨야 한다”고 말한다.

단순히 “이거 만들어 주세요”가 아니라, “왜 이걸 해야 하고, 우리는 어떤 목적을 가지고 있는가”까지 드러나야 한다는 뜻이다. 나 역시 그 점을 절감했다.

프로젝트 관리의 기본, PMP를 고민하다

한참 프로젝트를 진행하다 보면 문득 그런 생각이 든다. “왜 어떤 프로젝트는 잘 되고, 어떤 프로젝트는 엉망이 될까?”

여기에 대한 답을 찾기 위해 나는 최근 PMP(Project Management Professional) 자격증을 준비하기 시작했다. 이 자격은 미국 PMI(Project Management Institute)에서 주관하는 국제 인증으로, 전 세계적으로 인정받는 프로젝트 관리 전문 자격이다.

PMP는 단순히 계획을 짜는 법을 가르치지 않는다.

범위, 일정, 비용, 품질, 위험, 인적 자원, 조달, 커뮤니케이션, 이해관계자 관리 등 총 10가지 영역에서 ‘프로젝트를 어떻게 리드할 것인가’를 다룬다.

이걸 공부하면서 가장 놀라웠던 건, 우리가 일상적으로 겪는 수많은 ‘혼란’들이 사실은 체계가 없어서가 아니라, ‘모두 다르게 이해하고 있어서’ 생긴다는 점이었다.

예를 들어 일정 지연이 발생하면 보통 “왜 늦었냐”는 질책이 오간다. 하지만 PMP에선 먼저 리스크 식별을 했는지, 우선순위 관리가 되었는지, 커뮤니케이션 경로는 명확했는지를 점검한다. 그 차이가 결과를 바꾼다.

문서가 아닌, 목적과 흐름을 보는 눈이 중요하다

IT 프로젝트는 결국 사람이 한다. 문서는 중요하지만, 그 문서가 만들어진 맥락과 의도를 이해하는 게 더 중요하다. RFI, RFQ, RFP라는 용어는 그 자체보다도 “우리는 왜 이 프로젝트를 하려는가”를 먼저 고민하게 만든다.

그리고 그 고민을 제대로 구조화하는 것이, 바로 프로젝트 관리(PMP)의 본질이 아닐까 싶다.

지금 어떤 프로젝트에 참여하고 있든, 혹은 앞으로 어떤 일을 하게 되든, RFI를 쓰기 전에 ‘왜’라는 질문을, RFP를 받기 전에 ‘무엇을 기대하는가’를 먼저 생각할 수 있다면, 이미 반은 성공한 것이라고 생각한다.

IT를 통해 밥을 먹고 있다면 PMP를 꼭 취득하길 추천 한다.