IT 외주 개발 견적서는 발주자가 만들고 싶은 것을 개발사가 자기 방식으로 해석한 뒤, 그 해석을 실제로 만드는 데 필요한 인력과 기간과 비용을 항목별로 적어 놓은 문서예요. 가격표처럼 보이지만 실제로는 해석 결과물에 가까워요. 같은 요구사항을 건네도 업체마다 금액이 달라지는 이유는 단가 차이 때문만이 아니라, 무엇을 만들어야 하는지에 대한 이해가 서로 다르기 때문이에요. 그래서 견적서를 읽는 일은 금액을 읽는 일이 아니라 그 업체가 내 프로젝트를 어떻게 이해했는지를 읽는 일이에요.
외주 견적서를 여러 곳에 요청해 보면 총액 한 줄로 끝나는 문서와 화면 단위까지 쪼개진 문서가 같은 요구사항에 대해 나란히 도착하기도 해요. 이 포맷 격차 자체가 이미 판단 재료예요. 쪼개져 있다는 건 그 업체가 요구사항을 항목 수준까지 내려가 읽었다는 뜻이고, 뭉뚱그려져 있다는 건 아직 그만큼 읽지 않았거나 읽고도 적지 않기로 했다는 뜻이니까요.
이 글은 견적을 요청하는 단계부터 여러 업체의 외주 견적서를 나란히 놓고 판단하고, 깎을 것과 지킬 것을 나누고, 계약서로 옮기는 단계까지를 순서대로 정리했어요. 특히 표기 방식이 서로 다른 견적서를 어떻게 읽을 수 있는 상태로 만드는지에 무게를 뒀어요.
견적서를 잘 읽으려면 먼저 "정상적인 견적서에는 무엇이 들어 있어야 하는가"라는 기준선이 필요해요. 기준선이 없으면 받은 문서가 부실한지 아닌지 판단할 수가 없어요. 견적서가 갖춰야 할 구성요소는 금액 말고도 여러 개예요.
| 구성요소 | 적혀 있어야 하는 내용 | 빠지면 생기는 일 |
|---|---|---|
| 범위 정의 | 이 금액으로 만드는 화면과 기능과 연동의 목록 | 무엇이 포함인지 말로만 남아 나중에 해석이 갈려요 |
| 제외 범위 | 이 금액에 들어 있지 않은 항목의 명시 | 포함이라고 믿었던 항목이 추가 견적으로 돌아와요 |
| 산정 근거 | 각 항목의 공수와 단위, 계산 방식 | 금액을 조정할 근거가 사라져요 |
| 전제 조건 | 발주자가 제공해야 할 자료와 계정, 의사결정 기한 | 지연 책임이 누구에게 있는지 다투게 돼요 |
| 일정 | 단계 구분과 각 단계의 산출물 | 진척을 확인할 지점이 없어요 |
| 산출물 목록 | 코드 외에 문서와 계정과 배포 환경까지 | 납품 후 손에 남는 것이 코드뿐이게 돼요 |
| 결제 조건 | 분할 지급 시점과 각 시점의 조건 | 검수 전에 잔금이 나가는 구조가 돼요 |
| 유효기간 | 이 금액이 유지되는 기간 | 비교하는 사이 금액이 바뀌어요 |
이 목록을 옆에 두고 받은 견적서를 훑으면, 어디가 비어 있는지가 바로 보여요. 비어 있는 칸은 그 자체로 질문 목록이 돼요. 채워 달라고 요청했을 때 어떤 태도로 응답하는지도 업체를 판단하는 재료가 되고요. 범위와 제외 범위를 문서로 다시 정리해 보내 주는 곳과, 말로 안심시키고 넘어가려는 곳은 프로젝트 중반에도 같은 방식으로 갈려요.
범위를 문장으로만 적으면 해석이 갈리기 때문에, 견적 이전에 기능명세서에는 무엇을 어디까지 적어야 하나요를 먼저 정리해 두면 견적서의 범위 칸이 훨씬 단단해져요.
견적의 품질은 견적서를 받는 순간이 아니라 요청하는 순간에 거의 결정돼요. 개발사는 모르는 것을 비용으로 덮어요. 정보가 적으면 위험을 감안해 금액을 올리거나, 반대로 좁게 해석해 금액을 낮춰 적고 나중에 추가 청구로 맞추게 돼요. 어느 쪽이든 발주자에게 좋지 않아요.
그래서 견적을 요청할 때는 아래 자료를 가능한 만큼 함께 보내는 게 좋아요. 완벽할 필요는 없고, 모르는 항목은 "미정"이라고 적어 보내면 돼요. 미정이라고 적는 것만으로도 업체는 그 부분을 가정으로 처리하고 가정을 견적서에 적게 되니까요.
| 요청 시 함께 보내는 자료 | 이 자료가 없애는 불확실성 |
|---|---|
| 화면 목록 또는 화면 흐름 | 만들 화면 수와 화면당 복잡도 |
| 사용자 유형과 권한 | 관리자 화면의 존재 여부와 규모 |
| 외부 연동 대상 | 결제, 인증, 알림, 지도 등 연동 공수 |
| 기존 데이터 이관 여부 | 이관 설계와 검증에 드는 별도 공수 |
| 운영 환경 요구 | 서버 구성, 보안 요건, 접근 통제 수준 |
| 동시 사용 규모에 대한 기대 | 성능 설계와 부하 대응 범위 |
| 희망 일정과 고정된 마감 | 인력 투입 밀도와 병렬 진행 여부 |
| 디자인 보유 여부 | 디자인이 견적에 포함되는지 여부 |
여러 업체를 비교할 계획이라면 이 자료를 모든 업체에 동일하게 보내야 해요. A업체에는 화면 목록을 주고 B업체에는 말로 설명했다면, 돌아온 견적서 두 장은 애초에 비교 대상이 아니에요. 요청 문서를 한 번 제대로 만들어 두는 편이 결국 시간을 아껴요. 요청 문서의 형식과 항목은 RFP를 어떻게 써야 업체들이 같은 기준으로 견적을 주나요에서 정리해 두었어요.
범위를 어디서 끊을지 아직 정하지 못했다면 견적을 먼저 받지 말고 범위부터 정하는 편이 나아요. 범위가 흔들리는 상태에서 받은 견적서는 비교에도 쓸 수 없고 협상에도 쓸 수 없어요. 첫 버전의 범위를 어디서 끊어야 하나요를 먼저 읽고 기능 목록을 고정한 다음 요청하는 순서를 권해요.
견적 비교가 어려운 진짜 이유는 금액이 달라서가 아니라 표기 단위가 달라서예요. 한 곳은 화면 이름으로 줄을 나누고, 한 곳은 프론트엔드와 백엔드와 디자인처럼 개발 영역으로 나누고, 한 곳은 총액 한 줄로 끝내요. 이 세 장은 서로 뺄셈도 덧셈도 되지 않아요. 단위가 다른 값을 나란히 놓은 상태이기 때문이에요.
그래서 금액을 보기 전에 먼저 할 일은 표기 단위를 하나로 맞추는 거예요. 여기서 발주자가 혼자 할 수 있는 환산과, 업체에 다시 요청해야만 가능한 환산이 갈려요. 이 구분을 모르면 혼자 계산기를 두드리다가 잘못된 비교표를 만들게 돼요.
| 견적서의 표기 방식 | 이 방식이 가려 놓는 것 | 읽을 수 있게 만드는 방법 |
|---|---|---|
| 화면 이름 단위 | 화면에 드러나지 않는 서버 작업과 데이터 설계가 어느 줄에 섞였는지 | 내 화면 목록과 대조하고, 화면이 없는 작업이 별도 줄로 있는지 확인해요 |
| 개발 영역 단위 | 어느 기능이 어느 영역 값 안에 들어갔는지 | 발주자가 쪼갤 수 없어요. 각 영역이 덮는 기능 이름을 목록으로 받아야 해요 |
| 공정 단계 단위 | 기획과 디자인과 개발과 검수 각 단계에 어떤 기능이 들어 있는지 | 단계별 산출물 이름을 받아서 기능과 이어 붙여요 |
| 총액 한 줄 | 사실상 전부 | 환산할 방법이 없어요. 항목을 나눠 다시 받는 것 말고는 길이 없어요 |
| 옵션 포함 총액 | 기본 사양과 옵션의 경계 | 옵션을 뺀 기본 금액과 옵션별 금액을 따로 받아요 |
| 월 정액 구독형 | 개발 대가와 운영 대가의 비중 | 계약 기간과 중도 해지 조건, 해지 후 산출물 귀속을 함께 물어요 |
여기서 중요한 건 총액 한 줄짜리 견적을 발주자가 머릿속에서 쪼개면 안 된다는 점이에요. 쪼개는 순간 그건 업체의 산정이 아니라 발주자의 추측이 되고, 추측으로 만든 표는 협상 근거도 계약 근거도 되지 못해요. 나눠 달라는 요청에 어렵다는 답이 돌아온다면 그것도 정보예요. 내부에서 산정 근거를 항목으로 갖고 있지 않다는 신호일 수 있으니까요.
표기 단위가 맞춰지고 나면 그다음에 볼 것은 각 항목에 붙은 상태 표시예요. 금액보다 먼저 봐야 하는 게 이 칸이에요. 같은 기능이라도 어떤 표시가 붙어 있느냐에 따라 그 줄의 뜻이 완전히 달라져요.
| 항목에 붙은 표시 | 실제로 뜻하는 것 | 다음에 할 일 |
|---|---|---|
| 포함이라고 적힘 | 이 금액 안에서 만들어져요 | 어디까지가 이 항목인지 화면과 예외 흐름을 물어봐요 |
| 제외라고 적힘 | 만들지 않아요. 적어 준 것 자체는 좋은 신호예요 | 넣으면 얼마가 붙는지 금액을 미리 받아 둬요 |
| 언급이 없음 | 포함도 제외도 아닌 상태예요 | 먼저 물어볼 칸이에요. 답을 반드시 문서로 받아요 |
| 전제 조건이 붙음 | 발주자가 무언가를 제때 준다는 조건에서만 이 금액이에요 | 조건을 못 지켰을 때 금액과 일정이 어떻게 바뀌는지 확인해요 |
| 조건부 포함 | 범위 안이지만 횟수나 범위에 상한이 있어요 | 상한을 넘기면 어떻게 되는지 문장으로 적어 달라고 해요 |
| 별도 협의 | 아직 값이 없다는 뜻이에요 | 협의 시점과 그때 쓸 산정 기준을 미리 정해 둬요 |
"언급이 없음" 칸은 계약 후에 다시 열리게 되는 자리예요. 포함이라고 믿은 쪽과 별도라고 생각한 쪽이 둘 다 근거를 갖지 못한 상태니까요. 이 칸을 견적 단계에서 없애 두면 나중에 범위를 두고 다투는 일이 줄어요. 표시를 채워 넣은 표를 업체에 그대로 다시 보내면 견적이 한 번 더 정확해지기도 해요.
공수 표기를 맨먼스로 받은 경우에는 그 숫자가 어떻게 쌓였는지 되짚어 볼 필요가 있어요. 견적서의 맨먼스 숫자가 타당한지 어떻게 검증하나요에서 검증 절차를 따로 다뤘어요. 앱 프로젝트라면 화면 수와 플랫폼 수가 곱해지는 구조라 표기 방식이 하나 더 늘어나는데, 단가 정규화와 운영 기간까지 포함한 총비용 비교는 앱 개발 견적서는 어떤 항목으로 비교하나요에 정리돼 있어요.
견적서를 펼쳤을 때 먼저 확인할 것은 금액이 아니라 금액이 어떤 단위로 만들어졌는가예요. 산정 단위는 크게 세 가지로 나뉘고, 각각 협상 가능성과 위험이 달라요.
| 산정 방식 | 구조 | 조정할 때 | 주의할 점 |
|---|---|---|---|
| 맨먼스와 맨데이 | 등급별 단가 곱하기 투입 공수 | 기능을 빼면 공수가 줄어 금액이 줄어요 | 등급 구성이 실제 투입 인력과 같은지 확인해야 해요 |
| 기능당 정액 | 기능 하나에 고정 금액 | 기능 단위로 빼고 넣기가 쉬워요 | 기능의 정의가 좁으면 세부 사항이 추가 항목이 돼요 |
| 총액 일괄 | 전체를 한 줄로 제시 | 조정 근거가 없어요 | 기능이 빠져도 금액이 그대로일 수 있어요 |
단가가 명시되지 않고 "전체 얼마"로만 적힌 견적은 협상할 근거가 사라진 견적이에요. 기능이 빠지거나 추가됐을 때 얼마를 빼고 얼마를 더해야 할지 계산할 방법이 없으니까요. 반대로 기능당 정액 견적은 단위 기능의 정의가 명확할 때만 안전해요. "로그인 기능"이라는 한 줄이 어디까지를 뜻하는지 적혀 있지 않으면, 정액이라는 말은 보호막이 아니라 해석 여지가 돼요.
읽기 좋은 견적서는 기능 단위가 화면과 API와 데이터 모델 수준까지 쪼개져 있어요. 읽기 어려운 견적서는 "회원 관리"처럼 대분류 한 줄로 끝나요. 이 차이는 취향의 문제가 아니라 나중에 돈이 되는 문제예요.
예를 들어 견적서에 "회원 관리"라는 한 줄만 있고 계약을 진행했다고 해 볼게요. 개발이 진행되는 중에 소셜 로그인 이야기가 나오면, 업체는 견적서에 소셜 로그인이 적혀 있지 않다는 이유로 별도 항목이라고 답할 수 있어요. 발주자는 회원 관리에 당연히 포함된다고 생각했고 업체는 회원 가입과 로그인만 잡았던 거예요. 둘 다 거짓말을 하지 않았는데 비용이 늘어나요. 원인은 나쁜 의도가 아니라 한 줄짜리 항목이에요.
쪼개는 기준은 화면 하나, API 하나, 저장되는 데이터 한 덩어리예요. 이 단위까지 내려가면 항목마다 공수를 붙일 수 있고, 공수가 붙으면 그 항목을 빼거나 미룰 때 금액이 어떻게 움직이는지 계산할 수 있어요. 반대로 대분류 한 줄짜리 항목은 빼도 얼마가 줄어드는지 알 수 없어서 협상 대상이 되지 못해요. 견적서를 잘게 쪼개 달라고 요청하는 건 까다롭게 구는 게 아니라, 나중에 조정할 수 있는 상태로 만들어 달라는 요청이에요.
그래서 확인 방법은 단순해요. 견적서 옆에 기능 명세와 화면 흐름이 함께 붙어 있어야 하고, 각 기능이 견적 항목과 하나씩 대응돼야 해요. 대응되지 않는 기능은 그 업체 기준으로 범위 밖이라고 보는 편이 안전해요. 대응 관계를 확인할 때는 다음 질문이 잘 들어요.
개발 견적에는 들어 있어도 실제 운영에 들어가는 비용은 빠져 있는 경우가 있어요. 개발사는 개발 비용을 적는 문서라고 생각하고, 발주자는 서비스를 굴리는 데 드는 총액이라고 읽어서 생기는 어긋남이에요. 이 항목들은 견적서에 없다고 사라지지 않고, 서비스가 살아 있는 동안 계속 나가요.
| 비용 항목 | 개발 기간 중 | 운영 이관 후 | 물어볼 문장 |
|---|---|---|---|
| 클라우드 호스팅, 데이터베이스, 스토리지 | 누가 결제하나요 | 계정 명의는 누구인가요 | 이관 시점과 절차를 적어 주실 수 있나요 |
| AI 모델 호출 비용 | 개발 테스트분은 포함인가요 | 사용량이 늘면 누가 부담하나요 | 사용량 상한과 알림은 어떻게 설정되나요 |
| 문자, 알림, 이메일 발송 | 테스트 발송 비용 포함 여부 | 발송 단가와 계약 주체 | 발송 계정은 처음부터 저희 명의로 열 수 있나요 |
| 결제 대행 연동 | 연동 개발 공수 포함 여부 | 수수료 계약 주체 | 심사 서류 준비는 누가 하나요 |
| 도메인과 인증서 | 구매 대행 여부 | 갱신 책임 | 갱신 실패 시 대응은 누구 몫인가요 |
| 오류 추적과 모니터링 도구 | 구축 포함 여부 | 구독 부담 주체 | 운영 이관 후에도 접근 권한이 유지되나요 |
| 백업과 로그 보관 | 보관 설정이 구축 범위인지 | 보관 기간과 저장 비용 부담 | 로그와 백업을 얼마나 오래 남기도록 설정하나요 |
여기서 핵심 질문은 금액이 아니라 명의예요. 개발사 명의로 열린 계정은 계약이 끝난 뒤 서비스의 목줄이 돼요. 비용을 개발사가 대신 결제하는 구조라면 이관 시점과 절차를 견적 단계에서 문서로 못 박아 두는 게 좋아요. 모델 호출처럼 사용량에 따라 늘어나는 비용은 상한과 알림 설정까지 함께 물어보면 나중에 놀랄 일이 줄어요.
"개발 완료 후 일정 기간 무상 유지보수"라는 문구가 있다면 반드시 무상의 정의를 물어봐야 해요. 같은 문장이 업체마다 다른 뜻으로 쓰여요. 어떤 곳은 납품한 기능이 명세대로 동작하지 않는 경우만 무상으로 보고, 어떤 곳은 운영 중 발생하는 문의 대응까지 포함해요. 정의가 다르면 기간의 길이는 의미가 없어요.
유지보수 항목은 최소한 이 정도로는 나뉘어 있어야 판단이 가능해요.
유지보수 단가가 개발 단가보다 높게 잡혀 있다면 그 자체로 문제는 아니지만 이유는 물어봐야 해요. 소규모 작업은 착수 비용이 붙기 때문에 단가가 올라갈 수 있고, 반대로 유지보수를 수익 구간으로 설계해 둔 경우도 있어요. 어느 쪽인지는 근거를 물어보면 드러나요. 계약 형태별 차이는 유지보수 계약에서는 무엇을 정해 둬야 하나요에 정리해 두었어요.
견적서에 QA 라인이 아예 없다면 둘 중 하나예요. 개발자가 자기 코드를 훑어보는 수준으로 검증을 끝낸다는 뜻이거나, QA 공수를 개발 공수 안에 섞어 넣고 겉으로는 무료처럼 보이게 했다는 뜻이에요. 후자라면 개발 항목의 공수가 부풀어 보이는 대신 검증 범위는 문서에 남지 않아요. 어느 쪽이든 검수 시점에 문제가 드러나요.
검증이 설계된 견적서는 이런 식으로 나뉘어 있어요.
검증 범위를 물어볼 때는 무엇을 테스트하는지보다 어떤 상태를 결함으로 보는지를 먼저 맞추는 게 좋아요. 기준이 없으면 발주자가 결함이라고 부르는 것을 개발사는 추가 요구로 읽어요. 화면 동작, 데이터 정합성, 예외 상황 처리, 성능 중 어디까지를 합격 조건에 넣을지 견적 단계에서 한 문장씩 적어 두면 검수 단계의 다툼이 크게 줄어들어요.
여기서 중요한 건 테스트를 했다는 사실이 아니라 테스트 결과가 문서로 남는가예요. 문서로 남지 않으면 검수 단계에서 무엇을 근거로 합격을 줄지 애매해져요. 검수 기준을 어떻게 잡는지는 산출물 검수는 무엇을 기준으로 합격을 주나요에서 다뤘어요.
프로젝트는 진행 중에 요구사항이 바뀌어요. 이건 실패가 아니라 정상 상태에 가까워요. 문제는 바뀌는 것 자체가 아니라, 바뀔 때 어떻게 처리할지가 정해져 있지 않은 상태예요. 절차가 없으면 변경 하나마다 협상이 새로 시작되고, 그 협상은 일정이 촉박한 시점에 벌어지기 쉬워요.
견적 단계에서 확인해 둘 조항은 이 정도예요.
마지막 항목은 눈에 잘 띄지 않아 빠지기 쉬워요. 추가는 청구되는데 축소는 반영되지 않는 구조면 변경 조항이 한쪽으로만 작동해요. 처리 흐름을 단계로 정리한 내용은 변경 요청은 어떤 단계를 거쳐 처리해야 하나요에 있어요.
이 항목은 프로젝트가 잘 끝난다는 전제에서는 아무 문제가 없어 보여서 견적 단계에서 밀리기 쉬워요. 그런데 확인이 필요한 시점은 프로젝트가 끝나는 시점이고, 그때는 이미 협상력이 발주자 쪽에 없어요. 잔금이 남아 있을 때만 조건을 바꿀 수 있어요.
소스코드 이관이 별도 유상 작업으로 적혀 있는 구조가 있을 수 있어요. 계약서 본문이 아니라 별첨이나 유지보수 조건 안에 들어 있기도 해요. 개발이 끝난 뒤 내부 팀으로 운영을 옮기려다 이관 비용을 다시 지불하게 되는 흐름이에요. 견적서를 받은 시점에 다음 항목을 확인하면 이 흐름을 피할 수 있어요.
마지막 항목은 놓치기 쉬운데 중요해요. 개발사가 여러 프로젝트에 쓰는 공통 모듈이 들어가 있으면, 코드는 넘어와도 그 부분만 사용 허락 형태로 남을 수 있어요. 이런 조항은 계약서에서 걸러내야 하고, 문제가 되는 문구는 계약서에서 반드시 걸러야 할 조항은 무엇인가요에 모아 두었어요.
같은 요구사항을 보냈는데 견적 금액이 크게 벌어졌다면, 어느 한쪽이 틀렸다고 단정하기 전에 차이의 원인부터 찾아야 해요. 금액 차이는 실력 차이일 수도 있고 해석 차이일 수도 있고 구조 차이일 수도 있어요. 원인에 따라 대응이 완전히 달라져요.
| 차이의 원인 | 드러나는 신호 | 확인 질문 |
|---|---|---|
| 범위 해석이 다름 | 한쪽 견적에만 있는 항목, 다른 쪽의 항목 수가 적음 | 이 기능은 귀사 견적의 어느 항목에 들어 있나요 |
| 투입 등급 구성이 다름 | 총 공수는 비슷한데 금액이 벌어짐 | 어떤 등급이 몇 명 투입되나요 |
| QA와 관리 공수 유무 | 개발 항목만 있고 검증 항목이 없음 | 검증과 프로젝트 관리는 어느 항목에 포함되나요 |
| 재하도급 구조 | 담당 인력에 대한 설명이 모호함 | 실제 개발은 어느 조직이 수행하나요 |
| 기간 압축 | 같은 범위인데 일정이 뚜렷하게 짧음 | 이 일정은 몇 명이 동시에 붙는 전제인가요 |
| 낮은 초기 금액과 변경 청구 구조 | 제외 범위가 길고 변경 단가가 높음 | 제외 범위에 있는 항목을 넣으면 총액이 얼마가 되나요 |
| 기술 선택이 다름 | 같은 결과에 대한 구현 방식 설명이 다름 | 이 방식을 고른 이유와 운영 비용은 어떻게 되나요 |
낮은 견적을 무조건 의심할 필요는 없어요. 다만 낮은 이유를 설명하지 못하는 견적은 의심해야 해요. 반대로 높은 견적도 마찬가지예요. 높은 이유를 항목으로 설명할 수 있으면 그건 근거 있는 금액이고, 설명하지 못하면 여유분을 얹은 금액일 수 있어요. 판단 기준은 금액의 크기가 아니라 설명 가능성이에요.
추가 청구는 악의에서만 나오지 않아요. 견적서에 적히지 않았고, 발주자는 당연히 포함이라고 생각했고, 개발사는 당연히 별도라고 생각한 항목에서 나와요. 그래서 계약 전에 "이건 포함인가요"라고 한 번씩 짚어 두는 것만으로 정리되는 항목이 많아요.
| 나중에 등장하는 항목 | 왜 견적서에서 빠지나요 | 계약 전 확인 문장 |
|---|---|---|
| 디자인 시안 수정 | 수정 횟수 기준이 적혀 있지 않아서 | 시안 수정은 몇 회까지 포함인가요 |
| 기존 데이터 이관 | 데이터 상태를 본 적이 없어서 | 이관 대상과 검증 방식은 어느 항목에 있나요 |
| 콘텐츠 입력과 초기 데이터 등록 | 개발이 아니라고 봐서 | 초기 데이터 등록은 누가 하나요 |
| 관리자 화면 | 사용자 화면만 세어서 | 관리자 기능은 어느 항목에 포함되나요 |
| 알림과 안내 문구 작성 | 개발 범위가 아니라고 봐서 | 발송 문구와 안내 문안은 누가 작성하나요 |
| 다국어와 반응형 대응 | 기본 사양으로 가정하지 않아서 | 지원 언어와 화면 폭 기준은 무엇인가요 |
| 운영 교육과 매뉴얼 | 산출물 목록에 없어서 | 운영 인수인계 교육이 포함되나요 |
| 검수 기간 중 수정 | 검수 절차가 정의되지 않아서 | 검수 중 수정 요청은 어디까지 무상인가요 |
이 표의 오른쪽 열을 그대로 복사해서 업체에 보내는 것도 좋은 방법이에요. 답변을 문서로 받아 두면 그 문서가 나중에 범위 다툼을 대신 막아 줘요.
견적을 받고 나면 금액을 낮추고 싶어져요. 그런데 협상은 값을 깎는 작업이라기보다 예산 추정을 다시 맞추는 작업에 가까워요. 현실적인 예산 추정이 서 있어야 어디를 조정할지 정할 수 있고, 조정한 결과가 프로젝트가 끝날 때까지 유지되려면 비용 관리 규칙까지 함께 정해 둬야 해요. 같은 금액을 낮추더라도 무엇을 깎았는지에 따라 결과가 완전히 달라져요. 범위를 깎으면 비용이 실제로 줄고, 품질을 깎으면 비용이 미뤄질 뿐이에요. 미뤄진 비용은 검수와 운영 단계에서 다시 나타나요.
| 깎는 대상 | 깎았을 때 일어나는 일 | 권하는 방향 |
|---|---|---|
| 기능 범위 | 공수가 실제로 줄어 금액이 줄어요 | 금액과 범위가 함께 줄어드는 유일한 자리예요 |
| 1차 출시 대상 | 일부 기능을 다음 단계로 미뤄요 | 단계를 나누면 검증 후에 결정할 수 있어요 |
| 디자인 범위 | 화면별 맞춤 디자인을 공통 규칙으로 대체해요 | 초기 버전이라면 합리적인 선택이 될 수 있어요 |
| 단가 | 등급이 낮은 인력으로 대체될 수 있어요 | 단가를 깎기보다 범위를 조정하는 편이 나아요 |
| QA 공수 | 결함이 검수와 운영 단계로 넘어가요 | 줄이지 않는 쪽을 권해요 |
| 프로젝트 관리 공수 | 소통과 일정 관리가 발주자 몫이 돼요 | 줄이려면 내부 담당자를 먼저 확보해야 해요 |
| 문서화 | 인수인계와 유지보수 비용이 올라가요 | 산출물 목록은 유지하는 편이 나아요 |
| 일정 | 같은 범위를 짧게 하면 인원이 늘거나 품질이 내려가요 | 일정 압축은 비용 절감이 아니에요 |
협상에서 힘이 되는 건 값을 깎아 달라는 요청이 아니라 범위를 정확히 아는 것이에요. 어떤 기능을 빼면 얼마가 줄어드는지 항목으로 알고 있으면, 금액을 낮추면서도 무엇을 포기하는지 스스로 통제할 수 있어요. 무엇을 빼도 되는지 판단하려면 첫 버전에 꼭 필요한 기능은 어떻게 고르나요가 기준이 돼요.
금액 자체보다 지급 구조를 조정하는 편이 나을 때도 있어요. 총액은 그대로 두고 단계별 지급 비중과 각 단계의 합격 조건을 조정하면, 발주자 입장에서는 위험이 줄고 개발사 입장에서는 매출이 유지돼요. 단계 설계는 대금을 어떤 단계로 나눠 지급해야 안전한가요를 참고하면 좋아요. 협상에서 조정한 범위와 금액은 그 자리에서 문서에 다시 적어 두세요. 그래야 이후 변경이 생길 때마다 무엇이 기준선이었는지 되짚을 수 있고, 비용 관리가 감이 아니라 기록으로 굴러가요.
견적서에서 합의한 내용이 계약서에는 다르게 적혀 있는 경우가 있어요. 서식을 옮겨 적는 과정에서 생기기도 하는데, 원인이 무엇이든 결과는 같아요. 분쟁이 생기면 계약서가 기준이 되기 때문에, 견적서에만 있는 좋은 조건은 없는 것과 비슷해져요.
그래서 계약 직전에 이 순서로 대조하는 게 좋아요.
어긋난 부분을 발견하면 구두로 확인받고 넘어가지 말고 문서를 고쳐 달라고 요청하는 게 맞아요. 이 요청에 대한 반응이 그 업체와 일하는 동안의 소통 방식을 미리 보여 주기도 해요. 일정 조항을 어떻게 문서로 옮기고 관리하는지는 프로젝트 일정표는 어떻게 만들고 관리하나요에서 다뤘어요.
정리하면 순서는 이래요. 먼저 같은 자료를 여러 업체에 동일하게 보내고, 돌아온 견적서의 표기 단위를 하나로 맞춘 다음 항목마다 상태 표시를 채워요. 그다음 산정 단위, 기능 세분화, 인프라와 외부 서비스 비용, 유지보수, 검증 공수, 변경 절차, 소유권과 인수인계를 항목별로 확인해요. 금액 차이가 크면 원인을 먼저 찾고, 협상은 단가가 아니라 범위와 지급 구조에서 해요. 마지막으로 합의된 내용이 계약서에 그대로 옮겨졌는지 대조하고 서명해요.
견적서가 뭉뚱그려진 업체는 개발 중에도 뭉뚱그려 소통할 가능성이 있어요. 반대로 항목을 쪼개서 보여 주는 업체는 일정과 품질을 다루는 방식도 같은 결로 드러나요. 그래서 견적서를 읽는 시간은 가격을 비교하는 시간이 아니라 앞으로 몇 달간 함께 일할 방식을 미리 확인하는 시간에 가까워요.
웹사이트처럼 항목 구성이 비교적 정형화된 프로젝트라면 금액을 가르는 변수부터 확인하는 편이 빨라요. 홈페이지 제작 비용은 무엇에 따라 갈리나요에서 변수별 차이를 정리해 두었어요.
제안서는 문제를 어떤 접근으로 풀겠다는 계획을 담은 문서이고, 견적서는 그 접근을 실행하는 데 드는 비용을 항목으로 적은 문서예요. 제안서만 받으면 금액 근거를 알 수 없고, 견적서만 받으면 왜 그렇게 만드는지를 알 수 없어요. 비교할 때는 두 문서를 함께 받아서 제안서의 범위와 견적서의 항목이 서로 대응되는지 확인하는 게 좋아요. 대응되지 않는 부분이 나중에 해석 차이가 생기는 자리예요.
유효기간을 적어 달라고 요청하는 게 좋아요. 기간이 없으면 검토하는 동안 인력 사정이나 일정 전제가 바뀌었다는 이유로 금액이 조정될 수 있어요. 언제까지 이 금액과 일정이 유지되는지, 기간이 지나면 무엇이 달라지는지 한 줄로 받아 두면 내부 결재와 업체 비교에 그대로 쓸 수 있어요.
그 자체로 문제는 아니에요. 요구사항이 정리되지 않은 상태에서 상세 견적을 뽑으려면 분석과 설계에 가까운 작업이 필요하고, 거기에는 실제로 공수가 들어가요. 확인할 것은 비용의 유무가 아니라 산출물이에요. 유상으로 진행한다면 결과물인 요구사항 정의와 산정 근거를 발주자가 가져가서 다른 업체 비교에도 쓸 수 있는지 먼저 물어보세요.
사업 자료나 데이터를 넘겨야 한다면 요청 전에 맺는 편이 안전해요. 다만 비밀유지 계약이 있다고 모든 자료를 한 번에 열어야 하는 건 아니에요. 견적 산정에 필요한 범위, 즉 기능 목록과 연동 대상 정도를 먼저 주고 계약 단계에서 세부 자료를 여는 순서로 나눠도 견적 정확도에는 큰 문제가 없어요.
총액 옆에 부가세 별도인지 포함인지 문구가 있는지 먼저 봐요. 표기가 없으면 업체에 확인해서 문서에 적어 달라고 요청하세요. 별도인지 포함인지에 따라 실제 집행 금액이 달라지고, 여러 업체를 비교할 때 한쪽만 별도 표기라면 비교 자체가 어긋나요. 검토표에는 같은 기준으로 통일해 옮겨 적는 게 좋아요.
정해진 숫자는 없어요. 기준은 같은 자료를 동일하게 보내고, 돌아온 견적서를 전부 같은 표에 옮겨 검토할 수 있는 범위인지예요. 업체를 늘릴수록 판단 품질이 올라가는 게 아니라, 자료를 동일하게 주지 못해 비교가 무너지는 일이 생겨요. 감당할 수 있는 만큼만 부르고 대신 요청 자료를 똑같이 맞추세요.
투입 인력의 소속과 계약 형태를 문서로 물어보면 돼요. 재하도급이 있다는 사실 자체보다, 책임 소재와 인수인계 경로가 길어지는 게 위험 요소예요. 하도급이 포함된다면 최종 책임이 계약 상대방에게 있다는 조항, 그리고 산출물과 계정이 발주자에게 직접 넘어온다는 조항을 함께 확인하세요.
알려 주는 편이 견적 품질에는 유리해요. 예산을 숨기면 업체는 범위를 임의로 가정해 견적을 만들고, 그 가정이 어긋나면 비교가 무의미해져요. 예산을 밝히면 그 안에서 무엇을 넣고 무엇을 뺄지 제안을 받을 수 있어요. 다만 금액만 알려 주지 말고 기능 목록과 함께 주고, 그 예산으로 무엇이 가능한지 항목으로 답을 받으세요.