많은 대표님들이 웹사이트 개발 계약서에 서명할 때 견적과 공기에만 집중하고, 산출물 항목에는 "웹사이트 한 세트, 소스 코드 한 세트"라고 대충 적습니다. 프로젝트가 끝나고 나서야 알게 됩니다. 디자인 시안은 주지 않고, 백엔드 계정은 을 측이 쥐고 있고, 서버는 상대방 명의로 되어 있으며, 배너 하나 수정하는 데도 추가 비용이 든다는 사실을요.
이것은 누가 나쁘기 때문이 아니라 계약서에 명확히 쓰지 않았기 때문입니다. 산출물을 구체적으로 작성할수록 이후가 편해집니다. 아래에서 다섯 가지로 나누어 설명하고, 각 항목마다 그대로 참고해 수정할 수 있는 작성법을 제시합니다.
1. 소스 코드와 배포 패키지: "무엇을, 어떻게 줄 것인지" 명확히
소스 코드는 가장 모호해지기 쉬운 항목입니다. 계약서에 세 가지를 명확히 할 것을 권장합니다. 어떤 코드를 납품하는지, 어떤 형식으로 납품하는지, 납품 후 독립적으로 실행할 수 있는지입니다.
실현 가능한 작성법은 다음과 같습니다. 프런트엔드 소스 코드, 백엔드 소스 코드, 데이터베이스 구조 파일, 배포 설명 문서를 패키징하여 납품하고, 납품 후 갑 측이 자체 서버에서 독립적으로 배포·운영할 수 있음을 약정합니다.
주의할 점은 두 가지입니다. 첫째, "소스 코드 제공"만 쓰고 데이터베이스 구조를 쓰지 않으면 코드를 받아도 실행할 수 없습니다. 둘째, 코드에 을 측이 자체 구축한 사설 컴포넌트나 암호화 파일을 참조하면 표면적으로는 납품했지만 실제로는 상대방 없이는 사용할 수 없습니다. 기업 웹사이트 같은 프로젝트는 특히 주의해야 하며, 많은 템플릿 사이트의 이른바 소스 코드는 사실 라이선스가 포함된 2차 패키징입니다.
미니프로그램 개발이라면 추가로 명확히 해야 합니다. 미니프로그램 주체 계정은 갑 측 소유이며, 코드는 갑 측 자신의 개발자 백엔드에 제출할 수 있어야 합니다.
2. 디자인 시안과 소재: 스크린샷만 주지 마세요
디자인 산출물에는 편집 가능한 원본 파일(예: Figma, Sketch 또는 PSD), 슬라이스 리소스, 폰트와 아이콘 사용 설명을 명시할 것을 권장합니다.
JPG 스크린샷만 주는 것은 주지 않은 것과 같습니다. 이후 디자이너를 교체하거나 이벤트 페이지를 확장 제작할 때 전부 다시 그려야 합니다.
소재 저작권 귀속도 약정해야 합니다. 을 측이 사용한 이미지, 폰트, 아이콘이 상업적 사용이 가능한지, 저작권 분쟁 발생 시 누가 책임지는지입니다. 이 조항은 웹사이트 개발 프로젝트에서 자주 간과되지만, 실제로 문제가 생기면 바로 사이트가 내려갑니다.
3. 도메인, 서버, 계정: 소유권은 반드시 명시
분쟁이 빈번한 영역입니다. 계약서에 명확히 해야 합니다. 도메인은 갑 측 명의로 등록하고, 서버 또는 클라우드 계정은 갑 측이 실명으로 구매하며, 을 측은 개발 및 운영 기간의 필요한 조작 권한만 보유합니다.
구체적인 사례 하나: 어떤 회사가 공식 홈페이지를 개편했는데, 완료 후 도메인이 이전 서비스 업체 손에 있어 갱신에 추가 비용이 들고 이전에 협조가 필요해 한 달을 지연시켰습니다.
따라서 납품 목록에는 도메인 관리 계정, 클라우드 서버 계정, 데이터베이스 계정, 백엔드 관리자 계정, 등록 정보, 제3자 서비스(문자, 결제, 지도)의 계정과 키를 나열해야 합니다. 인계 시 항목별로 확인하고 서명합니다.
4. 백엔드와 문서: 사용할 수 있어야 납품
백엔드 관리 시스템의 납품은 계정만이 아니라 기능 목록, 필드 설명, 역할 권한 설명, 일반 조작 매뉴얼도 포함합니다.
온라인 또는 오프라인 인계 교육을 한 차례 약정하고 화면 녹화를 보관할 것을 권장합니다. 이렇게 하면 인력 이동 시 새 동료가 직접 볼 수 있습니다.
App 개발과 복잡한 백엔드 프로젝트는 추가로 인터페이스 문서와 버전 기록을 제공하도록 요구하여 이후 다른 시스템과의 연동을 용이하게 해야 합니다.
5. 검수 기준: "사용 가능"을 측정 가능한 항목으로
검수 조항은 실행 가능해야 합니다. 다음과 같이 작성할 것을 권장합니다. 기능은 요구사항 문서에 따라 항목별 검수, 주요 브라우저 및 기기 호환 목록, 페이지 로딩 시간 상한, 웹사이트 보안 테스트의 기본 항목(예: 일반적인 인젝션, 권한 우회, 민감 정보 노출 점검).
동시에 결함 수정 기간과 응답 시간, 검수 불통과 시 개선 라운드를 약정합니다.
주의: "갑 측 만족을 기준으로 한다"거나 "업계 표준에 부합한다"와 같이 검증할 수 없는 표현을 쓰지 마세요.
MIC Studio와 협업하기 적합한 경우
다음과 같은 상태라면 저희와 상담해 보시기 바랍니다. 요구사항이 이미 명확하고 실행 가능한 납품 목록이 필요한 경우, 기존 시스템에 리버스 테스트 또는 보안 점검이 필요한 경우, 또는 내부에 전담 기술 인력이 없지만 계정, 소스 코드, 문서를 모두 직접 보유하고 싶은 경우입니다.
저희는 기업 웹사이트, 미니프로그램 개발, App 개발과 스크립트 개발을 하며 보안 테스트도 수행합니다. 계약 단계에서 산출물을 항목별 표로 작성하여 첨부 파일로 서명에 포함시켜 이후 반복적인 설명을 피합니다.
세 가지 실행 가능한 제안
1. 산출물을 표 첨부 파일로 만들어 "명칭, 형식, 납품 시간, 검수 방식"을 항목별로 작성하고 서명 확인합니다.
2. 계약 전에 도메인과 클라우드 계정이 누구 명의인지 확인하고, 자신 명의가 아니면 먼저 이전한 후 개발을 논의합니다.
3. 잔금 비율을 검수와 연동하여 10%~20%는 인계 교육 완료, 계정 확인 무오류 후 지급합니다.
계약을 세밀하게 쓰는 것은 불신이 아니라 양측 모두 설명에 쓰는 시간을 줄이기 위함입니다.