앱 MVP Android WebView: 내부 표시·도메인·파일 접근을 나누는 5가지 기준
앱 MVP Android WebView: 내부 표시·도메인·파일 접근을 나누는 5가지 기준
앱 안에서 약관, 고객센터, 결제 안내처럼 웹 콘텐츠를 보여주려 할 때 WebView는 빠른 선택지처럼 보입니다. 다만 “페이지가 열렸다”를 기능 완료로 판단하면, 외부 링크의 이동 위치·자바스크립트·파일 선택·앱 기능 연결까지 한 덩어리로 남습니다. MVP에서는 무엇을 앱 안에 둘지, 어디서 시스템 브라우저로 넘길지, 어떤 설정이 필요한지부터 나누는 편이 안전합니다.
이 글은 Android WebView에 웹 화면을 넣으려는 팀이 기능 범위를 정하고 QA 기록을 남기는 방법입니다. 특정 앱의 보안 상태나 심사 결과를 단정하지 않습니다.
먼저 정할 것: WebView 안에 남길 화면과 브라우저로 넘길 화면
Android 공식 문서는 WebView를 앱의 Activity 안에서 웹 페이지를 표시하는 구성요소로 설명합니다. 기본 WebView에는 브라우저의 주소창이나 탐색 제어가 들어 있지 않습니다. 따라서 “웹을 앱 안에 보여 준다”는 선택은 화면 표시만의 문제가 아니라, 사용자가 현재 어느 사이트에 있는지 어떻게 알리고 이전·외부 이동을 어떻게 처리할지까지 포함합니다.
MVP에서는 웹 화면을 두 목록으로 나눠 적어 두세요. 첫째는 회사가 소유하고 경로를 관리하는 콘텐츠입니다. 예를 들어 앱 도움말, 고정된 안내 문서, 로그인 뒤의 한정된 웹 기능이 여기에 속할 수 있습니다. 둘째는 외부 사이트·광고·문서 공유 링크처럼 도메인과 내용을 앱이 통제하지 않는 콘텐츠입니다. 후자는 기본 브라우저로 보낼지, 별도 확인 화면을 둘지부터 제품 정책으로 정합니다.
구분 | 출시 전에 결정할 질문 | QA에 남길 증거 |
|---|---|---|
내부 웹 화면 | 어느 도메인과 어느 경로까지 앱 안에서 표시할 것인가 | 허용 호스트·대표 URL·기대 화면 |
외부 링크 | 앱 안에 남기지 않는 링크를 어디서 열 것인가 | 외부 브라우저 전환 결과 |
뒤로가기 | 웹 기록과 앱 화면 이동을 어떤 순서로 다룰 것인가 | 첫 화면·하위 화면·외부 이동 뒤 복귀 기록 |
WebViewClient로 URL 로딩과 탐색 관련 이벤트를 다룰 수 있다는 사실은, 모든 링크를 가로채야 한다는 뜻이 아닙니다. 먼저 “내부 WebView가 담당하는 URL”의 경계를 작성한 뒤 그 밖의 링크가 어떤 사용자 경험으로 빠져나가는지 테스트하세요. Android WebView 안내는 WebViewClient를 통해 URL 로딩을 제어하는 방식을 설명합니다.
두 번째 기준: URL은 문자열이 아니라 scheme과 host로 확인하기
초기 앱은 서버 알림, 이메일, 고객센터의 링크처럼 여러 경로에서 URL을 받습니다. 이때 특정 단어가 포함됐는지만 보고 내부 WebView로 열면, 실제 목적지 판단이 흐려질 수 있습니다. Android 보안 문서는 WebView에 URI를 넣기 전에 최소한 scheme과 host를 검증하고, 허용 호스트는 부분 문자열이 아니라 URI에서 분리한 값으로 확인하라고 안내합니다.
실무 기록에는 “trusted”라는 한 칸보다 다음 두 칸이 유용합니다. 하나는 HTTPS인지, 다른 하나는 호스트가 허용 목록과 정확히 맞는지입니다. 서브도메인을 허용한다면 어떤 형태까지 허용하는지도 별도로 정합니다. 앱 코드의 구체 구현은 팀의 아키텍처에 맞게 검토하되, 검수표에서는 URL 예시와 허용·차단 결과를 함께 남기세요.
입력 경로 | 검토 대상 | 다음 동작 예시 |
|---|---|---|
앱이 만든 내부 링크 | HTTPS와 정확한 허용 호스트 | WebView에서 표시 |
외부 공유 링크 | 호스트·scheme·제품 정책 | 기본 브라우저 또는 안내 화면 |
형식이 깨진 링크 | URI 파싱 가능 여부 | 로딩하지 않고 오류 안내 |
“https로 시작한다”만으로 도메인까지 확인된 것은 아니며, 반대로 호스트 이름 일부가 맞아도 scheme을 확인하지 않은 것은 아닙니다. Android의 안전하지 않은 URI 로딩 가이드는 두 값을 함께 확인하는 예시와 부분 문자열 비교의 한계를 제시합니다.
세 번째 기준: 자바스크립트와 네이티브 브리지는 화면 표시와 분리하기
정적인 안내 페이지라면 JavaScript가 필요하지 않을 수 있습니다. Android 문서에 따르면 WebView의 JavaScript 실행은 기본적으로 꺼져 있으며, 필요한 웹 기능이 있을 때만 별도로 켜는 방식입니다. 따라서 “웹 페이지가 동작한다”와 “JavaScript를 켠다”를 같은 체크 항목으로 두지 않는 것이 좋습니다.
특히 웹의 버튼이 앱의 카메라, 로그인 상태, 결제 시작처럼 네이티브 동작을 요청해야 한다면 JavaScript 인터페이스나 메시지 채널을 검토하게 됩니다. 이때는 브리지 이름·노출 메서드·호출 가능한 URL·민감 기능 여부를 한 표에 기록하세요. Android는 `addJavascriptInterface()`가 WebView의 모든 프레임에 객체를 노출할 수 있으며, 신뢰할 수 없는 HTML에서 사용하지 말라고 경고합니다.
아래처럼 세 가지를 분리하면 MVP 범위가 선명해집니다.
1. 웹 페이지가 JavaScript를 실제로 필요로 하는가
2. 웹 코드가 앱 기능을 호출해야 하는가
3. 그 호출이 사용자 데이터나 민감한 동작에 닿는가
셋 중 하나라도 답이 바뀌면 같은 WebView 화면이라도 검토 범위가 달라집니다. Android의 WebView 네이티브 브리지 보안 가이드는 신뢰할 수 없는 콘텐츠에서의 브리지와 메시지 원본 검증 위험을 설명합니다. 민감 기능은 웹 인터페이스가 아니라 앱 코드에서 수행할 수 있는지 먼저 검토하세요.
네 번째 기준: 파일 선택과 로컬 파일 접근은 별도 기능으로 취급하기
WebView 안에 파일 첨부 버튼이 보인다고 해서, 앱의 파일 접근 정책까지 자동으로 정해지는 것은 아닙니다. `file://` URL, 로컬 파일 접근 설정, 파일 선택 콜백은 각각 다른 위험과 구현 결정을 가집니다. Android 문서는 파일 접근 관련 설정이 넓게 열려 있으면 WebView 쿠키나 앱 전용 데이터를 포함한 로컬 파일에 접근할 수 있는 위험을 설명합니다.
따라서 문서 업로드나 이미지 첨부가 꼭 필요한 MVP라면 다음을 분리해 적습니다.
웹 화면이 파일 선택을 요청하는가
사용자가 고를 수 있는 파일의 형식·개수·처리 목적은 무엇인가
선택 뒤 앱이 URI를 어디까지 읽고 언제 서버로 보내는가
취소·권한 거부·업로드 실패에서 어떤 화면으로 돌아가는가
로컬 파일이나 콘텐츠 URL 접근이 정말 필요한가
파일 업로드 기능의 제품 흐름은 이미 다룬 앱 MVP 문서 첨부 기준과 연결해 검토할 수 있습니다. 이 글은 WebView라는 표시 컨테이너에서 파일 접근 설정과 선택 요청을 어떻게 분리해 볼지에 초점을 둡니다. Android의 WebView 파일 포함 보안 가이드는 파일 관련 설정을 대체할 수 있는 WebViewAssetLoader와 파일 선택 시의 주의점을 설명합니다.
다섯 번째 기준: 출시 QA는 ‘열림’이 아니라 경계별 결과로 남기기
WebView 테스트는 화면이 보이는 한 장면만 확인해서 끝나기 쉽습니다. 그러나 실제 운영 범위는 외부 링크, 리디렉션, 파일 선택, JavaScript 필요 화면, 잘못된 URL, 네트워크 실패에서 결정됩니다. 다음과 같이 한 URL씩 결과를 기록하면 나중에 웹팀·앱팀·운영팀이 같은 판단을 재현하기 쉽습니다.
테스트 장면 | 기대 결과 | 실제 결과 | 다음 결정 |
|---|---|---|---|
허용된 내부 HTTPS URL | 앱 안에서 표시 | 기기·버전별 관찰 | 통과 또는 수정 |
허용되지 않은 호스트 | 제품 정책에 따른 외부 전환 | 전환·취소 결과 | 허용 목록 또는 UX 검토 |
JavaScript 없는 안내 화면 | 불필요한 설정 없이 표시 | 기능 필요 여부 확인 | 설정 유지 또는 재검토 |
파일 선택 요청 | 사용자 선택·취소가 설명된 경로로 처리 | URI·업로드 결과 | 파일 정책 검토 |
네이티브 호출 요청 | 허용된 동작만 실행 | 호출 주체·결과 기록 | 브리지 범위 재검토 |
WebView 버전이나 앱의 특정 취약 여부, 개인정보 영향, 심사 통과 여부는 이 표만으로 판단할 수 없습니다. 다만 URL·파일·브리지·사용자 복귀를 한 “웹 화면 완료” 상태로 묶지 않으면, 다음 릴리스 전에 무엇을 다시 확인해야 하는지가 남습니다.
WebView는 웹을 표시하는 구성요소입니다. 어떤 웹을 어디까지 앱 안에 넣을지, 어떤 기능을 앱 코드로 남길지는 제품과 보안 검토가 함께 필요한 결정입니다.
WebView MVP 출시 전 체크리스트
내부 표시 대상의 HTTPS 호스트와 경로를 목록으로 정했는가
허용하지 않는 링크를 기본 브라우저 또는 다른 경로로 보낼 기준이 있는가
JavaScript가 필요한 화면과 필요하지 않은 화면을 구분했는가
네이티브 브리지의 호출 URL·기능·민감도와 제거 조건을 기록했는가
파일 선택·로컬 파일 접근·업로드 처리를 한 항목으로 뭉치지 않았는가
허용 URL, 외부 URL, 잘못된 URL, 취소, 실패, 재시도 결과를 실제 기기에서 남겼는가
앱 안 웹 화면의 범위가 정리됐다면, 그 다음에는 출시·운영 과정에서 남는 권한과 검수 기록도 함께 설계해야 합니다. 유인어스는 MVP의 화면·운영 경계를 정리하고 다음 개발 범위를 검토하는 과정을 돕습니다. MVP 개발 범위 상담하기.
자주 묻는 질문
WebView로 외부 사이트를 보여 주면 안 되나요?
항상 안 된다고 일반화할 수는 없습니다. 다만 외부 사이트의 URL과 콘텐츠를 앱이 통제하지 않는다면, 내부 WebView에 둘 이유와 허용 도메인·이동 정책을 먼저 정해야 합니다. Android 문서는 신뢰하지 않는 콘텐츠를 WebView에 넣는 경우 URL의 scheme과 host 검증, 브리지 분리를 안내합니다.
JavaScript를 켜면 바로 문제가 생기나요?
그 자체로 특정 앱의 문제를 뜻하지는 않습니다. WebView에서 JavaScript가 필요한 웹 기능인지, 어떤 콘텐츠를 불러오는지, 네이티브 브리지가 있는지에 따라 검토 범위가 달라집니다. 필요하지 않은 화면에는 켜지 않는 원칙부터 검토하세요.
WebView 안의 파일 업로드는 일반 파일 업로드와 같은가요?
같은 완료 상태로 보면 안 됩니다. 웹 페이지의 파일 선택 요청, 사용자가 고른 URI, 앱의 접근 범위, 서버 수신과 실패 안내는 각각 확인할 항목입니다. 특히 WebView의 파일 접근 설정과 `file://` 사용은 별도로 검토해야 합니다.
이 체크리스트만 통과하면 보안 검토가 끝나나요?
아닙니다. 이 글은 MVP 범위와 QA 기록을 나누기 위한 기준입니다. 실제 서비스의 인증·세션·개인정보·결제·취약점 대응은 앱 구조와 처리 데이터에 맞춘 별도 보안 검토가 필요합니다.
WebView를 도입할지, 어떤 화면만 앱 안에 남길지 결정하기 어렵다면 현재 사용자 흐름과 운영 제약을 기준으로 MVP 범위를 함께 정리할 수 있습니다. 유인어스에 MVP 범위 문의하기.