안녕하세요, 에이블리 데이터 분석 챕터 리드 최윤성, AI 서비스 사업 PO 박근우 입니다.

에이블리에는 “나비 (NABI)”라는 데이터 분석 봇이 있습니다. Navigator for ABLY's Business Intelligence 의 줄임말로 에이블리의 비즈니스 인텔리전스를 안내하는 길잡이라는 의미와 함께, 작은 질문 하나가 비즈니스의 큰 변화를 만들어내는 "나비효과"가 되길 바라는 마음을 담아 지은 이름입니다.

나비의 시작은 데이터 분석가라면 누구나 공감할 법한 현실적인 고민에서 비롯되었습니다.

데이터 분석가의 아침은 보통 아래와 같은 슬랙 메시지로 시작됩니다.

대답하기 어려운 질문은 아니지만, 이러한 상시 데이터 확인이 하루에도 수십 번 반복되면 분석가는 더 깊이 있는 인사이트를 도출하거나 호흡이 긴 데이터 분석 업무에 몰입할 물리적 시간을 충분히 확보하기 어려워집니다. 그리고 동료들은 바빠 보이는 분석가에게 매번 비슷한 질문하는 것이 미안해 요청을 주저하기도 하죠. 에이블리 데이터 분석 챕터는 이 현상이 결국 조직을 데이터 기반의 의사결정에서 멀어지게 만든다고 보았습니다. 그래서 에이블리 구성원이라면 누구나 직접 데이터를 추출하고 살펴볼 수 있는 환경을 만들고자 “나비” 라는 데이터 분석 봇을 만들었습니다.

기획 초기만 해도 핵심 과제는 명확해 보였습니다. ‘자연어를 SQL로 얼마나 정확하게 변환 하느냐.’ 였죠. 하지만 제작 그리고 운영 과정에서 사용자에게 신뢰받는 데이터 분석 봇이 되기 위해 진짜 해결해야 할 본질적인 문제들은 따로 있다는 것을 확인했습니다.

• 방대한 데이터 중 AI가 어떤 데이터를 기반으로 답변해야 하는지?
• 같은 의도의 질문에 어떻게 일관된 답변을 제공할 수 있는지?
• AI가 스스로 잘못된 답변을 얼마나 빠르게 감지하고 바로잡을 수 있는지?

결국 나비를 만드는 과정은 단순히 쿼리를 짜주는 기능을 만드는 작업이 아니라, 누구나 믿고 쓸 수 있는 데이터의 기준을 세우고, AI와 인간 사이의 신뢰를 쌓아가는 과정에 더 가까웠습니다.

그럼 지금부터 에이블리 데이터 분석 챕터가 Text2SQL 에이전트 "나비"를 만들며 마주한 문제들과, 이를 해결해온 여정을 소개해 드리겠습니다.

1. 어디까지 자동화를 할까?

틀린 답을 자신 있게 내놓는 것은, 차라리 답을 하지 못하는 것보다 더 위험할 수 있습니다. 그럴듯해 보이는 답변이 비즈니스 의사결정을 잘못된 방향으로 이끌 수 있기 때문입니다. 그래서 데이터 분석가는 결과를 전달하기 전, 스스로 여러 질문을 던지며 답변을 검증합니다.

• 이 데이터가 목적에 맞는 테이블인지?
• 컬럼 정의가 변경되지는 않았는지?
• 결과 값이 비즈니스 맥락에서 자연스러운 수치인지?

그래서 분석가의 검증 과정을 나비에도 적용하고자 했습니다. 나비가 SQL을 생성하기 전, 반드시 메타데이터를 먼저 탐색하여 데이터의 맥락을 이해하도록 설계한 이유이죠. 단순해 보이지만 이 원칙은 나비의 정확도를 크게 높이는 데 중요한 역할을 했습니다. ‘메타데이터가 먼저, SQL은 그다음’이라는 원칙은 이후 나비를 설계하는 과정의 핵심 기준이 되었습니다.

2. 그런데 메타데이터는? - dbt를 SSOT로

나비가 SQL을 생성하기 전 메타데이터를 탐색하도록 설계하자 자연스럽게 다음 과제가 따라왔습니다. 바로 나비가 참고할 메타데이터 자체가 “충분히” 그리고 “잘” 정리되어 있어야 한단 점이었는데요. 실제로 나비를 만들며 가장 많은 시간을 들인 작업은 데이터 정의와 메타데이터를 정리하는 것이었습니다.

에이블리에는 이미 2024년부터 데이터를 신뢰할 수 있는 분석용 데이터로 가공하고 관리하기 위한 개발 도구인 dbt가 도입되어 있었습니다. 그래서 모델 간의 관계나 테이블 설명, 지표 정의 등을 코드로 함께 관리할 수 있어, 데이터의 의미와 기준을 정리하기에 적합한 환경이었습니다. 하지만 분석가가 안정적으로 다루기에는 다소 시간이 필요했고, 모든 분석 로직과 메타데이터가 완벽히 dbt 중심으로 정리되진 못한 상태였습니다. 그렇다보니, 나비를 제작하며 데이터를 살펴보았을 때 테이블 설명과 지표 정의는 여러 곳에 흩어져 있었습니다. 누군가의 Redash 쿼리나 노션 문서, 심지어 분석가의 머릿속에만 존재하는 경우도 많았습니다. 물론 나비가 기존 Redash 쿼리나 문서를 참고하도록 만들 수도 있었습니다. 하지만 과거 자료에는 작성 당시의 맥락과 오래된 로직이 함께 남아 있는 경우가 많았고, 현재 기준과 맞지 않는 정보도 적지 않았습니다. 결국 어떤 정보를 기준으로 답해야 하는지를 나비가 스스로 판단하도록 두는 것은 또 다른 불확실성을 만드는 일이었습니다.

그래서 dbt 프로젝트를 데이터의 SSOT(Single Source of Truth)로 만들기 시작했습니다. 흩어져 있던 지표 정의와 컬럼 설명, 테이블 관계, 비즈니스 룰을 dbt로 모으고, dbt가 데이터의 공통 언어 역할을 하도록 만들었습니다. 그리고 나비는 오직 이 기준만을 바탕으로 SQL을 생성하도록 설계했습니다. 즉, 컬럼 설명이 비어 있으면 나비도 답할 수 없고, 이름이 모호하면 잘못 해석할 가능성이 커집니다. 결국 SSOT의 완성도가 나비의 정확도를 결정하는 셈입니다.

이 과정에서 또 다른 긍정적인 변화도 있었습니다. 나비가 실제 업무에 활용되자, 비어 있던 데이터 정의들이 빠르게 채워지기 시작했습니다. “설명이 부족하고, 답변이 모호하다”는 피드백은 자연스럽게 dbt 업데이트로 이어졌고, 데이터 문서화 속도는 이전보다 훨씬 빨라졌습니다. 나비를 신뢰할 수 있는 시스템으로 구축하는 과정이 결과적으로 에이블리의 전사의 데이터 체계를 더욱 단단하게 정비하는 과정이 되었습니다.

3. 같은 지표, 다른 기준

메타데이터를 정리하는 과정에서 가장 많은 논의가 오간 주제는 “이 지표를 정확히 어떻게 정의할 것인가?”였습니다. 예를 들어 ‘상품 클릭률(CTR)’처럼 익숙한 지표도 기준에 따라 의미가 달라질 수 있습니다. 상품 단위의 노출 대비 클릭률을 볼 것인지, 특정 화면이나 리스트에서의 클릭률을 볼 것인지, 검색어별 상품 클릭률을 볼 것인지에 따라 참조해야 할 데이터와 계산식이 달라집니다. 같은 상품 CTR이라도 이벤트 수 기준으로 계산할지, 고유 사용자 수 기준으로 계산할지에 따라 결과가 달라질 수 있습니다. 데이터 분석가는 여러 맥락을 파악하고 이를 유연하게 판단할 수 있지만, 나비는 명확한 기준이 없으면 동일한 질문에도 서로 다른 답을 내놓을 수 있습니다.

이 문제를 해결하기 위해, 봇이 매번 SQL을 새롭게 생성하도록 두지 않았습니다. 대신 dbt의 Semantic Layer를 활용해 각 지표가 어떤 기준과 필터 위에서 계산되어야 하는지 미리 정의했습니다. dbt를 공통 지표 저장소(Metric Store)처럼 운영한 것이죠. 덕분에 상품 CTR, 화면/리스트 CTR, 검색어 CTR처럼 비슷해 보이지만 기준이 다른 지표를 각각 구분해 관리할 수 있었습니다. 각 메트릭에는 계산 방식과 필터 조건뿐 아니라 CTR, 상품 클릭률, 검색어 클릭률, 노출 대비 클릭률처럼 나비에게 질문을 던지는 사람이 실제로 사용하는 다양한 표현도 함께 저장했습니다. 덕분에 어떤 표현으로 질문하더라도, 나비는 에이블리 내부적으로 합의한 동일한 정의를 기준으로 답변할 수 있게 되었습니다.

하지만 지표를 잘 정의하는 것만큼이나 중요한 과제가 있었습니다. 사용자의 질문 의도에 가장 가까운 지표를 안정적으로 연결해 주는 작업이었습니다. 그래서 메타데이터 검색 결과에 여러 신호를 반영한 '점수 체계'를 도입했습니다. 명칭 일치도, 별칭(Alias) 포함 여부, 비즈니스 도메인, 서비스 특성 등 약 10가지 요소를 종합해 점수를 계산하고, 가장 적합한 지표를 선택하도록 설계했습니다. 질문이 반복되더라도 항상 동일한 기준으로 답변할 수 있도록 하기 위해서였습니다.

결국 신뢰할 수 있는 답변은 두 가지가 함께 갖춰질 때 가능했습니다. 하나는 지표의 정의를 명확하게 정리하는 일, 다른 하나는 사용자의 질문을 가장 적절한 지표 정의와 연결하는 일이었습니다. 사용자에게는 짧은 한 줄의 답변처럼 보이지만, 그 뒤에는 데이터 정의를 맞추고 기준을 정리하기 위한 많은 논의와 설계가 담겨 있습니다.

4. 신뢰는 검증 가능할 때 만들어진다.

나비의 답변이 정확해질수록, 그 결과가 어떤 과정을 통해 만들어졌는지 투명하게 검증할 수 있어야 한다고 생각했습니다. 데이터 분석가와 요청자 사이의 신뢰는 결국 결과를 확인하고 검증할 수 있을 때 만들어지기 때문입니다. 그래서 나비의 답변에는 항상 Redash 쿼리 링크를 함께 제공됩니다. 숫자만 전달하는 것이 아니라, 어떤 쿼리를 통해 해당 결과가 계산되었는지 사용자가 직접 확인할 수 있도록 한 것입니다. 데이터 규모가 큰 경우에는 통계값 중심으로 요약해 보여주되, 일부 원본 데이터도 함께 노출해 결과를 직접 검증할 수 있도록 설계했습니다.

그리고 답변 옆에는 사용자가 즉시 나비의 답변을 평가할 수 있는 점수 시스템(1~5점)을 추가했습니다. 이 피드백은 단순한 만족도 수집에 그치지 않고, 시스템을 개선하는 핵심 데이터로 활용됩니다. 낮은 점수가 반복되는 지표는 자동으로 거버넌스 검토 큐에 쌓이며, 이를 바탕으로 분석가가 dbt의 정의와 메타데이터를 다시 정비합니다. 자연스럽게 나비의 오답은 데이터 정의를 더 정교하게 다듬는 계기가 되었습니다. 그리고 피드백은 지표 추천 로직을 개선하는 데에도 활용됩니다. 분석가는 사용자 평가를 바탕으로 어떤 신호가 더 적절한 결과로 이어지는지 확인하고, 메타데이터 검색과 추천 과정의 가중치를 지속적으로 조정합니다.

또한, ‘잘 답하는 방법’만큼이나 ‘답하지 않아야 할 상황’을 구분하는 기능도 중요했습니다. 사용자가 가장 적절한 방식으로 빠르게 필요한 데이터에 도달할 수 있도록 하기 위해서였습니다. 예를 들어, TB 단위의 사용자 이벤트 로그처럼 대규모 테이블을 직접 조회하려는 요청은 자동으로 제한하고, 대신 “이 분석은 앰플리튜드에서 확인하는 편이 더 적합합니다.”와 같이 목적에 맞는 분석 도구를 안내하도록 설계했습니다. 무조건 많은 데이터를 조회하는 것보다, 목적에 맞는 도구와 경로를 안내하는 것이 더 좋은 사용자 경험이라고 판단했기 때문입니다.

5. 유저의 의도 분류하기

• "어제 매출 알려줘." — 당장 숫자가 필요한 상황
• "이거 다음에도 쓸 수 있게 저장해줘." — 파라미터 쿼리로 등록
• "지난번 그 쿼리에서 날짜만 바꿔줘." — 기존에 생성했던 쿼리 수정

위 세 질문에서 사용자가 기대하는 결과물은 모두 다릅니다. 첫 번째는 즉시 실행, 두 번째는 재사용 가능한 쿼리 등록, 세 번째는 이전 이력의 탐색과 수정인데요. 만약 나비가 사용자의 요청 및 질문 의도를 잘못 판단하면 사용자 경험에 큰 영향이 있을 수 있습니다. “지난번 쿼리를 수정해달라”는 요청을 오인해 매번 새 쿼리 생성으로 처리하면, 사용자는 다시 맥락을 설명해야 하고 불필요한 대화가 길게 반복될 수 있기 때문입니다.

“저장해.”, “고쳐줘.”처럼 명확한 표현은 비교적 구분하기 쉽습니다. 하지만 실제 업무 시에는 “이거 다시 좀 정리해줘”, “지난번처럼 다시 보여줄 수 있어?” 같은 의도가 모호한 표현이 훨씬 더 많습니다. 이를 해결하기 위해 의도 분류 결과의 확신도가 낮은 경우, 나비가 임의로 판단하지 않고 사용자에게 한 번 더 확인하도록 설계했습니다.

“이전 쿼리를 수정해 드릴까요, 아니면 새로 작성해 드릴까요?”

잘못된 결과를 바로 제시하는 것보다, 한 번 더 맥락을 확인하는 편이 더 안정적인 경험이라고 판단했기 때문입니다. 이는 실제 분석가가 데이터 요청을 받을 때 자연스럽게 질문을 되묻고 맥락을 확인하는 과정과도 닮아 있습니다.

결국 나비를 고도화하는 과정은 단순히 질문에 답하는 시스템을 만드는 일이 아니었습니다. 사용자의 의도를 이해하고, 상황에 맞는 행동을 선택할 수 있는 시스템을 설계하는 과정에 가까웠습니다.

6. 지속 가능한 운영을 위한 고민

나비가 본격적으로 운영되기 시작하면서, 또 다른 현실적인 문제와 마주하게 되었습니다. 바로 지속 가능한 운영 비용에 대한 고민이었습니다. 모든 작업을 가장 성능이 좋은 고비용 모델 하나에 맡기는 방식은 효율적이지 않았습니다. 사용자의 질문에서 검색 키워드를 추출하거나 결과를 간단히 요약하는 작업까지 무거운 추론 모델이 처리할 필요는 없으니까요.

시스템 내부에서 모델 별 역할을 분리하기 시작했습니다. SQL 생성이나 인사이트 해석처럼 복잡한 추론이 필요한 작업은 메인 모델이 담당하고, 키워드 추출이나 결과 요약, 의도 분류와 같은 상대적으로 가벼운 작업은 경량 모델이 처리하도록 구성했습니다. 이러한 역할 분담은 비용 절감만을 위한 선택은 아니었습니다. 경량 모델이 안정적으로 추출한 키워드는 앞서 소개한 지표 추천 시스템의 입력값으로 활용되었고, 이는 전체 답변의 정확도를 높이는 데에도 매우 중요한 역할을 했습니다.

또한 각 모델의 응답 속도와 비용, 안정성을 지속적으로 모니터링할 수 있는 체계도 함께 구축했습니다. 특정 모델의 응답이 느려지거나 장애가 발생하면 다른 모델로 자동 전환되도록 설계해 봇 이용의 안정성을 확보했습니다. 흔히 ‘모델 라우팅(Model Routing)’ 이라고 불리는 구조를 운영 환경에 적용한 것입니다.

7. 나비가 만든 나비효과

나비가 활발히 운영되면서 데이터 분석 챕터는 ‘구성원 누구나 데이터를 믿고 활용할 수 있는 환경을 설계하는 조직’으로 진화하고 있습니다. 즉, 답을 대신 만들어주는 조직에서, 신뢰할 수 있는 데이터 환경을 만드는 조직으로 역할을 확장해 가고 있는 것이죠.

나비 도입 후, 가장 큰 변화는 전사의 의사결정 속도가 비약적으로 빨라졌다는 점입니다. 이제 PO와 MD, 마케터, 디자이너를 포함한 구성원들은 분석가를 거치지 않고도 필요한 숫자를 직접 확인하고, 그 결과를 바탕으로 빠르게 다음 의사결정으로 이어갈 수 있게 되었습니다. 과거에는 간단한 SQL 요청 하나에도 분석가의 응답을 기다리며 의사결정이 지연되는 경우가 많았지만, 이러한 병목은 눈에 띄게 줄어들었는데요. 실제로 나비 도입 이후 약 두 달 동안 100명이 넘는 구성원이 1,000건 이상의 질문을 나비에게 남겼고, 같은 기간 데이터 분석 챕터로 들어오던 단순 SQL 요청은 눈에 띄게 감소했습니다. 구성원들이 데이터를 직접 탐색하고 활용하는 방식이 일상적인 업무 흐름으로 자리 잡은 것입니다.

그리고 구성원이 데이터에 던지는 질문의 깊이도 달라졌습니다. 단순한 지표 확인은 나비가 빠르게 해결해 주면서, 이제는 숫자 확인을 넘어 그 의미를 해석하는 데 더 많은 시간을 쓰기 시작했습니다.

분석가에게 의존하지 않고도 직접 숫자를 확인하고 검증하며 다음 단계로 이어가는 경험. 이런 변화들이 쌓이면서, 에이블리에서 데이터 민주화와 거버넌스는 더이상 선언적인 가치가 아니라, 에이블리언들의 실제 업무 방식으로 자리 단단하게 잡아가고 있습니다.

그리고 에이블리 데이터 분석 챕터는 나비를 질의응답 봇에 머무르게 하지 않고, 그 다음 단계로 확장해 나가고 있으며 현재는 크게 세 가지 방향의 고도화를 준비하고 있습니다.

첫 번째는, 한 줄의 SQL만으로 해결하기 어려운 복잡한 질문들에 대응하는 것입니다. 지표가 갑자기 하락한 원인을 찾거나 특정 캠페인의 효과를 분석해야 하는 상황처럼, 정해진 답이 없는 문제들이 대표적인데요. 이를 위해 나비가 먼저 분석 계획을 제안하고, 사용자와 방향을 맞춘 뒤 단계적으로 분석을 수행하는 ‘분석 시나리오 설계 모드’를 구축하고 있습니다. 단순히 결과를 반환하는 도구를 넘어, 답에 도달하는 과정 자체를 함께 설계하는 데이터 분석 파트너로 확장하고자 하는 시도입니다.

두 번째는, 나비가 자신의 답변을 스스로 검증할 수 있는 교차 검증 시스템입니다. 나비가 생성한 답변을 다른 모델이 다시 검토하고, 오류 가능성이 높다고 판단되면 결과를 바로 전달하는 대신 “이 답변은 신뢰도가 낮을 수 있습니다.”와 같이 먼저 불확실성을 안내하도록 설계하고 있습니다. 항상 정답을 말하는 시스템보다, 스스로의 한계를 인지하고 위험 신호를 먼저 전달할 수 있는 시스템이 더 신뢰할 수 있다고 생각했기 때문입니다.

세 번째는 인프라와 데이터 환경의 확장입니다. 현재는 TB 단위의 대규모 사용자 행동 로그를 나비가 직접 조회하지 않고, 앰플리튜드와 같은 분석 도구를 활용하도록 안내하고 있습니다. 앞으로는 로그 적재 구조와 쿼리 최적화 환경, 마트 레이어를 함께 정비해 이벤트 기반의 복잡한 분석까지 나비 안에서 자연스럽게 수행할 수 있는 환경을 구축하고자 합니다.

8. 마치며 - 업의 본질을 다시 고민할 수 있었던 시간

데이터 분석 봇을 구축하며 얻은 가장 큰 깨달음은, 데이터 분석가의 역할이 단순히 무엇을 자동화할 것인가에 머무르지 않는다는 점이었습니다. 더 중요한 것은 무엇을 신뢰할 수 있게 만들 것인가였습니다.

돌이켜보면 이번 프로젝트의 핵심은 단순히 나비라는 봇을 만든 데 있지 않았습니다. 나비가 안정적으로 동작할 수 있도록 메타데이터와 지표 정의, 모델 간 관계를 정비하고 데이터 환경 전반을 신뢰 가능한 구조로 다듬는 과정 자체가 더 중요한 일이었습니다. 나비는 그 위에 만들어진 하나의 표면에 가까웠습니다.

결국 나비는 완성된 도구라기보다, 에이블리의 데이터 환경을 더 신뢰할 수 있는 방향으로 바꾸어 나가는 과정에 가깝습니다. 지표의 정의를 하나의 제품처럼 관리하고, AI가 언제든 틀릴 수 있다는 전제 위에서 검증 가능한 가드레일을 설계하며, 구성원들이 더 빠르고 올바른 판단을 내릴 수 있는 환경을 만드는 일. 에이블리 데이터 분석 챕터는 오늘도 그 기반을 계속 다듬어 가고 있습니다.