앱 MVP Play Integrity API: 요청·검증·서비스 결정을 나누는 5가지 기준
Android 앱 MVP에서 결제 확인, 쿠폰 적용, 계정 변경처럼 중요한 서버 요청을 다룰 때 “무결성 검사를 붙였다”는 말만으로 설계가 끝나지는 않습니다. 앱이 어떤 행동을 방어하려는지, 어떤 값으로 토큰을 요청했는지, 서버가 무엇을 검증했는지, 검증 결과를 어떤 서비스 상태로 바꿨는지는 서로 다른 일입니다. 이 경계를 한 줄로 묶으면 실패했을 때 사용자 안내와 재시도, 운영 기록, 다음 판단이 모두 흐려질 수 있습니다.
먼저 답하면, Android 앱 MVP 팀은 **보호할 행동, 앱의 토큰 요청, 서버의 복호화·검증, 응답에 대한 제품 정책, 사용자가 보게 되는 다음 상태**를 따로 기록하는 편이 좋습니다. Play Integrity API가 주는 신호는 서버 판단의 입력 중 하나이며, 이 글은 특정 앱의 부정 사용 차단, 보안, 심사 통과, 결제 완료, 전환·매출 성과를 보장하지 않습니다.
앱에서 로그인 뒤 세션을 다시 확인하는 흐름은 앱 MVP 로그인 재시작 경계에서, 스토어 구매 알림을 서비스 권한 변경과 분리하는 흐름은 앱 MVP 스토어 구매 서버 알림 기준에서 다룹니다. 여기서는 Android의 Play Integrity API 신호를 제품 서버의 결정과 혼동하지 않는 기준을 정리합니다.
먼저 구분할 것: 토큰 요청은 서비스 결정이 아닙니다
Android Developers는 표준 요청을 두 부분으로 설명합니다. 먼저 토큰 제공자를 필요한 시점보다 앞서 준비하고, 보호하려는 서버 요청이 생기면 앱이 토큰을 요청합니다. 그 토큰은 앱의 서버로 전달되며, 서버는 복호화·검증 절차를 거쳐 응답을 읽습니다. 따라서 “앱에서 토큰을 받았다”는 상태와 “서버가 특정 기능을 계속 진행하기로 했다”는 상태는 같은 완료 표시를 쓰면 안 됩니다.
초기 팀의 작업 보드에는 보호하려는 행동, 원래 서버 요청에 포함된 값, 앱에서 요청한 토큰, 서버가 검증한 결과, 서비스가 반환한 상태를 다른 행으로 두는 방법이 유용합니다. 예를 들어 서버 요청이 실패했는데도 앱의 토큰 요청만 성공했을 수 있고, 반대로 신호가 예상과 다르더라도 제품이 사용자에게 안내·재시도·보류 중 무엇을 보여 줄지는 서비스 정책이 정합니다.
기준 1. 방어할 행동을 먼저 한 문장으로 고정합니다
무결성 검사는 막연한 “앱 전체 확인”보다 특정 행동 또는 서버 요청에 연결해 검토할 때 범위가 선명해집니다. Android Developers는 보호하려는 행동이나 서버 요청에 가까운 시점에 요청하는 방식을 안내합니다. 팀은 먼저 어떤 버튼·요청·권한 변경을 확인할 것인가, 그 요청의 정상적인 입력은 무엇인가, 검증이 늦거나 실패할 때 사용자가 어디로 가는가를 문장으로 정하세요.
여기서 중요한 것은 앱 화면의 이벤트 이름과 서버의 실제 요청을 같은 것으로 가정하지 않는 일입니다. 사용자가 버튼을 누른 사건, 앱이 서버에 전달한 요청, 서버가 처리한 결과는 시간과 실패 원인이 다를 수 있습니다. 보호 범위를 정했다면 화면 로그가 아니라 서버 요청 식별과 처리 결과까지 연결할 수 있는지 별도로 확인합니다.
기준 2. 요청에 묶은 값과 토큰 자체를 다른 기록으로 남깁니다
표준 요청에는 requestHash로 관련 요청 값을 묶을 수 있습니다. Android Developers는 이 값에 앱 요청의 관련 값을 해시로 포함해 변조와 유사한 문제를 줄이도록 안내하며, 값이 앱과 Google에 평문으로 보일 수 있으므로 원문을 그대로 넣지 않도록 주의하라고 설명합니다. 이 안내를 “어떤 사용자 정보든 넣어도 된다”는 뜻으로 넓혀 해석하면 안 됩니다.
기획·개발 협업에서는 무엇을 묶었는가와 어떤 개인정보 원문을 남기지 않았는가를 구분해 두세요. 예를 들어 주문번호나 이메일을 문서에 복사하는 대신, 팀이 검증할 요청 식별 규칙과 해시 생성 책임 위치를 적을 수 있습니다. 실제 해시 구성, 보관 기간, 접근 권한은 앱의 데이터 처리 방식과 보안 요구에 맞춰 별도 검토할 일입니다.
기준 3. 서버의 검증 순서를 제품 정책보다 앞에 둡니다
무결성 응답에는 요청 세부 정보와 앱·계정·기기 관련 신호가 포함될 수 있습니다. Android Developers는 각 신호를 보기 전에 requestDetails가 원래 요청의 기대값과 일치하는지 먼저 확인하라고 안내합니다. 즉, “기기 신호가 괜찮아 보인다”는 이유만으로 다른 요청에서 온 토큰을 현재 행동에 연결하면 안 됩니다.
서버 점검표는 최소한 세 질문으로 시작할 수 있습니다. 첫째, 이 토큰이 지금 처리하는 요청과 연결되는가. 둘째, 서버가 복호화·검증 결과를 정상적으로 읽었는가. 셋째, 그 뒤에 적용할 제품 정책은 무엇인가. 이 순서가 있으면 신호 검증 실패와 기능 정책 거부, 네트워크 오류를 모두 같은 “차단” 상태로 기록하는 일을 줄일 수 있습니다.
우리 앱 MVP의 중요 요청과 서버 결정 경계 정리하기
기준 4. 신호의 종류와 서비스 응답을 일대일로 고정하지 않습니다
Android Developers는 앱 인식, 계정 관련 정보, 기기 관련 정보처럼 여러 영역의 verdict를 설명하고, 하나의 높은 기준만으로 처리하기보다 단계별 서버 전략을 둘 수 있다고 안내합니다. 이 말은 모든 낮은 신호에 같은 응답을 해야 한다는 뜻이 아닙니다. 팀은 사용자에게 기능을 계속 제공할지, 추가 확인을 보여 줄지, 나중에 다시 시도하게 할지, 상담·지원 경로를 제공할지처럼 실제 서비스 응답을 별도 결정해야 합니다.
따라서 문서에는 받은 신호, 서버의 해석 규칙, 사용자에게 보낸 응답, 재시도 또는 후속 처리를 하나의 필드에 합치지 않습니다. 같은 신호라도 행동의 중요도, 사용자 상황, 서버의 일시적 오류 여부가 다르면 적절한 안내가 달라질 수 있습니다. 특정 verdict가 나왔다는 기록이 특정 사용자의 의도나 부정 행위를 증명하는 것은 아니라는 점도 남겨 두세요.
기준 5. 오류·재시도와 사용자 안내를 사후 예외가 아니라 경로로 설계합니다
토큰 요청과 서버 검증에는 네트워크·기기 환경·연동 상태에 따른 오류가 생길 수 있습니다. Android Developers는 오류 코드 유형을 구분하고, 일시적인 조건에는 재시도 전략을 적용하되 일시적이지 않은 오류는 반복 재시도하지 않도록 안내합니다. 그러므로 “검증이 안 되면 다시 호출” 같은 한 문장 대신, 무엇을 일시 오류로 볼지와 사용자 화면이 기다림·재시도·대체 안내 중 무엇을 보여 줄지 분리해 정해야 합니다.
테스트 시에는 정상 응답만 보지 말고 토큰 준비 실패, 토큰 요청 실패, 서버 복호화·검증 실패, 요청-응답 연결 불일치, 제품 정책상 보류를 구분해 관찰하세요. 각각의 상태에 담당자, 사용자 문구, 로그의 최소 식별값, 재시도 조건을 적으면 운영 중 문제가 생겼을 때 API 자체의 오류와 제품 정책의 결정을 혼동하지 않을 수 있습니다.
MVP 회의에서 바로 확인할 5문장
지금 보호하려는 것은 어떤 사용자 행동 또는 서버 요청인가.
앱은 어떤 요청 식별 규칙을 토큰 요청과 연결하고, 원문 민감정보는 어떻게 피하는가.
서버는 원래 요청과의 일치 여부를 먼저 확인한 뒤 어떤 신호를 읽는가.
각 검증 결과와 오류 상태에서 서비스는 사용자에게 어떤 다음 상태를 보여 주는가.
실제 기기와 테스트 환경에서 앱 요청, 서버 검증, 제품 응답을 각각 관찰했는가.
유인어스는 민간 사업 지원 서비스입니다. 이 글은 특정 앱의 보안성, 부정 사용 예방, Google Play 정책 적합성·심사 결과, 사용자 접근, 결제·권한 처리, 트래픽·전환·매출 또는 사업 성과를 보장하지 않습니다. 실제 도입 전에는 현재 Android Developers 문서와 Google Play Console·Cloud 프로젝트 설정, 앱과 서버의 실제 구현·테스트 결과를 함께 확인하세요.
자주 묻는 질문
앱이 토큰을 받으면 서버 요청도 자동으로 승인되나요?
아닙니다. Android Developers는 앱이 요청한 토큰을 서버로 보내 복호화·검증하고 결과를 읽는 절차를 설명합니다. 서비스가 요청을 계속 처리할지와 사용자에게 보일 다음 상태는 서버와 제품 정책이 따로 정합니다.
verdict를 볼 때 가장 먼저 확인할 것은 무엇인가요?
requestDetails가 원래 서버 요청의 기대값과 일치하는지 먼저 확인합니다. Android Developers도 각 verdict를 보기 전에 이 연결을 확인하도록 안내합니다.
낮은 기기 신호가 나오면 모든 기능을 막아야 하나요?
그렇게 단정할 수 없습니다. Android Developers는 단계별 전략을 설명합니다. 실제 대응은 보호하려는 행동의 중요도, 오류 조건, 사용자 안내와 서비스 정책을 함께 검토해 정해야 합니다.
검증 오류가 나면 계속 재시도하면 되나요?
아닙니다. Android Developers는 일시적인 조건에는 재시도를 고려하되, 일시적이지 않은 오류는 재시도하지 않도록 안내합니다. 오류 유형과 사용자 안내를 먼저 나누어 설계하세요.
확인한 공식 출처
- Android Developers · Play Integrity API overview — 신호 영역, 요청 시점, 단계별 서버 전략을 2026-09-20 KST에 확인했습니다. - Android Developers · Make a standard API request — 토큰 제공자 준비, 토큰 요청, 서버 복호화·검증 흐름을 2026-09-20 KST에 확인했습니다. - Android Developers · Integrity verdicts — `requestDetails`를 먼저 확인하는 순서를 2026-09-20 KST에 확인했습니다.