앱 MVP 무결성 확인: 요청·서버 검증·대응을 나누는 5가지 기준

앱 MVP 무결성 확인: 요청·서버 검증·대응을 나누는 5가지 기준

로그인, 결제 전 확인, 쿠폰 적용, 중요한 데이터 변경처럼 악용 가능성을 점검하고 싶은 순간이 생기면 “앱 무결성 API를 붙이면 되겠지”라고 생각하기 쉽습니다. 그러나 신호를 받는 일과 그 신호를 어떤 요청에 연결하고, 서버에서 무엇을 대조하며, 예상과 다른 결과를 사용자에게 어떻게 안내할지 결정하는 일은 다릅니다.

먼저 답하면, 보호할 행동, 요청 내용 연결, 서버 검증, 단계별 대응, 실패·장애 안내를 따로 정하세요. Google Play Integrity API는 사용자 행동이나 서버 요청이 Google Play에서 설치된 인식 가능한 앱과 인증된 Android 기기에서 온 것인지 판단하는 데 쓸 수 있는 verdict를 제공합니다.

다만 이 신호 하나가 모든 악용·부정 이용·보안 검토를 끝내 주는 것은 아닙니다. Android 문서도 전체 악용 대응 전략의 일부로 사용하고, 적용 전에 실제 사용자군의 신호를 관찰하라고 안내합니다.

이 글은 특정 앱의 보안·개인정보 적합성, 부정 이용 차단, 플랫폼 심사·출시 또는 사업 성과를 보장하는 구현 명세가 아닙니다. Android 앱 MVP 팀이 현재 코드와 백엔드, 지원 기기, 서비스의 위험도에 맞춰 출시 기록을 정리하는 방법을 다룹니다.

공식 원문 확인일: 2026년 9월 17일 · 작성: 유인어스(UINUS)

먼저 답: “무결성 확인”을 다섯 개의 제품 결정으로 나누세요

이 표는 Android의 필수 서식이 아닙니다. 다만 “무결성 통과/실패”라는 한 칸으로는 놓치기 쉬운 제품·서버·운영 결정을 나누어 보려는 틀입니다. 같은 기록을 기획·개발·운영이 공유하면, 앱에서 신호를 요청하는 이유와 서버가 내리는 결정을 나중에 서로 다른 뜻으로 해석할 가능성을 줄일 수 있습니다.

1. 모든 화면이 아니라 실제로 보호할 행동부터 고르세요

Play Integrity API는 변조된 앱 버전, 신뢰하기 어려운 기기, 에뮬레이터 환경 같은 위험한 상호작용을 파악하는 verdict를 제공하고, 백엔드가 그 결과를 바탕으로 다음 행동을 정할 수 있게 합니다. 하지만 이 설명이 앱의 모든 화면에서 같은 방식으로 요청해야 한다는 뜻은 아닙니다.

MVP에서는 먼저 “이 행동이 의도와 다르게 반복되면 어떤 문제가 생기는가”를 적으세요. 예를 들어 로그인, 선물·쿠폰 확정, 유료 기능 시작, 중요한 데이터 변경은 서로 위험도와 실패 비용이 다릅니다. 보호할 행동의 서버 요청 직전에 확인할지, 앱 시작 시 미리 준비만 할지, 단순 조회 화면에는 적용하지 않을지를 분리해 두면 불필요한 요청과 사용자 흐름을 함께 검토할 수 있습니다.

Android 문서는 앱 액세스 위험 verdict를 보호하려는 사용자 행동 또는 서버 요청에 가능한 가깝게 요청하라고 설명합니다. 따라서 “로그인 화면에 한 번”처럼 화면 이름만 적기보다, 어떤 서버 요청을 보호하는지와 그 요청이 완료되기 전인지 후인지를 출시 기록에 남기세요. 앱 시작 시간과 중요한 동작을 같은 성능 목표로 묶지 않는 관점은 앱 MVP 시작 시간 측정 글에서도 이어집니다.

2. 신호와 요청을 연결하지 않으면 다른 요청에 재사용될 수 있습니다

무결성 token이 왔다는 사실만으로 지금 처리하려는 주문·점수·쿠폰 요청과 연결되는 것은 아닙니다. Android의 standard request 문서는 보호하려는 사용자 행동 또는 서버 요청의 관련 파라미터를 해시로 계산해 requestHash에 넣고, 서버가 token 안의 값을 꺼내 동일한 방식으로 계산한 값과 비교하도록 안내합니다.

여기서 MVP 팀이 정할 것은 암호 알고리즘 이름을 외우는 일이 아니라, “무엇을 같은 요청으로 볼 것인가”입니다. 예를 들어 계정 식별자, 행동 종류, 서버가 받은 변경 대상, 시간 창처럼 실제 판단에 필요한 값을 안정된 방식으로 직렬화해 해시 대상에 포함할지 정할 수 있습니다.

반대로 비밀번호, 인증번호, 고객 메모처럼 민감한 원문을 그대로 넣지 마세요. Android 문서는 requestHash와 nonce 값이 앱과 Google에 평문으로 보일 수 있으므로, 입력값을 기본적으로 암호화하거나 해시하라고 주의합니다.

입력값을 어떤 화면에서 받고 언제 서버에 보내는지 별도로 정리하려면 앱 MVP 클립보드 입력 글을 함께 보세요. 붙여넣기 가능 여부와 중요한 요청의 무결성 연결은 같은 문제가 아니며, 각 흐름의 데이터 범위를 분리해 점검해야 합니다.

우리 앱 MVP의 중요 요청 흐름 점검하기

3. 앱에서 받은 token은 서버의 판단 재료로 다루세요

standard request 흐름에서 앱은 token을 받아 백엔드로 보내고, 백엔드는 Google Play 서버에 token의 해석·검증을 요청한 뒤 결과를 기준으로 다음 행동을 정합니다. 즉 앱 화면에서 받은 token을 곧바로 “승인” 값으로 취급하는 대신, 서버가 기대한 요청 값과 결과를 대조하고 실제 서비스 규칙을 적용하는 경계를 명확히 두는 편이 좋습니다.

서버 기록에는 최소한 세 가지를 남기세요. 첫째, 어떤 endpoint가 token을 받는지입니다. 둘째, 그 endpoint가 requestHash 또는 nonce 등 기대한 요청 세부사항을 어떻게 확인하는지입니다. 셋째, 앱 인식·라이선스·기기 관련 결과 가운데 현재 제품이 실제로 참고하는 범위입니다.

Android 문서는 기기 신뢰도를 평가하기 전에 request details, 앱 인식, 계정 관련 기본 신호를 확인하고, 신호가 기대와 다를 때의 처리를 마련하라고 설명합니다.

이 과정은 구현 코드나 서비스 계정 정보를 글·기획 문서에 복사하라는 뜻이 아닙니다. 비밀값·서명 키·실제 고객 데이터는 제외하고, 책임 경계와 검증 결과를 누가 확인하는지만 기록하세요. 외주 개발 뒤 운영권한을 점검하는 경우에는 앱 외주개발 인수인계처럼 계정·권한·다음 릴리스 책임을 분리하는 방식이 도움이 됩니다.

4. 한 번의 거절보다 단계별 대응과 관찰을 먼저 설계하세요

무결성 verdict에는 여러 가능한 응답이 있을 수 있습니다. Android 문서는 이를 바탕으로 백엔드가 서로 다른 응답을 하는 단계형 대응 전략을 구성할 수 있다고 설명하며, 더 높은 신뢰 등급만을 유일한 기준으로 삼기보다 사용자 도달 범위를 고려한 전략을 권합니다.

그래서 MVP의 첫 결정은 “낮은 신뢰 신호면 무조건 차단”이 아니라, 각 경우에 무엇을 할지 적는 일입니다. 예를 들어 정상 범위에서는 요청을 계속 처리하고, 확인이 더 필요한 범위에서는 추가 인증이나 지원 안내를 보여 주며, 요청 자체가 기대값과 맞지 않으면 처리 보류와 서버 로그 검토로 이어지게 할 수 있습니다. 어떤 선택이 맞는지는 서비스의 실제 위험도와 사용자 영향에 따라 달라지므로, 이 글의 예시를 그대로 정책으로 채택하지 마세요.

적용 직후 바로 강제하는 것도 유일한 순서는 아닙니다. Android는 기존 사용자군의 verdict를 먼저 이해할 수 있도록 enforcement 없이 구현해 관찰한 뒤, 계획한 강제의 영향을 추정하고 전략을 조정할 수 있다고 안내합니다. 이때도 개인을 추적하기 위한 새 데이터를 만들기보다, 현재 서비스가 합법적으로 수집·보관하는 범위와 필요한 법무·보안 검토 안에서 관찰 항목을 정해야 합니다.

5. 오류·만료·서비스 장애는 별도의 사용자 흐름으로 남기세요

신호를 요청하는 과정은 항상 같은 결과를 돌려주지 않을 수 있습니다. Android 문서는 token provider가 오래 유지되면 다음 요청에서 만료 오류가 날 수 있으며 새 provider를 요청해 처리하라고 설명합니다. 또한 예상치 못한 문제나 대규모 장애 때 백엔드가 어떻게 동작할지 미리 계획하고, 사용자에게 가능한 경우 재시도·인터넷 연결·Play Store 업데이트 같은 실행 가능한 안내를 제공하라고 권합니다.

따라서 출시 전 QA에는 정상 신호만 넣지 마세요. 네트워크 오류, provider 갱신, 서버 검증 실패, 시간 초과, Play 측 장애처럼 팀이 실제로 안내해야 할 경우를 구분합니다. 각 경우에 사용자가 다시 시도할 수 있는지, 기다려야 하는지, 중요한 행동을 잠시 보류하는지, 지원으로 이어지는지를 화면·서버·운영 기록에서 일치시켜야 합니다.

오류 문구를 요청 상태와 섞지 않는 기준은 앱 MVP 네트워크 오류 안내 글에서도 확인할 수 있습니다. 무결성 신호가 기대와 다름, 네트워크가 끊김, 서버가 처리 중임은 사용자에게 필요한 다음 행동이 서로 다를 수 있습니다.

출시 전 다섯 줄로 점검하세요

1. 보호하려는 사용자 행동과 정확한 서버 요청을 한 줄로 적습니다.

2. 그 요청의 어떤 값을 requestHash 또는 nonce 검증에 연결할지 정하고, 민감한 원문은 넣지 않습니다.

3. 앱에서 받은 token을 백엔드가 어떻게 해석·대조하고 서비스 규칙을 적용하는지 책임 경계를 적습니다.

4. 정상·추가 확인·처리 보류·지원 안내를 어떤 경우에 구분할지 사용자 영향과 함께 정합니다.

5. 만료·네트워크·서버 검증 실패·서비스 장애에서 재시도와 안내가 실제 기기·서버 환경에서 맞는지 QA 기록을 남깁니다.

앱 무결성 신호는 단일 스위치가 아니라, 중요한 요청을 어느 근거로 처리할지 정하는 제품·서버의 경계입니다. 유인어스는 민간 사업 지원 서비스이며, 이 글은 개별 앱의 보안·개인정보 적합성, 악용 방지, 플랫폼 심사·출시 결과 또는 사업 성과를 보장하지 않습니다. 실제 구현과 판단은 최신 Android 문서, 현재 코드와 백엔드, 지원 기기·배포 경로, 서비스의 위험도와 필요한 보안·법무 검토를 바탕으로 하세요.

우리 앱 MVP의 중요 요청 흐름 점검하기

자주 묻는 질문

Play Integrity API를 넣으면 모든 부정 이용을 막을 수 있나요?

그렇게 단정할 수 없습니다. Android 문서는 이 API를 전체 악용 대응 전략의 일부로 사용하고 다른 적절한 보안 관행과 함께 적용하라고 안내합니다. 실제 대응 범위는 서비스의 위험도와 현재 구현을 기준으로 별도로 정해야 합니다.

무결성 token은 앱에서 확인하고 바로 중요한 요청을 처리해도 되나요?

중요 요청과 token의 연결, 결과 해석, 서비스 규칙 적용은 백엔드 경계에서 명확히 정하는 편이 좋습니다. Android의 standard request 흐름도 앱이 token을 백엔드로 보내고 서버가 Google Play에서 결과를 확인한 뒤 다음 행동을 정하는 구조를 설명합니다.

requestHash에 비밀번호나 인증번호를 넣어도 되나요?

민감한 원문을 넣지 마세요. Android 문서는 requestHash와 nonce에 쓰는 데이터가 앱과 Google에 평문으로 보일 수 있다고 주의하며, 입력값을 암호화하거나 해시해 전달하라고 안내합니다. 실제 데이터 처리 방식은 서비스의 보안·법무 검토와 함께 정해야 합니다.

기대와 다른 verdict가 나오면 사용자를 즉시 차단해야 하나요?

항상 같은 대응이 정답은 아닙니다. Android는 결과별로 백엔드가 다르게 행동하는 단계형 전략을 설명합니다. 서비스의 위험도와 사용자 영향에 맞춰 계속 진행, 추가 확인, 처리 보류, 지원 안내를 나누고 실제 사용자군의 신호를 관찰한 뒤 조정하세요.

공식 출처

• Android Developers · Overview of the Play Integrity API

• Android Developers · Make a standard API request