외주 업체 선정 기준 2026 — 제안서 배점표로 비교하는 7단계

개발 외주 제안서를 세 곳에서 받았다. 금액도 다르고 분량도 다르고, 무엇보다 서로 다른 것을 만들겠다고 적혀 있다. 이 상태에서 최저가를 고르면 싼 걸 고른 게 아니라 범위가 가장 좁은 걸 고른 것이다.

이 글은 여러 업체의 제안을 같은 자로 재는 배점표를 만드는 7단계를 정리한 것이다. 100점 배분 예시와 가격 배점을 15~25점으로 묶는 이유, 최저가 만점식과 기준가 편차식이 실제로 만드는 점수 차이, 정성 항목의 판정 루브릭 작성법, 평가위원 구성과 제안발표 질문까지 발주처가 그대로 쓸 수 있는 형태로 담았다.

제안서 평가 기준을 먼저 만들어야 하는 이유

같은 요구사항을 보냈는데 견적이 1,800만 원, 3,200만 원, 5,500만 원으로 들어온다. 이건 업체 세 곳의 단가가 세 배 차이 난다는 뜻이 아니다. 세 곳이 서로 다른 것을 만들겠다고 답한 것이다. 한 곳은 화면 12개만 세었고, 한 곳은 기존 데이터 이관과 권한 설계까지 넣었고, 한 곳은 1년 유지보수와 인수인계 교육까지 포함했다.

그래서 견적서 세 장을 나란히 놓고 최저가를 고르는 방식은 비교가 아니다. 비교하려면 무엇을 몇 점으로 볼지 먼저 정한 표가 있어야 한다. 이 표가 제안 평가표이고, 그 표를 만드는 규칙이 제안서 평가 기준이다.

순서는 하나뿐이다. 요구사항 정의서 → 배점표 확정 → 제안서 접수 → 평가. 배점표는 제안서 접수 마감 전에 확정하고 문서로 잠근다. 요구사항 정의서 자체를 쓰는 법은 요구사항 정의서 작성법에서 따로 다뤘으니 여기서는 반복하지 않는다.

⚠️ 제안서를 다 읽은 뒤에 배점표를 만들면 기준이 이미 본 제안 쪽으로 휜다. 본인은 객관적이라고 느끼지만 결과는 정해져 있다. 더 큰 문제는 탈락한 업체가 사유를 물었을 때 답할 근거가 없다는 것이다. 다음 프로젝트에서 그 업체는 다시 제안하지 않는다.

배점표 100점을 어디에 나눌 것인가

민간 발주처가 그대로 써도 되는 기본 배분이다. 프로젝트 성격에 따라 ±5점 안에서 조정한다.

가격은 15~25점 사이로 둔다. 조달청 협상에 의한 계약도 기술 80 대 가격 20을 기본으로 삼고, 소프트웨어 사업에서는 기술 비중을 더 올려 운영한다. 정부가 최저가를 피하려고 20년 걸려 만든 배분을 민간이 다시 발명할 이유가 없다.

요구사항 이해도에 25점을 몰아주는 이유는 명확하다. 프로젝트가 깨지는 지점의 대부분이 범위 해석 차이이기 때문이다. 기술 스택이 틀려서 실패한 프로젝트보다, 서로 다른 것을 만들고 있다는 사실을 3개월 뒤에 안 프로젝트가 훨씬 많다.

⚠️ 가격에 40점 이상을 주면 그 표는 최저가 입찰서다. 배점표를 만든 노력이 통째로 무의미해진다. 반대로 가격 0점도 안 된다. 예산을 초과한 제안이 1등이 되면 평가를 다시 해야 한다.

가격 점수를 계산하는 두 가지 방식

가격 배점을 정한 다음이 진짜 함정이다. 환산식을 어떻게 쓰느냐로 결과가 뒤집힌다.

최저가 만점식은 `배점 × (최저 견적 ÷ 해당 견적)`이다. 단순하고 흔하지만 덤핑 제안에 만점을 준다. 기준가 편차식은 내부 예산 또는 견적 중위값을 기준가로 놓고, 기준가의 ±10% 안이면 만점, 벗어난 폭만큼 감점한다. 아래는 가격 배점 15점, 기준가 3,000만 원일 때의 실제 차이다.

최저가 만점식에서는 A사가 B사보다 6.2점 앞선다. 기술 점수에서 뒤집으려면 B사가 요구사항 이해도에서 A사를 크게 이겨야 한다. 기준가 편차식에서는 이 왜곡이 사라진다. 덤핑과 과다 견적을 같은 방향으로 감점하기 때문이다.

⚠️ 예산 상한을 RFP에 적지 않으면 견적 분산이 3배까지 벌어지고, 그 순간 가격 점수는 사실상 난수가 된다. 기준가를 잡을 근거가 없어지기 때문이다. 상한은 공개하는 편이 낫다.

정량평가와 정성평가를 분리하는 법

정량평가와 정성평가를 한 표에 섞어 위원들에게 던지면 채점이 무너진다. 서류만 보면 답이 나오는 항목을 사람이 감으로 매기게 되기 때문이다. 둘은 채점 주체부터 다르다.

정량 항목은 담당자가 제안서 접수 즉시 채점해 표로 배포한다. 위원이 이력서를 세고 있을 시간에 요구사항 이해도를 읽어야 한다.

정성 항목은 항목마다 3단계 앵커 문장을 미리 쓴다. 예를 들어 요구사항 이해도라면 이렇게 적는다. 우수 — 제외 범위를 명시하고 요구사항 번호 단위로 대응 방식을 기술했다. 보통 — 전체 범위를 서술했으나 요구사항 번호와 연결되지 않는다. 미흡 — 일반적인 개발 절차만 기술했고 우리 요구사항 고유의 내용이 없다.

⚠️ 정성 항목 이름에 "성실성", "신뢰도", "적극성" 같은 단어가 들어가면 그 항목은 채점 불가다. 관찰 가능한 문장으로 바꿔라. 바꿀 수 없다면 그 항목은 배점표에서 빼는 게 맞다.

평가위원 구성 — 3~5인, 발주부서 단독은 금지

평가위원은 홀수로 3~5인이다. 2인은 의견이 갈리면 결론이 안 나고, 7인이 넘으면 일정을 잡다가 계약이 2주 밀린다.

외부 자문 1인 비용은 서면 검토와 제안발표 참석을 합쳐 반나절 기준 30만~80만 원이다. 3,000만 원짜리 프로젝트에서 이 비용을 아끼는 것은 계산이 맞지 않는다.

이해충돌은 서약으로 처리한다. 최근 3년 내 해당 업체와 거래·재직·자문 이력이 있거나 친인척이 소속된 위원은 그 건에서 빠진다. 위원 가중치는 전원 동일하게 두고, 위원장 가산점은 만들지 않는다.

⚠️ 대표 한 사람이 제안발표를 보고 결정하는 조직이라면 평가표는 사후 정당화 문서가 된다. 그 경우엔 평가 절차를 생략하고 대표가 직접 고르는 편이 정직하다. 형식만 있는 평가는 담당자의 시간을 쓰고 결과는 바꾸지 못한다.

제안발표(PT)에서 반드시 물을 질문 8개

제안발표는 발표를 듣는 자리가 아니라 제안서에 안 쓰인 것을 확인하는 자리다. 발표 15분, 질의 15분이 적정 배분이다.

1. 우리 요구사항 중 이번 범위에서 제외한 항목 세 가지는 무엇인가
2. 이 일정에서 가장 먼저 밀릴 항목은 무엇이고 왜 그런가
3. 투입 인력 중 실제로 코드를 쓰는 사람은 몇 명이고, 오늘 이 자리에 몇 명이 왔나
4. 기존 데이터 이관은 몇 회 리허설하나, 실패하면 되돌릴 절차가 있나
5. 검수 기준은 누가 쓰나, 우리가 쓰나 업체가 쓰나
6. 산출물 목록과 소스 코드·지식재산권 귀속은 어떻게 되나
7. 하자보수 기간은 몇 개월이고, 그 이후 유지보수 요율은 얼마인가
8. 우리가 중간에 요구를 바꾸면 어떤 절차로 처리되고 비용은 어떻게 산정되나

4번과 5번에서 업체 수준이 가장 잘 갈린다. 검수 기준을 발주처가 써야 한다고 답하는 업체는 최소한 정직하다. 검수를 알아서 하겠다고 답하는 업체는 대개 검수 개념이 없다. 검수 기준을 어떻게 문서로 만드는지는 테스트 케이스 작성법에 정리해 뒀다.

⚠️ 발표에 나온 인력과 계약 후 투입되는 인력은 자주 다르다. 제안서에 명시된 핵심 인력을 교체할 때 발주처 사전 승인을 받는다는 조항을 계약서에 넣어라. 이 조항 하나가 실적 부풀리기 제안을 대부분 걸러낸다.

프로젝트 유형별 정상 견적대와 기간

배점표가 있어도 기준가를 모르면 가격 점수를 못 준다. 아래는 국내 중소 규모 외주 시장에서 반복적으로 확인되는 밴드다. 요구사항 정의서가 있는 상태를 전제로 한다.

밴드 하단의 60% 이하로 들어온 견적은 감점이 아니라 질의로 처리한다. 어느 요구사항을 범위에서 뺐는지 서면으로 받고, 그 답변을 요구사항 이해도 항목에 반영한다. 실제로 효율이 좋아서 싼 팀도 있다. 둘을 구분하는 것은 가격이 아니라 그 답변이다.

⚠️ 비용을 견적서 총액으로만 비교하면 3년 뒤에 뒤집힌다. 유지보수 요율, 서버·라이선스 비용, 인수인계 없이 재의뢰할 때의 비용까지 합쳐서 본다. 개발비 1,800만 원에 연 유지보수 25%는 개발비 2,400만 원에 연 10%보다 3년 총비용이 크다.

배점표로 실제 채점하면 무슨 일이 일어나는가

표를 만들어도 숫자가 어떻게 움직이는지 보지 않으면 배점이 적절한지 알 수 없다. 사내 재고관리 시스템 발주(예산 상한 4,000만 원)에 세 곳이 제안했다고 하자.

제안 금액은 A사 2,600만 원, B사 3,250만 원, C사 4,000만 원이었다. 최저가 만점식(최저가/해당가×20)으로 계산한 결과다.

여기서 읽어야 할 것이 세 가지다.

하나, 1위와 2위가 1점 차다. A사 81점과 C사 80점은 통계적으로 같은 점수다. 이 폭에서는 평가위원 한 명의 주관이 순위를 뒤집는다. 3점 이내로 붙으면 총점으로 결정하지 말고 제안발표를 한 번 더 잡거나, 미리 정해 둔 동점 처리 기준을 적용해야 한다. 동점 기준은 접수 마감 전에 정해 둔다. 사후에 정하면 특정 업체를 밀기 위한 기준으로 보인다.

둘, C사는 가격에서 7점을 잃고도 2위다. 정성 항목에서 A사보다 앞섰기 때문이다. 만약 가격 배점이 40점이었다면 C사는 A사에 14점 뒤져 경쟁 자체가 성립하지 않았다. 가격 배점을 15~25점으로 묶으라는 말의 실제 의미가 이것이다.

셋, B사는 실적 점수만 높고 나머지가 전부 중간이다. 회사 규모로 따온 실적은 이 프로젝트에 투입되는 인력과 무관한 경우가 많다. 그래서 실적 항목은 회사 실적이 아니라 투입 예정 인력의 유사 프로젝트 참여 이력으로 받아야 한다.

⚠️ 표를 채우기 전에 위원별 원점수를 먼저 모으고 평균을 나중에 내라. 회의실에서 합의하며 채우면 목소리 큰 사람의 점수로 수렴한다. 각자 채점한 뒤 항목별 편차가 큰 곳만 골라 토론하는 순서가 맞다. 편차가 큰 항목은 대개 평가 기준 문장이 모호한 것이지 위원 간 실력 차가 아니다.

탈락 업체의 이의제기를 처리하는 법

배점표를 쓰기 시작하면 반드시 따라오는 것이 이의제기다. 미리 절차를 정해 두지 않으면 담당자가 개인 판단으로 답하게 되고, 그 답이 다음 발주의 선례가 된다.

핵심은 네 유형 모두 접수 마감 전에 만들어 둔 문서로 답할 수 있어야 한다는 점이다. 이해관계 확인서, 배점표, 평가 기준 문장, 채점 기록 네 가지가 있으면 이의제기는 사무 절차로 끝난다. 없으면 논쟁이 된다.

평가를 시작하기 전에 발주처가 확정해야 할 것

아래 목록이 다 채워지기 전에는 제안서를 받지 않는다. 하나라도 비어 있으면 업체마다 다른 전제로 견적을 내고, 그 순간 비교 자체가 성립하지 않는다.

• 예산 상한과 공개 여부 — 공개를 권장한다
• 요구사항 정의서 — 요구사항마다 고유 번호가 붙어 있어야 한다
• Must / Should / Could 구분 — 필수와 선택이 갈려 있지 않으면 견적이 흩어진다
• 납기와 그 근거 — 외부 일정(전시회, 감사, 계약 만료)이 있으면 명시
• 데이터 이관 대상과 원본 소유자 — 기존 시스템 벤더 협조 여부 포함
• 검수 주체와 합격 기준 — 누가 언제 무엇으로 합격을 판정하나
• 계약 조건 — 지재권 귀속, 하자보수 기간과 기산점, 유지보수 요율. 세 항목 모두 제안 접수 전에 문안이 확정돼 있어야 업체가 같은 전제로 견적을 낸다 (계약 이후를 지키는 7단계)
• 평가위원 명단과 배점표 — 접수 마감 전 확정, 이후 수정 금지
• 유찰·재공고 조건 — 몇 곳 미만이면 다시 받나

⚠️ 이 중 실무에서 가장 자주 비는 항목은 Must/Should/Could 구분과 검수 기준이다. 두 개가 비면 제안서는 비교 대상이 아니라 각자 다른 문서 여섯 장이 된다. 업체 선정 이후의 계약·관리 관점은 .NET 외주 업체 선정 가이드에서 이어서 다룬다.

제안서 평가에서 흔한 실패 5가지

1. 최저가 낙찰. 1,800만 원에 계약하고 변경 요청으로 3,400만 원이 된다. 총액은 늘고 신뢰는 줄고 일정은 두 달 밀린다. 가격 배점을 낮게 잡는 이유가 이것이다.

2. 제안서를 받은 뒤 배점표 만들기. 특정 제안의 강점이 그대로 평가 항목이 된다. 평가가 아니라 선택의 사후 정당화다.

3. 정성 항목에 앵커 문장이 없음. 위원 A는 요구사항 이해도에 22점, 위원 B는 12점을 준다. 같은 제안서를 읽고 그렇다. 배점 25점짜리 항목에서 10점 편차가 나면 그 항목이 사실상 결과를 정한다.

4. 실적을 건수로만 세기. 실적 20건이 우리 문제와 무관하면 0건과 같다. 실적표는 건수가 아니라 우리 요구사항 상위 3개와 같은 문제를 푼 적이 있는가로 본다. 20건 중 1건이라도 맞으면 그 1건을 상세히 묻는 편이 낫다.

5. 유지보수·인수인계 배점 0점. 개발이 끝나면 관계가 끝난다고 가정한 평가표다. 실제로는 인수인계 문서가 없어서 다음 업체가 처음부터 다시 만들고, 그 비용을 발주처가 두 번 낸다.

⚠️ 다섯 가지 중 4번이 압도적으로 흔하다. 제안서의 실적 페이지는 대개 로고 나열이라 검증 없이 점수가 매겨진다. 계약서나 완료확인서 사본을 요구하면 실적표의 절반이 사라지는 경우가 있다.

AI-Native 팀이 제안서 평가를 다루는 방식

2026년부터 제안서에 AI 도구 활용이 등장하기 시작했다. "AI로 개발해 기간을 절반으로 줄인다"는 문장이 그대로 들어온다. 발주처가 이걸 어떻게 평가해야 하는지가 새 문제다.

기간과 비용이 줄어드는 것은 사실이다. 다만 줄어드는 것과 검증 절차가 있는 것은 다른 문제다. 평가 항목을 세 개 추가하면 구분된다.

나무숲(TreeSoop)은 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 쓴다. 그래서 제안 단계에서 산출물 목록과 함께 검토 절차를 같이 낸다. 어떤 공정을 AI가 초안 잡고 어디서 사람이 판단하는지 문서로 구분해 두면, 발주처는 그 문서를 평가표에 그대로 대입할 수 있다. 이 작업 방식은 AI-Native 개발 방식에 정리돼 있다. AI가 들어가지 않는 순수 웹·앱 구축이라면 포텐랩(Potenlab) 같은 팀의 제안도 같은 표로 비교된다. 평가 기준은 도구와 무관하게 동일하다.

⚠️ "AI로 빠르게"를 가격 할인 근거로만 내세우면서 검토 절차를 못 쓰는 제안은 감점 대상이다. 속도는 산출물 품질의 근거가 아니다. 반대로 AI를 쓰지 않는다는 이유로 감점해서도 안 된다. 평가 항목은 결과물과 책임 소재이지 도구가 아니다.

자주 묻는 질문

Q. 제안을 몇 곳에서 받아야 하나?

3~5곳이다. 2곳은 비교가 아니라 선택이고, 7곳이 넘으면 위원들이 다 못 읽어 평가 품질이 떨어진다. 사전에 회사 소개서로 5곳까지 추린 뒤 정식 제안을 요청하는 방식이 현실적이다.

Q. 예산을 RFP에 공개해야 하나?

공개를 권한다. 감추면 견적 분산이 커져 가격 점수가 무의미해지고, 업체는 범위를 임의로 줄여 예산을 맞춘다. 상한을 밝히면 같은 범위에서 무엇을 더 주는지로 경쟁이 옮겨간다.

Q. 결국 최저가를 뽑으면 안 되는 건가?

가격 배점 15~25점 안에서 최저가 업체가 총점 1위를 했다면 아무 문제 없다. 문제는 가격이 사실상 유일한 변수일 때다. 공공 발주에서 협상에 의한 계약 방식이 기술 배점을 크게 두는 이유도 같다. 배점표는 최저가를 배제하는 장치가 아니라 가격 외 항목을 같이 보게 만드는 장치다.

Q. 탈락한 업체에 결과를 알려줘야 하나?

항목별 점수와 위원별 채점은 공개하지 않는다. 다만 "요구사항 이해도와 유지보수 계획에서 차이가 있었다" 수준의 요약은 전달한다. 이 한 통이 다음 프로젝트의 제안 품질을 올린다.

Q. 제안서 접수부터 계약까지 얼마나 걸리나?

접수 마감 후 3~4주가 표준이다. 서류 검토와 정량 사전 채점 1주, 제안발표 1주, 협상과 계약 1~2주다. 이보다 짧으면 검토가 형식이 되고, 6주를 넘기면 제안 시점의 견적 전제가 흔들린다.

정리

제안서 평가에서 결과를 가르는 지점은 세 가지다.

하나, 배점표를 제안서보다 먼저 만든다. 접수 마감 전에 확정하고 그 뒤로는 고치지 않는다. 순서가 뒤집히면 나머지 절차는 전부 사후 정당화가 된다.

둘, 가격은 15~25점으로 묶고 기준가 편차식으로 계산한다. 최저가 만점식은 덤핑 제안에 만점을 주고, 그 제안은 계약 후 변경 요청으로 총액을 회수한다. 밴드를 크게 벗어난 견적은 감점이 아니라 서면 질의로 처리한다.

셋, 정성 항목마다 3단계 앵커 문장을 쓴다. 앵커 없는 정성 평가는 위원 간 10점 편차를 만들고, 그 편차가 배점표 전체보다 결과에 크게 작용한다. 앵커를 못 쓰는 항목은 평가할 수 없는 항목이므로 표에서 뺀다.