우리는 Clarity를 이렇게 씁니다 — 세션 리플레이 + MCP로 UX 개선 루프 만들기
우리는 Clarity를 이렇게 씁니다 — 세션 리플레이 + MCP로 UX 개선 루프 만들기#
"트래픽은 보이는데, 왜 사용자가 멈추는지는 모르겠다."
이 문제가 우리 팀에서 Clarity를 본격적으로 쓰게 된 출발점이었습니다.
GA4로는 유입과 전환을 확인할 수 있습니다. 하지만 클릭이 왜 안 먹히는지, 어떤 문구에서 사용자가 헷갈리는지, 어느 구간에서 손이 멈추는지는 GA4만으로 해석하기 어렵습니다. 그래서 우리는 정량(GA4) + 정성(Clarity) 구조로 운영하고 있습니다.
이 글에서는 아래 4가지를 중심으로 정리합니다.
- Clarity란 무엇인가?
- Clarity를 우리는 어떻게 세팅했는가?
- Clarity MCP를 연결하는 방법
- Clarity로 우리는 어떻게 분석하고 개선하고 있는가? 작업 시 어떻게 이용하는가?
추가로, 실제 운영 과정에서 얻은 체크리스트와 실패 패턴도 함께 공유합니다.
Clarity란 무엇인가?#
Microsoft Clarity는 사용자의 실제 행동을 보여주는 행동 분석 도구입니다. 핵심 기능은 3가지입니다.
- Session Recording: 사용자의 실제 이동/클릭/스크롤 흐름을 확인합니다.
- Heatmap: 어디를 많이 클릭하고, 어디까지 읽었는지 파악합니다.
- Behavior Signals: dead click, rage click, quick back 같은 마찰 신호를 확인합니다.
우리는 Clarity를 "예쁜 대시보드"가 아니라 UX 디버깅 도구로 사용합니다. 에러는 Sentry로 잡고, 성과는 GA4로 보고, "왜 막히는지"는 Clarity로 확인합니다.
예를 들어 2026년 3월 6일~3월 12일(UTC) 기준으로 Clarity MCP에서 확인한 값은 아래와 같습니다.
- 세션 수:
197 - 데드 클릭:
335 - 레이지 클릭:
65 - 평균 스크롤 깊이:
65.35%
숫자만 보면 "데드 클릭이 많다"로 끝날 수 있습니다. 하지만 Clarity의 강점은 여기서부터입니다. 세션 리플레이로 들어가서 어디서, 어떤 UI에서, 어떤 문맥으로 데드 클릭이 발생했는지 바로 확인할 수 있습니다.
Clarity를 우리는 어떻게 세팅했는가?#
핵심 원칙은 단순합니다.
"코드에는 최소 침습으로 넣고, 운영에 필요한 이벤트만 남깁니다."
1) 전역 초기화: 프로덕션에서만 켭니다#
우리는 ClarityProvider에서 Project ID를 초기화하고, 개발 환경에서는 수집하지 않습니다.
"use client";
import { useEffect } from "react";
import Clarity from "@microsoft/clarity";
const PROJECT_ID = "1111111";
export default function ClarityProvider() {
useEffect(() => {
if (process.env.NODE_ENV === "production") {
Clarity.init(PROJECT_ID);
}
}, []);
return null;
}
이 Provider는 앱 루트 레이아웃 <head>에서 로딩합니다. 따라서 서비스 전반에서 공통 추적이 동작합니다.
2) 이벤트 태깅: "중요 행동"만 명시적으로 남깁니다#
우리는 Typefy 핵심 흐름에 커스텀 이벤트를 추가했습니다.
- 테스트 시작 시:
Clarity.event("typefy_test_start") - 결과 보기 시:
Clarity.event("typefy_result_view")
이렇게 하면 세션 리플레이를 볼 때 사용자가 퍼널의 어느 단계에 있는지 빠르게 파악할 수 있습니다. 즉, 단순 클릭 로그가 아니라 의미 있는 제품 이벤트로 세션을 읽게 됩니다.
3) 이벤트 네이밍 규칙을 맞춥니다#
이벤트 이름은 길게 설명형으로 쓰지 않습니다. 우리는 아래 규칙을 사용합니다.
- 포맷:
서비스_행동_단계 - 예시:
typefy_test_start,typefy_result_view - 금지: 팀원만 아는 약어, 실험명, 감정 표현
이 규칙을 지키면 Clarity 대시보드, 세션 필터, MCP 질의에서 재사용성이 올라갑니다.
Clarity MCP를 연결하는 방법#
여기서부터가 우리가 Clarity를 "조회 도구"가 아니라 "AI 운영 도구"로 쓰는 핵심입니다.
1) MCP 서버를 등록합니다#
우리 프로젝트는 .mcp.json에 Clarity MCP 서버를 등록해 둡니다. 로컬 실험 환경에서는 토큰이 직접 들어간 설정을 쓰기도 하지만, 공유/운영 환경에서는 환경변수 주입으로 분리하는 것을 원칙으로 합니다.
{
"mcpServers": {
"clarity-mcp": {
"command": "npx",
"args": [
"@microsoft/clarity-mcp-server",
"--clarity_api_token=${CLARITY_API_TOKEN}"
]
}
}
}
운영에서는 CLARITY_API_TOKEN을 시크릿 저장소 또는 런타임 환경변수로 관리합니다. 토큰을 레포에 직접 남기면 운영 리스크가 커집니다.
2) Slack Agent에도 같은 MCP를 연결합니다#
우리는 Slack 분석 에이전트에도 clarity-mcp를 붙여 운영합니다. 그래서 팀이 슬랙에서 아래처럼 바로 질의할 수 있습니다.
- "지난 7일 데드클릭/레이지클릭 보여줘"
- "모바일 세션 active time 짧은 이유 찾아줘"
- "세션 리플레이 5개 뽑아서 공통 패턴 요약해줘"
실제로 2026-03-06~2026-03-12(UTC) 조회 결과, 디바이스별 값은 아래와 같았습니다.
- Mobile:
131세션, 평균 active duration57초 - PC:
60세션, 평균 active duration515.43초 - Tablet:
6세션, 평균 active duration45.05초
이 숫자 하나만으로도 "모바일에서 더 빨리 이탈한다"는 가설을 바로 세울 수 있습니다.
3) 연결 확인 체크리스트#
연결이 되지 않을 때는 대부분 아래 4가지였습니다.
- API 토큰 scope 문제 (Data Export 권한 누락)
- MCP 서버는 떠 있지만 에이전트에 등록되지 않음
- UTC 기준 날짜 필터 누락으로 빈 데이터 반환
- 질의가 너무 포괄적이라 도구 응답 실패
우리는 항상 "짧은 기간 + 명확한 지표"로 먼저 조회해서 연결 상태를 점검합니다.
Clarity로 우리는 어떻게 분석하고 개선하는가?#
우리 팀의 운영 루프는 아래 5단계입니다.
- 신호 탐지: dead/rage/scroll 지표에서 이상치를 확인합니다.
- 세션 확인: 샘플 세션 5~10개로 문제 위치를 파악합니다.
- 가설 작성: UI/카피/상태전이 문제를 문장으로 정의합니다.
- 빠른 수정: 1~2일 안에 수정 배포합니다.
- 재측정: 같은 지표, 같은 구간으로 전후를 비교합니다.
실제 사례: 최근 BlogPost 데드클릭 개선#
가장 최근에는 블로그 포스트 id=8(AI 팀원 운영 글)에서 데드클릭이 집중적으로 발생했습니다.
Clarity 세션 리플레이에서 사용자가 본문 헤딩/코드 영역을 반복 클릭하는 패턴이 확인됐고, 이를 P0로 분류해 즉시 수정했습니다.
적용한 변경은 아래 2가지입니다.
- 헤딩(
h1/h2/h3)에 앵커 링크를 추가해 클릭 시 의미 있는 동작(링크 복사/이동)이 일어나도록 변경 - 코드블록 우측 상단에 복사 버튼을 추가해 "클릭했는데 반응 없음" 상황 제거
실제 수치도 개선됐습니다(Clarity MCP, UTC, 비봇 기준).
| 구간 | Dead Click | Rage Click | 세션 수 | Dead Click / 세션 | Rage Click / 세션 |
|---|---|---|---|---|---|
| 개선 전 (2026-03-01 ~ 2026-03-10) | 236 | 41 | 17 | 13.88 | 2.41 |
| 개선 후 (2026-03-11 ~ 2026-03-12) | 5 | 0 | 8 | 0.63 | 0.00 |
요약하면, 세션당 데드클릭이 13.88 → 0.63으로 약 95.5% 감소했고, 세션당 레이지클릭은 2.41 → 0으로 100% 감소했습니다.
기간과 모수가 동일하지 않기 때문에 절대 비교에는 주의가 필요하지만, 방향성은 매우 명확했습니다.
핵심은 "문제처럼 보이는 느낌"이 아니라, 세션에서 반복되는 실제 행동을 근거로 수정한다는 점입니다.
작업할 때는 어떻게 쓰는가?#
우리는 기능 개발 플로우에도 Clarity를 포함합니다.
- 기획 단계: "이 화면의 성공 행동 이벤트"를 먼저 정의합니다.
- 개발 단계: 핵심 이벤트 1~3개만 Clarity 이벤트로 추가합니다.
- QA 단계: 테스트 계정 세션 리플레이로 플로우를 검증합니다.
- 배포 후: 24~72시간 모니터링으로 dead/rage 급증 여부를 확인합니다.
특히 "새 기능인데 지표가 조용하다"는 상황에서 Clarity가 유용합니다. 사용자가 기능을 못 찾는지, 눌렀는데 동작이 느린지, 카피가 모호한지 세션에서 바로 확인할 수 있습니다.
AI에게 데이터 컨텍스트를 주면 결과 품질이 달라집니다#
저도 같은 생각입니다. AI에게 "분석해줘"만 요청할 때보다, 실제 데이터를 같이 주면 결과 품질이 확실히 올라갑니다.
- 데이터 없이 요청하면: 일반론 중심 제안이 나옵니다.
- 데이터와 함께 요청하면: 문제 구간, 우선순위, 수정안을 더 구체적으로 제시합니다.
우리는 아래 템플릿으로 자주 요청합니다.
기간: 최근 7일(UTC)
대상: /blog/posts/8/*
지표: dead click, rage click, session, scroll depth
요청: 상위 마찰 구간 3개와 수정안 3개를 우선순위로 제안해줘
이 방식의 장점은 3가지입니다.
- 가설 품질이 올라갑니다. (추측이 아니라 수치+세션 근거)
- 우선순위가 선명해집니다. (영향도 큰 이슈부터 처리)
- 실행 속도가 빨라집니다. (분석 → 수정 → 재측정 루프 단축)
우리가 추가로 얻은 것: 팀 커뮤니케이션 비용 감소#
Clarity를 도입한 뒤 가장 크게 줄어든 것은 회의에서의 "추측 대화"였습니다.
예전에는 이런 대화가 길었습니다.
- "아마 버튼이 안 보여서 그럴 거예요"
- "모바일 사용자가 원래 짧게 보다가 나가요"
- "광고 유입 질이 낮아서 그래요"
지금은 이렇게 바뀌었습니다.
- "3월 10일 세션에서 해당 텍스트 dead click이 반복됩니다"
- "모바일 active time이 57초로 PC 대비 크게 짧습니다"
- "결과 보기 직전 구간에서 클릭 반복 후 이탈이 나옵니다"
같은 문제를 말해도, 근거가 영상+숫자로 붙으면 실행 속도가 확실히 빨라집니다.
한계와 운영 원칙#
Clarity가 만능은 아닙니다. 그래서 우리는 역할을 분리해 운영합니다.
- GA4: 트래픽, 퍼널, 채널 성과
- Clarity: 행동 마찰, UI 이해도, 맥락 확인
- Sentry: 오류, 성능, 예외 추적
또한 개인정보 보호 원칙을 반드시 지킵니다.
- 민감 데이터는 입력/재생 정책을 사전에 점검합니다.
- 원본 세션 링크를 외부 공유할 때는 최소 권한 원칙을 적용합니다.
- 개선 회고 문서에는 개인 식별 정보 없이 패턴만 기록합니다.
정리#
Clarity는 "녹화 툴"이 아니라 제품 팀의 UX 디버거입니다.
MCP까지 연결하면 "대시보드를 열어보는 사람"뿐 아니라 AI 에이전트도 같은 데이터를 바로 읽고 분석 루프에 들어올 수 있습니다.
우리 팀은 지금 아래 구조를 기본 운영 스택으로 사용합니다.
- 추적:
ClarityProvider+ 핵심 이벤트 - 조회: Clarity 대시보드 + Clarity MCP
- 실행: 주간 개선 루프(탐지 → 확인 → 수정 → 재측정)
이 방식의 장점은 단순합니다.
의견은 줄고, 근거는 늘고, 수정 속도는 빨라집니다.
비슷한 고민을 하고 계시거나 같이 실험해보고 싶은 분은 커피챗 하고 싶습니다 ☕️ 📩 ksy90101@gmail.com
함께 읽으면 좋은 글
댓글
0의견을 남겨보세요. 로그인하면 닉네임이 자동으로 입력됩니다.
댓글을 불러오는 중...