1. 질문하기 전에 같은 자료를 보내세요.
업체마다 서로 다른 설명을 듣고 견적을 요청하면 비교가 어렵습니다. 프로젝트 목적, 핵심 사용자, 주요 기능, 참고 화면, 예상 일정, 필요한 산출물을 가능한 범위에서 동일하게 전달하세요.
2. 첫 미팅에서 반드시 확인할 질문
핵심 사용자 흐름과 기술·운영상 난점을 구체적으로 설명하고, 불명확한 부분을 다시 질문합니다.
“다 가능합니다”, “문제 없습니다”처럼 근거 없이 가능 여부만 답합니다.
PM·기획·디자인·프론트·백엔드 등 실제 역할과 담당 범위를 설명합니다.
영업 담당자만 만나고 실제 개발자나 프로젝트 책임자가 누구인지 알기 어렵습니다.
기획 확정, 디자인, 개발, 중간검수, 통합테스트, 오픈 등 단계와 확인 시점을 설명합니다.
최종 완료일만 제시하고 중간 확인 방식이 없습니다.
기존 범위 내 구체화와 신규 기능·정책 변경을 구분하고 변경 절차를 설명합니다.
“웬만한 수정은 다 해드립니다”처럼 범위와 기준이 불명확합니다.
요구사항·화면·업무흐름을 기준으로 검수하고 테스트 환경과 오류 처리 방식을 설명합니다.
화면이 보이는 것을 완료로 보거나 검수 기준이 계약 후에도 불명확합니다.
Git, 소스, DB, 디자인 원본, 서버·도메인·외부서비스 계정과 문서 인계방식을 설명합니다.
“소스는 드립니다” 외에 실제 접근권한과 계정 소유관계가 불명확합니다.
하자보수 기간, 오류 판단기준, 유지보수 및 추가개발 절차를 구분해서 설명합니다.
“오픈 후에도 계속 봐드립니다”처럼 기간과 범위가 정해져 있지 않습니다.
3. 답변 내용보다 ‘구체성’을 보세요.
| 확인 포인트 | 좋은 신호 | 주의 신호 |
|---|---|---|
| 가능 여부 | 조건과 전제를 함께 설명 | 모든 요구에 즉시 “가능” |
| 일정 | 단계·중간검수·의존조건 설명 | 근거 없이 매우 빠른 일정 약속 |
| 견적 | 포함·제외 범위를 설명 | 총액만 강조 |
| 변경 | 변경관리 절차가 있음 | 무제한 수정처럼 표현 |
| 인수 | 구체적인 산출물과 계정 이전 설명 | “다 드립니다”로 끝남 |
4. 업체가 나에게 무엇을 질문하는지도 중요합니다.
업체가 기능 목록만 받고 바로 견적을 이야기하는 것보다 서비스 목적과 사용자, 우선순위, 운영방식까지 확인하는지 살펴보세요.
사용자 유형과 실제 사용환경을 이해하려는 질문입니다.
기능보다 사업 단계와 개발 목적을 확인하려는 질문입니다.
관리자·데이터·배포·유지보수까지 고려하는 질문입니다.
5. 미팅 직후 같은 표에 기록하세요.
| 평가 항목 | 업체 A | 업체 B | 업체 C |
|---|---|---|---|
| 요구사항 이해도 | 상/중/하 + 메모 | 상/중/하 + 메모 | 상/중/하 + 메모 |
| 실제 투입인력 | 확인 내용 | 확인 내용 | 확인 내용 |
| 일정·중간검수 | 확인 내용 | 확인 내용 | 확인 내용 |
| 변경관리 방식 | 확인 내용 | 확인 내용 | 확인 내용 |
| 소스·인수 조건 | 확인 내용 | 확인 내용 | 확인 내용 |
| 소통의 구체성 | 상/중/하 | 상/중/하 | 상/중/하 |
6. 미팅이 끝나기 전에 체크하세요.
업체 미팅에서는 ‘할 수 있나요?’보다 ‘어떻게 할 건가요?’를 물어보세요.
가능하다는 답은 대부분의 업체가 할 수 있습니다. 차이는 범위·인력·일정·변경·검수·인수 과정을 얼마나 구체적으로 설명할 수 있는가에서 드러납니다.