외주 개발사 고르는 법은 포트폴리오 비교가 아닙니다. 상담 방식, 설계 문서, 진행 대시보드가 진짜 실력을 보여줍니다.
외주 개발사를 고르려고 검색한다. 크몽, 숨고, 에이전시 리스트. 포트폴리오를 본다. 다 비슷하게 생겼다. 깔끔하다. 반응형이다. "이 정도면 되겠지."
하지만 포트폴리오는 완성된 결과물만 보여준다. 과정은 안 보인다. 과정이 결과를 결정한다.
기준 1: 첫 질문이 뭔가
나쁜 신호: "어떤 페이지를 만들어드릴까요?" "참고 사이트 있으세요?" "디자인 시안 보여드릴까요?"
이 질문은 "뭘 만들어달라고 하세요, 만들어드릴게요"라는 뜻이다. 사장님이 뭘 만들어야 하는지 알고 있다는 전제다. 대부분은 모른다.
좋은 신호: "이 홈페이지로 뭘 하고 싶으세요?" "고객이 누구인가요?" "지금 매출에서 가장 큰 병목이 뭔가요?"
비즈니스를 먼저 이해하려는 질문이다. 비즈니스 설계 없이 개발하면 벌어지는 일에서 이야기한 것처럼, 설계가 없으면 결과물이 작동하지 않는다.
기준 2: 설계 단계가 있는가
개발 전에 설계 단계가 별도로 있는가. 와이어프레임, 유저 플로우, 정보 구조. 이런 단계 없이 바로 디자인 시안으로 들어가는 곳은 피한다.
설계 없이 만들면 "예쁘지만 안 되는" 결과가 나온다. 수정하려면 처음부터 다시 해야 한다.
기준 3: 구축 후에 뭘 해주는가
대부분의 외주는 "완성 → 인수인계 → 끝"이다. 그 후에 수정이 필요하면 추가 비용이다. 트래킹은 없다. 성과 분석은 없다. 만들고 끝이다.
외주 맡기고 나서 사장님이 해야 할 일에서 이야기한 것처럼, 구축 후 운영이 진짜 시작이다. 운영까지 지원하는 곳인지 확인한다.
기준 4: 비용 구조가 투명한가
"상담 후 견적 안내"만 있는 곳은 주의한다. 상담해야 가격을 알 수 있다는 건, 같은 작업이라도 사람마다 가격이 다를 수 있다는 뜻이다.
가격 범위를 공개하는 곳이 낫다. 최소한 "이 정도 규모면 이 정도 비용"이 미리 보여야 한다.
기준 5: 자기 제품이 있는가
자기 서비스를 직접 만들어서 운영하는 개발사와, 외주만 하는 개발사는 다르다.
자기 제품이 있으면 "사용자 경험"을 알고 있다. 만드는 것과 쓰는 것의 차이를 체감하고 있다. 외주만 하는 곳은 "클라이언트가 원하는 대로 만들어주는 것"이 목표다. 자기 제품이 있는 곳은 "사용자에게 작동하는 것"이 목표다.
이 웹사이트, 3일 만에 만들었다에서 이야기한 도그푸딩이 이것이다. 자기가 만든 걸 자기가 쓰는 회사는 품질에 대한 기준이 다르다.
요약
- 첫 질문이 비즈니스 이해인가
- 설계 단계가 별도로 있는가
- 구축 후 운영 지원이 있는가
- 비용 구조가 투명한가
- 자기 제품이 있는가
5개 중 3개 이상이면 괜찮은 곳이다. 1개 이하면 포트폴리오가 아무리 좋아도 다시 생각한다.
견적서보다 진행 방식 샘플을 보자
외주 개발사를 고를 때 견적서만 받으면 부족하다. 견적서는 결과만 말한다. 실제로 중요한 것은 진행 방식이다. 요구사항을 어떻게 정리하는지, 결정사항을 어디에 남기는지, 자료 요청을 어떻게 하는지, 검수 기준을 어떻게 공유하는지 봐야 한다.
가능하다면 샘플 문서를 요청해보자. 과업정의서, 화면 설계서, 프로젝트 진행 보드, 클라이언트 대시보드 예시가 있으면 좋다. 문서가 있는 회사는 일을 구조화할 가능성이 높다. 문서가 없고 카톡으로만 진행하는 회사는 담당자 기억에 프로젝트가 걸린다.
카톡이 나쁘다는 뜻은 아니다. 하지만 카톡은 결정사항을 보관하기 어렵다. 파일, 일정, 검수 기준, 요청사항이 흩어진다. 프로젝트가 길어질수록 이 흩어짐은 비용이 된다.
클라이언트 대시보드가 있는지 확인하자
좋은 외주사는 진행 상황을 숨기지 않는다. 지금 어떤 문서가 확정됐고, 어떤 화면이 개발 중이고, 어떤 자료가 필요한지 클라이언트가 볼 수 있어야 한다. 사장님이 매번 "지금 어디까지 됐나요?"라고 물어봐야 한다면 이미 소통 비용이 생긴 것이다.
클라이언트 대시보드는 단순 보기 좋은 기능이 아니다. 프로젝트의 불안을 줄이는 장치다. 견적서, 계약서, 과업정의서, 요청 확인, 검수 기준이 한 곳에 있으면 프로젝트가 흔들릴 가능성이 줄어든다.
studio.bth가 클라이언트 대시보드를 쓰는 이유도 여기에 있다. 말로만 진행하지 않고, 문서와 상태와 요청을 같이 남긴다. 외주 개발은 신뢰가 중요한데, 신뢰는 친절한 말보다 투명한 진행에서 나온다.
사후 운영 기준까지 물어보자
외주 개발은 런칭으로 끝나지 않는다. 버그 수정, 운영 문의, 작은 수정, 기능 추가 요청이 반드시 생긴다. 이때 무엇이 무상 수정이고, 무엇이 추가 과업인지 기준이 없으면 관계가 금방 불편해진다.
계약 전에 물어봐야 한다. 검수 기간은 며칠인지, 런칭 후 버그는 어떻게 처리하는지, 텍스트 수정과 기능 변경을 어떻게 구분하는지, 월 운영비가 있는지. 이 질문을 불편해하는 업체라면 조심해야 한다. 좋은 업체는 이런 기준을 오히려 먼저 정리한다.
홈페이지 외주 실패 체크리스트와 같이 보면 계약 전 확인해야 할 신호가 더 구체적으로 보인다. 업무 자동화 견적도 연결된다. 기능보다 범위와 반복 비용을 먼저 봐야 한다는 점은 외주 개발에서도 똑같다.
같이 읽으면 이어지는 글
- 크몽 외주 300만원 vs 올인원 300만원: 단건 외주와 통합 설계의 차이를 본다.
- 홈페이지 리뉴얼 비용: 가격 차이를 구조로 보는 글이다.
- 개발보다 설계가 먼저인 이유: 외주 개발 전에 설계가 필요한 이유다.
- 외주 맡기고 나서 사장님이 해야 할 일: 계약 후 사장님이 준비해야 할 자료를 정리했다.