외주 개발사는 정해진 범위 안에서 결과물을 만드는 데 강합니다. 반면 방향을 자주 바꾸며 수년간 운영할 서비스라면 내부 팀이 더 맞을 수 있습니다.

시장 반응을 보려는 MVP인지, 바로 운영에 들어갈 정식 서비스인지, 기존 제품에 기능을 추가하는 건지 먼저 구분하세요. 목적이 달라지면 필요한 인력 구성과 계약 방식도 달라집니다.

💡 "목적이 다르면 같은 기획서라도 견적이 수천만 원 차이 납니다."

같은 기획서에 2천만 원짜리와 1억 원짜리 견적이 나오면 평균값을 구해봐야 의미가 없습니다. 한쪽은 핵심 기능만 담았고, 다른 쪽은 관리자 페이지와 예외 처리까지 포함한 경우가 대부분이거든요.

맨먼스(한 사람이 한 달간 투입되는 업무량)와 역할별 투입 기간을 반드시 요청하세요. 개발자 4명이 두 달간 전담하는데 총액이 지나치게 낮다면, 경력 구성이나 동시 진행 프로젝트 수를 따져봐야 합니다.

💡 "업체는 그 가격이 가능한 운영 구조를 설명할 수 있어야 합니다."

AI로 만든 목업은 완성도가 높아 보여도, 그 팀이 실제로 데이터베이스 설계, 결제 연동, 권한 관리까지 수행했는지 화면만으로는 알 수 없습니다. 앱스토어 등록 정보나 접속 주소를 직접 확인하세요.

전체 프로젝트 수보다 중요한 건, 우리 서비스의 핵심 기능을 구현한 경험이 있느냐입니다. 예약, 정산, 외부 서비스 연동 같은 기능은 유사 경험을 가진 담당자가 이번 프로젝트에 직접 참여하는지 꼭 확인해야 합니다.

💡 "같은 업종 클라이언트가 있다는 것과, 그 담당자가 우리 프로젝트에 들어오는 건 다른 이야기입니다."

계약 전에 사무실을 방문하거나 실제 참여자와 화상 미팅을 하세요. 영업 담당자와의 대화만으로는 개발 조직이 어떻게 구성되어 있는지 파악하기 어렵습니다.

누가 요구사항을 정리하고, 진척 상황을 어떤 주기로 공유하는지 물어보세요. 테스트 책임 소재와 담당자 교체 시 인수인계 절차도 확인해야 합니다. 답변이 구체적일수록 협업 과정을 미리 그려볼 수 있습니다.

💡 "값이 싸도 관리에 들어가는 시간까지 합산하면 오히려 비용이 늘어날 수 있습니다."