초록
외주 개발을 준비하는 의뢰인이 여러 업체에 같은 문서를 보내고 받은 견적이 두세 배로 벌어지는 상황은 예외가 아니라 오히려 표준에 가깝습니다. 이 글은 그 격차의 상당 부분이 업체의 정직성이나 실력 차이가 아니라, 견적서가 서로 다른 것을 세고 있기 때문에 발생하는 측정 단위의 문제라는 관점에서 출발합니다. 총액이라는 하나의 숫자는 범위, 품질 수준, 일정 압축 정도, 리스크를 누가 떠안는가, 그리고 오픈 이후 운영이 포함되는가라는 다섯 개의 독립적인 축이 곱해진 결과물인데, 견적서는 이 다섯 축을 분리해 표기하지 않은 채 최종 숫자만 제시하는 경우가 대부분입니다. 본 글은 먼저 견적서가 구조적으로 비교 불가능해지는 세 가지 원인을 진단하고, 이어서 서로 다른 형식의 견적서를 같은 단위로 환산하는 다섯 단계의 정규화 절차를 제시합니다. 마지막으로 정규화를 마친 뒤에도 여전히 남는 가격 차이를 어떻게 해석해야 하는지, 그리고 최저가가 합리적 선택이 되는 조건과 그렇지 않은 조건을 구분하는 기준을 논의합니다. 특정 업체의 단가나 시세표는 다루지 않으며, 가격표가 바뀌어도 유지되는 비교 절차 자체에 초점을 맞춥니다.
1. 서론
1.1 문제 제기
세 곳에서 견적을 받았는데 하나는 800만 원, 하나는 1,600만 원, 하나는 2,400만 원이라는 상황을 생각해 봅시다. 의뢰인의 첫 반응은 대체로 두 갈래로 나뉩니다. 하나는 "가장 싼 곳이 뭔가를 빠뜨렸거나 나중에 추가 비용을 청구할 것"이라는 의심이고, 다른 하나는 "가장 비싼 곳이 거품을 붙였다"는 의심입니다. 두 해석 모두 가능하지만, 두 해석의 공통된 전제—세 견적이 같은 대상을 측정한 결과라는 전제—는 대체로 성립하지 않습니다.
같은 요구사항 문서를 받았더라도, 각 업체는 그 문서의 빈칸을 서로 다르게 메웁니다. "회원 관리 기능"이라는 한 줄은 어떤 업체에게는 이메일 가입과 로그인만을 뜻하고, 다른 업체에게는 소셜 로그인·비밀번호 재설정·탈퇴 처리·개인정보 동의 이력까지 포함하는 묶음을 뜻합니다. "관리자 페이지"는 목록과 상세 조회만을 의미할 수도 있고, 권한 등급별 접근 제어와 변경 이력 추적까지 포함할 수도 있습니다. 이 해석 차이는 견적서 위에서 눈에 보이지 않습니다. 두 견적서 모두 "회원 관리"라는 같은 항목명을 쓰고, 그 옆에 다른 숫자를 적을 뿐입니다.
문제는 이 구조 안에서 의뢰인이 취할 수 있는 가장 자연스러운 행동—총액을 나란히 놓고 비교하는 것—이 체계적으로 잘못된 결론을 유도한다는 점입니다. 총액 비교는 암묵적으로 "범위가 동일하다"는 가정을 깔고 있는데, 바로 그 가정이 성립하지 않는 것이 격차의 원인이기 때문입니다. 결과적으로 이 비교는 가장 적게 포함한 견적을 가장 매력적으로 보이게 만드는 편향을 갖습니다. 그리고 그 편향이 실현되는 시점은 계약 이후, 빠져 있던 항목이 하나씩 추가 요청으로 돌아오는 중반부입니다. 이 전개는 외주 개발사가 절대 알려주지 않는 비용의 비밀에서 다룬 초기 견적과 최종 청구액의 괴리와 같은 뿌리를 갖습니다.
1.2 기여와 범위
이 글의 기여는 세 가지입니다. 첫째, 견적서가 비교 불가능해지는 원인을 업체의 태도 문제가 아니라 문서 형식이 만들어 내는 구조적 결과로 재정의하고, 그 원인을 범위의 암묵성·단위의 불일치·리스크 배분의 비대칭이라는 세 가지로 분해합니다. 둘째, 서로 다른 형식으로 도착한 견적서를 같은 축 위에 올리는 다섯 단계의 정규화 절차를 제시하고, 각 단계에서 업체에 되물어야 할 질문을 구체화합니다. 셋째, 정규화를 마친 뒤에도 남는 가격 차이를 "누가 리스크를 떠안기로 했는가"라는 질문으로 번역하여, 최저가 선택이 합리적인 조건과 그렇지 않은 조건을 구분합니다.
범위는 다음으로 한정합니다. 이 글은 특정 기능의 적정 단가나 시세표를 제시하지 않습니다. 단가는 기술 스택·팀 구성·시점에 따라 크게 달라지며, 어떤 숫자를 제시하더라도 그것이 독자의 상황에 맞는다는 보장이 없습니다. 대신 이 글은 "숫자가 얼마여야 하는가"가 아니라 "숫자들을 어떻게 같은 자리에 놓는가"라는 절차적 질문에 집중합니다. 대략적인 규모 감각이 먼저 필요하다면 외주 개발 비용 계산기로 종류와 기능을 골라 범위를 확인한 뒤 이 글의 절차로 돌아오는 순서를 권합니다. 또한 이 글은 계약서의 법적 조항, 대금 지급 조건, 세무 처리 같은 계약 실무는 다루지 않습니다. 이 영역은 별도의 전문성이 필요하며, 견적 비교라는 이 글의 주제와는 독립적으로 검토되어야 합니다.
2. 배경: 견적서가 비교 불가능해지는 세 가지 원인
2.1 범위의 암묵성 — 빈칸을 누가 메웠는가
요구사항 문서에는 반드시 빈칸이 있습니다. 의뢰인이 아무리 성실하게 작성해도, 개발을 해본 적이 없다면 무엇을 명시해야 하는지 자체를 알기 어렵기 때문입니다. 이 빈칸은 사라지지 않고, 견적을 산정하는 쪽이 자신의 경험을 근거로 메웁니다. 여기서 결정적인 비대칭이 발생합니다. 빈칸을 넉넉하게 메운 업체는 총액이 올라가고, 최소한으로 메운 업체는 총액이 내려갑니다. 두 업체 모두 자신의 기준에서는 정직하게 산정했지만, 견적서 위에서는 후자가 우월해 보입니다.
이 암묵성이 특히 위험한 이유는, 빈칸을 좁게 메운 견적이 틀린 견적이 아니라 다른 계약이기 때문입니다. 나중에 "이건 견적에 없던 기능입니다"라는 말이 나올 때, 그 말은 대체로 사실입니다. 문서에 명시되지 않았고, 업체는 그것을 포함하지 않은 상태로 산정했습니다. 분쟁의 형태를 띠지만 실제로는 해석 차이이며, 해석 차이는 계약 이후에 해소하려 하면 거의 항상 의뢰인에게 불리하게 정산됩니다.
2.2 단위의 불일치 — 무엇을 세는가
두 번째 원인은 견적서가 세는 단위 자체가 다르다는 점입니다. 어떤 견적서는 화면 수를 세고, 어떤 견적서는 기능 단위를 세며, 어떤 견적서는 투입 인월(man-month)을 셉니다. 화면 기준 견적은 화면 하나에 얼마나 복잡한 로직이 붙는지를 반영하지 못하고, 인월 기준 견적은 결과물의 범위를 보증하지 않으며, 기능 기준 견적은 기능의 경계를 어떻게 그었는지에 따라 개수가 달라집니다.
세 단위는 서로 자동 변환되지 않습니다. 화면 20개짜리 견적과 3인월 견적을 나란히 놓는 것은 무게와 길이를 비교하는 것과 구조적으로 같습니다. 그럼에도 두 견적서 모두 마지막 줄에는 원화 총액이 적혀 있기 때문에, 비교 가능하다는 착시가 생깁니다. 공통 화폐 단위의 존재가 공통 측정 대상의 존재를 보증하지 않는다는 것이 이 원인의 핵심입니다.
2.3 리스크 배분의 비대칭 — 불확실성의 가격
세 번째 원인은 가장 덜 인식되지만 격차에 가장 크게 기여합니다. 모든 견적에는 불확실성이 포함되어 있고, 그 불확실성을 누가 떠안느냐가 가격에 직접 반영됩니다. 요구사항이 흔들릴 가능성, 외부 시스템 연동이 문서대로 동작하지 않을 가능성, 검수 기간이 늘어질 가능성—이런 위험을 업체가 흡수하기로 하면 견적에는 완충이 붙고, 의뢰인이 떠안기로 하면 견적은 얇아지는 대신 변경 시마다 추가 정산이 발생합니다.
이 배분은 견적서에 거의 표기되지 않습니다. 표기되지 않은 채로 가격에만 반영되므로, 의뢰인이 보는 것은 "완충을 포함한 견적"과 "완충을 뺀 견적"의 총액 차이일 뿐이고, 그 차이가 어디서 왔는지는 보이지 않습니다. 결과적으로 의뢰인은 자신도 모르는 사이에 더 싼 가격과 함께 더 많은 리스크를 선택하게 됩니다. 이 선택이 언제나 잘못된 것은 아니지만, 그것이 선택이라는 사실 자체를 인지하지 못한 채 이루어진다는 점이 문제입니다.
3. 분석틀: 총액을 다섯 축으로 분해하기
앞의 세 원인을 실무에서 다루려면, 견적 총액을 곱셈의 결과로 보는 관점이 필요합니다. 이 글은 총액을 다음 다섯 축의 조합으로 분해합니다.
- 범위(Scope): 무엇을 만드는가. 기능 목록과 각 기능의 경계.
- 품질(Quality): 어느 수준으로 만드는가. 디자인 맞춤 정도, 접근성, 브라우저·기기 대응 폭, 테스트 수준.
- 일정(Time): 언제까지 만드는가. 일정을 압축할수록 동시 투입 인원이 늘어 단위당 비용이 올라갑니다.
- 리스크(Risk): 예상 밖의 일이 생기면 누가 부담하는가. 요구사항 변경, 연동 실패, 검수 지연.
- 운영(Run): 오픈 이후는 포함되는가. 하자 보수 기간, 유지보수 계약, 인수인계 산출물.
이 분해가 유용한 이유는, 앞 절에서 다룬 세 원인이 각각 다른 축에 붙기 때문입니다. 범위의 암묵성은 Scope 축의 문제이고, 단위의 불일치는 Scope와 Time을 뒤섞어 표기하는 데서 오며, 리스크 배분의 비대칭은 Risk 축이 아예 표기되지 않는 데서 옵니다. 다섯 축 중 견적서에 명시적으로 적히는 것은 대체로 Scope 일부와 Time뿐이고, Quality·Risk·Run은 총액 안에 녹아든 채 보이지 않습니다.
정규화란 결국 보이지 않는 세 축을 표면으로 끌어올려, 모든 견적이 같은 다섯 칸을 채우도록 만드는 작업입니다. 이 작업이 끝나면 총액의 차이는 더 이상 미스터리가 아니라 "A는 Run을 포함했고 B는 빼놓았다"는 식의 읽을 수 있는 차이가 됩니다. 다음 다섯 개 장에서 각 축을 하나씩 정규화하는 절차를 다룹니다.
4. 절차 1 — 범위를 기능 목록으로 환원한다
4.1 견적서가 아니라 목록을 맞춘다
정규화의 첫 단계는 견적서를 비교하는 것이 아니라, 비교의 기준이 될 목록을 의뢰인이 먼저 만드는 것입니다. 각 업체가 자기 형식으로 작성한 견적서를 사후에 맞추려 하면, 항목명이 겹치지 않아 대응 관계를 만드는 데만 상당한 시간이 듭니다. 반대로 의뢰인이 기능 목록을 먼저 고정하고 "이 목록의 각 줄에 대해 포함 여부와 금액을 표기해 달라"고 요청하면, 도착하는 견적서들이 처음부터 같은 뼈대를 갖게 됩니다.
이 목록은 정교할 필요가 없습니다. 오히려 초기에는 개발 용어를 쓰지 않고 사용자가 하는 행동으로 적는 편이 정확합니다. "회원 관리"보다 "방문자가 이메일로 가입한다 / 비밀번호를 잊었을 때 재설정한다 / 관리자가 회원을 정지시킨다"처럼 행동 단위로 쪼갠 목록이, 2.1절에서 다룬 빈칸을 구조적으로 줄여 줍니다. 요구사항 정리의 출발점 자체가 막연하다면 개발 외주를 처음 맡길 때에서 다룬 범위·우선순위·제약 조건의 구분을 먼저 통과하는 것이 효율적입니다.
4.2 우선순위 등급을 함께 붙인다
목록의 각 줄에 필수·권장·선택이라는 세 등급을 붙이면, 정규화 이후의 협상이 훨씬 수월해집니다. 총액이 예산을 넘었을 때 무엇을 뺄지 논의하는 과정이, 등급이 없으면 "그럼 뭘 줄일 수 있나요"라는 열린 질문이 되어 업체의 판단에 맡겨지기 때문입니다. 등급이 붙어 있으면 같은 논의가 "선택 등급 네 개를 2차로 미루면 얼마가 되나요"라는 닫힌 질문으로 바뀌고, 이 질문에는 모든 업체가 같은 형식으로 답할 수 있습니다.
5. 절차 2 — 포함과 제외의 경계를 명시하게 한다
5.1 제외 항목을 적게 하는 것의 효과
견적서에서 가장 정보량이 많은 부분은 포함 목록이 아니라 제외 목록입니다. 그런데 대부분의 견적서에는 제외 목록이 없거나, 있어도 형식적인 한두 줄에 그칩니다. 정규화 단계에서 각 업체에 "이 견적에 포함되지 않는 항목을 명시해 달라"고 요청하는 것만으로, 2.1절의 암묵적 빈칸 상당수가 문서 위로 올라옵니다.
이 요청이 효과적인 이유는 비대칭을 뒤집기 때문입니다. 포함 목록만 요구하면 좁게 산정한 업체가 유리해지지만, 제외 목록까지 요구하면 좁게 산정한 업체일수록 적어야 할 줄이 많아집니다. 즉 제외 목록의 길이 자체가 그 견적이 얼마나 얇은지를 드러내는 지표로 기능합니다. 제외 목록을 성실히 채운 업체를 불리하게 대하지 않는 것이 이 절차를 유지하는 조건입니다.
5.2 경계에서 반복적으로 문제가 되는 항목들
경험적으로 견적서의 경계에서 반복적으로 누락되는 항목들이 있습니다. 콘텐츠와 이미지를 누가 준비하는가, 기존 데이터를 새 시스템으로 옮기는 작업이 포함되는가, 결제·문자·지도 같은 외부 서비스의 가입과 심사를 누가 진행하는가, 도메인과 서버 계정의 소유권이 누구 앞으로 개설되는가, 검수 기간에 나온 수정 요청이 몇 회까지 무상인가. 이 다섯 가지를 목록에 미리 넣어 두면, 정규화 과정에서 가장 빈번한 분쟁 지점이 계약 전에 드러납니다.
6. 절차 3 — 일정 압축 비용을 분리한다
6.1 같은 범위가 일정에 따라 다른 가격을 갖는 이유
동일한 범위라도 일정을 절반으로 줄이면 비용은 절반이 되지 않고 오히려 올라갑니다. 작업의 상당 부분이 순차적 의존 관계를 갖기 때문에, 기간을 줄이려면 병렬로 투입할 인원을 늘려야 하고, 인원이 늘면 조율 비용과 중복 작업이 함께 늘어납니다. 여기에 검토·수정 주기가 압축되면서 나중에 발견되는 문제의 수정 비용도 커집니다.
이 구조 때문에, 일정을 명시하지 않은 채 받은 견적들은 서로 다른 일정을 가정하고 있을 가능성이 높습니다. 여유 일정을 가정한 견적과 촉박한 일정을 가정한 견적을 총액으로 비교하면, 전자가 싸 보이지만 실제로는 의뢰인이 원하는 오픈 시점을 맞추지 못하는 견적일 수 있습니다. 정규화 단계에서 희망 오픈 시점을 먼저 고정하고, 그 일정을 전제로 견적을 요청하는 것이 이 축을 정리하는 방법입니다.
6.2 일정을 두 가지로 요청하는 방법
더 유용한 변형은 두 개의 일정으로 견적을 요청하는 것입니다. 하나는 희망 오픈 시점, 다른 하나는 업체가 판단하기에 무리 없는 시점입니다. 두 견적의 차액이 곧 일정 압축의 가격이며, 이 숫자는 의뢰인에게 "오픈을 한 달 앞당기는 것이 그만한 가치가 있는가"라는 질문을 정량적으로 던져 줍니다. 이 질문에 답하고 나면 상당수의 프로젝트에서 압축이 불필요했다는 결론이 나오고, 그만큼의 예산이 범위나 품질로 재배치됩니다.
7. 절차 4 — 산출물과 인수인계 조건을 항목화한다
7.1 무엇을 받는가가 가격의 일부다
프로젝트가 끝났을 때 의뢰인이 손에 쥐는 것은 동작하는 서비스만이 아닙니다. 소스 코드의 소유권과 보관 위치, 서버·도메인·외부 서비스 계정의 명의, 배포 방법과 접근 권한, 데이터베이스 구조에 대한 최소한의 문서, 그리고 다음 담당자가 이어받을 수 있는 형태의 정리—이 산출물들이 포함되었는지 여부는 총액에 반영되지만 견적서에는 거의 적히지 않습니다.
이 축이 특히 중요한 이유는, 산출물이 부실한 프로젝트의 비용이 다음 프로젝트로 이월되기 때문입니다. 코드를 넘겨받지 못했거나 계정이 업체 명의로 되어 있으면, 다음 개선 작업을 다른 업체에 맡기는 선택지 자체가 사라지거나 큰 비용을 동반합니다. 즉 산출물 조건은 지금의 가격이 아니라 미래의 협상력을 결정하는 항목입니다.
7.2 정규화 질문의 형태
이 축은 다음과 같은 닫힌 질문들로 정규화할 수 있습니다. 소스 코드 저장소는 어느 계정으로 개설되며 종료 시 어떻게 이전되는가. 서버·도메인·결제 서비스 계정의 명의는 누구인가. 배포를 의뢰인 쪽에서 직접 수행하려면 무엇이 필요한가. 종료 시 전달되는 문서는 무엇인가. 이 네 질문에 대한 답을 나란히 놓으면, 총액이 비슷한 두 견적 사이에서도 실질적인 가치 차이가 드러나는 경우가 많습니다.
8. 절차 5 — 구축 구간과 운영 구간을 분리한다
8.1 오픈은 끝이 아니라 전환점이다
견적서의 총액이 구축까지만 포함하는지, 오픈 이후 일정 기간의 하자 보수를 포함하는지, 나아가 지속적인 유지보수를 포함하는지는 견적마다 다릅니다. 세 가지를 구분하지 않고 총액만 비교하면, 구축만 포함한 견적이 가장 싸게 보입니다. 그러나 오픈 이후에는 반드시 비용이 발생합니다. 서버와 도메인이 매달 청구되고, 외부 서비스 요금이 사용량에 따라 늘어나며, 브라우저와 결제 정책이 바뀌면 대응이 필요합니다.
따라서 정규화의 마지막 단계는 견적을 구축 구간과 운영 구간으로 쪼개어, 두 숫자를 따로 받는 것입니다. 구축 총액이 낮고 운영 비용이 높은 견적과, 그 반대인 견적은 서로 다른 시점에 돈이 나가는 구조일 뿐 총합에서는 뒤집힐 수 있습니다. 이 뒤집힘이 실제로 어느 시점에 일어나는지는 외주 개발의 총소유비용에서 별도로 다루며, 대략적인 감각은 TCO 시뮬레이터로 기간과 변경 빈도를 바꿔 보면서 확인할 수 있습니다.
8.2 운영 비용의 두 종류
운영 구간의 비용은 두 종류로 나뉩니다. 하나는 사용 여부와 무관하게 시간에 비례해 나가는 고정비(서버, 도메인, 인증서, 각종 구독)이고, 다른 하나는 무언가를 바꿀 때만 발생하는 변동비(기능 추가, 디자인 수정, 장애 대응)입니다. 견적을 요청할 때 이 둘을 구분해 달라고 하면, "유지보수 월 얼마"라는 뭉뚱그린 숫자가 어떤 성격의 비용인지 판단할 수 있습니다. 고정비는 예산에 미리 반영하면 되지만, 변동비는 실제로 얼마나 자주 바꿀 계획인지에 따라 크게 달라지므로 의뢰인 쪽의 계획이 먼저 서 있어야 의미 있는 비교가 됩니다. 이 구분은 서비스 운영 비용 일반에 적용되는 원리이기도 하며, 시간 비례형과 트래픽 비례형이라는 같은 구분이 사이드 프로젝트 FinOps에서도 분석의 축으로 쓰입니다.
9. 정규화 이후 — 남은 차이를 해석하는 법
다섯 축을 모두 정리하고 나면, 견적 간 격차는 눈에 띄게 줄어듭니다. 그럼에도 차이는 남습니다. 이 잔여 격차는 이제 미스터리가 아니라 해석 가능한 정보이며, 대체로 다음 네 가지 중 하나에서 옵니다.
첫째, 투입 구성의 차이입니다. 같은 결과물을 만드는 데 몇 명이 얼마나 붙는지, 기획·디자인·개발이 분리되어 있는지 한 사람이 겸하는지에 따라 비용 구조가 달라집니다. 둘째, 재사용 자산의 차이입니다. 유사한 프로젝트를 반복해 온 팀은 이미 검증된 구성 요소를 갖고 있어 같은 범위를 더 적은 시간에 만들 수 있습니다. 셋째, 리스크 완충의 차이입니다. 2.3절에서 다룬 대로, 불확실성을 흡수하기로 한 견적에는 완충이 포함됩니다. 넷째, 수요와 여유의 차이입니다. 일정이 꽉 찬 팀은 새 일을 받을 유인이 낮고, 그 사정이 가격에 반영됩니다.
이 네 가지 중 앞의 두 가지는 의뢰인에게 유리한 차이(같은 값에 더 많은 것을 얻거나, 더 적은 값에 같은 것을 얻음)이고, 세 번째는 중립적인 거래(가격과 안정성의 교환)이며, 네 번째는 프로젝트 자체와 무관한 외부 요인입니다. 잔여 격차를 볼 때 던져야 할 질문은 "왜 비싼가"가 아니라 **"이 격차가 네 가지 중 어디에서 왔는가"**입니다. 이 질문은 업체에 직접 물어도 되며, 답변의 구체성 자체가 그 업체의 산정 방식이 얼마나 근거를 갖는지를 드러냅니다.
10. 최저가 선택이 합리적인 조건
정규화를 강조하는 글이 흔히 남기는 오해는 "싼 견적은 피하라"는 결론입니다. 이 글의 주장은 그것이 아닙니다. 정규화의 목적은 최저가를 배제하는 것이 아니라, 최저가가 무엇을 대가로 한 최저가인지 알고 선택하는 것입니다. 그리고 다음 조건들이 충족되면 최저가는 충분히 합리적인 선택입니다.
범위가 이미 확정되어 있고 프로젝트 중간에 바뀔 가능성이 낮을 때, 정규화 과정에서 제외 목록이 짧게 나왔을 때, 산출물과 계정 명의가 의뢰인 쪽으로 정리되어 있을 때, 그리고 오픈 이후를 직접 감당하거나 다른 방법으로 대비해 두었을 때—이 네 조건이 갖춰진 상태의 최저가는 단순히 싼 것이 아니라 불필요한 완충을 지불하지 않는 선택입니다.
반대로 요구사항이 아직 유동적이고, 제외 목록이 길며, 계정 명의가 업체 쪽으로 열리고, 운영 계획이 없는 상태에서의 최저가는 가격이 아니라 리스크를 산 것에 가깝습니다. 이 경우 절감된 금액은 대체로 프로젝트 중후반에 변경 정산이라는 형태로, 혹은 그 이후에 이관 비용이라는 형태로 회수됩니다. 판단이 서지 않는 구간이라면 상담 문의에서 정리해 둔 목록을 그대로 공유하고 어느 축이 비어 있는지부터 확인하는 편이, 견적서를 한 장 더 받는 것보다 대체로 빠릅니다.
논의
지금까지의 절차를 관통하는 하나의 패턴은, 견적 비교의 어려움이 정보의 부족이 아니라 정보의 비구조화에서 온다는 것입니다. 업체들은 대체로 자신이 무엇을 포함했는지 알고 있고, 물으면 답합니다. 문제는 견적서라는 문서 형식이 그 정보를 담도록 설계되어 있지 않다는 것이며, 그 결과 의뢰인은 총액이라는 압축된 한 숫자만 받아 들고 그 안에 접힌 다섯 개 축을 스스로 펼쳐야 하는 위치에 놓입니다.
이 관찰은 왜 정규화의 대부분이 "의뢰인이 먼저 형식을 정하는 것"으로 귀결되는지를 설명합니다. 4장에서 목록을 먼저 만들고, 5장에서 제외를 요구하고, 6장에서 일정을 고정하고, 7장에서 산출물을 항목화하고, 8장에서 구간을 쪼개는 절차는 모두 같은 동작의 변형입니다—답변의 형식을 질문하는 쪽이 지정하는 것. 형식이 지정되면 비교는 자동으로 따라오고, 형식이 지정되지 않으면 아무리 많은 견적을 받아도 비교는 끝내 성립하지 않습니다.
또 하나 짚어 둘 것은, 이 절차가 업체에 대한 불신을 전제하지 않는다는 점입니다. 오히려 정규화는 성실하게 산정한 업체에게 유리하게 작동합니다. 넓게 포함한 견적은 총액 비교에서는 불리하지만 축별 비교에서는 그 넓이가 그대로 드러나기 때문입니다. 즉 정규화는 의뢰인의 방어 장치인 동시에, 제대로 산정한 쪽이 그 사실을 보여줄 수 있는 표현 수단이기도 합니다. 이 양방향성이 이 절차를 지속 가능하게 만듭니다.
한계와 후속 과제
이 글의 분석에는 몇 가지 한계가 있습니다. 첫째, 다섯 축의 분해는 대부분의 웹·앱 구축 프로젝트에 적용되지만, 연구개발 성격이 강해 범위 자체를 사전에 확정할 수 없는 프로젝트에는 잘 맞지 않습니다. 이런 프로젝트는 고정 범위·고정 가격이라는 전제 자체가 성립하지 않으므로, 구간을 짧게 끊어 반복 계약하는 다른 구조가 필요하며 그 설계는 이 글이 다루지 않았습니다.
둘째, 이 글은 정규화의 절차를 제시했을 뿐, 정규화에 드는 의뢰인 쪽 비용은 정량화하지 않았습니다. 목록을 만들고 다섯 축을 되묻는 데는 실제로 상당한 시간이 들며, 프로젝트 규모가 작을수록 이 비용의 상대적 비중이 커집니다. 소규모 프로젝트에서 다섯 축 중 어디까지 생략해도 되는지에 대한 기준은 후속 과제로 남습니다.
셋째, 이 글은 잔여 격차의 원인을 네 가지로 분류했지만, 각 원인이 격차에 기여하는 비중을 판별하는 방법은 제시하지 않았습니다. 업체의 답변에 의존하는 현재의 방법은 답변의 성실성에 좌우되며, 이를 보완할 객관적 지표—예컨대 과거 유사 프로젝트의 실제 기간과 최종 정산액—를 요청하는 절차가 정규화의 여섯 번째 단계로 추가될 수 있을지는 추가 검토가 필요합니다.
넷째, 계약 조항·대금 지급 구조·분쟁 해결 절차는 이 글의 범위 밖이지만, 실제로는 견적 비교의 결론을 뒤집을 수 있는 요소입니다. 같은 총액이라도 지급 시점이 앞에 몰려 있는지 산출물 인도와 연동되어 있는지에 따라 의뢰인이 지는 위험이 달라지므로, 이 축을 다섯 축에 어떻게 통합할지는 별도의 정리가 필요합니다.
결론
같은 요구사항에 대한 견적이 세 배로 갈리는 것은 대체로 누군가 틀렸기 때문이 아니라, 세 견적서가 서로 다른 것을 세고 있기 때문입니다. 총액은 범위·품질·일정·리스크·운영이라는 다섯 축이 곱해진 결과인데, 견적서는 이 중 일부만 표기하고 나머지는 숫자 안에 접어 넣습니다. 따라서 비교의 첫 단계는 더 많은 견적을 받는 것이 아니라, 접혀 있는 축을 펼치도록 답변의 형식을 지정하는 것입니다.
이 글이 제시한 다섯 단계—기능 목록으로 범위를 환원하고, 제외 항목을 명시하게 하고, 일정 압축 비용을 분리하고, 산출물과 인수인계를 항목화하고, 구축과 운영 구간을 쪼개는 것—는 모두 같은 원리의 변형입니다. 이 절차를 통과하면 남은 가격 차이는 투입 구성·재사용 자산·리스크 완충·수요 상황이라는 읽을 수 있는 네 가지 원인으로 번역되고, 그때 비로소 최저가를 선택하는 것이 절약인지 리스크 구매인지 판단할 수 있게 됩니다.
정규화에는 시간이 듭니다. 그러나 그 시간은 계약 이후에 변경 정산과 재작업이라는 훨씬 비싼 형태로 지불될 비용을 앞당겨 치르는 것에 가깝습니다. 견적서를 비교 가능하게 만드는 일은 결국, 프로젝트가 시작되기 전에 의뢰인과 개발 쪽이 같은 그림을 보고 있는지 확인하는 가장 저렴한 방법입니다.