초보자가 위시캣에서 외주 프로젝트 맡기려면 이렇게 시작하세요
얼마 전 지인이 작은 쇼핑몰 리뉴얼을 준비하면서 개발자를 어디서 찾아야 하냐고 물어본 적이 있어요. 주변 소개로만 찾기에는 일정이 애매하고, 검색으로 업체를 찾자니 견적 차이가 너무 커서 판단이 어렵다고 하더라고요. 그때 후보로 나온 곳 중 하나가 위시캣이었습니다.
위시캣은 웹사이트, 앱, 디자인, 개발, 유지보수 같은 IT 외주 프로젝트를 의뢰자와 프리랜서 또는 개발사를 연결해주는 플랫폼으로 많이 알려져 있습니다. 처음 이용하는 입장에서는 “글만 올리면 알아서 잘 되나?” 싶지만, 실제로는 프로젝트를 어떻게 설명하느냐에 따라 제안의 질이 꽤 달라집니다.
위시캣을 쓰기 전에 먼저 정할 것
외주를 맡길 때 가장 먼저 필요한 건 플랫폼 가입이 아니라 내가 원하는 결과물을 말로 설명할 수 있는 상태를 만드는 일입니다. 예를 들어 “쇼핑몰을 만들고 싶다”보다 “카페24 기반 쇼핑몰을 운영 중인데, 모바일 상품 상세 페이지 전환율을 높이기 위해 디자인과 퍼블리싱을 개선하고 싶다”가 훨씬 좋습니다.
프로젝트 설명에는 최소한 목적, 필요한 기능, 참고 사이트, 희망 일정, 예산 범위를 넣는 편이 좋습니다. 예산을 숨기면 더 싸게 받을 수 있을 것 같지만, 사실 괜찮은 파트너는 대략적인 범위가 있어야 투입 가능 여부를 판단합니다. 300만 원짜리 작업인지, 3,000만 원짜리 작업인지에 따라 제안 내용도 완전히 달라지니까요.
- 무엇을 만들지: 웹, 앱, 관리자 페이지, 랜딩페이지 등
- 왜 필요한지: 매출 개선, 업무 자동화, 신규 서비스 검증 등
- 필수 기능: 로그인, 결제, 예약, 알림, 게시판, 통계 등
- 희망 일정: 착수일, 중간 확인일, 오픈 목표일
- 예산 범위: 협의 가능하더라도 대략적인 상한선
프로젝트 등록은 자세할수록 유리합니다
위시캣에 프로젝트를 등록할 때는 짧고 멋진 소개보다 구체적인 조건이 더 중요합니다. 개발자나 업체 입장에서는 “브랜드 감성 있는 앱” 같은 표현보다 “회원가입, 상품 목록, 장바구니, 결제, 주문 내역, 푸시 알림이 필요하다”는 설명이 견적을 내기 쉽습니다.
특히 이미 운영 중인 서비스가 있다면 현재 상황을 적어두는 게 좋습니다. 기존 코드가 있는지, 서버는 어디를 쓰는지, 디자인 파일은 준비되어 있는지, 관리자 계정 제공이 가능한지 같은 내용이죠. 이런 정보가 빠지면 미팅 때 다시 확인해야 하고, 그만큼 일정도 늘어질 수 있습니다.
반대로 아직 아이디어 단계라면 너무 완성된 기획서처럼 꾸미려고 애쓰지 않아도 됩니다. 대신 우선순위를 나눠두면 좋아요. 예를 들어 “1차 오픈에는 회원가입, 예약, 결제까지만 필요하고 리뷰 기능은 이후 고도화에서 추가”라고 적으면 파트너도 현실적인 범위로 제안할 수 있습니다.
제안서를 볼 때 가격만 보면 놓치는 것
위시캣에서 여러 제안을 받으면 자연스럽게 금액부터 보게 됩니다. 그런데 외주는 싼 견적이 항상 좋은 선택은 아닙니다. 500만 원 제안과 800만 원 제안이 있을 때, 후자가 화면 설계, 테스트, 배포, 유지보수 기간까지 포함한다면 실제로는 더 안정적인 선택일 수 있습니다.
제안서를 볼 때는 작업 범위가 어디까지인지 꼭 확인해야 합니다. 디자인 포함인지, 반응형까지 처리하는지, 관리자 페이지가 별도인지, 서버 배포와 도메인 연결이 포함되는지에 따라 비용이 크게 달라집니다. 나중에 “그건 별도입니다”라는 말을 듣지 않으려면 처음부터 범위를 문장으로 남겨두는 게 편합니다.
파트너를 고를 때 보면 좋은 기준
- 비슷한 프로젝트 경험이 있는지
- 제안 내용이 내 요구사항을 제대로 반영했는지
- 일정 산정이 지나치게 짧거나 모호하지 않은지
- 커뮤니케이션 방식이 명확한지
- 수정 횟수와 검수 기준을 설명하는지
솔직히 포트폴리오가 화려해도 내 프로젝트와 맞지 않으면 소용이 적습니다. 쇼핑몰 개선을 맡기는데 대형 게임 앱 포트폴리오만 많은 팀이라면 멋져 보여도 적합도는 다시 따져봐야 합니다. 반대로 규모는 작아도 비슷한 업종의 작업을 여러 번 해본 파트너가 더 빠르게 문제를 이해할 때가 많습니다.
계약 전에는 이 부분을 꼭 확인하세요
외주에서 가장 자주 생기는 갈등은 “당연히 포함된 줄 알았다”에서 시작됩니다. 그래서 계약 전에는 산출물과 검수 기준을 구체적으로 맞춰두는 게 좋습니다. 예를 들어 “디자인 완료”보다 “PC 5개 화면, 모바일 5개 화면을 피그마 파일로 제공”처럼 적어야 서로 같은 그림을 봅니다.
개발 프로젝트라면 소스코드 전달 방식도 중요합니다. Git 저장소를 넘겨받는지, 배포 계정은 누가 소유하는지, 사용한 유료 플러그인이나 외부 API 비용은 누가 부담하는지 확인해야 합니다. 유지보수 기간도 “오픈 후 2주간 버그 수정”처럼 기간과 범위를 분리해서 적는 편이 좋습니다.
- 최종 산출물 형식: 소스코드, 디자인 파일, 기획 문서, 계정 정보
- 검수 기준: 어떤 상태를 완료로 볼지
- 수정 범위: 단순 수정과 기능 추가의 구분
- 지급 조건: 착수금, 중도금, 잔금 기준
- 유지보수: 버그 수정 기간과 추가 비용 기준
처음이라면 작은 범위로 시작하는 게 편합니다
처음 위시캣을 이용한다면 전체 서비스를 한 번에 맡기기보다 작은 단위로 시작하는 방식도 괜찮습니다. 예를 들어 전체 앱 개발 전에 화면 설계나 MVP 개발만 먼저 진행하는 식입니다. 이렇게 하면 파트너의 작업 방식, 응답 속도, 문서화 습관을 실제로 확인할 수 있습니다.
근데 예산이 넉넉하지 않을수록 더 구체적으로 준비해야 합니다. 예산이 작다는 건 나쁜 일이 아니지만, 범위가 흐릿하면 작은 예산 안에서 서로 피곤해지기 쉽습니다. “이번에는 관리자 기능 없이 예약 접수만 가능하면 된다”처럼 덜어낼 것을 정하면 오히려 결과물이 선명해집니다.
위시캣 같은 외주 플랫폼은 좋은 사람을 자동으로 골라주는 마법 도구라기보다, 내가 원하는 일을 더 많은 후보에게 정확히 설명할 수 있게 도와주는 창구에 가깝습니다. 준비가 조금 번거롭더라도 요구사항을 차분히 적어두면 상담 시간도 줄고, 견적 비교도 훨씬 쉬워집니다. 외주는 결국 사람과 사람이 같이 만드는 일이어서, 처음의 설명이 친절할수록 끝의 결과도 편안해지는 것 같아요.
