시스템 개발 견적이 회사마다 3배씩 차이 나는 이유

같은 요구사항 정의서를 세 회사에 보냈는데 400만 엔, 900만 엔, 1,200만 엔이 나란히 돌아온다. 어디가 부당하게 비싼 건지, 싼 곳이 대충 할 생각인 건지 판단이 안 선다. 발주 직전에 이 상태로 멈춰 있는 회사가 많다.

금액 차이 자체는 이상한 일이 아니다. 견적은 네 가지 숫자를 곱하고 더한 결과라서, 하나만 달라져도 전체가 몇 배로 벌어진다. 거꾸로 말하면 네 가지로 쪼개 보면 차이가 어디서 왔는지 설명이 된다.

견적은 네 가지 숫자로 이루어진다

금액 = 공수 × 단가 + 버퍼
       ↑ 여기에 '어디까지 포함하느냐'가 작용한다

견적서에는 합계 금액만 적혀 있지만 내역은 이런 구조다. 세 배 차이가 날 때는 네 가지 중 여러 개가 동시에 어긋나 있다.

공수 — 무엇을 셌느냐에 따라 달라진다

'로그인 기능'을 견적 낼 때 구현만 세느냐, 설계·리뷰·테스트·버그 수정·사양 변경 반영까지 세느냐에 따라 같은 기능이 3인일도 되고 12인일도 된다.

경험 있는 회사일수록 후자를 센다. 구현이 끝난 뒤 테스트와 리뷰에 그만큼의 시간이 더 든다는 걸 알기 때문이다. 세지 않은 회사의 견적서가 가벼워 보이는 건 그 작업이 사라져서가 아니다. 아직 안 셌을 뿐이다.

공수가 작은데도 대충 하는 게 아닌 경우도 있다. 인증·관리 화면·권한 쪽 사내 템플릿을 가진 회사는 매번 처음부터 만들지 않는다. 재사용할 부분이 많을수록 공수는 정당하게 줄어든다. "왜 그 공수로 되는지"를 물어보면 구분할 수 있다.

단가 — 누가 작업하는가

인월(MM) 단가는 회사 규모와 체제로 정해진다. 원청이 받아서 하청에 넘기는 구조라면 중간 마진이 단가에 얹힌다. 단가가 높은 회사가 나쁜 게 아니다. 그 돈을 내고 누가 실제로 손을 움직이는지가 보이느냐가 문제다.

물어볼 건 정해져 있다. 설계하는 사람과 구현하는 사람이 같은가. 프로젝트에 몇 명이 어느 정도 비율로 투입되는가. 중간에 멤버가 바뀌는 걸 전제로 하는가. 단가만 비교해서는 의미가 없다.

포함 범위 — 차이가 가장 크게 나는 곳

금액이 크게 벌어지는 건 여기다. 견적서에 금액으로 적히지 않는 항목들이 있다.

항목	빠져 있으면 어떻게 되나
요구사항 정의 참여	정해지지 않은 사양을 발주 측이 전부 채워야 한다
테스트	동작 확인이 발주 측 일이 된다. 버그는 릴리스 후에 나온다
환경 구축 (운영·스테이징)	개발은 끝났는데 돌릴 곳이 없다
CI / 배포 구조	매번 수작업으로 릴리스하게 된다
모니터링·백업	장애를 사용자 연락으로 알게 된다
문서	다음 개편을 다른 회사에 맡길 수 없다
데이터 이관	기존 시스템에서 옮기는 작업이 별도 견적이 된다
릴리스 후 버그 대응	검수 후 수정이 추가 비용이 된다

빠져 있다는 것 자체가 불성실한 건 아니다. "그 전제로 낸 견적입니다"라는 얘기고, 전제가 적혀 있으면 제대로 된 견적서다. 문제는 전제가 안 적힌 견적서 쪽이다. 그런 경우 나중에 추가 비용으로 돌아온다.

버퍼 — 불확실성에 대한 보험

요구사항이 모호할수록 견적 내는 쪽은 여유를 둔다. "세부 사항은 개발하면서 정한다"고 적힌 요구사항에 최악의 경우를 가정한 숫자를 내는 건 당연한 판단이다.

여기는 발주 측이 움직일 수 있는 몇 안 되는 변수이기도 하다. 사양을 한 단계 더 구체화한 뒤 다시 견적을 받으면 금액이 내려가는 경우가 있다. 비싸다고 느낄 때 가격을 깎는 협상보다 요구사항을 구체화하는 쪽이 효과가 있다.

싼 견적에서 빠져 있는 것

싼 견적서를 봤을 때 확인하는 순서는 대체로 정해져 있다.

테스트. 단위 테스트를 작성하는지, 통합 테스트는 누가 하는지. 테스트를 안 쓰는 전제의 견적은 초기 비용이 내려가는 대신, 고칠 때마다 동작 확인 공수가 늘어난다. 반년 운영하면 역전되기도 한다.

환경 구축. 운영 환경뿐 아니라 검증용 환경도 만드는지. 검증 환경이 없는 프로젝트는 운영에서 처음 확인하게 된다.

비기능 요구사항. 동시에 몇 명이 쓰는지, 응답 속도는 어느 정도인지, 데이터가 날아갔을 때 어디까지 되돌릴 수 있는지. 이 세 가지가 요구사항에 없으면 견적에서도 빠진다. 나중에 성능이 안 나온다는 걸 알고 다시 만드는 건 비싸다.

릴리스 후 대응 기간. 납품 후 얼마 동안 버그를 무상으로 고쳐주는지. 1개월인지 3개월인지, 아예 없는지.

문서. 환경 구축 절차와 데이터 구조 설명이 없으면, 나중에 다른 회사로 넘길 때 비용이 확 뛴다.

비교할 때 볼 것

금액을 나란히 놓기 전에 견적서를 같은 조건으로 맞추는 작업이 필요하다.

1. 전제 조건이 적혀 있는가. "~는 포함하지 않습니다"가 명시된 견적서는 믿을 만하다. 아무것도 안 적힌 견적서는 비교할 재료가 부족하다
2. 쪼개져 있는가. 일괄 얼마가 아니라 기능별 공수가 나열돼 있는가. 쪼개져 있으면 어떤 기능을 빼야 예산에 맞는지 발주 측이 판단할 수 있다
3. 검수 기준. 무엇을 기준으로 완료로 보는가. 이 기준이 모호한 프로젝트는 막바지에 "이건 추가입니다", "아니, 포함돼야죠" 하는 줄다리기가 된다
4. 변경하면 어떻게 되는가. 도중에 사양을 바꿨을 때의 처리. 매번 따로 견적인지, 일정 범위까지는 포함인지
5. 유지보수와 운영. 월 얼마에 무엇을 해주는지. 장애 시 연락처와 대응 시간대
6. 유효 기간과 재견적 조건. 요구사항이 바뀌면 언제 다시 내는지

이 여섯 가지를 맞추면 금액 차이의 일부는 전제의 차이로 설명이 된다. 그걸 걷어내고 남은 금액이 비교해야 할 진짜 차이다.

정당한 차이와 그렇지 않은 차이

정당한 차이는 설명할 수 있는 차이다. 범위가 넓다, 테스트를 쓴다, 경험 있는 멤버가 들어간다, 이관 작업을 포함한다. 이유를 물으면 숫자가 어디서 움직였는지 짚어 줄 수 있다.

그렇지 않은 차이는 물어봐도 답이 안 온다. "대략 이 정도입니다"로 끝나는 견적은 근거가 없거나 내역을 보여주고 싶지 않거나 둘 중 하나다. 어느 쪽이든 발주 후에 금액이 바뀔 가능성이 높다.

금액이 크냐 작냐보다 질문에 숫자로 답이 돌아오는지를 보는 게 덜 틀린다.

판단이 안 설 때

견적서를 나란히 놓고도 못 정할 때는, 대개 견적의 문제가 아니라 발주 측에 판단 재료가 부족한 것이다. 전제 조건이 안 적힌 견적서는 쓴 쪽에 물어보면 채워진다. 무엇을 어떻게 물어야 할지 모르는 단계에서 멈춰 있는 경우가 많다.

저희는 다른 회사 견적을 보신 뒤의 상담도 받고 있습니다. 발주처를 정하기 전 단계에서, 전제 조건을 맞추는 방법이나 요구사항을 어디까지 구체화하면 금액이 달라지는지에 대해 이야기 나눌 수 있습니다. 상담만 하고 끝나셔도 괜찮습니다.

→ 상담하기