웹 개발 외주 사기 안 당하는 체크리스트 3가지
외주 개발을 처음 맡겨보는 분들한테 가장 많이 듣는 말이 있습니다.
"계약할 때까지는 엄청 친절했는데, 계약금 받고 나서 연락이 점점 느려졌어요."
포트폴리오도 그럴싸하고, 미팅 때 말도 잘 통했는데 막상 돈을 보내고 나면 분위기가 바뀌는 경험 — 외주 시장에서 꽤 자주 일어납니다. 크몽이나 위시켓 같은 플랫폼을 이용해도 마찬가지입니다. 플랫폼이 최소한의 안전망을 제공하긴 하지만, 실제 커뮤니케이션 품질이나 결과물 수준까지 보장해주진 않거든요.
이 글에서는 계약 전·진행 중·납품 직전 단계별로 꼭 확인해야 할 체크리스트 3가지를 정리합니다. 업계 실무에서 나온 이야기라 조금 딱딱하게 들릴 수도 있지만, 알아두면 수백만 원을 아낄 수 있습니다.
🔍 왜 외주 개발 사기가 이렇게 많을까?
진입 장벽이 낮고, 검증이 어렵다
개발자 자격증이나 면허 같은 건 없습니다. 포트폴리오 사이트 하나 만들면 누구든 "개발 에이전시"를 표방할 수 있죠. 실제로 1~2인이 운영하면서 수주는 계속 늘리고, 개발은 다시 더 저렴한 프리랜서에게 재하청을 주는 구조도 적지 않습니다.
문제는 발주자 입장에서 이걸 사전에 파악하기가 쉽지 않다는 겁니다. 미팅에서 보여주는 결과물이 실제로 자기 팀이 만든 건지, 다른 클라이언트 것을 빌려 보여주는 건지 알 방법이 없으니까요.
"싸게 먹히려다" 더 비싸게 치르는 구조
처음엔 저렴해 보이는 견적을 제시한 뒤, 개발이 시작되면 "이건 범위 밖이라 추가 비용이 필요합니다"라는 패턴도 흔합니다. 기능 하나 추가할 때마다 별도 견적이 붙는 구조인 거죠. 처음 계약서에 기능 범위를 명확히 적어두지 않으면 이런 식으로 비용이 늘어납니다.
✅ 체크리스트 1 — 계약서에 이것만 있으면 절반은 막힌다
계약서가 있다는 것 자체보다, 계약서에 뭐가 적혀 있는지가 중요합니다. 아래 항목이 빠져 있다면 계약 전에 반드시 요청하세요.
| 항목 | 체크 포인트 |
|---|---|
| 기능 범위(Scope) | 어디까지가 이번 계약 범위인지 기능 단위로 명시 |
| 납기 일정 | 마일스톤(단계별 납기) + 최종 납기 날짜 |
| 지연 시 처리 방법 | 지연 발생 시 환불·위약금 조항 |
| 소스 코드 소유권 | 납품 완료 시 발주사에 귀속되는지 명시 |
| 하자보수 기간 | 납품 후 몇 개월까지 무상 수정 보장 |
특히 소스 코드 소유권은 반드시 확인해야 합니다. 이게 빠져 있으면 나중에 다른 업체로 유지보수를 넘기려 할 때 "소스 못 드립니다"라는 상황이 생길 수 있습니다. 실제로 개발사가 소스를 인질 삼아 유지보수 계약을 강제하는 사례가 있습니다.
✅ 체크리스트 2 — 중간 점검 없는 외주는 믿지 마라
중간 산출물을 요구하는 게 당연한 권리입니다
"완성되면 보여드릴게요"라는 말을 들었다면 주의가 필요합니다. 외주 개발은 공장 라인처럼 마지막에 완성품이 탁 나오는 구조가 아닙니다. 기획 → 디자인 → 개발 → 테스트 각 단계별로 확인하고 피드백을 주고받아야 최종 결과물이 원하는 방향으로 갑니다.
점검 없이 진행된 프로젝트는 막판에 "이건 제가 원하던 게 아닌데요"라는 상황으로 이어질 확률이 높고, 그때 가서 수정하려면 이미 구조 자체를 뜯어고쳐야 하는 경우도 많습니다.
최소한 이 시점에는 중간 확인을 요구하세요
- 기획 완료 시점: 화면 흐름(와이어프레임)과 기능 정의 문서 전달
- 디자인 완료 시점: 실제 화면 시안(피그마 또는 이미지) 공유
- 개발 50% 시점: 스테이징(테스트용 서버)에서 직접 눌러보기
이 세 번의 확인만 제대로 해도 "생각이랑 달라요" 리스크를 크게 줄일 수 있습니다.
✅ 체크리스트 3 — 납품 전 검수, 이렇게 하면 됩니다
"잘 돌아가요"는 검수가 아닙니다
개발사가 "다 됐습니다"라고 하면 대부분의 발주사는 한 번 클릭해보고 "네, 잘 되네요"하고 넘어갑니다. 그런데 실제 사용자가 몰리거나, 특정 조건에서만 쓰는 기능을 건드리면 그때 오류가 터집니다.
납품 전에 아래 항목을 직접 테스트하거나 요청하세요.
기능 검수
- 핵심 기능(결제·로그인·데이터 저장 등)을 실제 데이터로 끝까지 테스트
- 오류 발생 시 어떤 메시지가 뜨는지 확인 (에러 처리 여부)
환경 검수
- 모바일(아이폰·안드로이드)과 PC 브라우저(크롬·사파리·엣지) 각각 확인
- 인터넷이 느린 환경에서도 기본 기능이 동작하는지 확인
소스 및 서버 검수
- 소스 코드를 깃허브 등 형상관리 도구로 넘겨받았는지
- 서버 계정(AWS, 카페24 등)이 발주사 명의로 되어 있는지
- 도메인·SSL 인증서 만료일과 소유자 확인
서버가 개발사 명의로 묶여 있으면 나중에 개발사와 관계가 틀어졌을 때 서비스 자체가 인질이 됩니다. 이것도 계약 전에 발주사 명의로 한다는 조항을 넣는 게 좋습니다.
🏗️ 실무에서 본 케이스 — 왜 DB 이전이 리스크인가
어니스트패밀리가 123타이어 쇼핑몰 리뉴얼을 진행할 때, 기존 레거시 DB를 새 시스템으로 옮기는 작업이 포함되어 있었습니다. 이때 가장 신경 쓴 부분은 무중단 이전 — 즉, 기존 고객의 주문 이력, 차량 정보, 회원 데이터가 단 하나도 유실되지 않으면서 새 서비스로 넘어가는 것이었습니다.
이런 작업은 겉으로 보면 단순해 보이지만, DB 구조가 다르거나 데이터 인코딩이 맞지 않으면 이전 과정에서 데이터가 깨지거나 누락됩니다. 그리고 대부분 계약서에 "DB 이전"이라고만 적혀 있어 발주사 입장에선 무엇을 검수해야 하는지조차 모릅니다.
계약서에 "이전 완료 후 데이터 정합성 검증 보고서 제출"을 명시했다면, 이런 리스크를 훨씬 줄일 수 있습니다. 검증 보고서를 요구하는 것만으로도 개발사 입장에서 함부로 처리할 수 없게 됩니다.
정리 — 3가지만 기억하세요
| 단계 | 핵심 확인 사항 |
|---|---|
| 계약 전 | 기능 범위·일정·소스 소유권·하자보수 계약서에 명시 |
| 진행 중 | 기획·디자인·개발 중간 3회 이상 산출물 직접 확인 |
| 납품 전 | 실데이터 기능 테스트 + 서버·소스 소유권 발주사 명의 확인 |
이 세 가지는 특별한 기술 지식 없이도 누구나 할 수 있는 것들입니다. 그리고 이걸 당연하게 요구할 수 있는 업체라면 그 자체로 신뢰할 만한 파트너에 가깝습니다.
자주 묻는 질문
외주 개발 계약금 비율은 보통 얼마가 적당한가요?
계약금 30%, 중도금 40%, 잔금 30% 구조가 일반적입니다. 계약금이 50% 이상을 요구하는 경우에는 이유를 꼭 확인하세요. 납기 전 계약금 비중이 높을수록 개발사 입장에서 긴장감이 떨어집니다.
소스 코드를 못 받으면 어떻게 되나요?
다른 개발사로 유지보수를 이전할 수 없고, 기능 추가도 기존 업체에 계속 의존해야 합니다. 소스가 없으면 처음부터 다시 만드는 것과 비용이 비슷하게 듭니다. 반드시 계약서에 "납품 완료 시 소스 코드 전체를 발주사에 귀속한다"는 문구를 넣으세요.
크몽·위시켓 같은 플랫폼을 이용하면 더 안전한가요?
플랫폼은 결제 안전장치와 분쟁 중재 창구를 제공하지만, 커뮤니케이션 품질·결과물 수준·일정 준수까지 보장하지는 않습니다. 플랫폼을 통해 계약하더라도 위 체크리스트는 동일하게 적용됩니다.
프로젝트를 진행하려는데 어떤 방식이 맞는지, 계약서에 뭘 넣어야 하는지 아직 감이 잡히지 않는다면 어니스트패밀리에서 무료로 한 번 상담을 받아보시는 것도 방법입니다. 비용 없이 방향 정도는 같이 정리할 수 있습니다. 무료 상담 신청 →