RFP는 Request for Proposal의 약자로, 한국어로는 제안요청서라고 하며, 발주자가 여러 공급사에 "우리는 이런 문제를 풀고 싶으니 어떻게 풀지 제안해 달라"고 요청하면서 보내는 문서예요. 즉 RFP는 답이 적힌 문서가 아니라 질문이 적힌 문서예요. 무엇을 왜 만들고 싶은지는 발주자가 확정해서 적고, 그것을 어떤 방법과 기술로 만들지는 비워 둔 채 개발사에게 넘기는 구조죠.
이름에 걸린 오해부터 풀고 가는 게 좋아요. "요청서"라는 번역 때문에 개발사가 발주자에게 보내는 문서로 착각하는 경우가 많은데, RFP를 쓰는 쪽은 돈을 내는 발주자예요. 요청하는 대상이 견적이나 일정이 아니라 "제안(Proposal)"이라는 점도 핵심이에요. 사양이 다 정해져 있다면 제안할 것이 없고, 그때 필요한 문서는 RFP가 아니에요.
실무에서 RFP는 기획이 끝난 직후, 개발사를 고르기 직전에 등장해요. 위치를 잡는 기준은 두 가지예요. 요구사항이 아직 머릿속에만 있으면 RFP를 쓸 수 없고, 반대로 화면 설계까지 전부 확정했다면 RFP보다 단순 견적 요청이 빨라요. 무엇을 만들지는 정했고 어떻게 만들지는 아직 안 정한 구간, 그 사이가 RFP의 자리예요.
그래서 RFP를 쓰기 전에 끝나 있어야 하는 일이 따로 있어요. 핵심 사용자, 화면 흐름, 필수 기능 목록이 문장으로 정리돼 있어야 RFP의 빈칸이 채워져요. 착수 전에 무엇을 어느 수준까지 만들어 가야 하는지는 기획 단계에서 개발사에 들고 갈 산출물 쪽에 정리해 두었어요. 프로젝트 전체 흐름에서 RFP가 어느 칸에 놓이는지 먼저 보고 싶다면 기획부터 런칭까지 외주 프로젝트 전체 흐름을 훑어도 좋아요.
다른 문서이고, 방향이 반대예요. RFP(제안요청서)는 발주자가 개발사에게 보내고, 제안서(Proposal)는 개발사가 발주자에게 보내요. 한국어 이름이 "제안요청서"와 "제안서"로 '요청' 두 글자 차이라서 미팅에서 실제로 자주 뒤섞이는 지점이에요.
구분이 필요한 순간은 대개 메일에서 와요. "제안서 보내주세요"는 개발사에게 답을 달라는 요구이고, "제안요청서 주세요"는 발주자에게 조건을 달라는 요구예요. 회신이 며칠째 없다면 서로 상대가 보낼 차례라고 생각하고 있는 것은 아닌지부터 확인하세요 — 마지막으로 오간 메일에 적힌 문서 이름이 둘 중 무엇이었는지 보면 발신 차례가 바로 갈려요. 첨부파일 이름을 "RFP_회사명_날짜"처럼 문서 종류로 시작하게 정해 두면 이 혼선을 줄일 수 있어요.
세 문서를 가르는 기준은 정의가 아니라 우리 쪽에서 아직 정해지지 않은 것이 무엇인가예요. 무엇이 가능한지조차 모르면 RFI, 무엇이 필요한지는 알지만 방법을 모르면 RFP, 사양이 확정돼 가격만 남았으면 RFQ예요. 이 기준으로 보면 세 문서는 경쟁 관계가 아니라 미확정 항목을 하나씩 지워 나가는 순서가 돼요.
| 문서 | 무엇을 묻나요 | 우리 쪽에 확정돼 있어야 하는 것 | 받는 산출물 |
|---|---|---|---|
| RFI 정보요청서 (Request for Information) | 이런 일이 가능한가요, 보통 어떻게들 하나요 | 풀고 싶은 문제 하나. 그 외에는 아무것도 없어도 돼요 | 업체 소개서, 사례, 접근 방식 개요. 가격이 와도 구속력 없는 개략치라서 비교 근거로는 쓰지 않는 게 안전해요 |
| RFP 제안요청서 (Request for Proposal) | 이 문제를 어떤 방법으로, 얼마에, 언제까지 풀어 줄 건가요 | 목적, 필수 기능 목록, 일정 범위, 예산 범위, 평가 기준 | 제안서. 방법론과 구성, 일정표, 견적이 함께 와요 |
| RFQ 견적요청서 (Request for Quotation) | 이 사양 그대로면 얼마인가요 | 사양서 전체. 화면 수, 연동 대상, 인수 조건까지 고정 | 가격표. 같은 사양이라 금액 비교가 바로 돼요 |
순서는 RFI로 시장을 훑고, RFP로 방법을 받고, RFQ로 금액을 확정하는 흐름이에요. 다만 세 단계를 전부 밟아야 하는 것은 아니고, 확정된 것이 많을수록 앞 단계를 건너뛰어요. 이미 같은 기능을 여러 번 발주해 봤고 사양서가 그대로 재사용된다면 RFQ 하나로 끝나고, 후보 개발사조차 모르는 첫 외주라면 RFI부터 시작하는 편이 안전해요. 회신받은 금액을 실제로 비교하는 단계에서는 회신받은 견적서를 항목별로 뜯어보는 법이 따로 필요해요.
세 문서를 섞어 쓰면 회신 품질이 무너져요. 사양이 절반만 정해진 상태로 RFQ를 보내면 개발사는 빠진 부분을 각자 상상해서 값을 매기고, 결과적으로 비교 불가능한 금액표만 모이게 돼요. 반대로 이미 모든 게 확정된 건에 RFP를 보내면 개발사는 제안할 여지가 없어 회사 소개서만 두껍게 보내와요.
RFP를 처음 만나는 경로는 크게 두 갈래예요. 하나는 공공기관 입찰공고에 붙어 나오는 제안요청서를 받는 경우이고, 다른 하나는 민간 기업이 개발사 서너 곳에 메일로 돌리는 경우예요. 같은 이름을 쓰지만 절차의 강제력이 달라서, 지금 보고 있는 RFP가 어느 쪽인지부터 확인해야 다음 행동이 정해져요.
아래 비교는 공공기관이 제안서를 받아 평가하는 방식(협상에 의한 계약)을 기준으로 한 것이고, 적격심사나 최저가 방식에는 그대로 적용되지 않아요. 공공 쪽 칸은 제도 전체를 요약한 것이 아니라 해당 공고문에서 직접 확인할 수 있는 것만 적었어요.
| 구분 | 공공 조달 RFP | 민간 발주 RFP |
|---|---|---|
| 배포 방식 | 일반경쟁으로 공고되면 자격 요건을 갖춘 곳은 누구나 제안요청서를 받을 수 있어요. 다만 제한경쟁·지명경쟁이나 수의계약처럼 참여 대상이 미리 좁혀지는 방식도 있어서, 공고문의 입찰 방법 항목을 먼저 확인해야 해요 | 발주자가 고른 후보 업체에만 개별 전달해요 |
| 참가 자격 | 참가 자격이 공고문에 별도 항목으로 적혀 있어요. 업종 등록이나 실적·재무 요건이 붙는지는 공고마다 달라서 그 항목을 먼저 읽어야 해요 | 정해진 형식이 없어요. 발주자가 후보를 고르는 것으로 대신해요 |
| 평가 방식 | 제안서를 평가하는 공고라면 평가항목과 배점이 제안요청서에 함께 실려요 | 형식이 자유롭고, 배점 공개 여부도 발주자가 정해요 |
| 질의응답 | 질의 접수 기간과 답변 공개 방법이 공고문에 함께 적혀 있는 경우가 많아요. 실제 기간은 공고문에서 확인하세요 | 메일이나 미팅으로 수시로 진행돼요 |
| 수정 여지 | 공고 뒤 요건을 바꾸려면 공고를 다시 손봐야 해서, 민간 발주만큼 유연하지 않아요 | 제안을 받아 보고 요구사항을 조정하는 것이 가능해요 |
이 차이가 만드는 실무 결론은 단순해요. 공공 RFP에서는 문서에 적힌 요건을 그대로 충족하는 것이 먼저이고, 요건 밖의 좋은 아이디어는 점수를 받을 칸이 없어요. 민간 RFP라면 요건 자체를 다시 그리는 제안도 채택될 수 있으니, 개발사가 우리 요건을 바꾸자고 말했을 때 그것을 결격으로 볼지 강점으로 볼지 발송 전에 정해 두세요. 이 글의 나머지는 민간 IT 외주 발주자를 기준으로 쓰였고, 공공 입찰이라면 각 기관의 공고문과 규격서가 이 글보다 우선이에요.
가장 먼저 나타나는 증상은 견적 편차예요. 같은 프로젝트를 설명했는데 업체별 금액이 크게 벌어진다면, 단가 차이보다 먼저 의심할 것은 각 업체가 서로 다른 범위를 가정했을 가능성이에요. 기준 문서가 없으면 어느 금액이 맞는지 판정할 근거 자체가 없어요. 회신을 실제로 대조하는 순서는 이 글 뒤쪽 제안 비교 절에서 다루고, 애초에 어느 기능을 범위에 넣고 뺄지 정하는 절차는 MVP 범위를 확정하고 경계 기능을 판정하는 절차에 따로 있어요. 이 글이 맡는 몫은 정해진 범위를 RFP에 어떤 문장으로 적는가까지예요.
두 번째 증상은 착수한 뒤에 나타나요. 범위를 문서로 고정하지 않으면 "당연히 포함이라고 생각했다"와 "그건 추가 건입니다"가 부딪히고, 그 협상 비용이 개발 일정을 잠식해요. 그래서 RFP에는 착수 후 변경을 어떤 절차로 처리할지 함께 적어 달라고 요구해 두는 게 좋아요. 그 절차가 실제로 어떻게 굴러가는지는 변경 요청서(CR)가 실제로 굴러가는 방식에 정리돼 있어요.
세 번째는 인수 시점에 나타나요. 기대를 문서로 적어 두지 않았으니 결과물이 기대와 다르다는 것을 증명할 방법이 없고, 검수 기준이 결국 발주자의 인상으로 정해져요. 특히 AI 기능, 외부 시스템 연동, 보안 요구사항처럼 눈으로 완성 여부를 판정하기 어려운 항목일수록 이 문제가 크게 벌어져요.
RFP 한 장이 이 세 가지를 한꺼번에 막아요. 모든 업체가 같은 문서를 읽고 같은 범위에 값을 매기니 금액이 비교 가능해지고, 그 문서가 착수 후에는 범위 다툼의 기준선이 되고, 인수 시점에는 검수 기준이 돼요. 그래서 RFP는 개발사에게 잘 보이려고 쓰는 문서가 아니라, 발주자가 나중에 판단할 근거를 미리 남겨 두는 문서에 가까워요.
개발사가 견적을 내려면 최소한 개요, 기능, 기술, 보안, 일정, 예산, 평가 기준 일곱 가지가 채워져 있어야 해요. 포텐랩이 받아 온 RFP를 기준으로 정리한 목록이에요. 이 글은 민간 IT 외주 RFP 기준이고, 공공 입찰은 별도 규정을 따르므로 여기서 다루지 않아요. 항목을 빠뜨렸을 때 벌어지는 일은 거의 정해져 있어요. 빈칸은 개발사가 각자의 경험으로 채워 넣고, 그 가정이 서로 다르기 때문에 회신 금액을 같은 기준으로 비교할 수 없게 돼요.
아래 표는 항목마다 무엇을 잃는지와, 실제 문서에 어떤 형태의 문장을 쓰는지를 같이 놓은 거예요. 왼쪽 열을 그대로 목차로 삼고 오른쪽 열의 문장 형태를 흉내 내면 초안 한 장은 만들어져요. 각 항목의 자세한 판단 기준은 이어지는 절에서 하나씩 풀어 놓았어요.
| 항목 | 안 적으면 생기는 일 | 적을 때 쓰는 표현 형태 |
|---|---|---|
| 프로젝트 개요와 배경 | 개발사가 기능 목록만 보고 견적을 낸다. 더 싼 대안을 제안할 근거가 없다 | 지금 무엇이 불편한지 + 이 프로젝트가 끝나면 무엇이 달라지는지, 각각 한 문장 |
| 기능 요구사항 | 필수와 선택이 뒤섞여 우선순위가 사라진다. 업체별 금액을 같은 칸끼리 비교할 수 없다 | "누가 무엇을 할 수 있다" 형태의 사용자 문장 + 각 줄 끝에 필수 또는 선택 표기 |
| 기술 요구사항 | 연동 대상이 착수 후에 드러나 일정이 밀린다 | 플랫폼과 연동 대상은 확정 사실로, 기술 스택은 "제안 요청"으로 열어 두기 |
| 보안과 데이터 | 민감 데이터가 뒤늦게 드러나 구조를 다시 짠다 | 수집하는 항목과 수집하지 않는 항목을 각각 나열, 암호화 대상 명시 |
| 일정과 마일스톤 | 중간 확인 지점이 없어 마지막에야 어긋난 걸 안다 | 마일스톤마다 산출물 하나 + 승인 방법 한 문장 |
| 예산 범위 | 개발사가 제안 규모를 맞출 기준이 없다 | 상한과 하한 두 숫자, 그리고 그 범위에 유지보수가 포함되는지 여부 |
| 평가 기준과 절차 | 비교표를 만들 축이 없어 결국 가격으로만 고른다 | 평가 항목 나열 + 어느 항목을 더 크게 보는지 방향, 제출 기한과 형식 |
개요에는 서비스 소개를 옮겨 적기 쉬운데, 개발사가 읽고 싶은 건 소개가 아니라 지금 무엇이 막혀 있는지예요. "상담 신청을 메신저로 받아서 담당자가 매일 수기로 시트에 옮긴다"처럼 현재 동작을 그대로 적으면 개발사가 더 싼 대안을 제안할 수 있어요. 여기에 타깃 사용자, 예상 사용자 규모, 참고할 만한 경쟁 서비스를 덧붙이면 개요는 끝이에요.
여기 적을 내용이 아직 머릿속에만 있다면 RFP를 쓰기에 이른 단계예요. 핵심 사용자와 화면 흐름, 기술 요구사항 목록을 먼저 정리하는 순서는 개발 전 기획에서 정해 두어야 하는 것에 따로 두었어요. 이 글은 그 결과물을 RFP 문장으로 옮기는 자리예요. 화면 흐름도나 와이어프레임이 있으면 첨부 목록에 넣고, 없으면 없다고 적으세요. 없다고 적는 게 중요한 이유는 개발사가 기획 공수를 견적에 포함할지 판단해야 하기 때문이에요. RFP에 첨부할 기획 산출물을 어디까지 만들어 가야 하는지는 따로 정리해 두었으니, 첨부물 목록만 여기에 적고 만드는 방법은 그쪽에서 확인하세요.
기능 요구사항은 RFP에서 분량이 가장 길어지는 자리이자, 표현이 모호해지기 쉬운 자리예요. "회원 관리 기능"이라고 쓰면 가입만 뜻할 수도 있고 등급과 포인트까지 뜻할 수도 있어요. 대신 "가입한 회원은 이메일로 비밀번호를 재설정할 수 있다"처럼 주어와 행동이 들어간 한 줄로 쪼개세요. 한 줄이 곧 견적의 한 칸이 되기 때문에, 줄을 잘게 쪼개 두면 업체별 금액을 같은 칸끼리 비교할 수 있어요.
각 줄 끝에는 필수와 선택을 표기하고, 관리자 화면 요구사항을 반드시 별도 묶음으로 두세요. 관리자 화면은 사용자 화면 뒤에 가려져 있어서 기능 목록에서 빠지기 쉽고, 착수 후에 추가되면 그대로 증액 사유가 돼요. 무엇을 필수로 넣고 무엇을 선택으로 미룰지 판정하는 일은 이 문서의 일이 아니에요. 필수 기능과 선택 기능을 가르는 판정 기준은 따로 정리해 두었어요. RFP에서는 두 묶음으로 나눠 적는 것까지만 하면 충분해요.
기술 요구사항은 확정 사실과 열어 두는 항목을 갈라 적는 게 요령이에요. 이미 정해진 것은 플랫폼과 연동 대상이에요. 웹인지 앱인지, 앱이면 두 운영체제 모두인지, 사내 ERP나 결제 대행사와 붙어야 하는지는 발주자만 아는 사실이라 반드시 적어야 해요. 반대로 프레임워크와 서버 구성은 "제안 요청"으로 남겨 두는 편이 회신 품질이 좋아요.
성능 요구사항은 숫자를 모르면 조건으로 적으세요. 동시 접속자 수를 모르겠다면 "행사 당일 한 시간에 신청이 몰린다" 같은 상황 설명이 오히려 정확해요. AI 기능을 넣을 계획이면 챗봇인지 추천인지 문서 요약인지를 구분해 적고, 결과가 매번 달라지는 기능이라 검수 기준을 함께 논의하고 싶다는 문장을 붙이세요. 이 한 줄은 인수 조건을 제안서에 함께 적어 달라고 요청하는 자리예요.
보안 항목은 수집하는 데이터와 수집하지 않는 데이터를 각각 적는 게 핵심이에요. 결제 정보나 건강 정보, 신분증 사본처럼 민감한 데이터가 하나라도 있으면 구조 설계가 달라지기 때문에, 뒤늦게 밝히면 이미 만든 부분을 다시 만들어야 해요. 개인정보 처리 근거, 저장 시와 전송 시 암호화 요구, 접근 권한 등급 정도면 RFP 단계에서는 충분해요. 점검을 어느 수준으로 요구할지, 재점검 주기를 어떻게 잡을지는 보안 점검과 취약점 대응을 어느 수준으로 요구할지 정리한 글에서 이어서 보세요.
일정에는 희망 시작일과 최종 기한만 적지 말고 중간 확인 지점을 함께 넣으세요. 확인 지점이 없으면 끝나는 날에야 어긋난 걸 알게 되고, 그때는 고칠 시간이 없어요. RFP에서는 "각 마일스톤의 산출물과 승인 기준을 제안서에 함께 제시해 주세요"라는 요청 한 줄이면 충분하고, 그 기준을 어떤 문장으로 적어 계약 조항으로 굳히는지는 마일스톤별 승인 기준을 계약 조항으로 굳히는 법에 따로 두었어요.
예산은 밝히는 쪽이 유리해요. 예산을 숨기면 개발사는 회신 금액을 맞출 기준이 없어 안전한 상한선을 부르게 돼요. 정확한 숫자가 아니어도 상한과 하한 두 숫자를 적고, 그 범위에 유지보수가 포함되는지, 단계별 분할 지급이 가능한지, 착수 후 추가 요청이 나오면 어떤 절차로 비용을 처리할지를 함께 적으세요. 마지막 항목이 착수 후 변경 요청이 들어왔을 때 굴러가는 CR 절차인데, RFP에는 "변경 관리 절차를 제안서에 포함해 주세요"라고 요청하는 것으로 자리를 잡아 두면 돼요.
RFP는 견적을 받기 위한 문서이고, 받은 견적서를 뜯어보는 일은 그다음 단계예요. 회신이 들어오면 금액 총액이 아니라 항목 구성을 먼저 보게 되는데, 회신받은 견적서를 항목별로 뜯어보는 법은 따로 정리해 두었어요. RFP 단계에서 할 일은 그 비교가 가능하도록 회신 형식을 지정해 두는 것까지예요.
공개하는 편이 좋아요. 평가 기준을 숨기면 개발사는 무엇을 강조해야 할지 몰라 회사 소개서를 두껍게 붙이고, 발주자는 서로 다른 형식의 문서를 놓고 비교표를 만들지 못해요. 평가 항목은 기술력, 유사 프로젝트 경험, 금액, 일정 현실성, 커뮤니케이션 방식 다섯 축으로 잡으면 비교표가 만들어져요. 정확한 배점을 공개하기 부담스럽다면 어느 항목을 더 크게 보는지 방향만 적어도 돼요.
절차도 함께 적으세요. 제안서 제출 기한과 형식, 질문을 받는 창구와 마감일, 발표나 미팅 진행 여부, 최종 통보 시기 네 가지면 돼요. 질의응답 기간은 자주 빠지는 항목인데, 질문할 곳이 없으면 개발사는 모르는 부분을 보수적으로 가정한 채 금액을 적어 내고 그 가정이 착수 후에 드러나요.
계약 조건은 RFP에 전부 옮겨 적을 필요가 없어요. 협상이 필요한 조건은 "계약 단계에서 협의한다"고 한 줄만 두고, 미리 못 박고 싶은 것이 있다면 그 한두 개만 명시하세요. 어떤 조항이 나중에 문제가 되는지는 계약서 단계에서 자주 문제가 되는 조항들을 정리한 글에서 확인하는 게 빨라요.
실수는 대부분 문서를 잘못 쓴 게 아니라 판단을 문서 밖에 남겨 둔 데서 나와요. 아래 표는 각 실수를 대신할 문장과, 그 문장을 RFP의 어느 자리에 넣는지를 함께 놓은 거예요. 그대로 복사해 해당 섹션에 붙여도 문서가 성립해요.
| 실수 유형 | 대신 RFP에 쓰는 문장 | 문장을 넣는 자리 |
|---|---|---|
| 전부 필수로 표기 | "선택으로 표기된 기능은 2차 범위로 분리해 별도 금액을 적어 주세요" | 기능 요구사항 목록 끝 |
| 기술 스택을 버전까지 지정 | "기술 선택은 제안에 맡기며, 선택 이유를 한 문단으로 적어 주세요" | 기술 요구사항 첫 줄 |
| 유지보수 항목 없음 | "런칭 후 운영 조건과 월 비용을 개발 금액과 분리해 적어 주세요" | 예산 범위 아래 |
| 회신 기한만 있고 질의 창구 없음 | "질의는 담당자 메일로 받고, 답변은 지원한 모든 곳에 동일하게 공유합니다" | 평가 기준과 절차 |
모든 기능에 필수 표기를 붙이면 우선순위가 없는 것과 같아요. 개발사는 우선순위가 없는 문서를 받으면 전부 1차 범위로 잡고 금액을 내기 때문에, 발주자가 의도한 것보다 큰 프로젝트가 만들어져요. 무엇을 필수로 남기고 무엇을 선택으로 미룰지 가르는 질문은 MVP 범위 확정 절차에 있어요. RFP에서는 이미 갈라 놓은 두 묶음을 표기로 옮기는 것까지가 일이고, 선택 기능을 별도 금액으로 받아 두면 나중에 붙일지 말지를 숫자를 보고 결정할 수 있어요.
특정 프레임워크와 버전을 못 박으면 더 나은 대안을 제안할 여지가 사라져요. 사내에 유지보수 인력이 있어서 스택을 맞춰야 하는 경우처럼 이유가 분명하다면 그 이유를 함께 적으세요. 이유 없는 지정은 개발사가 익숙하지 않은 도구로 작업하게 만들어 일정과 품질을 동시에 흔들어요. 비즈니스 요구를 정확히 적고 기술 선택은 제안으로 받는 편이 결과가 좋아요.
개발이 끝나면 서버 관리, 버그 수정, 운영체제 업데이트 대응, 보안 패치가 남아요. 이 부분을 RFP에서 빼면 개발 금액만으로 업체를 비교하게 되고, 런칭 직후에 운영 조건을 처음부터 협상하게 돼요. RFP 단계에서는 "운영 조건과 월 비용을 함께 제시해 주세요"라는 요청 한 줄이면 충분해요. 운영 인수인계와 SLO를 어떤 기준으로 요청하는지는 별도 글에서 기준을 잡아 두었어요.
밝히는 쪽이 유리해요. 예산을 숨기면 개발사는 회신 금액을 맞출 기준이 없어 안전한 상한선을 부르게 돼요. 정확한 숫자가 아니어도 상한과 하한 두 숫자를 적고, 그 범위에 유지보수가 포함되는지를 함께 적으면 돼요.
플랫폼과 연동 대상은 발주자만 아는 확정 사실이라 반드시 적고, 프레임워크와 서버 구성은 제안 요청으로 열어 두세요. 사내 유지보수 인력이 있어 스택을 맞춰야 하는 경우처럼 이유가 분명하면 그 이유를 함께 적으면 돼요. 이유 없이 버전까지 못 박으면 더 나은 대안이 제안되지 않아요.
공개하는 편이 회신 품질에 유리해요. 기준을 숨기면 개발사는 무엇을 강조할지 몰라 회사 소개서를 두껍게 붙이고, 발주자는 형식이 다른 문서를 놓고 비교표를 만들지 못해요. 정확한 배점이 부담스럽다면 어느 항목을 더 크게 보는지 방향만 적어도 돼요.
"누가 무엇을 할 수 있다" 한 줄이 기준이에요. "회원 관리 기능"처럼 묶어 쓰면 가입만 뜻하는지 등급과 포인트까지 뜻하는지 갈려요. 한 줄이 곧 견적의 한 칸이 되기 때문에, 잘게 쪼개 두면 업체별 금액을 같은 칸끼리 비교할 수 있어요.
전부 옮겨 적을 필요는 없어요. 협상이 필요한 조건은 "계약 단계에서 협의한다"고 한 줄만 두고, 미리 못 박고 싶은 것이 있다면 그 한두 개만 명시하세요. RFP는 계약 전 단계의 문서라, 조항을 따지는 일은 계약서를 받은 뒤에 해도 늦지 않아요.
"런칭 후 운영 조건과 월 비용을 개발 금액과 분리해 적어 주세요"라는 요청 한 줄을 예산 범위 아래에 넣으면 돼요. 이 줄이 없으면 개발 금액만으로 업체를 비교하게 되고, 런칭 직후에 운영 조건을 처음부터 협상하게 돼요.
포텐랩이 발주자에게 권하는 기준은 3곳에서 5곳이에요. 2곳 이하면 비교할 기준선 자체가 안 생겨서 받은 견적이 비싼 건지 싼 건지 판단할 근거가 없고, 후보가 늘어날수록 회신 한 부를 우리 RFP와 한 줄씩 대조하는 시간이 그대로 늘어나요. 3~5곳은 기준선을 만들 최소 수와 발주자가 실제로 끝까지 읽을 수 있는 상한이 겹치는 구간이에요. 제안서 한 부를 제대로 쓰려면 개발사도 우리 RFP를 처음부터 다시 읽어야 하니, 후보 수를 RFP에 밝힐 생각이라면 이 구간 안일 때만 밝히는 게 유리해요.
후보를 고를 때는 회사 규모보다 네 가지를 봐요. 우리와 같은 도메인의 결과물이 실제로 운영되고 있는지, 우리 프로젝트가 그 팀에게 너무 크거나 너무 작지 않은지, 런칭 이후 유지보수를 맡는 조직이 사내에 있는지, 그리고 계약 주체가 실제 개발 팀인지 중개인지예요. 프리랜서 중개 플랫폼과 개발사를 한 표에 섞어 비교하면 견적 구조가 달라서 대조가 성립하지 않아요. 성격이 다른 후보를 넣고 싶다면 아예 그룹을 나눠서 따로 비교하는 편이 나아요.
RFP를 뿌렸는데 회신이 한두 곳뿐이라면 후보 명단이 아니라 문서를 의심하는 게 맞아요. 제출 기한이 배포일로부터 1주일 미만이거나, 예산 범위가 통째로 비어 있거나, 기능이 전부 필수로 표기돼 있거나, 질문을 보낼 담당자 연락처가 없는 경우예요. 이 네 가지는 개발사가 회신을 포기하거나 금액을 방어적으로 잡게 되는 조건이에요. 특히 기한은 질의 회신을 기다렸다가 금액을 다시 계산할 시간이 남는지로 보세요. 1주일 미만이면 질문을 던져 봐야 답을 받고 반영할 여유가 없어서, 묻지 않고 가정으로 채운 금액이 들어와요.
한 곳에만 추가 정보가 가면 나중에 견적 차이가 정보 차이 때문인지 실력 차이 때문인지 구분할 수 없기 때문이에요. 그래서 RFP를 배포한 뒤 제출 마감까지 사이에 3영업일에서 5영업일 정도 질의 접수 구간을 두세요. 개발사가 문서를 읽고 질문을 정리할 하루, 우리가 답을 모아 한꺼번에 회신할 하루, 그 답을 금액에 반영할 하루를 더한 것이 3영업일이고, 그보다 길게 잡으면 마감만 밀려요. 접수 창구를 한 명으로 지정하고, 들어온 질문과 답변은 질문한 곳뿐 아니라 후보 전체에 같은 내용으로 회신하는 게 원칙이에요.
질의응답의 진짜 소득은 답변이 아니라 질문 목록이에요. 어떤 팀은 로그인 방식과 데이터 보관 기간, 관리자 권한 등급을 묻고, 어떤 팀은 아무것도 묻지 않아요. 질문이 하나도 없이 견적만 온 곳은, 우리 RFP 중 어디를 어떻게 읽었는지 확인할 근거가 남지 않아요. 그 상태에서 온 금액은 나중에 전제가 드러나면서 바뀔 여지가 커요. 질문 목록을 그 자체로 평가 자료로 쓰면, 발표 자리에서 무엇을 확인해야 하는지가 먼저 정리돼요.
질의응답 중에 우리 RFP의 구멍이 드러나는 일도 흔해요. 같은 항목에 대해 서로 다른 두 곳이 같은 질문을 했다면, 그 문장이 모호하다는 뜻이에요. 이때는 RFP를 수정해 재배포하고 마감을 며칠 미루는 게, 해석이 갈린 채로 받은 제안서를 비교하는 것보다 훨씬 싸요.
읽기 전에 평가 항목을 먼저 고정해 두고, 항목마다 무엇을 보면 확인되는지와 어떤 표현이 위험 신호인지를 미리 적은 표로 비교해요. 순서를 뒤집어 제안서부터 나란히 읽으면 잘 쓴 문서가 좋아 보이는 착시가 생겨요. 아래 표는 그대로 비교 시트의 행으로 옮겨 쓸 수 있게 정리한 것이고, 앞에서 RFP에 공개하라고 한 평가 항목이 그대로 이 표의 행이에요. 공개한 기준과 채점하는 기준이 같아야 회신이 그 기준에 맞춰 들어와요.
| 평가 항목 | 확인 방법 | 위험 신호 |
|---|---|---|
| 기술 역량 | 우리와 비슷한 규모의 트래픽과 연동을 다뤄 본 근거, 그 구조를 고른 이유를 적은 문단 | 사용 기술 목록만 나열되고 우리 프로젝트에 왜 그 선택인지가 없음 |
| 유사 도메인 수행 경험 | 지금 접속되는 서비스 URL 또는 스토어 링크를 요구 | 화면 캡처만 있고 살아 있는 결과물이 하나도 없음 |
| 투입 인력 구성 | 역할과 연차, 투입률을 표로 제출받고 착수 후 교체 조건을 명시 | 제안서에는 시니어, 착수 미팅에는 처음 보는 인력 |
| 범위 해석 일치도 | RFP 기능 목록과 제안서 항목을 한 줄씩 1대1로 대조 | RFP에 있던 항목이 제안서에서 설명 없이 사라짐 |
| 일정의 근거 | 마일스톤별 산출물과 승인 기준이 붙어 있는지 확인 | 총 기간만 있고 중간 확인 시점이 없음 |
| 견적 구성 | 기능 단위 분해, QA와 인프라 비용의 위치를 확인 | 총액 한 줄, 항목별 근거 없음 |
| 변경 처리 방식 | 변경 요청 절차와 단가 기준이 문서에 있는지 확인 | 변경은 협의라는 한 단어로 끝남 |
| 커뮤니케이션 방식 | 질의응답에서 받은 질문의 수준과 회신 속도, 착수 후 보고 주기와 창구 | 아무 질문 없이 견적만 회신 |
| 운영과 유지보수 | 개발 종료일 이후의 조건을 제안서에 적었는지 확인 | 개발 종료일 이후에 대한 언급이 아예 없음 |
| 리스크 인식 | RFP에서 정해지지 않은 부분과 전제 조건을 짚었는지 확인 | 모든 요구사항이 가능하다고만 적혀 있음 |
총점만 보고 결정하지는 마세요. 범위 해석 일치도와 운영 항목은 점수가 낮다고 감점하고 넘어갈 게 아니라, 기준 미달이면 총점과 무관하게 후보에서 빼는 통과 조건으로 두는 편이 안전해요. 점수를 매기기 전에 통과 조건으로 한 번 거르고, 남은 곳끼리 점수를 비교하는 순서예요.
금액이 두 배씩 벌어져 보이는 회신도 이 표 위에서 다뤄요. 실력을 의심하기 전에 양쪽이 무엇을 세었고 무엇을 뺐는지부터 대조하세요. RFP 단계에서 할 일은 싼 곳을 골라내는 게 아니라 모든 후보에게 같은 형식으로 견적을 받아 내는 것까지예요. 회신 형식을 RFP에 지정해 두면 전제 조건이 각주나 하단 약관으로 밀려나지 않고 항목 안에 적혀 들어와요. 표에서 세 항목은 다음 단계의 문서가 따로 있어요. 항목별 단가와 공수 산정 방식은 회신받은 견적서를 항목별로 뜯어보는 법에, 변경 처리 방식은 착수 후 변경 요청이 들어왔을 때 굴러가는 CR 절차에 정리해 두었어요. 일정의 근거는 계약 단계에서 조항으로 굳는 항목이라 이 글 마지막 절에서 다시 짚어요. 애초에 범위를 어디서 끊을지가 흔들린다면 필수 기능과 선택 기능을 가르는 판정 기준은 따로 정리해 두었어요.
발표 자리를 잡는다면 슬라이드 발표보다 질문 시간을 길게 잡으세요. 우리 서비스에서 가장 복잡한 화면 하나를 골라 어떻게 구현할 계획인지 물으면, 제안서로는 구분되지 않던 차이가 그 자리에서 드러나요. 이때 답변하는 사람이 실제 프로젝트에 투입되는 인력인지도 함께 확인하세요.
관리자 페이지, 기존 데이터 이관, 초기 콘텐츠 입력, 운영 계정 명의, 외부 서비스 월 과금, 발주자 쪽 과업 여섯 가지예요. 사용자가 보는 화면에만 집중하다 보면 런칭 이후에 반드시 필요한 것들이 견적에서 통째로 빠지는데, 이 항목들은 빠져도 개발 중에는 티가 나지 않다가 오픈 직전에 별건으로 돌아와요. 제안서를 받았을 때 아래 세 열을 그대로 체크리스트로 쓰세요.
| 빠지기 쉬운 항목 | 제안서에서 확인할 것 | 빠졌을 때 나중에 협의해야 하는 것 |
|---|---|---|
| 관리자 페이지 | 운영자가 쓸 화면 목록과 권한 등급이 기능 목록에 있는지 | 런칭 직전에 별도 견적으로 협의가 시작됨 |
| 기존 데이터 이관 | 데이터 건수와 형식, 이관 후 검증 방법 | 이관과 검증 일정을 오픈 일정 안에서 다시 잡아야 함 |
| 초기 콘텐츠 입력 | 상품, 게시글, 이미지 등 첫 데이터를 누가 얼마나 넣는지 | 입력 작업의 담당과 기간을 오픈 직전에 새로 정해야 함 |
| 운영 계정 명의 | 서버, 도메인, 결제 대행사, 앱 스토어 계정을 누구 이름으로 개설하는지 | 계정 이전 조건과 장애 시 연락 절차를 계약과 별도로 협의해야 함 |
| 외부 서비스 월 과금 | 문자, 지도, 결제, 푸시 등 월 과금의 부담 주체 | 런칭 다음 달부터 나갈 고정비의 부담 주체를 다시 정해야 함 |
| 발주자 쪽 과업 | 발주자가 제공해야 할 것(계정, 실데이터, 검수 인원, 회신 기한) 목록이 있는지 | 일정이 밀렸을 때 어느 쪽 사유인지 가릴 근거가 없어 책임 소재부터 협의해야 함 |
특히 계정 명의는 제안서 단계에서 못 박아 두세요. 앱 스토어 개발자 계정이 개발사 명의로 개설되면, 이전하려 해도 개발사 동의와 플랫폼의 이전 조건을 모두 통과해야 해서 우리 일정만으로는 회수할 수 없어요. 장애가 났을 때도 우리 쪽에서 직접 조치할 수 없고 개발사 담당자가 붙을 때까지 기다려야 해요. 인수인계 산출물과 운영자 교육, 장애 연락 체계를 어느 수준으로 요구할지는 운영 인수인계와 SLO를 어떤 기준으로 요청하는지에 기준을 잡아 두었으니, 그 목록을 그대로 제안서에 요구하면 비교표에서 이 칸이 비어 있는 곳이 바로 눈에 들어와요.
선정 통보와 계약 사이에 우선협상 구간을 며칠 두는 게 좋아요. 이 자리에서 RFP 단계의 마지막 할 일은 하나예요. 제안서를 계약서 별첨으로 명시하는 한 문장을 넣는 것. 제안서에만 적혀 있으면 구속력이 약한 기능 목록과 일정, 조건이 그 한 문장으로 계약의 일부가 돼요.
여기서부터는 RFP의 일이 아니라 계약의 일이에요. 계약서에서 처음 등장하는 조항들은 별도로 검토해야 하고, 계약서 단계에서 자주 문제가 되는 조항들을 먼저 훑어보고 협상 자리에 들어가면 평가 1위였던 곳과도 조건을 다시 맞출 여지가 생겨요. 제안서에 적힌 마일스톤 승인 기준을 조항으로 굳히는 일도 이 자리에서 벌어지는데, 어떤 문장으로 옮기는지는 마일스톤별 승인 기준을 계약 조항으로 굳히는 법에 정리해 두었어요. 탈락 후보에 대한 통보는 계약이 확정된 뒤에 하는 편이 협상 여지를 남겨요.
포텐랩이 권하는 기준은 3곳에서 5곳이에요. 2곳 이하면 받은 금액이 비싼지 싼지 판단할 기준선이 안 생기고, 후보가 늘어날수록 회신을 RFP와 한 줄씩 대조하는 검토 시간이 그대로 늘어나요. 성격이 다른 후보를 넣고 싶다면 개발사와 중개 플랫폼을 한 표에 섞지 말고 그룹을 나눠 따로 비교하세요.
배포일과 마감 사이에 3영업일에서 5영업일을 두세요. 개발사가 질문을 정리할 하루, 우리가 답을 모아 회신할 하루, 그 답을 금액에 반영할 하루를 더한 것이 최소선이에요. 접수 창구는 한 명으로 지정하고, 질문과 답변은 질문한 곳뿐 아니라 후보 전체에 같은 내용으로 회신하는 게 원칙이에요.
총액을 비교하기 전에 각 회신이 무엇을 세었고 무엇을 뺐는지부터 대조하세요. RFP 단계에서 할 일은 싼 곳을 골라내는 게 아니라 모든 후보에게 같은 형식으로 견적을 받아 내는 것까지예요. 회신 형식을 RFP에 지정해 두면 전제 조건이 각주나 하단 약관이 아니라 항목 안에 적혀 들어와요.
관리자 페이지, 기존 데이터 이관, 초기 콘텐츠 입력, 운영 계정 명의, 외부 서비스 월 과금, 발주자 쪽 과업 여섯 가지예요. 개발 중에는 티가 나지 않다가 오픈 직전에 별건으로 돌아오는 항목들이라, 제안서를 받는 즉시 이 여섯 칸이 채워졌는지부터 확인하세요.
우선협상 구간을 며칠 두는 편이 좋아요. 제안서를 계약서 별첨으로 명시하는 한 문장을 넣으면 제안서의 기능 목록과 일정, 조건이 계약의 일부가 돼요. 탈락 후보에 대한 통보는 계약이 확정된 뒤에 하는 편이 협상 여지를 남겨요.
슬라이드 발표보다 질문 시간을 길게 잡으세요. 우리 서비스에서 가장 복잡한 화면 하나를 골라 어떻게 구현할 계획인지 물으면, 제안서로는 구분되지 않던 차이가 그 자리에서 드러나요. 답변하는 사람이 실제 프로젝트에 투입되는 인력인지도 함께 확인하세요.
맡겨도 되고, 그때 지켜야 할 원칙은 하나예요. 제안한 개발사와 제안을 검토하는 곳을 분리하는 것이에요. 검토하는 쪽이 같은 건에 제안을 냈다면 그 검토는 비교가 아니라 영업이 돼요. 검토를 맡길 때는 우리 RFP 원문과 회신받은 제안서를 함께 넘기고, 결과는 순위가 아니라 항목별 대조표로 받으세요. 순위만 받으면 왜 그 순서인지 확인할 수 없고, 다음 프로젝트에서 다시 쓸 기준도 남지 않아요.
어디에 맡길지는 만들려는 것이 무엇이냐로 갈려요. MVP나 앱, 웹 프로덕트를 만드는 건이면 포텐랩이 맞고, 챗봇이나 RAG처럼 AI 동작 자체가 결과물의 핵심인 건이면 트리숲(TreeSoop)이 맞아요. 맞지 않는 쪽으로 보내는 게 서로에게 손해라, 저희는 그 판단부터 같이 해요. RFP 작성만 맡기든 받은 제안서 비교 기준을 잡는 단계만 맡기든, 범위 해석이 갈리는 지점과 견적에서 빠진 항목을 짚는 일부터 시작하면 돼요.
RFP는 Request for Proposal의 약자로, 한국어로는 제안요청서라고 해요. 발주자가 여러 공급사에 "우리는 이런 문제를 풀고 싶으니 어떻게 풀지 제안해 달라"고 요청하면서 보내는 문서예요. 답이 적힌 문서가 아니라 질문이 적힌 문서이고, 쓰는 쪽은 돈을 내는 발주자입니다.
방향이 반대예요. RFP(제안요청서)는 발주자가 개발사에게 보내고, 제안서(Proposal)는 개발사가 발주자에게 보냅니다. 한국어 이름이 '요청' 두 글자 차이라 미팅에서 자주 뒤섞여요. 회신이 며칠째 없다면 서로 상대가 보낼 차례라고 생각하고 있는 건 아닌지, 마지막 메일에 적힌 문서 이름부터 확인하세요.
가르는 기준은 정의가 아니라 우리 쪽에서 아직 정해지지 않은 것이 무엇인가입니다. 무엇이 가능한지조차 모르면 RFI, 무엇이 필요한지는 알지만 방법을 모르면 RFP, 사양이 확정돼 가격만 남았으면 RFQ예요. 세 문서는 경쟁 관계가 아니라 미확정 항목을 하나씩 지워 나가는 순서입니다.
기획이 끝난 직후, 개발사를 고르기 직전입니다. 요구사항이 아직 머릿속에만 있으면 RFP를 쓸 수 없고, 반대로 화면 설계까지 전부 확정했다면 단순 견적 요청이 빨라요. 무엇을 만들지는 정했고 어떻게 만들지는 아직 안 정한 구간이 RFP의 자리입니다.
절차의 강제력이 다릅니다. 공공 조달에서는 참가 자격과 평가 배점이 공고문에 적혀 있고 요건을 바꾸려면 공고를 다시 손봐야 해요. 민간 발주는 형식이 자유롭고 제안을 받아 본 뒤 요구사항을 조정할 수 있습니다. 공공 RFP에서는 문서에 적힌 요건을 그대로 충족하는 것이 먼저이고, 요건 밖의 아이디어는 점수를 받을 칸이 없어요.
먼저 견적 편차가 나타납니다. 기준 문서가 없으면 업체마다 서로 다른 범위를 가정하고, 어느 금액이 맞는지 판정할 근거 자체가 없어요. 착수 후에는 "당연히 포함이라 생각했다"와 "그건 추가 건입니다"가 부딪히고, 인수 시점에는 결과물이 기대와 다르다는 것을 증명할 방법이 없습니다.