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

이번 칼럼은 홈페이지 제작 외주·업체 선정에 관한 이야기입니다. "좋은 업체를 추천"하는 글이 아니라 실무자가 견적과 계약을 해석할 때 손해를 막는 구조적 판단 기준을 정리했습니다.

 

 

외주 업체 선정에서 가장 많이 착각하는 비교 기준 4가지

처음 외주를 맡기는 실무자는 대개 포트폴리오 디자인, 총 견적 금액, 유지보수 포함 문구, 표준 계약서라는 네 가지에 마음이 기웁니다. 그런데 이 네 가지는 오픈 직후에는 문제를 숨기고, 오픈 6개월~1년쯤 지나 운영 단계에서 분쟁으로 터지는 일이 많습니다. 이유는 "완성물"을 비교했지 "운영 구조"를 비교하지 않았기 때문입니다.

 

 

포트폴리오는 보통 오픈 당시의 스크린샷입니다. 중요한 건 지금 상태입니다. 실제 URL을 열어보면 로딩이 느리거나 모바일에서 깨지거나, 클릭 동선이 불편한 경우가 있습니다. 더 본질적인 문제는 운영 편의성입니다. 예쁘게 만든 화면과, 내부에서 자주 바뀌는 콘텐츠를 쉽게 바꿀 수 있는 구조는 별개의 역량입니다. 포트폴리오가 좋아 보여도 오픈 후 제품 페이지 추가, 배너 교체, 메뉴 변경 같은 요청이 매번 유료라면 내부에서는 "수정이 막히는 사이트"가 됩니다.

유지보수라는 단어는 업체마다 정의가 다릅니다. 어떤 곳은 보안 업데이트와 백업만 포함이고, 어떤 곳은 텍스트·이미지 수정도 월 몇 회까지 포함, 어떤 곳은 운영 리포트까지 포함입니다. "유지보수 1년 포함" 한 줄로는 콘텐츠 수정이 무료인지 아닌지 알 수 없습니다. 문장 하나로 믿으면, 오픈 후 사진 교체나 문구 수정부터 갈등이 시작됩니다. 유지보수는 문구가 아니라 범위표로 받아야 합니다.

 

 

저가 견적이 무조건 나쁘다는 뜻이 아닙니다. 다만 저가 견적은 대개 '오픈까지만' 책임지고, 운영 비용을 후불 구조로 설계하는 경우가 많습니다. 오픈 이후에 자주 바뀌는 요소가 많은 회사라면, 수정이 누적될수록 장기 총비용이 올라갑니다. 결국 비교의 단위는 제작비가 아니라 "3년 총비용(제작 + 운영 + 확장)"이 돼야 합니다.

 

 

외주 분쟁은 누가 더 성실했냐가 아니라, 계약서에 정의가 없어서 생깁니다. 특히 범위, 수정 정책, 납품물, 일정, 권한, 소스코드·이관 조건 6곳에서 터집니다. 계약서를 '표준이니까 괜찮겠지'로 넘기면, 운영 권한이 업체로 기울어지고 이관이 막혀서 재제작 비용이 생길 수 있습니다.

 

 

업체 유형을 구조로 분류하면 선택이 쉬워집니다

업체를 "잘한다/못한다"가 아니라 구조로 나누면 판단이 단순해집니다.

조직 형태로 보면 프리랜서는 의사소통이 빠르고 유연하지만 장기 유지보수와 인수인계 리스크가 있습니다. 소규모 에이전시는 역할 분담이 있어 안정적이지만 특정 핵심 인력에 의존할 수 있습니다. 중견 이상은 프로세스와 관리가 체계적이지만 커뮤니케이션 단계가 늘고 비용과 일정이 커질 수 있습니다.

 

 

작업 방식으로 보면 템플릿 제공형은 빠르고 예산 부담이 낮지만 구조 변경이 제한되고 유사한 형태가 나올 수 있습니다. 맞춤형 개발형은 확장성과 차별화에 유리하지만 요구사항 정의가 명확해야 하고 검수와 문서화가 중요합니다. 전략 컨설팅형은 전환과 성과를 목표로 설계하지만 초기 투입이 크고 기간이 길 수 있습니다.

이 분류의 의미는 단순합니다. 우리 회사의 목적이 명함형인지, 영업형인지, 서비스형인지에 따라 "맞는 구조"가 달라진다는 점입니다.

견적서·제안서를 받을 때 '질문 리스트'로 범위를 고정하세요

 

 

실무에서 가장 안전한 방법은 "문장"이 아니라 "질문"으로 범위를 고정하는 겁니다. 아래 질문은 업체 비교를 공정하게 만들고, 나중에 추가 비용 분쟁을 줄입니다.

범위를 확인할 때는 페이지 수의 정의가 무엇인지, 게시판·문의폼이 몇 개인지, 문의폼이 DB 저장인지 이메일 발송인지, 관리자에서 무엇을 수정할 수 있는지, SEO 기본 설정과 분석 도구 연동이 포함인지 등을 항목으로 확인합니다.

디자인·수정 정책은 수정 횟수보다 수정 범위를 확인합니다. 색상·폰트 변경만 가능한지, 섹션 재배치와 레이아웃 변경도 가능한지, 모바일 시안을 별도로 제공하는지, 원본 디자인 파일 납품 여부를 확인해야 합니다.

반응형·테스트는 "반응형 포함"이라는 답변은 대부분 "예"입니다. 중요한 건 구현 수준입니다. 모바일에서 레이아웃이 재구성되는지, 터치 영역 기준을 지키는지, 실기기 테스트를 하는지, 어떤 브라우저까지 지원하는지 확인합니다.

기술 스택·이관에서 어떤 방식인지보다 중요한 건 유지보수와 이관 가능성입니다. 소스코드, DB 덤프, 관리자 매뉴얼, 기술 문서 제공 여부를 납품물로 확정해야 합니다.

 

 

계약서에서 자주 터지는 조항 6개만 잡아도 분쟁이 줄어듭니다

계약서 전체를 완벽히 바꾸기 어렵다면, 최소한 아래 6개는 문장으로 고정해야 합니다.

범위와 산출물은 페이지 구성과 기능을 항목화하고 제외 항목을 명시합니다. 수정 정책은 수정 횟수, 수정 범위, 초과 단가를 정합니다. 일정과 지연은 단계별 마일스톤, 고객 피드백 기한, 지연 처리 원칙을 명시합니다. 소스코드·소유권은 대금 완납 시 소스코드·데이터가 고객 귀속, 이관 조건을 명시합니다. 유지보수 범위는 시스템·콘텐츠 포함 범위, 월 무료 범위, 장애 대응 기준을 정합니다. 검수·하자는 검수 기간, 하자 보증 범위, 계약 범위 내 오류는 무상 수정으로 합니다.

핵심은 "모호한 단어를 없애는 것"입니다. 맞춤 제작, 기본 기능, 유지보수 포함 같은 표현은 반드시 항목표로 바꿔야 안전합니다.

 

 

오픈 이후 의존도가 폭발하는 패턴 4가지와 예방

오픈 후 6개월~1년 차에 실무자가 제일 많이 후회하는 지점은 "수정이 안 된다"입니다. 패턴은 거의 고정입니다.

배너·제품·공지 같은 자주 바뀌는 요소가 관리자에서 수정 불가하면 외주 비용이 누적됩니다. 제작 전에 "자주 바뀌는 요소 리스트"를 만들고, 그 영역을 관리자 편집으로 열어야 합니다.

 

 

회원, 예약, 다국어처럼 나중에 붙일 가능성이 있다면 초기 설계에서 확장성을 고려해야 합니다. 데이터 구조와 메뉴 구조가 닫혀 있으면 추가 개발이 커집니다.

유지보수가 끝났는데 업데이트와 백업이 멈추면, 사고 비용이 발생합니다. 자동 백업과 복구 방식, 업데이트 주기는 계약서에 포함되어야 합니다.

 

 

트래픽이 늘거나 정책이 바뀌면 이전이 필요합니다. 계정 권한을 고객이 갖고, 정기 백업을 받으며, 이전 가이드가 있어야 종속을 줄일 수 있습니다.

홈페이지 제작 외주는 업체의 실력만큼이나, 계약서에서 범위와 권한을 어떻게 정의하느냐가 결과를 결정합니다.

 

 

감사합니다.

 

희명웹이었습니다.