구글 색인 API 승인 신청서 돌연 증발: 하루 200건 기본 쿼터는 이제 정식 배포용인가

수개월 먹통이던 승인 링크의 기습 삭제: 구글 인덱싱 API 문서 개편이 던진 신호

채용 정보 포털이나 실시간 스트리밍 방송 플랫폼을 운영하는 기술팀에게 구글의 인덱싱 API(Indexing API)는 일종의 고속도로 하이패스 같은 도구였다. 웹사이트에 새 채용공고가 올라오거나 마감되었을 때 구글 검색 로봇이 스스로 찾아오길 기다리지 않고, “이 주소를 지금 즉시 크롤링하라”고 구글 서버에 직접 신호를 쏘는 통로이기 때문이다.

그런데 10월 16일, 구글이 이 핵심 도구의 공식 개발자 문서에서 수년 동안 유지해 온 ‘사용 승인 신청서(Approval Form)‘와 추가 쿼터 신청 안내 문구를 흔적도 없이 지워버렸다.

그동안 구글 개발자 문서는 인덱싱 API를 등록할 때 제공되는 하루 200건의 호출 한도를 단순한 ‘초기 셋업 및 테스트용(For Testing)‘으로 규정해 왔다. 실제 서비스 운영에 투입하려면 구글이 마련한 양식을 제출하고 승인을 받아 쿼터를 정식으로 할당받아야 한다는 전제 조건이 붙어 있었다.

하지만 현실은 딴판이었다. 수많은 채용 플랫폼 운영진이 수개월 전에 제출한 승인 신청서는 구글 내부에서 아무런 답변 없이 멈춰 있었다. 심사 기한도, 진행 상태도 확인할 길이 없는 상태에서 글로벌 개발자들의 불만이 쌓여가던 와중이었다.

구글은 변경 기록을 통해 “현재 쿼터 제한과 절차를 정확히 반영하고 오래된 양식을 정리하기 위한 개편”이라고 설명했다. 그러나 승인 심사 자체가 완전히 폐지된 것인지, 아니면 추가 쿼터 발급 창구를 아예 닫아버린 것인지 명확한 입장을 밝히지 않아 현업 엔지니어링팀의 혼란이 가중되고 있다.

하루 200건과 분당 380건: 개편 전후 인덱싱 API 운영 규칙 대조

이번 문서 개편에서 가장 눈에 띄는 변화는 문구의 삭제다. 구글은 빠른 시작 가이드(Quickstart)의 첫 단계에 적혀 있던 ‘승인 및 쿼터 요청’ 안내를 지웠고, 사용 가이드 본문에서 인덱싱 API 쿼터가 단순 ‘테스트용’이라고 적혀 있던 세 군데의 문장을 모두 걷어냈다.

반면 실제 작동하는 물리적 수치 한도는 이전과 정확히 동일하게 유지되고 있다. 구글 클라우드 콘솔에서 프로젝트를 개설했을 때 주어지는 일일 발행 한도와 분당 처리량은 그대로다.

위의 실제 수치가 보여주듯, 구글이 ‘테스트용’이라는 딱지를 뗐다고 해서 API를 대규모로 쓸 수 있게 된 것은 아니다. 하루 200건은 신규 공고 등록(URL_UPDATED)과 마감 공고 삭제(URL_DELETED)가 같은 밥그릇을 나눠 쓰는 구조다. 공고 100개를 새로 등록하고 마감된 공고 100개를 삭제 요청하면 그날의 호출 한도는 완전히 바닥난다.

대규모 채용 플랫폼과 방송사 검색 노출에 닥친 3대 병목 지점

공식 승인 신청 창구가 닫히면서 구글 검색 생태계에 의존하는 채용 정보 포털, 인력 매칭 플랫폼, 온라인 스트리밍 운영사는 세 가지 직접적인 운영 압박을 받게 되었다.

하루 200건 쿼터 한계와 수천 건 채용공고의 충돌

중소규모 사이트라면 하루 200건의 제한 안에서 핵심 공고 위주로 운영할 수 있다. 하지만 매일 수천 건의 구인 구직 정보가 오가는 엔터프라이즈급 채용 플랫폼에서는 이야기가 완전히 다르다.

신청 양식이 사라진 현시점에서 구글로부터 쿼터를 수만 건 단위로 늘려 받을 수 있는 공식 창구가 봉쇄되었다. 기존에 쿼터 증설을 요청하고 수개월 동안 회신을 기다리던 기업들은 기존 신청 건이 심사 중인지, 아니면 휴지통에 들어갔는지조차 알 수 없는 상태다. 결과적으로 하루 200건을 넘어서는 초과 공고들은 실시간 API 호출 대기열에 올리지 못하고 일반 크롤링 경로로 밀려날 수밖에 없다.

승인 대기 폐지로 인한 초기 출시 속도 변화

역설적이게도 이번 개편은 서비스를 갓 시작하는 신생 플랫폼에는 긍정적인 신호로 작용한다.

과거에는 구글 문서에 “테스트용이므로 실제 운영에 쓰려면 추가 승인을 받아야 한다”고 적혀 있어, 법적 검토나 운영 정책을 중시하는 기업들은 구글의 답장이 올 때까지 인덱싱 API 연동 배포를 차일피일 미루곤 했다. 그러나 이제 해당 문구가 삭제되었으므로, 하루 200건 이하의 작은 규모로 시작하는 신규 서비스는 별도의 승인 대기 기간 없이 즉시 프로덕션 환경에 API를 붙여 구글 봇을 호출할 수 있게 되었다.

멀티 계정 꼼수 원천 차단과 스팸 제재 위험

하루 200건이라는 빡빡한 한도를 우회하기 위해 일부 개발팀에서는 구글 클라우드 프로젝트를 여러 개 쪼개서 만들거나 다중 서비스 계정을 발급받는 방식을 쓰곤 했다. 프로젝트 10개를 만들면 하루 2,000건을 쏠 수 있다는 계산에서다.

구글은 이번 문서 개편에서도 이 점을 명시적으로 경고했다. 사용 가이드 페이지는 구글의 스팸 정책이 모든 인덱싱 API 요청에 동일하게 적용된다는 점을 재확인하며, “여러 계정을 생성하여 제출 한도를 우회하려는 행위”를 금지 사항으로 못 박았다. 만약 비정상적인 다중 계정 패턴이 적발될 경우 개별 API 차단에 그치지 않고 도메인 전체가 구글 검색 색인에서 완전히 제외되는 수동 조치(Manual Action)를 당할 수 있다.

색인 API 의존을 낮추는 이원화 크롤링 및 완충 시스템

구글의 인덱싱 API 지원 창구가 불투명해진 지금, 특정 API에만 목을 매는 아키텍처는 치명적인 약점이 된다. 실제로 구글의 공식 채용공고 검색 가이드라인(Job Posting Guidelines)은 여전히 개별 URL 통보에는 인덱싱 API를 권장하면서도, 전체 사이트 커버리지를 확보하기 위해서는 반드시 XML 사이트맵(Sitemap)을 함께 병용하라고 명시하고 있다.

현업 기술팀이 즉시 구축해야 할 완충 시스템의 핵심은 ‘스마트 라우팅’이다. 하루에 발생하는 수천 건의 데이터 변경 사항 중에서 구글 검색에 1분이라도 빨리 노출되어야 하는 ‘고가치 공고’ 상위 200개를 우선 선별한다. 이 물량만 인덱싱 API로 쏘아 즉각적인 색인을 유도하고, 나머지 일반 공고나 마감 처리는 잘 정돈된 XML 사이트맵을 통해 구글 봇이 긁어가도록 유도하는 방식이다.

이러한 파이프라인을 운영할 때는 구글 클라우드 콘솔의 할당량 페이지를 주기적으로 점검해야 하며, 백엔드 호출 실패율과 API 응답 지연을 방지하기 위해 Datadog 같은 모니터링 체계를 연동하여 429 한도 초과 에러가 발생하는지 상시 감시해야 한다.

실무 리스크 완화 및 위기 대응 3단계 방어선

구글이 명확한 추가 공지를 내놓기 전까지, 검색 기반 플랫폼 실무진은 보수적이면서도 빈틈없는 운영 체계를 가동해야 한다. 막연히 구글의 추가 쿼터 양식이 다시 열리기를 기다리는 것은 사업 운영상 위험이 너무 크다.

1차 방어선: 즉각적인 색인 요청 현황 및 쿼터 잔여량 점검

• 프로젝트별 호출 성공률 전수 조사: 구글 클라우드 콘솔에 접속하여 최근 30일간의 인덱싱 API 호출 성공률과 에러 코드를 점검한다. 매일 자정 직전에 429 에러(Quota Exceeded)가 빈번하게 찍히고 있다면 이미 서비스에 병목이 발생하고 있다는 뜻이다.
• 다중 계정 우회 로직 즉시 폐기: 트래픽을 늘리기 위해 프로젝트를 임의로 복제해 분산 호출하고 있는 편법이 사내 코드베이스에 남아 있다면 즉각 걷어내야 한다. 구글의 스팸 탐지 시스템이 강화되는 시점에 도메인 전체 신뢰도가 추락할 수 있다.

2차 방어선: 사이트맵 보완 및 대체 크롤링 유도 체계 재설계

• XML 사이트맵 갱신 주기 단축: 하루 200건을 초과하는 대다수 공고는 사이트맵에 의존해야 한다. 신규 공고가 등록되거나 마감될 때마다 사이트맵 파일의 <lastmod> 태그를 정확한 UTC 타임스탬프로 실시간 갱신하고, 구글 서치 콘솔(Google Search Console)을 통해 사이트맵 인덱스를 정기적으로 재전송해야 한다.
• RSS/아톰 피드(Feed) 백업 라우팅 구성: 사이트맵 외에도 최신 갱신 공고 100–200개를 담은 실시간 피드를 발행하여, 구글봇이 사이트맵 파싱 주기보다 더 빠르게 신규 페이지의 존재를 눈치챌 수 있도록 크롤링 유도 경로를 겹겹이 깔아야 한다.

3차 방어선: 스팸 알고리즘 트리거 방지를 위한 구조화 데이터 검증

• JSON-LD 스키마 마크업 무결성 확인: 인덱싱 API는 무조건 JobPosting이나 BroadcastEvent 구조화 데이터가 심겨 있는 페이지만을 대상으로 한다. API를 호출했더라도 구글 봇이 방문했을 때 스키마 데이터가 누락되어 있거나 필수 속성(급여, 마감일, 근무지 등)이 빠져 있으면 색인 자체가 거절된다.
• 마감 공고의 404/410 처리 파이프라인 정비: 채용이 끝난 공고를 검색 결과에 방치하면 사용자 경험을 해치고 구글의 페널티를 받는다. API 쿼터가 부족해 URL_DELETED를 즉각 전송하지 못하더라도, 브라우저와 검색 봇 접근 시 즉시 HTTP 410(Gone) 상태 코드를 뱉어내도록 웹 서버 응답을 최적화해야 한다.