심 혁주 
안녕하세요, 베이글코드 데이터&AI팀 데이터 엔지니어 정수창입니다.
최근 많은 기업이 AI 에이전트를 실무에 적용하려는 움직임을 보이고 있습니다.
저희 회사에서도 정기적으로 AI 해커톤, <Bageljam:Dev>를 열고 있는데요. 저희 팀은 데이터 에이전트를 출품해 비즈니스 밸류 상을 수상했습니다.
오늘은 단순히 일회성 수상으로 끝내지 않고 프로젝트를 계속 진행하여 개발하고, Databricks Data Intelligence Day 한국 이벤트 2025에서 발표했던 ‘Bagelcode의 데이터 에이전트 D.A.V.I.S. 와 지니를 활용한 데이터 기반 의사 결정 가속화’에 관한 이야기를 해보려고 합니다.
1. Motivation
베이글코드는 글로벌 시장을 무대로 빠르게 성장하고 있는 모바일 게임 전문 기업입니다.
저희는 글로벌 시장에서 다년간 쌓아온 데이터&AI 기술과 마케팅 역량을 중심으로 철저한 데이터 기반 의사결정을 하고 있으며, 이를 위해 약 10,000여 개의 테이블과 1,000 개가 넘는 대시보드들을 관리하고 있습니다.
이처럼 데이터를 중시하는 문화 속에서 가장 중요한 비즈니스 니즈는 의사 결정권자에게 인사이트를 빠르게 제공하는 것입니다.
특히 글로벌 게임 출시를 준비하는 퍼블리싱 팀은 여러 스튜디오를 동시에 서포트하고 있으며, KPI 기반으로 출시 후의 방향을 빠르게 결정해야 합니다. 신작 사이클 구조 상 새로운 게임을 출시하고 주요 지표를 확인한 뒤, 다음 단계로의 전환을 반복적으로 수행하는 구조이기 때문에 빠른 데이터 접근과 해석이 필수라고 볼 수 있습니다.
그렇다면 KPI 기반 빠른 의사 결정이 필요한 사례는 어떤 것이 있을까요?
- 첫 번째는 광고 캠페인입니다. 마케팅팀은 어느 나라, 어떤 매체에 얼마의 예산을 투입할지를 결정해야 하며, 광고 비용이 크기 때문에 효율적인 판단을 위해 빠른 데이터 확인이 필요합니다.
- 두 번째는 게임 피처 개발입니다. 출시 후 유저를 유지하기 위한 신규 기능 개발이나 기존 기능 개선에 대한 우선순위에 대한 결정이 필요한데, 이는 유저 반응과 데이터 기반으로 빠르게 결정해야 합니다.
2. Before AI
앞선 이유로 어떻게 해야 데이터를 빠르게 전달할 수 있을지에 대해 저희 데이터팀은 항상 고민하고 여러 시도를 해왔습니다.
베이글코드는 태블로 대시보드를 통해 데이터에 대한 인사이트를 제공하고 있습니다. 데이터 시각화에 큰 장점을 가지고 있고 다루기도 어렵지 않습니다. 하지만 새로운 대시보드가 필요할 경우 업스트림 데이터 작업부터 대시보드 제작까지 요청과 작업이 필요하여 대응이 느리다는 단점이 있었습니다.
빠른 데이터 확인에 대한 니즈가 생겨서 저희는 직접 데이터를 푸시해주는 방법도 시도했습니다. 기존 내부적으로 저장하던 데이터의 일부를 Redshift에 싱크 하여 다른 팀에 공유를 했습니다. 해당 데이터에 대해서 직접 쿼리를 해볼 수 있었지만 전체 데이터를 공유하기에는 어려움이 있었고 저장 비용 또한 증가하였습니다.
2022년에는 쿼리 도구인 Superset을 제공해 Spark 테이블에 대한 접근을 열어주기도 했습니다. 직접 SQL 쿼리를 작성해서 원하는 데이터를 사내 구성원들이 직접 뽑고 가공할 수 있다는 장점이 있었지만, SQL이 익숙하지 않은 사용자들에겐 접근성이 떨어지는 숙제가 있었습니다.
따라서 SQL 지식 없이 클릭만으로 데이터에 접근할 수 있는 Metabase를 도입했습니다. (자세한 사항은 SQL 몰라도 데이터 활용하기: Metabase 도입기 를 참고해 주세요) 하지만 낯선 UI로 인해 실제 사용자들의 활용으로 이어지지는 못했습니다.
3. After AI: DAVIS의 시작
최근 기술 트렌드를 정리할 때 AI는 빠질 수 없는 핵심이 되었습니다. 단순히 LLM을 검색이나 코딩에 사용하는 것을 넘어 실제로 업무 효율화를 시도하는 회사도 점점 많아지고 있습니다. 이런 흐름에서 저희 회사도 AI 해커톤을 진행했습니다. 주어진 행사 시간은 단 2일이었고 AI를 활용해 업무에 도움을 줄 수 있는 어떤 것이든지 만들어 오는 것이 목표였습니다.
데이터&AI팀에서도 많은 분들이 참가했는데요. DAVIS팀은 데이터를 ‘쉽게’ 가져오는 서비스를 목표로 했습니다. 원하는 데이터를 요청하면 알아서 가져오는 만능 서비스로, 아이언맨의 만능 비서 J.A.R.V.I.S.(Just A Rather Very Intelligent System)가 생각나 데이터형 만능 비서 D.A.V.I.S.로 이름을 짓게 되었습니다.
초기 프로토타입의 Agent는 Slack기반으로 설계하게 되었습니다. 베이글코드의 모든 직원이 공통적으로 사용하는 협업 툴이기 때문에 접근성이 가장 뛰어나다고 생각했습니다.
그렇게 슬랙봇을 통해 유저의 요청을 슬랙 이벤트 형식으로 요청을 수신한 뒤, API Gateway를 통해 Lambda로 전달합니다. Lambda에서 메시지의 종류를 판단하고, document retrieval agent/tableau agent/query agent로 나눠서 요청을 전달하고 응답을 받아오는 방식입니다.
그중 오늘 중점적으로 다룰 query agent는 다음과 같이 구성되어 있습니다.
Databricks에 저장된 테이블에 관한 정보를 주기적으로 가져와 Kendra에서 읽을 수 있게 적재합니다. AWS Kendra는 지능형 검색 서비스로서, 찾고자 하는 내용과 가장 유사한 문서 혹은 내용을 관련도 순으로 제공하여 RAG 시스템에 많이 사용됩니다.
사용자가 데이터 쿼리 관련 요청을 하게 되면 query agent에서는 우선 Kendra를 통해 해당하는 테이블 정보를 가져오게 되고, 테이블 정보와 요청 정보를 LLM에 제공하여 SQL 쿼리를 생성하게 됩니다. 최종적으로 생성된 SQL은 Databricks API를 통해 실행하고 결과를 가져오게 됩니다.
4. Databricks AI/BI Genie
DAVIS의 프로토타입에서 만든 query agent는 자연어로 데이터를 조회할 수는 있었지만, 유지보수 비용이 많이 들었고 구성요소가 많다 보니 성능도 불안정했습니다.
비슷한 서비스로 Databricks AI/BI Genie가 있는데, Databricks에서 테이블을 Genie Space에 등록하기만 하면 Text2SQL과 데이터 관련 대화를 할 수 있는 서비스입니다.
하지만 당시에는 Databricks workspace에서만 사용이 가능해서 사내 서비스로 사용하기에는 제약이 있었습니다. 그러나 Genie API의 등장으로 판도는 바뀌게 되었습니다.
Genie API가 Private Preview로 출시되자마자 이를 도입해 DAVIS의 쿼리 기능을 대체했습니다. DAVIS에서 사용한 방식은 우선 Start conversation 기능으로 사용자의 요청을 첨부하여 대화를 시작합니다.
이후 Get conversation 기능으로 대화 상태를 확인합니다. 만약 쿼리 생성이 완료되지 않으면 다시 Get conversation 호출을 하고, 성공 시 Get message attachment SQL query result를 호출하여 최종 결과를 받아옵니다. 현재는 Conversation 중심 기능만 제공되기 때문에 이 모든 과정은 Genie Space를 생성한 이후에 사용을 할 수 있습니다.
이렇게 새로운 버전의 DAVIS를 출시하게 되었고 기존에 수많은 관리 포인트 대신에 Genie Space와 API만 관리하면 되는 훨씬 간편한 형태로 바뀌었습니다. 하지만 막상 연결하고 보니 Genie의 성능이 기대만큼 나오지 않았습니다.
같은 질문을 하더라도 WHERE절이 걸려있는 시점이 다르거나, SELECT문에서 선택하는 컬럼들도 다른 등 다른 결과를 보였고, 당연히 반환하는 데이터도 달랐습니다. 서비스를 할 수 없는 수준이었기 때문에 대책이 필요했습니다.
5. Genie 더 똑똑하게 만들기
Genie의 한계를 느끼고 성능을 개선하기 위한 해결책을 찾기 위해 여러 아티클도 참고하고 Databricks Korea의 서포트를 받으면서 결국 원하던 수준으로 끌어올릴 수 있었는데, 그 과정에서 얻은 노하우들에 대해 소개를 해드리겠습니다.
첫 번째 팁은 ‘Stay Focused’입니다. Genie Space에 등록할 수 있는 테이블은 50개 이상으로 최근에 늘어났지만, 예전에는 20개의 제한이 있었던 적이 있고 실제로 성능도 테이블이 늘어날수록 떨어지는 경향이 있기 때문에 꼭 필요한 테이블만 추가하는 것이 좋습니다.
저희 데이터팀의 경우 크게 Base/Intermediate/Mart의 3-layer 구조로 데이터를 처리하고 있습니다. 위의 이미지에서 처럼 각 테이블을 역할별로 구분하고 있어서 테이블의 수가 상당했고, 모든 테이블을 Genie Space에 등록하기에는 어려움이 있었습니다. 그래서 신작팀과 퍼블리싱 팀 등의 니즈를 파악했고, Mart 테이블을 중심으로 등록하면 된다는 결론을 얻게 되었습니다.
여기서 한 가지 의문이 들 수 있습니다. 데이터를 서빙하고 싶은데 등록할 수 있는 테이블이 한정되면 비즈니스 밸류가 떨어지지 않을까요?
핵심은 ‘하나’의 Genie Space에 테이블을 제한하고, 여러 Genie Space를 활용하는 것입니다. 베이글코드에서도 보는 데이터의 종류는 Mart로 한정시킬 수 있었지만, 여러 게임 스튜디오 존재했기에 전체적으로 보면 여전히 테이블 수는 많았습니다. 그래서 게임 스튜디오 별로 Genie Space를 분리하게 되었습니다.
Genie Space를 분리하면 또 다른 문제를 마주하게 되는데, 각 요청이 하나의 Genie Space에만 보낼 수 있다는 것입니다.
DAVIS에서는 이 문제를 Router Agent를 통해 해결했습니다.
유저의 요청을 받았을 때 요청을 처리하기에 앞서 해당 요청이 ‘어떤’ 게임에 대한 데이터를 요청하는지 판단을 먼저 하고, 해당하는 Genie Space Id로 요청을 보내게 하는 역할입니다. 이런 방식을 통해 사용자는 컨택스트가 없어도 편하게 요청을 보낼 수 있게 되었습니다.
두 번째 팁은 ‘Plan to Iterate’입니다. Genie에 테이블 등록 이외에 제공하는 기능으로는 Instructions와 샘플 SQL 등록이 있습니다. 먼저 Instructions는 LLM 프롬프트에 넣을 추가적인 내용입니다.
Instruction이 필요한 예로는 Genie에게 revenue에 대한 질문을 할 경우 Genie에서 어떤 종류의 revenue를 묻는 것인지, 날짜 등의 필터 적용이 필요한지 정확한 정보를 요청합니다. 이렇게 회사마다 주로 통용되는 용어에 대한 설명을 Instructions에 넣어준다면 더욱 정확한 답변을 받을 수 있습니다.
Instruction만으로 처리하기 어려운 경우도 많을 수 있는데, 그럴 경우에는 SQL Query 샘플을 등록할 수 있습니다. 예를 들어 retention을 요청하는 경우에도 classic retention을 보는 경우가 있을 수 있고, rolling retention을 보는 경우가 있을 수 있습니다.
중요한 건 팀에서 주로 확인하는 지표에 알맞은 retention을 돌려주는 것이기 때문에 사용자들이 하는 질문들을 통해 특수용어에 대한 적합한 SQL을 작성했는지 확인하고, 원하는 SQL이 나오면 등록하는 방식을 반복하여 꾸준히 Genie를 학습시켜 나갔습니다.
마지막 팁은 ‘Build on Well-annotated Tables’입니다. Genie는 AI 모델로서 여러 데이터를 통해 학습한다고 알려져 있는데, 테이블 및 컬럼 description도 포함해서 학습한다고 합니다.
그렇다면 모든 테이블과 컬럼에 설명을 추가하면 되지 않을까요?
작은 규모의 데이터를 처리하는 팀이라면 수작업으로 충분히 관리가 되겠지만, 어느 정도 규모 이상의 팀들은 관리하기 어려울 것으로 예상됩니다. Databricks에서 AI Description 기능을 제공하긴 하지만, 일일이 각 테이블 컬럼별로 다 UI에서 눌러줘야 하고 테이블이 삭제될 경우 똑같이 복구하기도 어렵습니다.
이 문제를 해결하기 위해 베이글코드 데이터 팀에서는 dbt를 활용하고 있습니다. 현재 dbt를 활용해서 일부 테이블을 구축하고 있는데, dbt는 sql파일과 yml파일이 모여 하나의 모델을 이룹니다.
sql 파일은 모델 구현과 의존성 관리에 초점을 두고 있으며, yml파일은 모델 문서화에 초점을 두고 있습니다. 테이블과 컬럼 설명도 yml 파일에 관리할 수 있는 것입니다. 가장 중요한 점은, dbt를 통해 테이블을 만들면 해당 description들도 같이 테이블에 적용되어 생성되는 것입니다.
설명 부분까지 코드로 저장하여 git에서 버전 관리까지 가능해지는 것입니다. 더 나아가 정형화된 형식이므로 AI를 활용하여 yml파일을 생성하는 것도 가능합니다.
6. DAVIS 사용 사례 및 후기
Genie와 DAVIS를 고도화하기 위한 여러 과정을 겪고 나온 프로덕트에 대한 사용사례에 대해 소개해드리겠습니다.
퍼블리싱 팀에서 핼러윈과 크리스마스 기간의 KPI에 관해 질문하는 예시입니다.
DAVIS에서 요청을 파싱하고 Genie를 통해 스스로 핼러윈과 크리스마스가 포함된 주간의 정보를 취합해서 제공하는 것을 볼 수 있습니다. DAVIS가 없다면 사용자는 먼저 핼러윈과 크리스마스 기간을 확인해야 했을 것입니다. 그러나 DAVIS는 이를 자동으로 파악해 결과를 제공합니다.
사내 베타테스트를 통해 얻은 사용자 후기들은 다음과 같습니다. 사용자 입장에서 즉각적으로 데이터 접근이 가능해져서 의사결정 속도가 크게 향상되었고, 자연어 기반 쿼리로 SQL 지식 없이도 데이터 활용이 가능하다는 장점이 있었습니다.
분석가의 경우, 단순 반복적인 데이터 추출 요청이 감소해서 핵심 업무에 집중할 수 있습니다.
DAVIS 프로젝트를 통해 많은 가능성을 확인할 수 있었고, 아직 개선할 여지는 있지만, AI 활용 경험을 바탕으로 다양한 업무 영역에 AI 기술을 확장할 수 있는 가능성을 확인할 수 있었던 계기가 되었습니다.
현재는 신작 게임들 위주로 적용을 했지만 주 분야이며 데이터가 더 방대한 소셜 카지노 게임들에도 적용할 예정입니다. 단순 쿼리를 넘어, 시각화 및 분석까지 아우르는 에이전트 개발을 최종 목표로 하고 있습니다.
마지막으로 AI잼부터 DAVIS 프로젝트를 함께 고생하며 진행한 Data Scientist 이준희 님과 Data Engineer 이기연 님, 프로젝트 진행을 도와주신 Technical PM 태연님께 감사드립니다.
DAVIS를 고도화하는데 도움을 주신 Business PM 윤성님, Databricks Korea SA 분들도 감사드립니다.
Members
- Soochang Chung, 정수창 | Data Ops Team Manager
- Junhee Lee, 이준희 | Data Scientist
- Giyeon Lee, 이기연 | Data Engineer
- Taeyeon Kim, 김태연 | Technical Product Manager