기존 시스템 유지보수 인수: 개발사 연락 두절·문서 부재 대응

기존 개발사가 없어도 시스템을 인수할 수 있나요?

인수 가능 여부는 개발사와 연락이 되는지뿐 아니라 소스, 운영 계정과 사용 권한이 얼마나 확보되어 있는지에 따라 달라집니다. 서비스가 실행되고 있다는 사실만으로 수정과 재배포가 가능한 것은 아닙니다. 당장 전체 재개발을 정하기 전에 접근할 수 있는 자산, 확인되지 않은 설정과 중단되면 안 되는 업무를 목록으로 정리하세요.

문서가 없으면 인수와 수정을 나눠 진행하세요

우선 저장소, 운영 서버, DB, 예약 작업과 외부 연동을 연결한 목록을 만듭니다. 다음으로 운영에 적용된 버전과 받은 소스가 같은지 확인하고, 분리된 검증 환경에서 빌드와 배포를 재현합니다. 이 과정에서 나온 누락 자료와 위험을 바탕으로 안정화 우선순위를 정하세요. 문서가 없다는 이유만으로 인수가 불가능한 것은 아니지만 조사 없이 일정과 수정 범위를 확정하기는 어렵습니다.

• 자산 목록: 소스 저장소·서버·DB·도메인·배포 계정과 담당자
• 재현 결과: 실행 환경·빌드 절차·운영 버전과의 차이
• 위험 목록: 접근 불가 계정·확인하지 못한 설정·지원이 끝난 구성
• 안정화 제안: 우선 수정·검수 방법·별도 개선이 필요한 항목

소유 계정과 작업 권한을 구분해 정리하세요

클라우드·도메인·저장소의 소유자와 비용을 지불하는 주체를 확인하고, 새 담당자가 맡은 작업에 필요한 권한을 정합니다. 계약 종료 시 전달할 소스, 변경 기록과 운영 문서도 처음부터 목록에 넣으세요. GitHub는 저장소 이전 후에도 협업자와 일부 연동 정보가 유지될 수 있다고 안내합니다. 따라서 저장소를 옮긴 뒤에도 기존 접근 권한과 배포 키 등을 다시 점검해야 합니다.

• GitHub 저장소 이전과 권한 확인 사항

ERP·WMS·IoT는 실제 업무 단위로 검수하세요

ERP와 WMS는 주문·입고·출고·반품이 각 시스템에서 어느 시점에 반영되는지 확인합니다. 데이터 건수만 맞추지 말고 재고 합계와 대표 거래를 대조하세요. IoT는 앱·서버·펌웨어 버전, 통신 규격과 시험할 기기를 함께 확보하고 연결 단절과 재연결도 확인 대상으로 정합니다. 샘플 기기나 외부 API 시험 환경을 구할 수 없다면 검수하지 못한 범위를 명확히 남겨야 합니다.

운영 전환은 현장의 작업 시간과 맞춰 계획하세요. 배포 전후 확인할 주문과 재고, 장치 상태를 정하고 실패 시 이전 상태로 돌아갈 조건을 합의합니다. 기존 시스템과 병행해서 확인한다면 어느 쪽에 입력하는지 정해 중복 처리와 누락을 점검해야 합니다.

개발자 공백 기간에는 운영 책임과 개선 작업을 나누세요

사내 개발자가 퇴사했다면 장애 접수, 배포 승인, 계정 관리와 업무 검수를 누가 이어받는지 먼저 정합니다. 후임 채용 전까지 외부에 맡길 범위는 핵심 운영과 긴급 수정부터 검토할 수 있습니다. 내부팀이 남아 있다면 외부팀이 진단·수정·QA 중 무엇을 맡고, 내부에서 무엇을 승인하는지 나누세요. 후임에게 전달할 작업 이력과 배포 문서도 같은 기록으로 관리하는 것이 좋습니다.

확인되지 않은 조건을 남긴 채 전환하지 마세요

접근·사용 권한이 불분명하거나 받은 소스를 빌드할 수 없다면 먼저 해결할 선행 조건으로 남깁니다. 검증 환경, 핵심 업무 확인 또는 복구 방법이 준비되지 않았다면 운영 전환 일정을 다시 검토하세요. 기술이 오래됐다는 이유만으로 모두 재개발하거나, 어떤 시스템이든 곧바로 고칠 수 있다고 가정하지 말고 유지 가능한 부분과 교체할 부분을 진단 결과로 구분해야 합니다.

• 기존 개발사에 요청할 인수 자료 체크리스트
• 토핑 유지보수 인수 범위
• 인수·회귀 검수·복구의 가상 예시