개발사와 첫 미팅이 잡혔습니다. 그런데 뭘 물어봐야 할지 모르겠습니다. 기획서도 완벽하지 않고, 기술 용어도 익숙하지 않습니다. 괜찮습니다. 미팅에서 꼭 확인해야 할 질문들을 정리했습니다.

반드시 물어봐야 할 질문들

"실제로 제 프로젝트를 담당하는 분은 누구인가요?"

영업 담당자와 실제 개발자가 다른 경우가 많습니다. 미팅에서 멋진 포트폴리오를 보여준 사람이 내 프로젝트를 만드는 사람이 아닐 수 있습니다.

• 실제 개발을 담당할 팀(또는 개인)을 확인
• 해당 담당자의 경력과 유사 프로젝트 경험
• 프로젝트 중 담당자가 바뀔 가능성

"시니어가 설계하고 주니어가 구현합니다"는 일반적인 구조이지만, 시니어가 실제로 얼마나 관여하는지는 다를 수 있습니다.

"일정이 밀리면 어떻게 되나요?"

모든 프로젝트에는 변수가 있습니다. 중요한 건 밀렸을 때의 대응 방식입니다.

• 일정 지연 시 클라이언트에게 알리는 시점과 방법
• 지연에 대한 책임 구조 (개발사 귀책 vs 클라이언트 귀책)
• 계약서에 지연 관련 조항이 있는지

"절대 안 밀립니다"라고 말하는 곳보다, "밀릴 수 있고, 그때 이렇게 대응합니다"라고 말하는 곳이 현실적입니다.

"기능 추가나 변경이 생기면 어떻게 처리하나요?"

개발 중에 "이것도 넣어주세요"는 반드시 발생합니다. 이때의 처리 방식을 미리 확인하세요.

• 범위 변경 시 추가 비용 산정 기준
• 변경 요청의 프로세스 (구두? 문서? 승인 절차?)
• 어디까지가 "원래 범위"이고 어디부터가 "추가"인지의 기준

범위가 모호할수록 나중에 "이건 별도입니다"를 듣게 됩니다.

"최종적으로 제가 받는 것은 무엇인가요?"

개발이 끝나면 받게 되는 산출물을 명확히 확인하세요.

• 소스코드 전체 (Git 저장소 이력 포함)
• 서버 접속 정보, DB 접속 정보
• 환경 변수, API 키, 인증 정보
• 배포 절차 문서
• 로컬 개발 환경 구축 가이드

"소스코드를 드립니다"와 "인수인계를 완료합니다"는 다릅니다. ZIP 파일 하나 받는 것과, 다른 개발자가 바로 이어받을 수 있는 상태로 전달받는 것은 전혀 다릅니다.

"납품 후 버그가 발견되면 어떻게 하나요?"

서비스를 운영하면 버그는 반드시 발생합니다.

• 무상 버그 수정 기간 (최소 3개월 권장)
• "버그"의 정의 — 기획과 다른 동작인지, 기능 추가 요청인지
• 긴급 장애 시 대응 시간
• 유상 유지보수 전환 시 비용 구조

개발사가 물어보는 질문의 질을 보세요

미팅에서 클라이언트만 질문하는 게 아닙니다. 개발사가 어떤 질문을 하는지가, 그 개발사의 수준을 보여줍니다.

좋은 개발사는 이런 질문을 합니다:

• "이 서비스의 핵심 사용자는 누구인가요?"
• "경쟁 서비스와 어떤 점이 다른가요?"
• "런칭 후 첫 3개월의 목표는 무엇인가요?"
• "이 기능이 비즈니스적으로 왜 필요한가요?"
• "나중에 직접 유지보수할 내부 개발자가 있나요?"

비즈니스를 이해하려는 질문을 하는 개발사는, 기능을 만드는 것이 아니라 문제를 해결하려는 곳입니다.

반면 이런 경우는 주의하세요:

• 비즈니스 맥락 없이 바로 기능 목록부터 확인
• 모든 요청에 "가능합니다" — 제약이나 트레이드오프를 설명하지 않음
• 기술적 결정을 비전문가가 이해할 수 있는 언어로 설명하지 못함
• "저희 방식대로 하면 됩니다" — 클라이언트 상황을 고려하지 않음

미팅 전 준비하면 좋은 것들

완벽한 기획서가 없어도 괜찮습니다. 아래 내용만 정리해가면 미팅이 훨씬 생산적입니다.

• 서비스의 한 줄 설명: "~한 사람을 위한 ~한 서비스"
• 레퍼런스: "이런 느낌으로 만들고 싶다"는 사이트나 앱 2~3개
• 핵심 기능 3~5개: 전체 기능 목록이 아니라, 이것만 있으면 서비스가 되는 핵심
• 예산 범위: 정확한 금액이 아니어도, "이 정도 안에서 가능한지" 수준
• 일정: 언제까지 런칭해야 하는지

프로토타입이나 데모가 있다면 더 좋습니다. Cursor나 Figma로 만든 것이라도, "이렇게 동작해야 한다"를 보여줄 수 있으면 소통 효율이 완전히 다릅니다.

정리

미팅에서 확인할 핵심:

• 실제 담당자 — 누가 만드는지
• 일정 리스크 대응 — 밀리면 어떻게 하는지
• 범위 변경 처리 — 추가 비용 기준
• 산출물 — 코드만 받는지, 인수인계까지인지
• 사후 지원 — 버그 수정 기간과 조건
• 개발사의 질문 — 비즈니스를 이해하려 하는지

좋은 미팅은 "얼마예요?"로 끝나지 않습니다. "이 팀이 내 프로젝트를 이해하고 있구나"라는 확신을 얻는 것이 목표입니다.

*프로젝트 상담을 원하시면, 프로젝트 상담을 통해 문의해 주세요. 첫 미팅은 무료입니다.*