앱 유지보수는 고장 났을 때 고치는 일만이 아닙니다. 구글 플레이와 App Store는 해마다 새 OS 버전에 맞춰 빌드하라고 요구하고, 이를 맞추지 못하면 업데이트를 올릴 수 없습니다. 그래서 스토어 요건 대응, 라이브러리와 보안 업데이트, 서버와 인증서 관리, 장애 대응은 개발사에 맡기고, 공지와 문의 응대, 콘텐츠 관리 같은 운영은 운영사가 직접 하는 구성이 일반적입니다. 아래에 각각 무엇을 하는지, 계약에서 범위를 어떻게 나누는지 적었습니다.

앱은 출시하고 나서도 왜 계속 손이 가나요

앱 코드는 그대로인데 주변이 계속 바뀝니다. 휴대폰 OS가 매년 새 버전으로 올라가고, 스토어는 그에 맞춰 제출 기준을 올립니다. 앱 안에 들어간 결제, 로그인, 지도, 푸시 같은 외부 SDK도 각자 버전을 올리고 오래된 버전 지원을 끊습니다. 서버 인증서와 도메인에는 만료일이 있습니다.

출시 후 1년 동안 아무것도 안 한 앱을 다시 열어 보면, 코드를 한 줄도 안 바꿨는데 빌드가 안 되거나 새 기기에서 화면이 어긋나 있는 경우가 흔합니다. 유지보수는 이런 변화를 따라가서 앱이 계속 업데이트 가능한 상태로 남아 있게 하는 일이라고 보시면 됩니다.

해마다 바뀌는 스토어 요건은 어떻게 대응하나요

가장 확실하게 돌아오는 일정이 스토어 요건입니다. Google Play 타깃 API 요건 도움말을 보면 구글은 매년 8월 31일을 기준으로 새 앱과 업데이트가 타깃으로 삼아야 하는 안드로이드 버전을 한 단계씩 올려 왔습니다. 2025년 8월 31일에는 Android 15(API 35), 2026년 8월 31일에는 Android 16(API 36)이 기준이 됐습니다. Android Developers 문서에 따르면 이미 출시된 앱도 API 35 미만이면 더 새로운 안드로이드 기기를 쓰는 새 사용자에게는 보이지 않습니다. 올해 연장 신청 기한은 2026년 11월 1일이었습니다.

최근 스토어 요건 일정

1. 2025.8.31구글 플레이 API 35 기준
2. 2026.4.28Xcode 26, iOS 26 SDK 필수
3. 2026.8.31구글 플레이 API 36 기준
4. 2026.9.9iOS 13 이상 대상 필수
5. 2026.11.1API 36 연장 신청 기한

Apple도 비슷합니다. Apple의 예정된 요구사항 페이지에 따르면 2026년 4월 28일부터 App Store Connect에 올리는 앱은 Xcode 26 이상, iOS 26 SDK로 빌드해야 합니다. 2026년 9월 9일부터는 iOS와 iPadOS 앱이 iOS 13 이상을 대상으로 해야 한다는 요건도 붙었습니다.

이런 요건 대응은 숫자 하나 바꾸는 일로 끝나지 않습니다. 새 OS 동작에 맞춰 화면과 권한 처리를 고쳐야 하고, 외부 SDK가 새 버전을 지원하는지도 확인해야 합니다. 그래서 저희는 요건 발표가 나오면 바로 영향을 보고, 마감 몇 달 전에 작업을 끝내는 것을 목표로 잡습니다. 올해 요건의 자세한 내용은 API 36 대응 글, iOS 26 SDK 글, 2026년 구글 플레이 정책 글에 정리해 두었습니다.

라이브러리와 보안 업데이트는 얼마나 자주 해야 하나요

앱에는 직접 만든 코드 말고도 외부에서 가져온 라이브러리가 수십 개 들어 있습니다. 이 중 하나에서 보안 문제가 발표되거나, 결제사나 본인인증 업체가 오래된 SDK 지원 종료를 알려 오면 그때그때 버전을 올려야 합니다.

평소에는 몇 달에 한 번 정도 의존성 목록을 점검하고, 급하지 않은 업데이트는 다음 정기 업데이트에 묶어서 반영하는 방식이 무난합니다. 버전을 한 번에 많이 건너뛰면 바뀐 사용법을 한꺼번에 고쳐야 해서 작업이 커집니다. 매년 스토어 요건 작업을 할 때 라이브러리도 함께 최신으로 맞춰 두면 다음 해 부담이 줄어듭니다.

만료되는 것들을 놓치면 앱이 멈춥니다

유지보수에서 사고가 가장 허무하게 나는 곳이 만료일입니다. 기능은 멀쩡한데 날짜가 지나서 앱이 동작하지 않는 경우입니다.

• 도메인: 서버 주소에 쓰는 도메인이 만료되면 앱이 서버에 접속하지 못합니다.
• SSL 인증서: 서버 주소의 보안 인증서가 만료되면 앱의 통신이 실패합니다.
• 푸시 인증서: iOS 푸시를 인증서 방식으로 보내고 있다면 인증서 만료일에 푸시가 끊깁니다.
• 개발자 계정: Apple Developer 멤버십은 매년 갱신해야 하고, 갱신은 계정 소유자가 합니다.
• 클라우드와 외부 서비스 결제 카드: 카드 유효기간이 지나 결제가 실패하면 서비스가 정지될 수 있습니다.

각각의 만료일을 한 표에 모아 두고, 한 달 전에 알림이 오게 해 두는 것만으로 대부분 막을 수 있습니다. 자동 갱신을 걸어 두더라도 결제 카드가 바뀌면 소용이 없으니 연 1회는 눈으로 확인하는 편이 안전합니다.

장애가 나면 누가 무엇을 하나요

장애는 미리 정해 두지 않으면 대응이 늦어집니다. 누구에게 어떤 경로로 연락하는지, 몇 시간 안에 확인하는지, 주말과 야간에는 어떻게 하는지를 계약할 때 정해 둡니다.

운영사가 할 일은 장애를 빨리 알아차리고 정확히 전달하는 것입니다. 어떤 화면에서, 어떤 기기와 OS 버전에서, 몇 시쯤부터 문제가 생겼는지 알려 주시면 원인 찾는 시간이 크게 줄어듭니다. 개발사는 오류 수집 도구와 서버 로그로 원인을 찾고, 서버 쪽 문제면 바로 고치고, 앱 수정이 필요하면 긴급 업데이트를 올립니다. 앱 업데이트는 스토어 심사를 거쳐야 하므로, 서버 설정만으로 막을 수 있는 문제인지 먼저 확인하는 것이 순서입니다.

운영사가 직접 해야 하는 일은 무엇인가요

모든 것을 개발사에 맡기면 오히려 운영이 느려집니다. 공지 등록, 배너 교체, 이벤트 문구 수정, 고객 문의 답변, 스토어 리뷰 답글처럼 매일 일어나는 일은 운영사가 관리자 페이지로 직접 하는 편이 빠릅니다. 스토어 소개 문구와 스크린샷 교체, 앱 안의 콘텐츠 관리도 여기에 들어갑니다.

맡길 일과 직접 할 일

개발사

• 스토어 요건 대응
• 라이브러리 업데이트
• 장애 원인 찾기와 수정
• 정책 변경 대응

운영사

• 공지와 배너 관리
• 고객 문의 답변
• 스토어 리뷰 답글
• 앱 안 콘텐츠 관리

그러려면 처음 만들 때 관리자 페이지에 이런 기능이 들어가 있어야 합니다. 공지 하나 바꾸는 데 앱 업데이트가 필요한 구조라면 운영 비용이 계속 개발사 쪽으로 넘어옵니다. 반대로 스토어 정책 변경 대응, 권한 설명 문구 수정, 개인정보 관련 신고 항목 갱신처럼 기술 판단이 필요한 일은 개발사와 함께 처리하는 것이 안전합니다.

유지보수 계약에서 범위는 어떻게 정하나요

유지보수 계약에서 다툼이 생기는 곳은 대부분 "이것도 유지보수에 들어가느냐"입니다. 기존 기능이 원래대로 동작하게 하는 일과 새 기능을 추가하는 일을 나눠서 적어 두면 대부분 정리됩니다. 처음 개발 계약의 하자보수와 유지보수를 구분하는 이야기는 외주 계약서 글에 따로 적었습니다.

마지막 줄이 생각보다 중요합니다. 유지보수 업체가 바뀔 때를 대비해 계정은 운영사 명의로 두고, 소스코드는 운영사가 접근할 수 있는 저장소에 최신 상태로 올리도록 계약에 적어 두세요.

월간·연간 점검표

정기 점검은 매달 하는 것과 해마다 하는 것으로 나누면 관리하기 편합니다.

정기 점검 항목

• 매달 새로 늘어난 크래시 확인
• 매달 서버 자원과 백업 상태 확인
• 매달 스토어 정책 알림 확인
• 매년 스토어 요건 확인과 대응
• 매년 외부 SDK 일괄 업데이트
• 매년 도메인, 인증서 만료일 확인

매달 하는 것은 오류 수집 도구에서 새로 늘어난 크래시 확인, 서버 자원 사용량과 백업 상태 확인, 스토어 리뷰에서 반복되는 불만 확인, Play Console과 App Store Connect의 정책 알림 확인입니다. 정책 알림은 메일로 오는데 담당자가 바뀌면서 놓치는 경우가 많습니다.

해마다 하는 것은 구글 플레이 타깃 API 요건과 Apple SDK 요건 확인 및 대응, 외부 SDK 일괄 업데이트, 도메인·인증서·개발자 계정 만료일 확인, 새 OS 버전에서 전체 화면 점검입니다. 새 OS는 보통 가을에 정식 배포되므로 여름부터 베타 버전으로 미리 확인해 두면 여유가 생깁니다.

자주 묻는 질문

업데이트를 안 하면 스토어에서 앱이 내려가나요?

요건을 맞추지 못했다고 바로 삭제되지는 않습니다. 구글 플레이는 새 버전 안드로이드 기기의 새 사용자에게 앱이 보이지 않게 되고, 두 스토어 모두 요건에 맞지 않는 빌드는 업데이트로 올릴 수 없습니다. 급한 수정이 생겼을 때 배포를 못 하는 것이 가장 큰 문제입니다.

유지보수는 처음 만든 업체에 맡겨야 하나요?

꼭 그럴 필요는 없습니다. 소스코드와 계정, 서명 키를 넘겨받을 수 있다면 다른 업체도 이어서 맡을 수 있습니다. 다만 넘겨받는 데 시간이 들기 때문에, 계정과 코드가 운영사 쪽에 정리되어 있는지가 중요합니다.

기능 추가 요청은 유지보수 범위에 들어가나요?

보통은 별도 작업으로 봅니다. 기존 기능을 유지하는 일과 새 기능을 만드는 일은 작업량 예측 방식이 달라서, 계약서에 기준을 적어 두고 그때그때 협의하는 경우가 많습니다.

앱 사용자가 적어도 유지보수가 필요한가요?

사용자 수와 상관없이 스토어 요건과 만료일은 똑같이 돌아옵니다. 사용자가 적다면 매달 점검은 가볍게 하고, 해마다 하는 요건 대응과 만료일 확인 위주로 범위를 줄이는 방법이 있습니다.

모바일파트너스는 출시한 앱의 스토어 요건 대응과 업데이트, 장애 대응을 포함한 유지보수를 맡고 있습니다. 다른 업체가 만든 앱도 넘겨받아 이어서 관리합니다. 지금 앱 상태가 궁금하시다면 상담 페이지로 알려 주세요. 제공하는 서비스는 서비스 소개에서 보실 수 있습니다.