위시캣으로 개발 외주 맡기려면 이렇게 준비하세요
얼마 전 지인이 작은 쇼핑몰 기능을 고치려고 개발자를 찾다가 꽤 오래 헤맸다는 이야기를 들었습니다. 견적은 사람마다 다르고, 어디까지 맡겨야 하는지도 애매하고, 처음 만나는 개발자에게 비용을 먼저 보내도 되는지 불안하다고 하더라고요. 이런 상황에서 많이 찾는 플랫폼이 위시캣입니다. 정확한 서비스명은 위시켓으로 알려져 있지만, 검색할 때는 위시캣이라고 입력하는 분들도 꽤 많습니다.
위시켓은 IT 프로젝트를 의뢰하는 클라이언트와 개발자, 디자이너, 기획자, 개발 회사를 연결해 주는 매칭 플랫폼입니다. 위시켓 안내 기준으로 10만 개 이상의 기업이 이용했고, 개발 회사 풀과 프리랜서 풀도 함께 갖추고 있어 단순한 구인 게시판보다는 프로젝트 외주에 더 초점이 맞춰져 있습니다.
위시캣을 쓰기 전에 먼저 정해야 할 것
개발 외주를 맡길 때 가장 먼저 해야 할 일은 플랫폼 가입이 아니라 범위를 줄이는 일입니다. 예를 들어 “앱을 만들고 싶다”는 말만으로는 견적을 내기가 어렵습니다. 쇼핑 앱인지, 예약 앱인지, 사내 업무용 앱인지에 따라 필요한 기능과 개발 기간이 완전히 달라집니다.
처음부터 완벽한 기획서를 만들 필요는 없습니다. 대신 아래 4가지는 간단히라도 적어두는 게 좋습니다.
- 무엇을 만들 것인지: 웹사이트, 앱, 관리자 페이지, 업무 시스템 등
- 꼭 필요한 기능: 회원가입, 결제, 예약, 채팅, 알림, 관리자 권한 등
- 예상 예산: 300만 원 이하, 1,000만 원 전후, 3,000만 원 이상처럼 범위라도 정하기
- 희망 일정: 언제 시작해서 언제까지 1차 결과물이 필요한지
사실 이 정도만 정리해도 상담의 질이 꽤 달라집니다. 개발자는 기능 단위로 일을 쪼개서 생각하기 때문에 “예쁜 홈페이지”보다 “회사 소개 5페이지, 문의 폼, 관리자에서 게시글 등록 가능”처럼 말하는 쪽이 훨씬 빠릅니다.
프로젝트 등록은 자세할수록 유리합니다
위시켓에서는 프로젝트를 등록하면 여러 전문가의 제안과 견적을 비교할 수 있습니다. 위시켓이 안내하는 방식도 공고 등록 후 제안서를 받아 비교하는 흐름에 가깝습니다. 여기서 중요한 건 등록 글을 너무 짧게 쓰지 않는 겁니다.
예를 들어 “예약 사이트 개발”이라고만 쓰면 지원자는 안전하게 높은 견적을 부를 가능성이 큽니다. 모르는 부분이 많기 때문입니다. 반대로 “미용실 1곳에서 사용할 예약 사이트, 고객은 날짜와 시간을 선택하고 관리자는 예약 목록을 확인하며, 결제는 1차 버전에서 제외”라고 쓰면 불확실성이 줄어듭니다. 그러면 견적 비교도 훨씬 현실적으로 됩니다.
예산을 숨기는 게 유리하다고 생각하는 분들도 있는데, 외주에서는 꼭 그렇지 않습니다. 예산이 500만 원인데 2,000만 원짜리 기능을 요구하면 서로 시간만 쓰게 됩니다. 차라리 “1차 버전은 500만 원 안에서 핵심 기능만 만들고 싶다”고 말하는 편이 낫습니다.
견적 비교할 때 금액만 보면 위험합니다
외주 견적을 받으면 가장 낮은 금액이 먼저 눈에 들어옵니다. 그런데 개발 외주는 노트북을 사는 것처럼 같은 제품을 놓고 가격만 비교하는 일이 아닙니다. 같은 예약 기능이라도 어떤 사람은 기본 달력만 만들고, 어떤 사람은 관리자 승인, 문자 알림, 중복 예약 방지까지 포함해서 견적을 낼 수 있습니다.
그래서 견적을 볼 때는 금액보다 포함 범위를 먼저 봐야 합니다. 700만 원 견적에는 디자인, 개발, 테스트가 포함되어 있는데 500만 원 견적에는 디자인이 빠져 있다면 실제로는 700만 원 쪽이 더 현실적일 수 있습니다. 특히 유지보수 기간, 수정 횟수, 서버 세팅, 소스코드 전달 여부는 꼭 확인하는 게 좋습니다.
지원자에게 물어보면 좋은 질문
- 비슷한 프로젝트를 해본 경험이 있는지
- 작업 범위에 디자인과 기획 보완이 포함되는지
- 중간 산출물은 어떤 방식으로 확인할 수 있는지
- 완료 후 버그 수정 기간은 얼마나 되는지
- 추가 기능이 생기면 비용을 어떻게 산정하는지
이 질문에 답변이 구체적인 사람일수록 프로젝트 운영 경험이 있을 가능성이 큽니다. 반대로 “다 됩니다”, “금방 됩니다”만 반복한다면 조금 더 확인이 필요합니다. 개발은 가능하다는 말보다 어떻게 진행할지가 더 중요합니다.
클라이언트 입장에서 좋은 진행 방법
위시캣, 즉 위시켓을 클라이언트로 이용한다면 처음부터 큰 프로젝트를 한 번에 맡기기보다 1차 버전을 작게 잡는 편이 실전에서는 더 안정적입니다. 예를 들어 중개 플랫폼을 만들고 싶다면 처음부터 채팅, 결제, 후기, 정산, 추천 알고리즘까지 넣기보다 회원가입, 게시글 등록, 문의 기능 정도로 시작하는 식입니다.
이렇게 하면 예산도 줄고, 개발자와의 호흡도 빠르게 확인할 수 있습니다. 실제 서비스는 만들어 놓고 나서 바뀌는 부분이 많습니다. 처음 생각한 기능보다 사용자가 실제로 원하는 기능이 다를 때도 흔합니다. 그래서 1차 개발에서는 “반드시 있어야 서비스가 굴러가는 기능”만 남기는 판단이 필요합니다.
진행 중에는 말로만 피드백하지 말고 화면 기준으로 남기는 게 좋습니다. “메인 화면 버튼 색을 바꾸고 싶다”보다 “메인 화면 상단의 문의하기 버튼을 파란색에서 검은색으로 변경”처럼 적으면 오해가 줄어듭니다. 수정 요청을 한꺼번에 모아 전달하는 것도 중요합니다. 매일 조금씩 바뀌면 일정이 밀리고, 개발자 입장에서도 작업 흐름이 깨집니다.
프리랜서가 위시캣에서 일감을 찾을 때
반대로 개발자나 디자이너 입장에서 위시캣을 활용한다면 프로필과 포트폴리오가 거의 첫인상입니다. 클라이언트는 코드를 직접 평가하기 어렵기 때문에 비슷한 업종 경험, 결과 화면, 담당 범위, 작업 기간을 보고 판단합니다.
포트폴리오에는 “쇼핑몰 개발”이라고만 쓰기보다 “상품 등록 관리자, 장바구니, 결제 연동, 주문 관리 개발 담당”처럼 본인이 맡은 범위를 적는 게 좋습니다. 팀 프로젝트였다면 본인이 한 부분을 분리해서 보여주는 편이 신뢰를 줍니다.
제안서를 보낼 때도 복사한 문장처럼 보이면 약합니다. 프로젝트 설명을 읽고 “현재 요구사항 기준으로는 관리자 기능 정의가 먼저 필요해 보입니다”처럼 한두 문장만 맞춤형으로 써도 차이가 납니다. 클라이언트는 기술 용어를 많이 아는 사람보다 자기 프로젝트를 이해하려고 한 사람에게 더 마음이 갑니다.
위시캣을 잘 쓰는 방법은 결국 준비의 문제에 가깝습니다. 의뢰자는 만들고 싶은 것을 기능 단위로 쪼개야 하고, 작업자는 할 수 있는 일을 사례 중심으로 보여줘야 합니다. 플랫폼은 만남을 편하게 만들어 주지만, 좋은 결과물은 서로의 기대치를 얼마나 구체적으로 맞추느냐에서 갈립니다. 처음 외주를 맡긴다면 큰 욕심을 조금 덜어내고, 작게 시작해서 검증하는 방식이 훨씬 현실적이라고 느낍니다.
