웹사이트 개발 계약에서 어떤 조항을 먼저 확인해야 합니까?
먼저 납품 범위를 확인하고, 총액만 보지 마세요.
많은 기업이 웹사이트 제작 계약을 체결할 때 우선적으로 가격을 확인하지만, 이후 과정이 순조롭게 진행되는지를 실제로 결정하는 것은 대개 견적 금액이 아니라 계약서에 납품 범위가 명확하게 기재되어 있는지입니다.
예를 들어 홈페이지와 내부 페이지를 정확히 몇 개씩制作할지, 모바일 최적화가 포함되는지, 콘텐츠 입력은 어느 수준까지 진행할지, 이미지와 사례 자료는 누가 정리할지, 공개 후 기본 테스트가 포함되는지 등입니다. 이러한 사항을 사전에 명시하지 않으면 이후 실행 단계에서 이해 차이가 지속적으로 발생할 수 있습니다.
기업에 있어 계약의 가장 핵심적인 의미는 “협력하기로 했다는 점을 확인하는 것”이 아니라, 양측이 프로젝트 범위에 대해 가진 인식을 고정하는 데 있습니다. 범위가 명확할수록 이후 추진이 안정적이며, 세부적인 문제에서 자꾸 다투는 일도 줄어듭니다.
수정 라운드와 피드백 방식은 반드시 사전에 합의해야 합니다.
웹사이트 프로젝트에서 가장 흔한 분쟁 중 하나는 양측 당사자가 ‘수정’에 대해 이해하는 것이 다르다는 점입니다. 기업 측에서는 페이지가 기대한 수준에 미치지 못했으므로 계속 수정해야 한다고 생각할 수 있지만, 서비스 제공자 측에서는 이미 원래 정해진 범위를 벗어났다고 판단할 수 있습니다. 이 문제를 계약서에 미리 명확히 명시하지 않으면, 이후에 거의 반드시 분쟁이 발생합니다.
더 안정적인 방법은 핵심 마일스톤을 나누어 명확히 명시하는 것입니다. 구조 확인은 몇 회, 홈페이지 디자인은 몇 회, 내부 페이지 확장은 몇 회, 출시 전 연동 테스트는 몇 회인지 적어 주면 됩니다. 이렇게 하면 기업은 자신의 피드백을 제공할 수 있는 시점을 알 수 있을 뿐 아니라, 프로젝트가 상당히 진행된 뒤에 대규모 수정 작업이 다시 발생하는 것도 피할 수 있습니다.
회차뿐만 아니라 피드백 방식이 명확한지도 살펴봐야 합니다. 한 번에 모아서 제출하는지, 화면별로 하나씩 확인하는지, 문서로 정리해 제출하는지, 온라인으로 코멘트를 남기는지, 회차별 피드백 시간을 미리 정하는지—이런 요소들이 모두 프로젝트 효율에 직접적인 영향을 미칩니다. 많은 프로젝트가 지연되는 것은 설계가 어렵기 때문이 아니라, 피드백 메커니즘 자체가 명확하지 않기 때문입니다.
콘텐츠 소유권, 소스 코드 전달 및 배포 지원은 모호해서는 안 됩니다.
기업 공식 홈페이지가 오픈된 후에도 보통은 계속해서 사례를 보충하고, 글을 추가하며, 제품 자료를 수정해야 하므로, 콘텐츠와 납품물의 귀속을 반드시 사전에 확인해야 합니다. 디자인 원고, 프런트엔드 페이지, 관리자 계정, 이미지 소스, 이미 등록된 글과 사례 중 무엇이 함께 인계되고, 무엇이 기간 한정 사용 권한만 가지는지, 이 모든 사항을 계약서에 명시해야 합니다.
특히 소스 코드와 백오피스 관리 권한은, 기업이 이후 공식 웹사이트를 장기적으로 운영할 계획이라면, 런칭 이후에 인계 가능한지 나중에 물어볼 일이 아닙니다. 진정으로 성숙한 프로젝트라면 계약 단계에서 다음 사항을 명확히 해야 합니다. 운영 환경은 누가 제공하고, 도메인과 서버는 누가 관리하며, 향후 이전이 가능한지, 기업이 직접 콘텐츠를 유지·관리할 수 있는지 여부입니다.
배포 지원 역시 중요합니다. 일부 계약서는 "페이지 제작"만 명시하고, 배포 연동 테스트, 브라우저 호환성 점검, 폼 테스트, 기본적인 페이지 이동 검증 및 오류 수정 지원은 포함하지 않습니다. 즉, 프로젝트는 페이지가 완성된 것처럼 보여도 실제로는 아직 배포 가능한 상태에 도달하지 못했을 수 있습니다.
후속 유지보수 범위를 명확히 정의해야 프로젝트가 출시 후에도 중단되지 않습니다.
많은 기업은 공식 웹사이트를 오픈한 이후의 작은 변경 사항도 프로젝트에 포함된다고 기본적으로 생각하지만, 서비스 제공자 입장에서는 계약에 그러한 내용이 명시되어 있지 않은 한 이러한 작업이 추가 유지보수 업무로 간주되는 경우가 많습니다. 가장 이견이 생기기 쉬운 지점은 바로 여기에 있습니다.
따라서 계약 체결 전에 웹사이트 출시 후의 지원 기간, 문제 수정 범위, 콘텐츠 업데이트 비용 별도 여부, 이후 페이지를 추가할 경우 과금 방식 등을 함께 확인하는 것이 좋습니다. 이는 일을 지나치게 복잡하게 만들기 위해서가 아니라, 웹사이트가 출시되자마자 협력 관계가 불분명한 회색 지대에 빠지지 않도록 하기 위해서입니다.
기업에 더 유리한 계약은 보통 분량이 가장 긴 계약이 아니라, 핵심 조항이 충분히 구체적인 계약입니다. 인도 범위, 수정 메커니즘, 출시 지원 및 유지보수의 경계를 명확히 적어 두면, 웹사이트 프로젝트는 “양측의 암묵적 합의”에 의존해 진행되던 방식에서 “명확한 규칙에 따른 진행”으로 바뀝니다. 그래야 더 안정적이며, 장기적으로 활용하기에도 적합합니다.