AI에게 Google Analytics를 쥐어주면 — GA MCP로 데이터 기반 AI Product Owner 만들기

"감으로 결정하는 PO"의 한계

이전 글에서 Claude Code Skills로 28명의 AI 팀원을 세팅한 이야기를 했다. CPO, CTO, 기획자, 디자이너, 개발자가 각자의 역할을 수행하며 /develop 한 마디로 기능 개발 파이프라인이 돌아가는 구조다.

그런데 운영하면서 한 가지 근본적인 문제를 발견했다.

AI CPO가 기능 우선순위를 판단할 때, 감으로 결정한다는 것이다.

"블로그에 태그 시스템을 추가할까, 검색 기능을 추가할까?" — AI는 일반적인 제품 원칙에 따라 그럴듯한 답을 내놓는다. "검색이 더 보편적으로 사용됩니다", "태그가 SEO에 유리합니다" 같은 논리를 펼치지만, 정작 우리 서비스의 실제 데이터는 보지 못한다.

블로그 DAU가 5명인데 검색 기능이 급한가? Quiver 퀴즈의 이탈률이 80%인데 새 테스트를 만드는 게 먼저인가? 이런 질문에 답하려면 프로덕트 데이터가 필요하다. 사람 PO가 매일 GA 대시보드를 확인하듯이, AI PO도 실제 트래픽을 보고 판단해야 한다.

그래서 Google Analytics를 AI에게 직접 연결했다.

핵심 아이디어: MCP로 AI에게 "눈"을 준다

MCP(Model Context Protocol)는 AI가 외부 도구나 데이터 소스에 접근할 수 있게 해주는 표준 프로토콜이다. Claude Code에서는 .mcp.json 파일 하나로 MCP 서버를 연결한다. 파일 시스템, 데이터베이스, API 등 다양한 소스를 AI 에이전트의 도구로 등록할 수 있다.

여기서 핵심 발상은 이것이다.

Google Analytics Data API를 MCP 서버로 감싸면, AI가 자연어로 GA 데이터를 조회할 수 있다.

"어제 블로그 DAU 보여줘"라고 하면, AI가 run_report를 호출해서 실제 숫자를 가져온다. 그리고 그 숫자를 기반으로 의사결정을 내린다. 감이 아니라 데이터로.

기존 방식:
  사람 → GA 대시보드 확인 → 엑셀 정리 → AI에게 붙여넣기 → AI 분석

MCP 방식:
  AI → GA Data API 직접 호출 → 실시간 데이터 기반 분석

중간 과정이 사라진다. AI가 스스로 필요한 데이터를 가져와서 분석한다.

Part 1: GA MCP 서버 설정 (따라하기)

Step 1: Google Cloud 서비스 계정 생성

GA Data API에 접근하려면 Google Cloud 서비스 계정이 필요하다.

1. Google Cloud Console → 프로젝트 선택 (없으면 새로 생성)
2. IAM 및 관리자 → 서비스 계정 → 서비스 계정 만들기
3. 이름은 자유 (예: mcp-analytics)
4. 역할은 별도로 부여하지 않아도 된다 (GA 쪽에서 권한 부여)
5. 키 만들기 → JSON → 다운로드

다운로드한 JSON을 프로젝트 내 안전한 위치에 저장한다. 우리는 .gemini/ga-service-account.json에 넣었다. .gitignore에 반드시 추가하자.

# .gitignore
.gemini/ga-service-account.json

Step 2: Google Analytics API 활성화

같은 Google Cloud 프로젝트에서 두 가지 API를 활성화한다.

1. Google Analytics Data API — 리포트 조회 (필수)

   • https://console.developers.google.com/apis/api/analyticsdata.googleapis.com

2. Google Analytics Admin API — 계정/속성 조회 (권장)

   • https://console.developers.google.com/apis/api/analyticsadmin.googleapis.com

활성화 후 전파까지 1~2분 걸릴 수 있다.

Step 3: GA4 속성에 서비스 계정 추가

서비스 계정이 GA4 데이터를 읽으려면 GA4 관리자에서 권한을 부여해야 한다.

1. Google Analytics 접속
2. 관리(Admin) → 해당 속성 선택
3. 속성 액세스 관리 → + → 사용자 추가
4. 서비스 계정 이메일 입력 (JSON 파일의 client_email 값)
5. 역할: 뷰어(Viewer)
6. 저장

우리의 경우 mcp-214@weggle-plus.iam.gserviceaccount.com을 뷰어로 추가했다.

Step 4: analytics-mcp 패키지 설치

analytics-mcp는 Google Analytics Data API를 MCP 서버로 감싼 Python 패키지다. pipx로 설치한다.

# pipx 설치 (없는 경우)
brew install pipx
pipx ensurepath

# analytics-mcp 실행 테스트
pipx run analytics-mcp --help

pipx run을 사용하면 별도 설치 없이 바로 실행할 수 있다.

Step 5: .mcp.json 설정

프로젝트 루트에 .mcp.json 파일을 만든다.

{
  "mcpServers": {
    "analytics-mcp": {
      "command": "pipx",
      "args": ["run", "analytics-mcp"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/절대경로/ga-service-account.json",
        "GOOGLE_PROJECT_ID": "your-project-id"
      }
    }
  }
}

이것이 전부다. Claude Code를 재시작하면 MCP 서버가 자동으로 연결된다. AI에게 새로운 도구가 추가된 것이다.

Step 6: 연결 확인

Claude Code에서 간단히 확인할 수 있다.

> 내 GA 계정 정보 보여줘

AI가 get_account_summaries를 호출해서 계정 목록과 속성 정보를 보여주면 성공이다. 우리의 경우 이렇게 나왔다.

계정: weggle-plus (ID: 367467336)
└── 속성: weggle-plus-prd (Property ID: 503926824)
    타임존: Asia/Seoul
    통화: KRW

여기서 주의할 점이 있다. 계정 ID와 속성(Property) ID는 다르다. Data API 호출에는 속성 ID(503926824)를 사용한다. GA4의 Measurement ID(G-XXXXXXX)와도 다른 값이다.

연결에 성공하면 사용할 수 있는 도구들

MCP 서버가 제공하는 주요 도구는 이렇다.

가장 핵심은 run_report다. 자연어로 요청하면 AI가 알아서 dimensions, metrics, filters를 조합해서 API를 호출한다.

Part 2: AI CPO에게 GA를 연결하다

기존 CPO 스킬의 한계

이전 글에서 소개한 CPO 스킬은 이랬다.

## 행동 원칙
1. **사용자 중심**: 모든 결정의 기준은 "사용자에게 어떤 가치를 주는가?"
2. **MVP 사고**: 가장 작은 범위로 가장 큰 가치를 검증
3. **데이터 기반**: 가설 → 실험 → 검증 사이클을 선호

"데이터 기반"이라고 적어뒀지만, 실제로 데이터에 접근할 수 없었다. 원칙만 있고 도구가 없는 상태. 사람으로 치면 "데이터를 보고 판단하라"고 해놓고 GA 접근 권한을 안 준 셈이다.

GA 연결 후 달라진 CPO 스킬

MCP 연결 후 CPO 스킬에 구체적인 데이터 활용 지침을 추가했다.

---
name: cpo
allowed-tools: Read, Grep, Glob, WebSearch,
  mcp__analytics-mcp__run_report,
  mcp__analytics-mcp__get_account_summaries,
  mcp__analytics-mcp__run_realtime_report
---

핵심 변화는 allowed-tools에 GA MCP 도구가 추가된 것이다. 이제 CPO가 리뷰할 때 GA 데이터를 직접 조회할 수 있다.

스킬 본문에는 임팩트 검증 프로세스를 추가했다.

## Google Analytics 데이터 기반 의사결정

### GA4 속성 정보
- **Property ID**: `503926824` (weggle-plus-prd)
- **타임존**: Asia/Seoul

### 임팩트 검증 프로세스
새로운 기능을 리뷰하거나 제품 결정을 내릴 때,
**반드시 GA 데이터를 조회**하여 근거를 확보합니다.

#### 자주 사용하는 분석 패턴
| 분석 목적      | dimensions                    | metrics                          |
|---------------|-------------------------------|----------------------------------|
| 서비스별 DAU   | pagePath                      | activeUsers, sessions            |
| 유입 채널 효과  | sessionDefaultChannelGroup    | activeUsers, newUsers            |
| 디바이스 분포   | deviceCategory                | activeUsers, sessions            |
| 일별 트렌드    | date                          | activeUsers, newUsers, sessions  |
| 페이지 성과    | pagePath                      | screenPageViews, bounceRate      |

### 리뷰 시 데이터 활용 원칙
- "감"이 아닌 "데이터"로 의사결정
- 트래픽이 낮은 서비스의 신규 기능보다
  트래픽이 높은 서비스의 개선을 우선 검토

Property ID, 분석 패턴 테이블, 데이터 활용 원칙까지 넣었다. AI가 어떤 상황에서 어떤 데이터를 봐야 하는지를 구체적으로 가이드한 것이다.

Part 3: AI 기획자에게도 GA를 준다

CPO뿐 아니라 서비스별 기획자(Planner)에게도 GA 접근 권한을 줬다. 기획자가 기능 명세서를 작성하기 전에 현재 서비스 상태를 파악해야 하기 때문이다.

기획자 기본 템플릿에 GA 활용 지침 추가

## Google Analytics 데이터 기반 기획

기획서를 작성하기 전, **반드시 GA 데이터를 조회**하여
현재 서비스 상태를 파악합니다.

### 필수 조회 항목
1. 담당 서비스 DAU/트래픽 (최근 7일 트렌드)
2. 사용자 행동 패턴 (pageViews, bounceRate, 체류시간)
3. 유입 채널 (Direct, Organic Social, Organic Search 비율)

### 우선순위 판단 기준
- 트래픽 높은 페이지의 이탈률이 높다면 → UX 개선 우선
- 신규 사용자 비율이 높다면 → 온보딩/첫 경험 개선 우선
- 특정 페이지에 트래픽 집중 → 해당 기능 강화 우선
- 트래픽이 거의 없는 서비스 → 유입 전략 수립 우선

### 기획서에 GA 데이터 포함
기획서 개요 섹션에 현재 지표를 반드시 포함:
- 최근 7일 DAU: X명
- 관련 페이지 일평균 pageViews: X회
- 이탈률: X%
- 주요 유입 채널: ...

이제 기획서의 개요 섹션에 GA 데이터가 자동으로 포함된다. "이 기능이 왜 필요한가?"에 대한 답이 숫자로 뒷받침되는 것이다.

서비스별 기획자의 특화 분석

각 서비스 기획자에게는 해당 서비스에 맞는 분석 관점을 추가했다.

Blog Planner는 인기 글 분석에 집중한다.

- 인기 글 분석: `/blog/posts/*` 경로별 pageViews로 인기 주제 파악
- 블로그 메인 vs 개별 글 트래픽 비율로 목록 페이지 개선 필요성 판단
- 콘텐츠 체류 시간으로 글의 깊이/품질 간접 측정
- Organic Search 유입이 높은 글 → SEO 강화 대상

Quiver Planner는 퀴즈 완주율과 바이럴 효과를 본다.

- 테스트별 인기도: `/quiver/*` 경로별 pageViews, activeUsers
- 완주율 간접 측정: 시작 페이지 대비 결과 페이지 비율
- 공유 효과: Organic Social 채널 유입 비율로 바이럴 측정
- 신규 사용자 비율: newUsers/activeUsers로 유입 견인력 판단

DFC Planner는 인증 기반 서비스 특성을 고려한다.

- 서비스 트래픽: `/digital-fixed-cost` DAU, sessions 추이
- 이탈률 모니터링: 인증 필수이므로 높은 이탈률 → 비로그인 경험 개선 필요
- 디바이스 분포: 모바일/데스크톱 비율로 반응형 우선순위 판단

같은 GA 데이터를 보더라도, 서비스 맥락에 따라 다른 관점으로 해석하도록 한 것이다.

Part 4: 실전 사례 — "블로그에 어떤 기능을 추가할까?"

이론만으로는 와닿지 않으니, 실제로 /cpo에게 "블로그 서비스에 어떤 기능을 추가하면 좋을까? 5개만 추천해줘"라고 요청한 결과를 공유한다.

AI가 실제로 수행한 분석

AI CPO는 요청을 받자마자 4개의 GA 리포트를 동시에 호출했다.

1. 최근 30일 블로그 페이지별 트래픽 + 이탈률 + 체류시간
2. 유입 채널별 사용자 수 (Direct, Organic Social, Organic Search, Referral)
3. 디바이스별 세션 + 이탈률 + 체류시간
4. 일별 DAU 트렌드 (30일)

사람이 GA 대시보드에서 4개 탭을 열어서 확인하는 과정을, AI가 병렬로 한 번에 처리한 것이다.

GA 데이터에서 읽어낸 인사이트

AI가 가져온 실제 데이터와 그로부터 도출한 인사이트다.

트래픽 데이터:

유입 채널:

디바이스 비교:

AI가 데이터에서 발견한 3가지 핵심 문제

AI CPO는 이 데이터를 종합해서 세 가지 핵심 문제를 도출했다.

문제 1: "읽고 떠나기" — 개별 포스트 이탈률이 35~89%. 한 글만 읽고 이탈하는 사용자가 대다수다. 블로그 메인의 이탈률은 11%로 우수하지만, 개별 글에서 다른 글로 이어지는 동선이 없다.

문제 2: Organic Search 부재 — 전체 유입의 2%에 불과(5명). 콘텐츠가 SNS에서 바이럴될 만큼 좋지만(Organic Social 121명), 검색으로는 발견할 수 없다. SEO가 완전히 빠져 있다.

문제 3: 모바일 체류 시간 3.7배 격차 — 모바일 60초 vs 데스크톱 222초. 모바일 사용자가 2.4배 더 많은데, 글을 제대로 읽지 못하고 떠나고 있다.

AI가 제안한 기능 Top 5 (임팩트 순)

임팩트 ↑
 높음  │ ① 관련글 추천     ② SEO 메타 최적화
       │ ③ TOC+읽기시간    ④ 태그 시스템
 낮음  │                   ⑤ 공유 CTA 강화
       └──────────────────────────→ 노력
         낮음                   높음

1순위: 관련 글 추천 — 포스트 #7에 125명이 왔는데 35.7%가 바로 이탈. 글 하단에 "함께 읽으면 좋은 글" 2~3개만 보여줘도 이탈률을 20% 이하로 낮출 수 있다. 노력 대비 임팩트가 가장 크다.

2순위: SEO 메타 최적화 — Organic Search가 5명(2%). Open Graph 태그, JSON-LD 구조화 데이터, sitemap.xml만 추가해도 검색 유입이 10배 이상 성장할 여지가 있다. 콘텐츠 품질은 이미 검증됨(Organic Social 121명).

3순위: 목차(TOC) + 읽기 예상 시간 — 모바일 체류 60초 문제를 해결한다. 긴 글에 목차를 자동 생성하고, "약 5분 소요" 같은 정보로 기대치를 관리한다.

4순위: 태그 기반 글 분류 — 11개+ 포스트로 콘텐츠가 늘어나면서 탐색성이 부족하다. 태그 페이지는 SEO에도 기여해서 2순위와 시너지.

5순위: SNS 공유 CTA 강화 — Organic Social이 이미 강한 채널(121명). 공유 버튼은 있지만, 공유 시 미리보기 카드 품질과 CTA를 개선하면 바이럴 효과를 극대화할 수 있다.

감으로 했다면?

만약 GA 데이터 없이 "블로그에 추가할 기능 5개"를 물었다면, 아마 이런 답이 나왔을 것이다.

• 다크 모드
• 글 검색 기능
• 소셜 로그인
• 북마크/저장 기능
• 댓글 알림

일반적으로 "있으면 좋은" 기능들이다. 하지만 우리 서비스에 맞는 답인가? DAU 5명인 날도 있는 서비스에 검색 기능이 급한가? 다크 모드보다 SEO가 10배 더 급하다는 걸, 데이터 없이는 알 수 없다.

GA 데이터가 붙으니 제안의 질이 완전히 달라졌다. 모든 제안에 "왜 이걸 해야 하는가?"에 대한 숫자 근거가 있다.

Part 5: 전체 워크플로우에서의 위치

GA MCP는 기존 AI 팀 구조에 자연스럽게 녹아든다.

 CEO: "/develop 블로그에 관련 글 추천 기능 추가"
  │
  ▼
┌──────────────────────────────────────────────┐
│ Phase 0: 데이터 조회 (NEW)                    │
│                                              │
│  기획자 → GA 조회                             │
│  "최근 7일 /blog/posts/* 이탈률 데이터"       │
│  → 기획서 개요에 현재 지표 포함               │
└──────────────┬───────────────────────────────┘
               ▼
┌──────────────────────────────────────────────┐
│ Phase 1: 설계 (기획서에 GA 지표 포함)         │
│                                              │
│  기획서 개요:                                 │
│  "현재 개별 포스트 이탈률 35~89%.             │
│   관련 글 추천으로 이탈률 20% 이하 목표"      │
└──────────────┬───────────────────────────────┘
               ▼
┌──────────────────────────────────────────────┐
│ Phase 2: C-Level 리뷰 (GA 데이터 기반 판단)   │
│                                              │
│  CPO → GA 조회                               │
│  "기획서의 이탈률 수치가 맞는지 교차 검증"    │
│  "관련 글 추천이 정말 이탈률에 영향을 줄 수    │
│   있는 위치(글 하단)에 배치되는가?"           │
└──────────────┬───────────────────────────────┘
               ▼
  Phase 3~5: 피드백 반영 → 구현 → 최종 보고
               ▼
┌──────────────────────────────────────────────┐
│ Phase 6: 임팩트 측정 (NEW)                    │
│                                              │
│  CPO → GA 조회 (출시 전 vs 후 비교)           │
│  "관련 글 추천 출시 후 이탈률 변화:            │
│   35.7% → 22.1% (개선)"                     │
└──────────────────────────────────────────────┘

Phase 0(데이터 기반 기획)과 Phase 6(임팩트 측정)이 새로 추가된다. 기획에서 검증까지 데이터가 관통하는 구조다.

Part 6: 일상적인 활용 패턴들

GA MCP를 연결하고 나서 일상적으로 사용하는 패턴들이 생겼다.

패턴 1: 아침 DAU 체크

> 어제 WegglePlus 서비스 DAU를 분석해줘

이 한 마디로 AI가 전체 서비스의 DAU, 유입 채널, 디바이스 분포, 인기 페이지를 한 번에 분석해준다. GA 대시보드에 로그인할 필요가 없다.

패턴 2: 기능 기획 전 현황 파악

> /blog-planner 블로그에 목차 자동 생성 기능을 기획해줘

Blog Planner가 자동으로 GA를 조회해서 현재 블로그의 모바일 체류시간(60초), 데스크톱 체류시간(222초) 격차를 확인하고, 기획서에 "모바일 체류 시간을 120초 이상으로 개선"이라는 목표를 자동으로 설정한다.

패턴 3: 콘텐츠 성과 측정

> 지난주 올린 블로그 글의 성과를 분석해줘

특정 포스트의 pageViews, 체류시간, 유입 채널을 분석해서 "어떤 주제가 잘 먹히는지" 패턴을 파악한다. 다음 콘텐츠 방향을 데이터로 잡을 수 있다.

패턴 4: 출시 전후 비교

> /cpo 관련 글 추천 기능 출시 전후 이탈률을 비교해줘

GA Data API의 date_ranges 파라미터를 2개 넣으면 기간 비교가 가능하다. 출시 전 7일과 후 7일의 이탈률, DAU, 체류시간 변화를 한 번에 볼 수 있다.

Part 7: 셋업 시 겪은 삽질과 해결법

삽질 1: 서비스 계정 JSON 포맷

서비스 계정 JSON의 private_key 필드에 실제 줄바꿈이 들어가면 JSON 파싱이 실패한다. \n 이스케이프 시퀀스로 한 줄에 담겨야 한다.

// 잘못된 형태 (실제 줄바꿈)
"private_key": "-----BEGIN PRIVATE KEY-----
MIIEvg...
-----END PRIVATE KEY-----"

// 올바른 형태 (\n 이스케이프)
"private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvg...\n-----END PRIVATE KEY-----\n"

Google Cloud Console에서 다운로드한 원본 JSON은 올바른 형태다. 수동으로 편집하다가 깨뜨리지 않도록 주의한다.

삽질 2: 계정 ID vs 속성(Property) ID

GA4에는 여러 가지 ID가 있다.

run_report에는 속성 ID를 써야 한다. Measurement ID나 계정 ID를 넣으면 권한 오류가 난다. 속성 ID를 모르면 get_account_summaries로 확인할 수 있다.

삽질 3: API 활성화 잊음

Google Cloud 프로젝트에서 Analytics Data API와 Admin API를 활성화하지 않으면 403 에러가 난다. 에러 메시지에 활성화 URL이 포함되어 있으니, 그 링크를 따라가면 된다.

Part 8: 이 방식의 의미

AI PO의 진화 단계

1단계: AI가 일반 원칙으로 조언한다 ("검색이 보편적으로 중요합니다") 2단계: 사람이 데이터를 붙여넣으면 AI가 분석한다 ("이 데이터를 보면...") 3단계: AI가 직접 데이터를 가져와서 분석한다 ← 현재 단계

3단계에서 사람의 역할은 "질문을 던지는 것"으로 바뀐다. "어떤 기능을 만들까?"라고 물으면, AI가 알아서 데이터를 보고, 문제를 정의하고, 우선순위를 매기고, 근거를 제시한다.

한계와 주의점

만능은 아니다.

정량적 데이터의 한계 — GA는 "무엇이 일어났는가"를 보여주지만 "왜 일어났는가"는 알려주지 않는다. 이탈률이 높은 이유가 콘텐츠 품질 때문인지, 로딩 속도 때문인지, 모바일 레이아웃 때문인지는 추가 조사가 필요하다.

사용자 인터뷰를 대체하지 못한다 — 숫자 뒤에 있는 사용자의 감정, 기대, 불만은 GA에 찍히지 않는다. AI PO가 아무리 데이터를 잘 분석해도, 직접 사용자와 대화하는 것을 대체할 수는 없다.

표본 크기 문제 — DAU 5~30명 수준의 초기 서비스에서 이탈률 35%와 40%의 차이는 통계적으로 유의미하지 않을 수 있다. 작은 숫자에서 과도한 결론을 끌어내지 않도록 AI에게도 주의를 줘야 한다.

그래도 이 방식이 좋은 이유

위의 한계에도 불구하고, 데이터 없는 의사결정보다는 확실히 낫다.

감으로 "다크 모드가 필요하다"고 하는 것보다, "모바일 체류시간이 60초인데 TOC가 먼저 필요하다"고 하는 게 더 나은 판단이다. 틀릴 수 있지만, 최소한 왜 그런 판단을 했는지 근거가 남는다.

그리고 이 모든 것이 설정 한 번으로 가능하다. .mcp.json 파일 하나, 스킬 파일에 몇 줄 추가. 그 뒤로는 AI가 알아서 데이터를 가져오고 분석한다.

마무리

결국 이 이야기의 핵심은 간단하다.

AI에게 역할만 주지 말고, 데이터도 줘라.

CPO라는 역할을 주면 CPO처럼 말한다. 거기에 GA 데이터를 쥐어주면, CPO처럼 판단한다. 기획자에게 서비스 지식을 주면 기획서를 쓴다. 거기에 현재 지표를 주면, 근거 있는 기획서를 쓴다.

MCP는 AI에게 "눈"을 주는 기술이다. GA뿐 아니라 Amplitude, Mixpanel, BigQuery, Slack, Jira — 어떤 데이터 소스든 MCP로 연결하면 AI의 판단 품질이 올라간다. 우리는 GA로 시작했지만, 앞으로 더 많은 "눈"을 연결할 계획이다.

.mcp.json에 한 줄 추가하는 것으로, AI 팀원 전체의 판단 기준이 "감"에서 "데이터"로 바뀐다. 그게 이 글에서 말하고 싶었던 전부다.

---

비슷한 고민을 하고 계시거나 같이 실험해보고 싶은 분은 커피챗 하고 싶습니다 ☕️ 📩 ksy90101@gmail.com