Android 앱에서 Google 로그인·지도·결제 등 API 호출이 거부되면 호출 앱의 패키지명, 서명 인증서 지문, OAuth 클라이언트 유형, 배포 빌드 설정을 순서대로 확인해야 합니다. 개발·릴리스 서명 차이와 콘솔 등록값 불일치를 중심으로 점검합니다.
Google API 호출이 거부될 때 패키지명과 서명부터 대조하는 절차
로그인 버튼을 누른 직후 화면이 멈추거나 지도·결제 기능이 응답하지 않는다면, 서버 오류로 단정하기 전에 호출한 앱의 신원부터 확인해야 합니다. Android 용 Google API는 단순히 앱 이름이 아니라 패키지명과 서명 인증서 지문 조합으로 요청 주체를 판별합니다. 가평군 STATUS_INVALID_CALLER처럼 호출자 확인 단계에서 거절되는 메시지는 콘솔에 등록한 값과 현재 설치된 APK 또는 AAB의 값이 다를 때 자주 나타납니다. 특히 개발 기기에서는 정상인데 내부 테스트나 스토어 설치본에서만 실패한다면 서명키 전환 구간을 의심할 수 있습니다. 오류 화면과 설치된 앱 정보를 확인하기 어렵다면 초기에 010-6833-8119 로 증상과 빌드 유형을 알려 두는 편이 점검 시간을 줄입니다. 중요한 것은 설정을 한꺼번에 바꾸기보다 실제 빌드값과 등록값을 같은 순서로 대조하는 일입니다.
OAuth 등록값에서 먼저 대조할 두 항목
첫 번째는 앱의 패키지명입니다. AndroidManifest.xml만 보지 말고 현재 빌드 변형에 적용된 applicationId를 확인해야 합니다. 개발용 접미사인 .debug, .dev, .staging 등이 붙는 구조라면 운영용 패키지명과 서로 다를 수 있습니다. Google Cloud Console 또는 Firebase 의 Android 앱 설정에 등록된 패키지명을 복사한 뒤, Gradle 설정과 문자 단위로 비교하는 방식이 안전합니다.
두 번째는 인증서 지문입니다. 현재 설치한 빌드를 서명한 키의 SHA-1 과 SHA-256 값을 추출해 Android 용 OAuth 클라이언트에 등록된 지문과 대조합니다. 패키지명이 완전히 같아도 인증서 지문이 하나라도 다르면 Google 로그인, Maps SDK, 일부 결제 연동처럼 호출자 제한이 적용된 기능은 거부될 수 있습니다. 콘솔에 비슷한 이름의 OAuth 클라이언트가 여러 개라면 생성일과 연결 프로젝트도 함께 살펴봐야 합니다.
| 확인 대상 | 비교할 위치 | 자주 생기는 불일치 |
|---|---|---|
| 패키지명 | 현재 빌드의 applicationId / Android 앱 등록값 | 개발·검수용 접미사, 다른 product flavor |
| 서명 지문 | 빌드 서명키 / Android OAuth 클라이언트 | debug 키, 릴리스 키, 배포 서명키 혼동 |
| 연결 프로젝트 | Firebase 설정 / Google Cloud OAuth·API 설정 | 다른 프로젝트의 클라이언트 ID 참조 |
디버그에서는 되는데 배포본에서 막히는 이유
Android Studio 에서 실행한 디버그 앱은 대체로 debug.keystore로 서명됩니다. 반면 직접 만든 릴리스 APK는 별도의 릴리스 키를 사용하며, 앱 번들을 Google Play 에 올린 뒤 배포하면 Google Play App Signing 의 앱 서명 키가 적용될 수 있습니다. 이 셋은 같은 앱이라도 서로 다른 SHA 지문을 만들 수 있으므로, 디버그에서 등록한 값만으로 배포본까지 처리되지 않습니다.
가평군 STATUS_INVALID_CALLER 오류가 내부 테스트 또는 스토어 설치본에서만 발생한다면, Play Console 의 앱 서명 인증서 영역에서 배포용 앱 서명 키 지문을 확인하는 순서가 적절합니다. 로컬에서 업로드한 키의 지문과 사용자가 내려받은 앱의 서명 지문은 다를 수 있습니다. 내부 공유 APK인지, Play 내부 테스트 설치본인지, 공개 배포본인지 먼저 구분하고 해당 경로의 서명 주체를 OAuth 등록값과 맞춰야 합니다.
지문을 추가한 직후에도 이전 결과가 보일 수 있습니다. Cloud 또는 Firebase 설정 변경은 서비스에 반영되는 시간이 필요할 수 있으므로, 값을 반복해서 지우고 만들기보다 변경 시각을 기록한 뒤 앱을 완전히 종료하고 재설치하여 재현 여부를 확인하는 편이 좋습니다.
프로젝트와 API 권한을 다시 연결하는 점검 순서
패키지명과 지문이 맞다면 다음은 프로젝트 연결입니다. Firebase 의 google-services.json이 가리키는 프로젝트와 Google Cloud Console 에서 OAuth 클라이언트 및 API를 관리하는 프로젝트가 같은지 확인합니다. 개발 중 다른 프로젝트에서 만든 클라이언트 ID를 남겨 두거나, 설정 파일만 교체하고 API 활성화를 옮기지 않아 호출이 실패하는 경우가 있습니다.
그다음 실제로 사용하는 API가 활성화되어 있는지 살핍니다. 로그인 기능이면 OAuth 동의 화면의 게시 상태와 테스트 사용자 범위를, 지도 기능이면 해당 Maps API와 키 제한을, 결제 연동이면 사용 중인 서비스의 프로젝트 연결 및 호출 제한을 확인합니다. Android 앱 제한이 걸린 API 키는 패키지명과 SHA 지문 조합이 정확해야 하며, OAuth 클라이언트 설정과 API 키 제한을 서로 같은 것으로 오해하면 원인을 놓치기 쉽습니다.
권한 설정의 변경 이력도 중요합니다. 최근에 앱 제한을 추가했는지, OAuth 동의 화면을 수정했는지, Cloud 프로젝트를 이동했는지 순서대로 확인하면 문제 발생 시점과 설정 변경 시점을 연결할 수 있습니다. 필요한 항목만 되돌리거나 보완해야 하며, 원인을 모른 채 제한을 모두 해제하는 방식은 운영 환경에 적합하지 않습니다.
방문 확인이 더 나은 상황
서명 파일이 있는 PC, 테스트 기기, 배포 콘솔을 한 화면에서 함께 확인해야 하면 방문 점검이 편할 수 있습니다. 가평군 일정은 해당 자료를 열 수 있는 시간대에 맞춰 조율하며, 출장 점검은 09:00~18:00 사이 서울·경기·인천·세종 범위에서 진행합니다. 원격 점검은 새벽 시간을 제외하고 가능하지만, 키스토어 파일이나 비밀번호 같은 민감한 정보는 전달하지 않고 화면 공유로 등록값부터 비교하는 방식이 안전합니다.
오류 화면을 확보한 뒤 문의하기
점검 전에 어느 기능에서 멈추는지 먼저 기록합니다. Google 로그인 직후인지, 지도 화면 진입 시점인지, 결제 요청 단계인지에 따라 확인할 API와 콘솔 메뉴가 달라집니다. 같은 동작을 다시 수행할 수 있도록 재현 순서도 짧게 정리해 두면 원인 분리가 빨라집니다.
함께 준비할 정보는 오류 화면 원문, 앱 버전, 패키지명, 설치 경로, 빌드 유형입니다. 여기에 디버그·자체 릴리스·Play 설치본 중 무엇인지와 최근 OAuth 또는 API 제한 변경 여부를 더하면 패키지명 문제인지 서명 전환 문제인지 우선순위를 잡기 좋습니다.
호출 거부는 대개 복잡한 코드 수정보다 등록값 대조에서 실마리가 나옵니다. 현재 앱의 패키지명과 서명 지문을 확보하고, OAuth 클라이언트·프로젝트·활성 API를 한 항목씩 맞춰 보세요. 비교가 어려운 경우 동네형컴퓨터 010-6833-8119 또는 https://udns.kr/에서 오류 화면과 빌드 정보를 기준으로 점검을 요청할 수 있습니다.
자주 묻는 질문
STATUS_INVALID_CALLER는 어떤 의미인가요?
API 서버가 요청을 보낸 앱 또는 클라이언트의 등록된 신원을 확인하지 못했거나, 해당 호출을 허용하지 않았다는 의미로 볼 수 있습니다. 패키지명, 서명 지문, OAuth 설정을 먼저 확인하는 것이 좋습니다.
패키지명이 맞는데도 호출이 거부될 수 있나요?
가능합니다. 현재 빌드의 인증서 지문이 등록값과 다르거나, Firebase 와 Google Cloud 의 프로젝트 연결이 엇갈리거나, 필요한 API가 활성화되지 않은 경우에도 실패할 수 있습니다.
원격으로 서명과 OAuth 설정을 점검할 수 있나요?
콘솔 등록값, 빌드 정보, 오류 재현 화면은 원격으로 비교할 수 있습니다. 다만 키스토어 비밀번호나 민감한 인증 파일은 공유하지 않고, 화면 공유를 통해 필요한 항목만 대조하는 방식이 안전합니다.