요구사항이 흐릴 때 싸게 맡기면 비용이 커지는 이유

“대충 이런 앱이요. 참고 사이트는 여기고요. 예산은 최대한 낮게요.”

이 문장만으로 계약이 체결되는 순간, 프로젝트는 이미 비용 구조를 확정합니다. 요구사항이 흐릴수록 수행하는 쪽은 해석의 여지를 갖게 되고, 그 해석이 발주자 기대와 어긋날 때마다 변경 비용이 생깁니다.

아이러니하게도 초기 견적이 싸면 싸울수록, 해석 차이 한 번의 충격이 상대적으로 커집니다. 이 글은 요구가 모호할 때 어떻게 돈이 늘어나는지, 왜 최저가와 결합하면 더 위험해지는지, 착수 전에 무엇을 고정해야 하는지를 설명합니다.

요구사항이 흐릴 때 싸게 맡기면 비용이 커지는 이유 — 핵심 개념 시각 자료

모호한 요구가 비용을 만드는 방식

견적이 “추정 묶음”이 된다

명확한 시나리오가 없으면 견적은 페이지 수·유사 프로젝트 감으로 산정됩니다. 수행 측은 리스크를 낮추려고 범위를 좁게 해석하거나, 반대로 수주를 위해 넓게 약속합니다. 어느 쪽이든 실행 단계에서 충돌합니다.

결정이 개발 중에 이뤄진다

원래 기획 단계에서 싸게 끝낼 결정이, 개발 인력이 붙는 구간으로 이동합니다. 화면이 나온 뒤 “이건 아닌 것 같아요”가 반복되면, 이미 쓴 시간은 되돌리기 어렵고 수정 시간이 추가됩니다.

변경인지 하자인지 경계가 사라진다

“당연히 포함인 줄 알았어요”와 “그건 추가입니다”의 대치입니다. 문서가 없으면 감정과 관계로 해결되고, 관계는 나빠지며 일정은 늘어납니다.

품질 기준이 없다

“예쁘게”, “빠르게”, “안정적으로”는 검수 기준이 아닙니다. 기준이 없으면 잔금 시점에 무한 수정 요청 또는 조기 종료 중 하나로 흐르기 쉽습니다.

	초기 견적에 여유가 있을 때	초기 견적이 타이트(최저가)할 때
요구가 선명	변경 비용을 예측하기 쉬움	범위 안 납품 가능성 높음 (품질 여력은 별도 확인)
요구가 모호	해석·재작업 비용 발생	분쟁·재작업·재개발 위험이 가장 큼

오른쪽 아래 칸이 실무에서 가장 비싼 조합입니다. 싸게 시작했지만 총비용이 가장 커지기 쉽습니다.

참고 주소는 유용한 출발점입니다. 그러나 다음이 빠지면 요구사항이 아닙니다.

참고 사이트를 그대로 복제하는 것도 보통 불가능하거나 부적절합니다. 브랜드·라이선스·뒷단 구조가 다르기 때문입니다.

완벽 기획서를 요구하는 것이 아닙니다. 아래 여섯이 있으면 모호성 비용이 크게 줄어듭니다.

이 문서들을 발주자가 혼자 써야 한다는 뜻이 아닙니다. 유료 탐색 단계로 전문 업체와 같이 써도 됩니다. 그 비용이 나중에 재작업을 막는 보험이 됩니다.

모호한 계약을 싸게 맺는 것은 할인을 받는 일이 아니라, 분쟁 옵션을 매수하는 일에 가깝습니다.

문서 작성이 부담되면 이해관계자 90분 워크숍으로 대체할 수 있습니다.

워크숍 결과 한 페이지만 있어도 견적 요청 품질이 달라집니다. 수행 측에 “이 페이지를 전제로 견적”이라고 명시하면, 돌아온 숫자의 전제가 맞는지 검증할 수 있습니다.

내부에서 요구가 계속 추가되는 조직이라면, 워크숍에서 변경 예산 슬롯(예: 전체의 10~15%)을 미리 확보해 두는 것도 방법입니다. 슬롯이 없으면 모든 아이디어가 “당연히 포함”으로 밀고 들어와 저가 계약을 무너뜨립니다.

초기 견적 차액보다 기회비용과 재작업이 큽니다. 모호한 채 싸게 맡기는 것은 할인이 아니라, 미정의 리스크를 미래 청구로 미루는 행위에 가깝습니다. 그 이자는 변경 공수·분쟁·재작업입니다.

LB Contents는 앱·홈페이지·쇼핑몰 제작과 운영 구조를 함께 설계합니다. 요구사항이 아직 흐린 단계에서도, 범위를 선명히 만드는 상담부터 시작할 수 있습니다.