외주 개발사를 선택하는 프로세스: 요구사항 정리부터 계약까지
외주 개발사를 잘못 선택하면 프로젝트의 전체가 흔들립니다. 선택이 실패하는 건 판단 기준이 아니라 판단 순서 때문인 경우가 많습니다. 요구사항 확정부터 계약까지 다섯 단계와, 후보를 점수로 비교하는 가중 스코어카드까지, 외주 개발사를 선정하는 순서를 정리했습니다.
Jul 20, 2026
개발이 필요한 서비스나 앱을 개발할 때, 그리고 아직은 내부 개발팀이 없이 외주 개발을 통해 MVP부터 개발을 먼저 시작해야 할 때가 있습니다. 개발사를 잘못 선정하게 되면 프로젝트의 시작부터 끝까지 전부 어려움에 봉착할 수밖에 없습니다. 그러나 막상 선택하려고 하면 무엇부터 해야 할지가 막막합니다. 대부분은 아는 외주 개발사 몇 곳에 연락해 견적서를 받는 것으로 시작합니다.
그러나 사실 여기서부터 어긋나기 시작하는 셈입니다. 우리가 무엇을 원하는지 확정하지 않은 상태에서 받은 견적서는 서로 비교할 수가 없습니다. 각 회사가 저마다 다른 범위를 가정하고 계산한 숫자이기 때문입니다. 판단 기준이 명확하지 않아서 실패로 이어지는 경우는, 그러나 생각보다 적습니다. 대부분의 큰 실패는 대개 판단의 순서에서 옵니다. 이 글은 개별 판단 기준을 하나씩 해설하는 대신, 개발사 선택을 실제로 굴리는 다섯 단계의 순서와 후보를 점수로 비교하는 도구를 정리합니다. 각 단계에서 더 깊이 알아야 할 내용은 해당 글로 안내합니다.
선택은 다섯 단계로 진행됩니다
전체 순서는 다섯 단계입니다. 요구사항을 확정하고, 후보 목록을 만들고, 가중치를 매겨 점수로 비교하고, 상위 후보를 검증하고, 계약 구조를 확정합니다.
각 단계에는 만들어야 할 산출물과 다음 단계로 넘어가도 되는지를 판단하는 조건이 있습니다. 요구사항 단계에서는 요구사항 문서와 예산 범위가 나와야 하고, 후보 목록 단계에서는 최종 평가할 3~5곳이 확정되어야 합니다. 평가 단계에서는 점수표가, 검증 단계에서는 확인이 끝난 한 곳이 나옵니다. 계약 단계에서 조항을 확인하고 서명하면 선택이 끝납니다.
순서를 건너뛰면 당장의 시간은 절약할 수 있을지 몰라도 결국엔 실패의 확률이 올라갑니다. 요구사항 없이 견적부터 받으면 비교 기준이 없어 결국 최저가를 고르게 됩니다. 검증 없이 계약하면 제안서에 적힌 인력과 실제 투입되는 인력이 다른 것을 뒤늦게 알게 됩니다. 계약 조항을 확인하지 않고 서명하면 소스코드 소유권이나 유지보수 범위를 나중에 협상해야 하는데, 그 시점에는 협상력이 이미 개발사 쪽에 있습니다.
외주 개발사 후보를 만나기 전에 요구사항부터 확정합니다
가장 먼저 할 일은 외주 개발사를 찾는 것이 아닙니다. 우리가 무엇을 원하는지 문서로 만드는 것입니다. 이 단계를 건너뛰면 이후 모든 단계가 모래성 위에 쌓이는 결과로 이어질 수 있습니다.
이것이 단순히 형식적인 절차가 아니라는 근거는 공공 발주 기준에서 확인할 수 있습니다. 국가가 소프트웨어 사업의 제안서를 평가할 때 배점이 가장 큰 항목은 회사 규모나 실적이 아니라 요구사항 분석과 추진 전략입니다. 조달청 제안서 평가 기준에서 이 항목의 배점은 최대 30점으로, 제안 업체의 조직과 인력과 실적을 합친 항목(10점)의 세 배입니다. 발주자의 문제를 정확히 이해하고 그에 맞는 전략을 제시했는지를 가장 중요하게 본다는 뜻입니다. 그런데 발주자가 요구사항을 정리하지 않으면 개발사는 이 항목에서 좋은 제안을 할 수가 없습니다.
확정해야 할 것은 세 가지입니다. 첫째, 요구사항 문서입니다. 필요한 화면과 기능, 사용자가 누구이며 어떤 순서로 움직이는지를 정리합니다. 완벽할 필요는 없고, 개발사가 같은 전제로 견적을 낼 수 있을 정도면 됩니다. 둘째, 예산 범위입니다. 여기서 제작비만 잡으면 나중에 곤란해집니다. 소프트웨어 생애비용의 60~80%가 출시 이후 유지보수에서 발생하므로, 운영 예산까지 포함해 범위를 잡아야 합니다. 이 구조는 「유지보수 비용의 진실」에서 자세히 다뤘습니다. 셋째, 프로젝트의 성공 기준입니다. 무엇이 되면 이 프로젝트가 성공인지를 미리 정해야 나중에 검수 기준이 됩니다.
요구사항을 글로만 쓰기 어렵다면 노코드나 AI 코딩 도구로 화면을 만들어 보는 방법이 있습니다. 실제로 돌아가는 화면 하나가 기획서 열 장보다 오해를 줄입니다. 도구로 만든 프로토타입을 발주 문서로 활용하는 방법은 「노코드·바이브코딩으로 만든 앱과 서비스의 한계와 시사점」에서 정리했습니다. 이 세 가지가 내부적으로 도출되기 전까지는, 가급적 외주 개발사를 만나지 않는 것이 좋습니다.
유형을 좁혀 후보 목록을 만듭니다
요구사항이 나오면 외주 개발사 후보를 리스트업하고 모읍니다. 실무에서는 8~12곳 정도의 넓은 목록에서 시작해 최종 평가 대상 3~5곳으로 좁히는 방식을 씁니다.
넓게 시작하는 이유는 처음부터 아는 곳 두세 군데만 보면 시장의 가격대와 수준을 모르는 채 판단하게 되기 때문입니다. 반대로 최종 평가를 3~5곳으로 제한하는 이유는 그 이상이 되면 비교 자체가 되지 않기 때문입니다. 후보가 여덟 곳이면 각각의 제안을 제대로 읽을 시간이 없고, 결국 인상이나 가격 같은 단순한 기준으로 판단하게 됩니다.
좁히는 데는 엄격한 평가가 필요 없습니다. 다섯 가지 조건으로 거르면 충분합니다. 우리 프로젝트와 비슷한 작업 경험이 있는가, 우리 프로젝트 규모에 맞는 회사인가(너무 큰 회사에 작은 프로젝트를 맡기면 우선순위에서 밀립니다), 단가 범위가 우리 예산과 맞는가, 우리가 원하는 일정에 인력을 투입할 수 있는가, 협업 방식이 우리와 맞는가입니다.
여기서 함께 정할 것이 유형입니다. 프리랜서와 중소 개발사와 대형 개발사와 매칭 플랫폼은 비용과 책임 범위와 연속성이 서로 다릅니다. 오래 운영할 서비스이고 담당자가 바뀌어도 유지되어야 한다면 팀 단위로 책임지는 개발사 쪽이 맞고, 범위가 좁고 기간이 짧은 작업이라면 프리랜서가 합리적일 수 있습니다. 각 유형의 장단점과 비용 구조는 「프리랜서 vs 개발사 vs 매칭 플랫폼 비교」에서 다뤘으니, 이 단계에서는 우리 프로젝트에 어느 유형이 맞는지만 정하면 됩니다.
기준에 가중치를 매겨 점수로 비교합니다
여기가 선택의 중심입니다. 3~5곳의 후보를 놓고 무엇을 얼마나 중요하게 볼지 정한 다음 점수로 비교합니다.
먼저 가격을 어떻게 다룰지부터 정해야 합니다. 대부분의 발주자는 견적서를 나란히 놓고 비교하는 것으로 평가를 시작합니다. 국가는 정반대로 합니다. 국가계약법 시행령과 기획재정부 계약예규에 따른 협상에 의한 계약에서, 정보시스템 구축 같은 기술강조형 사업은 기술 90점에 가격 10점을 배정합니다. 일반적인 경우에도 기술 70점에 가격 30점이 기본입니다. 소프트웨어에서는 가격이 판단의 10~30%짜리 항목이라는 뜻입니다. 게다가 가격 평가에도 하한이 있어서, 추정가격의 80%에 못 미치는 지나치게 낮은 입찰은 오히려 최저점을 받습니다. 싸다고 점수를 더 주지 않는 구조입니다.
주의할 점은 이 배점이 고정값이 아니라는 것입니다. 국가 기준도 사업 특성에 따라 기술강조형(90 대 10), 균형형(80~70 대 20~30), 가격중시형(50 대 50)으로 배점을 바꿉니다. 단순한 용역이라면 가격 비중을 높이는 것이 합리적입니다. 중요한 것은 배점을 프로젝트 성격에 맞춰 미리 정하고 시작한다는 원칙입니다.
평가표를 만드는 방법은 단순합니다. 평가할 항목을 5~10개로 제한하고, 각 항목에 가중치를 매겨 합이 100%가 되게 합니다. 후보마다 각 항목을 1~5점으로 채점하고, 점수에 가중치를 곱해 더하면 총점이 나옵니다. 채점 전에 점수의 의미를 합의해 두어야 합니다. 5점은 요구를 넘어서는 수준, 3점은 기본 요구를 충족하는 수준, 1점은 미달이거나 위험이 있는 수준으로 정하는 식입니다. 평가자가 여러 명이면 각자 채점한 뒤 평균을 내면 개인의 선호가 희석됩니다. 평가할 일곱 가지 축은 다음과 같습니다.
첫째는 요구사항 이해도입니다. 우리가 준 문서를 읽고 우리 문제를 정확히 파악했는지, 빠진 것을 짚어 주는지를 봅니다. 공공 평가에서 배점이 가장 큰 항목이기도 합니다. 둘째는 투입 인력의 수준입니다. 실무에서 이 항목을 가장 중요하게 보는 이유는 분명합니다. 실제로 일하는 사람이 우리 프로젝트에 맞지 않으면 나머지 조건이 아무리 좋아도 결과가 나오지 않습니다. 셋째는 도메인 경험과 유사 실적입니다. 우리와 비슷한 문제를 풀어 본 적이 있는지를 봅니다. 넷째는 소통과 관리 체계입니다. 진행 상황을 어떻게 공유하고 문제가 생겼을 때 어떤 절차로 대응하는지를 봅니다. 다섯째는 코드 품질과 인수인계입니다. 결과물을 나중에 다른 사람이 이어받을 수 있는 상태로 만드는지를 보는 항목으로, 판단 방법은 「코드를 못 읽어도 품질을 판단하는 법」에서 정리했습니다. 여섯째는 유지보수와 운영 조건입니다. 출시 이후의 대응 범위와 비용 구조를 봅니다. 일곱째는 계약 구조와 지식재산권입니다. 소스코드 소유권이 우리에게 오는지, 중간에 다른 주체가 끼는지를 봅니다.
가격은 이 일곱 축에 넣지 않고 별도 항목으로 두고, 프로젝트 성격에 따라 10~30%를 배정하는 방식이 실무에서 다루기 쉽습니다.
가중치는 프로젝트 성격에 따라 달라집니다. 오래 운영할 핵심 시스템이라면 코드 품질과 유지보수와 계약 구조에 무게를 싣고, 개인정보나 결제를 다루는 시스템이라면 계약과 인력과 관리 체계를 올립니다. 빠르게 시장을 검증하는 것이 목적이라면 요구사항 이해도와 소통 속도가 중요하고, 범위가 좁은 단순한 작업이라면 가격 비중을 높여도 됩니다.
마지막으로 점수의 한계를 알아 두어야 합니다. 총점은 판단을 돕는 도구이지 판단 자체가 아닙니다. 점수 차이가 근소하다면 숫자로 우열을 가리려 하지 말고, 함께 일할 때의 소통 방식처럼 점수화하기 어려운 요소를 놓고 판단하는 편이 낫습니다. 이 표는 순위를 자동으로 정해 주지 않습니다. 주관적인 인상을 설명 가능한 근거로 바꿔 내부에서 합의할 수 있게 만드는 것이 이 표의 쓸모입니다.
상위 후보만 골라 검증합니다
점수가 나오면 상위 2~3곳만 실제로 검증합니다. 모든 후보를 검증하는 것은 시간 낭비이고, 점수가 낮은 곳을 검증해도 결론이 바뀌지 않습니다.
검증은 세 방향으로 합니다. 첫째, 질문으로 확인합니다. 테스트와 코드 리뷰 절차, 장애 대응 방식, 인수인계 자료 같은 것을 묻고 답변의 구체성을 비교합니다. 무엇을 물어야 하는지는 「외주 개발사를 검증하는 10가지 체크리스트」에 목록으로 정리해 두었으니 이 단계에서 그대로 활용하면 됩니다.
둘째, 레퍼런스가 실재하는지 확인합니다. 포트폴리오에 올라온 작업이 실제로 그 회사가 수행한 것인지, 어느 범위까지 참여했는지를 확인합니다. 가능하다면 이전 고객에게 직접 물어보는 것이 가장 정확합니다. 이때 유지보수까지 계속 맡기고 있는 고객의 비율을 물어보면 많은 것이 드러납니다. 만들고 나서 관계가 끊긴 고객만 있다면 그 이유를 확인해야 합니다.
셋째, 제안한 인력이 실제로 투입되는지 확인합니다. 제안서에는 경력 많은 개발자가 적혀 있지만 실제로는 다른 사람이 투입되는 경우가 있습니다. 공공 발주에서도 한 사람이 여러 사업에 겹쳐 투입되는 것을 감점 사유로 봅니다. 책임자급 인력이 우리 프로젝트에 어느 정도 비율로 참여하는지를 계약 전에 확인하고 문서로 남겨야 합니다.
계약 구조로 마지막을 확정합니다
검증을 통과한 곳과 계약합니다. 이 단계가 마지막인 이유는, 여기서 정해지지 않은 것은 전부 나중에 비용이 되기 때문입니다. 프로젝트가 시작된 뒤에는 협상력이 발주자 쪽에서 개발사 쪽으로 넘어갑니다.
계약 형태부터 확인합니다. 개발사와 직접 계약하는지, 중개 주체가 끼는지에 따라 책임 소재와 연속성이 달라집니다. 이 차이는 「중개 플랫폼보다 직계약 개발이 안전한 3가지 이유」에서 다뤘습니다.
조항에서는 네 가지 범주를 확인합니다. 소스코드와 산출물의 소유권이 누구에게 있는지, 유지보수의 범위와 기간과 비용이 어떻게 되는지, 인수인계로 무엇을 받는지, 하자가 발생했을 때 담보 기간과 책임 범위가 어떻게 되는지입니다. 특히 유지보수 조건은 출시 이후 발생할 비용의 대부분을 좌우하므로 계약 단계에서 명시해야 합니다. 인수인계 자료를 받을 수 있어야 나중에 다른 개발사로 옮기거나 내부에서 운영하는 선택지가 생깁니다.
선택에서 반복되는 판단 실수
지금까지의 다섯 단계를 뒤집어 보면 실패하는 방식도 다섯 가지로 정리됩니다. 요구사항 없이 견적부터 받아 비교 기준을 잃는 것, 후보를 너무 많이 두거나 너무 적게 두는 것, 가격을 최우선으로 두는 것, 검증을 생략하고 제안서만 믿는 것, 계약 조항을 확인하지 않고 서명하는 것입니다. 다섯 가지 모두 순서를 지키면 대부분 피할 수 있습니다.
스파르타빌더스는 직계약으로 진행하며 소스코드와 인수인계 패키지를 표준으로 제공합니다. 개발이 끝나면 아키텍처 문서와 운영 매뉴얼과 접근 권한을 함께 넘겨, 발주사가 직접 운영하거나 다른 팀에 이어줄 수 있는 상태로 마무리합니다. 지금 개발사를 고르는 중이라면 평가 기준과 가중치를 프로젝트 성격에 맞게 잡는 것부터 함께 정리해 드립니다.
자주 묻는 질문
Q1. 외주 개발사는 어떤 순서로 골라야 합니까?
- 총 다섯 단계를 거쳐 선택하시길 권장합니다. 요구사항과 예산과 성공 기준을 확정하고, 후보를 8~12곳에서 3~5곳으로 좁히고, 평가 항목에 가중치를 매겨 점수로 비교하고, 상위 2~3곳을 질문과 레퍼런스로 검증하고, 계약 조항을 확인해 확정합니다. 견적서 비교부터 시작하지 않는 것이 핵심입니다.
Q2. 외주 개발사 선정하기에 앞서 몇 곳을 비교해야 합니까?
- 넓은 후보 목록은 8~12곳, 실제로 제안을 받아 평가하는 곳은 3~5곳이 적당합니다. 후보가 너무 적으면 시장의 가격대와 수준을 모르는 채 판단하게 되고, 너무 많으면 각 제안을 제대로 읽지 못해 단순한 기준으로 고르게 됩니다.
Q4. 가중치는 어떻게 정합니까?
- 프로젝트 성격에서 출발합니다. 오래 운영할 핵심 시스템이면 코드 품질과 유지보수와 계약 구조에 무게를 싣고, 개인정보나 결제를 다루면 계약과 인력과 관리 체계를 올리고, 빠른 검증이 목적이면 요구사항 이해도와 소통을 올립니다. 항목은 5~10개로 제한하고 가중치의 합이 100%가 되게 맞춥니다.
Q5. 소규모 프로젝트에도 이 절차가 필요합니까?
- 축소해서 적용하면 됩니다. 후보를 3곳 정도로 줄이고 평가 항목을 4~5개로 줄여도 순서 자체는 지키는 것이 좋습니다. 특히 요구사항을 먼저 정리하는 첫 단계와 계약에서 소스코드 소유권을 확인하는 마지막 단계는 프로젝트 규모와 관계없이 필요합니다. 규모가 작을수록 문제가 생겼을 때 감당할 여력도 작기 때문입니다.
Share article