외주 개발, 첫 미팅에서 뭘 물어야 하나

시즌이 바뀌기 전에 재고 배분 시스템을 바꾸고 싶었다. 엑셀로 돌아가는 발주 프로세스도 손봐야 하고, 온·오프라인 재고를 한눈에 볼 수 있는 화면도 필요하다. 그래서 개발사 미팅을 잡았다. 그런데 막상 회의실에 앉으니 뭘 물어야 할지 막막하다. 상대방은 유창하게 기술 용어를 늘어놓고, 나는 고개를 끄덕이다가 결국 "견적서 보내주세요"로 끝난다.

이 패턴, 한 번쯤 겪어본 적 있을 것이다. 그리고 그 결과는 대부분 비슷하다. 계약 후 3개월이 지나도 화면 하나 못 보고, 추가 비용 얘기가 나오고, 결국 프로젝트가 흐지부지된다. 외주 개발 실패의 80%는 첫 미팅에서 물어야 할 것을 묻지 않은 데서 시작된다.

첫 미팅의 목적을 다시 정의하라

많은 브랜드 담당자들이 첫 미팅을 "견적을 받으러 가는 자리"로 생각한다. 틀렸다. 첫 미팅은 이 회사가 우리 업무를 이해할 수 있는지 검증하는 자리다.

개발사는 코드를 짜는 곳이다. 하지만 우리가 필요한 건 단순히 코드가 아니라, 시즌별 입고 스케줄, SKU별 배분 로직, 반품 처리 흐름, 매장별 재고 기준 같은 패션·유통 업무의 맥락을 이해하는 파트너다. 이걸 확인하지 않고 계약하면, 나중에 "그 기능은 요구사항에 없었습니다"라는 말을 듣게 된다.

첫 미팅에서 얻어야 하는 것은 두 가지다. 첫째, 이 회사가 우리 업종의 업무 흐름을 아는가. 둘째, 프로젝트가 어떻게 진행되는지 구체적으로 설명할 수 있는가.

반드시 물어야 할 질문 4가지

1. "비슷한 업종, 비슷한 규모의 프로젝트를 해본 적 있나요?"

포트폴리오를 보여달라는 게 아니다. 우리 업무와 유사한 문제를 풀어본 경험이 있는지를 확인하는 것이다. 패션 유통 ERP와 병원 예약 시스템은 개발 기술은 비슷할 수 있어도, 업무 로직은 완전히 다르다. 시즌 마감, 이월 재고 처리, 매장별 배분 우선순위 같은 개념을 설명 없이 이해하는 회사인지 아닌지는 이 질문 하나로 갈린다.

좋은 답변: "패션 브랜드 재고 관리 시스템을 구축한 경험이 있고, 당시 이월 재고 처리 로직에서 이런 문제가 있었습니다." 나쁜 답변: "저희는 다양한 업종 경험이 있어서 어떤 프로젝트든 잘 할 수 있습니다."

2. "요구사항은 어떻게 정리하나요?"

이 질문이 왜 중요하냐면, 요구사항 정리 방식이 곧 분쟁 발생 지점이기 때문이다. 많은 소규모 개발사들은 첫 미팅 메모와 구두 합의로 개발을 시작한다. 그러다 중간에 "그 기능은 포함 안 됐는데요"라는 말이 나온다.

요구사항 정의서(기능 명세서)를 계약 전에 작성하는 회사인지 반드시 확인해야 한다. 이 문서가 없으면 추후 범위 분쟁이 생겼을 때 판단 기준이 없다. "우리가 원하는 기능을 문서로 정리해줄 수 있나요?"라고 물어보자. 이걸 당연하게 여기는 회사와 그렇지 않은 회사는 프로젝트 완성도에서 큰 차이가 난다.

3. "중간 산출물은 언제, 어떤 형태로 확인할 수 있나요?"

개발은 눈에 보이지 않는다. 3개월 후 완성본을 받아보니 내가 생각한 것과 전혀 다른 경우가 허다하다. 중간 점검 없이 진행되는 프로젝트는 리스크가 크다.

좋은 개발사는 2~4주 단위로 작동하는 화면을 보여준다. "화면 설계서(와이어프레임)는 언제 나오나요?", "중간에 우리가 직접 테스트해볼 수 있는 시점이 있나요?" 이 두 가지를 물어보자. 여기서 명확한 일정을 제시하지 못하는 회사는 주의가 필요하다.

4. "추가 비용이 발생하는 경우는 어떤 때인가요?"

계약서에 명시된 금액이 최종 금액이 아닌 경우가 많다. 특히 "추가 요구사항", "기획 변경", "연동 작업" 등의 명목으로 비용이 붙는 경우가 흔하다. 처음 견적은 3,000만 원이었는데 최종 청구는 5,000만 원이 되는 일이 실제로 일어난다.

이 질문을 하면 회사의 투명성도 함께 확인할 수 있다. 추가 비용 발생 기준을 명확히 설명하는 회사는 신뢰할 수 있다. 반면 "그런 일은 없을 거예요"라고 얼버무리는 회사는 계약 조건을 꼼꼼히 따져봐야 한다.

미팅 전에 준비해야 할 것

질문만큼 중요한 건 우리가 미팅에 들고 가는 준비물이다. 개발사가 정확한 견적을 내려면 우리가 무엇을 원하는지 알아야 한다. 막연하게 "재고 관리 시스템 만들고 싶어요"라고 하면 상대방도 막연한 제안을 할 수밖에 없다.

최소한 다음 세 가지를 준비하고 가자.

현재 업무 흐름 한 장 요약: 지금 어떤 도구로, 어떤 순서로 일하는지. 엑셀 파일 몇 개를 쓰고, 어디서 병목이 생기는지. 이걸 A4 한 장으로 정리해 가면 미팅 품질이 완전히 달라진다.

해결하고 싶은 문제 3가지: "모든 걸 다 자동화하고 싶다"는 범위가 너무 넓다. "매장 배분 계산에 매주 반나절이 걸린다", "재고 실사 후 ERP 반영이 3일씩 걸린다" 같이 구체적인 문제를 가져가야 한다.

예산 범위와 오픈 목표 시점: 이걸 숨기는 분들이 많은데, 오히려 공유하는 게 낫다. 예산이 맞지 않으면 빨리 다른 회사를 찾는 게 낫고, 일정이 맞지 않으면 범위를 조정해야 한다. 이 대화를 첫 미팅에서 하지 않으면 계약 직전에 하게 된다.

미팅 후 판단 기준

미팅이 끝나고 나서 판단할 때 쓸 수 있는 기준이 있다. 좋은 개발사는 미팅 후 회의 내용을 정리한 이메일이나 문서를 먼저 보내온다. 우리가 말한 문제를 그들이 어떻게 이해했는지 확인할 수 있다. 이 문서가 우리 업무를 정확히 담고 있다면 좋은 신호다. 기술 용어만 가득하고 우리 업무 맥락이 없다면 다시 생각해볼 필요가 있다.

또 하나, 담당 PM(프로젝트 매니저)이 누구인지 확인하자. 영업 담당자가 미팅을 이끌고 실제 개발은 다른 팀이 하는 구조라면, 우리가 전달한 맥락이 실제 개발팀에 제대로 전달되지 않을 수 있다. 실제로 개발을 이끌 사람이 미팅에 함께 있는지, 아니면 적어도 미팅 내용을 직접 전달받는 구조인지 확인해야 한다.

외주 개발에서 가장 비싼 실수는 "일단 시작해보자"다. 첫 미팅에서 30분을 더 쓰면, 나중에 3개월과 수천만 원을 아낄 수 있다. "요구사항을 계약 전에 문서로 정리해주시나요?" — 이 질문 하나만 제대로 해도 절반은 검증된다. → 문의하기