좋은 업체는 ‘유명한 업체’와 같은 뜻이 아닙니다.
대형 개발사, 소규모 전문업체, 프리랜서 모두 적합한 프로젝트가 다릅니다. MVP처럼 범위가 작고 빠른 의사결정이 중요한 프로젝트에서는 작은 전문팀이 더 적합할 수 있고, 복잡한 기업 시스템은 역할이 분리된 조직이 필요할 수도 있습니다.
1. 포트폴리오는 개수보다 ‘무엇을 했는지’를 확인하세요.
| 단순 확인 | 한 단계 더 확인할 질문 |
|---|---|
| 유사 서비스가 포트폴리오에 있다 | 그 프로젝트에서 실제로 어느 범위를 담당했나요? |
| 유명 고객사 프로젝트를 했다 | 전체 구축인지, 특정 기능·인력 투입인지 확인했나요? |
| 디자인이 좋아 보인다 | 디자인뿐 아니라 실제 개발·배포까지 담당했나요? |
| 기술 스택이 비슷하다 | 이번 프로젝트에 실제 투입되는 개발자가 그 경험을 가지고 있나요? |
| 프로젝트가 성공적으로 보인다 | 오픈 이후 유지보수와 운영은 어떻게 진행됐나요? |
2. 좋은 개발업체에서 자주 보이는 신호
사용자, 목적, 우선순위와 운영방식을 이해한 뒤 범위를 정하려고 합니다.
예산·일정 안에서 어려운 요구와 위험요소를 사전에 설명합니다.
포함·제외 기능과 결과물을 문서로 맞추려 합니다.
완료일까지 기다리지 않고 단계별 결과물을 확인할 수 있습니다.
변경 요청이 일정과 비용에 미치는 영향을 투명하게 설명합니다.
소스·DB·계정·배포·문서와 이후 유지보수까지 고려합니다.
3. 반대로 이런 신호는 한 번 더 확인하세요.
정확한 범위보다 수주를 먼저 결정했을 가능성이 있습니다.
기술적 가능성과 예산·일정 내 현실적인 구현 가능성은 다른 문제입니다.
기획·검수·테스트가 일정에 실제 반영되어 있는지 확인해야 합니다.
계약 전 만난 사람과 실제 프로젝트 수행자가 완전히 다를 수 있습니다.
완료 후 인수와 업체 변경 가능성을 반드시 확인해야 합니다.
중요한 범위·일정·산출물은 견적서나 계약 문서로 남겨야 합니다.
4. 회사 규모보다 실제 수행체계를 보세요.
10명이 있는 회사라도 프로젝트에 한 명만 투입될 수 있고, 2~3명의 작은 팀이라도 기획·개발·배포 경험이 충분할 수 있습니다. 그래서 회사 전체 인원보다 실제 프로젝트에 누가 어떻게 참여하는지가 더 중요합니다.
| 확인 항목 | 질문 |
|---|---|
| 프로젝트 책임자 | 의사결정과 일정 관리는 누가 담당하나요? |
| 실제 개발자 | 누가 개발하고 해당 기술 경험은 어느 정도인가요? |
| 기획·디자인 | 필요할 경우 누가 담당하며 견적에 포함되어 있나요? |
| 테스트 | 개발자 외에 검수 역할이 있는지, 어떤 방식으로 테스트하나요? |
| 부재 대응 | 핵심 담당자가 빠질 경우 프로젝트를 이어갈 수 있나요? |
5. 최종 선정은 같은 기준으로 점수화해보세요.
가중치는 프로젝트에 따라 바꿀 수 있습니다. 중요한 것은 느낌이나 가격 하나로 결정하지 않는 것입니다.
6. 최종 업체 선정 체크리스트
좋은 개발업체는 개발을 시작하기 전에 프로젝트를 제대로 이해하려는 업체입니다.
기술력과 포트폴리오도 중요하지만 실제 프로젝트의 성공 가능성은 요구사항 이해 → 범위 합의 → 수행 → 검수 → 인수·운영을 얼마나 일관되게 관리할 수 있는지에서 결정됩니다.