TWA 앱이 Google Play에서 거부? WebView로 전환

개인 개발자가 겪는 거부 중에서도 가장 답답한 패턴 중 하나입니다. 테스터는 실제로 썼습니다. 인원도 12명이었습니다. 14일도 지났습니다. 그런데도 Google은 "your testers were not engaged enough."(테스터 참여가 충분하지 않음)라고 돌려보냅니다. 앱을 Trusted Web Activity(TWA)나 PWA 래퍼로 만들었다면 우연이 아닙니다. 7,400개가 넘는 앱을 온보딩하며 본 결과, 래퍼형 빌드는 이 유형의 거부에 표준 네이티브·WebView보다 훨씬 자주 걸립니다. 이 가이드에서는 이유, 중요한 아키텍처 차이, 이미 쌓은 테스트 일수를 버리지 않고 WebView로 전환하는 절차를 설명합니다.

TWA 앱이 비공개 테스트에서 거부되기 쉬운 이유

Trusted Web Activity는 화면을 자체 앱 안에서 그리는 대신, Chrome의 Custom Tabs 표면을 통해 웹사이트를 렌더링합니다. 사이트나 PWA를 설치 가능한 형태로 만드는 빠른 방법이며, 이미 출시된 많은 앱에서는 문제없이 동작합니다. 문제는 개인 개발자 계정이 프로덕션 액세스 전에 필수인 14일 비공개 테스트 요건을 넘어야 할 때 특히 드러납니다.

7,400개가 넘는 앱의 과정을 도우며 본 결과, TWA·PWA 래퍼 빌드는 테스터가 매일 실제로 써도 표준 네이티브 앱보다 "testers were not engaged"(테스터 참여 부족) 거부에 훨씬 자주 걸립니다. 패턴이 일관되어, 아직 14일 비공개 테스트를 넘어야 하는 앱에는 TWA를 권하지 않습니다.

TWA란 무엇이며 어떻게 구축하나요?

거부에 대응하기 전에 무엇을 게시했는지 정확히 이해해야 합니다. Trusted Web Activity는 본질적으로 실제 브라우저 엔진에서 웹사이트를 전체 화면으로 실행하는 Android 앱입니다. 주소 표시줄과 브라우저 UI가 없어 사용자는 웹페이지를 보고 있다는 사실을 알기 어렵습니다. 겉으로는 네이티브 앱처럼 보이고 작동하지만, 내부에서는 실제 웹사이트가 실행됩니다.

TWA는 보통 Google의 Bubblewrap CLI 또는 PWABuilder로 생성하며, 둘 다 Google의 androidbrowserhelper 라이브러리를 기반으로 합니다. 도구에 URL을 지정하면 Android 프로젝트가 만들어지고, 서명한 뒤 AAB를 Google Play에 업로드합니다.

개발자가 TWA를 선택하는 이유

거부로 이어질 수 있는 절충점

TWA를 저렴하게 만드는 특성은 비공개 테스트에서는 약점이 될 수 있습니다.

• 인터넷이 필요합니다. 사이트를 보여 주는 창이므로 PWA에 탄탄한 오프라인 지원이 없다면 연결이 약할 때 앱도 불안정해집니다.
• Play Store 거부 위험이 있습니다. 최소 기능 및 재패키징 콘텐츠 정책은 "래퍼 안의 웹사이트일 뿐인" 앱을 대상으로 합니다. 실제 네이티브 기능이 없는 TWA는 특히 신규 제출에서 거부되거나 삭제될 수 있습니다. 푸시 알림, 오프라인 모드, 카메라, 공유 대상 같은 네이티브 기능을 추가해야 정책 기준에 대응할 수 있습니다.
• 앞에서 설명한 참여 신호 문제도 있습니다. 개인 계정이 14일 비공개 테스트에서 "testers not engaged" 메시지를 반복해서 받는 이유입니다.

오해 바로잡기: TWA는 WebView가 아닙니다

많은 글이 잘못 설명하는 부분이며, 대응 방법을 바꾸는 차이이므로 정확히 알아야 합니다. TWA는 Android의 WebView 컴포넌트를 전혀 사용하지 않습니다.

TWA는 Custom Tabs 기반 엔진을 사용하므로 Chrome 브라우저와 같은 렌더링 엔진, JavaScript 엔진, 보안 샌드박스를 활용합니다. Chrome과 쿠키 및 저장소도 공유하므로 웹에서 로그인한 사용자의 상태가 유지되고, 브라우저 자동 업데이트와 전체 웹 플랫폼 지원도 받습니다. 일반적인 출시 앱에는 강력한 장점입니다. 그러나 화면이 자체 앱이 아니라 Chrome의 별도 프로세스에서 실행된다는 뜻이기도 합니다. 참여 신호가 약해지고 활성 사용자 수가 낮게 보이는 원인으로 관찰되는 구조입니다.

실행 흐름 단계별 보기

신뢰 확인: Digital Asset Links

Chrome은 앱이 Digital Asset Links로 웹사이트 소유권을 증명할 때만 주소 표시줄을 숨깁니다. 앱은 자신이 나타내는 웹사이트를 선언하고, 웹사이트는 앱의 package name과 서명 인증서 지문(SHA-256)이 들어 있는 /.well-known/assetlinks.json 파일을 제공해야 합니다.

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp.name",
    "sha256_cert_fingerprints": [
      "AB:CD:EF:...:99"  // your signing cert SHA-256
    ]
  }
}]

참여 신호 경로: TWA vs WebView

거부를 이해하는 가장 쉬운 방법은 테스터의 활동이 어디로 전달되는지 따라가는 것입니다. TWA의 화면은 앱에서 한 단계 떨어진 Chrome Custom Tabs 표면에 있습니다. WebView 앱에서는 같은 화면이 자체 애플리케이션 프로세스 안에서 실행되어 package name에 직접 연결됩니다. 이 차이가 활동 신호가 기록되는 강도를 바꿉니다.

TWA 식별 방법: 외부와 내부 확인

직접 또는 외주로 게시한 앱이 실제 TWA인지 확실하지 않다면, 먼저 눈으로 확인하고 APK나 연결된 기기에서 기술적으로 판별할 수 있습니다.

빠른 시각적 단서

• 웹사이트 자체이므로 웹사이트와 완전히 동일하게 작동합니다.
• 설정이 잘못되면 상단에 브라우저 주소 표시줄이 보입니다. 앞에서 설명한 assetlinks 오류의 확실한 단서입니다.
• Play Store에 앱 업데이트가 없어도 콘텐츠가 바뀝니다.

확실한 기술적 단서: APK 및 기기 검사

adb로 확인하기

연결된 기기 또는 에뮬레이터에서는 다음 두 명령으로 확인할 수 있습니다.

# Is it a TWA? Look for the delegation service:
adb shell dumpsys package <package.name> | grep -i DelegationService

# Which site does it wrap, and is the trust check passing?
adb shell pm get-app-links <package.name>
#   -> "verified"  = Digital Asset Links pass (fullscreen)
#   -> "1024"      = verification failed (address bar shows)

비공개 테스트용 TWA vs WebView 비교

두 아키텍처 모두 웹 콘텐츠를 감쌉니다. 14일 비공개 테스트에서 중요한 차이는 콘텐츠가 어디에서 실행되고 활동이 어떻게 연결되는지입니다. 한 주기 안에 프로덕션 단계로 나아가는 데 영향을 주는 항목을 비교합니다.

해결 방법: 표준 WebView 앱으로 다시 구축

TWA를 패치하거나 더 나은 신호를 끌어내려 하기보다 WebView 컴포넌트를 중심으로 앱을 다시 구축해 그 빌드를 게시하는 편이 깔끔합니다. 다음 세 가지 일반적인 방식은 모두 사이트를 자체 애플리케이션 안에서 불러옵니다.

최소 WebView 설정: 복사해서 사용

핵심은 간단합니다. JavaScript와 storage를 활성화한 WebView가 URL을 불러오고, 탐색을 Chrome으로 보내지 않고 앱 안에 유지하며, Google 검토에서 기대하는 뒤로 버튼 처리를 연결합니다. 언어 탭을 선택해 기본 코드를 복사하세요.

val webView = findViewById<WebView>(R.id.webview)
webView.settings.apply {
    javaScriptEnabled = true          // most sites need this
    domStorageEnabled = true          // localStorage / sessionStorage
    cacheMode = WebSettings.LOAD_DEFAULT
}

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.webViewClient = WebViewClient()
webView.loadUrl("https://yourwebsite.com")

// The exact back-button handler Google looks for
onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
    override fun handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack()
        } else {
            finish()
        }
    }
})

WebView webView = findViewById(R.id.webview);
WebSettings settings = webView.getSettings();
settings.setJavaScriptEnabled(true);      // most sites need this
settings.setDomStorageEnabled(true);      // localStorage / sessionStorage
settings.setCacheMode(WebSettings.LOAD_DEFAULT);

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.setWebViewClient(new WebViewClient());
webView.loadUrl("https://yourwebsite.com");

// The exact back-button handler Google looks for
getOnBackPressedDispatcher().addCallback(this, new OnBackPressedCallback(true) {
    @Override
    public void handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack();
        } else {
            finish();
        }
    }
});

# Wrap an existing web/PWA project in a native WebView shell
npm install @capacitor/core @capacitor/cli
npx cap init "YourApp" "com.yourapp.name"

# Point Capacitor at your live site (capacitor.config.ts)
#   server: { url: "https://yourwebsite.com", cleartext: false }

npm install @capacitor/android
npx cap add android
npx cap sync

# Capacitor handles back-button + DOM storage natively.
# Open in Android Studio to build a signed AAB:
npx cap open android

검토에 대비해 반드시 추가할 세 가지

loadUrl()만 호출하는 기본 WebView는 여전히 얇은 래퍼입니다. 다음 세 가지를 추가하면 실제 앱다운 동작을 갖추고 테스터에게 빈 화면이 보이지 않게 할 수 있습니다.

14일 카운트를 리셋하지 않고 전환하는 방법

이미 테스트가 진행 중이어도 처음부터 다시 시작할 필요는 없습니다. 같은 테스트 트랙과 같은 package name을 유지하면 앱 업데이트 후에도 14일 카운트가 이어집니다. 안전한 전환 순서는 다음과 같습니다.

WebView 앱도 여전히 "얇은 래퍼"인가요?

WebView가 모든 문제를 자동으로 해결한다고 생각하면 이 함정에 빠집니다. TWA에서 WebView로 전환하면 참여 신호 문제에 대응할 수 있지만 Google의 스팸 및 최소 기능 정책이 면제되지는 않습니다. 홈페이지를 틀 안에 넣은 것뿐인 WebView는 기본 TWA와 마찬가지로 얇은 래퍼로 거부될 수 있습니다.

두 문제를 서로 다른 두 관문으로 보면 이해하기 쉽습니다. 테스트 서비스나 WebView 재구축은 한 관문에 도움을 줄 수 있지만 다른 관문까지 대신 해결하지는 않습니다.

목표는 단순히 "TWA 대신 WebView"가 아니라, 독립적인 앱으로 인정받을 만큼 실제 가치와 네이티브 동작을 갖춘 WebView 앱입니다. 실무적으로는 다음이 필요합니다.

품질 거부를 일으키는 항목을 더 자세히 확인하려면 비공개 테스트가 반려되는 이유 가이드에서 참여 문제 외에 흔한 정책 및 검토 실패를 확인하세요.

앱이 TWA인지 모르시나요? 주문 즉시 확인합니다

직접 adb 명령을 실행하거나 APK를 살펴볼 필요가 없습니다. PrimeTestLab이 앱이 TWA인지 확인해 드립니다. 테스트 서비스를 주문하면 팀이 빌드를 검사해 TWA 또는 PWA 래퍼인지 판별합니다. 해당한다면 참여 문제로 지적될 수 있는 아키텍처에 14일을 쓰기 전에 정확한 수정 방향을 알려 드립니다.

주문하는 순간 진행되는 일

PrimeTestLab이 돕는 부분: 문제의 나머지 절반

아키텍처는 문제의 절반입니다. 다른 절반은 많은 1인 개발자가 막히는 부분으로, 실제로 테스트 참여를 선택하고 14일 연속 유지할 테스터 12명을 구하는 일입니다. 그 부분을 PrimeTestLab이 맡습니다.

검증된 테스터가 실제 Android 기기로 테스트에 참여하고 전체 요구 기간 동안 활동하도록 관리합니다. 한 명이 이탈해도 14일 연속 기록이 깨지지 않도록 여유 인원도 둡니다. 비공개 테스트 참여 링크를 공유하면 초대, 참여 확인, 일일 활동 모니터링, 14일 유지 관리를 맡습니다. 지금까지 7,400개가 넘는 앱을 지원했고 첫 시도 성공률은 99.9%입니다.

현재 플랜

서비스 수수료 5% 추가 · 무료 재테스트 또는 전액 환불

자주 묻는 질문

핵심 요약