개발 외주 계약 전에 무엇을 확인해야 하나요?
소스코드 저작권부터 인수인계 산출물까지 10가지를 계약서와 첨부 문서에 명시해야 합니다. 외주 프로젝트의 분쟁은 대부분 기술보다 계약서에 적히지 않은 부분에서 시작됩니다. 아래 순서대로 확인하세요.
1. 소스코드 저작권은 누구에게 귀속되나요?
별도 약정이 없으면 일반적으로 실제 개발한 개발사에 귀속됩니다. 저작권법 제9조의 업무상저작물은 회사 직원이 업무로 만든 경우에 적용되고, 독립된 개발사에 맡긴 외주 개발은 여기에 해당하지 않는다는 것이 통설입니다. 대금을 모두 지급했다고 저작권이 자동으로 넘어오지 않습니다.
가장 분쟁이 많은 항목입니다. "소유권"이라는 표현보다 저작재산권 양도와 2차적저작물작성권 포함 여부를 명확히 적어야 합니다.
계약서 예시 문구:
"본 계약에 따라 개발된 소스코드, 설계 문서, 데이터베이스 스키마 등 산출물의 저작재산권(2차적저작물작성권 포함)은 대금 지급 완료 시 갑에게 양도된다."
함께 확인할 것:
- 개발사가 원래 갖고 있던 모듈·라이브러리: 양도 대상에서 빠지는 대신 갑에게 영구 사용권을 주는지
- 오픈소스 라이선스: 사용한 오픈소스 목록과 라이선스(GPL 등) 의무를 산출물로 받는지
- AI 코딩 도구 사용: 생성형 AI로 작성한 코드에 대한 검수 책임이 개발사에 있는지
2. 서버와 인프라 계정은 누구 명의인가요?
모든 인프라의 소유 계정은 발주사(갑) 명의로 만들어야 합니다. 개발사 계정으로 세팅하면 계약 종료 후 접근이 어려워질 수 있습니다.
- AWS·GCP·Azure 등 클라우드 계정과 결제 수단이 갑 명의인지
- 도메인 등록자와 DNS 관리 계정이 갑 명의인지
- GitHub·GitLab 조직, CI/CD, 앱스토어 개발자 계정이 갑 소유인지
- 외부 API 키(결제, 지도, LLM 등)가 갑 계정에서 발급됐는지
개발사에는 갑 계정 안에서 필요한 권한만 부여하고, 계약 종료 시 회수하면 됩니다.
3. 작업 범위는 어떻게 적어야 하나요?
기능 단위로 적어야 합니다. "관리자 페이지 포함 홈페이지 개발"이 아니라 화면 수, 기능 목록, 지원 기기, 연동 대상을 구체적으로 적은 작업 범위서(SOW) 를 계약서에 첨부하세요.
- 나쁜 예: "관리자 페이지 포함 홈페이지 개발"
- 좋은 예: "사용자 화면 12개, 관리자 화면 8개, 반응형(데스크톱·태블릿·모바일), 한/영 2개 언어, 이메일 + 소셜 로그인 3종"
기능 목록을 표로 만들고 각 항목의 포함·미포함을 표시해 두면 이후 추가 비용 논의가 쉬워집니다.
4. 추가 비용은 언제 발생하나요?
SOW에 없는 기능을 추가하거나, 합의한 횟수를 넘어 수정할 때 발생하도록 미리 기준을 정해 둡니다.
- 기능 추가: 별도 견적
- 기존 기능 수정: 무상 수정 횟수 명시
- 디자인 시안 변경: 무상 변경 횟수 명시
- 산정 방식: 투입 공수(M/D) 기준과 단가 명시
"SOW에 명시되지 않은 기능 추가 시 갑과 을이 협의하여 추가 견적을 산정하며, 산정 기준은 1인일 OO만 원으로 한다."
5. 납기와 지체상금은 어떻게 정하나요?
전체 납기뿐 아니라 마일스톤별 기한과 지연 시 페널티(지체상금)를 함께 정합니다.
- 마일스톤: 기획 확정 → 디자인 확정 → 개발 → 통합 테스트 → 최종 납품
- 지체상금: 민간 계약은 당사자가 정합니다. 참고로 공공 용역 계약은 국가계약법 시행규칙 제75조에 따라 지체 1일당 계약금액의 1000분의 1.25가 기준입니다.
- 갑의 의무: 갑의 자료 제공이나 피드백이 늦어진 기간만큼 납기를 연장한다는 조항을 함께 둡니다.
6. 하자 보수는 어떻게 정하나요?
기간, 하자의 정의, 대응 시간, 제외 범위 네 가지를 적습니다. 하자 보수 기간은 법으로 일률 정해져 있지 않으므로 계약에 명시해야 합니다.
- 무상 보수 기간: 단순한 시스템 3개월, 복잡한 시스템은 6개월 이상 권장
- 하자의 정의: 요구사항 명세서에 정의된 기능이 명세대로 동작하지 않는 경우
- 대응 시간: 서비스 장애와 일반 오류를 나누어 정함
- 제외 범위: 갑의 운영 환경 변경, 외부 서비스 정책 변경으로 생긴 문제
참고로 미라클스튜디오는 납품 후 90일 무상 하자 보수, 영업일 48시간 이내 대응(긴급 건 24시간)을 기본으로 계약합니다.
7. 중간 산출물은 얼마나 자주 공유받아야 하나요?
최소 주 1회 진행 보고와 2주 단위 동작 시연을 권합니다. "다 만들고 보여 드리겠습니다"는 위험 신호입니다.
- 주간 보고: 진행률, 이슈, 다음 주 계획
- 격주 데모: 실제 동작하는 화면 시연
- 저장소 접근: 갑의 GitHub·GitLab 조직에서 개발하도록 요구
개발사가 중간 산출물 공유를 꺼리거나 자체 저장소에서만 개발하겠다고 하면, 진행 상황을 확인할 수 없고 계약 종료 시 코드 이관도 어려워집니다.
8. 기술 스택은 왜 미리 합의해야 하나요?
나중에 유지보수 인력을 구할 수 있는지가 기술 스택에 달려 있기 때문입니다. 언어, 프레임워크, DB, 클라우드를 계약 전에 문서로 합의하세요.
- 프론트엔드: React·Next.js, Vue·Nuxt 등
- 백엔드: Node.js, Python·FastAPI, Java·Spring 등
- DB: PostgreSQL, MySQL 등
- 인프라: AWS, GCP, Azure, Vercel 등
- 고려 사항: 국내 개발자 수급이 원활한 스택인지, 개발사만 쓰는 자체 프레임워크는 아닌지
9. 인수 테스트 기준은 무엇으로 정하나요?
"동작하면 납품"이 아니라 합격 기준을 숫자와 목록으로 정합니다.
- 기능 테스트: 요구사항 명세의 모든 항목
- 브라우저: Chrome, Safari, Edge 최신 버전
- 모바일: iOS Safari, Android Chrome
- 성능: 주요 페이지 로딩 시간, 예상 동시 접속자 수 기준
- 보안: SQL Injection, XSS 등 OWASP Top 10 기본 항목 점검
10. 인수인계 때 무엇을 받아야 하나요?
코드만으로는 운영할 수 없습니다. 다음 산출물을 계약서에 목록으로 적어 두세요.
- 소스코드 (Git 저장소 전체 이력 포함)
- API 문서 (OpenAPI 형식 권장)
- DB ERD와 스키마 설명서
- 배포 가이드와 CI/CD 설정
- 환경별 설정 가이드 (개발·스테이징·운영)
- 관리자 매뉴얼, 장애 대응 매뉴얼
- 사용한 오픈소스 목록과 라이선스
문서 전달과 별도로 인수인계 미팅을 계약에 포함하세요. 문서만으로 전달되지 않는 운영 맥락이 있습니다.
개인정보를 다루는 프로젝트라면 무엇을 더 확인하나요?
개발사가 고객 개인정보에 접근한다면 개인정보 처리 업무 위탁 계약이 필요합니다. 개인정보보호법 제26조는 위탁 목적과 범위, 재위탁 제한, 안전조치 등을 문서로 정하고 위탁 사실을 공개하도록 하며, 수탁자가 재위탁하려면 위탁자 동의를 받도록 합니다. 개발·테스트에는 가능한 한 가명 처리하거나 가짜 데이터를 쓰도록 계약에 적어 두는 것이 안전합니다.
최종 체크리스트
- 산출물의 저작재산권 양도 조항이 있는가?
- 인프라·저장소·API 키가 모두 갑 명의인가?
- 작업 범위가 기능 단위로 정의된 SOW가 첨부되었는가?
- 추가 비용 발생 기준과 단가가 명시되었는가?
- 마일스톤별 기한과 지체상금, 갑의 피드백 의무가 있는가?
- 하자 보수 기간·정의·대응 시간이 정해졌는가?
- 중간 산출물 공유 주기와 저장소 접근이 합의되었는가?
- 기술 스택이 문서로 합의되었는가?
- 인수 테스트 합격 기준이 정의되었는가?
- 인수인계 산출물 목록과 개인정보 위탁 계약이 준비되었는가?
미라클스튜디오는 대금 정산 후 소스코드를 이관하고, 3영업일 이내에 견적을 드립니다. 계약서 검토가 필요하시면 30분 무료 상담에서 함께 확인해 드립니다. (법률 자문이 필요한 사항은 변호사 검토를 함께 받으시길 권합니다.)
