스타트업 외주 개발, 이것만 알면 돈 안 날립니다

"MVP 하나 만드는 데 3천만 원이 날아갔습니다."

한 커머스 스타트업 대표의 이야기입니다. 지인 소개로 외주 개발팀을 만났고, 미팅 분위기가 좋아서 구두로 범위를 정한 뒤 계약을 체결했습니다. 계약서에는 "쇼핑몰 앱 개발 일체"라고만 적혀 있었습니다. 3개월 뒤 받은 결과물은 기대와 달랐습니다. 관리자 페이지가 빠져 있었고, 결제 모듈은 테스트 환경에서만 작동했으며, 모바일 반응형은 아예 고려되지 않았습니다. 수정을 요청하자 "계약 범위에 없습니다"라는 답변이 돌아왔습니다. 추가 개발 견적은 1,500만 원이었습니다.

이런 사례는 스타트업 커뮤니티에서 매주 올라옵니다. 디스콰이엇, 블라인드, 각종 창업자 오픈채팅방에서 외주 실패담을 검색해 보면 패턴이 놀라울 정도로 비슷합니다. 요구사항이 모호했고, 계약서가 부실했고, 중간 점검이 없었고, 검수 기준이 없었습니다.

외주 개발 자체가 나쁜 것이 아닙니다. 문제는 관리 방식입니다. 이 글에서는 외주 업체 선정부터 계약, 프로젝트 관리, 검수, 유지보수까지 — 실제 스타트업 현장에서 통하는 외주 관리 노하우를 시간 순서대로 정리했습니다.

먼저 판단하세요: 외주가 정말 맞는 상황인가?

외주를 고려하기 전에, 정말 외주가 최선인지 먼저 따져봐야 합니다. 잘못된 판단에서 출발하면 아무리 관리를 잘해도 결과가 좋기 어렵습니다.

외주가 적합한 경우:

• MVP 또는 PoC(개념 증명)를 빠르게 만들어서 시장 반응을 검증해야 할 때
• 앱 디자인, 영상 제작, 인프라 세팅 등 일회성 전문 작업이 필요할 때
• 핵심 제품은 내부에서 개발하되, 부가 기능(어드민 패널, 랜딩 페이지 등)을 병렬로 진행해야 할 때
• 개발자 채용에 2~3개월이 걸리는데, 당장 결과물이 필요할 때

외주가 부적합한 경우:

• 핵심 기술 자체를 외주로 만들려는 경우 (기술 의존도가 너무 높아집니다)
• 요구사항이 계속 바뀌는 초기 탐색 단계 (변경 요청마다 추가 비용이 쌓입니다)
• 완성 후에도 지속적인 기능 추가와 운영이 필요한 제품 (장기적으로 인하우스가 저렴합니다)
• "잘 모르겠으니까 외주에 맡기자"는 마인드 (본인이 모르면 검수도 못 합니다)

가장 위험한 시나리오는 세 번째입니다. MVP를 외주로 만든 뒤 인하우스 개발자를 뽑았는데, 코드 품질이 너무 낮아서 처음부터 다시 만들어야 하는 경우입니다. 이렇게 되면 외주 비용 + 재개발 비용이 이중으로 들어갑니다. 외주를 결정했다면 반드시 코드 품질과 인수 가능성을 계약 단계에서부터 염두에 두어야 합니다.

1단계: 외주 업체 찾기와 선별

한국에서 외주 업체를 찾는 경로는 크게 네 가지입니다.

중개 플랫폼: 위시켓, 프리모아, 크몽 등이 대표적입니다. 위시켓은 프로젝트 단위 매칭에 강하고 에스크로 결제를 지원합니다. 크몽은 소규모 작업(로고, 랜딩 페이지 등)에 적합하며, 프리모아는 IT 전문 프리랜서 매칭에 특화되어 있습니다. 플랫폼의 장점은 포트폴리오와 리뷰를 미리 확인할 수 있다는 것이고, 단점은 플랫폼 수수료(보통 10~20%)가 견적에 반영된다는 것입니다.

직접 소싱: 스타트업 커뮤니티(디스콰이엇, OKKY, 개발자 오픈채팅방)에서 추천을 받거나, GitHub/포트폴리오를 직접 검토해서 연락하는 방법입니다. 수수료가 없지만, 신뢰성 검증을 직접 해야 합니다.

지인 소개: 가장 흔하지만 가장 위험한 경로이기도 합니다. "잘한다더라"는 평판이 자신의 프로젝트에도 맞을 것이라는 보장이 없습니다. 지인 소개라도 포트폴리오 검토와 계약서 체결은 반드시 정식으로 진행하세요. 관계가 불편해질까 봐 계약을 대충 하면, 나중에 관계가 훨씬 더 불편해집니다.

에이전시 vs 프리랜서: 에이전시는 PM, 디자이너, 개발자가 팀으로 붙어서 안정적이지만 비용이 높습니다(보통 3천만 원 이상). 개인 프리랜서는 비용이 저렴하지만, 한 명에게 의존하는 리스크가 있고, 본인이 PM 역할까지 해야 합니다. 예산이 1천만 원 이하라면 프리랜서, 3천만 원 이상이면 에이전시를 권장합니다.

업체 선별 시 반드시 확인할 5가지

1. 유사 프로젝트 경험: "개발 잘합니다"가 아니라, 자신의 프로젝트와 비슷한 유형(이커머스, SaaS, 모바일 앱 등)의 경험이 있는지 확인하세요. 포트폴리오에서 실제 운영 중인 서비스 링크를 받아 직접 확인하는 것이 좋습니다.

2. 기술 스택 일치: 자신이 원하는 기술 스택(React, Flutter, Python 등)을 주력으로 사용하는 팀인지 확인하세요. "다 할 수 있습니다"라고 말하는 팀보다 "이 스택 전문입니다"라고 말하는 팀이 낫습니다.

3. 커뮤니케이션 테스트: 첫 미팅에서 요구사항을 설명한 뒤, 상대방이 역으로 질문을 많이 하는지 살펴보세요. 질문 없이 "다 가능합니다"라고 하는 팀은 요구사항을 제대로 이해하지 못한 것일 가능성이 높습니다.

4. 현재 동시 진행 프로젝트 수: 3~4개 이상을 동시에 진행하고 있다면, 자신의 프로젝트에 충분한 리소스가 투입되지 않을 수 있습니다. 직접 물어보세요.

5. 레퍼런스 확인: 이전 고객사 1~2곳의 연락처를 요청해서 실제로 확인하세요. 거절한다면 주의가 필요합니다.

2단계: 견적서 검토 — 숨겨진 비용을 찾아라

견적서를 받으면 총액만 보지 말고, 항목별 구성을 꼼꼼히 살펴야 합니다.

견적서에 포함되어야 할 항목:

• 기능 목록 (각 기능별 개발 공수 — 인/일 또는 인/시간)
• 디자인 비용 (UI/UX 설계 포함 여부)
• PM(프로젝트 매니저) 비용
• 서버/인프라 초기 세팅 비용
• QA(품질 검증) 비용
• 수정 횟수 및 범위 (보통 2~3회가 표준)
• 유지보수 기간 및 비용 (하자보수 vs 유상 유지보수)

자주 빠지는 숨겨진 비용:

• 서버 비용: 개발은 외주지만 서버 비용은 별도인 경우가 많습니다. AWS, NCP 등 클라우드 비용이 월 얼마나 나올지 미리 확인하세요.
• 외부 API 연동 비용: 결제(PG사), 문자 발송, 지도 API 등 서드파티 연동은 추가 공수가 상당합니다. 견적에 포함인지 별도인지 확인하세요.
• 앱스토어 심사 대응: 모바일 앱의 경우, 앱스토어 심사 리젝 대응이 견적에 포함되는지 확인하세요. 심사 리젝은 흔히 발생하며, 대응에 추가 시간이 듭니다.
• 데이터 마이그레이션: 기존 시스템에서 데이터를 옮겨야 하는 경우, 이 작업이 견적에 빠져 있으면 나중에 추가 비용이 발생합니다.

단가 기준 참고 (2026년 한국 기준):

• 주니어 개발자: 80~120만 원/인월
• 미들급 개발자: 150~250만 원/인월
• 시니어 개발자: 300~500만 원/인월
• UI/UX 디자이너: 150~300만 원/인월

총액이 지나치게 낮은 견적은 경계하세요. 시장 평균의 절반 이하 견적은 경험이 부족한 팀이거나, 중간에 추가 비용을 청구할 가능성이 높습니다. 반대로 지나치게 높다고 무조건 좋은 것도 아닙니다. 2~3곳에서 견적을 받아 비교하면 적정 범위가 보입니다.

3단계: 계약서 — 분쟁을 예방하는 가장 확실한 방법

외주 개발에서 분쟁의 80%는 계약서에서 예방할 수 있습니다. "사이가 좋으니까 대충 해도 되겠지"라는 생각이 가장 비싼 실수입니다.

반드시 들어가야 할 핵심 조항 7가지

1. 산출물 및 범위 정의: 계약서에 "앱 개발"이라고만 적으면 안 됩니다. 기능 목록(화면 단위 또는 기능 단위)을 별첨으로 첨부하고, "별첨 1의 기능 목록에 명시된 범위"라고 명확히 기재하세요. 기능 정의서, 와이어프레임, 화면 설계서가 있다면 함께 첨부합니다.

2. 저작권 및 지적재산권 귀속: 가장 중요한 조항입니다. "개발 완료 후 산출물의 저작권 및 지적재산권은 갑(발주자)에게 귀속된다"고 명시해야 합니다. 이 조항이 없으면 저작권법상 개발자(을)에게 저작권이 남을 수 있습니다. 소스코드, 디자인 파일, 기술 문서 모두 포함시키세요. 간혹 "소스코드는 을의 자산이며 갑에게는 사용권만 부여한다"는 조항이 들어가 있는 경우가 있는데, 이러면 나중에 다른 개발팀에게 유지보수를 맡길 수 없습니다.

3. 기밀유지(NDA) 조항: 외주 과정에서 사업 아이디어, 고객 데이터, 기술 정보 등이 공유됩니다. 기밀유지 조항을 계약서에 포함하거나, 별도 NDA를 체결하세요. 특히 외주 개발사가 유사한 프로젝트를 다른 클라이언트에게도 수행하는 경우가 있으므로, 경쟁 제한 조항도 고려할 필요가 있습니다.

4. 납기일 및 지연 페널티: "약 3개월"이 아니라 구체적인 날짜를 명시하세요. 그리고 지연 시 페널티 조항을 넣으세요. 일반적으로 "지연일 1일당 총 계약 금액의 0.1~0.3%를 위약금으로 지급"하는 형태입니다. 단, 페널티만 넣고 끝내면 일방적이므로 "불가항력(천재지변, 발주자 측 요구사항 변경 등)으로 인한 지연은 예외"라는 단서도 함께 넣는 것이 공정합니다.

5. 하자보수 기간 및 범위: 개발 완료 후 일정 기간 동안 버그 수정을 무상으로 보장하는 조항입니다. 업계 표준은 검수 완료 후 3~6개월입니다. "하자"의 정의도 명확히 해야 합니다. 명세서에 명시된 기능이 작동하지 않는 것이 하자이지, 신규 기능 추가 요청은 하자가 아닙니다. 이 구분이 모호하면 분쟁이 발생합니다.

6. 대금 지급 조건: 전액 선불은 절대 하지 마세요. 가장 일반적인 구조는 다음과 같습니다.

• 계약 시 착수금: 30%
• 중간 마일스톤(디자인 확정 또는 1차 개발 완료): 30%
• 최종 검수 완료 후: 40%

잔금 비율을 40% 이상으로 유지하는 것이 핵심입니다. 이것이 검수 단계에서 수정을 요청할 수 있는 실질적인 레버리지가 됩니다.

7. 분쟁 해결 및 관할 법원: "본 계약에 관한 분쟁은 서울중앙지방법원을 관할 법원으로 한다"와 같이 관할 법원을 지정해 두세요. 규모가 큰 프로젝트라면 대한상사중재원(KCAB) 중재 조항을 넣는 것도 방법입니다.

4단계: 프로젝트 관리 — 던져놓고 기다리면 실패합니다

계약서를 잘 써도, 개발 기간 동안 관리를 하지 않으면 결과물은 기대와 달라집니다. 외주 프로젝트에서 발주자의 역할은 "시키고 기다리는 사람"이 아니라 "방향을 잡아주는 사람"입니다.

마일스톤 설정

전체 프로젝트를 3~5개의 마일스톤으로 나누세요. 예를 들어, 3개월짜리 앱 개발 프로젝트라면 다음과 같이 나눕니다.

• M1 (2주차): 화면 설계서(와이어프레임) 확정
• M2 (4주차): UI 디자인 시안 확정
• M3 (8주차): 핵심 기능 개발 완료 (알파 버전)
• M4 (10주차): 전체 기능 개발 완료 (베타 버전)
• M5 (12주차): QA 완료 및 최종 검수

각 마일스톤마다 구체적인 산출물을 정의하고, 이 산출물을 확인한 후에 다음 단계로 넘어가야 합니다. M2에서 디자인 시안이 마음에 들지 않으면 거기서 수정하는 것이지, 코딩이 끝난 뒤에 디자인을 바꾸려 하면 비용이 3배로 늘어납니다.

주간 체크인

최소 주 1회, 30분짜리 진행 상황 미팅을 하세요. 형식은 간단해도 됩니다.

• 지난주에 완료한 것
• 이번 주에 할 것
• 막히는 것 또는 결정이 필요한 것

이 미팅의 목적은 감시가 아니라 조기 경보입니다. 2주 동안 진척이 없다면 심각한 문제가 숨어 있을 가능성이 높습니다. 빨리 파악할수록 해결 비용이 낮습니다.

커뮤니케이션 도구는 슬랙 또는 카카오톡 단체방보다 노션이나 지라(Jira) 같은 프로젝트 관리 도구를 권장합니다. 대화는 흘러가지만, 태스크 보드에 기록된 내용은 남습니다. 나중에 "이건 말씀 안 하셨는데요"라는 상황을 방지할 수 있습니다.

디자인 시안 확정 프로세스

디자인 단계에서 가장 많은 분쟁이 발생합니다. "느낌이 좀 다른데요"라는 피드백은 수십 번의 수정 루프로 이어집니다. 이를 방지하려면 다음과 같은 절차를 정하세요.

1. 레퍼런스 공유: 좋아하는 앱이나 웹사이트 3~5개를 미리 공유하세요. "깔끔한 느낌"보다 "토스 앱의 메인 화면 같은 느낌"이 훨씬 구체적입니다.
2. 시안 수정 횟수 제한: 계약서에 "디자인 시안 수정은 2회까지 포함, 추가 수정은 건당 OO만 원"이라고 명시하세요.
3. 확정 서명: 디자인 시안이 확정되면 이메일이나 문서로 "이 시안으로 확정합니다"라는 서면 동의를 남기세요. 구두 확인은 나중에 "확정한 적 없다"로 번복될 수 있습니다.

중간 산출물 확인

개발이 진행되는 동안, 실제 작동하는 화면을 정기적으로 확인하세요. 코드만 작성하고 3개월 뒤에 한꺼번에 보여주겠다는 팀은 위험합니다. 2주에 한 번이라도 개발 서버에 올라간 화면을 직접 클릭해 보세요. 초기에 발견한 문제는 수정 비용이 낮고, 나중에 발견한 문제는 비용이 기하급수적으로 올라갑니다.

5단계: 검수 — 대충 하면 돈을 두 번 씁니다

개발이 끝났다고 해서 바로 잔금을 지급하면 안 됩니다. 체계적인 검수 프로세스를 거쳐야 합니다.

QA 체크리스트

최소한 아래 항목을 확인하세요.

기능 검증:

• 계약서(기능 명세서)에 명시된 모든 기능이 작동하는가?
• 주요 사용자 시나리오(회원가입 → 로그인 → 핵심 기능 사용 → 결제)가 끊김 없이 진행되는가?
• 에러 상황(잘못된 입력, 네트워크 끊김 등)에서 적절한 에러 메시지가 표시되는가?

크로스 환경 테스트:

• 모바일: iOS Safari, Android Chrome에서 정상 작동하는가?
• 데스크톱: Chrome, Safari, Edge에서 레이아웃이 깨지지 않는가?
• 다양한 화면 크기에서 반응형이 정상 작동하는가?

성능 확인:

• 주요 페이지 로딩 시간이 3초 이내인가?
• 동시 접속자 처리가 가능한가? (예상 트래픽 기준)

보안 기본 점검:

• HTTPS가 적용되어 있는가?
• 비밀번호가 암호화되어 저장되는가?
• SQL 인젝션, XSS 등 기본적인 보안 취약점이 없는가?

소스코드 인수

검수가 완료되면 다음을 인수받아야 합니다.

• 소스코드 전체: GitHub 또는 GitLab 저장소의 소유권 이전, 또는 전체 코드 전달
• 환경 변수 및 설정 파일: 서버 접속 정보, API 키, 데이터베이스 접속 정보 등
• 기술 문서: 설치 방법, 빌드 방법, 배포 방법이 적힌 최소한의 README
• 계정 정보: 서버, 도메인, SSL 인증서, 앱스토어 개발자 계정 등

특히 소스코드를 받은 뒤 반드시 다른 개발자가 빌드할 수 있는지 확인하세요. 코드를 받았는데 빌드가 안 되면 사실상 코드를 받지 않은 것과 같습니다. 가능하면 인수 전에 내부 개발자나 신뢰할 수 있는 제3의 개발자에게 코드 리뷰를 요청하세요.

검수 확인서

검수가 완료되면 "검수 완료 확인서"를 양측이 서명합니다. 이 문서에는 검수 일자, 검수 범위, 확인된 미비 사항 및 보완 일정, 하자보수 시작일을 기재합니다. 검수 확인서 없이 잔금을 지급하면, 나중에 하자 발생 시 "검수 때 문제없었잖아요"라는 반론에 대응하기 어렵습니다.

흔한 분쟁 사례와 예방법

외주 개발에서 반복적으로 발생하는 분쟁 패턴 네 가지와 예방법입니다.

1. "이건 추가 개발입니다" 분쟁: 발주자는 당연히 포함이라 생각했는데, 개발사는 범위 밖이라 주장하는 경우. 예방법은 기능 명세서를 최대한 상세하게 작성하고 계약서에 첨부하는 것입니다. "게시판 기능"이 아니라 "게시판 기능 — 글 작성, 수정, 삭제, 목록 조회, 페이지네이션, 이미지 첨부(최대 5장), 댓글"까지 나열하세요.

2. 연락 두절: 중간에 연락이 끊기는 경우. 예방법은 주간 체크인을 의무화하고, 계약서에 "연속 7일 이상 연락 두절 시 계약 해지 사유에 해당"하는 조항을 넣는 것입니다. 대금을 마일스톤별로 분할 지급하면 연락 두절의 동기도 줄어듭니다.

3. 품질 기준 분쟁: "작동은 하는데 너무 느려요" 또는 "디자인이 시안과 달라요" 같은 경우. 예방법은 성능 기준(로딩 시간 3초 이내 등), 디자인 기준(확정된 시안 대비 pixel-perfect 수준 또는 허용 오차 범위)을 계약서에 명시하는 것입니다.

4. 저작권 분쟁: 외주 개발사가 동일한 코드를 다른 프로젝트에 재사용하는 경우. 예방법은 저작권 귀속 조항을 명확히 하고, 개발사가 범용 라이브러리나 프레임워크를 사용하는 경우 그 부분은 예외로 처리하되, 프로젝트 고유의 비즈니스 로직은 발주자에게 귀속된다고 구분하는 것입니다.

유지보수: 외주 이후를 대비하세요

프로젝트 검수가 끝나도 소프트웨어는 완성이 아닙니다. 버그 수정, 기능 개선, 서버 관리가 계속 필요합니다.

하자보수 기간(보통 3~6개월)에는 계약서에 명시된 기능의 버그를 무상으로 수정받을 수 있습니다. 이 기간 동안 최대한 많이 테스트하고, 발견된 버그는 기록으로 남겨서 수정을 요청하세요.

하자보수 기간이 지난 후에는 두 가지 선택지가 있습니다.

• 유상 유지보수 계약: 같은 외주사에 월 일정 금액을 지급하고 운영 및 소규모 수정을 맡기는 방법. 월 50~200만 원 수준이 일반적입니다.
• 인하우스 전환: 자체 개발자를 채용하여 유지보수와 기능 추가를 내재화하는 방법. 장기적으로 비용 효율이 높지만, 인수인계가 제대로 되어야 가능합니다.

어떤 방식을 선택하든, 소스코드와 기술 문서를 확보해 두는 것이 전제 조건입니다. 외주사만 코드를 가지고 있으면, 해당 외주사에 종속되어 가격 협상력을 잃게 됩니다.

마무리: 외주는 기술이 아니라 관리의 문제입니다

외주 개발 실패의 원인은 대부분 기술이 아니라 관리입니다. 업체 선정을 꼼꼼히 하고, 계약서를 제대로 쓰고, 중간에 점검하고, 체계적으로 검수하면 — 외주도 충분히 좋은 결과를 낼 수 있습니다.

글에서 다룬 내용을 한 문장으로 요약하면 이렇습니다. "모든 것을 문서로 남기세요." 요구사항, 견적, 계약 조건, 디자인 확정, 검수 결과 — 구두로 합의한 것은 존재하지 않는 것입니다.

외주 계약서 작성이 막막하다면, AiDocX의 AI 계약서 작성 기능으로 용역계약서 초안을 빠르게 만들어 볼 수 있습니다. 저작권 귀속, 하자보수, 기밀유지 조항이 포함된 구조화된 초안을 AI가 생성해 주므로, 빠뜨리기 쉬운 조항을 점검하는 출발점으로 활용해 보세요.