구글 플레이에 올라가 있는 안드로이드 앱은 2026년 8월 31일부터 Android 16(API 36)을 타깃으로 해야 업데이트를 낼 수 있습니다. 연장을 신청했다면 그 기한도 2026년 11월 1일로 이미 지났습니다. 아직 targetSdk를 올리지 못했다면 지금은 업데이트 자체가 막혀 있는 상태라서, 급한 버그 수정도 배포할 수 없습니다. 이 글에서는 API 36으로 올릴 때 실제로 화면과 동작이 어떻게 달라지는지, 그리고 저희가 작업할 때 어떤 순서로 확인하는지를 적었습니다.

일정부터 다시 확인해 보겠습니다

Android Developers의 타깃 API 요건 문서에 따르면 2026년 8월 31일부터 새 앱과 앱 업데이트는 Android 16(API 36) 이상을 타깃으로 해야 구글 플레이에 제출할 수 있습니다. Wear OS와 Android Automotive OS 앱은 API 35, Android TV와 Android XR 앱은 API 34가 기준입니다. 이미 출시된 앱도 API 35 미만이면, 앱이 타깃으로 한 버전보다 새 안드로이드 기기에서는 새 사용자에게 보이지 않습니다.

시간이 더 필요한 경우 Play Console에서 2026년 11월 1일까지 연장을 신청할 수 있었습니다. 지금 날짜 기준으로는 연장 기간도 끝났으니, 남은 선택지는 작업을 마치고 API 36 빌드를 올리는 것뿐입니다. 사내 직원만 쓰는 비공개 배포 앱은 이 요건에서 빠집니다.

자주 받는 질문이 "그럼 앱이 내려가나요?"인데, 그렇지는 않습니다. 이미 설치한 사람은 계속 쓸 수 있습니다. 문제는 업데이트를 못 낸다는 점입니다. 결제 SDK에서 장애가 나거나 서버 주소를 바꿔야 하는 상황이 오면 손쓸 방법이 없어집니다. 구글 플레이 정책 전반은 2026년 구글 플레이 정책 글에 따로 정리해 두었습니다.

엣지 투 엣지를 더는 끌 수 없습니다

엣지 투 엣지는 앱 화면이 상단 상태 표시줄과 하단 내비게이션 바 뒤까지 꽉 차게 그려지는 방식입니다. Android 15를 타깃으로 할 때 이미 기본값이 됐지만, 그때는 windowOptOutEdgeToEdgeEnforcement 속성으로 잠시 피해 갈 수 있었습니다.

Android 16 동작 변경 문서를 보면 API 36을 타깃으로 하는 앱이 Android 16 기기에서 돌 때 이 속성은 무시됩니다. 작년에 이 속성으로 급하게 막아 둔 앱이라면 이번에 그대로 드러납니다. 실제로 많이 보는 증상은 상단 툴바 제목이 시계·배터리 아이콘과 겹치는 것, 하단 탭 바나 "결제하기" 버튼이 제스처 바 밑으로 내려가 눌리지 않는 것입니다.

고치는 방법은 화면마다 시스템 영역의 크기(인셋)를 받아서 그만큼 여백을 주는 것입니다. Compose라면 WindowInsets 관련 Modifier를, 기존 View 방식이라면 ViewCompat.setOnApplyWindowInsetsListener를 씁니다. 화면 수가 많은 앱은 공통 레이아웃을 한 곳에서 처리하도록 정리하는 편이 결국 빠릅니다. 웹뷰 앱은 웹 쪽 CSS에서 안전 영역을 처리하거나, 네이티브에서 웹뷰 자체에 여백을 주는 방식 중 하나를 고르게 됩니다.

뒤로 가기 처리 방식이 바뀝니다

예측형 뒤로 가기(predictive back)는 뒤로 가기 제스처를 하는 도중에 이전 화면이나 홈 화면을 미리 보여 주는 기능입니다. Android 16 동작 변경 문서에 따르면 API 36 타깃 앱이 Android 16 이상 기기에서 실행되면 이 애니메이션이 기본으로 켜지고, onBackPressed가 호출되지 않으며 KEYCODE_BACK 키 이벤트도 전달되지 않습니다.

API 36 전후 뒤로 가기

API 35 이하

• onBackPressed 불림
• KEYCODE_BACK 전달
• 예측형 애니메이션 꺼짐

API 36

• onBackPressed 안 불림
• KEYCODE_BACK 없음
• 예측형 애니메이션 기본 켜짐

이게 생각보다 영향이 큽니다. "뒤로 가기를 한 번 더 누르면 종료됩니다" 같은 안내, 작성 중인 글이 있을 때 띄우는 "나가시겠습니까?" 확인 창, 웹뷰에서 뒤로 가기를 누르면 웹 페이지 이전으로 가게 만든 처리가 대부분 onBackPressed를 덮어써서 만들어져 있습니다. 이런 코드가 그냥 동작하지 않게 됩니다.

정석은 OnBackPressedDispatcher(Compose는 BackHandler)로 옮기는 것입니다. 당장 시간이 없다면 매니페스트에서 android:enableOnBackInvokedCallback을 false로 두어 임시로 빠질 수 있다고 문서에 나와 있습니다. 다만 임시 방편이니, 다음 업데이트 일정에 이전 작업을 꼭 넣어 두시길 권합니다.

태블릿과 폴더블에서 세로 고정이 풀립니다

이번 변경 중 기획·디자인 쪽까지 영향을 주는 것이 이 부분입니다. Android 16 동작 변경 문서에 따르면 API 36을 타깃으로 하면 화면의 가장 짧은 폭이 600dp 이상인 기기, 즉 태블릿이나 펼친 폴더블에서는 화면 방향 고정, 크기 조절 제한, 화면 비율 제한이 무시됩니다. 매니페스트의 screenOrientation="portrait", resizeableActivity="false", maxAspectRatio 같은 설정이 큰 화면에서는 효과가 없어지고, 앱이 창 전체를 채웁니다.

큰 화면에서 볼 것

• 버튼이 옆으로 길게 늘어나지 않는지
• 이미지가 잘리지 않는지
• 하단 고정 영역이 가운데 뜨지 않는지
• 회전 후 입력 내용이 남아 있는지
• 분할 화면에서도 화면이 맞는지

휴대폰 세로 화면만 생각하고 만든 앱은 큰 화면에서 버튼이 옆으로 길게 늘어나거나, 이미지가 잘리거나, 하단 고정 영역이 화면 가운데쯤 떠 보이는 일이 생깁니다. 회전이 허용되면 화면이 다시 만들어지면서 입력하던 내용이 사라지는 문제도 같이 나옵니다. 회원가입 중간에 기기를 돌렸더니 처음부터 다시 입력해야 하는 식입니다.

예외도 있습니다. android:appCategory로 게임이라고 표시된 앱, 사용자가 기기 설정에서 앱 기본 비율을 직접 고른 경우, 폭이 600dp보다 작은 화면은 해당되지 않습니다. 준비가 덜 됐다면 PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY 속성으로 화면 단위나 앱 전체를 임시로 빼 둘 수 있습니다. 그런데 문서에 이 예외는 API 37을 타깃으로 할 때는 적용되지 않는다고 분명히 적혀 있습니다. 내년에 다시 같은 문제를 만나지 않으려면 이번에 큰 화면 레이아웃을 잡아 두는 편이 낫습니다.

그 밖에 앱 성격에 따라 확인할 것

모든 앱에 해당하지는 않지만, 업종에 따라 놓치기 쉬운 변경이 몇 가지 더 있습니다.

• 심박수 같은 신체 센서를 쓰는 앱: 기존 BODY_SENSORS 권한 대신 READ_HEART_RATE 같은 세분화된 헬스 권한을 요청해야 합니다. 모바일 앱은 개인정보처리방침을 보여 주는 화면도 선언해야 하고, 이걸 빠뜨리면 권한이 회수된다고 문서에 나와 있습니다.
• 블루투스 기기를 연결하는 앱: 페어링 정보가 깨졌을 때 받을 수 있는 새 인텐트(ACTION_KEY_MISSING, ACTION_ENCRYPTION_CHANGE)가 생겼습니다. 제조사마다 이 신호를 보내는 방식이 다를 수 있다고 하니, 실제 기기로 연결 끊김과 재연결을 다시 확인해야 합니다.
• 주기 작업을 scheduleAtFixedRate로 돌리는 앱: 앱이 멈춰 있던 동안 놓친 실행이 돌아왔을 때 전부 몰아서 실행되지 않고 한 번만 실행됩니다.
• 사진 일부만 허용하는 경우: 사용자가 일부 사진만 접근 허용을 고르면, 앱이 직접 만든 사진은 선택 화면에 미리 체크된 상태로 나옵니다.

헬스케어나 BLE 기기 연동 앱은 이 부분이 실제 장애로 이어지기 쉬워서, 저희는 반드시 실물 기기를 놓고 테스트합니다. 관련 경험은 BLE·IoT 앱 개발 페이지에도 정리해 두었습니다.

저희가 쓰는 점검 순서

targetSdk 숫자를 바꾸기 전에 먼저 하는 일이 있습니다. 앱에 들어 있는 외부 SDK 목록을 뽑고, 각 SDK가 API 36을 지원하는 버전이 나왔는지 확인하는 것입니다. 결제, 본인인증, 광고, 푸시, 지도 SDK 중 하나라도 대응이 늦으면 앱 코드를 아무리 고쳐도 일정이 밀립니다.

API 36 점검 순서

1. SDK 목록 확인외부 SDK의 API 36 지원 버전 확인
2. 버전 올리기targetSdk 36, AGP 등 정리
3. 변경 위치 검색엣지·뒤로 가기·방향 고정 코드 목록화
4. 큰 화면 확인회전, 창 크기, 분할 화면까지
5. 하단 버튼 확인다크 모드, 큰 글자, 내비게이션별
6. 단계적 배포비공개 테스트 후 프로덕션 배포

그다음 순서는 대체로 이렇습니다.

1. compileSdk와 targetSdk를 36으로 올리고 Android Gradle Plugin, Kotlin, AndroidX 라이브러리 버전을 맞춥니다.
2. Android Studio의 Android SDK Upgrade Assistant를 열어 버전별 확인 항목을 대조합니다.
3. windowOptOutEdgeToEdgeEnforcement, onBackPressed, screenOrientation 사용 위치를 코드 전체에서 검색해 목록을 만듭니다.
4. 휴대폰 실기기와 함께 태블릿 또는 폴더블 에뮬레이터에서 전체 화면을 한 번씩 열어 봅니다. 회전, 창 크기 변경, 분할 화면까지 해 봅니다.
5. 다크 모드, 큰 글자 설정, 3버튼 내비게이션과 제스처 내비게이션 양쪽에서 하단 버튼이 가려지지 않는지 봅니다.
6. 비공개 테스트 트랙에 먼저 올려 크래시가 없는지 확인한 뒤 프로덕션에 단계적으로 배포합니다.

화면이 수십 개인 앱이라면 3번에서 나온 목록이 곧 작업량입니다. 저희 경험으로는 엣지 투 엣지와 큰 화면 대응이 시간을 가장 많이 잡아먹고, 뒤로 가기 이전은 코드 위치만 찾으면 비교적 빨리 끝납니다. 출시 전 전체 점검 항목은 앱 출시 전 QA 글을 함께 보시면 됩니다.

자주 묻는 질문

연장 신청 기한을 놓쳤는데 다른 방법이 있나요?

공식 문서에 나와 있는 연장 기한은 2026년 11월 1일까지였고, 그 이후의 추가 연장 방법은 안내되어 있지 않습니다. 지금은 API 36 빌드를 만들어 올리는 것이 유일한 길입니다. 급한 수정이 있다면 위의 임시 예외 속성을 활용해 범위를 줄여서 먼저 배포하고, 남은 화면을 이어서 고치는 방식을 권합니다.

크로스플랫폼(Flutter, React Native)으로 만든 앱도 해당되나요?

네, 똑같이 적용됩니다. 결과물이 안드로이드 앱이기 때문입니다. 프레임워크 버전을 API 36을 지원하는 버전으로 올려야 하고, 엣지 투 엣지와 뒤로 가기 처리는 프레임워크와 플러그인 쪽 대응 상황도 같이 확인해야 합니다.

태블릿 사용자가 거의 없는데도 큰 화면 대응을 해야 하나요?

타깃을 올리는 순간 동작은 바뀌니, 최소한 깨지지 않게는 만들어야 합니다. 태블릿 전용 화면을 따로 디자인할 필요까지는 없고, 내용이 화면 가운데 적당한 폭으로 놓이고 회전해도 입력 내용이 유지되는 정도면 대부분 충분합니다.

targetSdk를 올리면 오래된 기기 사용자는 앱을 못 쓰게 되나요?

아닙니다. 지원하는 가장 낮은 버전은 minSdk가 정하고, targetSdk는 새 OS 동작을 받아들이겠다는 표시입니다. 둘은 별개라서 targetSdk를 올려도 기존 지원 기기는 그대로 유지할 수 있습니다.

API 36 대응이 막혀 업데이트를 못 내고 계시다면 상담 페이지로 앱 현황을 보내 주세요. 사용 중인 SDK와 화면 구성을 보고 작업 범위부터 짚어 드리겠습니다.