target API를 올렸더니 화면이 잘리고 뒤로가기가 안 먹는다면

숫자 하나만 바꾸면 되는 줄 알았는데

Google Play는 매년 target API 요구 수준을 올립니다. 콘솔에 경고가 뜨고, 팀은 빌드 설정에서 숫자를 한 칸 올립니다. 여기까지는 오 분이면 끝납니다.

문제는 그다음입니다. 빌드해서 실기기에 올려 보면 화면 위아래가 시스템 UI에 먹히거나, 뒤로가기 버튼이 먹통이거나, 태블릿에서 고정해 둔 화면 방향이 풀려 있습니다.

target API를 올린다는 건 "이 앱은 새 동작 규칙을 따르겠다"고 선언하는 일이기 때문입니다. 숫자를 바꾸는 순간 그동안 면제받던 규칙들이 한꺼번에 적용됩니다.

그리고 이건 미뤄도 되는 숙제가 아닙니다. 기한을 넘기면 업데이트 자체를 올릴 수 없게 됩니다.

아래는 그중 Unity 게임에서 실제로 티가 나는 것들입니다.

요구 수준과 기한은 해마다 바뀝니다. 현재 기준은 반드시 Google Play target API 요구사항에서 직접 확인하세요. 동작 변경의 전체 목록은 Android 동작 변경 문서에 있습니다. 이 글에 적는 건 올릴 때 무엇을 확인해야 하는가입니다.

미루면 어떻게 되나

이 마감에는 기한이 정해져 있고, 넘기면 두 가지가 동시에 일어납니다.

1. 업데이트를 올릴 수 없습니다. 신규 앱과 앱 업데이트는 요구 수준을 만족해야 제출됩니다. target API를 올리기 전까지는 어떤 업데이트도 못 냅니다. 콘텐츠 패치도, 크래시 수정도, 보안 긴급 패치도 마찬가지입니다.

2. 신규 유저에게 닿지 않습니다. 요구 수준에 못 미치는 앱은 자기 target API보다 높은 Android 버전을 쓰는 기기에서 새로 설치할 수 없게 됩니다. 시간이 갈수록 그런 기기의 비중이 늘어나므로 신규 유입이 서서히 끊깁니다.

정확히 해 두면 앱이 스토어에서 삭제되는 것은 아닙니다. 이미 설치한 유저는 계속 플레이할 수 있습니다. 다만 새 유저는 들어오지 못하고, 우리는 아무것도 고칠 수 없는 상태가 됩니다. 라이브 서비스에서는 이쪽이 더 곤란합니다. 문제가 생겨도 손을 쓸 수 없기 때문입니다.

기한을 놓쳤다면 콘솔에서 연장 신청 경로가 열려 있는지 확인하세요. 다만 연장은 시간을 버는 수단이지 면제가 아닙니다.

규칙은 두 갈래로 적용됩니다

Android의 동작 변경에는 성격이 다른 둘이 섞여 있습니다. 이걸 구분하면 대응 범위가 훨씬 좁아집니다.

아래에서 다루는 건 두 번째 갈래입니다. 우리가 스스로 켠 것들이라, 무엇을 켰는지 알고 확인하면 됩니다.

Unity 게임에서 실제로 티가 나는 것들

1. 화면이 시스템 UI에 먹힌다 — 엣지 투 엣지

앱이 화면 전체에 그려지고, 상태바와 내비게이션 바가 그 위에 겹칩니다. 예전에는 이 동작을 끄는 속성이 있었지만 지금은 그 회피 수단이 막혔습니다.

게임에서는 UI 가장자리부터 티가 납니다. 좌우 상단의 재화 표시, 하단의 버튼 열처럼 화면 끝에 붙여 둔 것들이 상태바나 제스처 바에 가립니다.

Unity에서 확인할 곳은 Screen.safeArea입니다. 이 값은 시스템 UI를 뺀 실제 사용 가능 영역을 돌려주는데, 캔버스를 화면 전체(Screen.width, Screen.height) 기준으로 잡아 두면 이 차이만큼 어긋납니다. 노치가 있는 기기에 대응하면서 이미 처리해 둔 프로젝트라면 대체로 무사하고, 그 대응을 건너뛴 프로젝트가 여기서 걸립니다.

2. 뒤로가기가 예전처럼 오지 않는다 — 예측형 뒤로가기

onBackPressed()가 더 이상 호출되지 않고, 뒤로가기 키 이벤트도 예전 방식으로는 전달되지 않습니다.

Unity 게임은 안드로이드 뒤로가기를 흔히 KeyCode.Escape로 받아 처리합니다. 일시정지 메뉴를 열거나 이전 화면으로 돌아가는 코드가 여기에 걸려 있다면 반드시 실기기에서 확인해야 합니다. 매니페스트에서 예전 동작으로 되돌리는 플래그가 있지만, 그건 시간을 버는 수단이지 해결이 아닙니다.

3. 태블릿·폴더블에서 화면 방향 고정이 풀린다 — 그런데 게임은 예외

큰 화면에서는 매니페스트의 화면 방향, 크기 조절 불가, 화면비 제한 설정이 무시됩니다. 세로 고정으로 만든 게임이 태블릿에서 가로로 늘어날 수 있다는 뜻입니다.

여기에 게임 예외가 있습니다. 매니페스트에서 앱 카테고리를 게임으로 선언하면 이 강제에서 빠집니다.

<application android:appCategory="game">
  <activity android:screenOrientation="portrait" />
</application>

Unity 프로젝트에서 이 속성이 빠져 있는 경우가 흔합니다. 대화면에서 레이아웃이 무너진다면 여기부터 확인하세요. 한 줄로 끝나는 문제일 수 있습니다.

4. 주기 작업이 밀렸을 때 몰아서 실행되지 않는다 — 주로 플러그인 쪽

일정 간격으로 반복 예약한 작업이 기기 절전 등으로 여러 번 건너뛰어졌을 때, 예전에는 밀린 횟수만큼 한꺼번에 실행됐지만 이제 한 번만 실행하고 넘어갑니다.

먼저 범위를 좁히겠습니다. 이건 Unity C# 코드보다 안드로이드 네이티브 쪽 이야기입니다. 게임에서 흔한 오프라인 보상 계산은 대개 복귀 시점에 시각을 비교해 처리하므로 여기에 해당하지 않습니다.

걸릴 수 있는 건 네이티브 플러그인이나 서드파티 SDK가 내부에서 반복 작업을 돌리는 경우입니다. 분석 이벤트 전송, 푸시 토큰 갱신, 주기적 동기화 같은 것들이 그렇습니다. 대개 SDK 공급자가 대응하므로, 우리가 할 일은 해당 SDK를 목표 API를 지원하는 버전으로 올렸는지 확인하는 것입니다.

라이브 게임이면 여기서 한 겹 더 있습니다

아직 출시 전이라면 위 항목만 고치고 빌드하면 됩니다. 이미 서비스 중이라면 사정이 다릅니다.

target API 상향은 재빌드하고, 심사받고, 유저가 업데이트를 받아야 끝납니다. 마감이 정해져 있으니 심사 기간을 역산해서 일정을 잡아야 하고, 그동안 기존 빌드는 그대로 돌아갑니다.

이 구조는 엔진 보안 권고를 받았을 때와 똑같습니다. 그때와 마찬가지로, 일정을 잡기 전에 지금 그 빌드를 다시 만들 수 있는지부터 확인하세요. 빌드 머신이 달라졌거나 서명 키에 접근할 사람이 없으면 일정 자체가 성립하지 않습니다.

보안 쪽에서 함께 볼 것

target API를 올리는 김에 확인해 두면 좋은 것들이 있습니다. 어차피 다시 빌드하고 다시 심사받아야 하기 때문입니다.

• 서명 체계가 그대로인가 — 다시 빌드하는 과정에서 서명 키와 절차가 예전과 같은지 확인합니다.
• 플러그인과 SDK가 목표 API를 지원하는가 — 네이티브 바이너리를 포함한 것들이 특히 그렇습니다. 공급자 문서에서 어느 버전부터 지원하는지와 그 버전이 언제 나왔는지를 함께 보세요. 오래 손대지 않은 플러그인이 발목을 잡는 일이 잦습니다.
• 빌드에 남으면 안 되는 것이 늘지 않았는가 — 대응하느라 넣어 둔 임시 로그나 디버그 플래그가 그대로 나가지 않도록 합니다.
• 변조 판별 기준을 다시 만들었는가 — 빌드가 바뀌면 정상 빌드의 기준도 함께 바뀝니다. 리패키징 판별은 유니티 MOD APK 방지 가이드에서 다뤘습니다.

점검 항목

올리기 전

• 현재 요구 수준과 기한을 공식 문서에서 확인했다.
• 지금 스토어에 있는 빌드가 어느 target API로 만들어졌는지 안다.
• 사용 중인 플러그인과 SDK가 목표 버전을 지원하는지 확인했다.

올린 뒤 실기기에서

• 화면 가장자리 UI가 시스템 UI에 가리지 않는다.
• 뒤로가기로 일시정지·이전 화면 이동이 정상 동작한다.
• 태블릿·폴더블에서 화면 방향과 레이아웃이 의도대로 유지된다.
• 반복 작업을 도는 플러그인·SDK가 목표 API 버전에서 정상 동작한다.

출시 절차

• 심사 기간을 역산해 일정을 잡았다.
• 서명 체계와 빌드 재현성을 함께 확인했다.
• 임시로 넣은 로그·플래그를 제거했다.

OZero Security를 쓰고 있다면

맡지 않는 영역

• 스토어 정책 대응을 대신하지 않습니다. target API 상향, 심사 일정, 매니페스트 설정은 팀의 작업입니다.
• 위 동작 변경으로 생긴 UI·입력 문제도 게임 코드 쪽 몫입니다.

맡는 영역

• 네이티브 라이브러리를 포함하는 SDK인 만큼, Google Play가 요구하는 API 수준에 맞춰 호환성을 유지하는 것은 저희 몫입니다. 현재 어느 범위까지 지원하는지는 매뉴얼이나 문의로 확인하실 수 있습니다.
• 다시 빌드한 결과물에 대해 실행 파일 바이너리 변조, 디버거 부착과 후킹, 에뮬레이터·루팅 같은 비신뢰 실행 환경을 식별해 우회 난이도를 높입니다.

정책 대응으로 어차피 재빌드와 재심사를 하는 시점이라면, 보호 적용을 같은 사이클에 넣는 편이 비용이 덜 듭니다. 나중에 따로 하면 심사를 한 번 더 받아야 합니다.

결론: 올라가는 건 숫자가 아니라 동작 규칙입니다

target API 상향을 빌드 설정 변경으로 생각하면 실기기에서 놀라게 됩니다. 실제로는 그동안 면제받던 동작 규칙을 한꺼번에 받아들이는 선언입니다.

그래서 순서는 이렇습니다. 숫자를 올리고, 실기기에서 화면·입력·대화면을 직접 보고, 그다음에 심사 일정을 잡습니다. 에뮬레이터만 보고 넘어가면 앞의 세 가지는 잘 드러나지 않습니다.

그리고 이 마감은 매년 옵니다. 이번에 확인한 항목을 기록해 두면 내년에는 훨씬 짧게 끝납니다.

다음 단계

1. 보호 범위 확인하기 — 플랫폼별 지원 사양과 플랜(Standard / Pro)별 방어 범위를 확인하세요.
2. 빠른 통합 시작하기 — 패키지 임포트와 설정 절차는 통합 가이드에 있습니다.
3. 기술 문의 및 상담 — 지원 대상 API 수준이나 재빌드 일정에 관해 문의해 주세요.