앱 외주개발 인수인계: 소스코드·도메인·클라우드 계정 체크리스트

앱 외주개발이 끝날 때 ‘소스코드 파일을 받았다’는 사실만으로 운영 인수인계가 끝난 것은 아닙니다. 서비스가 계속 열리려면 코드 저장소, 도메인 등록정보와 DNS, 배포·클라우드 계정, 오류 알림과 비용 결제 수단의 현재 관리자 권한을 따로 확인해야 합니다. 이 글은 개발사 교체나 계약 종료 전에 창업팀이 확인할 운영권한 체크리스트를 정리합니다.

공식 원문 확인일: 2026년 9월 15일 · 작성: 유인어스(UINUS)

먼저 답: ‘파일 전달’과 ‘운영권한 이전’을 분리해 확인합니다

인수인계는 두 묶음으로 나누면 빠뜨릴 항목이 줄어듭니다. 첫째는 소스코드·설계 문서·배포 설정처럼 무엇을 받는가입니다. 둘째는 도메인·클라우드·코드 저장소·스토어·분석도구처럼 누가 로그인하고 변경할 수 있는가입니다. 전자는 파일 목록으로, 후자는 각 서비스의 소유자·관리자·복구 이메일·결제 담당자를 표로 확인하세요.

특히 도메인은 홈페이지를 켜는 주소이면서 갱신·이전의 기준이 되므로 별도로 확인할 필요가 있습니다. 한국인터넷진흥원(KRNIC)은 제작업체 등을 통해 도메인을 등록할 때 실제 의뢰자 또는 사업자 명의로 등록됐는지 확인하라고 안내합니다. 제작업체 명의라면 계약 종료나 분쟁 때 권리 확보·이전·갱신에 어려움이 생길 수 있다고도 설명합니다. KRNIC 공식 안내에서 등록인, 책임자 전자우편, 사용종료일을 확인하는 방법을 볼 수 있습니다.

인수인계 표에는 ‘계정 이름’보다 역할과 복구 경로를 적습니다

인수 표를 만들 때 비밀번호 자체를 문서에 적지 마세요. 대신 각 항목에 서비스명, 역할, 현재 소유자, 새 관리자, 복구 이메일, 2단계 인증 담당자, 결제 담당자, 이전 완료 확인일을 둡니다. 이 표는 실제 자격증명을 보관하는 장소가 아니라, 누가 어떤 권한을 넘겨받았는지 확인하는 목록입니다.

여기서 ‘새 관리자 로그인’은 서비스 계정을 새로 만들라는 뜻이 아닙니다. 기존 서비스의 권한 구조에 맞춰 팀 내부의 책임자가 실제로 접근·복구·알림 수신을 할 수 있는지 확인하는 절차입니다. 권한을 바꾸기 전에는 기존 운영에 영향이 없는지, 고객 데이터 접근 범위가 넓어지지 않는지부터 검토하세요.

소스코드를 받기 전에 계약서의 권리·이용 범위를 먼저 읽습니다

소스코드 저장소를 복제할 수 있는 권한, 결과물을 운영·수정할 수 있는 범위, 제3자에게 다시 개발을 맡길 수 있는 범위는 같은 말이 아닙니다. 계약서와 발주·변경 기록에서 산출물 목록, 인도 시점, 이용 또는 양도 범위, 오픈소스 사용 고지, 비밀유지·개인정보 처리 조항을 각각 확인하세요. 문구가 불명확하면 인수 당일에 추측으로 정하지 말고, 개발사와 확인한 답변을 서면으로 남기는 편이 좋습니다.

한국저작권위원회는 저작재산권의 독점적·비독점적 이용허락 및 일부·전부 양도에 관한 표준계약서 서식을 제공합니다. 이는 특정 외주개발 계약의 결론을 대신하지 않지만, 이용허락과 양도처럼 계약에서 구분해 적을 수 있는 항목이 있음을 확인하는 공식 참고자료입니다. 실제 계약의 해석이나 권리 귀속 판단은 계약 내용과 개별 사실관계에 따라 달라질 수 있습니다. 저작권위원회 표준계약서를 참고해 필요한 검토 항목을 정리하세요.

앱 외주개발에서 완료 기준을 계약 전에 정의하는 방법은 앱 외주개발 검수 기준에서 이어서 확인할 수 있습니다. 개발 종료 뒤에만 이 표를 만들기보다, 계약·검수 단계부터 인수 항목을 연결해 두는 편이 좋습니다.

인수 순서는 ‘접속 가능 여부’부터, 그다음 ‘운영 가능 여부’입니다

첫날에는 모든 화면을 수정하려 하지 말고, 접근권한이 실제로 넘어왔는지를 확인합니다. 팀 계정으로 코드 저장소를 열고, 도메인 등록정보와 DNS 관리 화면을 확인하고, 클라우드 관리자 권한·복구 수단·비용 알림 수신자를 점검합니다. 이 세 항목 중 하나라도 기존 개발사 개인 계정에만 묶여 있다면, 서비스 운영권한이 완전히 넘어왔다고 보기 어렵습니다.

다음에는 운영에 필요한 문서를 묶습니다. 환경변수의 값이나 비밀번호를 일반 문서에 복사하지 말고, 보관 위치와 접근 책임자만 기록합니다. 배포 절차, 장애 알림, 백업 여부, 외부 연동 목록, 갱신일, 고객 문의가 들어왔을 때의 담당자를 정리하세요. 이 과정에서 실제 고객 정보나 비밀키가 노출되지 않도록 접근 범위와 공유 채널도 함께 점검해야 합니다.

MVP 개발 이후의 월 운영비를 기능 개발비와 섞지 않고 계획하는 기준은 MVP 앱 운영비 견적에서 볼 수 있습니다. 우리 팀의 개발·운영 준비 항목을 함께 점검하려면 유인어스 상담 준비 항목을 확인해 보세요.

개발사 교체가 예정됐다면 ‘원본 보관’과 ‘권한 회수’를 한 번에 하지 않습니다

계약 종료일에 기존 계정을 바로 삭제하면, 새 운영자가 놓친 설정을 되돌릴 방법도 사라질 수 있습니다. 먼저 계약·보안 기준에 맞춰 새 관리자 접근을 확인하고, 필요한 기록을 보관하고, 책임자와 종료 시점을 정한 뒤 기존 권한을 단계적으로 정리하세요. 반대로 기존 개발사 권한을 무기한 유지하면 책임 범위가 흐려질 수 있으므로, 종료 확인일과 남은 유지보수 범위를 문서로 남기는 것이 좋습니다.

이 글의 체크리스트는 법률 자문이나 특정 서비스의 이전 절차를 대체하지 않습니다. 계약서, 사용 중인 플랫폼의 최신 관리자 정책, 고객 데이터 처리 약정이 충돌하는 경우에는 관련 당사자와 전문가의 검토를 먼저 받으세요. 유인어스는 민간 사업 지원 서비스이며 계약 해석, 계정 이전 가능 여부, 서비스 운영 결과를 보장하지 않습니다.

개발 종료 전 10분 점검표

1. 팀이 코드 저장소의 소유자·관리자 권한을 실제로 보유하는가?

2. 도메인 등록인·책임자 이메일·갱신일을 회사가 확인할 수 있는가?

3. 클라우드·배포·오류 알림·결제 담당자가 팀 내에 지정됐는가?

4. 계약서의 산출물, 인도, 이용·양도 범위, 오픈소스 고지를 구분해 읽었는가?

5. 비밀키·고객정보를 일반 인수 문서에 복사하지 않았는가?

6. 새 운영자 접근 확인, 기존 권한 정리, 남은 유지보수 범위의 날짜와 담당자를 남겼는가?

앱 개발 종료 후 운영권한과 다음 성장 준비를 함께 정리하려면 현재 준비 항목을 점검해 보세요.

자주 묻는 질문

소스코드 ZIP 파일을 받으면 인수인계가 끝난 건가요?

아닙니다. 코드 파일 외에도 저장소 접근권한, 도메인·DNS, 클라우드·배포, 복구·알림·결제 담당자가 실제로 팀에 있는지 별도로 확인해야 합니다. 어떤 항목이 계약상 포함되는지는 계약서와 서비스 설정에 따라 다릅니다.

도메인 등록인이 개발사라면 무엇부터 확인하나요?

KRNIC의 안내처럼 등록인, 책임자 전자우편, 사용종료일을 먼저 확인하세요. 그다음 계약·등록대행자 절차에 맞춰 의뢰자 또는 사업자 명의와 관리 이메일을 어떻게 정리할지 확인합니다. 임의 변경 전에 서비스 영향과 권한을 검토해야 합니다.

개발사가 코드 저장소를 보여 주기만 하면 되나요?

열람 권한과 팀의 운영·관리 권한은 다를 수 있습니다. 팀 책임자가 저장소, 브랜치, 배포 설정에 필요한 수준으로 접근할 수 있는지 실제 로그인으로 확인하고, 결과물 이용·수정 범위는 계약서에서 따로 확인하세요.

계약서에 ‘소스 제공’만 적혀 있으면 어떻게 하나요?

어떤 산출물을 언제 어떤 방식으로 넘기는지, 결과물을 운영·수정·재개발할 수 있는 범위를 확인해야 합니다. 불명확한 부분은 추측으로 처리하지 말고 개발사와 서면으로 확인하고, 필요하면 계약·저작권 전문가에게 검토를 받으세요.