앱 MVP Android 디지털 자격증명: 요청·사용자 선택·신뢰 판단을 나누는 5가지 기준
앱 MVP Android 디지털 자격증명: 요청·사용자 선택·신뢰 판단을 나누는 5가지 기준
Android MVP에서 디지털 자격증명을 검토한다면, “신원 확인 기능을 넣었다”로 끝내지 않는 편이 안전합니다. 어떤 속성을 요청할지, 사용자가 무엇을 선택·동의하는지, 지갑이 어떤 응답을 돌려주는지, 서버가 무엇을 검증할지, 서비스가 그 결과를 얼마나 신뢰할지는 서로 다른 결정입니다. Android의 Digital Credentials API는 발급자·보관자·검증 앱의 상호작용을 조정하지만, 앱의 서비스 규칙이나 신뢰 판단을 자동으로 대신하지는 않습니다(C001~C006).
이 글은 Android MVP가 이메일 확인, 연령 확인 또는 자격 속성 확인 같은 흐름을 논의할 때 사용할 수 있는 범위 점검표입니다. 특정 자격증명 발급, 법적 적합성, 심사 통과, 전환·매출·검색 성과를 보장하지 않습니다.
1. 먼저 ‘자격증명 도입’이 아니라 필요한 속성 한 가지를 적습니다
Android 공식 개요는 디지털 자격증명을 암호학적으로 검증 가능한 디지털 문서로 설명하며, 인증 또는 인가에 사용할 수 있다고 안내합니다(C001). 또한 선택적 공개를 지원하는 형식은 필요한 정보만 공유하게 할 수 있다고 설명합니다(C002). 따라서 MVP의 첫 질문은 “디지털 신분증을 받자”가 아니라 “이 흐름에서 연령 조건, 확인된 이메일, 전화번호처럼 정말 필요한 속성이 무엇인가”여야 합니다.
편집상 판단: 수집하려는 속성을 한 문장으로 설명할 수 없거나, 그 속성이 현재 결정에 꼭 필요하지 않다면 API 통합보다 요구사항·보관 기간·대체 흐름을 먼저 정리하는 편이 낫습니다. 이 문장은 C001~C002에 근거한 제품 설계 해석이며 플랫폼의 의무 규정은 아닙니다.
요청 목록에는 속성 이름, 필요한 이유, 표시·저장 여부, 서버 전달 여부, 사용자가 거절했을 때의 대체 경로를 분리해 남기세요. ‘선택적 공개’가 가능하다는 설명을 모든 지갑·모든 시나리오에서 원하는 항목만 항상 제공된다는 보장으로 확대해서는 안 됩니다.
2. 요청을 보냈다는 것과 사용자가 정보를 공유했다는 것은 다릅니다
검증 앱이 요청을 보내면 Credential Manager는 자격증명을 보관한 앱들의 적합한 항목을 신뢰된 시스템 UI에서 보여 주고, 사용자가 진행에 동의한 뒤 선택한 보관 앱이 응답을 만듭니다(C003). Verifier API 가이드도 요청을 구성하고 `getCredential` 흐름을 실행해 성공 응답 또는 예외를 다루는 순서를 제시합니다(C004).
요청: 서비스가 어떤 형식과 속성을 요구하는지 정한 상태
선택·동의: 사용자가 시스템 UI와 보관 앱 UI에서 진행을 선택한 상태
응답 수신: 앱이 `DigitalCredential` 응답 또는 예외를 받은 상태
서버 검증: 응답을 서버에서 검증하는 상태
서비스 결정: 제품 정책에 따라 가입·접근·추가 확인을 결정한 상태
이 다섯 상태를 한 이벤트로 기록하면 취소, 보관된 자격증명 없음, 네트워크 단절, 서버 검증 실패를 모두 ‘인증 실패’로 뭉개기 쉽습니다. Android 문서가 예시로 든 취소·중단·자격증명 없음 같은 예외도 사용자 안내와 재시도 기준을 따로 정할 근거가 됩니다(C004).
3. 지갑의 응답과 서비스의 신뢰 판단을 분리합니다
Android의 신뢰·안전성 문서는 발급자가 암호학적으로 검증한 자격증명이 변조 방지와 출처 확인에 쓰일 수 있다고 설명합니다(C005). 그러나 속성이 `verified`로 표시되더라도, 이는 발급자가 그 속성을 확인했다는 주장이지 모든 상황에서 절대적 진실이라는 뜻은 아니며, 검증자가 특정 발급자를 어느 수준까지 신뢰할지는 직접 판단해야 한다고 명시합니다(C006).
확인 항목 | 기록할 질문 | 서비스가 별도 결정할 부분 |
|---|---|---|
발급자 | 누가 어떤 속성을 발급했는가 | 우리 서비스가 그 발급자를 신뢰하는가 |
속성 | 응답에 어떤 값이 포함됐는가 | 그 값이 현재 업무에 필요한 최소 범위인가 |
검증 | 서버에서 응답 검증이 완료됐는가 | 실패·만료·재시도 때 접근을 어떻게 처리할 것인가 |
보관 | 어떤 로그와 증빙을 남기는가 | 보관 기간·접근 권한·삭제 기준은 무엇인가 |
즉, 암호학적 응답을 받았다는 기록만으로 사업자 확인, 법령 준수, 부정 이용 방지, 고객 자격 부여까지 완료됐다고 표현하면 안 됩니다. 필요한 법률·업종 규칙·개인정보 처리 기준은 이 API 문서와 별도로 확인해야 합니다.
관련 글 앱 MVP passkey 로그인: 계정 연결·서버 검증·복구 경로를 나누는 5가지 기준은 로그인 자격증명과 계정 연결을 다룹니다. 이번 글은 암호학적으로 검증 가능한 속성을 지갑에서 요청하고, 그 신뢰 범위를 서비스가 판단하는 흐름에 초점을 둡니다.
4. MVP 검수는 화면 데모가 아니라 경계별 재현 기록으로 마칩니다
Verifier API는 Android 6(API 23) 이상 지원을 안내하며, 프로젝트 의존성 추가, 요청 구성, Credential Manager 실행, 성공 응답 또는 예외 처리, 응답 검증의 흐름을 제시합니다(C004). 이 지원 범위는 실제 보관 앱·발급자·형식·사용자 기기 조합이 모두 준비됐다는 보장은 아닙니다. 실제 서비스 범위는 연동 대상과 테스트 결과로 좁혀 확인해야 합니다.
대표 사용 사례 하나와 요청할 최소 속성을 적습니다.
지원 기기·앱 버전·보관 앱·테스트 자격증명·요청 형식을 기록합니다.
정상 선택 뒤 앱 응답, 서버 검증, 서비스 화면 상태를 각각 확인합니다.
사용자 취소, 자격증명 없음, 예외, 서버 검증 실패를 분리해 재현합니다.
로그에 남길 식별자와 민감 속성의 노출·보관 범위를 검토한 뒤 다음 릴리스 결정을 적습니다.
이 기록은 고객의 실제 자격이나 사업 성과를 증명하는 보고서가 아닙니다. 다만 ‘요청 가능한 UI가 보였다’와 ‘서비스가 필요한 범위에서 검증해 안전하게 다음 단계로 갔다’를 구분하는 운영 근거가 됩니다.
자주 묻는 질문
디지털 자격증명을 쓰면 앱이 사용자의 신분증 정보를 자동으로 받나요?
아닙니다. 검증 앱이 요청을 보내도 Android의 시스템 UI와 자격증명 보관 앱의 흐름에서 사용자가 선택하고 동의해야 응답이 전달됩니다. 필요한 속성만 요청하는 범위와 거절·취소 상태를 함께 설계해야 합니다.
응답의 verified 표시면 서비스가 무조건 믿어도 되나요?
아닙니다. verified는 발급자가 해당 속성을 확인해 서명했다는 주장입니다. 서비스를 운영하는 검증자는 발급자를 신뢰할지, 어떤 용도와 기간에 쓸지, 서버에서 어떤 검증을 할지 별도로 결정해야 합니다.
Android 앱에서 받은 응답은 화면에서만 확인하면 되나요?
아닙니다. Android 공식 Verifier API 가이드는 응답을 받은 뒤 서버에서 검증하는 단계를 제시합니다. 요청 전달, 사용자 선택, 응답 수신, 서버 검증, 서비스 권한 부여를 각각 기록해야 합니다.
이 기능을 붙이면 KYC나 가입 전환이 보장되나요?
아닙니다. 이 글은 Android 플랫폼의 요청·선택·검증 경계를 MVP 점검 항목으로 바꾼 것입니다. 심사, 법적 의무, 전환과 매출은 서비스 정책과 별도 측정으로 판단해야 합니다.
공식 출처
Android Developers: About digital credentials — 2026-09-25 KST 직접 확인
Android Developers: Credential Manager - Verifier API — 2026-09-25 KST 직접 확인
Android Developers: About trust and safety with digital credentials — 2026-09-25 KST 직접 확인
발행일: 2026-09-25 · 작성: 유인어스 앱 MVP 인사이트