1. 문제는 외주개발이 아니라 ‘운영권이 업체에 묶이는 것’입니다.
외주개발 자체가 서비스 운영을 위험하게 만드는 것은 아닙니다. 개발업체가 서버와 도메인을 자기 계정으로 만들고, 소스 저장소도 업체만 접근할 수 있으며, 배포방법을 특정 개발자만 알고 있는 상태가 위험합니다.
2. 서비스 독립성을 결정하는 여섯 가지 조건
운영본과 일치하는 소스와 Git 관리권한
DB·업로드 파일·백업을 운영주체가 확보
서버·도메인·외부서비스의 관리자 권한
다른 개발자도 빌드·테스트·배포할 수 있음
구성·운영·장애·정기업무가 문서화됨
장애나 계정 문제 발생 시 복구할 수 있는 백업
3. 같은 ‘소스 보유’라도 운영 가능성은 다릅니다.
| 상황 | 운영 위험 | 이유 |
|---|---|---|
| 소스 ZIP만 보유 | 높음 | 운영본·환경·배포방법을 다시 분석해야 할 수 있음 |
| 소스와 DB는 있지만 서버가 업체 계정 | 높음 | 인프라 통제권과 이전 가능성을 확인해야 함 |
| 계정은 자사 소유지만 배포를 업체만 할 수 있음 | 중간 | 기술 지식이 특정 업체에 집중되어 있음 |
| 소스·계정·DB·문서 확보, 다른 개발자 재현 가능 | 상대적으로 낮음 | 업체 변경 시 후속 운영으로 연결하기 쉬움 |
4. 업체가 없어지기 전에 준비하는 것이 가장 쉽습니다.
운영 독립성은 계약 종료 직전에 만드는 것이 아니라 프로젝트 시작부터 설계하는 편이 좋습니다. 핵심 계정은 운영주체 명의로 만들고 업체에는 필요한 권한을 부여하며, 소스와 배포정보도 프로젝트 진행 중 계속 공유받는 방식이 좋습니다.
Git·서버·도메인 핵심 계정 확보
소스·문서·설정 변경을 계속 반영
DB·파일과 주요 설정 복구 준비
특정 개발자만 아는 절차 제거
다른 담당자가 실행·배포 확인
5. 이미 개발업체와 연락이 끊겼다면 먼저 ‘현재 통제 가능한 자산’을 확인하세요.
바로 새 업체를 찾아 개발을 시작하기보다 현재 확보한 자산과 접근권한부터 목록화하는 것이 좋습니다. 무엇이 있는지 알아야 서비스 유지 가능성과 복구 범위를 판단할 수 있습니다.
| 우선순위 | 확인할 내용 |
|---|---|
| 1. 서비스 유지 | 운영 서버가 정상인지, 결제·도메인·SSL 등 만료 예정 항목이 있는지 |
| 2. 관리자 권한 | 클라우드·도메인·Git·외부서비스에 접근 가능한지 |
| 3. 데이터 보호 | DB와 파일을 안전하게 백업할 수 있는지 |
| 4. 소스 확보 | 현재 운영본과 대응되는 최신 소스를 확보했는지 |
| 5. 기술 분석 | 새 개발자가 시스템 구조·환경·배포방식을 파악할 수 있는지 |
| 6. 이전 계획 | 누락 자산과 위험을 정리하고 후속 운영체계를 결정 |
운영 중인 시스템에서는 무리한 설정 변경이나 즉시 재배포보다 먼저 백업과 현재 상태 보존을 우선하는 것이 안전합니다.
유지보수 계약이 있어도 운영 독립성은 필요합니다.
장기간 같은 개발업체와 협력하는 것은 효율적일 수 있습니다. 시스템을 잘 아는 업체가 유지보수를 맡으면 학습비용도 줄어듭니다. 다만 좋은 장기 협력과 업체 종속은 다릅니다. 계약을 계속하더라도 핵심 자산과 계정, 운영정보는 서비스 운영주체가 확인하고 통제할 수 있어야 합니다.
6. 우리 서비스의 업체 의존도 체크리스트
좋은 유지보수 관계는 개발업체에 의존하는 것이 아니라, 언제든 이어받을 수 있는 상태에서 협력하는 것입니다.
업체가 바뀌어도 소스·데이터·계정·운영지식이 서비스에 남는 구조를 만들어야 장기적으로 안정적인 운영이 가능합니다.