개발 외주 사기, 안 당하는 법 — 계약 전에 거르는 5가지 신호
개발 외주에서 진짜 위험은 대놓고 하는 사기보다, 불투명한 견적·모호한 범위·소유권 누락 같은 구조적 손실입니다. 계약 전에 걸러낼 수 있는 위험 신호 5가지와, 각 신호를 계약서·검수 기준·소스코드 소유권으로 막는 법을 발주자 입장에서 정리했습니다.
"사기"보다 무서운 건 구조적 손실입니다
개발 외주에서 돈 들고 잠적하는 노골적인 사기는 생각보다 드뭅니다. 실제로 발주자가 돈과 시간을 잃는 대부분의 경우는 사기죄로 신고하기도 애매한 회색지대 — 가격이 착수 뒤에 불어나고, "그건 범위에 없었다"는 말이 나오고, 납품받고 보니 소스코드가 내 것이 아니고, 정작 만든 사람은 계약 상대가 아니었던 상황입니다.
이런 손실의 공통점은 특정 업체가 나빠서가 아니라 구조가 허술해서 생긴다는 겁니다. 그래서 좋은 소식은, 이 구조적 위험은 대부분 계약서에 서명하기 전에 신호로 드러난다는 점입니다. 아래 다섯 가지는 착수 전에 확인할 수 있는 위험 신호이고, 각각을 무엇으로 막는지까지 함께 정리했습니다. 하나라도 걸리면 계약을 멈추고 문서부터 요구하세요.
신호 ① 가격을 안 알려주고 "미팅부터" 잡는다
견적을 물었는데 금액 대신 "상담부터 잡으시죠"만 돌아온다면, 착수 전에 예산을 못 잡는다는 뜻입니다. 이 자체가 사기는 아니지만, 가격이 협상 뒤로 미뤄질수록 나중에 추가금과 범위 분쟁이 생길 여지가 커집니다.
막는 법: 유형이 정해진 작업이라면 착수 전에 예상 범위(최소~최대)를 문서로 받으세요. 못 준다면 왜 못 주는지 물어보고, "요구사항이 확정돼야 안다"는 답이면 그 요구사항부터 문서로 정리하는 게 먼저입니다. 가격을 먼저 여는 곳일수록 나중에 말이 바뀔 여지가 적습니다.
신호 ② 범위를 계약서 없이 채팅으로만 말한다
"결제·알림·관리자까지 다 됩니다"를 메신저로만 약속하고 계약서·범위 문서가 없다면, 완료 시점에 "그건 포함이 아니었다"가 나올 확률이 높습니다.
막는 법: 화면 목록과 "포함/불포함"을 첨부 문서로 남기고, 대금은 단계별 분할 지급으로 거세요 — 예를 들어 착수·중간·완료 검수 후로 나눠 지급하면, 한 번에 전액을 잃을 위험이 사라집니다. 계약서에는 범위·기간·하자보수·지연 시 처리를 명시하는 게 기본입니다. 자세한 계약 항목은 외주 계약 분쟁, 이렇게 예방합니다 글에 정리해 뒀습니다.
신호 ③ 소스코드·계정 소유권을 안 넘긴다
납품은 받았는데 소스코드는 업체 서버에만 있고, 배포에 쓰인 계정·도메인·API 키가 전부 업체 명의라면, 유지보수나 업체 교체 시점에 발이 묶입니다. 계속 그 업체에만 의존하게 만드는 구조입니다.
막는 법: 계약서에 "납품물에 소스코드 전체가 포함되고, 운영에 필요한 계정·키는 발주자 명의로 이관한다"를 명시하세요. 이 한 줄이 있고 없고가 나중에 수백만 원짜리 재개발로 갈립니다. 처음 맡기는 경우라면 처음 외주 맡길 때 체크리스트를 같이 보세요.
신호 ④ 인수 기준 없이 "완료됐습니다"만 온다
무엇을 만족해야 "완료"인지 합의하지 않은 채로 완료 통보가 오면, 실제로 내 손님 환경에서 돌아가는지와 무관하게 대금부터 청구됩니다. 데모 화면은 완벽한데 실사용에서 터지는 전형적인 지점입니다.
막는 법: 시작 전에 검수 기준을 못 박으세요 — 실제 데이터로 테스트, 동시 사용·예외 상황 확인, 검수 기간(예: 인수 후 며칠). 검수를 통과해야 잔금이 나가도록 지급 조건과 묶으면, "완료" 선언의 기준이 업체가 아니라 계약서가 됩니다.
신호 ⑤ 재하청·플랫폼 밖 직거래를 유도한다
계약한 상대와 실제로 코드를 짜는 사람이 다르거나(재하청), 재능마켓에서 만났는데 "수수료 아끼게 밖에서 직접 하시죠" 하고 플랫폼 밖 거래를 제안한다면 위험 신호입니다. 재하청은 책임 소재가 흐려지고, 플랫폼 밖 거래는 에스크로(대금 보관) 보호가 사라집니다.
막는 법: "실제 개발 인력이 누구인지, 재하청이 있는지"를 계약 전에 물어보고 계약서에 담으세요. 재능마켓을 쓴다면 결제는 반드시 플랫폼 안에서 하세요 — 외부 직거래를 제안하는 순간 그 플랫폼을 쓰는 이유가 사라집니다. 재능마켓별 안전장치 차이는 크몽 개발 외주 5가지에서 다뤘습니다.
이 신호들을 구조로 없앤다면
위 다섯 신호는 결국 세 가지로 압축됩니다 — 가격이 불투명하다, 범위·소유권이 문서에 없다, 만드는 주체가 불분명하다. 그래서 이 위험을 줄이는 방향도 명확합니다: 가격을 먼저 공개하고, 범위·소스 소유권을 계약에 담고, 중개·재하청 없이 만드는 주체가 분명하면 됩니다.
프리시(freesi.net)는 이 지점을 구조로 풀었습니다. 중개가 아니라 직접 개발이라 재하청이 없고(신호 ⑤), 상품별 가격을 정찰제로 먼저 공개해 착수 전에 예산을 잡을 수 있으며(신호 ①), 계약서에 범위와 소스코드·계정 소유권을 명시합니다(신호 ②③). 물론 어떤 구조도 "모든 사기가 불가능"을 보장하진 못하니, 어디에 맡기든 위 다섯 신호는 직접 확인하세요. 유형과 가격을 먼저 보고 싶다면 정찰제 메뉴판에서, 일하는 방식이 궁금하면 진행 방식에서 확인할 수 있습니다.
두 가지만 고르면 됩니다. 연락처 입력 없음, 범위는 실제 수주가 기준입니다.
