기존 앱 인수 후 첫 2주에 확인할 장애 대응과 배포 책임
앱 유지보수 업체를 바꾸거나 내부 개발 담당자가 퇴사한 뒤 기존 앱을 인수할 때, 가장 먼저 눈에 들어오는 것은 소스코드입니다. 저장소 접근 권한을 받고 빌드가 되는지 보는 일도 필요합니다. 하지만 운영 책임자의 입장에서 더 곤란한 문제는 다른 곳에서 시작됩니다.
장애가 발생했을 때 누가 처음 접수하는지, 현재 배포 파일을 어떤 절차로 다시 만들 수 있는지, 운영 계정의 권한이 누구에게 있는지 모르면 코드가 있어도 대응이 늦어집니다. 산출물을 전달받는 일과 서비스를 이어받는 일은 같은 작업이 아닙니다.
첫 2주는 기능을 크게 바꾸는 기간이 아니라 운영 책임을 나누는 기간으로 잡는 편이 안전합니다. 기존 앱 인수 체크리스트도 화면 목록이나 소스코드 파일 목록에서 끝내지 말고, 장애와 배포를 실제로 다룰 수 있는지에 맞춰야 합니다.
첫 2주에 정해야 할 인수의 범위
인수 시작 전에 앱만 넘겨받는지, 관리자 웹과 API, 데이터베이스, 스토어 계정까지 함께 운영하는지 범위를 적어야 합니다. 한쪽은 앱 코드만 전달했다고 생각하고 다른 쪽은 서버 운영까지 포함됐다고 생각하면 장애가 발생한 순간 책임 공방이 시작됩니다.
다음 항목은 문서 제목이 아니라 실제 접근 가능 여부와 담당자까지 연결해 두는 것이 좋습니다.
- 모바일 앱 저장소와 브랜치 운영 방식
- 관리자 웹 저장소와 배포 환경
- API 서버와 데이터베이스의 운영 위치
- 앱스토어와 플레이스토어 배포 권한
- 푸시 알림, 결제, 지도 등 외부 서비스 계정
- 오류 로그와 모니터링 도구의 접근 권한
- 운영 데이터에 접근할 수 있는 담당자와 승인 방식
- 현재 유지보수 업체가 맡는 범위와 종료 시점
이 목록에서 중요한 것은 계정의 개수가 아닙니다. 장애가 발생했을 때 해당 권한을 사용해 조치할 수 있는지입니다. 예를 들어 스토어 계정에 초대되었더라도 인증 기기나 배포 인증서가 이전 담당자에게 묶여 있으면 긴급 배포가 막힐 수 있습니다.
장애 접수 방식부터 실제로 열어보기
앱 장애 대응은 연락처 하나를 받는 것으로 끝나지 않습니다. 사용자의 신고가 어디로 들어오고, 운영 담당자가 어떤 정보를 모아 개발 담당자에게 전달하는지 흐름이 있어야 합니다.
첫 주에는 최근에 접수된 문의나 내부에서 재현 가능한 오류를 기준으로 모의 접수를 진행하는 편이 좋습니다. 어떤 기기와 운영체제에서 문제가 발생했는지, 특정 계정이나 데이터 조건이 필요한지, 오류가 반복되는지 기록하지 않으면 개발자에게 전달되는 정보가 부족해집니다.
최소한 아래 질문에는 답할 수 있어야 합니다.
- 장애 접수 채널이 하나로 정해져 있는가
- 긴급 장애와 일반 문의를 구분하는 기준이 있는가
- 장애 접수 시 수집할 정보가 정리되어 있는가
- 일차 판단을 맡는 사람이 지정되어 있는가
- 운영 중단이 우려될 때 의사결정권자에게 알리는 방식이 있는가
- 조치 후 사용자 안내와 내부 기록을 누가 맡는가
앱 장애 대응에서 모든 문제를 개발자에게 바로 넘기는 방식은 효율적이지 않습니다. 일시적인 네트워크 문제인지, 특정 버전에서만 발생하는지, 서버 오류인지 먼저 분류해야 대응 순서가 정해집니다. 반대로 원인 판단을 운영 담당자 한 명에게만 맡기면 기술적 확인이 늦어질 수 있으므로, 접수와 분석의 경계도 함께 정해야 합니다.
배포가 다시 재현되는지 점검하기
인수 후 긴급 수정이 필요한 상황을 가정하면 배포 재현성이 드러납니다. 기존 업체가 가진 개인 컴퓨터에서만 빌드되는 앱이라면 저장소를 전달받아도 운영을 이어가기 어렵습니다.
첫 2주 안에 개발 환경을 새로 구성하거나, 최소한 새로운 담당자가 같은 절차로 테스트 빌드와 운영 배포 준비를 수행해 보는 것이 좋습니다. 이때 중요한 것은 특정 프레임워크의 사용법이 아니라 누가 작업해도 같은 결과에 접근할 수 있는 구조인지입니다.
- 의존성 버전과 빌드 명령이 문서화되어 있는가
- 개발·테스트·운영 환경의 차이가 설명되어 있는가
- 환경 변수와 비밀 정보가 안전한 방식으로 관리되는가
- 테스트 빌드를 만들 수 있는가
- 운영 배포 전에 검증할 수 있는 환경이 있는가
- 앱 서명과 배포 인증서의 관리 주체가 정해져 있는가
- 이전 버전으로 되돌릴 기준과 절차가 있는가
운영 배포 권한과 코드 수정 권한도 나눠서 봐야 합니다. 코드를 수정할 수 있지만 스토어 배포를 할 수 없거나, 반대로 배포 권한은 있지만 변경 내역을 검토할 수 없다면 긴급 수정 과정에서 통제가 약해집니다.
배포 책임을 정할 때는 ‘누가 버튼을 누르는가’보다 승인과 기록을 누가 맡는지가 더 중요합니다. 긴급 상황에서는 승인 절차를 간소화할 수 있지만, 변경 이유와 적용 범위가 남아야 다음 장애에서 같은 판단을 반복하지 않습니다.
운영 권한과 긴급 수정 절차를 문서로 남기기
운영 계정은 인수 과정에서 가장 쉽게 빠지는 항목입니다. 계정 목록만 전달받고 실제 권한 수준이나 복구 수단을 점검하지 않으면, 담당자 변경 시 다시 접근 문제가 생깁니다.
권한은 업무별로 나누는 것이 좋습니다. 서버와 데이터베이스에 접근하는 권한, 로그를 읽는 권한, 스토어에 배포하는 권한, 운영 데이터를 수정하는 권한은 서로 같은 수준일 필요가 없습니다. 특히 운영 데이터 수정은 앱 코드 배포와 별도의 승인 기준을 두는 편이 안전합니다.
긴급 수정 절차도 다음 순서로 짧게 적어 두면 실무에서 활용하기 쉽습니다.
- 장애 수준을 판단하는 담당자 지정
- 긴급 수정 범위와 승인자 지정
- 수정 전 데이터와 설정 백업 여부 결정
- 테스트 빌드 또는 제한된 검증 절차 실행
- 운영 배포와 변경 기록 작성
- 장애 종료 판단과 사후 공유 담당자 지정
이 절차는 문서로만 존재해서는 부족합니다. 작은 수정이나 테스트 배포를 통해 실제로 실행해 보고, 접근 권한이 막히는 지점과 설명이 모호한 지점을 고쳐야 합니다. 인수 기간에 발견한 문제는 운영 중 장애로 드러나기 전에 해결할 수 있는 문제이기도 합니다.
첫 2주를 인수 완료의 기준으로 바꾸기
기존 앱 인수의 완료 기준은 파일을 받았는지가 아닙니다. 운영 담당자가 장애를 접수하고, 기술 담당자가 원인을 좁히고, 승인된 절차에 따라 수정본을 배포할 수 있는지가 기준이 되어야 합니다.
첫째 주에는 권한과 현재 운영 흐름을 정리합니다. 둘째 주에는 테스트 빌드와 모의 장애 접수를 진행하고, 그 결과를 바탕으로 담당 범위와 긴급 대응 절차를 문서화합니다. 이 순서를 따르면 소스코드 검토에서 놓치기 쉬운 운영 공백을 먼저 발견할 수 있습니다.
앱 유지보수 업체를 선정할 때도 개발 언어와 기능 견적만 비교하기보다, 인수 이후 장애 대응과 배포 책임을 어떻게 나누는지 질문해야 합니다. 답변이 담당자 이름, 접근 권한, 기록 방식, 대응 순서로 구체화되지 않는다면 계약 전에 운영 범위를 다시 좁혀 쓰는 편이 낫습니다.
기존 앱 인수 후 장애 대응과 배포 책임이 모호하다면, 현재 권한 구조와 운영 절차를 기준으로 인수 범위를 진단해 보세요. 앱 유지보수와 긴급 안정화에 필요한 작업 순서를 함께 정리할 수 있습니다. https://www.universoft.kr/contact