개발 외주

지금 개발사와 헤어져도 서비스가 돌까요 | 계약 전 확인할 6가지

계약서에 소스코드 양도가 적혀 있어도 계정 소유자가 개발사 이름이면 실제로는 못 옮겨요. 저작권 분쟁은 외주 리스크 4대 유형 중 하나고, 대한상사중재원 IT 분쟁 비중은 약 16%예요. 계약 전에 실물로 확인할 6가지를 직접 운영해본 개발사 기준으로 정리했어요.

크리에이티브소프트
크리에이티브소프트
2026년 8월 7일 ·

핵심 요약 — 계약서에 “소스코드와 지식재산권 일체를 양도한다”고 적어도 이관이 안 되는 경우가 많아요. 권리는 넘어왔는데 서버 계정 소유자, 배포 권한, 외부 서비스 계약 주체가 개발사 이름으로 남아 있어서예요. 문서가 아니라 실물로 확인해야 하는 항목이 따로 있어요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.

“소스코드 다 주신다고 계약서에 넣었으니까 괜찮은 거죠?”

계약 직전에 자주 나오는 질문이에요. 그런데 1년 뒤에 다른 곳으로 옮기려다 막히는 회사를 여러 번 봤어요. 코드는 받았는데 서버에 올릴 방법을 아무도 모르거나, 도메인 관리 계정이 개발사 담당자 개인 메일로 돼 있는 식이에요.

개발외주계약서에 문장을 넣는 것과, 실제로 넘겨받을 물건이 있는 건 다른 얘기예요.


1. 계약서에 다 적었는데 왜 못 넘겨받을까요

권리와 접근 권한은 다른 것이라서예요.

서울 사무실에서 계약서와 서버 관리 화면을 나란히 놓고 확인하는 담당자

저작권 조항은 “이 코드는 누구 것인가”를 정해요. 이관은 “이 서비스를 누가 켜고 끌 수 있는가”의 문제예요. 앞의 것이 정리돼도 뒤의 것은 그대로 남을 수 있어요.

실제로 막히는 지점은 대개 이런 모양이에요.

  • 소스는 받았는데 어떤 순서로 빌드하는지 아무도 모름
  • 서버는 살아 있는데 접속 계정이 개발사 소유
  • 도메인 갱신 알림이 개발사 담당자 메일로 감
  • 결제·지도 같은 외부 서비스가 개발사 이름으로 계약돼 있음
  • 코드는 있는데 왜 그렇게 짰는지 적힌 문서가 없음

외주 리스크를 크게 나눌 때 저작권·소스코드 분쟁이 4대 유형 중 하나로 꼽혀요. 대한상사중재원에서 다루는 분쟁 중 IT 관련 비중이 약 16%라는 자료도 있고요. 다만 실제 상담에서 더 흔한 건 소송까지 가는 다툼이 아니라, 사이가 나쁘지 않은데도 물리적으로 못 옮기는 상황이에요.

용어 정리 — 이관(Handover) 개발이 끝난 서비스를 발주자나 다른 회사가 이어서 운영할 수 있게 넘기는 일이에요. 코드 전달만이 아니라 계정, 문서, 배포 절차까지 포함해요. 실무에선 “인수인계”라고 부르는데, 계약서에는 “산출물 인도” 정도로만 적혀 있는 경우가 많아요.

2. 소스코드는 어떤 형태로 받아야 할까요

압축 파일 하나만 받으면 절반만 받은 거예요.

개발자가 코드 저장소 화면을 열어 이력을 확인하는 모습

받는 방법은 두 갈래예요.

압축 파일(zip)로 받기. 특정 시점의 코드를 통째로 받아요. 보관은 되는데 그동안 무엇을 왜 고쳤는지는 안 남아요.

우리 저장소로 옮겨받기. 깃허브나 깃랩 같은 곳에 우리 회사 계정을 만들고, 개발사가 그 저장소로 코드를 올리는 방식이에요. 수정 이력이 같이 넘어와서 나중에 다른 개발자가 붙었을 때 파악이 훨씬 빨라요.

가능하면 둘 다 받아두는 편이 안전해요. 저장소는 살아 있는 원본이고, 압축본은 계정 문제가 생겼을 때의 보험이에요.

여기서 하나 더요. 코드를 받았으면 그 코드로 한 번 돌려봐야 받은 게 맞아요. 빌드에 필요한 설정값이나 라이브러리 목록이 빠져 있으면 파일은 있는데 실행이 안 돼요. 계약 마무리 단계에서 우리 쪽 사람이 개발사 도움 없이 한 번 올려보는 절차를 넣어두세요.

운영사 Tip 저희는 자체 서비스를 옮길 때 “새로 온 사람이 문서만 보고 반나절 안에 배포까지 가능한가”를 기준으로 삼아요. 이걸 못 넘기면 문서가 부족한 거지 사람이 부족한 게 아니더라고요. 이관 검증도 같은 방식으로 해보시면 부족한 부분이 바로 드러나요.

3. 계정은 누구 이름으로 돼 있어야 할까요

전부 발주자 이름이어야 해요. 예외를 두면 그 지점에서 막혀요.

클라우드 관리 화면에서 계정 소유자 정보를 확인하는 실무자

이관에서 실제로 가장 자주 걸리는 부분이에요. 개발 편의를 위해 개발사 계정으로 만들어두고 그대로 두는 경우가 많거든요.

계정 종류확인할 것흔한 문제
서버·클라우드최상위 소유자 계정이 우리 것인가개발사 계정 아래 하위 계정만 받음
도메인등록자·관리자 연락처가 우리 것인가갱신 알림이 개발사로 가서 만료됨
코드 저장소조직 소유자가 우리 것인가개인 계정에 남아 있음
데이터베이스관리자 권한 계정을 받았는가읽기 권한만 받음
앱 마켓개발자 계정이 우리 것인가개발사 계정으로 등록돼 이전 필요
인증서·결제명의와 결제수단이 우리 것인가개발사 카드로 자동결제 중

계정을 넘길 때는 아이디와 비밀번호만 받는 걸로 끝내지 마세요. 소유자 이메일을 우리 회사 주소로 바꾸고, 결제수단도 우리 것으로 교체해야 실제로 우리 자산이 돼요. 비밀번호만 받으면 나중에 개발사 쪽에서 복구 절차로 되찾을 수 있는 상태가 남아요.

4. 우리 쪽에서 혼자 배포할 수 있나요

이게 이관이 됐는지 아닌지를 가르는 실질 기준이에요.

개발 담당자가 배포 절차 문서를 보며 서버에 반영하는 장면

코드를 고쳐서 실제 서비스에 반영하는 과정은 회사마다 달라요. 이 절차가 개발사 머릿속에만 있으면 코드를 다 받아도 못 움직여요.

최소한 이 세 가지는 문서로 받아두세요.

  1. 환경 구성 방법 — 새 컴퓨터에서 개발 환경을 세팅하는 순서
  2. 배포 절차 — 고친 코드를 실제 서버에 올리는 순서와 되돌리는 방법
  3. 설정값 목록 — 주소, 열쇠값, 연결 정보가 각각 어디에 들어 있는지

받은 뒤에는 문서대로 한 번 해보세요. 읽어서 이해되는 것과 따라 해서 되는 건 다르고, 대개 두세 군데가 빠져 있어요. 그 자리에서 채워달라고 하는 게 계약 끝나고 연락하는 것보다 훨씬 쉬워요.

5. 외부 서비스 계약은 누구 이름으로 돼 있나요

여기가 놓치기 제일 쉬워요.

결제·지도 같은 외부 서비스 관리 화면을 점검하는 담당자

요즘 서비스는 결제, 지도, 문자·알림톡, 본인확인 같은 기능을 외부에서 가져다 붙여요. 이 계약들이 개발사 이름으로 돼 있으면 이관할 때 하나씩 새로 맺어야 해요. 심사가 필요한 결제 쪽은 몇 주가 걸리기도 하고, 그동안 서비스가 멈추거나 요금이 두 곳에서 나가요.

착수 전에 이렇게 정해두면 나중이 편해요.

  • 외부 서비스는 처음부터 발주자 명의로 가입하고, 개발사에게는 작업용 권한만 주기
  • 명의를 나중에 옮길 항목이 있다면 계약서 산출물 목록에 그 이름들을 적어두기
  • 각 서비스의 월 사용료와 결제일을 목록으로 받아두기

세 번째는 홈페이지운영비용을 다시 계산할 때도 그대로 쓰여요. 이관 뒤에는 그동안 개발사가 대신 내던 항목이 우리 카드로 옮겨오니까, 총액보다 항목 개수를 먼저 파악해두는 게 도움이 돼요.

흔한 실수 “일단 개발사 계정으로 시작하고 나중에 옮기죠.” 이 말이 나오면 대부분 안 옮겨져요. 옮기는 작업 자체가 공수라서 계약서에 없으면 아무도 안 해요. 옮길 계획이면 언제, 누가, 어떤 항목을 옮기는지 착수 시점에 적어두세요.

6. 운영까지 보면 무엇이 달라지나요

만들 때의 편의와 넘길 때의 편의는 자주 반대예요.

운영 이관 항목을 표로 정리해 함께 검토하는 회의 장면

개발 속도만 보면 개발사 계정으로 다 묶어두는 게 빨라요. 계정 만들고 권한 나누는 시간이 안 드니까요. 그런데 그렇게 만든 서비스는 2년쯤 뒤에 손이 많이 가요.

저희는 자체 SaaS 4종을 직접 굴리면서 이 차이를 자주 봤어요. 만드는 단계에서 아낀 며칠이 옮기는 단계에서 몇 주로 돌아오더라고요. 그래서 요즘은 프로젝트를 시작할 때 “이 서비스를 우리가 아닌 다른 팀이 이어받는다면”을 한 번 가정하고 계정과 문서 구조를 잡아요.

납품으로 끝나는 코드와 운영까지 버티는 코드는 다르다고 생각해요. 이관 구조는 그 차이가 가장 눈에 띄게 드러나는 지점이에요.

7. 계약 전 확인할 6가지를 한 장으로 정리하면

#확인 항목확인 방법
1산출물 목록에 소스코드·문서·계정이 각각 적혀 있는가계약서 산출물 조항 확인
2코드를 저장소와 압축본 두 형태로 받는가인도 방식 명시
3모든 계정 소유자와 결제수단이 발주자 명의인가계정 목록표 받기
4배포 절차 문서만 보고 우리가 올릴 수 있는가인수 전 1회 실행
5외부 서비스가 발주자 명의로 계약돼 있는가서비스별 명의·요금 목록
6무상 하자보수 기간과 그 이후 지원 범위가 적혀 있는가유지보수 조항 확인

여섯 항목 모두 계약 전에 물어보는 게 요령이에요. 착수 뒤에 요청하면 추가 공수로 잡히지만, 견적 단계에서 말하면 대개 처음부터 그렇게 구성해줘요. 비용 차이도 거의 없고요.

판단에 쓰이는 기준값은 출처 성격이 달라서 나눠 적어둘게요.

항목기준출처 구분
프로그램 임치 제도저작권법 제101조의7에 근거, 한국저작권위원회가 수치인공식 법령
IT 관련 분쟁 비중대한상사중재원 취급 분쟁 중 약 16%공개 자료
무상 하자보수 기간통상 1~3개월공개 시장 자료·실무 관행
연 유지보수 비용개발비의 10~20% 수준실무 추정치
이관 문서·계정 정리착수 시점에 요청하면 대개 별도 비용이 붙지 않아요자사 실무 기준

위 표에서 공식 법령·공개 자료자사 실무 기준은 성격이 달라요. 마지막 줄은 저희가 프로젝트를 진행하며 겪은 기준이지 업계 통계가 아니에요. 프로젝트 규모와 계약 형태에 따라 달라질 수 있어요.

8. 자주 묻는 질문

개발 외주 계약서 핵심 조항은 무엇인가요?

개발 범위와 산출물, 검수·인수 기준, 지연 시 처리, 저작권·소스코드 귀속, 유지보수·하자보수, 대금 지급 시점이에요. 이관 관점에서는 산출물 목록이 특히 중요해요. 권리 조항만 있고 받을 물건이 특정되지 않으면 다툼이 생겨요.

소스코드 임치는 꼭 해야 하나요?

필수는 아니에요. 저작권법 제101조의7에 프로그램 임치 제도가 있어서, 소스코드와 기술정보를 한국저작권위원회 같은 제3의 기관에 맡겨두고 정해둔 사유가 생기면 받아올 수 있어요. 개발사가 소스를 못 주겠다고 할 때나 규모가 큰 도입 사업에서 주로 써요. 소스코드를 그대로 받는 계약이라면 임치까지 갈 일은 드물어요.

이관 작업에도 비용이 드나요?

문서 정리와 계정 이전에는 공수가 들어가요. 그래서 착수 전에 견적에 포함시키는 게 좋아요. 나중에 요청하면 별도 항목으로 잡히는데, 그때는 협상력이 우리 쪽에 거의 없어요.

9. 마무리

이관은 프로젝트가 끝날 때 하는 일처럼 보이지만, 실제로는 시작할 때 결정돼요. 계정을 누구 이름으로 만드는지, 문서를 남기는지가 착수 첫 주에 갈리거든요.

방향이 아직 명확하지 않아도 괜찮아요. 지금 진행 중인 프로젝트가 나중에 옮길 수 있는 구조인지 궁금하시면 계정과 산출물 목록부터 같이 훑어볼게요 →

저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 만드는 쪽과 이어받는 쪽을 둘 다 해봐서, 넘길 때 무엇이 막히는지는 대체로 알고 있어요.

함께 보면 좋은 글