만든 개발사와 연락이 어렵거나 수정 요청이 계속 밀리는데, 소스코드와 서버, 앱 스토어 계정이 어디에 있는지도 분명하지 않은 경우가 있습니다. 이때 새 개발사에 전체 재개발 견적부터 받기 쉽습니다. 하지만 먼저 확인할 일은 현재 앱을 고쳐서 다시 출시할 수 있느냐입니다.
코드가 오래됐다는 이유만으로 앱 전체를 새로 만들 필요는 없습니다. 반대로 소스코드를 받았더라도 새 팀이 로그인 오류 하나를 수정하고, 테스트한 뒤, 문제가 생기면 이전 상태로 되돌릴 수 없다면 유지보수가 가능한 상태라고 보기 어렵습니다. 판단 기준은 코드의 연식이 아니라 서비스에 대한 통제권과 작은 변경을 출시하는 능력입니다.
비밀번호가 아니라 회사의 통제권을 확인한다
개발사 변경 전에 먼저 만들 자료는 완벽한 기술 문서가 아니라 간단한 통제권 지도입니다. 앱을 운영하는 데 필요한 계정과 서비스마다 누가 소유자인지, 회사 관리자를 추가할 수 있는지, 비용 청구와 복구 연락처가 누구인지 적어보면 됩니다.
비밀번호를 전달받는 것만으로는 충분하지 않습니다. 이전 개발사 개인 계정에 연결된 서비스라면 비밀번호를 알아도 관리자 권한을 바꾸지 못하거나, 결제수단과 복구 이메일이 이전 담당자에게 남아 있을 수 있습니다. 새 팀이 점검을 마치기 전부터 기존 담당자의 권한을 모두 끊기보다, 회사 명의 관리자 권한을 확보하고 서비스가 정상 동작하는지 확인한 뒤 접근 권한을 정리하는 편이 낫습니다.
처음에는 아래 다섯 영역만 확인해도 현재 상황을 상당 부분 파악할 수 있습니다.
- 소스코드 저장소와 자동 배포 설정
- 서버, 데이터베이스, 파일 저장 공간, 백업
- Apple·Google 앱 스토어 계정과 앱 출시 권한
- 도메인, 업무용 메일, 고객 알림 발송 계정
- 로그인, 결제, 푸시 알림, 분석처럼 앱 밖에서 연결한 서비스
모르는 항목은 억지로 채우지 말고 ‘미확인’으로 남겨야 합니다. 그 빈칸이 새 개발사의 초기 진단 범위가 됩니다. 특히 스토어 계정을 옮겼다는 사실과 새 팀이 앱을 업데이트할 수 있다는 사실은 다릅니다. 출시 서명, 결제, 푸시 알림, 로그인 설정은 별도로 연결 상태를 시험해야 할 수 있습니다.
유지보수 가능 여부는 작은 출시로 가른다
문서가 많거나 코드가 깔끔해 보인다고 운영 가능성이 증명되지는 않습니다. 새 개발사는 별도 작업 환경에서 코드를 내려받아 실행하고, 현재 운영 버전과 같은 앱을 만들며, 테스트용 배포까지 해볼 수 있어야 합니다. 이 과정에서 빠진 설정값, 접근할 수 없는 외부 서비스, 특정 담당자만 아는 작업 순서가 드러납니다.
처음부터 화면을 바꾸거나 기능을 크게 추가할 필요는 없습니다. 예를 들어 예약 앱이라면 회원 가입부터 예약 확인까지의 흐름 중 하나를 고르고, 작은 오류를 수정해 테스트 배포하는 방식이 적절합니다. 이 시험은 새 팀의 개발 실력만 보는 일이 아닙니다. 고객 데이터가 어디에 있는지, 결제나 알림이 어느 서비스에 연결되는지, 장애가 나면 어디를 봐야 하는지를 함께 확인하는 과정입니다.
유지보수를 이어갈 근거는 “분석을 마쳤다”는 말보다 결과물에서 확인됩니다. 새 팀이 실행 방법, 필요한 계정, 확인하지 못한 연동, 발견한 위험, 첫 수정안과 되돌리는 방법을 설명할 수 있다면 운영 안정화부터 시작할 여지가 있습니다. 이 단계가 확인된 영역은 기존 앱을 유지하면서 우선순위에 따라 개선하고, 확인되지 않은 영역은 별도 과제로 남기는 편을 검토할 수 있습니다.
전면 재작성보다 핵심 흐름의 부분 교체가 나은 때
재개발을 검토할 신호는 코드가 낡아 보인다는 평가가 아닙니다. 운영 버전을 재현하지 못하고, 회원·결제·주문처럼 중요한 기능의 데이터 위치와 연결 관계가 불명확하며, 장애 원인을 살필 기록이나 복구 방법도 없는 상황이 더 중요한 신호입니다. 사업 방식이 바뀌어 기존 구조가 새 요구를 계속 막는 경우도 여기에 포함됩니다.
그래도 앱 전체를 한 번에 폐기하는 결정은 신중해야 합니다. 기존 앱에는 고객이 익숙한 화면, 누적된 데이터, 아직 문제없이 작동하는 기능이 섞여 있기 때문입니다. 가령 상품 소개와 공지 기능은 유지하되, 오류가 잦고 매출에 직접 연결되는 주문 흐름만 새 구조로 교체하는 방법을 생각해볼 수 있습니다. 새 기능을 제한된 범위에서 확인하면서 기존 서비스도 계속 운영할 수 있습니다.
새 개발사가 전면 재개발을 제안한다면 “무엇이 낡았는가”보다 “어떤 흐름을 수정·배포·복구할 수 없는가”를 물어야 합니다. 유지할 부분, 먼저 안정화할 부분, 새로 만들 가능성이 있는 부분을 근거와 함께 나누어 달라고 요청하는 편이 판단에 도움이 됩니다. 코드 진단 결과만으로 전체 교체를 확정하기보다, 고객 영향이 큰 흐름부터 검증하고 교체 범위를 넓혀가는 선택지가 있는지 함께 살펴보십시오.
첫 논의에는 완성된 기획서보다 현재 화면 캡처, 최근 고객 문의와 장애 내용, 중요한 기능의 순서, 알고 있는 계정 목록, 기존 계약서와 산출물 위치를 준비하면 됩니다. 그 자료로 통제권 지도를 만들고 작은 수정 배포를 시험해 보십시오. 시험을 통과한 영역은 운영하며 개선하고, 통과하지 못한 핵심 흐름만 단계적으로 다시 만드는 판단이 새로운 시작의 범위를 불필요하게 키우지 않는 방법입니다.
