외주 개발사를 검증하는 10가지 체크리스트
본 아티클에서는 외주 개발사와의 미팅과 RFP에서 그대로 쓸 수 있는 10가지 질문을 네 그룹으로 구분하고 분류하여 정리했습니다. 어떤 회사가 외주 개발의 실패를 최소화하고 피하는지, 그 배경을 확인해봅니다.
Jun 05, 2026
외주 개발사를 비교할 때 가장 흔한 함정은 가격과 포트폴리오에 집중하는 것입니다. 견적이 가장 낮은 회사를 골랐다가 분쟁이 발생하면, 그때서야 계약서 조항이 빠져 있었다는 사실을 알게 됩니다. 한국소프트웨어공제조합(SCI)이 보증 처리한 SW 사업 분쟁 사례를 분석한 자료에 따르면, 분쟁의 70% 이상에서 계약서상 핵심 조항 누락이 원인으로 지목됩니다. 결국 좋은 외주사를 고르는 일은 가격 비교가 아니라 '물어볼 것을 물어보고 확인하는 일'에서 시작됩니다.
본 아티클에서는 외주 개발사와의 미팅과 RFP에서 그대로 쓸 수 있는 10가지 질문을 네 그룹으로 정리합니다. 구조·계약, 팀·운영, 프로세스·검증, 사후·리스크 — 외주 프로젝트가 어디에서 무너지는지를 다룬 「외주 개발 실패하는 7가지 이유와 예방법」이 "실패는 어떻게 일어나는가"를 다뤘다면, 이 글은 "어떤 회사가 그 실패를 최소화하고 피하는가"를 가르는 질문과 같습니다.
좋은 외주사일수록 같은 질문에 같은 방식으로 답합니다. 첫 미팅에서 무엇을 물어볼지가 명확히 정해져 있으면, 개발 회사마다의 차이가 답변에서 드러납니다.
그룹 A. 구조·계약
Q1. 직계약입니까, 중개 플랫폼입니까?
가장 먼저 확인할 것은 계약의 당사자입니다. 매칭 플랫폼은 전자상거래법 제20조의 통신판매중개자 지위로 운영되며, 본인은 거래 당사자가 아니라는 점을 약관에 명시합니다. 분쟁이 발생해도 플랫폼은 양측 사이를 중재할 뿐 직접 책임을 지지 않습니다. 직계약 개발사는 법인이 직접 계약 당사자로 들어와 책임 추적이 끊기지 않는 구조입니다.
좋은 답변 | 위험 신호 |
"법인이 직접 계약 당사자입니다" | "저희는 매칭만 하고 개별 프리랜서가 계약합니다" |
"한국소프트웨어산업협회(KOSA) 표준계약서를 사용합니다" | "자체 계약서를 사용합니다" (조항 누락 위험) |
"분쟁 시 저희 법인이 직접 대응합니다" | "당사자 간 협의를 우선합니다" |
- 추가 확인 포인트: 사업자등록증과 계약 당사자 명시 위치를 함께 요청하면 더 명확해집니다. 직계약 모델의 구조적 차이는 「직계약 개발이 중개 플랫폼보다 안전한 3가지 이유」에서 자세히 다룹니다.
Q2. 계약서에 IP 귀속·인수 기준·유지보수 조항이 명시되어 있습니까?
KOSA가 보급한 SW 표준계약서는 다섯 가지 핵심 조항, 즉 변경 관리, 소스코드 IP 귀속, 인수 기준(Acceptance Criteria), 유지보수 범위, 분쟁 해결 절차를 포함합니다. 자체 양식을 사용하는 회사일수록 이 조항들이 누락될 가능성이 큽니다. SCI 보증 분쟁 사례에서도 "납품 기준 불명확"과 "변경 처리 규정 부재"가 분쟁 원인 1~2위로 반복 등장합니다.
그 결과는 계약서에 적힌 한 줄에서 갈립니다. 한 중견 출판사가 디지털 구독 플랫폼을 1억 5,000만 원에 외주해 6개월 만에 출시한 뒤, 모바일 결제 모듈을 추가하려 하자 기존 개발사가 소스코드 인계를 거부한 사례가 있습니다. 그 근거는 "계약서에 IP 귀속 조항이 명시되어 있지 않다"는 한 줄이었습니다. 분쟁조정에 6개월을 잃은 끝에 다른 개발사를 찾아 처음부터 다시 만들면서 1억 4,000만 원이 더 들어갔습니다. 표준계약서의 IP 귀속 조항 한 줄이 들어 있었다면 막을 수 있었던 비용입니다.
좋은 답변 | 위험 신호 |
KOSA 표준계약서 + 5조항 모두 명시 | "그건 프로젝트 진행하면서 정합시다" |
인수 기준이 단계별로 명문화 | "납품 완료는 보통 합의로 처리합니다" |
1년 하자담보책임 조항 자동 포함 | "유지보수는 별도 계약으로 다시 협의합니다" |
- 추가 확인 포인트: 계약서 초안을 미팅 단계에서 받아 IP·인수·유지보수 조항의 위치를 직접 짚어보면, 답변의 정확성이 즉시 검증됩니다.
Q3. 변경 발생 시 비용·일정 산정 룰이 있습니까?
외주 프로젝트 실패 원인 1위는 요구사항 변경에 대한 처리 룰 부재로 알려져 있습니다. 외주 시작 후 요구사항이 추가되거나 변경되는 일은 자연스럽지만, 그 변경을 어떻게 처리할지에 대한 약속이 없으면 견적이 폭증하거나 일정이 무너집니다. "변경에 별도의 비용이 책정되어 있지 않는다"라는 답이 가장 위험합니다. 그 말은 변경의 비용이 처음 견적 안에 숨어 있거나, 변경이 일정 지연으로 전가된다는 의미인 경우가 많습니다.
좋은 답변 | 위험 신호 |
"스코프 변경은 별도 견적으로 처리합니다" | "변경은 무료로 반영해 드립니다" |
"월 시간 한도 내에서 변경을 흡수합니다" | "그때그때 협의해서 진행합니다" |
변경 요청서 양식과 승인 절차 운영 | 변경 기록 관리 절차 부재 |
- 추가 확인 포인트: 변경 요청서 샘플이 있는지, 변경 이력이 어디에 기록되는지를 물으면 룰의 실제 운영 여부가 드러납니다.
그룹 B. 팀·운영
Q4. 우리 프로젝트에 투입되는 개발자가 다른 프로젝트와 병행합니까?
NIPA 소프트웨어산업실태조사에 따르면, 국내 중소 SW 개발사에서 개발자 1인이 동시에 참여하는 프로젝트는 평균 2~3개로 파악됩니다. Gerald Weinberg의 컨텍스트 스위칭 연구에 따르면 2개 이상 병행 시 개인 생산성이 20~40% 감소합니다. 응답이 느린 외주 개발자는 게으른 것이 아니라, 구조적으로 그렇게 되어 있는 셈입니다.
한 달이 지난 뒤에야 다른 프로젝트와 병행 중이라는 걸 알게 됐습니다. 한 의료 IT 스타트업이 발주한 병원 진료 예약 앱은 4개월 일정이었지만, 슬랙 메시지에 답이 오는 데 평균 이틀, 코드 리뷰 응답은 5일까지 늦어졌습니다. 일정을 제 일정에 맞추기 위한 백업 외주 의뢰가 들어와 들여다보니, 담당 개발자가 동시에 다른 두 프로젝트에 투입된 상태였습니다. 일정이 6개월로 늘어난 사이 경쟁사가 유사 기능의 앱을 먼저 출시했고, 시장 진입 타이밍을 놓친 비용은 인건비 추가분보다 훨씬 크고 막대했습니다.
좋은 답변 | 위험 신호 |
1인 1프로젝트 전담 모델 | "여러 프로젝트 동시 진행이 효율적입니다" |
주간 가용 시간 보고 가능 | "투입 비율은 비공개입니다" |
계약서에 전담 여부 명문화 | "유연하게 조정합니다" |
- 추가 확인 포인트: 주간 가용 시간을 숫자로 받을 수 있는지 물으면, "이번 주 우리 프로젝트에 몇 시간 투입됐는가" 가 정량적으로 추적 가능한지가 드러납니다.
Q5. 전담 PM이 의사결정에 참여할 권한을 갖고 있습니까?
NIPA 보고서에 따르면 10인 미만 SW 개발사에서 전담 PM이 있는 비율은 30% 미만으로 알려져 있습니다. 절반 이상의 외주 프로젝트가 '개발자 겸 PM' 구조로 진행된다는 뜻입니다. PMI Pulse of the Profession 2023은 명확한 의사결정 구조를 갖춘 프로젝트의 성공률이 그렇지 않은 경우 대비 약 2.5배에 이른다고 보고합니다. PM이 명목상 존재해도 의사결정 권한이 없으면 회의에서 "확인하고 알려드리겠습니다"가 반복되고, 그 사이 개발자는 가설 위에서 코드를 쌓다가 가설이 틀리면 다시 작성하게 됩니다.
좋은 답변 | 위험 신호 |
전담 PM이 주간 회의 의사결정 참여 | "개발자가 PM을 겸합니다" |
우리 측 단일 의사결정자와 매칭 | "확인 후 알려드리겠습니다" 반복 |
의사결정/보고/검토 안건 사전 구분 | 회의 안건이 매번 즉석에서 정해짐 |
- 추가 확인 포인트: 계약 전에 담당 PM과 직접 30분 인터뷰를 요청하면 의사결정 권한의 실체가 가장 빠르게 드러납니다.
Q6. C레벨이나 시니어가 프로젝트에 직접 관여합니까?
영업 담당자와 처음 미팅한 뒤 실제 프로젝트는 신입 PM·주니어 개발자가 맡는 구조가 흔합니다. 그 단절이 분쟁의 시작점이 되는 경우가 많습니다. CTO나 시니어가 주간 회의에 참여하거나, 분쟁 발생 시 직접 대응하는 구조가 있는 회사라면 의사결정 회피 단계가 줄어듭니다.
좋은 답변 | 위험 신호 |
CTO·시니어가 주간 1회 이상 참여 | "영업담당이 전체 책임을 집니다" |
분쟁 시 C레벨이 직접 대응 | 분쟁 처리 라인이 영업 → 본사로만 전달 |
시니어가 코드 리뷰·아키텍처 결정 | 시니어가 미팅 시점에만 등장 |
- 추가 확인 포인트: 분쟁이나 일정 위기 시점에 누가 클라이언트와 직접 대화하는지를 미리 물어두면 답변의 결이 분명해집니다.
그룹 C. 프로세스·검증
Q7. 사전 디스커버리 워크숍과 와이어프레임 합의 단계가 있습니까?
외주 실패의 가장 큰 원인이자 1순위 위험요소는, 요구사항 미정의입니다. 한국 중소기업 외주 시장에서는 디스커버리 단계 없이 구두로 착수하는 관행이 흔하고, 그 관행이 변경 폭증의 출발선이 됩니다. 별도의 디스커버리 워크숍과 와이어프레임 합의 단계가 있는 회사라면, 그리고 그 산출물을 계약 첨부물로 합의하는 회사라면 변경의 출발선이 분명해집니다.
워크숍 1주를 들인 팀과 들이지 않은 팀의 결과가 갈린 자리는, 4개월 후 데모실에서였습니다. 같은 업종의 두 회사가 거의 같은 규모의 ERP 시스템을 외주했는데, 한 회사는 디스커버리 워크숍에 1주를 들였고 다른 회사는 견적과 동시에 개발에 착수했습니다. 워크숍을 거친 팀은 4개월 만에 운영팀이 그대로 사용 가능한 시스템을 받았고, 워크숍을 생략한 팀은 같은 시점에 핵심 화면 5개를 다시 만드는 작업에 들어가야 했습니다. 차이는 와이어프레임이 계약서에 첨부되어 있었는가, 없었는가에 있었습니다.
좋은 답변 | 위험 신호 |
디스커버리 워크숍이 별도 단계 | "MVP니까 바로 만들죠" |
와이어프레임을 계약 첨부물로 합의 | "기획은 진행하면서 정합시다" |
사용자 흐름도·기능 정의서 산출물 명시 | 산출물 없이 구두 합의 |
- 추가 확인 포인트: 이전 프로젝트의 디스커버리 산출물 샘플을 익명화한 형태로 요청하면 실제 운영 여부가 즉시 드러납니다.
Q8. 스프린트 단위 데모와 단계별 부분 인수가 가능합니까?
Standish Group의 CHAOS Report는 애자일 방식 프로젝트의 성공률을 약 42%, 워터폴 방식을 약 13%로 보고합니다. 차이는 결국 "중간에 보여주고 고치는가"에서 갈립니다. 한국 외주 시장은 여전히 워터폴 일괄 납품이 관행이고, "데모는 출시 직전 한 번"이라는 답이 돌아오면 최종 단계에서 전면 재작업이 발생할 위험을 그대로 안고 가야 합니다.
좋은 답변 | 위험 신호 |
2~3주 단위 스프린트 데모 | "최종 데모 한 번에 통합 검토" |
단계별 부분 인수 + 서면 피드백 | 일괄 납품 후 한꺼번에 인수 |
데모 일정이 계약서에 명시 | 데모 일정은 진행하면서 조정 |
- 추가 확인 포인트: 스프린트 길이, 데모 형식, 서면 피드백 양식의 샘플을 함께 요청하면 운영의 실체가 보입니다.
그룹 D. 사후·리스크
Q9. 무상 유지보수 기간과 인수인계 패키지가 포함됩니까?
NIPA의 SW 유지보수 비용 산정 가이드는 시스템 총 생애 비용 중 60~80%가 출시 이후 유지보수에 들어간다고 보고합니다. 출시는 종료점이 아니라 비용의 시작점입니다. 무상 유지보수 기간과 인수인계 패키지, 즉 시스템 아키텍처 다이어그램, 환경별 배포·운영 매뉴얼, 계정·API 키·도메인 권한 인계, SLA 명시, 종료 후 전환 시나리오 등이 포함된 외주는 출시 직후의 사고에 즉시 대응이 가능합니다.
출시 다음 주 결제 오류가 발생했을 때, 두 회사의 대응은 달랐습니다. 한 디지털 콘텐츠 기업의 구독 플랫폼이 출시 2주 후 결제 모듈에서 오류를 일으킨 사례가 있는데, PG사와의 결제 검증 응답 로직에 결함이 있었던 것이지만, 정작 더 큰 문제는 기존 개발사 연락이 지연됐다는 점이었습니다. 7일 동안 결제 불가 상태가 이어졌고, 그 기간 신규 구독 가입이 멈추면서 약 2,300건의 가입 기회가 사라졌습니다. 응급 패치 의뢰가 들어와 들여다보니 무상 유지보수 기간이 계약서에 명시되어 있지 않았고, 인수인계 문서도 한 장 남아 있지 않은 상태였습니다.
좋은 답변 | 위험 신호 |
1년 무상 유지보수 자동 포함 | "유지보수는 별도 계약입니다" |
인수인계 5종 세트 표준 제공 | "필요하면 추가 비용으로 만들어드립니다" |
SLA(응답 시간 약속) 계약서 명시 | "최대한 빨리 대응합니다" |
- 추가 확인 포인트: 인수인계 5종 세트 중 한 가지(예: 운영 매뉴얼)의 샘플을 익명화 형태로 요청하면 실제 표준화 여부가 검증됩니다.
Q10. 분쟁 시 해결 절차가 계약서에 명시되어 있습니까?
분쟁은 일어나지 않는 것이 가장 좋지만, 일어났을 때 다툴 절차가 확립되고 정해져 있어야 양측이 합리적인 결정으로 도달할 수 있습니다. 한국인터넷진흥원(KISA) 산하 전자거래분쟁조정위원회는 SW 용역 분쟁을 매년 처리하고, 그 사례 다수에서 발견된 '분쟁 절차의 불명확성과 미정'이 결국 양측 주장이 평행선을 달리게 만든 결과입니다.
좋은 답변 | 위험 신호 |
분쟁조정 기관 명시 (예: 전자거래분쟁조정위원회) | "원만한 협의로 해결합니다" |
관할 법원 명시 | 관할 조항 자체 없음 |
단계별 분쟁 절차 (조정 → 중재 → 소송) | "분쟁은 거의 없습니다" 답으로 회피 |
- 추가 확인 포인트: 과거 분쟁 사례를 어떻게 처리했는지 익명화된 형태로 물으면 실제 대응 역량이 드러납니다.
종합 체크리스트
10문항을 한 표로 정리하면 RFP나 미팅 진행 시 그대로 사용할 수 있습니다.
좋은 외주 개발사의 공통점
이 10문항을 비교 미팅에서 그대로 던지면, 두 회사의 답변에서 명확한 차이가 드러납니다. 좋은 외주사일수록 같은 질문에 같은 방식으로, 즉 계약·구조·운영의 표준화된 모델로 답합니다. 답이 회사마다 다르고, 즉석에서 만들어내는 듯한 답이 돌아온다면, 그 회사의 운영 모델 자체가 표준화되어 있지 않다는 신호입니다.
스파르타빌더스는 위 10문항 중 네 가지 핵심 영역, 직계약 모델(Q1), 1인 1프로젝트 전담(Q4), C레벨 직접 참여(Q6), 1년 무상 유지보수 + 인수인계 패키지(Q9)을 기본 운영 모델로 제공합니다. 좋은 외주사를 고르는 일은 결국 같은 질문에 같은 방식으로 답하는 회사를 찾는 일입니다. 직계약 모델이 위 위험을 어떻게 줄이는지는 「직계약 개발이 중개 플랫폼보다 안전한 3가지 이유」에서 자세히 다룹니다. 비슷한 비교를 진행 중이라면 프로젝트 규모와 도메인에 맞는 견적과 검증 시나리오를 함께 정리해 드립니다.
Share article