모두
모두콘텐츠
얼마 전 블로그에 쓰던 작은 도구를 조금 고치고 싶었는데, 주변에 부탁할 개발자가 딱히 없었다. 검색하다가 위시캣을 다시 보게 됐고, 예전에 이름만 들어봤던 IT 외주 플랫폼을 실제로 써보면 어떤 느낌일지 궁금해졌다.
처음엔 그냥 “이런 기능 하나 만들어주세요”라고 올리면 누군가 가격을 말해주고 끝날 줄 알았다. 그런데 막상 프로젝트 등록 화면 앞에 앉으니, 내가 원하는 걸 나도 꽤 흐릿하게 알고 있었다는 걸 알게 됐다. 위시캣을 써본 경험은 플랫폼 후기라기보다, 내 머릿속 요구사항을 꺼내보는 과정에 가까웠다.
위시캣은 어떤 일을 맡길 때 어울렸나
위시캣은 대체로 웹사이트 제작, 앱 개발, 쇼핑몰 기능 개선, 관리자 페이지, 디자인, 유지보수 같은 IT 작업을 의뢰하는 곳에 가깝다. 크몽처럼 아주 작은 단품 서비스를 바로 사는 느낌보다는, 프로젝트 내용을 올리고 지원자를 받아 비교하는 방식이 더 강했다.
내가 느낀 장점은 “개발자 한 명을 어디서 찾지?”라는 막막함을 줄여준다는 점이었다. 지인 소개는 빠를 수 있지만 비교군이 적고, 커뮤니티에 글을 올리면 책임 소재가 흐릴 때가 있다. 반면 위시캣은 프로젝트 설명, 지원자 프로필, 미팅, 계약 같은 흐름이 정해져 있어서 초보 의뢰자 입장에서는 덜 불안했다.
다만 모든 문제를 플랫폼이 대신 해결해주는 건 아니었다. 내가 원하는 기능을 애매하게 쓰면, 지원자도 애매하게 답한다. “예약 시스템을 만들고 싶어요”보다 “사용자가 날짜를 선택하고, 관리자가 승인하면 문자 알림이 가는 구조가 필요해요”처럼 적어야 대화가 빨라졌다.
직접 써보니 제일 중요한 건 예산보다 설명이었다
처음엔 예산을 얼마로 잡아야 할지가 제일 걱정이었다. 30만 원이면 되는지, 300만 원이 필요한지 감이 없었다. 그런데 실제로는 예산보다 먼저 정해야 할 게 있었다. 범위였다.
예를 들어 “홈페이지 수정”이라고 하면 너무 넓다. 메인 화면 문구만 바꾸는 일인지, 예약 기능을 붙이는 일인지, 결제까지 연결하는 일인지에 따라 완전히 다른 작업이 된다. 개발자는 시간으로 일하고, 시간은 범위에서 나온다. 이걸 늦게 깨달으면 견적이 서로 안 맞는다.
프로젝트를 올리기 전에 적어두면 좋았던 것
- 현재 사용 중인 서비스나 제작 방식
- 꼭 필요한 기능과 없어도 되는 기능
- 비슷하게 만들고 싶은 화면의 예시
- 희망 일정과 늦어도 되는 날짜
- 운영자가 직접 수정해야 하는 부분
특히 “꼭 필요한 기능”과 “있으면 좋은 기능”을 나누는 게 생각보다 중요했다. 나는 처음에 작은 기능 몇 개를 한꺼번에 넣고 싶었는데, 미팅을 하다 보니 그중 절반은 나중에 해도 되는 일이었다. 이렇게 나누면 예산도 줄고, 작업자도 우선순위를 이해하기 쉬워진다.
지원자를 볼 때 가격만 보면 좀 위험했다
위시캣에서 지원자가 들어오면 자연스럽게 금액부터 보게 된다. 솔직히 나도 그랬다. 그런데 몇 명의 제안을 읽어보니, 낮은 견적이 항상 좋은 선택은 아니었다. 어떤 사람은 짧게 “가능합니다”만 남겼고, 어떤 사람은 내가 빠뜨린 부분을 짚어주면서 추가 확인이 필요하다고 했다.
나는 후자 쪽에 더 신뢰가 갔다. 왜냐하면 개발 외주는 작업이 시작된 뒤에 몰랐던 변수가 자주 나오기 때문이다. “이건 됩니다”보다 “이건 되지만, 이 경우에는 추가 비용이 생길 수 있습니다”라고 말하는 사람이 오히려 현실적으로 느껴졌다.
프로필을 볼 때는 포트폴리오도 봤지만, 더 유심히 본 건 커뮤니케이션 방식이었다. 답변이 너무 늦지는 않은지, 질문을 구체적으로 하는지, 내가 모르는 말을 쉽게 풀어주는지. 작은 프로젝트일수록 기술력만큼 대화가 중요했다.
위시캣을 쓰기 전에 알아두면 덜 당황하는 점
플랫폼을 이용한다고 해서 의뢰자가 가만히 있어도 되는 건 아니다. 오히려 초반에는 꽤 적극적으로 움직여야 했다. 요구사항을 쓰고, 질문에 답하고, 미팅 시간을 잡고, 견적 범위를 조정해야 한다. 이 과정이 귀찮게 느껴질 수도 있지만, 여기서 대충 넘어가면 뒤에서 더 피곤해진다.
또 하나는 일정이다. “간단한 기능이니까 금방 되겠지”라고 생각하기 쉬운데, 작업자 입장에서는 기존 코드 확인, 환경 세팅, 테스트, 수정 요청 반영까지 시간이 든다. 내가 보기엔 버튼 하나 추가하는 일이어도, 실제로는 관리자 화면과 사용자 화면을 같이 만져야 할 수 있다.
그래서 일정은 조금 여유 있게 잡는 편이 낫다. 특히 쇼핑몰, 예약, 결제, 회원 정보처럼 돈이나 개인정보가 얽힌 기능은 테스트 시간이 필요하다. 빨리 끝내는 것보다 문제 없이 굴러가는 게 더 중요했다.
내가 다시 쓴다면 이렇게 올릴 것 같다
다시 위시캣에 프로젝트를 올린다면 제목부터 더 구체적으로 쓸 것 같다. “웹사이트 기능 개발”보다는 “기존 워드프레스 사이트에 예약 신청 폼과 관리자 확인 기능 추가”처럼 쓰는 식이다. 제목이 구체적이면 지원자도 대략적인 난이도를 빨리 판단할 수 있다.
본문에는 배경 설명을 길게 쓰기보다, 현재 상태와 원하는 상태를 나눠 적을 것 같다. 지금은 어떤 문제가 있고, 작업 후에는 사용자가 어떤 행동을 할 수 있어야 하는지 적는 방식이다. 화면 흐름을 번호로 써두면 더 좋았다.
- 사용자가 신청서를 작성한다
- 관리자는 관리자 화면에서 신청 내역을 확인한다
- 승인하면 사용자에게 안내 메시지가 간다
- 관리자는 신청 내역을 엑셀로 내려받을 수 있다
이 정도만 적어도 대화가 훨씬 구체적으로 시작된다. 작업자가 “문자 발송은 어떤 서비스를 쓰나요?” “엑셀 항목은 무엇이 필요하나요?”처럼 바로 다음 질문을 할 수 있기 때문이다.
위시캣은 개발자를 대신 골라주는 마법 같은 곳이라기보다, 의뢰자와 작업자가 서로 덜 헤매게 해주는 장치에 가까웠다. 그래서 준비 없이 들어가면 생각보다 어렵고, 반대로 내가 원하는 것을 조금만 구체화해두면 꽤 실용적이다. 작은 외주라도 결국 사람과 사람이 맞춰가는 일이라서, 플랫폼보다 먼저 내 요구사항을 또렷하게 만드는 게 제일 큰 숙제처럼 느껴졌다.
