안녕하세요. 희명웹입니다.

오늘은 홈페이지 제작 비용과 견적에 관한 이야기입니다. 이번 글의 목적은 단순히 "얼마가 적정가냐"가 아니라, 실무자가 견적서를 읽을 때 반드시 확인해야 하는 구조적 판단 기준을 정리하는 데 있습니다.

 

 

10페이지가 10페이지가 아닌 이유

견적 상담에서 가장 많이 나오는 비교가 "10페이지 기준"입니다. 그런데 같은 10페이지라도 실제 작업량은 완전히 다릅니다. 이유는 간단합니다. 페이지의 '개수'가 아니라, 각 페이지가 정적인지 동적인지, 그리고 사용자 입력·데이터베이스·관리자 기능이 붙는지에 따라 공수와 리스크가 달라지기 때문입니다.

 

 

정적 페이지는 회사소개, 오시는 길처럼 텍스트와 이미지 배치가 중심입니다. 구조가 한 번 잡히면 반복 적용이 가능해서 제작 난이도가 비교적 낮습니다. 반면 동적 페이지는 제품 목록 필터, 문의 폼, 게시판, 회원 기능처럼 입력과 처리 로직이 들어갑니다. 같은 1페이지라는 이름을 달고 있어도 실제 개발·테스트 범위가 몇 배로 커집니다.

실무에서 "페이지 수의 함정"은 여기서 시작됩니다. 어떤 견적서의 10페이지는 정적 구성 위주로 의미가 좁고, 어떤 견적서의 10페이지는 관리자 대시보드·검색·폼·데이터 연동이 포함되어 의미가 훨씬 넓습니다. 그래서 페이지 수만 놓고 비교하면, 사실상 서로 다른 프로젝트를 같은 기준으로 비교하게 됩니다.

 

 

비용은 6단계에서 갈린다

홈페이지는 보통 기획, 디자인, 퍼블리싱, 개발, 테스트, 오픈 이후 운영의 6단계로 나뉩니다. 견적이 달라지는 핵심은 "이 중 어디까지 포함하느냐"입니다.

기획은 "누구에게 무엇을 어떤 순서로 보여줄 것인가"를 정의합니다. 기획이 생략된 프로젝트는 제작 속도는 빠를 수 있지만, 오픈 후에 메뉴 구조나 콘텐츠 흐름이 틀어져서 수정이 반복되는 경우가 많습니다. 특히 B2B 기업 홈페이지는 구매 담당자가 원하는 정보를 첫 화면에서 찾지 못하면 문의로 이어지기 어렵습니다.

 

 

디자인은 예쁘게 만드는 일이 아니라 정보 우선순위를 시각적으로 정리하는 작업입니다. 템플릿 기반인지, 주요 페이지만 커스텀인지, 전체를 풀 커스텀으로 설계하는지에 따라 일정과 수정 범위가 달라집니다. 여기서 중요한 포인트는 "수정 횟수"보다 "수정 범위"입니다. 색상·폰트만 바꾸는 수정과 레이아웃을 다시 짜는 수정은 완전히 다른 작업입니다.

퍼블리싱은 디자인을 실제 화면에서 작동하도록 HTML/CSS/JS로 구현하는 단계입니다. 반응형이 '포함'되어 있어도, 단순 축소 수준인지, 화면별 레이아웃 재구성인지, 디바이스별 최적화인지에 따라 품질이 달라집니다. 퍼블리싱 단계가 얕게 잡히면, 오픈 후 모바일 사용성 문제로 재작업이 자주 발생합니다.

 

 

개발은 데이터베이스 연동, 사용자 입력 처리, 권한 관리, 관리자 기능을 구현하는 단계입니다. 게시판 1개와 제품 카탈로그는 둘 다 "페이지"처럼 보이지만 개발 난이도가 다릅니다. 견적서를 볼 때는 "기능 목록이 항목화 되어 있는지"가 가장 중요합니다. 기능이 "기본 기능 포함" 같은 문장으로 뭉뚱그려져 있으면, 오픈 뒤 추가 비용 분쟁이 생기기 쉽습니다.

테스트는 비용을 아끼기 쉬운 구간이지만, 사고가 가장 비싸게 나는 구간입니다. 기능 테스트, 디바이스 테스트, 브라우저 호환성 테스트, 성능, 보안을 얼마나 포함하는지에 따라 오픈 직후의 안정성이 갈립니다. 테스트가 약하면 오픈 이후 "긴급 수정"이 잦아지고, 긴급 수정은 정상 개발보다 비용·일정 부담이 커지는 경향이 있습니다.

 

 

오픈 이후 운영 단계에서 실무자가 가장 많이 놓칩니다. 홈페이지는 오픈이 끝이 아니라 운영의 시작입니다. 콘텐츠 수정이 잦은 기업은 관리자에서 직접 수정 가능한 범위를 넓혀야 하고, 기능 확장 가능성이 있다면 초기 설계부터 확장성을 고려해야 합니다. 운영 단계의 비용은 대개 수정, 유지보수, 확장으로 분류됩니다.

견적서에서 특히 위험한 모호한 표현들

견적서에서 자주 보는 표현이 있지만, 정의가 업체마다 달라서 그대로 믿으면 위험합니다.

"맞춤 제작"이라고 적혀 있다면 템플릿을 쓰는지 안 쓰는지, 메인만 커스텀인지 핵심 페이지만 커스텀인지 전 페이지 커스텀인지, 스타일 가이드 같은 산출물이 제공되는지 확인해야 합니다.

"반응형 포함"이라면 모바일에서 레이아웃이 재구성되는지, 모바일 터치 영역을 기준으로 설계했는지, 실기기 테스트 범위가 무엇인지 물어봐야 합니다.

 

 

"유지보수 포함"이라면 기술 유지보수만 포함인지 콘텐츠 수정도 포함인지, 월 몇 회까지 포함인지, 장애 대응 시간이 어떻게 되는지, 백업 주기와 보관 기간이 무엇인지 확인해야 합니다.

"기본 기능 포함"이라면 기본에 게시판이 들어가는지 문의 폼이 들어가는지, 관리자에서 직접 수정 가능한 항목은 어디까지인지, 회원·권한·검색 같은 기능은 포함인지 별도인지 물어봐야 합니다.

오픈 이후 '숨은 비용'이 생기는 대표 패턴

수정이 잦은데 관리자 편집 범위가 좁으면 회사 정보, 제품, 배너, 인재채용처럼 바뀌는 콘텐츠가 많은데 매번 외주 수정으로 처리하게 돼서 운영 속도가 느려지고 비용이 누적됩니다. 예방책은 제작 단계에서 "자주 변경될 콘텐츠 목록"을 먼저 정리하고, 해당 영역을 관리자 편집으로 열어두는 것입니다.

 

 

기능 확장이 예상되는데 초기 구조가 닫혀 있으면 처음에는 단순 소개형으로 시작했지만, 시간이 지나면서 회원, 예약, 다국어, 결제 같은 기능이 필요해지는 경우가 있습니다. 초기 설계가 확장성을 고려하지 않으면, 기능 추가 때 기존 구조를 크게 뜯어고쳐야 해서 비용과 일정이 커질 수 있습니다.

 

 

호스팅·서버 이전이 계획 없이 발생하면 트래픽이 늘거나 보안 요구가 높아지거나 운영 정책이 바뀌면 서버 환경을 바꿔야 하는 순간이 옵니다. 이때 이전 비용은 단순 이전이 아니라 점검·테스트·다운타임 관리가 포함됩니다.

보안 업데이트가 누락되면 오픈소스 CMS를 쓰는 경우 업데이트를 미루면 취약점이 누적될 수 있습니다. 문제가 생기면 복구, 보안 강화, 데이터 점검이 동시에 발생해 비용과 리스크가 커집니다.

 

 

실무자가 견적을 읽는 순서

먼저 목적을 정의합니다. 명함형인지, 영업형인지, 서비스형인지, 쇼핑몰형인지 구분합니다. 그다음 기능 목록을 문장으로 받지 말고 항목으로 받습니다. 게시판, 문의폼, 검색, 제품 카탈로그, 관리자 기능을 항목화해 요청합니다. 반응형 구현 수준과 테스트 범위를 확인하고, 모바일에서 레이아웃이 재구성되는지, 실기기 테스트가 포함되는지 확인합니다. 수정 정책은 수정 횟수보다 수정 범위를 확인하고, 오픈 후 수정의 기준을 명확히 합니다. 마지막으로 소스 코드·데이터 이관 조건을 확인합니다. 계약 종료 시 소스와 데이터가 어떻게 이관되는지, 권한은 누구에게 있는지 확인합니다.

 

 

홈페이지 제작 비용·견적은 "얼마냐"보다 "무엇이 포함됐냐"를 먼저 보면 대부분의 함정을 피할 수 있습니다.

읽어주셔서 감사합니다.

 

 

 

희명웹이었습니다.