샤먼 웹사이트 구축 업체를 선택할 때는 계약서에 ‘전체 소스 코드 인도’라고만 명시해서는 안 됩니다. 어떤 파일을 인도하는지, 어떻게 사용할 수 있는지, 독립적으로 배포할 수 있는지, 검수는 어떻게 진행할지를 명확히 해야 합니다. 그렇지 않으면 웹사이트를 오픈한 뒤 압축 파일을 받더라도 데이터베이스, 의존 구성 요소 또는 실행 권한이 없어 서버나 서비스 업체를 변경하지 못할 수 있습니다.
구매 단계에서 먼저 확인해야 할 사항은 독립 배포 가능한 웹사이트를 구매하는지, 아니면 연간 구독 방식의 웹사이트 구축 서비스를 이용하는지입니다. 전자의 경우 소스 코드, 데이터, 배포 자료를 인도 항목에 포함해야 합니다. 후자의 경우 플랫폼 소스 코드를 제공하지 않을 수도 있으므로 데이터 내보내기, 도메인 관리 권한, 서비스 종료 및 이전 지원을 중점적으로 약정해야 합니다. 두 가지 방안 모두에 ‘소스 코드는 갑의 소유’라는 한 문구만 적용해서는 구체적인 약정을 대신할 수 없습니다.
백오피스 관리자 계정이 있다는 것은 기업이 콘텐츠를 관리할 수 있다는 뜻일 뿐, 웹사이트 프로그램을 취득했다는 의미는 아닙니다. 브라우저에서 확인할 수 있는 페이지 코드도 비즈니스 로직, 인터페이스, 데이터베이스 구조를 포함한 전체 프로젝트 소스 코드와는 다릅니다.
견적을 비교할 때 공급업체에 견적서 첨부 문서에서 다음 세 가지 질문에 직접 답하도록 요청할 수 있습니다. 웹사이트를 기업이 지정한 서버에 배포할 수 있는가? 구독 갱신을 중단하면 어떤 기능을 사용할 수 없는가? 제3자 기술팀이 허용된 범위 내에서 유지보수를 인계받을 수 있는가? 답변에 ‘플랫폼 지원이 필요하다’는 내용이 있다면, ‘추후 협의 가능’이라는 말만 받아들이지 말고 필요한 의존 항목과 비용을 추가로 명시해야 합니다.
SaaS 방식으로 웹사이트를 구축한다고 해서 부적합한 방안인 것은 아닙니다. 하지만 기업이 향후 독립적으로 운영하기를 원한다면 계약 전에 독립 배포 방안이 있는지 확인해야 합니다. 웹사이트 오픈 후에 플랫폼의 기반 코드를 공개하라고 요구해서는 안 됩니다.
공급업체가 모든 책임을 ‘웹사이트 전체 패키지’라는 한마디로 뭉뚱그리지 않도록, 다음 항목을 계약서 첨부 문서로 작성하고 ‘인도’, ‘해당 없음’ 또는 ‘제3자 라이선스’로 표시하는 것이 좋습니다.
운영 환경 비밀번호와 인터페이스 키를 코드 패키지에 직접 기재해서는 안 됩니다. 보안이 보장되는 방식으로 별도 전달하고, 인계 후에는 키를 변경하고 공급업체에 더 이상 필요하지 않은 권한을 취소해야 합니다.

웹사이트에는 일반적으로 맞춤 제작 코드, 공급업체의 기존 구성 요소, 제3자 소프트웨어가 함께 사용됩니다. 계약에서는 각 권리를 구분해 약정해야 합니다. 맞춤 제작 부분의 소유권 또는 사용 라이선스, 기존 구성 요소의 지속적인 사용 가능 여부, 제3자 구성 요소에 적용되는 라이선스를 각각 명시해야 합니다. 공급업체가 양도할 권한이 없는 콘텐츠의 양도를 요구해서는 안 되며, 대금을 지급했다고 해서 모든 저작권을 자동으로 취득한다고 가정해서도 안 됩니다.
구매자가 보다 직접적으로 확인할 사항은 기업이 직접 또는 제3자에게 위탁해 웹사이트를 수정, 백업, 배포, 유지보수할 수 있는지 여부입니다. 이러한 권리가 도메인, 서버 수, 사용 기간 또는 구독 갱신 조건의 제한을 받는지도 확인해야 합니다. 관련 라이선스는 웹사이트의 실제 운영에 필요한 범위를 포괄해야 하며, 종료 조건도 명시해야 합니다.
글꼴, 이미지, 상용 플러그인은 현재 도메인에서만 사용할 수 있도록 라이선스가 부여된 경우도 있습니다. 도메인을 변경하거나, 다국어 사이트를 복제하거나, 사이트를 추가할 때 추가 구매가 필요한지 사전에 확인해야 합니다. 공급업체는 알고 있는 제한 사항을 공개해야 하며, ‘소스 코드 인도’를 라이선스 관련 설명의 대용으로 삼아서는 안 됩니다.
파일을 다운로드하고 압축을 풀 수 있다는 것만으로는 인계가 완전히 끝났다고 볼 수 없습니다. 더 신뢰할 수 있는 검수 방식은 약정한 별도의 테스트 환경에서 인도 문서에 따라 다시 배포한 뒤, 계약 범위에 포함된 핵심 기능을 확인하는 것입니다.
테스트 환경에서 정식 결제, 이메일 등의 서비스를 재사용할 수 없는 경우에는 대체 검증 방식을 미리 약정해야 합니다. 검수 과정에서 발견된 결함은 기록으로 남기고, 배포를 막는 문제와 일반적인 결함을 구분해 수정 기한과 재검수 방식을 명시해야 합니다.
소스 코드는 프로젝트 종료 시 한 번만 인도하는 방식으로 해서는 안 됩니다. 테스트 검수와 정식 오픈 시점에 각 버전을 인도하도록 약정하고, 이후 유상으로 진행하는 기능 개선도 소스 코드와 문서를 함께 갱신해야 합니다. 잔금 지급 조건은 단순히 ‘웹사이트에 접속할 수 있음’이 아니라 약정된 인도물과 검수 결과에 연동해야 합니다.
계약 조항은 다음과 같은 방향으로 구체화할 수 있습니다. 을은 약정된 시점에 첨부 문서에 명시된 소스 코드, 데이터 및 배포 자료를 인도한다. 갑 또는 갑이 위탁한 업체는 약정된 라이선스 범위 내에서 배포, 수정 및 유지보수를 할 수 있다. 인도되지 않는 항목과 제3자 제한 사항은 계약 체결 전에 명시해야 한다. 누락이 발견되거나 문서에 따라 배포할 수 없는 경우, 을은 약정된 기한 내에 이를 보완하고 재검수에 협조해야 한다. 구체적인 기한, 검수 조건, 계약 위반에 대한 처리는 양측이 기입하고 확인해야 합니다.
계약 종료 조항에는 데이터 내보내기 기한과 형식, 이전 지원 범위, 비용 산정 방식, 데이터 보관 방안도 명확히 기재해야 합니다. 도메인 등록 명의와 주요 계정은 가능한 한 기업이 관리해야 하며, 인계 확인 전에는 운영 데이터를 임의로 삭제해서는 안 됩니다.
샤먼 웹사이트 구축 서비스 업체를 선정할 때는 상대 업체에 민감 정보를 삭제한 인도 목록, 배포 문서 샘플, 라이선스 제한 목록을 제출하도록 요청할 수 있습니다. ‘소스 코드는 전부 제공한다’고만 약속하고 독립 배포 조건과 검수 방식을 확인해 주지 않는 방안은 이전 가능한 웹사이트로 구매하기에 적합하지 않습니다.
관련 기사
관련 제품


