안녕하세요. 버킷플레이스 유저 인사이트(User Insights)팀 Fred입니다. 유저인사이트 팀은 데이터 분석과 리서치로 고객을 깊이 이해하고, 이를 오늘의집의 더 나은 의사결정과 실행으로 연결하는 팀입니다. 저는 AI Transformation을 위한 AX-TF에서도 활동하며, 이러한 분석과 판단을 분석가뿐 아니라 구성원 누구나 자신의 업무에서 직접 할 수 있도록 데이터 활용 환경을 만들어왔습니다.

과거에는 숫자 하나를 확인하는 데도 분석가에게 요청하고 답을 기다려야 했습니다. 기간이나 분류 기준을 바꾸고 싶으면 다시 요청해야 했고요. 분석가는 비슷한 추출을 반복했고, 질문자는 궁금한 점이 생길 때마다 기다렸습니다. 같은 이름의 지표라도 자료마다 정의가 달라 숫자를 비교하기 전에 기준부터 맞춰야 하는 일도 있었습니다.

필요한 숫자를 직접 확인하고, 다음 질문을 이어갈 수 있도록

이러한 기다림과 기준의 차이는 구성원이 업무에서 발견한 질문을 판단과 실행으로 이어가는 데 걸림돌이 되었습니다. 고객과 사업의 변화를 가까이에서 마주하는 구성원이 필요한 순간에 가설을 확인하고, 동료와 같은 기준으로 결과를 논의할 수 있다면 조직이 기회를 발견하고 배우는 속도도 빨라질 것입니다. 오늘의집은 질문에서 행동까지 이어지는 이 과정의 속도를 높이고자 했습니다.

이를 위해 AI와 대화하며 필요한 데이터를 조회하고 후속 질문을 이어갈 수 있는 셀프서비스 데이터 분석 시스템(Self-Service Data Analytics)을 만들었습니다.

AI가 질문의 뜻을 파악하고 조직에서 사용하는 기준에 맞춰 답할수 있도록 하기까지는 많은 시행착오가 있었습니다. 지표 정의와 데이터 설명, 업무 맥락, 분석 절차를 정리하고, Claude Code와 Slack에서 이를 참고해 답하는 환경을 구축했습니다. 이 글에서는 그 과정에서 겪은 문제와 해결 방법을 소개합니다.

우리가 겪은 문제 - 기술보다 Data Governance 정리가 최우선

누구나 데이터에 쉽게 접근해 결과를 받아볼 수 있도록 하는 첫 시도는 2025년에 이루어졌습니다. 첫 시도에서는 특정 도메인(커머스)을 대상으로 테이블 구조와 대시보드의 SQL 쿼리 예시, 업무 용어들을 모아 질문에 맞는 데이터를 찾도록 했습니다. 내부 Vector DB에 이 정보를 넣고 RAG 방식으로 구현했습니다.

결과는 원하는 대로 나오지 않았는데요. 먼저, SQL이 작성되더라도 질문자가 원하는 기준으로 계산한 결과인지는 판단하기 어려웠습니다. 같은 이름의 지표에 서로 다른 정의가 남아 있었고 쿼리도 여러 곳에 흩어져 있었습니다. 또한 테이블에 금액 항목이 있다는 사실만으로는 취소를 어떻게 반영해야 하는지 알 수 없었습니다. 더불어 해당 구조에서는 빠르게 바뀌는 업무 맥락에 맞춰 검색 대상 자료를 갱신하고 관리하기 어려웠습니다.

이후에는 단순히 SQL을 생성하는 것을 넘어, AI가 사내의 기준과 업무 맥락을 정확하게 이해하고 답변할 수 있도록 만드는 데 집중했습니다. 이를 위해 지표 정의와 데이터 사용 기준, 업무별 판단 기준을 체계적으로 정리했습니다. 이러한 기준들을 어떻게 정리하고 데이터분석봇에 적용했는지는 뒤에서 설명드리겠습니다.

현재 구조 한눈에 보기

구성원은 Claude Code나 Slack에서 필요한 데이터를 자연어로 요청합니다.
AI는 SKILL.md에 정리된 절차와 업무 지식 및 라우팅 로직을 참고해 필요한 데이터를 조회합니다.

구성 요소

AI는 구성원의 질문을 지표, 대상, 기간, 분류 조건으로 구체화하고, 각 조건을 판단하는 데 필요한 파일을 찾습니다. 이때 업무 문서와 카탈로그, 실제 데이터 구조를 서로 다른 목적으로 사용합니다. 업무 문서는 이번 질문에 어느 자료를 써야 하는지 안내하고, 카탈로그는 그 자료의 용어와 컬럼이 무엇을 뜻하는지 설명합니다.

실제 구조를 조회하면 필요한 컬럼이 있는지와 자료형을 확인할 수 있습니다. 이미 확인한 정의와 사용법으로 답할 수 있으면 이를 재사용하고, 새 분류나 낯선 데이터가 필요한 부분을 추가로 탐색합니다. 자료에 사용 제약이나 품질상 주의사항이 있다면 조회 조건에 반영하고, 계산으로 처리하기 어려운 내용은 답변에 함께 밝히도록 했습니다.

이때 dimension과 비교 기간이 바뀌어도 지표의 정의는 유지되어야 합니다. 지원되는 dimension이라면 Semantic Layer에 정리한 계산 규칙에 따라 다시 집계합니다. 추가로 필요한 데이터의 의미는 Catalog에서 확인합니다. Calendar SSOT를 참고해 비교할 기간을 정하고, 해당 기간에 발생한 사건을 확인합니다. 지표 정의와 데이터 설명, 기간 기준을 함께 사용해 조건을 바꾼 뒤에도 일관된 기준으로 비교할 수 있도록 했습니다.

사내 A/B 테스트 결과나 고객 행동에 관한 질문도 같은 환경에서 다룰 수 있습니다. 실험 결과는 XPC가 계산한 통계를 확인하고, 구매 과정의 이탈이나 재방문 같은 질문은 UBA로 분석합니다. 여기에 Business Context 문서에 정리한 업무 지식을 함께 참고합니다. 어떤 고객군을 비교해야 하는지, 결과를 해석할 때 어떤 업무 조건을 고려해야 하는지까지 살펴볼 수 있도록 각 툴과 업무 맥락을 연결했습니다.

답변에는 결과와 함께 사용한 자료, 지표 정의, 기간과 적용 조건을 남깁니다. 질문자는 어떤 기준으로 계산된 값인지 확인한 뒤 조건을 바꿔 다시 물어볼 수 있습니다. 앞선 답변의 기준을 참고할 수 있으므로 후속 질문마다 분석 조건을 처음부터 설명할 필요도 줄어듭니다. 구성원이 같은 대화에서 필요한 숫자를 확인하고, 궁금한 점을 이어서 탐색할 수 있도록 한 것입니다.

AI Harness - 라우팅과 역질문

AI Harness는 의도를 파악하고 필요한 맥락으로 연결합니다. 같은 거래액을 묻더라도 공식 수치를 확인하려는지, 상품별 차이를 비교하려는지에 따라 필요한 자료와 분석 방법이 달라지는데, 라우팅 과정에서는 이런 질문의 목적과 업무 맥락을 바탕으로 필요한 지표 기준과 분석 도구를 선택합니다.

업무별 지식과 분석 기준은 스킬 문서에 정리했습니다. AI는 이 문서를 참고해 사내에서 쓰는 용어와 지표의 의미를 파악하고, 질문에 맞는 자료를 찾습니다. 같은 이름의 지표라도 집계 대상이나 기간 기준이 다를 수 있으므로, 자료를 찾은 뒤에도 질문자가 원하는 기준과 맞는지 확인하도록 했습니다.

문서를 참고해도 질문의 의미가 분명하지 않을 때는 사용자에게 필요한 조건을 역질문합니다. 사용자가 이미 정한 조건은 유지하고, 지표의 뜻이나 비교 대상처럼 답에 영향을 주는 부분만 추가로 확인합니다. 질문자가 세부 계산 규칙을 모두 알지 못하더라도, 대화를 통해 자신이 원하는 분석 기준을 정할 수 있도록 했습니다.

가입자와 방문자 중 어느 쪽을 말하는지, 월간 고유 이용자인지 일평균 이용자인지부터 정해야 합니다. 전월과 비교하는지, 전년 같은 달과 비교하는지에 따라서도 답이 달라집니다.

구성원에게 확인할 조건과 자료에서 확인할 대표적인 내용은 다음과 같습니다.

• 정의 유일성: 같은 이름에 여러 지표 정의가 있다면 어떤 뜻인지 확인합니다. MAU라고 한다면 월별 순방문자인지, 앱만 카운트하는 것인지 확인합니다.
• 기간 단위 일치: 요청한 기간과 지표의 기본 단위가 맞는지 확인합니다. 취환불 반영이라고 하면 당월인지 당일인지 확인합니다.
• 탐색 범위 확인: 기간이나 플랫폼 조건 때문에 필요한 지표가 검색에서 빠지지 않았는지 확인합니다. 일부 조건에서 찾은 결과를 전체 목록으로 받아들이지 않도록 합니다.
• 비슷한 용어의 사용: 사내에서 누군가는 ‘사과’라고 표현하고 누군가는 ‘빨간 달콤한 과일’이라고 표현하면 통일된 용어로 분석할 수 있도록 역으로 질문합니다.
• 없다고 답하기 전 재확인: 검색에서 찾지 못한 지표가 실제로 없는지 다시 확인합니다. 충분히 확인하지 못했다면 어디까지 찾아봤는지 답변에 함께 밝힙니다.

위와 같은 점을 확인해서 분석봇이 다음과 같이 역질문을 합니다.

확인한 조건에 맞춰 분석 경로를 고른 뒤, 지표의 정의와 범위를 확인하고 필요한 자료를 찾아 집계와 결합 규칙에 맞춰 계산하도록 했습니다. 계산 후에는 결과를 검토하고 예상과 다르면 선택한 자료와 조건을 다시 살펴봅니다. Harness는 이런 지침과 도구, 실행 환경을 함께 구성한 것입니다.

쿼리 단계의 안전장치

SQL은 같은 금액을 두 번 더하거나 단위를 잘못 바꿔도 오류 없이 실행되기 때문에, 자주 반복되는 계산 실수를 미리 정리해 AI가 쿼리를 작성할 때와 결과를 검토할 때 확인하도록 했습니다.

아래는 쿼리 생성 시 적용하는 안전장치의 대표적인 예시입니다.

파티션은 데이터를 날짜 같은 기준에 따라 나누어 저장한 단위입니다. 필요한 파티션만 읽도록 조건을 넣는 것은 기본이고, 파티션을 나누는 기준 날짜가 분석하려는 날짜와 같은 의미인지도 함께 확인합니다.

취소와 환불은 원천 데이터가 기록한 방식 그대로 반영합니다. 취소 금액이 이미 음수로 들어 있는데 한 번 더 빼면 금액이 오히려 커질 수 있습니다. 금액 단위도 마찬가지입니다. 저장 단위와 표시 단위가 다르면 환산을 빠뜨리거나 두 번 적용하기 쉬우니 같이 점검합니다.

유지보수

문서 배포와 최신화

분석가는 각자 자신의 도메인에서 새로 발견한 개념이나 자료 사용 기준을 스킬 문서에 반영합니다. 문서의 원본은 한 저장소에 두고 Claude Code와 Slack 봇에서 사용하도록 배포합니다.

등록한 원본의 변경을 감지해 매일 Slack 봇으로 변경 사항을 알려줍니다. 해당 슬랙봇이 알려준 내용을 검토해서 새 원문으로 갱신하고 저장소에 반영합니다.

Feedback Loop: 단계별 평가

틀린 답을 받았을 때 무엇을 고쳐야 할지부터 알아야 했습니다. 질문을 잘못 이해한 경우와 자료를 잘못 고른 경우, 계산 중 기준이 달라진 경우는 수정할 곳이 다릅니다. 실행에 실패해 답을 받지 못한 경우도 따로 봐야 합니다.

라우팅에서는 질문에 맞는 분석 경로를 골랐는지, 역질문에서는 필요한 조건을 적절히 되물었는지를 따로 평가했습니다. 확인이 필요한 질문을 놓치는 일과 명확한 질문에도 불필요하게 되묻는 일을 함께 점검했습니다.

운영에서는 읽은 문서와 사용한 도구, 실행 결과와 오류를 기록합니다. 문서를 읽은 기록만으로 그 정의를 끝까지 적용했는지는 알 수 없습니다. 읽은 자료와 실제 계산, 최종 답을 대조해야 기준을 지켰는지 알 수 있습니다.

QES(Query Evaluation Studio)는 같은 질문을 반복 실행해 개선 전후를 비교하는 평가 도구입니다. 질문 묶음과 스킬 버전을 정해 실행 조건을 남깁니다. 질문이나 기준까지 바뀌었다면 점수 차이를 스킬 개선의 효과로만 해석하기 어렵기 때문입니다.

AI가 답을 만들 때는 정답과 채점 기준을 주지 않습니다. 받은 답을 저장한 뒤 별도 단계에서 기준과 비교하고 답의 수치가 맞더라도 출처와 계산 근거를 점검합니다. 다른 자료에서 우연히 같은 숫자가 나왔을 수도 있기 때문이죠. 개별 평가와 운영 기록, QES의 결과를 함께 보고 문서, 지표 정의, 평가 질문 중 어디를 고칠지 판단합니다.

구성원들이 잘 사용하기 위해서 - 사용성의 측면

쿼리스킬은 Claude Code와 Slack에서 사용할 수 있도록 했습니다. Claude Code에서는 작업 중 필요한 데이터를 요청하고 분석을 이어갈 수 있습니다. Slack에서는 데이터분석봇을 통해 업무 대화 중에 질문하고 같은 스레드에서 답을 확인하거나 후속 질문을 이어갈 수 있고요. 사용 안내에는 가능한 질문과 필요한 조건, 답의 범위를 담았습니다.

Slack에서 분석을 요청한 뒤 작업이 길어지면 구성원은 진행 중인지 알기 어렵습니다. 진행 상황을 표시하고, 작업이 지연되거나 실패했을 때도 상태를 알려 계속 기다리지 않도록 했습니다.

분석가는 반복 질문에 같은 설명을 새로 쓰는 대신 공통 규칙을 고쳐 전달할 수 있습니다. 또한 LLM이 후속 질문을 3~4개 정도 제안해, 구성원이 무엇을 물어봐야 할지 모를 때에도 분석을 이어갈 수 있도록 했습니다.

도입이후 가장 큰 변화는 구성원들이 필요한 데이터를 직접 탐색하고, 간단한 분석까지 스스로 수행할 수 있게 되었다는 점입니다. 도입 이후 데이터 요청 채널의 주간 문의는 약 95% 감소했습니다. 반복적인 데이터 추출과 조회에 쓰이던 부담이 줄면서, 데이터 분석가들은 더 깊이 있는 분석과 의사결정 지원에 집중할 여력을 확보했습니다.

또한 구성원들의 활용 범위도 넓어지고 있습니다. 여러 도메인에 흩어진 데이터 정보를 확인하고, 반복적인 보고서를 자동화하며, 업무에 필요한 데이터 도구를 직접 만드는 사례로 이어지고 있습니다. 구성원에게는 필요한 답을 스스로 찾을 수 있는 환경을, 데이터팀에는 더 중요한 문제에 집중할 수 있는 여력을 만들어가고 있습니다.

남은 과제들

먼저 업무 기준이 바뀔 때마다 사람이 여러 문서를 찾아 고치는 부담을 줄이려 합니다. 비즈니스 맥락 등이 변경되었을 때 변경을 감지하고 영향을 받는 지표와 문서를 찾아 수정안을 준비하는 과정을 자동화해야 합니다. 담당자는 변경 근거와 적용 시점을 함께 보며 업무의 의미와 규칙이 제대로 반영됐는지 검토하는 데 집중할 수 있도록 하려 합니다.

Semantic Layer에 등록한 지표 정의와 계산 규칙을 문서와 여러 조회 경로에서 재사용하는 범위도 넓히려 합니다. 지표를 변경할 때는 영향을 받는 분석을 확인하고 대표 질문을 다시 실행해 결과가 의도대로 달라졌는지 점검하는 과정까지 연결하고 싶습니다. 같은 기준을 여러 곳에서 따로 고치는 일을 줄이는 것이 목표입니다.

장기적으로는 업무 개념과 그 관계를 온톨로지 형태로 관리하는 방안도 살펴보려 합니다. 고객, 주문, 상품, 혜택이 어떤 관계를 맺고 어떤 업무 규칙이 적용되는지 정의해 여러 업무 영역에 걸친 질문에도 필요한 맥락을 찾아갈 수 있도록 하는 것입니다.

이런 과제들을 하나씩 해결해, 분석가가 다루는 난도 높은 질문에도 답할 수 있도록 발전시켜 나가려 합니다. 구성원의 질문이 더 나은 판단과 실행으로 이어질 수 있도록, 더 좋은 의사결정에 더 빠르게 다가서기 위한 여정은 계속됩니다.