앱 출시 뒤 OS·스토어 대응, 방식별로 무엇이 다를까요

먼저 짧게 답부터 드릴게요. 앱은 기능을 하나도 안 고쳐도 해마다 손이 가요. 구글플레이는 2026년 8월 31일부터 새 앱과 업데이트에 Android 16(API 36) 타깃을 요구하고, 애플은 4월 28일부터 iOS 26 SDK로 빌드한 앱만 받아요. 크로스플랫폼은 이 대응을 한 번에 하는 대신 프레임워크와 라이브러리를 기다려야 하고, 네이티브는 두 번 하는 대신 기다릴 일이 적어요. 직접 만들고 운영해 본 개발사 기준으로, 견적에 넣어 둘 항목을 정리했어요.

“앱은 작년에 다 만들었는데요, 스토어에서 업데이트를 못 올린다고 메일이 왔어요.”

출시 1～2년 차에 자주 듣는 말이에요. 개발 방식별 초기 비용 차이는 크로스플랫폼 vs 네이티브, 비용과 유지보수는 어떻게 다를까요에 정리해 뒀어요. 이 글은 그다음만 봐요. 출시하고 나서 OS와 스토어가 요구하는 일은 방식별로 어떻게 다르고, 누가 돈을 내나요.

---

1. 아무것도 안 고쳐도 왜 일이 생길까요

앱은 혼자 돌아가지 않아요. 휴대폰 운영체제 위에서, 스토어를 거쳐서 사용자에게 가요. 두 곳이 해마다 규칙을 올려요.

공식 외부 기준 — 2025～2026년에 있었던 요건

시점	어디서	무엇을 요구했나요
2025년 11월 1일	구글플레이	Android 15 이상을 타깃하는 새 앱과 업데이트는 16KB 메모리 페이지를 지원해야 해요
2026년 4월 28일	애플 앱스토어	업로드하는 앱은 Xcode 26 이상, iOS 26 SDK로 빌드해야 해요
2026년 8월 31일	구글플레이	새 앱과 업데이트는 Android 16(API 36)을 타깃해야 해요

(출처: Android 개발자 문서의 타깃 API 요건, Apple 개발자 사이트의 SDK 최소 요건 안내. 구글은 사정이 있으면 2026년 11월 1일까지 연장을 요청할 수 있다고 안내해요.)

눈여겨볼 건 구글 쪽 규칙이 해마다 반복된다는 점이에요. 작년에는 API 35였고 올해는 36이에요. 내년에도 올라가요.

기존 앱도 예외가 아니에요. 구글플레이는 이미 올라가 있는 앱이 Android 15(API 35) 이상을 타깃하지 않으면, 그보다 새 OS를 쓰는 기기의 신규 사용자에게는 보이지 않게 해요. 지우지는 않지만 새 손님이 못 찾는 가게가 돼요.

용어 정리 — 타깃 API 레벨은 “이 앱은 이 버전의 안드로이드 규칙에 맞춰 만들었어요”라고 앱이 선언하는 숫자예요. 숫자만 올리면 끝나는 게 아니라, 그 버전에서 바뀐 권한과 화면 동작에 맞게 앱을 고치고 다시 시험해야 해요. 실무에선 “타깃 올려야 해요”라고 말해요.

2. 크로스플랫폼은 한 번만 고치면 되나요

절반만 맞아요. 화면과 업무 로직은 한 번만 고치면 양쪽에 반영돼요. 대신 다른 일이 두 가지 생겨요.

프레임워크 자체를 올리는 일. 크로스플랫폼 앱은 Flutter나 React Native 같은 도구 위에서 돌아가요. 스토어의 새 요건을 맞추려면 이 도구부터 새 버전으로 올려야 하는 경우가 많아요. Flutter는 분기에 한 번꼴로 안정 버전을 내 왔어요. React Native는 2025년 10월에 나온 0.82 버전부터 예전 구조를 걷어냈다고 기술 매체들이 전해요. 예전 구조로 만든 앱은 새 구조로 옮기는 작업을 먼저 해야 다음 버전으로 갈 수 있어요.

라이브러리를 기다리는 일. 결제, 지도, 푸시 알림, 본인인증은 대부분 남이 만든 라이브러리를 붙여서 써요. 16KB 요건처럼 기기 깊은 곳과 닿는 규칙은 이 라이브러리가 먼저 대응해야 해요. 관리가 끊긴 라이브러리를 쓰고 있었다면 다른 걸로 바꿔 끼워야 하고요.

애플 요건이 나왔을 때도 같았어요. 크로스플랫폼 빌드 도구 Expo는 자사 블로그에서 예전 버전을 쓰는 앱이 새 Xcode로 빌드하는 방법을 따로 안내했고, 모든 버전이 호환되지는 않는다고 밝혔어요.

3. 네이티브는 두 배로 드나요

두 번 하는 건 맞아요. 다만 두 배는 아니에요.

네이티브는 애플과 구글이 직접 만든 도구로 개발해요. 새 요건이 나올 때 그 도구는 이미 준비돼 있어요. 기다릴 중간 단계가 없어요. 대신 iOS 담당과 안드로이드 담당이 각자 고치고 각자 시험해요.

그리고 마감이 서로 달라요. 올해 애플은 4월, 구글은 8월이었어요. 네이티브 팀은 이걸 두 번의 작은 일로 나눠서 해요. 크로스플랫폼 팀은 한 번 올릴 때 양쪽을 같이 시험해야 해서 한 번의 일이 커져요.

자사 실무 기준 — 방식별로 일이 생기는 자리

	크로스플랫폼	네이티브
화면·로직 수정	1번	2번(OS별)
프레임워크 버전 올리기	있어요	없어요
라이브러리 대응 기다리기	자주 있어요	가끔 있어요
새 OS 기능을 쓰는 시점	도구가 지원한 뒤	나오는 즉시
시험 범위	한 번에 양쪽 전부	OS별로 나눠서
필요한 사람	한 팀	OS별 담당

(자사 실무 기준이에요. 앱에 붙은 연동의 수에 따라 달라져요.)

어느 쪽이 싸다고 잘라 말하기는 어려워요. 연동이 적고 화면 위주인 앱은 크로스플랫폼이 가벼워요. 카메라, 블루투스, 위치를 깊게 쓰는 앱은 기다리는 비용이 커져서 차이가 줄어요.

4. 한 해에 얼마를 잡아야 할까요

금액은 앱마다 달라서 계산하는 틀을 드릴게요.

공식 외부 기준 — 사람 값

한국소프트웨어산업협회(KOSA)가 공표한 2025년 적용 평균임금은 응용SW 개발자가 월 약 694만 원이에요(4대 보험 회사 부담분과 퇴직급여 충당금 포함). 2026년 적용분은 전체 평균이 4.7% 올랐다고 공표됐어요. 실제 외주 단가는 여기에 회사 운영비가 더해져요.

자사 실무 기준 — 해마다 오는 일

해마다 오는 일	횟수	값을 키우는 것
구글 타깃 API 올리기	연 1회	권한을 많이 쓰는 앱일수록
애플 새 SDK로 다시 빌드	연 1회	화면 구성이 복잡할수록
새 OS 버전에서 화면 깨짐 점검	연 1～2회	지원 기기가 많을수록
프레임워크 버전 올리기(크로스플랫폼)	연 1～2회	미룬 버전이 많을수록
붙여 쓰는 라이브러리 교체	비정기	연동이 많을수록
스토어 정책 문구·개인정보 표시 변경	비정기	수집하는 정보가 많을수록

(자사 실무 기준 예시예요. 횟수는 최근 2년의 스토어 요건을 기준으로 잡았어요.)

앱 개발 외주 비용을 견적받을 때 이 표를 그대로 보내서 “이 가운데 유지보수 계약에 포함된 건 몇 번째까지인가요”라고 물어보세요. 공공 SW는 유지관리 요율이 10%대에 머물러 왔다는 보도가 있었어요(전자신문 2021년 7월). 요율 계산은 유지보수 비용은 얼마를 잡아야 할까요에 정리해 뒀어요. 다만 요율이 같아도 위 표의 일이 들어 있는 요율과 빠진 요율은 다른 값이에요.

5. 미루면 어떻게 되나요

올해 한 번 건너뛰면 내년에 두 해 치를 한꺼번에 해야 해요. 문제는 두 해 치가 두 배로 끝나지 않는다는 거예요. 중간 버전에서 바뀐 것들이 서로 엮여서, 무엇 때문에 깨졌는지 찾는 시간이 붙어요.

더 곤란한 건 시점이에요. 밀린 대응은 대개 급한 수정을 올려야 하는 날 드러나요. 결제 오류를 고쳐서 올리려는데 스토어가 “먼저 타깃부터 올리세요”라고 막아요. 하루면 될 수정이 2주짜리 일이 돼요.

흔한 실수 유지보수 계약을 “버그가 나면 고쳐 주는 계약”으로만 이해하는 거예요. OS와 스토어 대응은 버그가 아니에요. 앱이 잘못한 게 없는데도 생기는 일이라 하자보수에 안 들어가요. 계약서에 따로 적지 않으면 양쪽 다 “그건 우리 범위가 아니다”라고 말하게 돼요.

무상 하자보수가 어디까지인지는 무상 하자보수는 몇 개월이고 어디까지일까요에 있어요.

6. 견적과 계약에는 무엇을 적어야 할까요

계약 전에 문장으로 정해 둘 여섯 가지예요.

1. 연 1회 타깃 API 올리기가 유지보수에 포함인가요. 포함이 아니면 건당 얼마인가요
2. 애플의 새 SDK 빌드 요건 대응이 포함인가요
3. 크로스플랫폼이라면 프레임워크 버전을 얼마나 자주 올리나요. “요청이 있을 때”가 아니라 주기로 적어요
4. 붙여 쓰는 라이브러리 목록을 문서로 받나요. 어떤 걸 쓰는지 알아야 바꿀 때 값을 따질 수 있어요
5. 스토어에서 정책 안내 메일이 오면 누가 받나요. 개발자 계정이 발주자 명의여야 발주자가 받아요
6. 지원하는 OS 최저 버전은 어디까지인가요. 낮게 잡을수록 시험할 기기가 늘어요

5번은 생각보다 자주 문제가 돼요. 계정이 개발사 이름으로 돼 있으면 마감 안내가 발주자에게 오지 않아요. 계정 명의는 앱 출시는 외주 범위일까요에서 다뤘어요.

운영사 Tip 유지보수 계약서에 “매년 9월, 스토어 요건 점검 1회”처럼 날짜를 박아 두세요. 구글의 마감이 최근 몇 년 8월 말이었고 새 OS도 가을에 나와요. 날짜가 있으면 예산도 그 달에 잡히고, 누가 먼저 말을 꺼낼지 눈치 볼 일도 없어요.

7. 기기와 닿는 앱은 무엇이 더 붙나요

저희가 만든 앱 가운데 OS 차이로 애를 먹은 사례가 있어요.

[유통 · App] 지구조각가 건설장비 쇼핑 플랫폼 — 현장에서 쓰는 작업일보에 서명을 받는 기능이 있어요. 아이폰과 안드로이드의 픽셀 차이 때문에 서명 영역이 어긋나는 문제가 있었어요. 이런 기능은 OS가 올라가 화면 처리 방식이 바뀔 때마다 다시 확인해야 해요. 지금 이 작업일보는 10,973건이 쌓였고 현장에서 계속 쓰이고 있어서, 한 번 어긋나면 바로 업무가 멈춰요.

[제조 · App] 코닥 인스턴트 프린터 연동 앱 — 블루투스로 인화기와 연결하는 앱이에요. 가장 어려웠던 건 수많은 휴대폰 기종과의 연결과 오류 처리였어요. 블루투스 권한은 OS 버전이 올라갈 때 자주 바뀌는 영역이라, 타깃을 올리는 해마다 연결 시험을 다시 해야 하는 앱이에요.

앱만 그런 것도 아니에요. Windows와 Mac에서 함께 돌아가는 캐논코리아 펌웨어 유틸리티 같은 GUI 소프트웨어 외주 개발에서도 가장 큰 부담은 버전과 장치 조합의 테스트였어요.

기기와 닿는 앱이라면 4번 표의 “새 OS 화면 깨짐 점검”에 기기 연결 시험을 별도 줄로 넣으세요. 화면만 보는 점검으로는 안 잡혀요.

8. 운영까지 해 본 회사는 무엇을 먼저 볼까요

저희는 자체 SaaS 4종을 직접 운영해요. 운영하면서 배운 건 초기 기능보다 운영 구조가 더 자주 비용을 바꾼다는 점이에요. OS와 스토어 대응이 딱 그래요. 만들 때는 보이지 않다가 1년 뒤에 청구서로 와요.

그래서 저희는 개발 방식을 고를 때 같은 기능 수보다 출시 뒤 얼마나 자주 손이 가는 앱인지부터 봐요. 화면 위주의 앱이면 크로스플랫폼으로 가볍게 가고, 기기와 깊게 닿는 앱이면 대응을 기다리지 않아도 되는 쪽을 먼저 따져요. 개발 외주 비용을 줄이려고 고른 방식이 3년 뒤 운영비를 키우는 일을 여러 번 봤기 때문이에요.

“개발 외주 업체 추천해 주세요”라는 질문을 받으면 이것도 같이 물어보시라고 권해요. 그 업체가 만든 앱 가운데 3년 넘게 스토어에 살아 있는 앱이 있는지요. 있다면 해마다 오는 일을 치러 본 곳이에요.

저희는 10년 넘게 50개 이상의 프로젝트를 만들었고 롯데·캐논 같은 곳과도 함께해 왔어요. 이미 출시한 앱에 스토어 안내 메일이 와서 막막하다면, 방향이 정해지지 않았어도 괜찮아요. 지금 앱이 어느 요건까지 밀려 있는지부터 같이 확인해 볼까요 →

9. 자주 묻는 질문 (FAQ)

앱을 안 고치고 그대로 두면 어떻게 되나요?

바로 사라지지는 않아요. 다만 구글플레이에서는 새 OS 기기의 신규 사용자에게 보이지 않게 될 수 있어요. 그리고 급한 수정을 올리려는 날 밀린 대응을 한꺼번에 해야 해요.

크로스플랫폼이면 OS 대응을 한 번만 하면 되나요?

화면과 로직은 한 번이에요. 대신 프레임워크를 올리는 일과 라이브러리를 기다리는 일이 따로 생겨요. 방식의 차이는 웹앱·네이티브앱·하이브리드, 무엇이 어떻게 다를까요를 참고하세요.

앱 개발 외주 과정을 알려주세요. 출시 뒤 대응은 어느 단계에 들어가나요?

기획, 디자인, 개발, 검수, 스토어 출시 다음이 유지보수예요. OS와 스토어 대응은 유지보수에 들어가는데 계약서에 따로 안 적으면 빈칸이 돼요. 첫해에 나가는 돈은 앱 견적서에 없는 첫해 비용에 모아 뒀어요.