목록으로
10분 읽기

외주 개발이 끝나면 소스코드는 누구의 것일까?

웹사이트나 웹서비스 개발을 외주로 맡길 때 자주 놓치는 부분이 있습니다.

  • #소스코드 소유권
  • #외주 개발 계약
  • #소스코드 제공
  • #개발 저작권
  • #웹개발 인수인계

웹사이트나 웹서비스 개발을 외주로 맡길 때 자주 놓치는 부분이 있습니다.

바로 개발이 끝난 뒤 소스코드를 받을 수 있는지, 소스코드의 권리는 누구에게 있는지입니다.

많은 의뢰사는 개발비를 모두 지급하면 결과물과 소스코드도 자동으로 회사 소유가 된다고 생각합니다.

하지만 실제로는 계약 내용과 개발 방식에 따라 다음이 서로 다를 수 있습니다.

  • 완성된 서비스를 사용할 권리
  • 소스코드를 전달받을 권리
  • 소스코드를 수정할 권리
  • 다른 업체에 유지보수를 맡길 권리
  • 결과물을 복제하거나 재판매할 권리
  • 저작재산권의 귀속
  • 기존 모듈과 외부 라이브러리의 권리

따라서 외주 개발 계약 전에는 다음 질문을 명확히 해야 합니다.

개발 완료 후 어떤 소스와 자료를 어떤 형태로 받으며, 해당 결과물을 어디까지 사용할 수 있는가?

이 글은 외주 개발 계약을 준비할 때 참고할 수 있는 실무적인 내용입니다. 실제 저작권과 계약 효력은 구체적인 계약 내용에 따라 달라질 수 있으므로 중요한 프로젝트는 법률 전문가의 검토를 받는 것이 안전합니다.

소스코드를 받는 것과 소유하는 것은 다릅니다

먼저 다음 세 가지를 구분해야 합니다.

1. 서비스 사용권

개발된 웹사이트나 웹서비스를 운영하고 사용할 수 있는 권리입니다.

예를 들어 의뢰사가 제작된 서비스를 다음 용도로 사용하는 것입니다.

  • 회사 홈페이지 운영
  • 고객 대상 웹서비스 제공
  • 사내 업무 시스템 사용
  • 교육 플랫폼 운영
  • 상품과 서비스 판매

서비스를 사용할 수 있다고 해서 반드시 소스코드를 받을 수 있는 것은 아닙니다.

2. 소스코드 제공

개발에 사용된 코드를 파일이나 Git 저장소 형태로 전달받는 것입니다.

소스코드를 받으면 다음 작업이 가능할 수 있습니다.

  • 다른 개발자에게 유지보수 의뢰
  • 내부 개발자가 기능 수정
  • 서버 이전
  • 보안 점검
  • 백업
  • 기능 추가
  • 기술 구조 확인

하지만 소스코드를 전달받았다고 해서 모든 저작권이 자동으로 이전되는 것은 아닐 수 있습니다.

3. 저작권 또는 사용·수정 권한

소스코드를 복제하고 수정하며 재사용할 수 있는 권리입니다.

계약에 따라 다음처럼 정해질 수 있습니다.

  • 의뢰사가 프로젝트 결과물을 자유롭게 사용·수정
  • 개발사가 저작권을 보유하고 의뢰사에 사용권만 제공
  • 프로젝트 전용 코드는 의뢰사에 귀속
  • 기존 공통 모듈은 개발사에 귀속
  • 제3자 라이브러리는 해당 라이선스를 따름

이 내용을 계약서에 명시하지 않으면 서로 다른 기대를 가질 수 있습니다.

개발 결과물은 하나의 코드로만 구성되지 않습니다

외주 개발 결과물에는 여러 종류의 자산이 섞여 있을 수 있습니다.

1. 프로젝트 전용 코드

해당 프로젝트를 위해 새로 개발한 기능입니다.

예를 들면 다음과 같습니다.

  • 회사만의 업무 처리 로직
  • 고객별 대시보드
  • 맞춤형 관리자 페이지
  • 신청·승인 흐름
  • 서비스 전용 데이터 구조
  • 고유한 계산 로직
  • 특정 사용자 경험

프로젝트 전용 코드의 권리는 계약서에서 별도로 정할 수 있습니다.

2. 개발사가 기존에 보유한 공통 코드

개발 업체가 이전부터 사용하던 공통 모듈이 포함될 수 있습니다.

  • 로그인 모듈
  • 이메일 발송 모듈
  • 파일 업로드 모듈
  • 관리자 기본 구조
  • 공통 UI
  • 배포 스크립트
  • 로그 처리
  • 개발 도구

개발사는 여러 프로젝트에서 같은 공통 코드를 사용할 수 있습니다.

이 경우 프로젝트 전체 저작권을 의뢰사에 이전하는 계약과 충돌할 수 있으므로 다음처럼 구분할 수 있습니다.

text
이번 프로젝트를 위해 새로 개발한 전용 결과물은 의뢰사에 귀속한다.

개발사가 계약 전부터 보유한 공통 모듈과 기술은 개발사에 귀속한다.

의뢰사는 최종 결과물을 운영·수정하기 위해 필요한 범위에서 해당 공통 모듈을 사용할 수 있다.

실제 문구는 계약 상황에 맞게 검토해야 합니다.

3. 오픈소스 라이브러리

대부분의 현대적인 웹서비스는 외부 오픈소스를 사용합니다.

예를 들면 다음과 같습니다.

  • React
  • Next.js
  • Node.js
  • UI 라이브러리
  • 차트 라이브러리
  • 이미지 처리 라이브러리
  • 데이터베이스 도구

오픈소스는 프로젝트 비용을 지급했다고 해서 의뢰사나 개발사의 독점 자산이 되지 않습니다.

각 라이브러리의 라이선스 조건에 따라 사용할 수 있습니다.

4. 유료 라이브러리와 플러그인

다음과 같은 유료 자산도 포함될 수 있습니다.

  • 워드프레스 테마
  • 워드프레스 플러그인
  • 유료 UI 컴포넌트
  • 차트 도구
  • 폰트
  • 스톡 이미지
  • 영상
  • 아이콘
  • 지도 서비스
  • 문서 변환 도구

라이선스를 개발 업체가 구매했는지, 의뢰사가 구매했는지에 따라 계약 종료 후 사용 가능 여부가 달라질 수 있습니다.

5. 외부 API와 클라우드 서비스

소스코드가 있어도 다음 계정이 없으면 서비스가 제대로 작동하지 않을 수 있습니다.

  • 서버
  • 데이터베이스
  • 파일 저장소
  • 결제
  • 이메일
  • 알림톡
  • 소셜 로그인
  • AI API
  • 지도
  • 분석 도구

따라서 소스코드 인계와 계정 인계는 함께 확인해야 합니다.

개발비를 지급하면 소스코드를 자동으로 받을 수 있을까?

반드시 그렇다고 단정할 수는 없습니다.

계약 방식에 따라 다를 수 있습니다.

구축형 외주

특정 의뢰사를 위해 맞춤형 시스템을 만드는 방식입니다.

이 경우 소스코드 제공과 수정 권한을 계약에 포함하는 경우가 많습니다.

솔루션 사용형

개발 업체가 보유한 기존 솔루션을 커스터마이징해서 제공하는 방식입니다.

예를 들면 다음과 같습니다.

  • 홈페이지 임대형 솔루션
  • 예약 솔루션
  • 회원관리 솔루션
  • 쇼핑몰 플랫폼
  • 교육 플랫폼
  • SaaS

이 경우 의뢰사는 서비스를 사용할 권리만 받고 전체 소스코드는 제공받지 못할 수 있습니다.

템플릿·웹빌더형

아임웹, Wix, Shopify 등의 플랫폼 위에서 제작한 경우 플랫폼 전체 소스코드를 받을 수 없습니다.

콘텐츠와 일부 디자인 자산은 받을 수 있어도 서비스 자체는 해당 플랫폼에 의존합니다.

따라서 홈페이지 제작이라는 같은 표현이라도 어떤 방식으로 제작되는지 확인해야 합니다.

소스코드를 받지 못하면 어떤 문제가 생길까?

소스코드 미제공이 무조건 잘못된 것은 아닙니다.

임대형 솔루션이나 SaaS를 선택했다면 소스를 받지 않는 조건이 합리적일 수 있습니다.

다만 맞춤 개발 서비스인데도 소스와 계정을 확보하지 못하면 다음 문제가 생길 수 있습니다.

  • 기존 업체가 아니면 기능을 수정하기 어려움
  • 업체와 연락이 끊기면 유지보수 불가
  • 다른 서버로 이전하기 어려움
  • 보안 점검이 어려움
  • 내부 개발자를 채용해도 수정할 수 없음
  • 업체가 폐업하면 운영 위험 발생
  • 개발 비용을 다시 들여 재개발해야 할 수 있음

장기 운영할 서비스라면 소스 제공 조건을 계약 전에 확인하는 것이 좋습니다.

어떤 소스코드를 받아야 할까?

프로젝트에 따라 다음 항목이 있을 수 있습니다.

프론트엔드

사용자에게 보이는 웹 화면 코드입니다.

백엔드

회원, 결제, 데이터 저장, API 등을 처리하는 서버 코드입니다.

관리자 페이지

운영자가 사용하는 관리자 화면과 관련 코드입니다.

배치·자동화 코드

정해진 시간에 실행되는 작업입니다.

  • 이메일 발송
  • 데이터 수집
  • 통계 집계
  • 결제 갱신
  • 만료 처리

인프라 설정

서비스를 배포하고 운영하기 위한 설정입니다.

  • Docker
  • CI/CD
  • 서버 설정
  • 클라우드 설정
  • 배포 스크립트
  • 환경 구성

데이터베이스 구조

  • 테이블 생성 문서
  • 마이그레이션 파일
  • 초기 데이터
  • 백업 파일

소스코드 폴더 하나만 받았다고 전체 인계가 완료된 것은 아닐 수 있습니다.

Git 저장소로 받는 것이 좋은 이유

가능하면 GitHub, GitLab, Bitbucket 같은 저장소의 권한을 받는 것이 좋습니다.

Git 저장소에는 다음 정보가 포함될 수 있습니다.

  • 최신 코드
  • 변경 이력
  • 브랜치
  • 작성자
  • 배포 기록
  • 이슈
  • 버전 태그

압축 파일만 받으면 다음을 확인하기 어렵습니다.

  • 실제 운영 버전과 같은가?
  • 어떤 파일이 변경됐는가?
  • 이전 버전으로 되돌릴 수 있는가?
  • 누가 어떤 작업을 했는가?

의뢰사 소유의 Git 조직이나 저장소를 만들고 개발 업체를 초대하는 방식도 검토할 수 있습니다.

소스코드는 실행 가능한 상태여야 합니다

코드 파일을 받았지만 실행 방법을 알 수 없는 경우도 있습니다.

다음 자료가 함께 필요할 수 있습니다.

  • 설치 방법
  • 실행 명령어
  • 필요한 소프트웨어 버전
  • 환경변수 목록
  • 데이터베이스 설정
  • 외부 API 설정
  • 빌드 방법
  • 배포 방법
  • 테스트 계정
  • 관리자 계정

환경변수에는 중요한 비밀값이 포함되므로 안전한 방식으로 전달해야 합니다.

환경변수와 API 키는 어떻게 받아야 할까?

소스코드 저장소에 API 키를 그대로 넣는 것은 피해야 합니다.

다음 정보는 별도로 관리할 수 있습니다.

  • 데이터베이스 비밀번호
  • 결제 API 키
  • 이메일 API 키
  • AI API 키
  • 소셜 로그인 비밀키
  • 스토리지 키
  • 관리자 암호

인계 시에는 다음을 확인하는 것이 좋습니다.

  • 의뢰사 명의 계정인가?
  • 기존 키를 계속 사용할 것인가?
  • 새 키로 교체할 것인가?
  • 기존 개발자의 접근 권한을 제거했는가?
  • 키가 코드나 문서에 노출되어 있지 않은가?

디자인 원본도 소스코드에 포함될까?

디자인 원본은 개발 소스와 별개의 산출물일 수 있습니다.

  • Figma
  • Adobe XD
  • Photoshop
  • Illustrator
  • 로고 파일
  • 아이콘
  • 이미지 원본
  • 디자인 시스템

디자인 비용이 포함됐다고 해서 편집 가능한 원본이 자동으로 제공된다고 단정하기는 어렵습니다.

계약서에서 제공 여부와 형식을 확인하는 것이 좋습니다.

데이터베이스도 받아야 할까?

운영 중인 서비스라면 데이터는 매우 중요한 자산입니다.

다음 데이터가 있을 수 있습니다.

  • 회원
  • 문의
  • 주문
  • 결제 내역
  • 게시물
  • 상품
  • 파일
  • 통계
  • 관리자
  • 로그

소스코드를 받아도 데이터베이스가 없으면 실제 서비스를 그대로 복구하기 어려울 수 있습니다.

다음 형태로 확보할 수 있습니다.

  • 데이터베이스 접속 권한
  • 백업 파일
  • 데이터 내보내기
  • 마이그레이션 파일
  • 데이터 구조 문서

개인정보가 포함되어 있다면 전달 과정의 보안도 고려해야 합니다.

계약서에 적으면 좋은 내용

1. 제공할 산출물

text
- 프론트엔드 소스코드
- 백엔드 소스코드
- 관리자 페이지 소스코드
- 데이터베이스 구조와 마이그레이션
- 배포 설정
- 디자인 원본
- 운영 문서

2. 제공 시점

text
잔금 지급과 최종 검수 완료 후 5영업일 이내 제공

또는 단계별로 저장소 권한을 공유할 수 있습니다.

3. 사용·수정 권한

text
의뢰사는 납품 결과물을 운영, 수정, 유지보수하기 위해 사용할 수 있다.

4. 기존 공통 자산

text
개발사가 계약 체결 전부터 보유한 공통 모듈과 기술은 개발사에 귀속한다.

5. 제3자 라이선스

text
오픈소스와 외부 라이브러리는 해당 라이선스 조건을 따른다.

6. 재판매와 복제

서비스를 다른 고객에게 재판매하거나 동일한 시스템을 복제할 계획이 있다면 별도로 협의해야 합니다.

일반적인 사내 사용권과 재판매 권리는 다를 수 있습니다.

소스코드 인계 체크리스트

text
[ ] 프론트엔드 소스
[ ] 백엔드 소스
[ ] 관리자 소스
[ ] 최신 운영 버전과 일치
[ ] Git 저장소 권한
[ ] 설치 방법
[ ] 실행 방법
[ ] 빌드 방법
[ ] 배포 방법
[ ] 환경변수 목록
[ ] 데이터베이스 구조
[ ] 데이터베이스 백업
[ ] 외부 API 목록
[ ] 파일 저장소
[ ] 테스트 계정
[ ] 관리자 계정
[ ] 디자인 원본
[ ] 오픈소스·유료 라이선스 목록
[ ] 운영 문서

다른 개발자가 실제로 이어서 개발할 수 있는지 확인하는 방법

소스 인계 후 새 개발자가 다음 작업을 할 수 있어야 합니다.

  1. 저장소를 내려받는다.
  2. 필요한 라이브러리를 설치한다.
  3. 개발 환경을 실행한다.
  4. 데이터베이스를 연결한다.
  5. 주요 기능을 테스트한다.
  6. 빌드한다.
  7. 테스트 서버에 배포한다.

이 과정이 가능해야 실질적인 인계라고 볼 수 있습니다.

소스 제공이 필요하지 않을 수 있는 경우

다음과 같은 경우에는 전체 소스코드 제공이 핵심 조건이 아닐 수 있습니다.

  • 단기간 사용하는 이벤트 페이지
  • 웹빌더 기반 홈페이지
  • 기존 SaaS 사용
  • 임대형 솔루션
  • 운영과 유지보수를 계속 같은 업체에 맡김
  • 소스보다 빠른 출시와 낮은 비용이 중요함

다만 서비스 종료나 업체 변경 시 콘텐츠와 데이터를 어떻게 받을 수 있는지는 확인하는 것이 좋습니다.

계약 전에 물어볼 질문

  • 개발 완료 후 전체 소스코드를 받을 수 있나요?
  • 프론트·백엔드·관리자 코드가 모두 포함되나요?
  • Git 저장소 권한을 받을 수 있나요?
  • 운영 중인 코드와 같은 버전인가요?
  • 환경변수와 실행 문서를 받을 수 있나요?
  • 데이터베이스 백업도 제공되나요?
  • 디자인 원본은 포함되나요?
  • 기존 공통 모듈의 권리는 어떻게 되나요?
  • 유료 플러그인과 외부 라이선스는 누구 명의인가요?
  • 다른 개발 업체가 이어서 유지보수할 수 있나요?
  • 서버와 외부 API 계정은 누구 명의로 생성하나요?
  • 계약 종료 후 개발 업체의 접근 권한은 제거되나요?

마무리

외주 개발이 끝났다고 해서 소스코드와 모든 권리가 자동으로 의뢰사에 이전된다고 단정할 수는 없습니다.

계약 전에 다음을 구분해야 합니다.

  • 서비스를 사용할 권리
  • 소스코드를 받을 권리
  • 소스를 수정할 권리
  • 결과물을 복제·재판매할 권리
  • 기존 공통 모듈과 외부 라이브러리의 권리

장기적으로 운영하고 확장할 서비스라면 소스코드뿐 아니라 데이터베이스, 서버 계정, API 계정과 실행 문서까지 함께 확보하는 것이 좋습니다.

필요한 답을 찾고, 끝까지 완성합니다.

기술을 알지 못해도, 기획서가 없어도 괜찮습니다.

프로젝트 문의하기