위시캣으로 개발 외주 맡기려면 이렇게 준비하세요
얼마 전 지인이 작은 쇼핑몰 기능을 고치려고 개발자를 찾다가 생각보다 많이 헤매는 걸 봤습니다. 견적은 제각각이고, 어떤 사람에게 맡겨야 할지도 모르겠고, 요구사항을 어디까지 적어야 하는지도 애매하다고 하더라고요. 그럴 때 많이 찾는 서비스 중 하나가 위시캣입니다. 개발, 디자인, 기획 같은 IT 프로젝트를 의뢰자와 프리랜서 또는 개발사를 연결해 주는 플랫폼이라 처음 외주를 맡기는 사람도 비교적 구조를 잡기 쉽습니다.
그런데 플랫폼을 쓴다고 해서 프로젝트가 자동으로 잘 굴러가지는 않습니다. 같은 예산이라도 의뢰서가 구체적이면 좋은 파트너를 만날 확률이 올라가고, 반대로 설명이 흐릿하면 견적도 흔들리고 일정도 길어질 수 있습니다. 위시캣을 제대로 쓰려면 ‘사람을 찾는 일’보다 먼저 ‘내가 무엇을 맡기려는지 설명하는 일’이 중요합니다.
위시캣 의뢰 전 먼저 정해야 할 것
가장 먼저 할 일은 만들고 싶은 결과물을 한 문장으로 말해보는 겁니다. 예를 들어 “예약 기능이 있는 병원 홈페이지를 만들고 싶다”, “기존 쇼핑몰에 정기결제 기능을 붙이고 싶다”, “사내에서 쓰는 엑셀 업무를 웹 시스템으로 바꾸고 싶다”처럼요. 이 문장이 흐릿하면 이후 대화도 계속 흐릿해집니다.
그다음에는 범위를 나눠보면 좋습니다. 꼭 필요한 기능, 있으면 좋은 기능, 나중에 해도 되는 기능을 구분하는 방식입니다. 실제 외주에서는 이 구분이 예산과 일정을 크게 좌우합니다. 예를 들어 회원가입, 상품 등록, 결제, 관리자 페이지가 모두 필요한 쇼핑몰과 단순 홍보용 홈페이지는 작업량이 완전히 다릅니다. 겉으로는 둘 다 “웹사이트 제작”이지만 필요한 기술과 시간이 달라집니다.
- 필수 기능: 없으면 서비스가 작동하지 않는 기능
- 선택 기능: 편의성은 높지만 나중에 추가해도 되는 기능
예산도 너무 두루뭉술하게 잡기보다 범위를 정해두는 편이 낫습니다. “최대한 저렴하게”보다는 “초기 버전은 300만 원 안팎으로 보고 있고, 핵심 기능부터 만들고 싶다”처럼 말하면 대화가 훨씬 현실적으로 흘러갑니다.
프로젝트 등록 글을 쓰는 방법
위시캣에서 프로젝트를 등록할 때는 의뢰서가 첫인상입니다. 파트너 입장에서는 그 글을 보고 일정, 난이도, 리스크를 가늠합니다. 그래서 멋진 문장보다 구체적인 정보가 더 중요합니다. 특히 현재 상태, 원하는 결과, 필요한 기능, 희망 일정, 예산 범위는 빠지지 않는 게 좋습니다.
예를 들어 “앱을 만들고 싶습니다”라고만 쓰면 견적을 내기 어렵습니다. 반면 “운동 기록 앱을 만들고 싶고, 사용자는 로그인 후 운동 날짜, 종목, 무게, 횟수를 입력합니다. 첫 버전은 iOS와 안드로이드 중 하나만 고려하고 있으며, 관리자 기능은 필요 없습니다”라고 쓰면 훨씬 선명합니다. 이 정도만 적어도 파트너가 질문할 지점이 줄어듭니다.
의뢰서에 넣으면 좋은 항목
- 현재 상황: 새로 만드는지, 기존 서비스 수정인지
- 목표 사용자: 고객용인지, 내부 직원용인지
- 주요 기능: 화면 단위나 업무 흐름 기준으로 작성
- 희망 일정: 시작 가능일과 완료 희망일
- 준비된 자료: 기획서, 디자인, 참고 화면, 계정 정보 여부
솔직히 처음부터 완벽한 기획서를 만들 필요는 없습니다. 다만 “이런 느낌”만 적어두면 서로 상상하는 그림이 달라질 수 있습니다. 화면 스케치가 없다면 종이에 그린 사진도 괜찮고, 엑셀에 메뉴와 기능을 적어둔 자료도 충분히 쓸모가 있습니다.
지원자를 고를 때 보는 기준
위시캣에서는 여러 파트너의 제안서를 받아볼 수 있습니다. 이때 금액만 보고 고르면 아쉬운 상황이 생길 수 있습니다. 낮은 견적이 나쁜 건 아니지만, 왜 그 금액이 가능한지 설명이 있어야 합니다. 반대로 높은 견적도 마찬가지입니다. 비용이 높은 이유가 인력 구성, 유지보수, 품질관리, 테스트 범위와 연결되어 있다면 비교할 만합니다.
좋은 제안서는 보통 의뢰 내용을 제대로 읽은 흔적이 있습니다. “가능합니다” 한 줄보다, 예상 작업 순서와 확인이 필요한 부분을 짚어주는 제안이 믿음이 갑니다. 예를 들어 결제 기능이 있다면 PG 연동 방식, 심사 기간, 테스트 계정 필요 여부를 물어보는 식입니다. 이런 질문은 귀찮은 게 아니라 프로젝트를 덜 흔들리게 만드는 과정입니다.
- 비슷한 프로젝트 경험이 있는지
- 작업 범위와 제외 범위를 명확히 말하는지
- 일정 산정 방식이 현실적인지
- 커뮤니케이션 속도와 설명 방식이 잘 맞는지
- 수정 요청과 유지보수 기준을 미리 안내하는지
근데 여기서 중요한 게 하나 있습니다. 포트폴리오가 화려해도 내 프로젝트와 성격이 다르면 기대한 만큼 맞지 않을 수 있습니다. 쇼핑몰 구축 경험이 많은 팀과 사내 업무 자동화 경험이 많은 팀은 잘하는 지점이 다릅니다. 내 프로젝트와 닮은 경험이 있는지를 보는 게 더 실용적입니다.
계약 전에 꼭 맞춰볼 대화
계약 전에는 작업 범위와 산출물을 꼭 확인해야 합니다. 산출물은 단순히 “완성된 사이트”만 뜻하지 않습니다. 소스코드 전달 여부, 관리자 계정, 서버 정보, 디자인 원본, 매뉴얼, 테스트 결과 같은 것들이 포함될 수 있습니다. 나중에 운영하거나 다른 개발자에게 넘길 때 꽤 큰 차이를 만듭니다.
일정도 “한 달 안에 완료”처럼 말하기보다 단계별로 나누는 편이 좋습니다. 예를 들어 1주 차 요구사항 확정, 2~3주 차 개발, 4주 차 테스트와 수정처럼 잡으면 중간에 상태를 확인하기 쉽습니다. 프로젝트가 2개월 이상으로 길어질 때는 중간 검수일을 정해두는 게 특히 유용합니다.
수정 범위도 미리 이야기해야 합니다. 오타 수정이나 색상 변경 같은 단순 수정과 기능 자체를 바꾸는 변경은 성격이 다릅니다. “회원가입에 휴대폰 인증을 추가하고 싶다”는 새 기능에 가깝고, “버튼 문구를 바꾸고 싶다”는 단순 수정에 가깝습니다. 이런 기준을 초반에 맞춰두면 서로 감정 상할 일이 줄어듭니다.
위시캣을 더 편하게 쓰는 작은 요령
위시캣 같은 플랫폼의 장점은 여러 후보를 한곳에서 비교하고, 프로젝트 진행 절차를 어느 정도 틀 안에서 관리할 수 있다는 점입니다. 하지만 결국 결과물의 품질은 의뢰자와 파트너가 얼마나 같은 그림을 보고 있느냐에 달려 있습니다. 그래서 대화 기록을 남기고, 중요한 결정은 말로만 넘기지 않는 습관이 꽤 중요합니다.
처음 외주를 맡긴다면 큰 프로젝트를 한 번에 모두 맡기기보다 1차 버전을 작게 잡는 것도 방법입니다. 예를 들어 전체 서비스를 처음부터 완성하려 하기보다 회원 관리와 핵심 화면부터 만들고, 이후 결제나 통계 기능을 추가하는 식입니다. 이렇게 하면 예산 부담도 줄고, 실제 사용자의 반응을 보면서 다음 개발 방향을 잡을 수 있습니다.
개발 외주는 돈을 내고 맡기는 일이지만, 완전히 손을 놓는 일은 아닙니다. 의뢰자가 방향을 또렷하게 잡아줄수록 파트너도 더 좋은 선택을 할 수 있습니다. 위시캣을 사용할 때도 결국 시작점은 좋은 의뢰서와 현실적인 대화입니다. 그 두 가지만 챙겨도 처음보다 훨씬 덜 막막하게 프로젝트를 굴릴 수 있습니다.
