AI 에이전트가 Google Search Console(구글 서치 콘솔) 데이터에 접근하게 만드는 현실적인 방법은 여섯 가지예요. 호스팅형 OAuth 커넥터, 커뮤니티 MCP 서버, Search Console API 직접 연동, BigQuery 대량 내보내기, 스프레드시트 브리지, 그리고 에이전트 없이 Search Console에 내장된 AI 구성 기능을 쓰는 방법이죠. 설정 시간은 2분부터 거의 하루까지 다양하고, 어떤 방법이 맞는지는 16개월이 넘는 기록이 필요한지에 따라 갈려요.
이 마지막 조건이 갈림길이니 먼저 짚고 넘어갈게요. Search Analytics API는 요청 한 번에 최대 25,000행을 반환하고, 기록은 16개월까지만 보관해요. 16개월이 지나면 데이터는 사라져요. 숨겨지는 게 아니라 삭제돼요. 더 긴 기록이 필요하다면 아래 목록 중 딱 한 가지 방법만 그걸 해결해 주고, 그것도 필요해지기 전에 미리 시작해 둬야 해요.
방법 1: 호스팅형 OAuth 커넥터
설정: 2~5분. 코드 불필요.
SEO 에이전트 제품에 Google 계정 권한을 부여하고 속성을 고르면, 연결 정보가 서버에 저장되어 매번 쿼리할 때마다 재사용돼요. 대부분의 마케터에게 권하는 방법인데, 귀찮아서가 아니라 실패할 수 있는 지점을 대신 처리해 주기 때문이에요. 잘 만든 커넥터는 연결이 없으면 추측하지 않고 연결하라고 안내하고, 속성을 여러 개 갖고 있으면 어떤 속성을 쓸지 정리해 주며, 25,000행 한도를 넘는 결과도 알아서 페이지를 나눠 가져와요.
저희 구현에서는 Search Console 도구가 읽기 전용으로 태그되어 있고, 처음 호출할 때 활성 연결이 있는지 확인해요. 연결이 없으면 통합(integrations) 화면으로 바로 이어지는 대화형 연결 안내를 띄우고, 연결을 마치고 돌아오면 대화를 그대로 이어가요.
단점: 공급업체가 만들어 둔 도구 목록만 쓸 수 있어요. 그들이 구현하지 않은 형태의 쿼리가 필요하다면 방법이 없어요.
방법 2: Search Console MCP 서버
설정: 15~45분. 개발에 익숙해야 해요.
Model Context Protocol(MCP)은 AI 어시스턴트를 외부 시스템에 연결하기 위한 개방형 클라이언트/서버 표준이에요. 그래서 Claude Desktop, Claude Code, Cursor처럼 MCP를 지원하는 클라이언트라면 어디서든 Search Console 서버를 직접 호출할 수 있어요.
중요한 주의점이 있어요. Google이 자체 MCP 서버를 공개한 GA4와 달리, Search Console용 공식 Google MCP 서버는 없어요. 대신 탄탄한 커뮤니티 구현체들이 있는데, 예를 들어 mcp-server-gsc는 25,000행 한도까지 검색 분석 데이터를 가져오고 정규식 필터링을 지원하며 읽기 전용이에요.
설정은 MCP 클라이언트에 JSON 블록을 하나 넣어 서버와 인증 정보를 지정하면 끝이에요.
{
"mcpServers": {
"search-console": {
"command": "npx",
"args": ["-y", "mcp-server-gsc"],
"env": { "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/service-account.json" }
}
}
}단점: 검색 데이터에 접근하는 인증 정보를 커뮤니티 패키지에 맡기는 셈이에요. 소스 코드를 직접 읽어 보고, 가능하면 읽기 전용 범위를 쓰고, 버전을 고정하세요. 서버가 구현한 프로토콜 버전이 클라이언트가 기대하는 버전과 맞는지도 확인해야 해요.
방법 3: 서비스 계정으로 Search Console API 직접 사용하기
설정: 1~3시간. 코드를 직접 짜야 해요.
통제권은 가장 크고, 손도 가장 많이 가요. 순서는 이래요.
- Google Cloud 프로젝트를 새로 만들거나 기존 프로젝트를 재사용해요.
- 그 프로젝트에서 Search Console API를 사용 설정해요.
- 서비스 계정을 만들고 JSON 키를 내려받아요.
- 서비스 계정의 이메일 주소를 Search Console 속성 자체에 사용자로 추가해요. 권한은 제한(읽기 전용)으로 주면 돼요.
- 키로 에이전트를 인증하고
searchanalytics.query를 호출해요.
다들 잊어버리는 게 4단계예요. Cloud에서 인증 정보를 만든다고 해서 속성에 대한 접근 권한이 생기지는 않아요. 둘은 별개의 권한 체계이고, 두 번째 단계를 건너뛰면 속성 접근 문제가 아니라 API 사용 설정 문제처럼 보이는 애매한 403 오류가 나요. 한 번쯤은 여기서 20분 정도 날린다고 생각하세요.
페이지 나누기를 포함한 최소한의 쿼리 본문은 다음과 같아요.
{
"startDate": "2026-04-01",
"endDate": "2026-06-30",
"dimensions": ["query", "page"],
"rowLimit": 25000,
"startRow": 0
}페이지마다 startRow를 25,000씩 늘리고, 요청한 것보다 적은 행이 돌아오면 멈추면 돼요. 그 밖의 할당량 처리, 재시도, 토큰 갱신은 이제 전부 직접 만들어야 해요.
단점: 유연성은 완벽하지만, 할당량 처리·페이지 나누기·재시도·토큰 갱신을 모두 직접 책임져야 해요. 어떤 커넥터도 제공하지 않는 형태의 쿼리가 필요하거나, 데이터가 자체 인프라 밖으로 나가면 안 될 때 선택하세요.
방법 4: BigQuery로 대량 내보내기
설정: 약 1시간, 그리고 첫 내보내기가 도착하기까지 최대 48시간.
16개월 문제를 해결하는 유일한 방법이에요. 지금 당장 필요하지 않더라도 오늘 설정해 두는 게 좋아요. 과거 데이터를 거슬러 가져오는 게 아니라 지금부터 앞으로의 기록을 쌓아 가는 방식이거든요.
Google의 대량 데이터 내보내기 문서에 따르면 순서는 이래요.
- 결제가 사용 설정된 Google Cloud 프로젝트를 만들거나 선택해요. 이건 선택 사항이 아니에요.
- 그 프로젝트에서 BigQuery API와 BigQuery Storage API를 사용 설정해요.
- Search Console 서비스 계정에 프로젝트 역할 두 가지를 부여해요. BigQuery Job User와 BigQuery Data Editor예요.
- Search Console에서 설정 → 대량 데이터 내보내기로 들어가 Cloud 프로젝트 ID와 데이터 세트 위치를 입력해요.
- 기다려요. 첫 내보내기는 48시간 안에 도착하고, 그 뒤로는 매일 실행돼요.
본격적으로 시작하기 전에 알아 둘 점이 두 가지 있어요. 첫째, 익명처리된 검색어는 개인정보 보호를 위해 내보내기에서 제외돼요. 그래서 BigQuery 합계가 Search Console 화면의 수치와 정확히 맞지 않아요. 버그가 아니라 원래 그런 거예요. 이걸 모르면 두 데이터를 비교하는 에이전트가 존재하지도 않는 불일치를 보고하게 돼요. 둘째, 데이터 세트 위치는 나중에 처음부터 다시 시작하지 않는 한 바꿀 수 없으니 신중하게 고르세요.
데이터가 BigQuery에 들어오면 에이전트는 Search Console API 대신 SQL로 쿼리해요. 행 한도와 보관 기간 문제가 한 번에 사라지는 거죠. 작은 사이트라면 비용은 BigQuery 무료 등급 안에서 해결되지만, 큰 사이트에서는 실제 비용이 발생해요. 그러니 에이전트에게 테이블 전체를 스캔하지 말고 파티션 날짜 열로 필터링하라고 지시하세요. 대형 속성의 3년 치 데이터에 범위 제한 없는 SELECT *를 날리는 에이전트는 잊지 못할 청구서를 만들어 낼 거예요.
단점: 돈이 들고, 모든 방법 중 인프라가 가장 많이 필요하며, 첫날에는 아무것도 얻을 수 없어요. 하지만 여러 해에 걸친 분석을 할 수 있는 유일한 길이기도 해요.
방법 5: 스프레드시트 브리지
설정: 10~20분. 코드 불필요.
부가기능(add-on)이나 Apps Script로 Search Console 데이터를 정해진 일정에 따라 Google Sheets로 내보낸 뒤, Sheets에 접근할 수 있는 에이전트가 그 시트를 보게 하는 방법이에요. 에이전트가 이미 스프레드시트를 읽을 줄 알고, 오늘 오후 안에 데이터를 넘겨주고 싶을 때 쓸 만한 현실적인 선택지예요.
단점: 데이터는 마지막으로 내보낸 시점만큼만 최신이고, 시트를 구성한 사람이 이미 필터링해 둔 데이터만 볼 수 있어요. 아무도 예상하지 못한 후속 쿼리를 에이전트가 던질 수도 없는데, 사실 그게 에이전트를 쓰는 이유잖아요. 임시방편으로만 생각하세요.
방법 6: 아예 연결하지 않기
설정: 없음.
Search Console에는 AI가 내장되어 있어요. Google의 AI 기반 구성 기능을 쓰면 원하는 분석을 자연어로 설명하기만 해도 보고서 필터, 비교, 측정항목 선택으로 바꿔 줘요. "/blog가 포함된 페이지의 이번 분기 트래픽을 작년 같은 분기와 비교해 줘"라고 하면 알아서 설정돼요.
Google이 분명히 밝힌 한계도 알아 두세요. 검색결과의 실적 보고서에서만 작동하고 Discover나 뉴스에서는 안 돼요. 필터, 비교, 측정항목은 설정해 주지만 표를 정렬하거나 데이터를 내보내지는 못해요. 또 Google은 AI가 요청을 잘못 해석할 수 있다고 경고하니, 분석 결과를 믿기 전에 적용된 필터를 꼭 확인하세요. 그리고 이건 어디까지나 구성 기능이라서, GA4와 Search Console을 함께 놓고 추론하거나 원인을 조사해 주지는 않아요.
이와 별개로, Search Console에는 이제 Google의 AI 기능에서 들어오는 트래픽을 다루는 생성형 AI 실적 보고서도 있어요. 궁금한 게 AI 영역에서의 노출이라면 이게 가장 믿을 만한 출처이고, 어떤 서드파티 추정치도 이를 대신할 수 없어요.
어떤 방법을 골라야 할까요?
| 방법 | 설정 시간 | 16개월 한계 극복 | 추천 대상 |
|---|---|---|---|
| 호스팅형 커넥터 | 2-5분 | 아니요 | 오늘 바로 답을 원하는 마케터 |
| MCP 서버 | 15-45분 | 아니요 | 이미 MCP 클라이언트를 쓰는 개발자 |
| API 직접 연동 | 1-3시간 | 아니요 | 맞춤형 쿼리, 데이터를 사내에 보관해야 할 때 |
| BigQuery 내보내기 | 1시간 + 48시간 | 예 | 여러 해에 걸친 분석, 대형 사이트 |
| 스프레드시트 브리지 | 10-20분 | 아니요 | 임시 해결책 |
| 내장 AI 구성 | 없음 | 아니요 | 보고서를 빠르게 만들 때(원인 조사용은 아님) |
대부분의 팀이 결국 정착하는 조합은 일상적인 질문용 호스팅형 커넥터에, 뒤에서 조용히 돌아가는 BigQuery 내보내기를 더하는 거예요. 그러면 1년 뒤에는 다른 누구도 갖지 못한 기록이 쌓여 있어요. 두 방법은 서로 경쟁하지 않아요.
에이전트에게 Search Console 접근 권한을 줘도 안전할까요?
세 가지 조건만 지키면 꽤 안전해요. 읽기 전용으로 주세요. Search Console 권한에는 사이트맵 제출이나 삭제 요청 같은 기능도 포함되는데, 에이전트에게는 하나도 필요 없어요. 개인 OAuth 권한보다 범위가 제한된 서비스 계정을 쓰세요. 그래야 권한을 회수할 때 직원 한 명의 계정에 좌우되지 않아요. 그리고 쓰기 도구와 웹 가져오기 도구를 분리하세요. 경쟁사 페이지를 읽는 에이전트는 외부에서 작성된 텍스트를 내 지시와 같은 컨텍스트 창에 끌어오게 되는데, 그 페이지에 주입된 명령이 숨어 있으면 순진한 에이전트는 그대로 실행할 수 있어요. 저희 런타임은 가져온 콘텐츠를 신뢰할 수 없는 것으로 격리하고, 해당 턴을 오염된 것으로 표시한 뒤, 사람이 승인하지 않는 한 그 턴이 끝날 때까지 쓰기 태그가 붙은 모든 도구를 거부해요. Search Console 쿼리는 읽기 태그가 붙어 있으니 어느 쪽이든 안전해요.
자주 나는 설정 오류와 그 진짜 의미
| 증상 | 흔한 원인 | 해결 방법 |
|---|---|---|
| API를 사용 설정했는데 모든 쿼리에서 403 | 서비스 계정을 속성에 사용자로 추가하지 않음 | Search Console 속성 설정에서 해당 이메일을 제한 권한으로 추가 |
| 오류 없이 결과가 비어 있음 | 속성 URL 불일치: 도메인 속성과 URL 접두어 속성 혼동, 또는 끝의 슬래시 누락 | Search Console에 표시된 속성 문자열을 그대로 복사 |
| 에이전트가 의심스러울 만큼 딱 떨어지는 합계를 보고함 | 결과가 25,000행 한도에서 잘렸는데 전체로 취급함 | startRow로 페이지를 나누거나, 잘림을 표시하도록 에이전트에 요구 |
| 수치가 Search Console 화면과 다름 | BigQuery 내보내기에서 익명처리된 검색어가 제외됨, 또는 날짜 경계가 다름 | BigQuery라면 정상. 아니라면 시간대와 절대 날짜 확인 |
| 대량 내보내기를 설정했는데 데이터 세트가 안 보임 | 아직 48시간 이내이거나 프로젝트에 결제가 설정되지 않음 | 기다린 뒤 결제와 IAM 역할 두 가지를 확인 |
| MCP 서버는 실행되는데 도구가 하나도 안 보임 | 인증 정보 경로가 잘못됐거나 클라이언트와 프로토콜 버전이 맞지 않음 | env 경로가 제대로 잡히는지, 서버가 지원하는 사양 버전을 확인 |
어떤 방법을 고르든 꼭 지켜야 할 두 가지
페이지 나누기를 정직하게 처리하세요. 25,000행을 요청해서 정확히 25,000행을 받고 합계를 보고하는 에이전트는 사실 잘린 결과를 보고하는 거예요. 페이지를 나눠 가져오거나, 결과가 한도에 걸렸다고 명시하도록 지시하세요.
절대 날짜를 쓰세요. "지난달" 같은 상대적 표현은 속성의 시간대와 쿼리가 실행된 시점을 기준으로 해석돼요. 자신감 넘치고 논리도 그럴듯한데 틀린 Search Console 분석이 나오는 가장 흔한 원인이 바로 이거예요.
연결을 마쳤다면 에이전트가 Search Console 데이터에서 실제로 찾아낼 수 있는 것에서 해 볼 만한 분석을 확인해 보세요. 방법 1에서 설명한 호스팅형 커넥터 방식은 Autopilot이 구현하고 있어요.
Get a free AI ranking consultation
Want your brand to show up when ChatGPT, Gemini and Perplexity answer questions in your market? Tell us about your site and our team will send a personalized strategy.
