외주 개발사를 고르는 건 생각보다 어렵습니다. 검색하면 수백 개의 업체가 나오고, 다들 "최고의 품질", "합리적인 가격"을 이야기합니다. 포트폴리오도 그럴듯해 보입니다. 그런데 막상 계약하면 결과가 기대와 다른 경우가 적지 않습니다.

가장 비싼 곳이 최고가 아니고, 가장 싼 곳이 최악도 아닙니다. 가격 외에 봐야 할 것들이 있습니다. 실제 프로젝트 경험을 바탕으로, 개발사를 고를 때 확인해야 할 기준을 정리합니다.

포트폴리오: 양보다 질

포트폴리오 페이지에 수십 개의 프로젝트가 나열되어 있으면 믿음이 가기도 합니다. 하지만 숫자는 중요하지 않습니다.

확인해야 할 것:

• 내 프로젝트와 비슷한 유형(앱, 웹, 관리자 시스템 등)을 해본 적이 있는가
• 포트폴리오에 있는 서비스가 현재도 운영 중인가 (만들어놓고 방치된 건 아닌가)
• "만들었다"가 아니라 "어떤 문제를 어떻게 해결했는지"를 설명할 수 있는가

포트폴리오가 10개인데 전부 운영 중인 서비스라면, 100개인데 절반이 링크가 깨진 곳보다 낫습니다. 결과물이 살아있다는 것은 납품 후에도 관리가 되었다는 의미이기 때문입니다.

"저희가 이 프로젝트에서 가장 고민한 부분은 이거였고, 이렇게 풀었습니다." 이런 설명이 나오는 개발사는 실제로 그 프로젝트를 깊이 있게 수행한 곳입니다.

커뮤니케이션: 응답 속도와 선제적 공유

개발 실력만큼 중요한 게 소통입니다. 아무리 잘 만들어도 소통이 안 되면 원하는 결과물이 나오지 않습니다.

확인해야 할 것:

• 문의에 대한 응답이 얼마나 빠른가 (계약 전 소통 속도가 계약 후에도 유지되는지)
• 클라이언트가 물어보기 전에 먼저 공유하는가 (진행 상황, 이슈, 일정 변동)
• 기술적인 내용을 비개발자가 이해할 수 있게 설명하는가

계약 전 상담 단계에서 답변이 하루 이상 걸리면, 프로젝트 진행 중에는 더 느려질 가능성이 높습니다. 반대로, 상담 단계에서부터 "이 부분은 이런 리스크가 있습니다"라고 먼저 짚어주는 곳은, 프로젝트 중간에도 문제를 선제적으로 공유할 확률이 높습니다.

좋은 개발사는 클라이언트가 불안해지기 전에 먼저 이야기합니다.

계약 조건: 소스코드와 사후 지원

계약서를 꼼꼼히 보는 분이 의외로 많지 않습니다. 하지만 나중에 문제가 되는 건 대부분 계약서에 명시되지 않은 부분입니다.

반드시 확인해야 할 것:

• 소스코드 소유권: 납품 후 소스코드를 전부 받을 수 있는가. "저작권은 개발사에 귀속"이라는 조항이 있으면, 나중에 다른 개발사로 이전이 불가능할 수 있습니다.
• 사후 지원: 납품 후 버그 수정 기간이 명시되어 있는가. "무상 1개월"과 "무상 3개월"은 큰 차이입니다.
• 추가 비용 기준: 어디까지가 원래 범위이고, 어디부터 추가 비용인지 명확한가.
• 중도 해지 조건: 프로젝트를 중간에 중단하면 어떻게 되는가.

계약서가 모호하면, 나중에 해석의 차이로 갈등이 생깁니다. 좋은 개발사는 이런 조건을 먼저 명확하게 정리해줍니다. 클라이언트가 물어보기 전에요.

기술 스택: 하나만 고집하지 않는가

"저희는 모든 프로젝트를 OO으로 합니다."

이 말은 두 가지로 해석됩니다. 해당 기술에 깊은 전문성이 있거나, 다른 기술을 할 줄 모르거나. 후자인 경우가 더 많습니다.

확인해야 할 것:

• 기술 선택의 근거를 설명할 수 있는가 ("이 프로젝트에는 이 기술이 적합한 이유는...")
• 프로젝트 특성에 따라 다른 기술을 제안한 경험이 있는가
• 클라이언트가 특정 기술을 요청했을 때, 무조건 수용하지 않고 더 나은 대안을 제시할 수 있는가

검색엔진 노출이 중요한 서비스에 네이티브 앱을 권하거나, 간단한 랜딩페이지에 과도한 프레임워크를 제안하는 곳은 클라이언트의 비즈니스보다 자기네 기술 스택을 우선하는 것입니다.

기술은 도구입니다. 서비스에 맞는 도구를 고를 줄 아는 곳이 좋은 개발사입니다.

팀 구조: 누가 실제로 만드는가

이것이 가장 중요합니다.

상담 미팅에 나오는 사람과 실제로 코드를 작성하는 사람이 다른 경우가 많습니다. 영업 담당이 계약을 따오고, PM이 중간에서 전달하고, 실제 개발은 주니어나 외부 인력이 하는 구조입니다.

확인해야 할 것:

• 미팅에 나온 사람이 직접 개발에 참여하는가
• 실제 투입 인력의 경력은 어느 정도인가
• 프로젝트 도중 담당자가 바뀔 가능성이 있는가
• 재하청 구조가 아닌가

"시니어 개발자가 직접 만듭니다"라고 해놓고, 실제로는 주니어가 대부분의 코드를 작성하고 시니어가 리뷰만 하는 경우도 있습니다. 계약 전에 "이 프로젝트에 투입되는 개발자와 직접 이야기할 수 있나요?"라고 물어보세요.

프로덕트 메이커의 방식

프로덕트 메이커는 화이트박스 개발을 합니다. 클라이언트가 개발 과정의 모든 것을 볼 수 있습니다. 격주마다 동작하는 결과물을 직접 만져보고, 피드백은 스프린트 범위 내에서 무제한이며, 위험 요소는 프로젝트 초기에 먼저 공유합니다.

미팅에서 만난 시니어가 직접 코드를 작성합니다. 재하청 없이 사내에서 전부 개발합니다. 소스코드는 당연히 클라이언트에게 전부 전달합니다.

이런 방식이 가능한 이유는 단순합니다. 숨길 것이 없기 때문입니다.

체크리스트 정리

개발사를 선택하기 전, 이것만 확인하세요.

• 내 프로젝트와 유사한 포트폴리오가 있는가
• 상담 단계에서 응답이 빠르고, 선제적으로 정보를 공유하는가
• 소스코드 소유권과 사후 지원이 계약서에 명시되어 있는가
• 기술 선택의 근거를 설명할 수 있는가
• 실제 개발자와 직접 소통할 수 있는가

전부 확인이 되는 곳이라면, 가격이 중간이어도 결과적으로 가장 합리적인 선택일 가능성이 높습니다.

*개발사 선택에 대한 고민이 있으시다면, 프로젝트 상담을 통해 편하게 문의해 주세요.*