"지난주 가입한 사용자 중에 온보딩을 끝까지 마친 사람이 몇 명이에요?"
이런 기초적인 수준의 궁금증 하나를 해소하기 위해 분석팀에 요청 DM을 보내고 결과 값을 받기까지 며칠을 기다린 적 있나요? SQL을 쓸 줄 모르는 기획자와 마케터에게는 몇 년전까지 데이터는 늘 남의 손을 거쳐야 닿는 곳에 있었습니다. 그러나 AI 애널리틱스의 등장으로 요즘에는 이러한 광경이 크게 줄었습니다. 데이터를 몽땅 집어넣고 물으면 AI가 쿼리를 만들고 결과를 돌려주니, SQL 없이도 어느정도의 분석은 누구나 할 수 있게 됐습니다.
그러면 자연스럽게 이런 생각이 듭니다. "그럼 AI를 우리 데이터에 바로 붙이면 되지, 왜 따로 데이터 웨어하우스나 제품 분석 툴이 필요하죠?"
답은 실제로 데이터를 연결했을 때 어디까지 답이 나오는지에 있습니다.
1. "그냥 AI에 우리 데이터를 바로 연결하면 되지 않나요?"
충분히 해 볼 만한 시도입니다. 실제로 이 방법을 택하는 팀은 파일 하나가 아니라 운영 DB, CRM, 서버 로그, 웹 분석 데이터까지 가지고 있는 소스를 최대한 많이 연결하려고 시도합니다. 물론 이렇게 하면 답할 수 있는 질문도 꽤 많아집니다. "지난달 매출이 가장 높은 상품은?", "VIP 등급 고객의 재구매 주기는?" 같은 질문은 데이터 연동만 잘 해놓는다면 꽤 정확하게 나옵니다.
그런데 데이터를 아무리 많이 연결해도 잘 풀리지 않는 질문이 존재합니다. "결제 페이지까지 왔다가 결제하지 않고 나간 사용자는 몇 명인가요?" 같은 질문입니다. 왜 그럴까요? 두 가지 이유가 존재합니다.
첫째, 기록된 적 없는 행동은 어느 소스에도 없습니다. 서버 로그에는 서버로 요청이 간 순간만 남습니다. 화면에서 버튼을 눌렀지만 서버 요청이 없었던 행동이나, 페이지를 보다 그냥 닫은 순간은 남지 않습니다. 결제 페이지 진입이 요청으로 남았더라도 그 요청을 CRM의 고객과 이어 줄 기준이 없으면, 한 사람이 어디까지 왔다가 떠났는지 흐름으로 복원하기 어렵습니다.
둘째, 데이터가 있어도 뜻이 정해져 있지 않습니다. GA4와 같은 기초적인 웹 분석 도구로 이미 이벤트를 쌓고 있다면 행동 데이터는 있는 셈입니다. 그러나 AI가 이러한 값을 받는다 하더라도 그 이벤트가 무엇을 뜻하는지, 다른 테이블의 사용자와 같은 사람인지는 스스로 추정해야 합니다. 연결한 소스가 많을수록 추측해야 할 연결도 함께 늘어납니다. AI가 추측을 더 많이 할수록 할루시네이션(환각) 현상도 뚜렷해집니다.
답을 찾지 못한 AI는 둘 중 하나를 합니다. 데이터가 없다고 답하거나, 있는 숫자를 엮어 그럴듯한 추정치를 만들어 냅니다. 후자는 더 위험합니다. 근거 없는 숫자가 할루시네이션인지 모른 채 의사결정에 녹여지기 대문입니다.
결국 AI 애널리틱스에서 막히는 지점은 AI의 성능도, 연결한 데이터의 양도 아닙니다. 묻고 싶은 행동이 기록돼 있고 그 뜻이 정해져 있느냐입니다.
2. 우리 회사에 있는 데이터, 없는 데이터
AI에 연결할 수 있는 데이터를 하나씩 펼쳐 놓고 보면, 각각 무엇을 위해 생성된 데이터인지가 드러납니다.
| 데이터 | 담긴 내용 | 답할 수 있는 질문 |
|---|---|---|
| 운영 DB | 주문, 결제, 계정 정보 | 무엇이 팔렸고 누가 샀는가 |
| CRM | 가입일, 구매 이력, 고객 등급 | 누가, 언제 고객이 되었는가 |
| 서버 로그 | 요청, 응답, 에러 | 제품이 정상적으로 작동하는가 |
| 웹 분석 데이터 | 유입 경로, 페이지 조회, 일부 이벤트 | 어디서 들어와 어떤 페이지를 봤는가 |
운영 DB, CRM, 서버 로그는 결과와 상태를 기록합니다. 누가 샀는지, 언제 가입했는지, 서버가 멈췄는지는 알 수 있습니다. 웹 분석 데이터는 행동에 더 가깝지만, 보통 유입과 페이지 단위를 보려고 설정해 두는 경우가 많아 제품 안의 세부 행동까지 담기지 않곤 합니다. 데이터는 처음 만든 목적에 맞는 질문에 가장 잘 답합니다.
그런데 기획자와 마케터가 정말 궁금해하는 질문은 대개 결과에 이르기까지의 과정에 있습니다.
- 가입 완료 화면에서 온보딩 버튼을 누르지 않고 떠난 사용자는 몇 명인가?
- 대시보드에서 보고서 탭을 거쳐 다운로드 버튼까지 간 세션은 몇 퍼센트인가?
- 기능 A를 처음 쓰고 7일 안에 기능 B도 쓴 사용자의 30일 리텐션은 어떤가?
- 캠페인 1에서 들어온 유저는 어떤 랜딩페이지와 기능을 거쳐서 구매까지 이르게 됐나?
이런 질문에 답하려면 "누가, 언제, 어떤 화면에서, 무엇을 눌렀는가"가 이벤트 단위로 쌓인 행동 데이터가 있어야 합니다. 이 데이터는 운영 DB에 기본으로 생기지 않습니다. 누군가 미리 어떤 행동을 기록할지 정하고, 제품에 수집 코드를 심어 두어야 비로소 쌓입니다. 그 전까지는 AI에 소스를 몇 개를 연결하든, 이 질문들의 답은 비어 있거나 여러 소스에 조각으로 흩어져 있습니다.
3. 비어 있는 행동 데이터는 누가 채울까
묻고 싶은 행동을 이벤트로 기록하는 일, 그리고 그 이벤트와 지표의 뜻을 하나로 정하는 일, 이건 결국 사람이 해야합니다. 둘 다 AI를 연결한다고 저절로 생기지 않고, 누군가 미리 설계해서 쌓아 두어야 합니다.
기록은 "어떤 화면에서 어떤 행동이 일어나면 무엇을 남길지" 정하고 제품에 수집 코드를 심는 작업입니다. 뜻을 정하는 일은 생각보다 자주 어긋납니다. 같은 "가입"을 한 화면에서는 sign_up으로, 다른 화면에서는 register_complete로 기록했다면 AI는 둘 중 하나만 보고 가입자 수를 절반으로 셀 수 있습니다. "활성 사용자"의 기준이 팀마다 다르면 AI의 답도 묻는 사람에 따라 달라집니다. 사람이 헷갈리는 정의는 AI도 똑같이 헷갈리기 때문에 가장 중요한 지점이라고 말할 수 있습니다.
이 두 가지 과업을 맡는 곳이 바로 제품 분석 툴입니다. 최근의 고객들은 제품 분석 툴을 AI로 분석을 쉽게 해 주는 대시보드로 생각하지만, 실제로 맡는 자리는 그보다 앞단에 있으며, 훨씬 더 중요한 부분을 맡고 있습니다.
| 흔한 오해 | 실제 역할 |
|---|---|
| AI 분석을 더 쉽게 해 주는 데이터 대시보드 | 사용자 행동 데이터를 수집하고 표준화하는 기반 |
| 범용 GPT처럼 AI가 SQL을 대신 써 주는 도구 | AI가 분석할 수 있는 데이터를 만들어 주는 곳 |
| 기존 데이터에 AI를 붙이면 대신할 수 있음 | 기존 데이터가 답하지 못하는 행동 질문을 위해 데이터를 설계하고 쌓는 곳 |
다시 정리해보자면, 데이터 분석가가 아닌 사람이 SQL 없이 정확한 인사이트를 도출하려면 세가지 요소가 갖춰져야 합니다.
- 수집: 어떤 행동을 이벤트로 남길지 정하고 제품에 심는다
- 정의: 이벤트와 지표의 이름, 계산 방식을 한 기준으로 맞춘다
- 질문: AI가 그 정의를 참조해 자연어 질문을 실제 이벤트와 지표로 바꾼다
AI 애널릭틱스는 세 번째 단계의 이야기입니다. 앞의 두 단계가 비어 있으면 아무리 좋은 AI와 프롬프트를 갖다 붙여도 정확한 답이 나오지 않습니다. 반대로 앞의 두 요소가 단단하면, 마케터의 질문 하나가 데이터팀을 거치지 않고 몇 분 안에 숫자로 돌아옵니다.
(이벤트를 어떤 기준으로 설계하는지는 엔터프라이즈 데이터 수집의 3가지 기준에서 더 자세히 다뤘습니다.)
4. 수집부터 질문까지 한 흐름으로: ThinkingAI Agentic Engine
문제는 앞선 두 단계가 가장 손이 많이 간다는 점입니다. 트래킹 플랜을 스프레드시트에 며칠씩 정리하고, 개발자와 이벤트 정의를 맞추고, 심은 코드가 제대로 트리거 되는지 확인하는 일은 지금까지 대부분 사람이 직접 해 왔습니다.
ThinkingAI Agentic Engine은 이 앞단을 AI 에이전트가 함께 맡도록 설계했습니다.
- 트래킹 플랜 생성: 코딩 에이전트가 서비스 코드베이스를 읽고 비즈니스 로직을 파악해 시나리오별 이벤트와 속성 테이블을 제안합니다. 사용자가 검토하고 승인하면 분석 모듈에 업로드됩니다.
- 트래킹 코드 설치와 검증: 같은 대화에서 트래킹 코드를 생성해 프로젝트에 넣고, 실제 브라우저로 이벤트를 하나씩 발생시켜 플랜과 대조합니다.
- 지표 지식 베이스: 이벤트, 속성, 지표 계산 방식, 비즈니스 용어를 한곳에 모아 사람과 AI가 같은 기준을 보게 합니다.
- 자연어 분석: "회원가입 퍼널을 분석해 줘" 같은 요청을 지식 베이스에 정의된 실제 이벤트와 지표로 바꿔 리포트와 대시보드를 만듭니다.
저희가온라인 뷰티 쇼핑몰을 기반으로 이 과정을 시연했을 때, 회원가입 전환, 콘텐츠 탐색, 장바구니 담기 세 가지 기본 시나리오에서 이벤트 17개가 설계됐습니다. 스프레드시트에서 며칠 걸리던 일이 대화 몇 번으로 끝났고, 그 이벤트를 바탕으로 퍼널과 리텐션 리포트까지 자연어로 만들었습니다.
행동 데이터는 CRM, 주문 데이터 같은 정형 데이터는 물론, VOC나 상담 내역 같은 비정형 데이터와도 지식 베이스 안에서 연결할 수 있습니다. "구매 전환율이 왜 떨어졌나요?"라는 질문에 숫자만이 아니라 그 숫자가 움직인 맥락까지 함께 답할 수 있는 이유입니다.
5. AI 애널리틱스를 검토 중이라면 먼저 확인할 것
AI 애널리틱스를 도입할지 고민 중이라면, 어떤 AI 모델을 쓸지보다 먼저 이 질문을 던져 보시기 바랍니다. "우리 팀이 가장 자주 묻는 질문의 답이, 지금 우리 데이터 안에 있는가?"
답이 운영 DB와 CRM 안에 있다면 지금 가진 데이터에 AI를 붙이는 것만으로도 충분히 빨라질 수 있습니다. 답이 사용자가 제품 안에서 한 행동에 있다면, 필요한 것은 더 똑똑한 AI가 아니라 그 행동을 기록하고 정의해 둔 데이터입니다. SQL 없이 데이터에 질문하는 일은 거기서부터 가능해집니다.
우리 서비스에 어떤 이벤트가 필요한지, 그 데이터로 어떤 질문까지 답할 수 있는지 화면으로 확인해 보고 싶으시다면 ThinkingAI 솔루션 전문가와 상담해보세요.




