견적 문의에 예산을 적을지 말지부터 정한다

문의 메일에 적는 건 대개 한두 줄이다. “이런 서비스를 만들고 싶습니다.” 업체는 이 한두 줄을 받아 나머지를 각자 머릿속에서 채운 다음 견적을 낸다. 어떤 곳은 작게 그리고 어떤 곳은 크게 그린다. 받은 견적서를 나란히 놓고 항목을 맞춰 읽는 법은 따로 적어 두었다. 여기서 다루는 건 그 앞 단계다. 업체가 빈칸을 채우기 전에, 이쪽에서 먼저 채워 둘 수 있는 것들이 있다.

예산 칸을 비워 두면 벌어지는 일

예산을 먼저 밝히면 그 금액까지 다 받아 낼 것 같아 비워 두는 경우가 많다. 실제로는 반대되는 일이 벌어진다. 업체는 예산을 모르면 자기가 평소에 많이 맡는 규모를 기본값으로 놓고 계산한다. 어떤 곳은 소규모 쇼핑몰을 기준으로 잡고, 어떤 곳은 개인 프로젝트 수준으로 잡는다. 같은 문장을 읽고도 서로 다른 크기의 프로젝트를 그리니, 돌아온 숫자를 나란히 놓아도 비교가 안 된다.

정확한 액수를 못 박을 필요는 없다. 범위로 말해도 충분하다. “이 정도까지는 생각하고 있고, 이 위로 넘어가면 다시 상의가 필요하다”는 문장 하나면 업체는 그 범위 안에서 뺄 것과 넣을 것을 골라 제안한다. 범위를 알려줬다고 그 금액까지 다 채워 청구하는 게 정상적인 관행은 아니다. 그런 곳을 만났다면 예산을 알려준 쪽의 실수가 아니라 업체를 다시 골라야 한다는 신호로 읽으면 된다.

결정을 누가 내리는지 먼저 정해 둔다

문의 단계에서 결정권자가 흔들리면 견적이 나온 뒤에도 진행이 멈춘다. 담당자가 받은 견적을 대표에게 올렸는데 방향이 다르게 나오면, 업체는 이미 낸 견적을 처음부터 다시 짜야 한다. 재견적은 새로 견적을 내는 것과 다르지 않은 일이라 시간이 그만큼 다시 든다.

문의를 넣기 전에 이 프로젝트의 답을 누가 내리는지, 몇 사람의 동의가 필요한지를 안에서 먼저 정리해 둔다. 담당자 한 명이 최종 답을 낼 수 있으면 가장 빠르고, 여러 사람의 합의가 필요하면 그 사람들이 견적을 받기 전에 무엇을 우선순위로 볼지 미리 맞춰 두는 편이 낫다. 업체 쪽 연락 창구도 하나로 좁혀 둔다. 같은 질문이 서로 다른 사람에게 두 번 들어가면 답도 두 번 다르게 나온다.

참고할 것과 참고하면 안 되는 것을 같이 보낸다

“이런 느낌으로”라며 사이트나 앱 주소 하나만 보내는 문의가 많다. 그 주소가 가리키는 게 디자인 톤인지, 화면 구성인지, 그 서비스가 가진 기능 전체인지가 안 밝혀지면 업체는 셋 중 하나를 짐작해 견적을 짠다. 디자인만 참고하라는 뜻으로 보낸 주소를 상대가 기능까지 전부 넣어야 한다고 읽으면, 견적은 필요 이상으로 부풀어 돌아온다.

넣고 싶지 않은 것도 같이 밝혀 두면 도움이 된다. 참고 사이트에는 있지만 이번엔 뺄 기능, 예전에 다른 곳에서 써 봤는데 별로였던 방식. 이런 제외 목록은 짧아도 효과가 크다. 원하는 것보다 원하지 않는 것이 범위를 더 빨리 좁혀 준다.

이미 가진 것부터 정리해 둔다

새로 만드는 게 아니라 기존 서비스를 고치거나 옮기는 일이라면, 지금 가진 것의 목록이 견적의 절반을 채운다. 쓰는 도구의 이름과 요금제, 로그인 정보, 예전에 다른 업체에서 받아 둔 코드나 디자인 파일, 지난번 견적서까지 있다면 함께 보낸다. 이 자료가 없으면 업체는 처음부터 새로 만드는 것으로 가정하고 계산하는데, 실제로는 기존 것을 살리는 편이 훨씬 간단하게 끝나는 경우가 흔하다.

자료를 찾다 보면 로그인 비밀번호를 모르거나 담당자가 이미 퇴사한 경우도 나온다. 이런 상태라면 견적 문의보다 계정부터 되찾는 일이 먼저다. 개발자와 연락이 끊긴 첫 주에 할 일에 그 순서를 따로 적어 두었다.

아직 다 못 정했어도 상담은 됩니다

위 네 가지를 전부 채워야 문의를 넣을 수 있는 건 아닙니다. 위플의 개발 상담은 이 빈칸들을 채우는 일 자체를 도와드립니다. 예산 범위를 어떻게 표현하면 좋을지, 참고 자료 중 무엇이 핵심인지, 지금 머릿속에 있는 걸 편하게 적어 보내시면 함께 짚어 정리합니다. 답변 형식과 상담 단가는 가격 안내에 적어 두었습니다. 정리된 문서는 다른 업체에 문의하실 때도 그대로 쓰실 수 있습니다.