[Google OAuth][운영] 승인된 앱에서 이름·로고·redirect URI를 바꾼 뒤 re-verification이 걸릴 때 무엇부터 다시 제출하나
IT 리서치 노트
[Google OAuth][운영] 승인된 앱에서 이름·로고·redirect URI를 바꾼 뒤 re-verification이 걸릴 때 무엇부터 다시 제출하나
Google OAuth 앱이 이미 승인된 상태라도 이름, 로고, redirect URI, 홈페이지 같은 표면 정보를 바꾸면 다시 검토가 걸릴 수 있다. 2026년 8월 5일 기준 Google 도움말을 다시 보면, 승인된 앱 변경은 scope 확대가 없어도 re-verification 대상이 될 수 있고 brand verification 요구로 이어질 수 있다. 이 글은 변경 뒤 무엇부터 다시 제출해야 시간을 덜 쓰는지 정리한 것이다.
1. 개요
결론부터 말하면 승인된 앱 변경은 scope 변경과 별개로 다시 검토가 걸릴 수 있다. 이름, 로고, redirect URI, 홈페이지, privacy policy처럼 consent screen에 드러나는 요소를 바꿨다면 먼저 brand verification 관점으로 정리해야 한다.
가장 짧은 순서는 변경 diff를 분류하고, live consent screen과 branding 화면 일치를 확인하고, 그다음 reviewer용 증거 묶음을 갱신하는 것이다. scope justification은 scope가 실제로 바뀐 경우에만 뒤이어 본다.
2. 어디서 실제로 막히는가
실무에서 자주 꼬이는 이유는 승인 이력이 있다는 안도감 때문이다. 많은 팀이 scope를 안 늘렸으니 재검토가 없을 것이라고 보지만, Google 도움말은 이름, 로고, redirect URI, 홈페이지, privacy policy 링크 수정만으로도 다시 brand verification을 요구할 수 있다고 적고 있다.
또 redirect URI 변경은 단순 설정 수정으로 보이지만 reviewer 입장에서는 데모 흐름의 실제 로그인 완료 경로가 달라진다. 그래서 branding 자료와 demo video, live consent screen 캡처를 같은 변경 집합으로 묶어 두지 않으면 제출 후 설명이 끊긴다. 운영자는 새 URI를 등록하고, 로그인 경로를 다시 확인하고, live consent screen을 캡처하고, reviewer 계정을 점검하고, 제출 메모까지 함께 갱신해야 한다.
홈페이지나 privacy policy 링크만 바꾼 경우도 가볍게 보면 안 된다. 링크를 열어 보고, 접근 여부를 확인하고, 새 브랜드 값과 문서 내용이 맞는지 비교하고, 실제 consent 화면의 링크 텍스트까지 검증해야 reviewer와 운영팀이 같은 변경 집합을 보게 된다. 이 과정을 생략하면 같은 앱인데도 보이는 정체성이 달라 보여 재검토가 길어질 수 있다.
- 증상: 승인된 앱인데 변경 후 반영이 지연되거나 다시 검토로 돌아간다.
- 실패: scope가 그대로라는 이유로 brand verification 재검토를 무시한다.
- 막힘: redirect URI 변경 후 demo video와 reviewer 계정 흐름을 갱신하지 않는다.
- 누락: live consent screen 증거를 새 branding 값과 맞춰 저장하지 않는다.
3. 실무에서 적용하는 순서
실무 순서는 다섯 단계가 짧다. 먼저 변경 항목을 이름·로고·redirect·링크·scope로 분리한다. 다음으로 live consent screen과 branding 값을 대조한다. 세 번째로 redirect URI가 바뀌었다면 reviewer가 실제 로그인 완료 경로까지 볼 수 있는지 확인한다. 네 번째로 demo video와 제출 메모를 바뀐 값 기준으로 다시 만든다. 마지막으로 scope가 늘어난 경우에만 justification과 verification package를 추가로 갱신한다.
- 변경 diff를 항목별로 나눈다.
- live consent screen과 branding 값을 맞춘다.
- redirect URI 변경 시 실제 로그인 경로를 다시 캡처한다.
- reviewer video와 제출 메모를 새 값 기준으로 갱신한다.
- scope 변화가 있을 때만 justification을 추가 정리한다.
checklist:
1. change diff 분류
2. live consent screen 캡처
3. branding 값 대조
4. redirect login 흐름 재확인
5. reviewer video 갱신
6. authorized domains 재확인
7. scope justification 필요 여부 판단이렇게 하면 reviewer가 묻는 질문도 짧아진다. 어떤 값이 바뀌었고, 그 값이 실제 사용자 화면과 일치하며, 데모 흐름이 새 redirect 경로까지 통과한다는 증거를 바로 보여 줄 수 있기 때문이다.
4. 공식 문서와 예시 화면으로 확인하기
첫 자료는 Google의 Changes to approved app 도움말이다. 이미 승인된 앱도 consent screen 구성이나 developer project를 바꾸면 다시 검증 대상이 될 수 있다고 명시한다.
즉 기존 승인 이력이 있다고 바로 반영되는 것은 아니다. 운영자는 변경 종류를 먼저 분류하고, 어떤 변경이 brand verification 재제출을 유발하는지 확인해야 한다.
두 번째 공식 화면은 재검증을 다시 요구하는 변경 목록이다. 이름, 로고, redirect URI, 홈페이지, privacy policy 변경은 brand verification 재제출과 바로 연결된다.
이 목록이 중요하다. scope가 그대로여도 브랜드 관련 변경만으로 다시 검토가 필요할 수 있기 때문에, 팀이 '민감 scope를 안 늘렸으니 괜찮다'고 판단하면 놓치기 쉽다.
세 번째 자료는 Verification requirements의 brand verification 섹션이다. Google은 앱이 자신의 정체성과 의도를 정확히 대표해야 한다는 관점에서 brand verification을 설명한다.
따라서 변경 후 제출 자료도 같은 방향으로 정리해야 한다. 새 로고, 새 홈페이지, 새 redirect 경로가 실제 live consent screen과 일치하는지부터 확인하는 편이 빠르다.
네 번째 자료는 변경 유형별 triage 표다. redirect URI와 로고 변경은 같은 재검증처럼 보여도 먼저 확인할 화면과 첨부 근거가 조금 다르다.
이미 auto-cancelled triage 글을 봤다면, 이번 표는 상태값이 아니라 변경 항목 중심의 재제출 순서다.
마지막 자료는 재제출 체크리스트다. brand verification 재검토가 걸렸을 때 실제 제출 묶음을 어떤 순서로 확인할지 메모 형태로 적었다.
이렇게 남기면 reviewer와 운영팀이 같은 변경 집합을 보고 이야기할 수 있다. demo video 재검증 글과 연결하면 제출물 묶음이 더 안정된다.
5. 주의사항과 리스크
첫 번째 리스크는 brand 변경과 scope 변경을 같은 원인으로 취급하는 것이다. 두 번째는 redirect URI만 바꾸고 live consent screen 또는 데모 흐름 증거를 갱신하지 않는 것이다. 세 번째는 홈페이지와 privacy policy 링크를 바꿨지만 접근성 확인을 안 하는 것이다.
운영 전에 확인할 때는 변경된 표면 정보가 실제 consent screen과 일치하는지, reviewer가 새 로그인 경로를 끝까지 따라갈 수 있는지, 그리고 제출 메모가 그 diff를 정확히 설명하는지 세 가지만 먼저 보면 된다.
6. 결론
승인된 Google OAuth 앱에서 이름, 로고, redirect URI를 바꾼 뒤 다시 검토가 걸렸다면 먼저 brand verification 관점으로 정리해야 한다. 변경 diff와 실제 사용자 화면 증거를 먼저 맞추면, reviewer video와 추가 제출도 훨씬 짧아진다.
- 승인 이력만 믿고 재검토 가능성을 무시하지 않는다.
- 변경 diff와 live consent screen을 같이 저장한다.
- redirect URI가 바뀌면 reviewer 흐름도 반드시 갱신한다.