[AI-Native AFINIT] 5분 안에 데이터 분석 질문을 답해주는 AI 데이터 분석가를 만든 이야기

1. PM과 DA의 경계 그 사이 어딘가

저는 PM(Product Manager)인데 사실 프로덕트 데이터분석가(DA, Data Analyst) 역할도 같이 하고 있었습니다. 리스크팀이나 프로덕트팀에서 숫자 질문이 오면 제가 받았거든요.

예를 들어, Credit Insights (저희가 만든 신용점수 조회 상품) 결과 페이지를 본 유저의 CIBIL(인도의 개인신용평가 점수, 즉, 한국의 NICE·KCB 점수와 비슷한 개념) 비중이 궁금하다거나,
특정 월에 LVL(소액 신용대출 상품) 신규로 들어온 사람들이 이후에 CL (LVL보다 큰 금액의 신용대출 상품)로 얼마나 넘어갔는지,
EMI(매달 갚는 원리금, Equated Monthly Installment)를 며칠 먼저 내는 사람이 몇 퍼센트인지..
짧아 보이는 질문인데 하루에도 몇 건씩 쌓아놓고 분석하는게 업무의 큰 비중일때가 있었습니다.

사실 인도에 있는 데이터 분석팀한테 요청을 넘기던 시절이 있었습니다. 하지만 보고 싶은 데이터를 말로 설명해야 하고, 데이터 분석팀의 업무 우선순위에 따라 요청을 기다려야 하고, 막상 결과가 나오면 그걸 검증하고 추가로 요청하는 데 또 그만큼 시간이 걸렸습니다. 그래서 어느 순간부터는 그냥 제가 직접 SQL을 짜기 시작했어요. 결과는 CSV로 받아서 Google Spread Sheet에 Import하고, Pivot table 돌려서 insight를 뽑고, 그걸로 분석하고 분석결과를 보고해왔었습니다.

문제는 분석이 복잡해질수록 SQL 쿼리 하나 만드는 데도 검수를 몇 번씩 거쳐야 한다는 거였습니다. 테이블부터 확인하고, 그 안에 컬럼이 무슨 뜻인지 확인하고.. 큰 쿼리 하나 짜서 돌리고 검증까지 마치면 2~3시간은 그냥 지나갔습니다.

2. 반나절이 5분이 된 이야기

이 흐름이 바뀐 건 지난 두 글에서 다뤘던 AI Sidekick(사내에서 만든, 개인별로 붙는 AI 에이전트 플랫폼) 도입 이후였습니다.

• AI와 함께하는 FPJR 실시간 메트릭 모니터링 (2026-03-27)

• 한 명의 PM이 더 큰 임팩트를 만드는 방식 (2026-05-08)

처음엔 SQL 쿼리 짜는 속도만 눈에 띄게 빨라졌습니다. 테이블 스키마랑 맥락을 Cursor(AI가 코드를 같이 짜주는 개발 툴)에 미리 심어두니까, 예전엔 2~3시간씩 걸리던 그 검수 과정이 거의 사라졌어요.

진짜 변화는 그 다음이었습니다. 저랑 에이전트가 같이 쌓아온 repo(코드·문서를 모아두는 저장소, repository) context가 계속 진화하면서, Pivot 돌리고 insight 뽑는 과정까지 AI가 알아서 하기 시작한 겁니다. SQL 짜고, 실행하고, Pivot table 돌리고, insight 뽑고, Slack에 정리해서 올리는 것까지... 원래는 반나절 걸리던 일이 5분 안에 끝났습니다. 쓸때마다 정말 놀라운 변화라고 느꼈고, 이 AI의 도입이 저의 큰 부담이었던 데이터 분석 리소스를 획기적으로 줄여주었습니다.

그런데 이걸 계속 반복하다 보니, 그 작업물들 (SQL 코드, Pivot 돌리는 Python 코드, 분석 리포트 md 파일) 이 어느새 엄청 쌓여 있더라고요. 그래서 저 혼자 쓰는 대신 모두가 쓰는 Slack 채널에 그대로 배포하기로 했습니다. 5분 안에 답하고 24시간 쉬지 않는 프로덕트 데이터분석가를, 사실상 새로 하나 만든 셈입니다.

3. 아직은 나에게 물어보는 나의 동료들

저의 리소스를 많이 잡아먹었던, 리스크팀이랑 프로덕트팀에서 오던 데이터 질문은 대략 이런 것들이었습니다.

• Credit Insights 결과 페이지를 본 유저 중 CIBIL 점수 vs CIBIL no-history 비중

• 특정 월 LVL 신규유저 코호트(같은 시기에 들어온 유저 묶음)가 이후 LVL 재방문유저 / CL로 얼마나 갔나

• 최근 6개월 EMI를 만기 전에 3일 이상 먼저 내는 비중

• 이 user_id에 SMS evaluation(문자메시지 데이터를 활용한 신용평가 모델)이 왜 없나

질문 자체는 짧죠. 근데 그 5분짜리 분석도 결국 저한테 먼저 물어봐야만 시작됐습니다. 동료 입장에서 보면 선택지가 둘이었어요. Athena(SQL로 데이터를 조회하는 AWS 서비스)에 직접 접근해서 SQL쿼리를 작성해 데이터를 받거나, 저한테 Slack으로 묻거나. 전자는 스키마를 알아야 하고 후자는 제 일정을 기다려야 하니까, 스키마를 잘 모르면 그냥 저한테 물어보는게 빨랐을 테니 저한테 질문이 계속 들어오고, 저는 PM 일을 하면서 사실상 데이터분석가로서 분석 큐를 계속 받고 있었던 셈입니다.

그래서 다음 목표는 명확했습니다. 제가 개인적으로 쓰던 Cursor를 활용한 데이터 분석을 5분짜리 워크플로우를 슬랙 채널로 그대로 옮기는 것이었습니다. 제 분신을 그냥 하나의 슬랙채널에 상주시키는 것이었죠. 제가 쓰던 Athena 접근이랑 DDL(테이블 구조를 정의한 스키마 문서), 분석 규칙, 그리고 쌓아둔 산출물들을 채널 봇 뒤에 붙이기만 하면 가능하겠다 생각하고 바로 실행했습니다.

4. 누구나 쉽게 쓸 수 있는 데이터 분석 슬랙 채널

쓰는 법은 구성원들이 슬랙 메신저에서 데이터 분석가에게 멘션하는 UX 그대로 구현했습니다.

1. #afinit_data_analysis_request 에 들어간다

2. @sk-dennis-data-request 를 멘션하고 질문을 적는다

3. 진행 이모지가 붙고 분석이 끝나면 같은 스레드에 답이 온다

여러 번 혼자 테스트 후에 배포를 알렸고, 배포 직후에는 채널에 바로 안 들어오셨지만, 써보신 분들이 자신의 동료를 이 채널에 초대하기 시작했고, 사내에서 제 AI agent가 입소문나기 시작했습니다.

인도인과 한국인, 그리고 사내에서 돌아가는 각자의 AI Agent 상관없이 그들의 언어로 질문이 올라왔습니다. 예시로 다음은 지난주에 채널에 실제로 올라온 질문입니다.

Credit Insights 에서 결과 페이지를 본 유저의 데이터를 분석하고 싶어.
모수는 Credit Insights 서베이 완료하여 결과 페이지를 본 유저
알고 싶은 데이터는 그 중 CIBIL 점수가 있는 유저와 CIBIL no history 유저의 비중

한국어로 물어보면 한국어로 답하고, 영어로 물어보면 영어로 답하고 있습니다. 인도와 한국 모든 구성원들이 자유롭게 쓸 수 있는 AI 데이터분석가가 탄생했습니다 🎉

리스크팀에서는 LVL 신규유저 코호트의 이후 집행을 물었고, 프로덕트팀에서는 EMI 선납 비중이랑 월별 MAU(월간 활성 사용자 수, Monthly Active Users)를 물었습니다. 예전에 저한테 오던 질문이 그대로 채널로 옮겨온 것이었고, 저는 이제 신경을 꺼도 되는 수준이었습니다.

여기서 생성하는 답은 그 메시지 스레드에 Sidekick Agent가 실행한 sql, 인사이트 숫자가 곧바로 붙습니다. 이어 같은 스레드 댓글에서 질문을 하면, 해당 스레드의 맥락을 AI가 확인하고, 분석 세그먼트 구간을 알아서 나누고, 거기서 나오는 인사이트와 조언까지 알아서 답변했습니다. 예전 같으면 제가 이 질문 하나에 몇 번을 더 받았을 후속 질문까지, 여기서는 다 5분 남짓 안에 채널 안에서 끝났습니다.

참고로 이 데이터 분석 에이전트는 그럴듯한 문장을 거의 쓰지 않습니다. 테이블 이름을 지어내면 안 되고요, repo에 있는 DDL이랑 예전에 짜둔 SQL을 먼저 찾고 필요하면 DESCRIBE로 컬럼을 확인한 다음에 읽기 전용 SELECT만 Athena에 보냅니다. 쿼리가 깨지면 깨진 채로 얘기하고 고쳐서 다시 돌리고, 결과가 없으면 없다고 합니다. 대답에 신뢰를 붙일수 있는 장치를 아래와 같이 만들었습니다.

답 아래에는 짧은 footer를 붙입니다.

_logic: 지표를 어떻게 정의했는지

_tables: 실제로 쓴 db.table

_code: 열어본 DDL/참고 파일

_query: 결정적 쿼리가 한 일 (한 줄)

5. Cursor로 쌓아 온 Sidekick GitHub repo

이 AI 데이터분석가 봇 코드 자체는 그렇게 두껍지 않았습니다. 채널에서 분석가처럼 답이 나오는 건 코드를 잘 짜서가 아니라, 뒤에 붙어있는 이미 검증된 산출물 덕분이고요. 앞서 말한 그 5분짜리 개인 워크플로우를 개인적으로 몇 달 반복하면서 쌓여온 것들입니다.

이전 글에서 Sidekick repo를 harness(AI를 감싸는 실행 틀, 어떤 자료를 읽히고 어떤 도구를 쓰게 할지 짜놓은 구조)라고 부른 적이 있는데, 여기도 똑같습니다. 보통 AI 쓰면 처음에 테이블 의미며 Jira(이슈·티켓 관리 툴) 배경이며 Slack 논의며 과거 실수까지 매번 다시 설명해줘야 하잖아요.

그런데 제가 Cursor로 일한 결과와 그 설명을 GitHub Sidekick repo에 전부 남겨두니까, 다음에 AI가 처리하는 작업은 그 파일을 읽고, 거기서부터 AI가 시작하면 됩니다.

이번에 구현한 데이터 질문 채널 내에서도 마찬가지입니다. 에이전트용 지식 베이스를 따로 만들지 않았어요. 지난 몇 달 동안 제가 Cursor로 돌린 분석이 이미 repo 안에 있었거든요. 그냥 그것을 AI가 돌아갈때 참조하게 했던 것이 전부였습니다.

• SQL: UAT(배포 전 실제 데이터로 검증하는 테스트, User Acceptance Testing) 쿼리 · funnel(유저가 서비스를 이용하는 단계별 흐름) 분석 · A/B 테스트 impact 분석 · 케이스 한 건, 한 건을 뜯어본 것. Jira 티켓 단위로 정리해 둔 이 쿼리들이 사실상 정답 예시입니다.

• Python: Athena 헬퍼 · Pivot 돌리던 스크립트 · 지표 재현 코드. 한 번 돌아간 코드라 "이 숫자는 이렇게 뽑는다"가 남아 있습니다.

• Markdown: 지표 정의 · config 값 의미 · Lead Gen(외부 금융 파트너로 유저를 연결해주는 상품) KPI · 실패 메모 · 분석 리포트. 모델이 추측하면 안 되는 문장들이 여기 있습니다.

• Slack 초안: 채널에 올렸던 공유문. 어떤 표를 올렸고 어떤 주의사항을 붙였는지가 남아 있습니다.

파일이 많아서 좋은 게 아니라, 사람이 한 번 보고 실제 업무에 쓰고, 피드백이 오간 것들이라서 그렇습니다. 테이블 이름을 지어낸 SQL이 아니라 Athena에서 진짜로 돌아가고 Slack에 올렸던 SQL이고요. 예를들어 "Offer List 결과 페이지를 본 유저"라는 데이터를 정의할때, 이 데이터를 결과 화면의 page_view에서 계산을 할 것인지, 아니면 서베이를 끝낸 다음 나오는 그 상태를 (status='SUCCESS') 계산 할 것인지 알 수 있는 맥락은 새 프롬프트로 맞힐 문제가 아니라, 레포에 있는 KPI 데이터 정의랑 DDL을 읽으면 되는 문제입니다.

그래서 AI LLM 모델을 업그레이드 하는 것도 중요하지만, 이 컨텍스트 파일들이 제대로 들어갔는지가 더 중요합니다. 그리고 아래와 같이 업무에서 쌓은 노하우가 들어가는 것이 중요합니다.

• abc.*(더 이상 쓰지 않는 레거시 테이블 계열)는 이제 쓰지 말 것

• CDC(원본 DB의 변경분만 복제해 쌓은 테이블, Change Data Capture)는 dt 파티션(날짜별로 나눠 저장한 컬럼)이 필요함

• Lead Gen(위에서 말한 그 외부 금융 파트너 연계 상품) 실행은 partner_status = 'DISBURSED' 로 본다는 것.

업무를 하면서 쌓여왔던 이런 도메인 지식들은 아무리 모델을 강화한다고 해서 정의하거나 해결할 수 있는 문제가 아니라 일하다가 쌓인 지식들이 repo에 그대로 남은 거고, 분석할 때마다 SQL이랑 코드랑 md랑 Slack 초안을 남겨두던 습관이 나중에 채널 봇의 두뇌가 되었습니다.

Slack에서 봇 멘션 + 질문
→ 채널을 폴링해서 요청을 집고 진행 이모지를 붙임
→ 스레드 맥락과 repo 산출물을 읽고 질문을 해석
→ Agent Tool 호출 반복 (search_ddl → describe_table → run_sql )
→ post_answer로 스레드에 표와 해석을 올리고 완료 이모지

예전에 제가 노가다로 했던 테이블을 탐색하는 방식들도 저 워크플로우에 녹였습니다. 이를테면 SELECT/WITH/SHOW/DESCRIBE와 LIMIT을 붙여 파악하는 방법입니다. 여기에 특정 필드를 가져오지 않으면 알아서 경고하고 보충하게 했습니다.

이제 이렇게 두뇌를 만들었던 과정은 마무리하고, 두뇌를 어떻게 팔과 다리로 연결했는지, 분석가에게 물어보는 유저의 경험을 어떻게 만들었는지는 아래에서 다루겠습니다.

6. Slack에서 반응하는 사람처럼 만들기 위한 작업

제 맥북에서 저 혼자 5분 만에 답하는 거랑, 채널에서 여러 사람이 며칠씩 쓰는 건 완전히 다른 문제더라고요. 이 데이터분석가 에이전트를 안정화하면서 이 사용자 경험을 발전 시켰던 것은 AI 모델 그 자체가 아니라 Slack 엑세스와 대답 프로세스의 시행착오 였습니다.

Slack 스레드 안에 있는 맥락이 보이지 않는 문제

처음에는 이 데이터분석가 에이전트가 Slack 스레드에 재 질문을 하면 그것에 대한 답글을 주지않았습니다. 그래서 첫 질문엔 답하고 "월별로 쪼개서 다시볼수있을까?" 같은 후속 대화는 못 보는 상태였습니다. 부모 메시지를 이미 처리했다고 스레드를 놓아버리면 그 대화는 그냥 거기서 끝나버립니다.

지금은 멘션이 들어온 스레드를 최대 n일까지 다시 봅니다. 후속 질문은 스레드 전체를 읽은 다음에만 답하고요. 맥락을 못 읽으면 대충 답하는 대신 다음 사이클로 미룹니다. 이 가드레일이 생기기 전에는 FPD/DPD(금융상품 연체를 나타내는 지표, First/Days Past Due) 질문 스레드에 전혀 다른 주제의 retention matrix가 붙은 적도 있었어요. 틀린 답을 자신 있게 올리는 게 아무 말 안 하는 것보다 더 나쁘거든요..

진행 이모지가 없는 문제

분석은 보통 20~40초, 무거운 건 몇 분씩 걸립니다. 그동안 이모지가 안 붙어있으면 "봇이 죽었나?" 느껴졌습니다. 그래서 요청을 집는 순간 progress 이모지를 붙이게 했습니다.

그런데 Slack에 봇이 자동으로 글을 올리는 API에 rate limit (한도)에 걸리면 루프 전체를 90초씩 쉬게 짜뒀던 때가 있었습어요. 그 사이에 새로 올라온 멘션은 history조차 못 봤습니다. 지금은 스레드 폴링만 잠깐 멈추고 채널 history 탐색을 계속 돌리게 했습니다. 새 질문은 답보다 먼저 이모지라도 받게요.

랩탑에서 원격 24/7로

처음엔 그냥 제 맥에서 돌렸습니다. 되는지만 보려면 그걸로 충분했었거든요. 근데 제 맥북 덮개를 닫으면 채널도 같이 멈춰버립니다. 5분 안에 답한다는 게 의미가 있으려면 제가 자고 있을 때도 5분이어야 했습니다.

그래서 같은 워커를 원격에 올렸습니다. 사내에서 dorm이라고 부르는, 상시 켜져 있는 원격 개발 서버로 코드를 밀어넣고, 비밀값은 원격 ~/.sidekick/.env만 쓰게 했어요. 한 사이클이 실제로 도는 거 확인하고 나서 채널에 남겨뒀습니다. 랩탑에서 자동 재시작하는 건 개발용이고, 결국 24시간 돌리려면 24시간 돌아가는 원격 서버에 배포를 해야 했습니다.

원격으로 옮기고 나서야 제가 자리를 비워도 질문이 안 쌓이게 됐습니다. 8월 11일 런칭 때는 사실 아직 제 맥에서 돌아가고 있고, 테스트/개선 중이었고, 그로부터 열흘 좀 넘게 지나서 멘션이 실제로 잘 돌아간다는 느낌이 든 다음에 원격에 배포하고 본격적으로 24시간 서비스를 시작하게 되었습니다.

바뀐 데이터 분석 일상과 한계점

그래도 아직 전사 기본 분석 툴이라고 하긴 이릅니다. 인도에 있는 데이터분석가 조직이 있고, 그들은 더욱 심층적인 분석과 원인과 이유, 액션아이템 등을 여전히 심도있게 제시해주거든요. 그래도 분명한 건, 원래 반나절 걸리던 데이터 분석이 5분이 됐고, 그게 저 혼자만 쓰는 게 아니라 채널에 있는 모두가 쓴다는 겁니다. 리스크팀이랑 프로덕트팀의 짧은 탐색 질문은 이제 제 DM을 기다리지 않고, 저는 지표 정의가 애매하거나 "이 숫자로 rollout 해도 되나" 같은 판단에만 시간을 씁니다.

사람이 데이터 분석을 할때 있던 몇몇 한계도 그대로 있습니다. 예를 들어, 질문에 대한 sql query 실행시간이 너무 길어지면 20분에서 끊고 있고, 적절한 스키마를 못찾기도 해서 그때는 어디서 막혔는지 말하게 했습니다. 그리고 채널에 어떤 질문을 열지, 지표 정의를 어떻게 문장으로 남길지는 여전히 제가 정하고 있습니다. 에이전트를 올렸다고 끝나는 것이 아니라, 오히려 뭘 결정하고 말하는게 좋을지, 어떤 데이터 소스를 봐야할지, 어떤 형식으로 보여줄지 정확히 알려줘야할 주체는 여전히 사람이 해야할 일입니다.

7. 마치며

인도 데이터 분석가한테 요청을 넘기고 하루이틀 기다리던 때를 생각하면, 지금은 확실히 다른 세상입니다. 반나절 걸리던 개인 워크플로우가 5분이 됐고, 그걸 채널에 그대로 올려서 이제는 저 대신 여러 명이 24시간 이 에이전트에게 물어봅니다.

새 화면이나 새 시스템을 만든 게 아닙니다. 매일 Cursor로 짜고 검증한 SQL, Python, md 파일이 repo에 쌓였고, 그 위에 얇은 Slack 봇 하나를 올렸을 뿐입니다.

그렇다고 이게 다 된 건 아닙니다. 제일 걱정되는 건 사실 틀린 답을 자신있게 내놓는 순간입니다. 지금은 테이블이랑 컬럼을 repo에서 찾아서 쓰게 막아놨고 스키마에 없으면 모른다고 말하게 해놨지만, 질문이 조금만 복잡해지거나 지표 정의가 애매하면 여전히 사람이 한 번 더 확인해야 합니다. 그리고 이게 가능했던 것도 제가 몇 달 동안 Cursor로 직접 짜고 검증한 SQL과 문서가 이미 repo에 쌓여 있었기 때문이지, 처음부터 AI 혼자 해낸 일은 아니었습니다. 아무도 안 써본 테이블, 맥락이 하나도 없는 데이터였다면 지금도 이 에이전트는 저만큼 헤맸을 겁니다.

그래도 이 방향 자체는 꽤 명확하다고 봅니다. 돌이켜보면 이번에도 단계가 있었거든요. 처음엔 SQL 짜는 속도만 빨라졌고, 그 다음엔 Pivot 돌리고 insight 뽑는 것까지 넘어갔고, 지금은 그걸 채널에 올려서 다른 사람 질문에도 답하는 수준까지 왔습니다. 지금 제가 쌓아주는 건 "이 테이블은 이렇게 읽는다", "이 지표는 이렇게 정의한다" 같은 맥락인데, 이걸 AI가 직접 찾고 검증하고 쌓는 범위가 넓어지면, 그 다음 단계는 숫자가 튀었다고 알려주는 것보다 왜 튀었는지에 대한 가설까지 같이 던지는 쪽일 거라고 생각합니다. 임계값 넘으면 알림 오는 기능 자체는 이미 흔해서 새로울 게 없지만, "이 지표가 떨어진 게 최근에 바뀐 그 정책 때문일 수도 있다"처럼 레포에 쌓인 과거 분석이랑 변경 이력까지 엮어서 원인을 짚어주는 건 맥락이 쌓여야만 가능한 일이고, 지금 제가 슬랙 채널에서 계속 쌓인 대화로 AI 에이전트가 참조하는 맥락을 더 강화하고 있는 일의 연장선이거든요.

그럼 인간 데이터 분석가라는 직업 자체는 어떻게 될까요. SQL 짜고 돌리는 쪽 일은 꽤 많이 줄어들 거라고 봅니다. 저만 봐도 이미 그 부분은 거의 사라졌고요. 근데 "이 지표를 어떻게 정의할지", "이 숫자로 뭘 판단할지"는 AI가 대신 정해주는 게 아니라 여전히 사람이 쥐고 있어야 하는 부분입니다. 그래서 저는 이 직업이 없어진다기보다는, '쿼리 짜는 사람'에서 '뭘 물어볼지와 그 답을 어떻게 쓸지 정하는 사람'으로 무게중심이 옮겨갈 거라고 봅니다. 다만 쿼리를 실행하는 것 자체가 일의 거의 전부였던 역할이라면, 거기엔 솔직히 위기감을 느껴야 하는 게 맞다고 생각합니다.

지금도 저희 회사에서는 누구나 숫자와 데이터가 필요할 때 #afinit_data_analysis_request 채널에서 @sk-dennis-data-request를 부릅니다. 반나절 걸리던 분석 요청이 이렇게 5분짜리 멘션 하나로 바뀐 것, 이게 AI가 만들어 준 또 하나의 생산성 퀀텀 점프입니다.