GA4 AI 에이전트: 구글 애널리틱스 데이터를 말로 묻고 답 받기

GA4용 AI 에이전트는 Google Analytics 속성에 접근할 수 있는 인증 정보를 가지고, 일상적인 말로 한 질문을 알맞은 측정항목·측정기준·기간으로 바꿔 Data API로 보고서를 실행한 뒤, 그 결과를 문장으로 답해 주는 소프트웨어예요. 이제 보고서를 만드는 대신 질문만 하면 돼요.

말로 하면 6초면 끝날 질문 하나에 답하려고 탐색 분석을 20분씩 붙잡고 있어 본 분이라면, 왜 끌리는지 바로 아실 거예요. 하지만 위험도 그만큼 실재하는데, 이 부분은 거의 이야기되지 않아요. 측정기준을 잘못 고른 에이전트는 자신감 넘치고 잘 쓰인, 하지만 틀린 답을 내놓아요. 그리고 그 결과물은 맞는 답과 겉보기에 전혀 다르지 않아요.

이 글에서는 연결이 실제로 어떻게 이뤄지는지, 무엇을 물어봐야 하는지, 에이전트가 GA4에서 특히 자주 하는 실수는 무엇인지, 그리고 비용은 얼마나 드는지 살펴볼게요.

GA4 AI 에이전트란 무엇인가요?

세 부분으로 이뤄져 있어요. 첫째는 연결로, 읽기 전용 범위로 속성에 접근하는 OAuth 권한이에요. 둘째는 변환 계층으로, "지난 분기 모바일 전환은 어땠어?" 같은 질문을 Google이 요구하는 측정항목 이름, 측정기준 이름, 기간이 담긴 Data API 요청으로 바꿔 줘요. 셋째는 루프로, 에이전트가 돌아온 결과를 보고 답하기 전에 쿼리를 한 번 더 해야 할지 판단하게 해 줘요.

에이전트와 자연어 검색창을 가르는 게 바로 이 세 번째 요소예요. "전환이 왜 줄었어?"라고 물으면 검색창은 전환 차트를 보여 주고 끝나요. 에이전트는 전환 데이터를 가져와서 하락이 한 채널에 몰려 있다는 걸 알아채고, 그 채널을 방문 페이지별로 다시 뽑아 하락을 이끈 페이지 두 개를 찾아낸 다음, 글자 그대로 입력한 질문이 아니라 정말 궁금했던 질문에 답해요.

AI 에이전트를 Google Analytics 4에 연결하는 방법

방법은 두 가지이고, 어느 쪽이 맞는지는 마케터인지 개발자인지에 따라 달라요.

방법 1: 호스팅형 OAuth 연결

마케터에게 맞는 방법이에요. Google 계정에서 제품을 승인하고 속성을 고르면, 연결 정보가 서버에 저장되어 쿼리할 때마다 재사용돼요. 저희 구현에서는 에이전트가 처음 GA4 도구를 호출할 때 활성화된 Analytics 연결이 있는지 확인해요. 연결이 없으면 실패하거나 추측하지 않고, 연동 화면으로 바로 이어지는 연결 요청을 띄운 뒤 연결이 끝나면 대화를 이어 가요. 속성은 워크스페이스 설정에 지정해 둔 것이 있으면 그걸 쓰고, 없으면 연결된 첫 번째 속성을 사용해요.

설정은 몇 분이면 끝나고 설치할 것도 없어요. 대신 업체가 만들어 둔 도구 목록 안에서만 쓸 수 있다는 점은 감안해야 해요.

방법 2: MCP

개발자에게 맞는 방법이에요. Google은 자체 Google Analytics MCP 서버를 공개하고 있는데, MCP를 지원하는 어떤 클라이언트에서든 GA4를 쓸 수 있게 해 줘요. 제공되는 도구는 run_report, run_realtime_report, run_funnel_report, get_account_summaries, get_property_details, get_custom_dimensions_and_metrics, list_google_ads_links예요. 인증은 읽기 전용 Analytics 범위의 Application Default Credentials로 하는데, 실제로는 Google Cloud 프로젝트에서 Admin API와 Data API를 사용 설정하고 gcloud auth application-default login을 실행하면 돼요.

이걸 기반으로 무언가를 만들기 전에 알아 둘 점이 두 가지 있어요. Google은 이 서버를 실험용(experimental)이라고 표시하고 있어요. 그리고 MCP는 에이전트에게 도구를 줄 뿐, 어떤 도구를 불러야 할지에 대한 판단력까지 주지는 않아요. 추론의 품질은 여전히 모델과 프롬프트에 달려 있어요.

일상적인 말로 물어볼 수 있는 GA4 질문

잘 통하는 질문에는 공통된 형태가 있어요. 비교 대상, 세그먼트, 그리고 정확한 날짜로 지정한 기간이에요.

Compare organic search conversions for [date range A] against [date range B],
broken down by landing page. Show the 10 pages with the largest absolute change.
Flag any row where sessions are low enough that the rate change may be noise.

Which acquisition channels improved and which declined over [date range],
measured by conversions rather than sessions? Name the conversion event you used.

Where do users drop off before completing [goal] over [date range]?
Give raw counts alongside percentages.

Is the gap between mobile and desktop conversion rate widening or narrowing
versus the previous equivalent period? Show both periods.

잘 안 통하는 건 막연한 질문이에요. "사이트 요즘 어때?"라고 물으면 모든 것을 요약하지만 결론은 아무것도 없는 답이 나와요. 게다가 비용도 더 들어요. 막연한 목표는 구체적인 목표보다 훨씬 많은 쿼리로 퍼져 나가거든요.

자동화할 만한 GA4 지표는?

움직일 때마다 반드시 설명이 필요한 지표는 자동화하고, 나머지는 필요할 때 물어보면 돼요.

지표	자동화하는 이유	주의할 점
채널별 전환수	비즈니스가 실제로 신경 쓰는 숫자	어떤 전환 이벤트가 기본으로 설정돼 있는지
방문 페이지별 전환율	페이지 문제와 트래픽 문제를 분리해 줌	작은 분모에서 나오는 극단적인 비율
소스별 참여율	전환이 움직이기 전에 트래픽 품질 변화를 포착	Universal Analytics의 이탈률과 정의가 다름
채널별 수익	마케팅 성과를 매출과 연결	사용 중인 기여 분석 모델
기기·국가별 세션수	비율 변화 뒤에 숨은 구성 변화를 설명	카디널리티 때문에 행이 (other)로 합쳐지는 현상

AI 에이전트가 GA4 데이터를 분석할 때 저지르는 실수

이 섹션은 두 번 읽어 주세요. 아래의 실수들은 모두 겉보기에는 지극히 정상적인 결과를 만들어 내요.

클릭수와 세션을 같은 것으로 취급하기. Search Console은 검색 결과의 클릭수를 세고, GA4는 페이지가 로드된 뒤의 세션을 세요. 두 숫자는 절대 일치하지 않아요. 이 점을 말하지 않고 둘을 비교하는 에이전트는 정의의 차이일 뿐인 불일치를 '발견'하게 돼요.

사용자 범위와 세션 범위 측정항목 섞기. 사용자 범위 측정항목을 세션 범위 측정항목으로 나누면 아무 의미 없는 숫자가 나와요. 그래도 소수점 둘째 자리까지 깔끔하게 표시되죠.

(not set)과 (other) 무시하기. 카디널리티가 높은 측정기준은 (other) 항목으로 합쳐지고, 출처를 알 수 없는 트래픽은 (not set)으로 들어가요. 눈에 보이는 행만 더해서 합계를 보고하는 에이전트는 이 둘을 조용히 빼 버리는 셈이에요.

아주 작은 분모로 증감률 읽기. 전환이 2건에서 3건이 되면 50% 개선이지만, 사실상 아무 일도 아니에요. 비율 옆에 원래 건수도 함께 보여 주도록 에이전트에게 항상 지시하세요.

어떤 전환 이벤트인지 모호한 경우. 대부분의 속성에는 주요 이벤트가 여러 개 설정돼 있어요. 프롬프트에서 하나를 지정하지 않으면 에이전트가 알아서 고르는데, 그 선택이 실행할 때마다 달라질 수 있어요.

상대적인 기간. "지난달"이 어떤 기간인지는 속성의 시간대와 쿼리 실행 시점에 따라 달라져요. 실제 의사결정에 쓸 분석이라면 정확한 날짜로 기간을 지정하세요.

대책은 숫자가 중요한 모든 프롬프트 끝에 아래 문장을 붙이는 거예요.

Every figure must come from the connected property.
Where a figure is unavailable, write "not available" - never estimate.
State the metric, dimension and date range you used for each number.

핵심은 마지막 문장이에요. 에이전트가 자기가 쓴 쿼리를 보여 주게 만들어서, 그냥 믿어야 했던 주장을 30초 만에 검증할 수 있는 주장으로 바꿔 주거든요.

에이전트가 지켜야 하는 GA4 API 한도

그냥 알아 두면 좋은 상식이 아니에요. 어떤 질문에 애초에 답할 수 있는지가 이 한도에 달려 있어요.

Google의 Data API 할당량 문서에 따르면, 표준 속성은 속성당 하루 200,000 코어 토큰, 시간당 40,000 토큰, 속성별·프로젝트별 시간당 14,000 토큰, 그리고 동시 코어 요청 10개까지 쓸 수 있어요. Analytics 360 속성은 하루 2,000,000 토큰, 동시 요청 50개예요. 특히 중요한 건 요청의 복잡도에 따라 토큰 소모량이 달라진다는 점이에요. 측정기준이 많을수록, 기간이 길수록, 카디널리티가 높을수록 할당량을 더 많이 써요. 요청에 returnPropertyQuota를 추가하면 실시간 사용량을 확인할 수 있어요.

현실적으로는, 규모가 큰 속성에서 에이전트가 마음대로 탐색하게 두면 오후 한나절 만에 하루 할당량을 다 써 버릴 수 있고, 할당량이 초기화될 때까지 이후의 모든 보고서가 실패해요. 측정기준을 좁게 지정하고 기간을 구체적으로 정한 프롬프트는 더 명확할 뿐 아니라, 돈 주고도 더 살 수 없는 자원을 아껴 줘요.

GA4로는 에이전트가 답할 수 없는 질문

속성 안에 아예 답이 없는 질문도 있어요. 좋은 에이전트와 나쁜 에이전트의 차이는 그 사실을 솔직하게 말하느냐예요.

탐색 분석에서 보관 기간을 넘어서는 질문. Google의 데이터 보관 문서에 따르면 표준 속성의 사용자 수준·이벤트 수준 데이터 보관 기간은 2개월 또는 14개월이고, 360이 아니라면 14개월이 최대예요. Google 신호 데이터는 설정과 관계없이 최대 26개월까지만 보관돼요. 여기서 중요한 차이가 있어요. 보관 기간은 탐색 분석과 유입경로 보고서에 영향을 주고, 표준 집계 보고서에는 영향을 주지 않아요. 그래서 에이전트는 긴 기간에 걸친 채널 수준의 추세 질문에는 정당하게 답할 수 있지만, 같은 기간의 사용자 경로 질문에는 답할 수 없을 수 있어요. 이 둘을 구분하지 못하는 에이전트는 어떻게든 뭔가를 만들어 내요.

기준점(임계값)이 적용된 데이터. 사용자 수가 너무 적어 개인을 추정할 수 있는 경우, GA4는 해당 행을 보여 주지 않아요. 보이는 것만 더해서 합계를 보여 주는 에이전트는 자기도 모르게 실제보다 적은 숫자를 보고하는 거예요.

동의하지 않은 사용자에 관한 질문. 동의 설정에 따라 일부 행동 데이터는 모델링되거나 아예 빠져 있어요. 이 공백은 오류로 나타나지 않고, 그냥 더 작은 숫자로 나타나요.

에이전트에게 직접 물어보세요. "이 분석에서 보관 기간 제한, 기준점 적용, 동의 공백의 영향을 받는 부분은 얼마나 돼?" 이 질문에 솔직하게 답하는 에이전트라면 계속 쓸 만해요.

AI 에이전트에게 Google Analytics 접근 권한을 줘도 안전할까요?

GA4 접근 권한은 허용할 수 있는 연동 중에서도 안전한 편이에요. 구조적으로 이유가 세 가지 있어요. 권한 범위가 읽기 전용이라 아무것도 수정할 수 없고, Google 계정에서 언제든 접근 권한을 취소할 수 있으며, 최악의 결과라고 해 봐야 직접 속성에서 확인할 수 있는 잘못된 결론이에요.

그래도 신경 써야 할 점이 두 가지 있어요. 첫째, 설정에 따라 GA4 데이터에 개인정보가 포함될 수 있으니 에이전트 업체가 쿼리 결과를 어디에서 처리하고 저장하는지 알아 두세요. 둘째, 같은 에이전트가 임의의 웹페이지도 가져올 수 있다면, 외부에서 작성된 텍스트를 내 지시와 같은 컨텍스트 안으로 들여올 수 있어요. 이른바 프롬프트 인젝션 문제예요. 저희 런타임은 모든 도구에 읽기·생성·쓰기 태그를 붙이고, 가져온 콘텐츠는 신뢰할 수 없는 것으로 격리하며, 신뢰할 수 없는 콘텐츠가 들어온 턴에서는 그 턴이 끝날 때까지 쓰기 태그가 붙은 도구를 거부하는 방식으로 이 문제를 처리해요. GA4 쿼리는 읽기로 태그되어 있어서 어느 쪽이든 영향을 받지 않아요.

GA4 에이전트 쿼리 비용은 얼마나 들까요?

두 가지로 나뉘어요. 첫째는 도구 호출이에요. 저희 카탈로그에서 GA4 쿼리는 호출 1회당 50크레딧이고, 제대로 된 조사는 여러 번의 호출로 이뤄져요. 에이전트가 데이터를 가져오고, 살펴보고, 다시 가져오니까요. 둘째는 모델 토큰이에요. 한 턴 안의 모든 모델 호출을 합쳐 100만 토큰당 300크레딧이 청구되고, 컨텍스트에 들어오는 데이터 양에 비례해 늘어나요. 그래서 50행을 반환하는 쿼리는 5,000행을 반환하는 쿼리보다 분석 비용이 눈에 띄게 적어요.

여기서 나오는 원칙은 할당량과 똑같아요. 넓게 묻는 것보다 정확하게 묻는 게 더 싸요. "사이트 요즘 어때?"는 크레딧으로도, 할당량으로도 가장 비싼 질문이면서 가장 쓸모없는 답을 돌려줘요.

에이전트가 Looker Studio를 대체할 수 있을까요?

아니요. 이유는 능력이 아니라 재현성이에요. 대시보드는 매번 같은 지표를 같은 레이아웃으로 보여 줘요. 모니터링이나 고객이 정기적으로 보는 자료라면 바로 그게 필요하죠. 반면 에이전트는 같은 질문이라도 날마다 다른 경로로 답을 찾아갈 수 있어요.

잘 맞는 역할 분담은 이래요. 대시보드는 무엇에 답하고, 에이전트는 왜에 답해요. 상시로 보는 화면은 대시보드로 유지하고, 대시보드에 설명할 수 없는 변화가 보일 때 에이전트에게 물어보세요. 정기적으로 나가는 결과물이라면 유연성보다 일관성이 더 중요하니 GA4 보고 자동화 글을 참고하세요.

어디서부터 시작하면 좋을까요?

속성을 읽기 전용으로 연결하고, 이번 분기에 이미 직접 답을 구해 본 질문 하나를 에이전트에게 물어보세요. 그리고 비교해 보세요. 이어서 각 숫자에 쓰인 측정항목·측정기준·기간을 보여 달라고 하고, 그중 하나를 GA4 화면에서 직접 확인해 보세요. 이걸 두 번만 해 봐도 업체 자료를 아무리 많이 읽는 것보다 그 도구를 믿어도 되는지 훨씬 잘 알 수 있어요.

Autopilot은 위에서 설명한 OAuth 흐름, 연결 요청, 쿼리 루프를 여러분의 속성에서 그대로 구현해요.