웹사이트 구축 및 유지보수 계약은 어떻게 체결해야 할까요? 납품 및 책임 조항을 중점적으로 검토하세요

웹사이트 구축 서비스를 구매할 때 가장 쉽게 분쟁이 발생하는 부분은 웹사이트가 열리는지 여부가 아니라, 어떤 상태를 납품 완료로 볼 것인지와 출시 후 문제가 생겼을 때 누가 처리할 것인지입니다. 웹사이트 구축 및 유지보수 계약(contrat de conception et de maintenance de site web)을 체결할 때는 페이지, 기능, 검수 방법 및 유지보수 범위를 실행 가능한 별첨 문서에 명시하고, 대금 지급 시점을 납품 결과와 연계해야 합니다。

웹사이트 구축 계약의 견적에는 웹사이트 운영을 시작한 후 지속적으로 발생하는 비용도 포함되어야 합니다. 도메인, 서버, 시스템 라이선스 및 후속 수정 비용을 누가 부담하는지는 실제 구매 비용에 직접적인 영향을 줍니다. 이러한 사항을 단지 ‘1년 유지보수 제공’이라고만 적어 두면 첫해 견적이 낮더라도 공급업체의 실제 제안을 비교하기 어렵습니다。

납품 목록에 ‘웹사이트 구축 완료’만 적어서는 안 됩니다

계약서에는 웹사이트 언어 버전, 페이지 유형, 메뉴 수, 주요 기능 및 호환성 요구사항을 기재해야 합니다. 예를 들어 다국어 웹사이트의 경우 번역과 업로드를 서비스 제공업체가 담당하는지, 아니면 기업이 번역문을 제공하는지 구분해야 합니다. ‘제품 전시’도 제품 분류, 상세 페이지의 항목, 이미지 수량 및 일괄 등록 방식 등을 명확히 해야 합니다. 문의 양식에는 필수 입력 항목, 수신 이메일 주소, 알림 방식 및 테스트 방법을 명시해야 합니다。

페이지 수의 산정 기준도 명확히 해야 합니다. 동일한 템플릿을 사용하는 여러 제품 상세 페이지를 템플릿 수로 계산할지, 실제 등록 수로 계산할지와 초과 시 비용을 어떻게 산정할지를 정해야 합니다. 기업이 제공하는 문안, 이미지 및 제품 자료의 제출 시점과 형식을 합의하고, 서비스 제공업체가 담당하는 디자인, 제작 및 등록 내용은 별도로 기재해야 프로젝트가 지연되었을 때 서로 책임을 떠넘기는 일을 방지할 수 있습니다。

계약에 검색 최적화의 기본 설정이 포함되는 경우, 웹사이트가 갖춘 기능과 최종 마케팅 성과를 구분해야 합니다. 예를 들어 각 페이지의 제목과 설명 설정, 사이트맵 생성, 페이지 리디렉션 설정은 확인 가능한 납품 항목입니다. 검색 순위, 색인된 페이지 수 및 문의 건수는 콘텐츠, 경쟁 상황과 검색엔진 규칙의 영향을 받으므로, 막연한 약속만으로 검수 기준을 삼아서는 안 됩니다. 광고 집행이나 장기 콘텐츠 운영도 웹사이트 구축 비용에 기본적으로 포함되는 것으로 간주해서는 안 됩니다。

검수 기준은 테스트할 수 있어야 하며, 분쟁에도 대응할 수 있어야 합니다

검수 별첨에는 테스트 환경, 브라우저 및 모바일 기기 호환 범위, 테스트 계정, 점검 항목과 결과 기록 방식을 명시해야 합니다. 문의 기능의 경우 테스트 정보를 제출하면 지정된 이메일 주소로 해당 입력 항목이 포함된 알림이 도착하도록 정할 수 있습니다. 또한 백엔드에 기록이 저장되는지, 스팸 필터링 방식이 정상적인 문의에 영향을 주지 않는지도 확인해야 합니다。

기능 외에도 다국어 페이지의 누락이나 잘못된 리디렉션 여부, 이미지 및 다운로드 파일의 접근 가능 여부, 기존 웹사이트를 개편할 때 보존하기로 한 URL의 리디렉션 완료 여부를 점검해야 합니다. 성능 지표를 정할 때는 테스트 도구, 테스트 페이지, 네트워크 또는 기기 조건과 제3자 플러그인이 결과에 미치는 영향도 함께 명시해 단순히 ‘페이지 로딩 속도가 빠를 것’이라고만 정하는 일을 피해야 합니다。

검수 절차에는 검수 요청, 문제 피드백, 수정 후 재검수 및 확인서 서명 기한이 포함되어야 하며, 출시를 막는 중대한 결함과 주요 기능에 영향을 주지 않는 일반적인 문제를 구분해야 합니다. 기한 내에 피드백이 없으면 검수에 합격한 것으로 간주할지 여부와 통지 방법 및 기산 시점을 명확히 해야 합니다. 해결되지 않은 결함이 있다면 웹사이트가 출시되었다는 이유만으로 모든 작업이 완료된 것으로 처리하지 말고, 문제 내용, 수정 기한 및 미해결 사항을 기록해야 합니다。

유지보수 비용의 범위는 항목과 서비스 수준별로 구분해야 합니다

유지보수에는 일반적으로 장애 복구, 보안 업데이트, 백업 및 복원, 콘텐츠 수정과 기능 조정이 포함되지만, 각 항목의 작업량은 크게 다릅니다. 계약서에는 서비스 시간, 접수 채널, 포함되는 수정 횟수 또는 작업 시간과 초과 시 견적 산정 방식을 명시해야 합니다. ‘무료 수정’이 문구나 이미지를 교체하는 것인지, 신규 페이지 디자인, 인터페이스 개발 및 기능 변경까지 포함하는지도 설명해야 합니다。

장애 대응 시에는 응답 시간과 복구 시간을 구분해야 합니다. 전자는 접수를 확인하고 처리를 시작하기까지의 기한이고, 후자는 서비스를 복구하기까지의 기한입니다. 웹사이트 접속 불가, 문의 기능 중단, 일부 화면 표시 오류 등의 상황에 따라 우선순위를 달리 정할 수 있습니다. 제3자 클라우드 서비스 장애나 기업이 필요한 권한을 제때 제공하지 않아 지연되는 경우에도 통지, 기록 및 협업 처리 방법을 명시해야 하며, 모든 문제를 단순히 면책 사유로 돌려서는 안 됩니다。

백업 조항에는 백업 주기, 보관 기간, 저장 위치, 복원 범위 및 복원 테스트 일정을 명시해야 합니다. ‘정기적으로 백업한다’고만 정해서는 장애 발생 후 웹사이트를 복원할 수 있다는 사실을 보장할 수 없습니다. 데이터베이스와 업로드 파일을 각각 백업하는 경우에는 두 항목을 함께 복원할 수 있는지도 확인해야 합니다. 유지보수 기간을 웹사이트 출시일, 검수일 또는 대금 지급일 중 어느 시점부터 계산하는지도 계약서에 명확히 기재해야 합니다。

대금 지급, 갱신 및 변경 비용은 서로 연계되어야 합니다

날짜만 기준으로 대금을 지급하는 것보다 단계별 지급이 납품 위험을 관리하기 쉽습니다. 계약에서 디자인 시안 승인, 테스트 환경 납품, 최종 검수 등의 단계에 대금 지급을 연계하고, 각 단계의 산출물과 확인 방법을 명시할 수 있습니다. 잔금 비율은 양측이 협의하되, 핵심 기능, 자료 이전 및 결함 수정이 확정되지 않은 상태에서 웹사이트가 출시되었다는 이유만으로 전액을 지급하는 것은 바람직하지 않습니다。

견적서에는 일회성 구축 비용, 연간 유지보수 비용, 클라우드 리소스, 도메인, 인증서, 플러그인 또는 라이선스 비용을 구분하고, 가격 적용 기간, 갱신 방식 및 세금 부담 주체를 명시해야 합니다. 방문자 수, 저장 공간 또는 제3자 인터페이스 사용량에 따라 과금되는 항목은 포함 한도, 초과 사용료 산정 방식 및 비용 확인 절차를 명확히 해야 합니다. 연간 예산 관리 절차를 거쳐야 하는 프로젝트라면 국유기업의 연간 투자 예산 편성 전략 및 실무를 참고해 연도 간 지출을 정리할 수도 있지만, 구체적인 비용은 계약서와 견적 별첨을 기준으로 해야 합니다。

요구사항 변경은 서면 절차에 따라 확인해야 합니다. 변경 요청, 비용과 일정 평가, 양측의 승인 후에 변경 작업을 진행해야 합니다. 승인되지 않은 신규 요구사항을 원래 계약의 작업으로 자동 간주해서는 안 되며, 서비스 제공업체가 일방적으로 추가 비용을 청구해서도 안 됩니다. 한쪽이 자료 제공, 피드백 또는 대금 지급을 지연해 일정에 영향을 주는 경우에는 통지 및 일정 조정 절차를 정해야 합니다。

계정, 데이터 및 계약 종료 절차는 기업의 통제하에 두어야 합니다

도메인 등록 정보, 클라우드 서비스, 분석 도구 및 광고 계정의 소유권, 관리자 권한과 갱신 책임을 명확히 해야 합니다. 가능한 경우 관련 계정은 기업이 보유하고 필요에 따라 서비스 제공업체에 사용 권한을 부여하는 것이 좋습니다. 서비스 제공업체가 대신 보유하는 경우에는 이전 조건, 시점 및 필요한 증빙 서류를 정해야 합니다. 그렇지 않으면 계약 만료 후 기업이 적시에 갱신하거나 DNS 설정을 변경하고 서비스 제공업체를 교체하기 어려울 수 있습니다。

웹사이트 납품 시에는 맞춤형 개발과 SaaS 웹사이트 구축을 구분해야 합니다. 맞춤형 프로젝트는 소스 코드, 디자인 파일, 데이터베이스 구조 및 배포 문서의 납품 범위와 사용 권한을 명확히 해야 합니다. SaaS 플랫폼은 구독 기간 중의 사용 권한, 내보낼 수 있는 페이지와 데이터의 형식, 플랫폼 템플릿이나 시스템의 이전 가능 여부 및 서비스 종료 후의 접근 가능 기간을 중점적으로 확인해야 합니다. ‘웹사이트는 기업 소유’라는 문구만으로 플랫폼 소프트웨어나 제3자 구성요소에 대한 모든 권리가 이전되었다고 추정해서는 안 됩니다。

고객 문의 정보와 연락처 등 개인정보를 취급하는 경우, 양측의 데이터 처리 권한, 비밀유지 의무, 보안 조치, 사고 통지, 계약 종료 후 데이터 내보내기 및 삭제 방안을 정하고 적용 법률과 웹사이트 서비스 지역의 요구사항에 따라 검토해야 합니다. 서비스 제공업체가 제3자 플러그인이나 하도급업체를 이용하는 경우에도 책임 범위와 필요한 권한 부여 조건을 명확히 해야 합니다。

계약 위반 책임은 입증 가능한 의무에 맞춰야 합니다

납품 지연, 검수 불합격, 핵심 장애의 장기 미복구, 무단 데이터 사용 등의 상황별로 시정 기한, 계약 위반 책임 및 계약 해지 조건을 명시해야 합니다. 위약금이나 배상 방식은 계약 금액과 손실 위험을 고려해 협의해야 합니다. 발동 조건과 처리 절차 없이 ‘위반 당사자는 모든 책임을 부담한다’고만 적는 것은 피해야 합니다。

계약 체결 전에 당사자 명칭, 계약 체결 권한, 수취 계좌 및 세금계산서 발행 정보를 확인하고, 본문, 견적서, 요구사항 목록, 검수 기준 및 서비스 수준 별첨 간의 우선순위를 확인해야 합니다. 국경 간 계약이나 복잡한 데이터 처리와 관련된 경우에는 준거법, 분쟁 해결 방식 및 계약 언어 버전도 검토해야 합니다. 중요한 조항은 프로젝트 상황에 따라 전문 법률 담당자의 검토를 받을 수 있습니다。