앱 MVP Android 관리형 구성: 선언·전달·적용·확인을 나누는 5가지 기준
앱 MVP Android 관리형 구성: 선언·전달·적용·확인을 나누는 5가지 기준
직접 답변: Android Enterprise용 MVP에서 관리형 구성을 지원하려면 “앱이 어떤 키를 선언했는가”, “관리 제공자가 어떤 값을 전달했는가”, “앱이 현재 값을 읽고 화면·동작에 반영했는가”, “실행 중 변경을 다시 읽었는가”, “관리 환경에서 결과를 확인했는가”를 따로 기록해야 합니다. 매니페스트에 항목을 추가했거나 EMM 화면에 필드가 보인다는 사실만으로 정책이 기기에 적용됐다고 볼 수는 없습니다.
이 글은 조직용 Android 앱에 네트워크 사용, URL 허용 범위, 기능 활성화처럼 관리자가 정하는 설정을 넣으려는 초기 팀을 위한 범위 설정 가이드입니다. Android 문서는 관리형 구성을 과거 명칭인 application restrictions로도 부르며, IT 관리자가 앱 설정을 원격으로 지정할 수 있는 방식으로 설명합니다. 하지만 기술적 선언, 관리 콘솔의 저장, 정책 전달, 앱의 실제 행동, 조직의 도입 판단은 서로 다른 신호입니다.
관리형 구성은 ‘앱 설정 화면’이 아니라 관리 경로입니다
사용자가 직접 고르는 일반 설정과 달리 관리형 구성은 조직의 IT 관리자가 관리 제공자를 통해 값의 범위를 정할 수 있게 만드는 인터페이스입니다. Android는 앱이 매니페스트에서 관리형 구성 파일을 선언하고, 그 파일에 각 옵션을 정의하면 관리 제공자가 이 정보를 읽을 수 있다고 안내합니다. 키는 앱이 값을 읽는 식별자이므로 임의로 바꾸거나 화면 문구와 혼동하면 안 됩니다.
예를 들어 ‘모바일 데이터에서 동기화 허용’은 제품 기능 이름이 아니라 정책으로 제어될 수 있는 하나의 설정입니다. 이때 팀은 키, 값 형식, 기본 동작, 값이 없을 때의 처리, 사용자에게 보여 줄 안내를 먼저 정합니다. ‘Wi-Fi만 허용’이라는 정책 문구가 있다고 해서 실제 네트워크 요청이 막혔다는 뜻은 아닙니다. 반영 코드를 거쳐 지원하는 관리 환경에서 관찰해야 합니다.
기준 1: 선언한 스키마와 전달받은 값은 다릅니다
Android의 설정 안내는 앱이 android.content.APP_RESTRICTIONS 메타데이터로 구성 파일을 연결하고, 구성마다 고유한 키를 둔다고 설명합니다. 이 스키마는 관리 콘솔이 어떤 값을 입력할 수 있는지 이해하는 출발점입니다. 스키마에 기본값이 있어도 현재 관리 구성 Bundle에 그 항목이 반드시 들어간다고 가정할 수는 없다는 점도 문서에 명시돼 있습니다.
따라서 설계 문서에는 ‘선언 기본값’과 ‘관리자가 명시한 값’을 분리해 적는 편이 안전합니다. Boolean, 정수, 문자열, 문자열 배열처럼 값 형식도 명시하고, 알 수 없는 값이나 빠진 키에서는 어떤 안전한 기본 동작을 할지 정합니다. 민감한 비밀값을 관리형 구성에 넣거나, 앱이 아직 해석하지 않는 키를 단지 미래 기능을 위해 공개하는 방식은 범위와 운영 책임을 넓힐 수 있습니다.
분리할 상태 | 점검 질문 | 그 자체로 증명하지 않는 것 |
|---|---|---|
스키마 선언 | 키·형식·설명이 매니페스트와 구성 파일에 있는가? | 관리자가 값을 저장했는가? |
정책 전달 | EMM 또는 관리 제공자가 현재 값을 기기에 전달했는가? | 앱이 동작을 바꿨는가? |
앱 읽기 | 현재 Bundle을 읽고 빠진 키를 안전하게 처리하는가? | 네트워크·화면·기능이 실제로 제한됐는가? |
변경 감지 | 실행 중 변경 뒤 최신 값을 다시 읽는가? | 모든 기기에서 즉시 동일하게 반영됐는가? |
환경 검수 | 관리 프로필 또는 대상 관리 방식에서 결과를 확인했는가? | 보안 심사·도입·성과가 완료됐는가? |
기준 2: 앱 시작·재개와 실행 중 변경을 나눠 읽습니다
Android 문서는 앱이 시작하거나 재개할 때 현재 관리 구성을 확인하고, 실행 중 변경에는 ACTION_APPLICATION_RESTRICTIONS_CHANGED를 동적으로 등록한 수신기로 대응하도록 안내합니다. 이 인텐트는 매니페스트에 선언한 수신기가 아니라 실행 중 동적으로 등록한 수신기에 전달된다는 조건도 있습니다. 따라서 ‘브로드캐스트를 만들었다’가 아니라 ‘지원하는 화면 또는 서비스가 활성 상태일 때 현재 값을 다시 읽고 적용했다’를 검수 기준으로 잡아야 합니다.
구성을 읽는 시점도 과하게 반복하면 안 됩니다. 공식 가이드는 getApplicationRestrictions()가 저장소 읽기를 필요로 하므로 매번 호출하기보다 시작·재개 시 읽어 캐시하고, 실행 중 변경 신호를 받으면 최신 Bundle을 다시 확인하라고 설명합니다. 여기서 캐시는 편의 수단일 뿐 정책의 출처가 아닙니다. 앱이 재개된 뒤에도 오래된 화면 상태를 쓰지 않는지, 변경 직후 기능 경계가 예상대로 바뀌는지를 별도 시나리오로 확인하세요.
우리 앱 MVP의 정책 설정·적용·검수 범위를 정리하기
기준 3: 빈 값·대기 상태·적용 실패를 같은 오류로 묶지 않습니다
Android Enterprise 개발 가이드는 getApplicationRestrictions()가 앱별 제한 묶음을 반환하면 사용자 입력 없이 구성할 수 있고, 빈 Bundle이면 개인 프로필처럼 비관리 상태로 동작할 수 있다고 설명합니다. 또 KEY_RESTRICTIONS_PENDING만 있는 경우에는 관리 중이지만 DPC가 올바르게 구성되지 않은 상태로 보고 사용자에게 IT 관리자 안내를 하도록 제안합니다. 이는 세 상태가 서로 다른 대응을 요구한다는 뜻입니다.
MVP에서는 최소한 ‘미관리 기본 흐름’, ‘관리된 유효값’, ‘관리 대기 또는 구성 오류’, ‘해석하지 못한 값’의 메시지와 행동을 분리해 보세요. 빈 Bundle을 일률적으로 차단하거나, 대기 신호를 일반 사용자 오류로 숨기면 운영자가 원인을 파악하기 어려워집니다. 반대로 관리 대기 신호가 보였다고 실제 정책 전달 실패 원인을 확정해서도 안 됩니다. 관리 모드, 등록 상태, EMM 정책, 앱 버전과 당시 관찰 결과를 함께 남겨야 합니다.
기준 4: EMM의 정책 저장과 앱의 적용 완료를 구분합니다
Android Management API 문서는 정책 리소스가 기기와 앱 관리 설정을 담고, 앱 정책에 관리형 구성 템플릿을 둘 수 있음을 설명합니다. 이는 EMM 구현 또는 조직 관리 측면의 전달 경로입니다. 반면 앱 개발자가 해야 할 일은 현재 구성 Bundle을 읽어 실제 UI와 기능을 바꾸고, 필요하면 키 기반 앱 상태로 적용 결과나 오류를 EMM에 알리는 것입니다.
그래서 테스트 기록은 ‘관리 콘솔에서 프로필 저장’, ‘정책이 대상 기기에 연결’, ‘앱이 최신 값을 읽음’, ‘기능 동작이 값과 일치’, ‘관리자가 앱 피드백을 확인’처럼 나누는 편이 좋습니다. 한 단계의 화면 캡처만으로 다른 단계를 대신 확인하지 마세요. 특히 기기 등록, 정책 배포 시점, 네트워크 상태, 앱 재시작 여부에 따라 관찰 범위가 달라질 수 있으므로, 테스트 결과를 모든 기기·조직의 적용 보장으로 확장하지 않아야 합니다.
기준 5: 관리형 지원의 범위와 운영 책임을 출시 전에 합의합니다
관리형 구성을 넣는다고 앱이 자동으로 엔터프라이즈 준비, 보안 인증, 조달 적합 또는 고객 도입 완료 상태가 되는 것은 아닙니다. 지원할 관리 방식, 제공할 키 목록, 개인 프로필에서의 기본 동작, 정책 충돌 때의 사용자 안내, 담당자에게 전달할 진단 정보, 변경 롤백 기준을 제품·개발·운영이 함께 정해야 합니다. 실제 조직 정책이나 계약 조건은 해당 조직과 별도로 확인해야 합니다.
외주 또는 내부 개발 뒤 운영 인수인계까지 범위를 넓힌다면 앱 외주개발 운영 전환: 배포 승인·환경값·되돌리기를 나누는 5가지 기준도 같이 확인하세요. 관리형 구성의 값 자체와, 그 값을 바꾸는 권한·릴리스·복구 절차는 한 문서로 섞기보다 연결된 별도 책임으로 관리하는 편이 명확합니다.
출시 전 짧은 점검표
각 키의 목적·형식·기본 동작·누락 시 처리를 문서화했는가?
스키마 선언과 관리 제공자의 현재 값을 구분했는가?
시작·재개 시 최신 Bundle을 읽고, 실행 중 변경 뒤 다시 적용하는가?
미관리·유효 설정·대기·해석 실패 상태별 안내와 행동이 다른가?
관리 콘솔의 저장, 정책 전달, 앱 적용, 관찰 결과를 하나의 완료 신호로 과장하지 않았는가?
자주 묻는 질문
관리형 구성을 선언하면 모든 기기에서 바로 적용되나요?
아닙니다. 앱이 구성 항목을 선언하는 일과 EMM 또는 관리 제공자가 값을 전달하는 일, 앱이 현재 값을 읽어 동작을 바꾸는 일은 별도입니다. 실제 관리 방식과 기기 조건에서 적용 상태를 확인해야 합니다.
빈 Bundle은 설정 오류인가요?
항상 그렇지는 않습니다. Android 문서는 빈 Bundle을 개인 프로필처럼 비관리 상태로 동작하는 경우로 설명합니다. 다만 관리 환경의 기대 상태와 다를 때는 정책·등록·관리 제공자 설정을 별도로 확인해야 합니다.
변경 브로드캐스트만 받으면 최신 값이 보장되나요?
아닙니다. 앱은 시작 또는 재개 시 현재 구성을 읽고, 실행 중에는 동적 수신기로 변경을 감지한 뒤 현재 Bundle을 다시 읽어야 합니다. 수신 자체와 적용 완료는 같은 상태가 아닙니다.
관리형 구성 지원은 보안 인증이나 기업 도입 증거인가요?
아닙니다. 이는 원격 설정을 지원하는 기술적 범위입니다. 특정 조직의 보안 심사, 정책 적합성, 계약·도입 결과는 별도의 확인 대상입니다.