같은 요구사항을 세 곳에 보냈는데 견적이 몇 배씩 벌어지는 일은 흔하다. 어느 한 곳이 특별히 비싸거나 싸서가 아니라, 세 곳이 서로 다른 것을 세고 있어서 생기는 차이다. 금액을 비교하기 전에 무엇을 세었는지부터 맞춰야 한다.
이 글에서 확인할 것
- 견적서를 나란히 놓고 비교할 수 있게 만드는 최소한의 요구사항 정리 방법
- 금액이 실제로 벌어지는 항목과, 견적서에서 그 항목을 찾는 위치
- 계약 전에 문서로 남겨 두어야 결과물을 온전히 받아 올 수 있는 조건
견적이 비교되지 않는 첫 번째 이유: 세는 단위가 다르다
요구사항이 “회원가입, 게시판, 결제”처럼 명사로만 적혀 있으면 업체마다 해석이 갈린다. 회원가입이 이메일 가입 하나인지, 소셜 로그인 세 종류와 본인인증까지인지에 따라 작업량은 몇 배 차이가 난다. 게시판도 글쓰기와 목록만인지, 이미지 업로드·검색·신고·차단까지 포함인지에 따라 다르다. 결제는 카드 단건 결제만인지, 정기결제와 부분취소, 정산 내역까지 필요한지에 따라 사실상 다른 프로젝트가 된다.
같은 이름의 기능이라도 안에서 처리해야 할 예외가 얼마나 되는지에 따라 일정이 갈린다. 예약 기능 하나를 예로 들면, 달력에서 날짜를 고르고 저장하는 데까지는 어느 업체든 비슷한 금액을 적는다. 차이는 중복 예약을 어떻게 막을지, 취소와 환불을 어느 단계까지 자동으로 처리할지, 예약 변경 이력을 남길지에서 생긴다. 이 조건들은 요구사항에 적혀 있지 않으면 견적서에도 나타나지 않고, 개발이 시작된 뒤에 추가 비용으로 나타난다.
견적 금액은 이 해석의 결과물이다. 요구사항이 뭉뚱그려져 있으면 받은 견적서는 서로 다른 제품의 가격표이고, 그 상태에서 금액만 비교하면 가장 적게 이해한 곳이 가장 싸 보인다.
금액보다 범위를 먼저 맞춘다
대단한 기획 문서가 필요한 것은 아니다. 아래 여섯 줄만 정리해 같은 파일을 모든 업체에 보내면 견적서가 같은 축 위에 놓인다.
- 화면 목록: 사용자가 보는 화면을 하나씩 이름 붙여 나열한다. 로그인, 목록, 상세, 결제, 마이페이지, 관리자 대시보드.
- 화면별 동작: 각 화면에서 할 수 있는 일을 동사로 적는다. 검색한다, 예약한다, 취소한다, 내보낸다.
- 데이터 규모: 예상 사용자 수, 하루 등록 건수, 이미지·파일 용량.
- 연동 대상: 결제사, 문자·알림, 지도, 소셜 로그인, 회계나 재고 같은 기존 시스템.
- 관리자 기능: 통계, 정산, 권한 분리처럼 사용자 화면에는 안 보이지만 반드시 필요한 것.
- 운영 주체: 출시 후 콘텐츠를 누가 넣고, 오류 신고를 누가 받는지.
문서 작성이 부담스럽다면 화면 목록 하나만이라도 표로 만들어 첨부한다. 그것만으로도 “이 화면은 견적에 포함되지 않았다”는 뒤늦은 다툼이 크게 줄어든다.
견적서에서 항목별로 확인할 여섯 가지
총액 한 줄짜리 견적서는 비교 대상이 아니다. 아래 항목이 각각 얼마인지 나눠 달라고 요청하고, 나뉜 상태로 비교한다.
| 항목 | 견적서에서 볼 것 | 금액이 벌어지는 지점 |
|---|---|---|
| 화면 수 | 화면당 단가인지 기능 묶음 단가인지 | 로딩·빈 목록·오류 화면을 세는지 여부 |
| 디자인 | 시안 수, 수정 횟수, 반응형 범위 | 기존 디자인 적용인지 신규 제작인지 |
| 관리자 페이지 | 포함인지 별도 견적인지 | 통계·정산·권한이 붙으면 별도 프로젝트급 |
| 외부 연동 | 연동 건수와 각각의 담당 범위 | 심사·계약이 필요한 연동은 일정까지 늘어남 |
| 테스트 | 대상 기기·브라우저, 검수 기간 | “검수 2주”에 수정 작업이 포함되는지 |
| 인수인계 | 소스·계정·문서 이전 방식 | 나중에 다른 곳으로 옮길 때의 비용을 좌우 |
특히 연동 항목이 금액을 가장 크게 흔든다. 앱 개발 외주를 처음 맡긴다면 화면 수보다 연동 목록을 먼저 확정하는 편이 예산 오차를 줄인다.
견적서에 안 적히지만 매달 나가는 돈
구축비만 비교하고 운영비를 빼면, 싼 견적이 1년 뒤에 더 비싸지는 일이 생긴다. 아래는 견적서 밖에서 발생하는 대표적인 비용이다.
- 서버·도메인·인증서 비용, 트래픽 종량제 요금
- 결제대행 수수료와 정산 주기
- 문자·알림 발송비, 지도·인증 API 사용료
- 앱 스토어 등록비와 갱신 주기
- 유지보수 계약(월 정액인지 시간 단가인지)
- 기능 추가 요청의 단가 기준
홈페이지 제작 업체를 고를 때도 같다. 첫 구축비와 함께 1년 치 운영비를 물어보고, 총액으로 견적을 다시 세우면 순위가 바뀌는 경우가 적지 않다.
계약 전에 문서로 남길 것
- 산출물 목록과 형식: 소스 저장소, 서버·도메인 계정, 설계 문서
- 소스 코드와 디자인 원본의 소유권, 재사용 범위
- 단계별 지급 조건과 각 단계의 “완료” 기준
- 하자보수 기간과 범위: 오류 수정과 기능 추가의 경계
- 일정 지연 시 처리 방법과 연락 주기
- 담당자 교체 시 인수인계 방식
브랜드 작업을 함께 맡긴다면 브랜드 로고 디자인의 원본 파일까지 인도 대상에 넣어 둔다. 완성된 이미지 파일만 받으면 나중에 간판이나 인쇄물에 쓸 때 다시 비용이 든다.
정리: 견적 비교 순서
순서는 단순하다. 화면 목록과 동작을 먼저 적고, 같은 문서를 모든 업체에 보내고, 항목별로 나뉜 견적을 받고, 1년 치 운영비를 더해 총액으로 비교한 다음, 마지막에 계약 조건을 본다. 금액부터 보면 이 순서가 뒤집히고, 뒤집힌 순서에서는 대체로 가장 적게 이해한 견적이 선택된다.
견적서는 가격표가 아니라, 상대가 이해한 요구사항의 요약본이다.
