홈페이지 제작 비용, 왜 업체마다 10배나 다를까?

홈페이지 제작을 처음 의뢰해 본 사람이라면 누구나 한 번쯤 겪는 순간이 있다. 세 군데 업체에 견적을 요청했는데, 돌아온 숫자가 300만원, 900만원, 3,000만원으로 제각각인 순간이다. 심지어 세 업체 모두 "반응형 홈페이지, 게시판 포함, 관리자 페이지 포함"이라는 거의 동일한 문장으로 견적서를 채워왔는데도 그렇다. 이쯤 되면 의뢰인은 자연스럽게 의심하게 된다. 싼 곳은 날림으로 만드는 걸까, 비싼 곳은 바가지를 씌우는 걸까.

결론부터 말하면 둘 다 아닐 가능성이 높다. 이 글에서 다루려는 핵심은, 가격 차이의 대부분이 실력의 차이가 아니라 '정의되지 않은 범위(Scope)'의 차이에서 발생한다는 사실이다. 같은 단어를 쓰고 있어도 업체마다 그 단어가 가리키는 작업량이 완전히 다르기 때문에 벌어지는 일이다. 이 구조를 이해하지 못한 채 계약하면, 저가 견적을 선택했다가 중간에 추가금을 요구받거나, 완성된 결과물이 기대와 전혀 다른 채로 프로젝트가 끝나는 전형적인 외주 분쟁으로 이어진다.

같은 홈페이지인데 왜 300만원과 3,000만원으로 갈릴까

견적서 앞자리만 보고 계약하면 안 되는 이유

대부분의 의뢰인은 견적서를 받으면 맨 아래 총액부터 확인한다. 하지만 정작 중요한 정보는 총액이 아니라 그 위에 나열된 항목의 세분화 정도에 있다. 견적서가 "홈페이지 제작 일체 – 300만원" 한 줄로 끝난다면, 이는 업체가 프로젝트 범위를 스스로도 명확히 정의하지 않았다는 신호일 수 있다. 반대로 "메인 페이지 기획 및 퍼블리싱 – 40만원, 게시판 모듈(권한 3단계, 파일첨부, 검색) – 120만원, 관리자 페이지 – 90만원..." 처럼 항목이 잘게 쪼개져 있다면, 그 업체는 이미 내부적으로 요구사항을 기능 단위로 분해해서 공수를 계산했다는 뜻이다.

세분화되지 않은 견적서로 계약하면 나중에 분쟁이 생겼을 때 "그건 견적에 포함된 게 아니다"라는 말을 들어도 반박할 근거가 없다. 반대로 항목이 세세하게 나뉜 견적서는 협상의 여지도, 책임 소재도 명확해진다.

가격 차이의 진짜 원인은 '범위'다

업계에서 통상적으로 통용되는 방식을 기준으로 보면, 홈페이지 제작 비용은 크게 세 가지 변수의 곱으로 결정된다. ① 요구사항이 얼마나 구체적으로 정의되어 있는가, ② 기능 하나하나에 얼마만큼의 개발 공수가 들어가는가, ③ 어떤 개발 방식(커스텀 vs 템플릿)을 쓰는가. 이 세 가지 변수가 곱해지면서 최종 견적은 쉽게 5배, 10배까지 벌어질 수 있다. 다음 장부터는 이 세 변수를 하나씩 뜯어본다.

요구사항 정의서, 견적의 기준선을 만드는 문서

"이쁘게 만들어주세요"가 위험한 이유

많은 의뢰인이 요구사항 정의서 없이 구두로, 혹은 참고 사이트 링크 몇 개만 던져주고 프로젝트를 시작한다. 이 방식의 문제는 "이쁘게"와 "필요한 기능 다 넣어서" 같은 표현이 사람마다 전혀 다르게 해석된다는 데 있다. 개발자는 "필요한 기능"을 최소 범위로 해석해서 견적을 낮게 잡고, 의뢰인은 자신의 머릿속에 있는 풍부한 기능 목록을 당연히 포함된 것으로 여긴다. 이 간극이 프로젝트 중반에 터지면, 개발사는 "추가 개발 건"이라며 별도 견적서를 내밀고, 의뢰인은 "당연히 포함된 거 아니냐"며 맞선다. 이 지점이 외주 분쟁의 8할이 시작되는 지점이다.

요구사항 정의서에 반드시 들어가야 할 5가지 항목

제대로 된 요구사항 정의서는 최소한 다음 다섯 가지를 담고 있어야 한다.

• 사용자 시나리오 — 방문자가 사이트에 들어와서 어떤 순서로 어떤 행동을 하는지 (예: 상품 탐색 → 장바구니 → 회원가입 → 결제)
• 기능 리스트 — 로그인, 게시판, 검색, 결제 연동 등 페이지 단위가 아니라 기능 단위로 쪼갠 목록
• 화면 정의서(와이어프레임) — 각 화면에 어떤 요소가 배치되는지 손그림 수준이라도 시각화한 자료
• 데이터 모델 — 회원정보, 게시글, 주문내역 등 어떤 데이터를 저장하고 어떻게 연결할지에 대한 최소한의 그림
• 비기능 요구사항 — 동시 접속자 규모, 반응 속도, 보안 등급, 향후 확장 계획처럼 눈에 보이진 않지만 설계에 영향을 주는 조건

이 다섯 가지가 준비된 상태로 견적을 요청하면, 업체 간 견적 편차가 눈에 띄게 줄어든다. 정의되지 않은 부분이 없으니, 견적서가 서로 다른 상상을 근거로 작성될 여지가 사라지기 때문이다.

정의서 유무가 실제 견적에 미치는 영향

실무에서 흔히 관찰되는 패턴은 이렇다. 정의서 없이 견적을 요청하면 업체는 두 가지 중 하나를 택한다. 첫째, 최소 범위로 가정하고 낮은 금액을 부른 뒤 진행 중 추가금을 청구하는 방식. 둘째, 리스크를 감안해 처음부터 여유 있게 높은 금액을 부르는 방식이다. 두 경우 모두 의뢰인 입장에서는 손해다. 반대로 정의서를 들고 견적을 요청하면, 업체는 실제로 필요한 공수만큼만 정확히 계산할 수 있고, 이는 종종 구두 견적보다 더 합리적인 숫자로 이어진다.

기능 명세서와 공수 산정의 비밀

맨먼스(Man-Month) 단가는 어떻게 계산되나

개발 견적의 기본 단위는 '사람이 며칠 동안 일하는가'다. 이를 맨데이(Man-Day) 또는 맨먼스(Man-Month)라고 부른다. 업체는 기획자, 디자이너, 퍼블리셔, 백엔드 개발자 각각의 일 단가를 정해두고, 기능 명세서에 명시된 작업 각각에 예상 소요일을 곱해서 총 공수를 계산한다. 이 총 공수에 인건비 단가를 곱하고, 여기에 관리비와 이윤을 더한 것이 최종 견적이 된다. 즉 겉으로 보이는 총액은 하나의 숫자지만, 그 안에는 "이 기능에 며칠이 걸릴 것으로 본다"는 수십 개의 판단이 누적되어 있다.

"게시판 하나"에도 공수가 4배 차이나는 이유

"게시판 만들어주세요"라는 한 문장은 업체마다 전혀 다른 작업량으로 해석된다. 아래 표는 게시판이라는 동일한 기능이 옵션에 따라 공수가 어떻게 달라지는지 보여주는 예시다.

위 수치는 프로젝트마다 달라질 수 있는 참고용 예시이지만, 방향성은 대부분의 실무 견적에서 동일하게 관찰된다. 기본형과 고급형 사이의 공수 차이가 4배 가까이 벌어지는 이유는 권한 분기, 예외 처리, 테스트 케이스가 기능이 추가될 때마다 산술적으로가 아니라 조합적으로 늘어나기 때문이다. 회원등급이 3단계라면 각 등급별로 보이는 버튼과 접근 가능한 글이 달라지고, 이 모든 경우의 수를 개발자가 코드로 분기 처리하고 검증해야 한다.

견적서에서 반드시 확인해야 할 항목 단위 분해

견적을 받으면 다음 세 가지를 반드시 확인해야 한다. 첫째, 게시판이라면 "몇 종류의 게시판이며 각각 권한 체계가 어떻게 다른가"가 명시되어 있는지. 둘째, "수정 요청은 몇 회까지 무상으로 포함되는가"가 계약서에 숫자로 박혀 있는지. 셋째, 견적서에 없는 기능이 나중에 발견되었을 때 추가 공수 산정 기준이 사전에 합의되어 있는지. 이 세 가지가 빠진 견적서는 아무리 총액이 매력적이어도 프로젝트 중반에 분쟁으로 이어질 가능성이 높다.

커스텀 개발 vs 템플릿·노코드 빌더, 근본적으로 다른 상품

그누보드/PHP 커스텀 개발이 비싼 이유

그누보드나 순수 PHP 기반으로 처음부터 코드를 작성하는 커스텀 개발은 템플릿 빌더보다 단가가 높다. 이유는 단순히 "손이 더 가서"가 아니다. 커스텀 개발은 소스코드에 대한 완전한 소유권을 의뢰인에게 넘긴다는 것을 전제로 한다. 서버 환경에 맞춘 성능 최적화, 자사 비즈니스 로직에 맞춘 무제한에 가까운 커스터마이징, 특정 플랫폼 정책에 종속되지 않는 독립성까지 포함된 상품이다. 회원 등급 체계가 복잡하거나, 외부 결제·물류 시스템과 연동해야 하거나, 트래픽이 커질 것을 대비해 서버 구조를 유연하게 가져가야 하는 사업이라면 커스텀 개발 외에는 사실상 대안이 없다.

이런 프로젝트일수록 처음부터 요구사항 정의서 작성을 함께 진행해 줄 수 있는 파트너를 찾는 것이 안전하다. 예를 들어 스타트업 전문 맞춤형 웹 개발사 노블웹(Nobleweb)처럼 기획 단계부터 개발자가 직접 참여해 요구사항을 구조화하는 방식으로 일하는 업체는, 견적 단계에서부터 범위가 명확해지기 때문에 진행 중 추가금 분쟁이 발생할 여지가 크게 줄어든다.

템플릿·노코드 빌더가 저렴한 이유와 숨은 비용

반대로 워드프레스 테마, 카페24, 아임웹, Wix 같은 템플릿·노코드 빌더는 초기 제작 비용이 낮다. 이미 만들어진 구조 위에 콘텐츠만 얹는 방식이기 때문이다. 다만 이 방식에는 눈에 잘 보이지 않는 비용이 따라붙는다. 월 구독료가 몇 년간 누적되면 초기 커스텀 개발 비용에 근접하거나 넘어서는 경우가 흔하고, 플랫폼이 제공하지 않는 기능은 아무리 원해도 추가할 수 없는 구조적 한계가 있다. 또한 플랫폼을 옮기고 싶어져도 데이터와 디자인을 그대로 들고 나올 수 없는 '락인(Lock-in)' 문제도 따라온다.

내 사업 단계에 맞는 선택 기준

결국 선택 기준은 "어느 쪽이 더 저렴한가"가 아니라 "내 사업이 지금 어느 단계인가"여야 한다. 아이디어를 빠르게 검증하는 초기 단계라면 템플릿 빌더로 시작해 시장 반응을 확인하는 편이 합리적이다. 반면 이미 검증된 비즈니스 모델을 바탕으로 회원 시스템, 결제, 대량 트래픽을 감당해야 하는 단계라면 커스텀 개발로 넘어가는 것이 장기적으로 비용을 아끼는 길이다. 두 상품은 경쟁 관계가 아니라, 사업의 성장 곡선에 따라 순서대로 필요한 서로 다른 도구다.

외주 사기·분쟁을 피하는 체크리스트

계약서에 없으면 위험한 5가지 조항

• 소스코드 인도 조항 — 잔금 지급 시 소스코드 전체를 이관받는다는 문구가 명시되어 있는가
• 유지보수 범위와 기간 — 무상 하자보수 기간이 며칠/몇 개월인지, 어디까지가 '하자'이고 어디부터가 '추가 개발'인지
• 수정 요청 횟수 — 디자인 시안 및 기능 수정이 몇 회까지 무상인지 숫자로 명시되어 있는가
• 저작권 귀속 — 완성된 결과물의 저작권이 최종적으로 의뢰인에게 귀속된다는 조항이 있는가
• 중도 해지 조건 — 프로젝트가 중단될 경우 기지급금과 미완성 결과물 처리 기준이 사전에 정해져 있는가

저가 수주 후 추가금을 요구하는 패턴 알아채는 법

시장 평균보다 눈에 띄게 낮은 견적을 받았다면 다음 신호를 의심해봐야 한다. 견적서 항목이 지나치게 뭉뚱그려져 있는지, 계약서에 "추가 기능은 별도 협의"라는 문구만 있고 산정 기준이 없는지, 계약금 비중이 유난히 낮고 중도금·잔금 비중이 큰지 여부다. 이런 구조에서는 프로젝트가 절반쯤 진행된 시점, 즉 의뢰인이 다른 업체로 옮기기 부담스러운 시점에 추가금 요구가 집중되는 경향이 있다.

견적 비교할 때 실전 체크리스트

여러 업체의 견적을 비교할 때는 총액을 나란히 놓기 전에, 각 업체가 같은 요구사항 정의서를 기준으로 견적을 냈는지부터 확인해야 한다. 기준이 다르면 숫자를 비교하는 것 자체가 의미가 없다. 요구사항 정의서를 먼저 준비하고, 그 문서를 기준으로 세 곳 이상에서 항목별 견적을 받아 비교하는 것이 가격 거품을 걷어내는 가장 확실한 방법이다.

좋은 외주처를 고르는 것은 결국 '기준'을 아는 것이다

홈페이지 제작 비용이 업체마다 10배씩 벌어지는 이유는 누군가는 정직하고 누군가는 부정직해서가 아니다. 견적이라는 숫자 뒤에 요구사항의 범위, 기능별 공수, 개발 방식이라는 세 겹의 변수가 숨어 있고, 그 변수를 의뢰인이 미리 통제하지 못하면 업체마다 전혀 다른 상상을 근거로 견적을 내기 때문이다. 요구사항 정의서를 먼저 준비하는 것, 견적서를 기능 단위로 쪼개 달라고 요청하는 것, 계약서에 소스코드 인도와 유지보수 범위를 숫자로 못 박는 것. 이 세 가지만 지켜도 외주 시장의 정보 비대칭 대부분을 걷어낼 수 있다.

사이트가 완성된 이후도 중요하다. 완성된 사이트를 유지보수 없이 방치하면 보안 취약점이 쌓이고, 워드프레스나 그누보드처럼 지속적인 패치가 필요한 구조라면 이 문제는 더 빨리 찾아온다. 커스텀으로 제작한 사이트라면 처음 개발을 맡긴 곳, 혹은 PHP 및 그누보드 유지보수 전문 아웃소싱 플랫폼 노블웹과 같이 유지보수를 전문으로 다루는 곳을 미리 확인해 두는 것도 실무적으로 도움이 되는 선택이다.