정보 공간

소스·계정 인수인계 없이 외주 끝난 뒤 생기는 일

소스·계정 인수인계 없이 외주 끝난 뒤 생기는 일

프로젝트가 “완료”로 닫히고 잔금까지 지급했습니다. 몇 주 뒤 문구 수정, 배너 교체, 결제 설정 변경, 서버 인증서 갱신 같은 작은 운영 일이 생깁니다. 그때야 알게 됩니다. 코드는 누군가의 개인 저장소에 있고, 서버는 개인 클라우드 계정에 묶여 있으며, 앱 스토어·푸시·도메인 관련 메일이 제작 담당자 개인 메일로만 옵니다.

인수인계 없이 끝난 외주는, 사고가 나기 전까지는 조용합니다. 아래는 그 이후에 실제로 자주 생기는 일과, 계약·검수 단계에서 막을 수 있는 지점을 쉬운 말로 정리한 것입니다.

소스·계정 인수인계 없이 외주 끝난 뒤 생기는 일 — 핵심 개념 시각 자료

왜 인수인계가 빠진 채 끝날까

일정이 빠듯해 “문서는 나중에”로 밀리고, 잔금과 인수 산출물이 계약에 연결되지 않은 경우가 많습니다. 화면 시연만 보고 완료 처리하거나, 빠르게 가려고 수행자 개인 계정으로 서버·스토어를 열어 둔 채 유지보수를 맺지 않고 관계가 끝나기도 합니다. 악의가 없어도 구조만으로 생길 수 있는 공백입니다.

끝난 뒤, 시간에 따라 생기는 일

1~2주

작은 수정이 안 됩니다. 텍스트·이미지 변경을 요청하면 “저장소 권한을 달라”는 답이 오거나 연락이 늦어집니다. 마케팅 일정만 먼저 움직이는 일이 생깁니다.

1~3개월

만료·청구 이슈가 따라옵니다. 도메인, 보안 인증서, 클라우드 카드, 스토어 개발자 계정 갱신 메일이 개인 메일로 갑니다. 놓치면 사이트 접속 장애, 앱 업데이트 불능으로 이어질 수 있습니다.

장애가 난 날

원인을 쫓기 어렵습니다. 서버 로그, 배포 이력, 설정 값 위치를 아는 사람이 없습니다. “재시작해 봤다” 수준의 대응만 반복되기 쉽습니다.

업체를 다시 고를 때

현황 파악 견적이 먼저 붙습니다. 코드 없이 추측하거나, 부분 접근만으로 조사하는 비용이 견적에 들어갑니다. 기능 개선 예산이 조사비로 옮겨 갑니다.

가장 나쁜 경우

데이터 백업은 있어도, 애플리케이션 버전·배치·키 조합을 몰라 같은 서비스를 그대로 재현하지 못합니다. 사실상 새로 만드는 것과 같습니다.

반드시 넘겨받아야 할 것들

구분 확인 방법
코드 저장소, 배포 태그 우리 조직에서 받아서 빌드·실행
인프라 클라우드, 서버 소유자·최고 권한이 우리 쪽인지
도메인 등록 기관, DNS 레코드를 우리가 수정할 수 있는지
스토어 콘솔, 서명 키 팀 멤버·역할이 우리 쪽인지
연동 결제, 문자, 푸시, 지도, 소셜 로그인 대시보드 소유자·키 재발급 가능 여부
데이터 DB, 파일 저장소, 백업 복원 연습 한 번
문서 배포·운영 절차, 계정 표 문서대로 따라 해 보기
법무 약관·개인정보 처리 원본 저장 위치와 책임자

하나라도 “그 사람 PC에만” 있으면 리스크 항목입니다.

잔금과 연결할 인수 조건 예시

발주 조직 저장소로 전체 이력이 넘어갔, 운영·시험 환경 접속 정보와 비밀 값이 합의된 안전한 경로로 이관됐는지, 외부 서비스 소유자 이전 또는 역할 부여가 끝났는지, 배포를 발주 측(또는 지정 인력)이 한 번 참관·재현했는지, 알려진 이슈와 미완 범위가 문서로 남았는지, 수행자 개인 권한이 제거됐는지까지 잔금 전에 맞춥니다. 시연 영상만으로 잔금을 닫지 않는 것이 핵심입니다.

문서 PDF를 받는 것과 인수 완료는 다릅니다. 가능하면 잔금 전에 아래 리허설 중 둘 이상 통과를 권합니다. 우리 계정으로 저장소를 받아 문서대로 띄워 보기, 시험 환경에 배포 한 번 해 보기, 관리자로 일상 운영 시나리오 몇 개 해 보기, 백업으로 복원 절차를 따라 보기, 외부 연동 콘솔의 소유자·멤버 목록을 자산 대장에 남기기, 수행자 개인 권한을 뺀 뒤에도 배포·운영이 되는지 확인하기입니다.

리허설에서 막히면 그것이 곧 남은 일입니다. “나중에 알려 주시겠죠?”로 넘기면 잔금 뒤 협상력이 떨어집니다. 계약에 산출물 정의 표(저장소 위치, 환경 목록, 계정 표, 문서 위치, 이관 완료일)를 붙이면 분쟁을 줄이는 데 도움이 됩니다.

이미 끝난 뒤라면

감정적으로 “연락이 안 된다”에만 매달리면 시간이 갑니다. 접근 가능한 것부터 목록으로 만들고, 계약상 산출물 조항을 확인한 뒤 정식으로 요청하고, 접근이 공유된 상태면 비밀번호·키를 교체하고, 데이터 백업을 최우선으로 확보한 다음, 복구 가능 범위를 보고 수리와 재구축을 결정하는 순서가 낫습니다. 그다음 소유권 정책을 조직 규칙으로 남깁니다.

관계가 이미 나빠진 경우에도, 공개 채널에서 감정 공방보다 자산 목록 요청 → 백업 → 권한 정리를 유지하는 편이 복구 확률을 높입니다. 개인정보·결제 키가 노출됐을 가능성이 있으면 교체 여부도 함께 봅니다.

인수인계 누락의 비용은 개발비 고지서보다 사업이 멈춘 시간에서 커지기 쉽습니다. 시즌 홈페이지 다운, 결제 설정 변경 불능, 앱 강제 업데이트 대응 실패는 광고비와 신뢰에 바로 닿습니다.

LB Contents는 앱·홈페이지·쇼핑몰을 만들 때 화면뿐 아니라 운영·인수인계 구조까지 같이 설계합니다. 종료 직전 점검이 불안하거나, 이미 공백이 생긴 뒤의 점검·재구축 상담이 필요할 때 이야기할 수 있습니다.