§ COST — KAIZEN KR

앱·웹 개발 외주 비용견적서를 읽는 법

금액표는 싣지 않습니다. 범위가 정해지기 전에 나온 숫자는 지킬 수 없는 약속이기 때문입니다. 대신 견적이 무엇으로 갈리고, 받은 견적서에 무엇이 적혀 있어야 하는지 적었습니다.

견적 문의하기 →개발 외주 서비스 보기
§01
전제

금액표를 걸지 않는 이유

“○○부터” 형태로 금액만 큼직하게 걸어 둔 문장은 검색에서는 클릭을 얻지만, 첫 통화에서 신뢰를 잃습니다. 그 숫자가 어떤 범위를 가정한 것인지 적힌 곳이 없기 때문입니다. 스니펫에 잘려 나가면 더 나쁩니다. 가정은 사라지고 숫자만 남습니다.

N° 01

같은 화면 수가 몇 배씩 갈립니다

화면 열 개짜리 소개 사이트와, 권한과 결제와 정산이 얽힌 화면 열 개는 다른 일입니다. 화면 수로 단가를 매기면 앞쪽 견적으로 뒤쪽 일을 받게 되고, 그 차이는 결국 품질이나 추가 청구로 메워집니다. 무엇이 견적을 가르는지는 개발 외주 비용을 정하는 것에 여섯 가지로 정리해 두었습니다.

N° 02

구간은 한 시간이면 나옵니다

필요한 화면과 반드시 붙어야 하는 연동, 오픈 시점만 정리되면 대부분 첫 통화에서 금액 구간이 잡힙니다. 그 정리까지는 무료이고, 정리한 내용은 저희와 진행하지 않더라도 그대로 쓰실 수 있는 문서로 남깁니다.

N° 03

기간은 근거가 있어 적습니다

동작하는 MVP는 보통 4~8주, 실제 트래픽을 받는 프로덕션은 8~16주를 기준으로 산정합니다. 이것은 금액과 달리 범위와 거의 무관하게 반복되는 값이라 미리 적어 둘 수 있습니다.

§02
견적서

견적서에 있어야 하는 것

여러 곳에서 받은 견적을 비교할 때는 총액보다 무엇이 빠져 있는지를 먼저 보십시오. 낮은 금액은 대개 범위가 좁게 잡혀 있다는 뜻입니다. 아래 일곱 개는 저희 견적서에 들어가는 항목이고, 다른 곳 견적서를 읽을 때도 그대로 쓰실 수 있습니다.

N° 01

화면 목록과 각 화면의 완성 기준

화면 이름만 나열된 견적서는 견적서가 아닙니다. 각 화면에서 사용자가 무엇을 할 수 있어야 완성인지가 적혀 있어야, 나중에 “그건 범위 밖입니다”라는 말이 나올 자리가 없어집니다.

N° 02

외부 연동 목록과 각각의 담당

결제, 본인인증, 알림톡, 지도, 사내 시스템. 연동마다 계정과 심사, 비용을 누가 준비하는지가 갈립니다. 이것이 빠진 견적서는 오픈 직전에 일정이 밀리는 가장 흔한 원인입니다.

N° 03

테스트와 배포에 들어가는 몫

기능 개발만 적고 테스트와 배포 자동화가 빠진 견적은 총액이 낮아 보입니다. 그 일이 없어진 것이 아니라 나중에 청구되거나, 품질이 낮은 채로 넘어옵니다.

N° 04

인수인계 산출물

소스 코드, 배포 문서, 계정과 권한, 운영 매뉴얼 중 무엇을 받는지 적혀 있어야 합니다. 코드만 받고 배포 방법을 모르면 다음 업체가 처음부터 다시 시작합니다.

N° 05

변경 요청을 다루는 방식

범위가 늘어날 때 어떻게 처리하는지가 계약서에 있어야 합니다. 문서로 남기고 일정과 금액 영향을 먼저 알리는지, 아니면 조용히 진행하고 나중에 청구하는지의 차이입니다.

N° 06

하자보수 기간과 그 범위

오픈 후 몇 개월 동안 무엇을 무상으로 고치는지 정해 두십시오. 버그와 기능 추가의 경계가 없으면 양쪽 다 손해를 봅니다.

N° 07

지급 시점과 조건

선금 비율과 중간 지급 시점, 그리고 무엇이 확인되면 지급하는지가 함께 적혀야 합니다. 일정에만 묶인 지급 조건은 진행 상황과 무관하게 돌아갑니다.

§03
계약

고정가와 시간제

어느 쪽이 항상 낫다는 답은 없습니다. 범위가 얼마나 정해져 있는지에 따라 갈립니다. 잘못 고르면 총액이 아니라 진행 방식이 먼저 무너집니다.

N° 01

고정가

범위가 명확할 때 유리합니다. 총액이 먼저 정해지니 예산을 세우기 쉽고, 개발사가 일정을 관리할 이유도 분명합니다. 다만 범위가 흐린 상태에서 묶으면 변경마다 추가 계약이 붙고, 결과적으로 시간제보다 비싸집니다. 만들면서 방향을 정하고 싶다면 맞지 않는 형태입니다.

N° 02

시간제

요구사항이 진행 중에 구체화되는 프로젝트에 맞습니다. 실제로 쓴 만큼 청구하니 필요 없는 기능에 돈이 가지 않습니다. 다만 총액 상한과 주 단위 보고가 없으면 예산 관리가 무너집니다. 저희는 상한을 정하고, 그 상한에 근접하면 남은 범위를 다시 정리합니다.

N° 03

단계 분리

규모가 크면 요구사항 정리와 설계를 별도 계약으로 먼저 끝내는 방식이 총액을 가장 크게 줄입니다. 설계가 끝난 뒤 견적을 다시 내면 추정 폭이 좁아지고, 그 시점에 개발사를 바꾸는 것도 가능합니다. 이 단계를 팔기 위해 붙잡아 두는 구조는 만들지 않습니다.

§04
준비

문의 전에 정해 두면 좋은 것

아무것도 없이 문의하셔도 됩니다. 다만 아래 세 가지가 정해져 있으면 첫 통화에서 구간이 잡히고, 견적의 추정 폭이 크게 좁아집니다.

N° 01

화면 목록

완성된 기획서는 필요 없습니다. 필요한 화면을 열 줄 정도로 적은 목록이면 충분합니다. 참고하고 싶은 서비스 링크가 있으면 그것이 문서 열 장보다 정확합니다.

N° 02

반드시 붙어야 하는 것

결제 수단, 본인인증 방식, 기존에 쓰던 사내 시스템처럼 협상 대상이 아닌 조건을 먼저 알려주십시오. 견적의 폭을 가장 크게 줄이는 정보입니다.

N° 03

오픈 시점과 그 이유

날짜만 있으면 일정을 압축하는 방법이 하나뿐입니다. 왜 그 시점인지 알면 무엇을 1차에서 빼고 무엇을 남길지 같이 정할 수 있습니다.

§05
자주 묻는 질문

비용에 대해 자주 받는 질문

대략적인 금액이라도 알 수 있나요?

범위를 한 시간 정도 같이 정리하면 그 자리에서 구간을 말씀드립니다. 그 전에 나오는 숫자는 추측이라 적어 두지 않습니다. 화면 목록과 필요한 연동만 정해지면 대부분 첫 통화에서 구간이 잡힙니다.

앱 개발 외주 단가는 어떻게 계산되나요?

인원 수와 기간을 곱한 값이 기준선이고, 거기에 연동 난이도와 완성 기준을 반영합니다. 화면당 단가나 기능당 단가로 계산하는 곳도 있지만, 같은 화면이 뒤에서 하는 일에 따라 몇 배씩 갈리기 때문에 저희는 쓰지 않습니다.

고정가와 시간제 중 어느 쪽이 유리한가요?

범위가 명확하면 고정가가 유리합니다. 만들면서 방향이 바뀔 여지가 크면 시간제가 총액이 낮게 끝나는 경우가 많습니다. 범위가 흐린 상태에서 고정가로 묶으면 변경마다 추가 계약이 붙어 결과적으로 더 비싸집니다.

견적을 받으려면 무엇을 준비해야 하나요?

쓰고 싶은 화면을 대략 적은 목록, 반드시 붙어야 하는 외부 서비스, 원하는 오픈 시점, 이 세 가지면 시작할 수 있습니다. 기획서가 없어도 됩니다. 참고하고 싶은 서비스 링크가 있으면 그것이 문서 열 장보다 빠릅니다.

가장 싼 견적을 고르면 안 되는 이유가 있나요?

금액이 낮은 견적은 대개 범위가 좁게 잡혀 있습니다. 테스트, 배포 자동화, 운영 문서, 인수인계가 빠진 견적은 그 일이 없어진 것이 아니라 나중에 청구되는 것입니다. 견적서를 비교할 때는 총액보다 무엇이 빠져 있는지를 먼저 보십시오.

유지보수 비용은 따로인가요?

별도입니다. 다만 유지보수를 함께 맡기로 정하면 초기 구조를 운영 관점으로 잡기 때문에 나중에 드는 비용이 줄어듭니다. 월 단위 운영과 건별 대응 중에 선택하실 수 있습니다.

계약 후에 범위가 늘어나면 비용은 어떻게 되나요?

변경 요청을 문서로 남기고, 일정과 금액에 어떤 영향이 있는지 먼저 알려드린 뒤 진행 여부를 정합니다. 조용히 밀어 넣고 나중에 청구하지 않습니다. 작은 변경은 잔여 범위 안에서 조정하는 편입니다.

ESTIMATE

범위부터 같이 정리해 보시겠습니까?

범위 정리와 구간 산정까지는 무료입니다. 정리한 문서는 저희와 진행하지 않더라도 그대로 쓰실 수 있습니다.

개발 외주 견적 문의 →서비스와 진행 방식 보기