시안 웹사이트 구축 계약에서 소스 코드 납품 범위를 어떻게 정해야 할까요?

시안 웹사이트 제작 계약을 체결할 때 “소스 코드 전체 제공”이라는 문구만으로는 범위가 명확하지 않습니다. 어떤 파일을 제공하는지, 어떻게 사용할 수 있는지, 독립적으로 배포할 수 있는지, 서비스 중단 후 어떻게 이전할지를 각각 명확히 작성해야 합니다. 코드 압축 파일을 받았다고 해서 저작권 전체를 취득한 것은 아니며, 다른 서비스 업체로 바꾸더라도 계속 유지관리할 수 있다는 뜻도 아닙니다.

견적을 비교하기 전에 프로젝트가 맞춤형 개발인지, 오픈소스 시스템을 기반으로 한 2차 개발인지, SaaS 플랫폼을 이용한 웹사이트 구축인지 먼저 확인하세요. 세 가지 방식은 제공 범위가 서로 다르므로, 계약서에서 “소스 코드는 갑의 소유로 한다”라는 한 문장으로 모두 정리해서는 안 됩니다.

맞춤형 코드, 제3자 구성 요소, 플랫폼 사용권을 먼저 구분하세요

맞춤형 개발 프로젝트에서는 본 프로젝트를 위해 새로 작성한 프런트엔드 및 백엔드 코드와 이에 대한 수정, 배포, 위탁 유지관리 권한을 제공하도록 정할 수 있습니다. 서비스 업체가 기존에 보유한 공용 프레임워크와 도구 라이브러리가 포함되는지는 별도로 명시해야 하며, 프로젝트와 함께 모두 양도된다고 가정해서는 안 됩니다.

오픈소스 시스템을 기반으로 개발한 웹사이트는 기존 프로그램, 상용 플러그인, 신규 코드를 구분해야 합니다. 오픈소스라고 해서 사용 조건이 없는 것은 아닙니다. 상용 플러그인은 설치되어 있더라도 도메인 연동, 사이트 수 제한, 만료 후 갱신 등의 조건이 있을 수 있습니다.

SaaS 웹사이트 구축은 일반적으로 플랫폼 사용 서비스를 제공하며, 플랫폼의 기반 소스 코드는 대개 제공 범위에 포함되지 않습니다. 이 경우에는 콘텐츠 및 데이터 내보내기, 도메인 관리, 갱신 규정, 서비스 종료 후 절차에 더욱 주의를 기울여야 합니다. 기업이 자체 배포를 명확히 요구한다면, 선정 단계에서 해당 조건을 지원하지 않는 방안을 제외해야 합니다.

예를 들어, 웹사이트 구축과 해외 마케팅을 통합한 이잉바오와 같은 SaaS 솔루션을 검토할 때는 플랫폼 사용권, 웹사이트 데이터 내보내기, 마케팅 계정 관리 방식을 각각 문의해야 합니다. “웹사이트 구축 서비스 제공”을 “플랫폼 소스 코드 제공”으로 이해해서는 안 됩니다.

소스 코드 범위를 별첨으로 작성하고 웹사이트 기능별로 명시하세요

계약 별첨은 “제공 대상, 파일 내용, 권리 범위, 제한 조건” 형식으로 작성할 수 있습니다. 제공하지 않는 항목도 명칭과 용도, 대체 방안 또는 갱신 조건을 명시해야 검수 단계에서 핵심 기능에 추가 라이선스가 필요하다는 사실을 뒤늦게 발견하는 일을 방지할 수 있습니다.

• 웹사이트 프로그램: 프런트엔드 소스 파일, 백엔드 업무 코드, 스타일, 스크립트 및 관련 설정 템플릿. 브라우저에서 접속할 수 있는 페이지만 제공하거나 압축된 실행 파일만 제공하는 것은 유지관리 가능한 소스 코드의 제공을 의미하지 않습니다.
• 데이터베이스 및 콘텐츠: 데이터베이스 구조, 합의된 범위의 데이터 백업, 이미지·동영상·첨부 파일 등 업로드된 파일. 사이트 개설 전에 제공하는 빈 데이터베이스는 운영 이후의 데이터 이전을 대신할 수 없습니다.
• 배포 자료: 운영 환경 버전, 종속성 목록, 설치 단계, 빌드 명령 및 예약 작업 설명을 제공하여 인수 담당자가 문서에 따라 배포할 수 있도록 합니다.
• 종속성 및 라이선스: 오픈소스 구성 요소, 상용 테마, 글꼴, 플러그인 및 외부 인터페이스 목록에 라이선스 주체, 유효 기간, 비용 부담 및 이전 제한을 명시합니다.

디자인 원본 파일, 전체 개발 이력, 내부 테스트 도구의 제공 여부도 별도로 명시하여 웹사이트 운영에 필수적인 코드와 혼동되지 않도록 해야 합니다. 비밀번호와 API 키 등 민감한 정보는 안전한 방식으로 이전하고, 인계 후 변경해야 합니다.

“소스 코드 제공”과 “저작권 보유”는 별도로 합의해야 합니다

소스 코드는 제공물이고, 저작권 및 사용 허가는 권리 관계에 관한 사항입니다. 계약서에서 본 프로젝트의 신규 성과물, 서비스 업체의 기존 성과물, 제3자 성과물을 구분한 다음, 각 항목의 귀속 또는 사용 허가 범위를 별도로 정해야 합니다.

후속 유지관리를 기존 서비스 업체에 종속되지 않게 하는 것이 주된 목적이라면, 기업이 직접 수정할 수 있는지, 다른 팀에 유지관리를 위탁할 수 있는지, 서버를 이전할 수 있는지, 합의된 범위에서 웹사이트를 배포할 수 있는지를 명확히 해야 합니다. “영구 사용”이라고만 작성해도 배포 수량, 사용 주체, 수정 권한이 불명확하게 남을 수 있습니다.

맞춤형 개발 성과물의 관련 저작권을 실제로 양도받으려는 경우에는 구체적인 권리, 해당 성과물, 효력 발생 조건을 명시해야 합니다. 제3자 구성 요소는 해당 라이선스를 따라야 하며, 포괄적인 조항 하나로 기존 사용 허가를 대체할 수 없습니다.

검수는 압축 파일이 열리는지만 확인해서는 안 됩니다

더 효과적인 검수 방법은 계약에서 정한 독립 환경에서 제공 자료를 바탕으로 직접 배포한 뒤, 페이지 접속, 관리자 로그인, 콘텐츠 게시, 양식 제출, 파일 업로드 등 핵심 기능을 확인하는 것입니다. 문의 이메일, 결제 또는 물류 인터페이스가 있다면 계정을 재설정한 뒤에도 정상적으로 연동되는지 확인해야 합니다.

이를 통해 파일은 모두 갖춰진 것처럼 보이지만 실제로는 서비스 업체가 공개하지 않은 인터페이스, 라이선스 서버 또는 암호화 모듈에 의존해 다른 환경에서는 작동하지 않는 흔한 문제를 확인할 수 있습니다. 사용이 허용된 종속 항목은 사용 조건과 비용을 사전에 명시해야 합니다.

마케팅 웹사이트를 이전할 때는 가치 있는 페이지 주소, SEO 제목과 설명, 리디렉션 규칙, 필요한 통계 및 전환 추적 설정도 보존해야 합니다. 웹사이트가 열리는 것만으로 기존 홍보 활동이 완전히 이어진다고 볼 수는 없습니다.

계약서에는 소스 코드 제공, 배포 검증, 결함 수정을 검수 조건으로 포함하고, 해당 대금 지급 시점을 검수 결과와 연계해야 합니다. 사이트 개설 후 수정된 코드도 제공 시점을 합의해 인계받는 코드가 구버전이 되지 않도록 해야 합니다.

가격에는 후속 인수 비용도 포함해 검토하세요

시안 웹사이트 제작 견적을 비교할 때는 개발비, 소스 코드 제공 비용, 제3자 라이선스 비용, 배포 및 이전 비용, 지속 서비스 비용을 나누어 살펴봐야 합니다. 견적이 저렴해도 장기간 유료 인터페이스에 의존하면 종료 비용이 늘어날 수 있으며, 모든 공용 기반 코드를 함께 양도하도록 요구하면 초기 비용이 높아질 수 있습니다.

장기간의 2차 개발, 여러 시스템과의 연동, 자체 운영이 필요한 웹사이트라면 독립 배포 및 유지관리 권한을 중시하는 것이 적합합니다. 표준형 기업 소개 웹사이트를 SaaS 서비스로 구축한다면 데이터 내보내기 가능 여부, 예측 가능한 비용, 계약 종료 후 이전 방안에 중점을 둘 수 있습니다.

계약 조항은 다음과 같이 구체화할 수 있습니다

아래 문구를 제공 조항의 기본으로 삼고, 별첨에 구체적인 내용을 보완할 수 있습니다.

“을은 별첨 《소스 코드 및 관련 자료 제공 목록》에 따라 최종 검수 버전과 일치하는 프로그램 소스 파일, 데이터베이스 구조 및 합의된 데이터, 리소스 파일, 종속성 목록, 배포 문서를 제공해야 한다. 프로젝트의 신규 성과물, 을의 기존 성과물 및 제3자 구성 요소의 권리 귀속, 사용 허가 범위와 제한 조건은 각각 별첨에 따른다. 제공 성과물은 합의된 환경에서 문서에 따라 배포할 수 있어야 하며, 합의된 기능 검수를 통과해야 한다. 공개되지 않은 필수 종속성으로 인해 배포 또는 실행이 불가능한 경우, 을은 합의된 기간 내에 이를 보완하거나 수정해야 한다.”

제공일, 수정 기한, 이전 지원 범위, 계약 위반 시 처리 방식도 추가로 정하세요. 계약 체결 전에 서비스 업체가 목록의 각 항목을 작성하도록 하는 것이, 막연히 “소스 코드 전체 제공”이라고 한 문장을 남기는 것보다 해당 비용으로 실제 무엇을 받는지 판단하는 데 더 효과적입니다.