외주 개발이 끝났습니다. 결과물에 만족해서 잔금을 치렀습니다. 그런데 소스코드를 달라고 하니 개발사가 말합니다. "소스코드는 드릴 수 없습니다." 실제로 일어나는 일입니다. 그리고 이건 초보 클라이언트를 노리는 대표적인 수법입니다.

핵심: 계약서에 안 적으면 안 주는 게 기본

이 글에서 가장 중요한 내용입니다.

소스코드에 대한 내용을 계약서에 명시하지 않으면, 개발사가 소스코드를 넘기지 않아도 법적으로 문제가 없을 수 있습니다.

한국 저작권법상, 별도 계약이 없으면 프로그램의 저작권은 창작자(개발사)에게 귀속됩니다. 클라이언트가 비용을 지불한 것은 "프로그램 사용권"이지, "소스코드 소유권"이 아니라는 해석이 가능합니다.

대부분의 클라이언트는 "돈을 주고 만든 것이니 당연히 내 것"이라고 생각합니다. 하지만 그 "당연히"가 계약서에 적혀있지 않으면, 개발사가 이를 악용할 수 있습니다.

이걸 악용하는 방법

유지보수 종속 — 가장 흔한 수법

소스코드를 넘기지 않으면 클라이언트는 해당 개발사 없이는 아무것도 수정할 수 없습니다. 버그 수정, 기능 추가, 서버 이전 — 모든 것을 해당 개발사에 의존해야 합니다.

"유지보수 계약을 하시면 코드를 관리해드립니다." 이 말의 이면에는 "다른 데 갈 수 없게 만들겠다"는 구조가 있습니다.

초기 개발 비용을 낮게 잡고 수주한 뒤, 유지보수 비용으로 장기간 수익을 뽑는 전략입니다. 클라이언트는 빠져나갈 수 없습니다.

실제로 벌어지는 일들:

• 버튼 텍스트 하나 바꾸는 데 수십만 원 견적
• 새로운 기능을 추가하고 싶은데 "현재 구조에서는 불가능합니다"
• 다른 개발사에 이관하고 싶어도 코드가 없어서 처음부터 다시 만들어야 함
• 서비스 개편을 하려면 개발사의 허락을 받아야 하는 상황
• 심한 경우 "그 수정은 못 합니다"라고 거절

결국 제대로 된 비즈니스를 운영할 수 없는 상태에 놓이게 됩니다. 내 서비스인데 내 맘대로 할 수 없는 것입니다.

코드 재사용 — 자체 솔루션을 돌려 파는 구조

다른 개발사보다 유난히 견적이 낮은 곳이 있습니다. "맞춤 개발"이라고 했지만, 실제로는 자기들이 만든 솔루션을 베이스로 일부 화면과 디자인만 수정해서 납품합니다.

이 경우 소스코드를 넘길 수 없습니다. 코드를 주면 자기들이 만든 솔루션 전체가 넘어가 버리니까요. 여러 클라이언트에게 같은 솔루션을 팔아야 하는 구조에서, 한 곳에 코드를 넘기면 비즈니스 모델이 무너집니다.

문제는 클라이언트가 이 사실을 모른다는 것입니다. "맞춤 개발"이라는 말을 듣고 계약했는데, 실은 솔루션 임대에 가까운 구조였던 겁니다.

두루뭉술한 계약서 — 의도적 누락

"프로그램 일체를 납품한다" 정도의 모호한 표현만 넣고, 소스코드 양도에 대한 명시적 조항은 빼둡니다. 경험이 없는 클라이언트는 이걸 모르고 넘어갑니다.

나중에 문제가 생기면 "계약서에 소스코드 양도라고 안 적혀있잖아요"로 빠집니다. 의도적입니다.

계약서에 반드시 넣어야 할 조항

외주 개발 계약 시 아래 내용이 명확히 기재되어야 합니다.

소스코드 소유권:

• "본 프로젝트로 생성된 모든 소스코드의 저작재산권은 잔금 완납 시점에 클라이언트에게 양도된다."
• 단순 "사용권"이 아닌 "저작재산권 양도"가 핵심입니다.

인수인계 범위:

• 소스코드 전체 (프론트엔드, 백엔드, DB 스키마)
• Git 저장소 접근 권한 또는 전체 이력 포함 전달
• 서버 접속 정보 (SSH, DB, 클라우드 콘솔)
• 환경 변수, API 키, 인증 정보
• 배포 절차 문서

인수인계 시점:

• 잔금 완납 후 N일 이내 인수인계 완료
• 인수인계 미완료 시 잔금 지급 보류 조건

개발사 입장에서의 현실

공정하게 이야기하면, 개발사 입장에서 소스코드 인수인계에 조건이 붙는 것은 합리적인 부분도 있습니다.

잔금 완납이 선행되어야 합니다. 소스코드를 먼저 넘긴 후 잔금을 받지 못하는 리스크가 있기 때문입니다. "코드 받았으니 나머지는 안 내도 되지"라는 클라이언트도 존재합니다.

프로덕트 메이커에서도 기본적으로 잔금 완납 후 소스코드를 전달합니다. 다만 클라이언트와의 신뢰가 충분한 경우, 클라이언트의 Git 저장소에서 직접 작업하기도 합니다. 이 경우 개발 과정이 실시간으로 공유되므로 양측 모두에게 투명합니다.

인수인계도 문서만 넘기고 끝이 아닙니다. 프로덕트 메이커에서는 모든 자료를 정리해서 공유하고 인수인계를 진행하지만, 그래도 부족한 경우 클라이언트의 담당 개발자가 사무실에 직접 방문해서 이해될 때까지 대면 인수인계를 하기도 합니다. (다만 React 같은 기술을 처음부터 가르치는 교육은 인수인계 범위에 포함되지 않습니다.)

핵심은 이 모든 조건이 사전에 합의되고 계약서에 명시되어야 한다는 것입니다.

소스코드를 받았는데 쓸 수 없는 경우

소스코드를 받았다고 끝이 아닙니다. 코드만 있으면 아무 의미 없는 경우가 많습니다.

흔한 문제:

• 빌드가 안 된다 (환경 설정 정보 누락)
• 서버에 배포하는 방법을 모른다 (배포 스크립트 없음)
• DB 접속 정보가 없다
• 코드에 주석이나 문서가 전혀 없다
• 개발자가 아닌 사람은 이해할 수 없는 구조

"소스코드 인수인계"는 ZIP 파일 하나 보내는 것이 아닙니다. 다른 개발자가 이어받아 유지보수할 수 있는 상태로 전달하는 것입니다.

인수인계 체크리스트:

• README에 프로젝트 구조, 실행 방법, 배포 방법 문서화
• 환경 변수(.env) 설명
• Git 저장소 전체 커밋 이력 포함
• 로컬 개발 환경 구축 가이드
• 운영 서버 접속 정보 및 구조도

정리

외주 개발에서 소스코드 문제는 대부분 계약서에 한 줄 적으면 예방할 수 있습니다.

• "소스코드 양도"를 계약서에 명시하지 않으면, 안 주는 게 기본입니다
• 두루뭉술한 계약서는 의도적일 수 있습니다
• 잔금 완납 → 소스코드 인수인계 순서가 일반적
• 코드만 받지 말고, 빌드·배포·운영이 가능한 상태로 받으세요

처음 외주를 맡기는 분들이 가장 많이 당하는 부분입니다. 이 글을 읽었다면, 최소한 이 실수는 피할 수 있습니다.

*외주 개발 계약이나 기술 인수인계에 대해 궁금한 점이 있다면, 프로젝트 상담을 통해 편하게 문의해 주세요.*