AI 데이터분석으로 LTV 계산하기: Text to SQL 4단계

AI 데이터분석 도구가 좋아지면서 「우리 몰 LTV가 얼마입니까?」라는 질문에 답하는 시간이 2주에서 30분으로 줄었습니다. 자연어로 물으면 SQL을 대신 써 주는 Text to SQL 덕분입니다.

결론부터 말씀드리면, 빨라진 것은 기다리는 시간이지 숫자의 정확도가 아닙니다. 정의를 먼저 고정하고, 테이블 세 개를 확인하고, AI가 만든 쿼리를 읽고, 한 번 뽑은 숫자를 코호트로 쌓는 순서를 지켜야 30분짜리 숫자가 회사의 결정에 쓸 수 있는 숫자가 됩니다. 순서를 건너뛰면 AI는 틀린 답을 빠르게 내놓습니다.

뉴스레터에서 성장판의 여섯 레버를 숫자로 채워 보시라고 했을 때 가장 많이 받은 답장은 「채우고 싶은데 데이터팀에 요청하면 2주 걸립니다」였습니다. 이 글은 그 2주를 없애는 순서입니다. 여섯 레버가 무엇이고 왜 이 숫자들이 회사의 크기를 정하는지는 그로스 마케팅이란 무엇인가에 정리해 두었습니다.

AI 데이터분석이 줄여 준 것은 대기 시간이지 검증이 아닙니다

데이터 요청이 2주씩 걸리던 이유를 뜯어 보면, 쿼리를 짜는 시간은 생각보다 짧습니다. 시간은 대부분 왕복에서 나갑니다. 요청서를 쓰고, 우선순위에 밀리고, 받아 보니 「신규」의 기준이 내가 생각한 것과 달라서 다시 요청합니다. Text to SQL은 이 왕복을 없앴습니다. 「지난 1월에 첫 구매한 고객의 30일 누적 구매액을 보여줘」라고 쓰면 쿼리가 나오고, 실행하면 표가 나옵니다. 묻는 사람과 확인하는 사람이 같아졌다는 것이 진짜 변화입니다.

그런데 여기서 흔한 오해가 생깁니다. AI가 뽑았으니 맞을 것이라는 생각입니다. 연구 결과는 반대 방향을 가리킵니다. 2025년 ICLR에 발표된 Spider 2.0 연구는 실제 기업 데이터 환경에서 가져온 632개 과제로 Text to SQL을 평가했습니다. o1-preview 기반 에이전트는 이 과제의 21.3%만 풀었습니다. 같은 방식이 정돈된 공개 벤치마크인 Spider 1.0에서는 91.2%, BIRD에서는 73.0%를 풀었던 것과 큰 차이입니다. 테스트용으로 다듬어진 데이터베이스와 실제 회사의 지저분한 데이터베이스는 다른 세계라는 뜻입니다.

쇼핑몰 데이터베이스는 대개 뒤쪽에 가깝습니다. 취소된 주문, 테스트 계정, 같은 사람의 중복 회원, 서버 시간과 한국 시간의 차이가 섞여 있습니다. 도구를 만든 쪽도 이 점을 분명히 합니다. Google Cloud의 BigQuery 문서는 Gemini가 SQL을 생성하는 기능을 설명하면서, 그럴듯해 보이지만 사실과 다른 결과를 낼 수 있으니 모든 출력을 사용 전에 검증하라고 권합니다(2026년 10월 확인).

구조적인 이유는 단순합니다. AI는 문장을 SQL로 번역할 뿐입니다. 「이탈」이 30일 무구매인지 90일 무방문인지는 문장 안에 없습니다. 모호한 단어를 받으면 AI는 그럴듯한 기본값으로 빈칸을 채우고, 그 기본값이 우리 회사의 기준과 다르면 숫자는 조용히 틀립니다. 그래서 정확도는 도구가 아니라 정의와 검증에서 나옵니다.

월요일에 할 일 — 최근 데이터 요청 세 건이 왜 오래 걸렸는지 한 줄씩 적어 봅니다. 쿼리를 짜는 시간이었는지, 정의가 달라 다시 요청한 왕복이었는지. 왕복이 대부분이었다면 도구보다 1단계가 먼저입니다.

1단계 — 정의를 먼저 고정합니다

가장 중요하고, 가장 자주 건너뛰는 단계입니다. 팀 안에서 같은 단어를 같은 뜻으로 쓰고 있는지부터 확인합니다. 쇼핑몰에서 숫자가 가장 많이 어긋나는 다섯 가지는 이렇습니다.

이탈 기준은 감으로 정하지 말고 우리 몰의 재구매 간격에서 꺼냅니다. 두 번 이상 산 고객의 구매 간격을 모아 보고, 대부분의 재구매가 그 안에 들어오는 기간을 이탈 기준으로 씁니다. 소모품 몰과 가구 몰의 이탈 기준이 같을 수 없는 이유입니다. 이탈률을 신규와 안착 고객으로 나눠 읽는 법은 이탈률 계산법에서 다뤘습니다.

정한 기준은 문장 다섯 줄로 적어 두고, AI에게 질문할 때마다 질문 앞에 그대로 붙입니다. 「신규는 첫 구매일 기준, 매출은 취소·환불을 뺀 결제 금액, 시간은 한국 시간 기준」 같은 머리말 하나가 그럴듯한 기본값으로 빈칸이 채워지는 일을 막아 줍니다. 이 다섯 줄을 팀이 같은 문장으로 말할 수 있으면 1단계는 끝입니다.

2단계 — 테이블 세 개로 여섯 레버를 꺼냅니다

데이터가 많아 보여도 성장판에 필요한 테이블은 세 개입니다. 유저, 방문(또는 이벤트), 주문. 이 셋이 고객 ID 하나로 이어져 있으면 여섯 개 레버가 거의 다 나옵니다.

CC = 신규 유입 수 ÷ 이탈률
LTV = 구매자 전환율 × 객단가 × 구매빈도 × 생애주기
성장판 ≈ CC × LTV

레버마다 어디서 나오고 무엇을 먼저 물으면 되는지 정리하면 이렇습니다.

이 단계에서 확인할 것은 두 가지입니다. 첫째, 세 테이블이 같은 고객 ID로 이어지는가. 비회원 주문이나 앱·웹의 다른 식별자가 섞여 있으면 한 사람이 여러 명이 됩니다. 흩어진 기록을 한 사람 단위로 묶는 법은 CDP란에서 설명했습니다. 둘째, 방문 데이터가 어디에 있는가. 방문·이벤트가 웹 분석 도구에만 있고 주문 데이터와 연결되지 않는다면, 이탈률과 구매자 전환율은 당분간 주문 기준으로만 계산합니다. 이벤트를 어떻게 설계해야 구매·재구매까지 이어지는지는 구글애널리틱스 GA4 자사몰 전환 측정에 정리해 두었습니다.

3단계 — 자연어로 묻고, 쿼리에서 다섯 군데를 읽습니다

질문은 레버 하나에 문장 하나로 던집니다. 한 문장에 세 가지를 묻으면 AI가 만드는 쿼리도 길어지고, 틀린 곳을 찾기 어려워집니다. 그리고 결과 표만 받지 말고 생성된 쿼리를 한 번 읽습니다. SQL을 몰라도 아래 다섯 군데는 볼 수 있고, 틀린 숫자는 대부분 여기서 걸립니다.

1. 날짜 조건 — 원하는 기간이 맞는지, 마지막 날이 포함되는지 봅니다. 「1월」이라고 했는데 1월 31일 주문이 빠지는 일이 흔합니다

2. 제외 조건 — 취소·환불, 테스트 계정, 임직원 주문이 빠졌는지 봅니다. 정의서에 쓴 문장이 쿼리 조건으로 들어갔는지 확인하는 자리입니다

3. 연결 조건 — 주문과 주문 상품을 이을 때 금액이 여러 번 더해지지 않는지 봅니다

4. 시간 기준 — 날짜가 한국 시간인지 봅니다. 서버 시간이 세계 표준시면 자정 근처 주문이 다른 날로 잡힙니다

5. 분모 — 비율의 분모가 방문자인지, 회원인지, 구매자인지 봅니다. 같은 「전환율」도 분모가 다르면 다른 숫자입니다

세 번째가 가장 무섭습니다. 겉보기에 멀쩡한 숫자를 크게 부풀리기 때문입니다.

아래는 설명을 위한 예시 숫자입니다.

주문 한 건에 상품이 세 개 담겨 있고 결제 금액이 6만 원이라고 하겠습니다. 주문 테이블과 주문 상품 테이블을 그대로 이으면 이 주문은 세 줄이 되고, 각 줄에 결제 금액 6만 원이 붙습니다. 이 상태로 금액을 더하면 18만 원이 됩니다. 객단가가 세 배로 나오는데, 숫자가 이상하게 커 보이지 않으면 아무도 눈치채지 못합니다. 쿼리를 읽을 때 「주문 금액을 어느 테이블에서 더하는가」 한 가지만 확인해도 이 함정은 피할 수 있습니다.

쿼리를 읽기 어렵다면 AI에게 한 번 더 묻습니다. 「이 쿼리가 무엇을 세는지, 무엇을 빼는지 한국어 문장으로 설명해줘.」 설명이 정의서와 다르면 질문을 고쳐 다시 묻습니다. 이 왕복은 사람끼리 하던 2주짜리 왕복과 달리 몇 분이면 끝납니다.

4단계 — 한 번 뽑지 말고 코호트로 쌓습니다

한 번 뽑은 LTV는 사진입니다. 필요한 건 영상입니다. 첫 구매 월별로 고객을 묶고, D+30·D+90·D+180 누적 구매액을 매주 같은 방식으로 쌓아야 추세가 생깁니다. 그래야 지난달 들어온 고객이 석 달 전 고객보다 나은지 못한지가 보입니다.

위 표와 아래 계산은 설명을 위한 예시 숫자입니다.

코호트 표는 같은 경과일끼리 비교합니다. 5월 고객의 D+180과 8월 고객의 D+30을 나란히 놓으면 아무것도 알 수 없습니다. 같은 D+30끼리 놓으면 31,000원, 30,000원, 28,000원, 26,000원으로 줄고 있다는 사실이 바로 보입니다. 전체 매출이 늘고 있어도 최근 들어온 고객의 질은 떨어지고 있다는 신호입니다. 이때 할 일은 세부 지표를 열어 역추적하는 것입니다. 유입 경로가 바뀌었는지, 첫 구매 상품이 바뀌었는지, 첫 구매 뒤 첫 메시지가 늦어졌는지를 봅니다.

생애주기를 예측하려고 애쓰지 않는 것도 같은 이유입니다. 1년 뒤의 숫자를 예측하는 대신 가입 시점별 코호트를 매주 관찰하면, 추세선에 경향이 생기고 그 경향은 잘 변하지 않습니다. 변화가 생기면 그때 원인을 찾습니다. 예측할 수 없는 숫자를 붙들고 있는 것보다 관찰한 숫자로 결정하는 편이 훨씬 빠릅니다. 코호트 LTV로 회사 성적표를 읽는 법은 코호트 분석으로 LTV 보는 법에 자세히 썼습니다.

CC도 같은 방식으로 쌓습니다. 월 신규 유입 수가 3,000명이고 월 이탈률이 5%라면 CC는 3,000 ÷ 0.05 = 60,000명, 지금 구조로 도달할 수 있는 MAU의 천장입니다. 이 숫자를 매달 같은 정의로 기록해야 천장이 올라가고 있는지 내려가고 있는지가 보입니다. 질문 문장과 정의서 머리말을 함께 저장해 두면, 다음 주부터는 같은 질문을 다시 실행하는 데 30분이면 충분합니다.

AI가 뽑은 숫자를 믿기 전에 하는 검증 세 가지

속도는 검증을 건너뛰어도 된다는 뜻이 아니라, 검증할 시간이 생겼다는 뜻입니다. 처음 몇 주는 아래 세 가지를 습관으로 만듭니다.

• 합계부터 대조합니다. 처음 세 번은 기존 방식으로 뽑은 숫자와 나란히 놓습니다. 월 매출 합계, 월 주문 수처럼 관리자 화면에서도 볼 수 있는 숫자가 맞는지부터 확인하면, 제외 조건과 시간 기준 오류가 대부분 드러납니다

• 고객 다섯 명을 손으로 맞춰 봅니다. 결과에서 고객 다섯 명을 골라 실제 주문 내역과 비교합니다. 한 명이라도 구매 횟수나 금액이 다르면 연결 조건이나 고객 ID 정의를 다시 봅니다

• 검증한 질문은 고정합니다. 같은 내용을 매번 다른 문장으로 물으면 매번 조금씩 다른 쿼리가 나옵니다. 검증을 통과한 질문과 쿼리는 이름을 붙여 저장하고, 매주 그것을 다시 실행합니다

하나 더 챙길 것이 개인정보입니다. 외부 AI 서비스에 고객 이름, 연락처, 주문 상세를 그대로 붙여 넣는 방식은 피합니다. 개인정보보호위원회가 2025년 8월 6일 공개한 「생성형 AI 개발·활용을 위한 개인정보 처리 안내서」는 외부 API를 쓸 때 입력값이 해외 서버로 전송될 수 있으므로 계약이나 약관으로 안전성을 확보하라고 권고했습니다(바이라인네트워크 2025년 8월 6일 보도). 실무에서는 AI에게 테이블 구조와 질문만 주고, 쿼리 실행은 우리 데이터베이스 안에서 읽기 전용 계정으로 하며, 결과는 개인 단위가 아니라 집계값으로 보는 방식이 안전합니다.

이 방법이 통하지 않는 경우 — 뽑기 전에 모아야 하는 회사

30분은 데이터가 한곳에 모여 있다는 전제에서 나오는 숫자입니다. 그렇지 않은 경우도 분명히 있습니다.

• 데이터가 흩어져 있으면 모으는 게 먼저입니다. 주문은 쇼핑몰 관리자에, 방문은 웹 분석 도구에, 메시지 반응은 발송 도구에 따로 있다면 Text to SQL이 물어볼 곳이 없습니다. 이때는 30분이 아니라 연결 작업부터 시작합니다

• 코호트가 너무 작으면 숫자가 흔들립니다. 한 달에 첫 구매 고객이 수십 명뿐이라면 월별 코호트는 우연에 크게 흔들립니다. 분기로 묶어서 봅니다

• 정의는 AI가 정해 주지 않습니다. 이탈 기준, 신규 기준은 사업의 판단입니다. 도구가 바뀌어도 이 결정은 사람이 합니다

• 숫자는 원인을 알려 주지 않습니다. 코호트가 나빠졌다는 사실은 30분이면 알 수 있지만, 왜 나빠졌는지는 가설을 세우고 확인하는 일입니다. 질문의 속도가 빨라진 만큼 가설을 더 많이 시험할 수 있게 됐을 뿐입니다

확인해 볼 것

• 「신규」와 「이탈」의 정의를 팀 안에서 같은 문장으로 말할 수 있습니까

• 유저·방문·주문 데이터가 고객 ID 하나로 이어져 있습니까

• 지난달 첫 구매 고객의 D+30 누적 구매액을 지금 바로 말할 수 있습니까

• AI가 만든 쿼리의 결과를 관리자 화면 합계와 대조해 본 적이 있습니까

플라이휠 그로스 컨설팅과 리토스로는 이렇게 풉니다

이 글의 순서는 정의 고정 → 테이블 3개 → 쿼리 읽기 → 코호트로 쌓기입니다. 순서는 단순한데, 정의를 정하고 흩어진 데이터를 한 사람 단위로 묶는 첫 걸음에서 대부분 멈춥니다.

플라이휠 그로스 컨설팅은 그로스 진단과 성장판 분석에서 시작합니다. 여섯 레버의 정의를 회사와 함께 고정하고, 지금 값이 어디에 있는지 숫자로 꺼낸 뒤, 데이터 분석이 매주 저절로 돌아가는 AI 워크플로우로 남깁니다. 문서가 아니라 돌아가는 워크플로우가 남도록 하는 것이 목표입니다.

AI 그로스 CRM, 리토스는 CDP가 기본으로 들어 있어 연동 첫날 과거 12개월치 고객 데이터를 한 사람 단위로 묶고, 가입 시점별 코호트 LTV와 퍼널 분석을 기본으로 보여 줍니다. Text-to-SQL로 「지난달 재구매 VIP」처럼 자연어로 물으면 조건과 예상 모수가 나오고, 그 조건으로 바로 캠페인을 걸 수 있습니다. 숫자를 뽑는 데서 끝나지 않고 그 숫자를 움직이는 메시지까지 한곳에서 이어집니다.

정리

• AI 데이터분석과 Text to SQL이 줄인 것은 요청과 왕복에 쓰던 대기 시간이지, 숫자의 정확도가 아닙니다

• 실제 기업 데이터에서 Text to SQL의 정답률은 정돈된 벤치마크보다 크게 낮습니다. 정확도는 정의와 검증에서 나옵니다

• 신규·이탈·기간·매출·고객 한 명의 정의를 다섯 줄로 고정하고, 질문할 때마다 머리말로 붙입니다

• 유저·방문·주문 세 테이블이 고객 ID로 이어지면 CC와 LTV의 여섯 레버가 나옵니다

• 쿼리에서 날짜·제외·연결·시간 기준·분모 다섯 군데를 읽고, 처음 세 번은 기존 숫자와 대조합니다

• 한 번 뽑은 LTV는 사진입니다. 첫 구매 월별 코호트로 매주 쌓고 같은 경과일끼리 비교합니다

참고 자료

• Lei et al., Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows (ICLR 2025, arXiv 2411.07763, 2026-10-13 확인)

• Google Cloud — Write queries with Gemini assistance, BigQuery 문서 (2026-10-13 확인)

• 바이라인네트워크 — AI 생애주기별 개인정보 처리기준 첫 공개 (2025-08-06)

자주 묻는 질문

AI 데이터분석에서 Text to SQL이란 무엇인가요?

「지난달 첫 구매 고객 수를 보여줘」처럼 자연어로 질문하면 AI가 데이터베이스에서 실행할 SQL 쿼리를 대신 써 주는 방식입니다. 데이터팀에 요청하고 기다리던 왕복이 사라져 질문하는 사람이 직접 숫자를 확인할 수 있습니다. 다만 AI는 문장을 번역할 뿐이라 신규·이탈 같은 정의는 회사가 먼저 정해 줘야 합니다.

Text to SQL로 LTV를 계산하려면 어떤 데이터가 필요한가요?

유저, 방문 또는 이벤트, 주문 세 테이블이 같은 고객 ID로 이어져 있으면 됩니다. 주문 테이블에서 구매자 전환율·객단가·구매빈도·생애주기가, 유저와 방문 테이블에서 신규 유입 수와 이탈률이 나옵니다. LTV는 첫 구매 월별로 D+30·D+90·D+180 누적 구매액을 쌓는 코호트 방식으로 보는 것이 정확합니다.

AI가 만든 SQL 결과를 믿어도 되는지 어떻게 확인하나요?

먼저 월 매출 합계나 주문 수처럼 관리자 화면에서도 볼 수 있는 숫자와 대조합니다. 그다음 쿼리에서 날짜 조건, 취소·환불 같은 제외 조건, 테이블 연결로 금액이 중복되지 않는지, 시간대, 비율의 분모를 확인하고, 고객 몇 명을 골라 실제 주문 내역과 맞춰 봅니다. 검증을 통과한 질문은 저장해 두고 매주 같은 질문으로 다시 실행합니다.

↑ 누르면 리토스 소개 페이지로 이동합니다

↑ 누르면 뉴스레터 구독 페이지로 이동합니다

↑ 누르면 플라이휠 그로스 컨설팅 안내 페이지로 이동합니다