앱 권한 권장사항

권한 요청은 기기에서 얻을 수 있는 민감한 정보를 보호하는 용도이므로 앱 작동을 위해 정보에 액세스해야 하는 경우에만 사용해야 합니다. 이 문서에서는 이러한 정보의 액세스를 요청하지 않고도 동일한(또는 더 나은) 기능을 구현할 수 있는 방법에 관해 도움말을 제공합니다. 그러나 Android 운영체제에서 권한이 사용되는 방식을 모두 다루지는 않습니다.

Android 권한과 관련된 일반적인 내용은 권한 개요를 참조하세요. 코드에서 권한을 사용하는 방법에 관한 자세한 내용은 앱 권한 요청을 참고하세요.

Android 6.0 이상에서의 권한

Android 6.0 Marshmallow는 앱이 설치 전이 아닌 런타임 시 사용자에게 권한을 요청할 수 있도록 하는 새로운 권한 모델을 도입했습니다. 새로운 모델을 지원하는 앱은 서비스 또는 서비스에 의해 보호되는 데이터가 실제로 필요할 때 권한을 요청합니다. 이 모델이 전체적인 앱 동작을 반드시 달라지게 하지는 않지만, 민감한 사용자 데이터가 처리되는 방식과 관련하여 몇 가지 변화를 유도합니다.

상황별 컨텍스트 향상: 사용자는 앱의 컨텍스트 내에서 권한 그룹이 담당하는 기능에 액세스할 권한을 런타임 시 요청받습니다. 사용자는 권한이 요청되는 컨텍스트에 더 민감하기 때문에, 앱에서 요청하는 권한과 목적이 일치하지 않는 경우 사용자에게 권한을 요청하는 이유를 자세히 설명하는 것이 더욱 중요합니다. 따라서 가능하다면 요청하는 시점과 사용자가 요청을 거부한 경우 그 이후의 대화상자에 모두 요청에 관한 설명을 제공해야 합니다.

권한 부여 유연성 향상: 사용자는 권한 요청을 받았을 때뿐만 아니라 설정에서도 개별 권한에 관한 액세스를 거부할 수 있지만, 권한 요청 거부로 인해 기능이 제대로 작동하지 않을 때 당황스러울 수 있습니다. 따라서 Google 애널리틱스를 사용하는 등의 방법으로 권한을 거부하는 사용자 수를 모니터링하여 해당 권한에 의존하지 않도록 앱을 리팩터링하거나 앱이 제대로 작동하기 위해 권한이 필요한 이유를 더 효과적으로 설명하는 것이 좋습니다. 또한 사용자가 권한 요청을 거부하거나 설정에서 권한을 사용 중지하는 경우 나타나는 예외를 앱에서 처리할 수 있도록 해야 합니다.

트랜잭션 부담 증가: 사용자는 권한 그룹에 관한 액세스를 그룹 단위가 아니라 개별적으로 부여하도록 요청받습니다. 이렇게 되면 권한을 부여하는 데 있어, 사용자의 부담이 증가하고 요청 중 하나 이상이 거부될 가능성이 커지기 때문에 요청하는 권한의 수를 최소화하는 것이 매우 중요합니다.

기본 핸들러가 되기 위한 권한

일부 앱은 통화 기록 및 SMS 메시지와 관련된 민감한 사용자 정보에 액세스해야 합니다. 통화 기록 및 SMS 메시지에 특정한 권한을 요청하고 Play 스토어에 앱을 게시하려면 런타임 권한을 요청하기 전에 사용자에게 허용 여부 메시지를 표시하여 앱을 핵심 시스템 기능의 기본 핸들러로 설정하도록 해야 합니다.

기본 핸들러 및 기본 핸들러 허용 여부 메시지를 사용자에게 표시하는 방법에 관한 자세한 내용은 기본 핸들러에서만 사용되는 권한에 관한 가이드를 참조하세요.

작업 중인 라이브러리 이해하기

앱에서 사용하는 라이브러리에 권한이 필요한 경우가 있습니다. 예를 들어 광고 및 분석 라이브러리에서 필수 기능을 구현하기 위해 LOCATION 권한 그룹에 액세스해야 할 수 있습니다. 그러나 사용자의 관점에서 보면 라이브러리가 아니라 앱에서 권한이 요청됩니다.

사용자 입장에서 동일한 기능을 제공하는 앱이라면 권한을 적게 필요로 하는 앱을 선택하는 것처럼, 개발자도 라이브러리를 검토하고 불필요한 권한을 사용하지 않는 타사 SDK를 선택해야 합니다. 예를 들어 위치 기능을 제공하는 라이브러리를 사용하는 경우 위치 기반 타겟팅 기능을 사용하지 않는 한 FINE_LOCATION 권한을 요청하지 마세요.

위치에 관한 백그라운드 액세스 제한

앱이 백그라운드에서 실행 중일 때 위치로의 액세스는 앱의 핵심 기능에 중요하며 사용자에게 분명한 이점을 보여야 합니다.

권한이 필요한 이유 설명

requestPermissions()를 호출할 때 시스템에서 표시하는 권한 대화상자에 앱에서 원하는 권한이 무엇인지 표시되지만 이유는 제시되지 않습니다. 이 때문에 사용자가 당혹스러워하는 경우도 있습니다. requestPermissions()를 호출하기 전에 앱에서 권한을 요청하는 이유를 사용자에게 설명하는 것이 좋습니다.

연구에 따르면 사용자가 앱에서 권한이 필요한 이유를 알고 있을 때 권한 요청을 훨씬 더 편안하게 느낀다고 합니다. 다음은 한 사용자 연구에서 얻은 결과입니다.

...모바일 앱에서 사용자의 요청된 권한 수락 여부는 해당 권한과 관련된 목적에 크게 영향을 받습니다. 예를 들어, 사용자는 위치 정보에 대한 액세스 권한 요청이 앱의 핵심 기능을 지원하는 데 필요한지, 광고 네트워크 또는 분석 회사와 위치 정보를 공유하는 데 필요한지에 따라 권한 부여 여부를 결정합니다.1

CMU의 제이슨 홍 교수는 이 주제에 관한 공동 연구를 통해 다음과 같은 일반적인 결론을 내렸습니다.

...사람들이 앱에서 사용자 위치와 같이 민감한 정보를 사용하는 이유(예: 타겟팅된 광고를 표시하기 위해)를 알고 있는 경우 앱에서 위치 정보를 사용한다는 것만 알려줄 때보다 권한 요청을 더 편안하게 느낍니다.1

따라서 권한 그룹에 속하는 API 호출 중 일부만 사용하고 있다면 앱에서 사용 중인 권한과 그 이유를 명시적으로 나열하는 것이 좋습니다. 예:

  • 대략적 위치만 사용 중인 경우 앱 설명이나 앱 도움말에 이 정보를 표시하여 사용자가 알 수 있도록 합니다.
  • 사기로부터 사용자를 보호하는 인증 코드를 받기 위해 SMS 메시지에 액세스해야 한다면 이 사실을 앱 설명을 통해 사용자에게 알리거나 데이터에 처음 액세스할 때 표시합니다.

    참고: 앱이 Android 8.0(API 수준 26) 이상을 타겟팅한다면 사용자 인증 정보를 확인하는 과정에서 READ_SMS 권한을 요청하지 마세요. 대신, createAppSpecificSmsToken()을 사용하여 앱별 토큰을 생성한 후에 확인 SMS 메시지를 전송할 수 있는 다른 앱이나 서비스로 이 토큰을 전달하세요.

특정 조건에서는 사용자에게 민감한 정보 액세스를 실시간으로 알리는 것이 효과적일 수 있습니다. 예를 들어 카메라나 마이크에 액세스한다면 앱의 특정 위치 또는 알림 목록(애플리케이션이 백그라운드에서 실행 중인 경우)에 알림 아이콘을 표시하여 사용자에게 앱에서 데이터를 은밀하게 수집하지 않음을 알리는 것이 좋습니다.

앱에서 기능을 사용하기 위해 권한을 요청해야 하지만 사용자의 입장에서 그 이유가 명확하지 않은 경우 사용자에게 가장 민감한 권한이 필요한 이유를 알릴 방법을 찾으세요.

두 가지 권한 모델 테스트

Android 6.0(API 수준 23)부터 사용자는 앱을 설치하는 시점이 아닌 런타임에 앱 권한을 부여하고 취소합니다. 따라서 다양한 조건에서 앱을 테스트해야 합니다. Android 6.0 이전에는 앱이 실행되면 앱 매니페스트에 선언된 모든 권한이 있다고 합리적으로 추측할 수 있었습니다. 그러나 Android 6.0부터는 사용자가 API 수준 22 이하를 타겟팅하는 앱을 포함하여 모든 앱에서 권한을 허용하거나 중지할 수 있습니다. 그러므로 권한 부여 여부와 관계없이 앱이 정상적으로 작동하는지 테스트해야 합니다.

다음은 API 레벨 23 이상을 실행하는 기기에서 권한 관련 코드 문제를 찾는 데 도움이 되는 팁입니다.

  • 앱의 현재 권한 및 관련 코드 경로를 식별합니다.
  • 권한 보호된 서비스 및 데이터 전반에 걸친 사용자 흐름을 테스트합니다.
  • 부여되거나 취소된 권한의 다양한 조합을 테스트합니다. 예를 들어 카메라 앱 매니페스트에 CAMERA, READ_CONTACTSACCESS_FINE_LOCATION이 나열되어 있을 수 있습니다. 이러한 권한을 하나씩 사용 설정하거나 중지한 상태로 앱을 테스트하여 앱이 모든 권한 구성을 정상적으로 처리할 수 있는지 확인해야 합니다.
  • adb 도구를 사용하여 명령줄에서 권한을 관리합니다.
    • 권한과 상태를 그룹별로 나열합니다.
      $ adb shell pm list permissions -d -g
    • 하나 이상의 권한을 부여하거나 취소합니다.
      $ adb shell pm [grant|revoke] <permission-name> ...
  • 권한을 사용하는 서비스의 앱을 분석해봅니다.

추가 리소스

참고

[1] Modeling Users’ Mobile App Privacy Preferences: Restoring Usability in a Sea of Permission Settings, by J. Lin B. Liu, N. Sadeh and J. Hong. SOUPS 2014 기록 참조.