본문 바로가기
이노자일

비슷해 보이는 외주 견적서의 금액이 달랐던 이유

외주 실패학8분 읽기이노자일

핵심 요약

외주 견적의 차이는 페이지 수보다 어디까지 만들고 확인하며 넘겨주는지에서 생기는 경우가 많았습니다. 수정 범위, 중간 확인, 콘텐츠 입력, 공개 후 대응과 운영 자료가 견적서에 어떻게 담기는지 살펴본 경험을 기록했습니다.

같은 내용을 여러 업체에 설명했는데 견적 금액은 예상보다 크게 달라질 때가 있습니다. 한쪽이 비싼 것인지, 다른 쪽이 효율적인 것인지 금액만으로는 판단하기 어렵습니다.

저희는 외주를 맡기는 쪽과 수행하는 쪽을 모두 경험했습니다. 두 입장에서 견적서를 보다 보니 반복해서 생기는 차이가 있었습니다. 화면의 개수는 비슷해도 어디까지 만들고, 확인하고, 넘겨주는지는 같지 않았습니다.

겉으로 보이는 결과가 같은 사이트라고 해도 운영을 시작한 뒤 필요한 일까지 포함했는지에 따라 범위가 달라졌습니다.

두 사람이 서로 다른 화면을 떠올리는 그림

“문의 화면 하나”에서도 생각하는 범위가 달랐습니다

회사 소개 화면과 문의 양식이 있는 사이트를 예로 들 수 있습니다. 설명만 들으면 비교적 단순해 보입니다.

방문자가 이름과 연락처를 적고 제출하는 화면을 만드는 것까지는 쉽게 떠올릴 수 있습니다. 실제 운영에서는 그다음 과정도 필요했습니다. 제출한 내용은 어디에 저장되는지, 담당자는 어떻게 알게 되는지, 사용자는 접수됐다는 사실을 어떻게 확인하는지, 잘못된 연락처나 반복되는 스팸은 어떻게 다룰지도 정해야 했습니다.

어떤 견적은 눈에 보이는 문의 화면까지 포함했습니다. 다른 견적은 저장, 알림, 개인정보 동의, 오류 안내와 관리 화면까지 함께 계산했습니다. 견적서에는 둘 다 “문의 기능”이라고 적힐 수 있었습니다.

이 차이는 처음에는 잘 보이지 않았습니다. 개발이 진행된 뒤 알림이나 관리 기능이 없다는 것을 알게 되면 추가 일정과 비용을 다시 논의하게 됐습니다. 누군가 일부러 항목을 숨겼기보다, 짧은 설명을 서로 다르게 이해한 경우가 많았습니다.

화면 이름보다 사용자가 하는 일을 적으니 대화가 쉬워졌습니다

이후에는 화면 목록만 전달하기보다 그 화면에서 일어나는 일을 짧게 적었습니다.

예를 들어 “문의 화면” 대신 다음과 같은 흐름을 설명했습니다.

방문자가 문의 내용을 작성해 제출한다. 내용은 담당자가 확인할 수 있는 곳에 저장되고, 담당자에게 새 문의 알림이 전달된다. 방문자에게는 정상적으로 접수됐다는 안내가 보인다.

완벽한 기획서는 아니지만, 이 정도만 있어도 업체마다 같은 범위를 기준으로 이야기하기 쉬웠습니다. 저장 방식이나 알림 도구처럼 결정하지 못한 부분은 상담 과정에서 선택할 수 있었습니다.

화면의 모양보다 사용자의 행동을 먼저 적으면 견적에 포함되지 않은 부분도 일찍 보였습니다. 오류가 났을 때의 안내, 개인정보 동의, 관리자의 확인 방식처럼 평소에는 잘 떠올리지 않는 항목들이었습니다.

수정 횟수보다 수정할 수 있는 시점이 중요했습니다

견적서에는 “수정 2회”처럼 횟수가 적히는 경우가 많습니다. 실제 진행에서는 횟수와 함께 어느 단계까지 무엇을 바꿀 수 있는지가 중요했습니다.

화면의 색이나 글자 배치를 고치는 일과, 거의 완성된 뒤 메뉴 구조나 기능 흐름을 바꾸는 일은 필요한 작업량이 다릅니다. 시안을 보는 단계에서는 비교적 쉽게 바꿀 수 있던 내용도 개발 후에는 여러 화면과 기능을 함께 고쳐야 할 수 있습니다.

중간에 무엇을 볼 수 있는지도 영향을 줬습니다. 방향을 확인할 수 있는 첫 화면, 실제로 눌러 볼 수 있는 주요 기능, 공개 전 전체 화면처럼 확인 시점이 나뉘어 있으면 큰 차이를 조금 일찍 발견할 수 있었습니다.

수정 횟수가 많다는 표현보다 각 단계에서 무엇을 확정하는지 설명된 제안이 진행 과정을 예상하기 쉬웠습니다.

글과 이미지를 누가 준비하는지도 일정에 들어 있었습니다

사이트 제작 일정이 늦어지는 이유가 개발 때문만은 아니었습니다. 회사 소개 문장, 서비스 설명, 사진과 사례를 준비하는 데 예상보다 시간이 걸리는 경우가 많았습니다.

견적에는 콘텐츠가 모두 준비돼 있다는 전제로 화면 제작만 포함될 수도 있습니다. 초안을 함께 정리하거나 기존 자료를 사이트에 맞게 다듬고 입력하는 과정까지 포함될 수도 있습니다.

같은 페이지 수라도 들어갈 글과 이미지의 상태에 따라 필요한 일이 달랐습니다. 임시 문구로 먼저 제작하는지, 누가 최종 원고를 확인하는지, 몇 개의 기존 글을 옮기는지가 미리 정리돼 있으면 일정도 현실적으로 잡혔습니다.

콘텐츠 입력이 별도라는 사실 자체가 문제는 아니었습니다. 누가 언제 해야 하는지 알려져 있으면 준비할 수 있었습니다.

공개하는 일과 운영할 수 있게 넘겨주는 일은 달랐습니다

사이트가 정상적으로 열리면 제작은 끝난 것처럼 보입니다. 운영을 시작하면 계정, 도메인, 외부 서비스, 관리 방법과 같은 정보가 필요해집니다.

문구나 이미지를 어디에서 바꾸는지, 문의 내역은 어디에서 보는지, 도메인과 호스팅은 누구 명의인지, 외부 서비스 비용은 어떻게 결제되는지 알 수 있어야 했습니다. 담당자가 바뀌면 같은 내용을 다시 찾게 됩니다.

어떤 프로젝트에서는 관리자 사용법과 계정 목록, 화면과 기능의 기준을 정리한 자료가 함께 전달됐습니다. 다른 프로젝트에서는 제작한 파일만 남기도 했습니다. 공개 당일에는 차이가 작아 보였지만 몇 달 뒤 수정하거나 다른 담당자가 이어받을 때 차이가 커졌습니다.

항목이 비어 있는 견적서

자주 바뀌는 내용의 관리 방식도 비슷했습니다. 공지와 사례를 담당자가 직접 올릴 수 있는지, 문구 하나를 바꿀 때마다 개발 요청이 필요한지에 따라 운영 비용이 달라졌습니다. 처음 견적에는 보이지 않지만 사용 기간이 길수록 쌓이는 부분이었습니다.

공개 이후의 지원은 기간보다 범위를 함께 봤습니다

“공개 후 3개월 지원”이라는 문구가 있어도 지원의 의미는 업체마다 달랐습니다. 제작 과정에서 생긴 오류를 고치는 것인지, 문구와 이미지를 바꾸는 작업도 포함하는지, 새로운 기능 요청은 어떻게 계산하는지 구분이 필요했습니다.

오류와 추가 요청의 경계가 모호한 경우도 있었습니다. 합의한 동작과 다르게 작동하는 것은 오류에 가깝고, 처음에 없던 기능을 새로 넣는 것은 추가 작업에 가깝습니다. 처음의 화면 기준과 완료 조건이 남아 있으면 이 구분도 비교적 수월했습니다.

응답 방식도 운영에 영향을 줬습니다. 요청을 어디로 남기는지, 긴급한 문제가 생겼을 때 연락 방법이 있는지, 보통 어느 정도 안에 상태를 알려주는지가 정해져 있으면 담당자가 바뀌어도 대응하기 편했습니다.

“완료”를 문장으로 적어 둔 프로젝트가 편했습니다

결과를 두고 가장 어려운 대화는 “이 정도면 완료된 것인지” 서로 생각이 다를 때였습니다. 디자인은 취향이 들어갈 수 있고, 기능은 화면만 보고 내부의 처리를 알기 어렵습니다.

중요한 흐름에 대해 완료 상태를 문장으로 적어 두면 확인이 단순해졌습니다.

문의를 제출하면 내용이 저장되고 담당자에게 알림이 전달되며, 방문자에게 접수 안내가 표시된다.

이 문장은 어떤 기술을 사용할지 정하지 않습니다. 대신 사용자와 운영자에게 어떤 결과가 있어야 하는지 알려 줍니다. 만드는 쪽은 놓치면 안 되는 범위를 알 수 있고, 확인하는 쪽은 무엇을 눌러 봐야 하는지 알 수 있었습니다.

규모가 큰 프로젝트라면 이런 기준이 더 많아지고, 작은 사이트라면 중요한 흐름 몇 개만 있어도 도움이 됐습니다.

낮은 견적이 부족하고 높은 견적이 좋은 것은 아니었습니다

범위가 좁은 견적은 목적에 맞으면 합리적인 선택이 될 수 있습니다. 짧은 기간 사용할 행사 페이지에 복잡한 관리 기능과 긴 운영 지원을 넣을 필요는 없습니다.

반대로 고객의 문의가 저장되고 예약이나 결제가 이어지며 앞으로 기능을 계속 추가할 서비스라면 처음부터 살펴볼 범위가 늘어납니다. 화면 제작 외에 데이터 보관, 권한, 확인 과정과 인수 자료가 필요할 수 있습니다.

금액의 높고 낮음보다 필요한 범위가 들어 있는지를 보니 비교가 쉬워졌습니다. 같은 항목끼리 비교할 수 있었고, 지금 제외한 기능을 나중에 추가할 때의 영향도 미리 들을 수 있었습니다.

제안서를 읽을 때 오래 보게 된 부분들

여러 제안서를 검토하면서 자연스럽게 오래 보게 된 내용이 있었습니다.

  • 화면 이름뿐 아니라 사용자가 완료해야 할 행동이 적혀 있는지
  • 중간 결과를 언제 어떤 형태로 확인하는지
  • 수정의 횟수와 함께 단계별 범위가 설명돼 있는지
  • 콘텐츠 준비와 입력을 누가 맡는지
  • 수정 후 기존 기능을 어떤 방식으로 확인하는지
  • 운영자가 직접 관리할 수 있는 내용이 어디까지인지
  • 공개 후 지원과 추가 작업의 기준이 구분돼 있는지
  • 계정, 문서와 운영 방법이 어떤 형태로 전달되는지

이 항목이 모두 들어 있어야 한다는 의미는 아닙니다. 프로젝트의 성격에 따라 필요하지 않은 부분도 있습니다. 다만 포함 여부가 드러나 있으면 금액과 일정을 같은 기준에서 이해하기 쉬웠습니다.

설명이 구체적인 제안은 작업을 시작한 뒤의 모습도 예상할 수 있었습니다. 누가 무엇을 준비해야 하는지, 어느 시점에 결정을 내려야 하는지, 공개 후에는 어떻게 운영할지가 함께 보였기 때문입니다.

견적은 완성 화면보다 진행 방식을 먼저 보여 줬습니다

좋은 결과를 미리 확신할 수 있는 견적서는 없습니다. 다만 제안서와 상담 과정에는 업체가 프로젝트를 이해하고 진행하는 방식이 어느 정도 드러났습니다.

요청한 기능을 그대로 나열하는 데서 끝나는지, 실제 이용 흐름에서 빠진 부분을 함께 짚는지, 결정하지 못한 내용을 선택지로 정리하는지에 따라 대화가 달랐습니다. 기술을 많이 언급하는 것보다 왜 그 방식이 필요한지 일상의 말로 설명해 주는 경우가 이해하기 편했습니다.

외주를 수행하는 입장에서도 범위를 일찍 정리한 프로젝트가 결과적으로 수월했습니다. 예상하지 못한 추가 작업을 줄이기 위해서만이 아니라, 고객이 중요하게 생각하는 결과에 집중할 수 있었기 때문입니다.

견적서는 최종 금액을 알려주는 문서이면서 앞으로 함께 일할 방식을 보여 주는 첫 자료에 가까웠습니다.

자주 묻는 질문

요구사항을 어느 정도 정리한 뒤 견적을 받아야 하나요?
완성된 기획서가 없어도 괜찮았습니다. 사이트를 만드는 목적, 주로 이용할 사람, 반드시 필요한 행동과 운영 중 자주 바뀔 내용을 정리하면 첫 상담에 충분했습니다. 구체적인 화면과 기능은 그 내용을 바탕으로 함께 정할 수 있습니다.
가장 낮은 견적을 선택하면 문제가 생기나요?
금액만으로 판단하기는 어렵습니다. 필요한 범위가 모두 들어 있으면서 효율적인 제안일 수도 있습니다. 페이지 수, 관리 기능, 콘텐츠, 확인 과정과 공개 후 지원을 같은 조건으로 놓고 보면 차이가 어디에서 생겼는지 이해하기 쉬웠습니다.
이미 진행 중인데 범위가 모호하면 어떻게 정리할 수 있나요?
지금까지 합의한 화면과 중요한 기능의 완료 상태를 문장으로 모으면 남은 작업을 확인하는 데 도움이 됩니다. 중간 결과와 결정 사항을 한곳에 정리하면 이후의 수정과 추가 요청도 구분하기 쉬워집니다.

관련 글

내 프로젝트, 시작해도 될까?

요구사항·예산·리스크·AI 활용, 개발 전 준비사항을 약 3분 동안 점검해 드려요.

3분 무료 진단 시작

12문항 응답 후 이름·이메일·현재 단계를 입력하면 결과를 확인할 수 있어요.

자주 듣는 이야기 — “개발사가 아니라 비즈니스 파트너를 만난 기분.”