위시켓에서 외주 개발사 고르기 전에 알아야 할 것

한줄 요약

위시켓은 진입이 쉬운 만큼 함정도 많다. 저가 견적과 구조적 한계를 이해하고 들어가야 한다.

---

위시켓에서 외주 개발사를 고른다는 건, 플랫폼의 구조적 특성을 이해하지 않으면 높은 확률로 실패한다는 뜻이기도 하다. 이 글은 플랫폼을 비난하는 게 아니다. 수십 번의 미팅과 계약을 직접 경험한 개발사 입장에서, 클라이언트가 알고 있어야 할 현실을 있는 그대로 쓴 것이다.

위시켓, 왜 다들 여기서 시작하나

외주 개발을 처음 알아보는 클라이언트 대부분이 위시켓부터 찾는다. 이유는 단순하다. 접근하기 쉽고, 프로젝트를 올리면 여러 업체가 알아서 지원해온다. 비교도 되고, 견적도 바로 받아볼 수 있다.

개발사 입장에서도 위시켓 진입 장벽은 낮다. 덕분에 이제 막 시작한 1인 프리랜서부터 소규모 팀, 중견 에이전시까지 폭넓게 섞여 있다. 문제는 이 '폭넓음' 자체가 클라이언트에게 혼란을 준다는 것이다. 포트폴리오만 보고는 역량 차이를 가늠하기 어렵고, 결국 가장 눈에 띄는 기준인 '가격'으로 선택하게 된다.

낮은 견적에 혹하면 어떻게 되나

경쟁이 치열한 플랫폼에서는 수주가 절박한 쪽이 더 낮은 가격을 제시한다. 이건 위시켓만의 문제가 아니라 어느 경쟁 플랫폼에서나 발생하는 구조적 현상이다. 문제는 소프트웨어 개발이라는 업종 자체가 일일 단가가 높은 영역이라는 것이다. 숙련된 개발자 한 명의 하루 인건비만 해도 상당하다. 그 현실과 플랫폼에 올라온 견적 사이에는 종종 설명이 안 되는 간격이 있다.

집에 비유하면 이렇다. 반지하도 집이고, 50층 주상복합도 집이다. 둘 다 '집'이라는 단어를 쓰지만 가격과 완성도는 전혀 다르다. 반지하 예산을 들고 와서 대리석 바닥 50평 아파트를 원하면 누구도 그걸 만들어줄 수 없다. 그런데 현실에서는 천만 원이 필요한 요구사항을 200~300만 원에 해결하려는 클라이언트가 생각보다 흔하다.

낮은 금액으로 계약이 성사되면 어떻게 되나. 개발사는 그 예산 안에서 할 수 있는 것만 한다. 중간에 요구사항이 늘면 추가 비용을 요청하거나, 감당이 안 되면 품질을 타협한다. 결국 클라이언트는 돈도 쓰고, 시간도 쓰고, 결과물도 만족스럽지 않은 상황에 놓인다.

수수료 구조가 만든 역설

2026년 들어 위시켓의 수수료 정책이 크게 바뀌었다. 플랫폼 입장에서 수익 구조를 조정하는 건 자연스러운 일이지만, 그 여파가 어떻게 작용하는지는 짚어볼 필요가 있다.

수수료가 오르면 개발사 입장에서는 두 가지 선택지가 생긴다. 수수료를 감안해 견적을 올리거나, 견적은 그대로 두되 어딘가에서 비용을 줄이는 것이다. 전자는 클라이언트 입장에서 수주 경쟁력이 낮아지고, 후자는 결과물의 품질이 타협되는 방향으로 이어질 수 있다. 수주 경쟁이 치열한 플랫폼 특성상 견적을 크게 올리기 어렵기 때문에, 현실에서는 후자의 방향으로 가는 경우도 적지 않다.

한 가지 오해는 짚고 넘어가야 한다. 수수료가 반영된다고 해서 위시켓을 통한 계약이 시장 단가보다 비싸다는 의미는 아니다. 직접 수주와 플랫폼 수주를 모두 경험해보면 오히려 위시켓에서 형성되는 단가가 시장 평균이거나 더 낮은 경우가 많다. 경쟁 구조 자체가 가격을 아래로 누르는 방향으로 작동하기 때문이다. 문제는 단가가 낮은 게 아니라, 그 낮은 단가 안에서 질까지 타협되는 상황이 발생한다는 데 있다.

"나도 개발 좀 아는데" — 돌아볼 필요가 있는 지점

AI 도구가 보편화되면서 비개발자도 개발에 대한 정보를 쉽게 얻을 수 있게 됐다. 이건 분명 긍정적인 변화다. 문제는 그 정보가 깊이 없이 소비될 때다.

"이 기능은 API 연동이면 하루면 되는 거 아닌가요?" 같은 질문이 미팅에서 나오기 시작했다. 개념은 맞다. 하지만 실제 구현에는 예외 처리, 보안, 서버 설계, 테스트, 배포, 유지보수 고려가 전부 들어간다. 하루짜리 작업처럼 보이는 것이 실제로는 2주짜리인 경우가 많다.

이 간극을 인식하지 못한 채로 개발사의 일정과 견적에 의문을 품게 되면, 자연스럽게 신뢰가 무너지는 방향으로 흘러간다. B2B 계약이지만 결국 사람이 하는 일이다. 관계가 소모적으로 흘러가면 최선의 결과물이 나오기 어렵다. 이건 어느 한쪽을 탓하는 얘기가 아니라, 그런 구조가 만들어지지 않도록 서로가 신경 써야 한다는 뜻이다.

이 지점에서 개발사의 역할도 중요하다. 클라이언트가 개발을 모르는 건 당연한 일이다. 좋은 개발사라면 "왜 이게 2주냐"는 질문에 방어적으로 반응하는 대신, 비개발자의 눈높이에 맞게 근거를 설명할 수 있어야 한다. 솔직하고 명확한 소통이 오해를 줄이고, 결과적으로 프로젝트의 완성도를 높인다.

개발사와의 관계, 어떻게 접근해야 하나

계약 구조상 개발사가 을인 건 맞다. 하지만 일방적인 관계 설정이 결과물에 영향을 미친다는 점은 돌아볼 필요가 있다. 요구사항은 계속 추가되고, 일정은 당겨지고, 소통은 일방적인 방향으로 흘러갈 때 프로젝트가 잘 마무리되는 경우는 드물다.

개발이라는 작업은 창의적 판단이 끊임없이 개입되는 업무다. 명세서에 없는 결정을 개발자가 하루에도 수십 번 한다. 그 판단들이 프로젝트의 완성도를 좌우한다. 관계가 소모적이고 감정적으로 불편하면, 그 판단들이 최소한의 수준에서 이루어지게 된다. 이건 태도의 문제가 아니라 인간의 기본적인 심리다.

좋은 결과물을 원한다면, 개발사를 비즈니스 목적을 함께 달성하는 파트너로 보는 관점이 도움이 된다. 모르면 모른다고 하고, 같이 맞춰가는 과정이 필요하다. 개발사 역시 단순히 일감을 처리하는 게 아니라 고객 비즈니스의 성공을 돕는 관점이어야 한다. 실력만큼이나 소통이 중요한 이유가 여기에 있다. 비개발자와 개발 전문가 사이의 눈높이를 맞추고, 불확실한 부분을 솔직하게 드러내며 대화할 수 있는 개발사가 결국 더 나은 결과물을 만들어낸다.

그래서, 외주 개발 파트너를 고르는 기준은

위시켓을 통하든, 직접 섭외하든 기준은 같다.

첫째, 견적서보다 질문의 질을 봐라. 좋은 개발사는 요구사항을 받은 후 단순히 견적을 내리기 전에 비즈니스 목적, 사용자 구조, 운영 계획을 묻는다. 그 질문들이 촘촘할수록 실력 있는 곳일 확률이 높다.

둘째, 설명 방식을 봐라. 기술적인 내용을 비개발자가 이해할 수 있게 풀어서 설명하는지 확인하라. 전문 용어로만 답하거나, 질문 자체를 불편해하는 곳이라면 협업 과정에서 소통 문제가 반복될 가능성이 높다.

셋째, 계약 전 소통 속도와 태도를 봐라. 미팅 전 이메일 응답, 질문에 대한 답변 방식, 명세서 작성 수준이 계약 이후 협업의 질을 예고한다.

넷째, 예산에 맞는 요구사항을 세팅하라. 개발사를 탓하기 전에 내 예산으로 내가 원하는 걸 만들 수 있는지를 먼저 검증해야 한다. 이게 잘못 세팅된 상태로 계약하면 누구도 만족스럽지 않다.

삼태연구소는 이 기준을 개발사 입장에서도 동일하게 적용한다. 파트너로 일하되, 정해진 예산 대비 무리한 요구에는 분명하게 선을 긋는다. 그게 결과적으로 양쪽 모두에게 더 나은 프로젝트로 이어진다는 걸 수십 건의 계약을 통해 확인했다.