실제로 있었던 일입니다.
한 식품 D2C 스타트업 대표님이 1년 반 동안 운영하던 쇼핑몰의 개발사와 연락이 끊겼습니다. 서버는 개발사 명의로 계약돼 있었고, 소스코드는 개발사 깃허브에만 있었습니다. 대표님은 자신이 비용을 낸 서비스에 접근할 수가 없었습니다.
이게 극단적인 사례처럼 보일 수 있지만, 구조적으로는 매우 흔한 일입니다.
왜 이런 일이 생기나
저작권법에 따르면, 코드를 작성한 사람(또는 법인)이 저작권을 가집니다. 돈을 낸 사람이 자동으로 소유권을 갖는 게 아닙니다.
계약서에 명시적인 소유권 이전 조항이 없으면, 개발사가 "우리가 만든 코드이므로 우리 것"이라고 주장할 수 있습니다. 실제로 이 논리로 수정 요청을 거절하거나 추가 비용을 요구하는 경우가 빈번합니다.
소유권 문제가 생기는 3가지 유형
유형 1: 계약서에 소유권 조항 자체가 없는 경우
가장 흔한 경우입니다. 계약서에 금액, 납기, 기능만 적혀 있고 소유권 조항이 없습니다. 프로젝트가 잘 끝나면 문제가 없지만, 개발사와 관계가 나빠지면 코드를 무기로 쓸 수 있습니다.
유형 2: 서버와 도메인이 개발사 명의인 경우
개발사가 편의상 자신들의 계정으로 서버와 도메인을 구매하고 관리합니다. 계약 해지나 관계 악화 시 서버 접근을 차단하거나 도메인을 인질로 잡을 수 있습니다.
유형 3: 깃(Git) 저장소가 개발사 것인 경우
소스코드가 개발사의 깃허브나 깃랩 조직 계정에 있으면, 의뢰인은 코드에 직접 접근할 수 없습니다. 관계가 끊기면 코드가 사라지는 것과 같습니다.
계약 전에 확인할 것들
- 소유권 이전 조항 확인 — "잔금 지급 완료와 동시에 소스코드 등 모든 결과물의 저작권은 의뢰인에게 귀속된다"는 문장이 있어야 합니다.
- 서버·도메인 명의 확인 — 의뢰인 명의 또는 의뢰인이 접근 가능한 계정으로 계약하도록 요청하세요. AWS, 가비아, 카페24 모두 본인 계정으로 가입 후 접근 권한만 공유 가능합니다.
- 깃 저장소 접근 확인 — 의뢰인이 읽기 권한을 가지거나, 납품 시 저장소 전체를 의뢰인 계정으로 이관한다는 조항이 있어야 합니다.
- 개발 과정에서 주간 백업 요청 — 개발 중에도 중간 소스코드 백업을 받는 방식을 사전에 협의하세요.
- 납품 체크리스트 요청 — 소스코드, 서버 접근 정보, 도메인 이전, 외부 API 키 목록을 납품 체크리스트로 받으세요.
이미 소유권 문제가 생겼다면
계약서가 없거나 소유권 조항이 없는 상태에서 개발사와 분쟁이 생겼다면 선택지가 제한적입니다.
- 협상 시도 — 이미 납부한 금액을 근거로 합의를 시도합니다. 많은 경우 법적 분쟁 없이 해결됩니다.
- 한국저작권위원회 조정 신청 — 소액 분쟁 시 저작권위원회 조정제도를 활용할 수 있습니다. 비용이 적고 전문적입니다.
- 처음부터 재개발 — 금액이 크지 않은 경우, 분쟁 비용보다 재개발 비용이 저렴할 수 있습니다. 이번엔 계약서 제대로 쓰고 시작하세요.