AI 데이터 분석가 ‘물어보새’ 등장 – 2부. Data Discovery

Aug.09.2024 BADA팀(Baemin Advanced Data Analytics)

AI Data PM

1부. RAG와 Text-To-SQL 활용에서는 구성원의 데이터 리터러시 향상을 돕는 AI 데이터 분석가 물어보새의 개발 계기, 목적, 핵심 기능, 그리고 RAG, LLMOps, Text-to-SQL과 같은 기술의 구현 방법에 대해 자세히 다루었습니다. 2부에서는 Text-to-SQL을 넘어, LLM을 활용해 사내의 다양한 데이터를 탐색하고 이해하여 유의미한 인사이트를 도출하는 물어보새의 Data Discovery 기능에 대해 설명하겠습니다.

1. 우리는 ‘왜’ Data Discovery 영역으로 확장했을까?

1.1 사용자 베타 테스트

사용자의 피드백을 기반으로 물어보새 기능의 유용성을 검증하고 개선할 부분을 확인하기 위해 두 차례의 베타 테스트를 진행했습니다. 이를 통해 다양한 사용자 질문에서 중요한 개발 인사이트를 얻을 수 있었습니다.

첫 번째 베타 테스트에서는 데이터 분석가와 엔지니어를 대상으로 Text-to-SQL 초기 버전을 테스트했습니다. 이를 통해 테이블 선별 정확도와 비즈니스 로직 반영 등 쿼리 생성 기능에 대한 피드백을 받았으며, Trino 쿼리 함수와 응답 시간 개선이 필요함을 확인했습니다. 또한, 쿼리 생성뿐만 아니라 쿼리 해설에 대한 요구도 파악할 수 있었습니다.

두 번째 베타 테스트는 PM을 대상으로 진행했습니다. 이 테스트를 통해 물어보새의 실무적 활용성을 검증하고, 데이터 관련 직군이 아닌 사용자의 사용 가능성을 확인했습니다. 수집된 질문에는 쿼리문 생성 외에도 쿼리문 해설, 테이블 해설, 특정 정보가 담긴 테이블과 칼럼 탐색, 로그 데이터 활용 등 다양한 Data Discovery 질문이 있었습니다. 이를 통해 더 많은 사용자가 유용하게 활용할 기능들을 파악할 수 있었습니다.

그림1. 물어보새 PM 대상 베타 테스트 질문 유형 분류


1.2 Data Discovery 기능 확장

물어보새는 사용자 베타 테스트에서 얻은 인사이트를 바탕으로, 사용자의 다양한 질문을 이해하고 답변할 수 있는 Data Discovery 기능을 추가했습니다. 이 기능은 사내 모든 테이블과 칼럼에 대한 상세한 정보들이 저장되어 있는 데이터 카탈로그(Data Catalog)와 앱과 웹에서 발생하는 사용자의 행동과 이벤트 정보를 로그 단위로 통합 관리하는 로그 체커(Log Checker) 등 사내 Data Discovery Platform에 있는 데이터를 벡터 스토어에 저장하고 활용합니다. 이를 통해 물어보새는 사용자 질문의 의도를 파악하고 관련 정보를 찾아 답변할 수 있습니다. 이후 더 상세한 정보가 필요할 경우, 사용자를 데이터 카탈로그나 로그 체커에 연결해 데이터 활용의 시너지를 극대화할 수 있도록 합니다.

구체적으로 Data Discovery 기능은 Text-to-SQL 기반의 쿼리문 생성 답변뿐만 아니라 쿼리문과 테이블 해설, 로그 데이터 활용 안내 답변까지 구성원의 데이터 리터러시를 향상시키는 데 도움을 주는 다양한 정보 획득 기능으로 구성되어 있습니다. 아래는 현재 제공 중인 기능과 각 기능에 대한 상세 설명입니다.

순번 단계 기능명 설명
1 질문 이해 질문 유형 분류 사용자의 질문을 정확히 이해할 수 있도록 질문 의도와 유형을 분류
2 정보 획득 쿼리문 생성 답변 Text-to-SQL 기술을 활용하여 비즈니스 문제 해결에 필요한 쿼리문 제공
3 쿼리문 해설 답변 쿼리문을 입력하면 주요 조건과 정보를 사용자가 이해할 수 있는 자연어로 번역하여 제공
4 테이블 해설 답변 테이블의 목적, 주요 칼럼, 활용 예시 등 테이블 전반적인 설명 제공
5 쿼리 문법 검증 답변 작성된 쿼리 문법이 올바르게 작성 됐는지 피드백을 제공
6 데이터 기술 지원 답변 쿼리 함수 및 데이터베이스 관련 질문에 대한 정보를 제공
7 테이블 및 칼럼 활용 안내 답변 특정 정보를 담고 있는 테이블 및 칼럼에 대한 정보를 제공
8 로그 데이터 활용 안내 답변 로그 체커 데이터를 기반으로 질문과 관련된 로그 정보를 제공
그림2. 물어보새 Data Discovery 기능 상세

1.3 Data Discovery 기능 구조

Data Discovery 기능은 질문 이해와 정보 획득을 기반으로 한 계층 구조로 구현했습니다. 이를 통해 사용자의 다양한 질문을 이해함으로써 LLM의 허위 생성(=Hallucination) 문제를 최소화하며, 동시에 Data Discovery 기능의 확장성을 확보할 수 있었습니다.

그림3. 물어보새 Data Discovery 기능 구조

지금부터 Data Discovery 구조에서 첫 번째 단계인 ‘질문 이해’와 두 번째 단계인 ‘정보 획득’을 어떻게 구현했는지 상세하게 알아보도록 하겠습니다.

2. 질문 이해 단계는 ‘어떻게’ 구현했을까?

쿼리문 생성 질문 외에도 다양한 질문 발생하여 하나의 체인으로 모든 질문에 대응하기 어려웠습니다. 무엇보다 사용자의 데이터 이해도와 활용 역량이 다르기 때문에 질문 수준도 다양했습니다. 예를 들어, "어제자 주문 마스터 테이블에서 테스트 매장을 제외하고 알뜰 배달 주문 비중을 소수점 둘째 자리에서 반올림해 구해줘"라고 묻는 사용자가 있는 반면, 어떤 사용자는 질문을 어떻게 시작해야 할지 모를 수도 있었습니다.

따라서 사용자의 데이터 활용 역량에 상관없이 질문의 완성도를 높이고, 적절한 체인으로 연결해 답변 품질을 높일 방안이 필요했습니다. 이를 위해 사용자의 질문 의도를 정확히 파악하고 적절한 답을 전달할 수 있는 Router Supervisor 체인을 구현했습니다. Router Supervisor 체인은 LangGraph의 Agent Supervisor에서 아이디어를 응용했습니다. 구체적인 방법에 대해 알아보겠습니다.

2.1 사용자 질문 개선 방법

(1) 질문 해석 능력 개선

전달받은 질문이 데이터와 얼마나 연관되어 있으며, 문제 해결을 위한 구체적인 단서를 얼마나 포함하고 있는지 평가하는 단계가 필요했습니다. 해당 단계를 추가한 이유는 질문 유형이 LLM을 통해 분류되더라도 오류가 있을 수 있으므로, 질문의 품질을 한 번 더 평가하는 단계가 필요했기 때문입니다. 질문 평가 기준을 수립하고, 평가 항목별 점수를 합산하여 종합 점수를 산출했습니다. 프롬프트 엔지니어링 기법을 활용해 기준을 충분히 달성했는지에 대한 일관성 있는 점수를 부여했습니다. 질문을 점수화하는 과정에서 Text-to-SQL 부분과 유사하게 벡터 스토어를 사용해 사내 용어와 질문을 결합하여 추상적이거나 전문적인 질문을 쉽게 이해할 수 있는 질문으로 변경했습니다. 일정 기준 점수와 분류 모델을 통과한 질문은 다음 단계인 정보 획득 단계로 넘어갑니다. 통과하지 못한 질문은 적합한 질문 예시를 참고하여 조금 더 구체적으로 질문해 달라는 안내 문구를 자동으로 제공합니다.

(2) 질문 생성 능력 개선

질문 해석 능력 개선 방법 외에도 사용자의 질문 생성 능력을 향상시키기 위한 방법을 고민했습니다. 문제 상황에 맞는 적합한 질문을 할 수 있도록 사용자 가이드를 제공했으나, 사용자들이 가이드북을 제대로 읽지 않고 질문하는 경우가 지속적으로 발생했습니다. 이로 인해 원하는 답을 얻지 못하는 경우가 발생했습니다. 이를 해결하기 위해 물어보새 슬랙 앱 등록 시, 튜토리얼과 같은 활용 안내 화면을 개발하여 직관적인 사용자 가이드를 제공했습니다. 이를 통해 현재 제공 중인 기능과 기능별 대표 질문 및 예시 답변을 통해 어떤 질문을 할 수 있으며 어떤 답변을 받을 수 있는지 인지시킬 수 있었습니다.

다음은 대화 유형별 대응 방법입니다.

2.2 대화 유형별 대응 방법

(1) Single-Turn

Single-Turn 대화 유형은 하나의 질문과 응답으로 구성됩니다. 구축이 간단하고 응답 속도가 빠르지만, 문맥이 유지되지 않는다는 단점이 있습니다. 질문 이해 단계에서는 응답 속도가 중요하므로 주로 Single-Turn을 사용했습니다. 베타 테스트 결과에 따르면 데이터와 관련 없는 질문도 10% 이상 발생한다는 것을 알 수 있습니다. 이러한 질문들을 Text-to-SQL 질문으로 연결하면 엉뚱한 답변이 나올 수 있습니다. 따라서 사용자의 질문을 우선적으로 데이터 또는 비즈니스 관련 여부에 따라 자동으로 분류합니다. 날씨 문의와 안부 인사처럼 관련 없는 질문은 일반 대화로 분류하여 별도의 처리 없이 적절한 답변을 제공합니다. 전통적으로 문장 분류는 머신러닝 기반 분류 모델을 사용해왔으나, 최근에는 LLM 기반의 프롬프트 엔지니어링으로 자동 분류가 가능해졌습니다. 이를 통해 구축이 더 쉬워지고 분류 성능도 우수해졌습니다.

데이터 또는 비즈니스 관련 질문으로 분류되면 어떤 정보 획득 유형이 적합한지 한 번 더 분류합니다. 예를 들어, 질문이 해설 답변을 요구하는지 검증 답변을 요구하는지에 따라 상세하게 분류합니다. 두 가지 질문을 하는 경우에는 기능의 우선순위와 문제 해결에 가장 적합한 답변을 우선적으로 제공합니다. 이 두 단계의 분류 과정을 통해 사용자의 질문에 최대한 적합한 답변을 제공합니다.

(2) Guided Single-Turn

Guided Single-Turn 대화 유형은 하나의 질문과 응답으로 구성되지만, 특정 방향으로 대화를 유도합니다. 질문이 구체적이지 않을 때, 물어보새는 질문 작성 가이드를 제공하여 사용자가 더 구체적으로 질문하도록 유도합니다. 이는 Multi-Turn 대화는 아니지만, 사용자가 Multi-Turn 대화와 비슷한 경험을 할 수 있습니다.

(3) Multi-Turn

Multi-Turn 대화 유형은 질문과 응답이 연속적으로 이어지며, 문맥이 유지됩니다. 이를 통해 긴 대화를 이어가며 지속적인 상호작용이 가능합니다. 하지만 다양한 기능과 연결될 때 답변의 허위 생성이 발생할 수 있어 적용 전에 충분한 테스트가 필요합니다. 현재 물어보새는 안정적인 서비스 제공이 가능한 Multi-Turn 기능을 개발 중입니다.

지금까지 Data Discovery 구조의 첫 번째 단계인 질문 이해에 대해 알아보았습니다. 앞서 설명한 전략을 통해 사용자 질문의 완성도를 높이고, 다양한 질문에 효과적으로 답할 수 있었습니다. 이를 통해 사용자 만족도와 신뢰도를 높일 수 있습니다.

다음으로, 질문 이해 단계에서 분류된 사용자의 질문에 대해 구체적인 답변을 제공하는 정보 획득 단계에 대해 설명하겠습니다. 정보 획득 단계는 ‘쿼리문과 테이블 해설 답변’, ‘쿼리문 문법 검증과 데이터 기술 지원 답변’, ‘테이블 및 칼럼 활용 안내 답변’, 그리고 ‘로그 데이터 활용 안내 답변’의 네 가지 복합 기능과 일곱 가지 세부 기능으로 구성되어 있습니다.

3. 정보 획득 단계는 ‘어떻게’ 구현했을까?

3.1 쿼리문과 테이블 해설 답변 기능

(1) 배경

서비스를 개발하고 개선하는 과정에서 데이터 분석과 이를 위한 쿼리문은 중요한 역할을 합니다. 이에 따라 데이터에 익숙한 구성원부터 그렇지 않은 구성원까지 많은 구성원이 다양한 영역에서 쿼리문을 활용하고 있습니다. 하지만 배달의민족 서비스가 다양해지고 고도화됨에 따라 한눈에 이해하기 어려운 복잡한 쿼리문도 생성되었습니다.이로 인해 쿼리문에 익숙하지 않거나, 쿼리문에 사용된 테이블을 잘 모르는 사람들은 쿼리문을 이해하는 데 많은 시간이 걸리곤 했습니다. 또한, 서비스 담당자가 바뀌는 경우 인수인계를 받은 사람이 기존에 활용되고 있던 쿼리문을 깊이 이해하기 어려운 상황이 자주 발생했습니다.

(2) 제공 정보

쿼리문과 테이블 해설 답변 기능은 위와 같은 어려움을 해결하기 위해 도입되었습니다. 사용자가 쿼리문을 입력하면 해당 쿼리문에 사용된 주요 비즈니스 조건, 주요 칼럼, 최종적으로 추출되는 정보, 그리고 해당 쿼리문의 활용 방법에 대한 정보를 제공합니다. 사용자가 테이블명을 입력하는 경우에는 테이블의 주요 칼럼, 칼럼 설명, 그리고 테이블의 활용 예시에 대한 정보를 제공합니다. 답변 마지막에는 사용자의 질문에 포함된 테이블의 데이터 카탈로그 정보 링크를 제공하여 더 상세한 정보를 탐색할 수 있도록 합니다.

그림4. 물어보새 테이블 해설 답변 예시

(3) 기능 구현 방법

쿼리문 해설 답변 기능 구현은 사용자의 질문에 포함된 테이블명을 추출하는 것으로부터 시작됩니다. SQLGlot이라는 파이썬 라이브러리와 정규 표현식을 활용하여 질문을 분석하고 테이블명을 추출한 후, DDL(Data Definition Language) 벡터 스토어에서 해당 테이블에 대한 정보를 가지고 옵니다. 사용자가 입력한 내용에 DDL 벡터 스토어에는 없는 사용자가 임의로 생성한 테이블 또는 개인정보 보호 등의 이유로 정보를 제공할 수 없는 테이블이 포함된 경우, 해설 정보가 부정확할 수 있다는 안내 문구를 답변에 추가합니다.

질문에 포함된 테이블의 DDL을 추출한 이후에는, 일부 칼럼에 대한 정보만 추출하는 DDL 축소 로직을 적용합니다. DDL을 축소하는 이유는 두 가지입니다. 첫 번째, LLM에 입력되는 프롬프트의 길이가 길어질수록 허위 생성이 발생할 가능성이 높아진다는 것입니다. 두 번째, 칼럼 수가 매우 많은 일부 DDL의 경우 전체 내용을 프롬프트에 입력하면 LLM의 토큰 제한에 걸려 에러가 발생하기 때문입니다. 따라서 쿼리문에서 사용된 칼럼명과 함께 테이블의 키 정보, 파티션 정보 등 주요 칼럼만 추출하는 로직을 적용하여 축소된 DDL을 프롬프트에 입력합니다. 이 프롬프트는 기존의 chain-of-thought (CoT) 방법론의 한계를 개선하기 위해 개발된 Plan and Solve Prompting 방법을 적용해 쿼리문과 테이블에 대한 해석 방법을 지시했습니다.

3.2 쿼리문 문법 검증과 데이터 기술 지원 답변

(1) 제공 정보

쿼리문 문법 검증 기능은 사용자가 작성한 쿼리문 문법의 정확성을 확인하고, 필요한 경우 칼럼명, 조건 값, 실행 최적화를 위한 개선 방안을 제안합니다. 길고 복잡한 쿼리에서 오류가 발생했을 때 또는 사용자가 쿼리 작성에 익숙하지 않아 어떤 부분에서 잘못되었는지 모를 때 유용한 기능입니다.

데이터 기술 지원 기능은 ‘어제 일자 구하는 함수’와 같은 쿼리 함수뿐만 아니라 데이터 과학이나 데이터베이스와 관련된 데이터 전문 지식을 제공합니다.

(2) 기능 구현 방법

쿼리문 문법 검증 기능은 두 단계의 세부 체인으로 구성되어 있습니다. 첫 번째 단계는 칼럼명 보정 체인으로, 이 단계에서는 쿼리문에 사용된 칼럼명과 테이블명을 추출한 후, 추출된 테이블의 DDL을 기반으로 칼럼명에 오류가 없는지를 확인하고 보정합니다. 이후 보정된 쿼리문을 기반으로 DDL을 축소합니다.

두 번째 단계는 쿼리문 문법 검증 및 최적화 체인입니다. 이전 단계에서 넘겨받은 보정된 쿼리문과 축소된 DDL을 기반으로 문법과 칼럼 값에 대한 오류를 확인하고 최적화 방안을 제안합니다. 두 단계의 세부 체인으로 나눔으로써 각 단계에서 LLM은 더욱 세분화된 역할을 부여받고, 단계별로 필요한 정보량을 줄임으로써 허위 생성 가능성을 낮추고 성능을 더욱 향상시킬 수 있었습니다.

질문에 쿼리문이 없는 경우에는 데이터 기술 지원 기능 체인으로 정보를 전달하여 답변할 수 있도록 합니다.

(3) 한계점

쿼리문 문법 검증 기능은 이름에서 알 수 있듯이 쿼리에서 사용된 비즈니스 로직에 대한 수정 사항을 제안하지는 않습니다. 이는 쿼리문 조건별 비즈니스 의미에 대한 메타 정보가 현재는 few-shot SQL 예제 데이터로 구축되어 있기 때문입니다. 따라서 상세한 수준의 비즈니스 로직에 대한 정보를 벡터 스토어에서 검색하여 제공하기 어려워 만족할 만한 수준의 답변을 내기가 어려웠습니다.

또한, 대부분의 질문에서 질문자가 어떤 상세 로직을 수정하고 싶은지 구체적으로 명시하지 않아 LLM이 정확한 답변을 하기 어렵습니다. 이와 같은 문제를 해결하고 해당 기능을 고도화하기 위해 특정 비즈니스 로직은 어떤 테이블에서 어떤 칼럼과 조건값을 사용해야 하는지에 대한 메타 정보를 벡터 스토어에 저장하고, 질문을 구체적으로 할 수 있도록 사용자 가이드를 추가할 계획입니다.

3.3 테이블 및 칼럼 활용 안내 답변

(1) 제공 정보

테이블 및 칼럼 활용 안내 답변 기능은 특정 정보를 담고 있는 테이블명과 칼럼 정보를 제공하여 사용자가 필요한 데이터를 보다 쉽게 찾고 활용할 수 있도록 돕습니다. 예를 들어, 사용자가 "배민클럽 멤버십 구독 정보에 대해서 알 수 있는 테이블 알려줘"와 같은 질문을 하면 해당 정보를 담고 있는 테이블명과 주요 칼럼, 활용 예시를 설명해 줍니다. 그리고 보다 상세한 정보를 확인할 수 있도록 데이터 카탈로그 링크를 제공합니다. 이처럼 검색 결과로서 요약된 형태의 종합 테이블 정보를 전달해 준다는 점에서 기존의 검색 기능과 차별화됩니다.

(2) 기능 구현 방법

테이블 및 칼럼 활용 안내 답변 기능을 구현하기 위해 LLM을 이용하여 테이블 메타 데이터 고도화를 진행했습니다. 1부에서 Text-to-SQL 기능 구현을 위한 ‘데이터 보강’에서 소개한 것처럼, 고도화된 메타 데이터에는 테이블의 목적과 특성, 주요 키워드 등에 대한 정보가 포함되어 있어 사용자의 질문과 관련된 테이블을 검색하는데 유용하게 활용할 수 있었습니다. 다만, 수많은 테이블에 대한 메타 데이터를 LLM을 통해 생성하는 과정에서 허위 생성 문제가 발생하여 일부 테이블에 대한 정보가 잘 못 기입되는 경우도 있었습니다. 이 부분은 향후 메타 데이터 생성 프롬프트 고도화와 보완 로직을 통해 개선할 계획입니다.

다음으로, 사용자의 질문을 이해하기 위해 비즈니스 용어 사전과 토픽 모델링을 활용한 질문 구체화 체인을 구현했습니다. 비즈니스 용어 사전을 통해 서비스 구조와 용어를 기반으로 LLM이 사용자의 질문을 확장할 수 있도록 하였습니다. 또한, DDL을 구성하는 단어들을 기반으로 토픽 모델링을 수행하여 선정된 토픽과 키워드를 질문 구체화 프롬프트에 입력했습니다. 이를 통해 LLM이 사용자의 질문과 가장 밀접한 관련이 있는 키워드를 선별하고, 더욱 풍부한 키워드를 기반으로 테이블을 검색할 수 있도록 했습니다.

마지막으로, 구체화된 사용자의 질문과 가장 밀접한 테이블을 찾기 위해 테이블 메타 데이터와 DDL을 이용한 Retriever와 LLM의 혼합 검색 체인을 구현했습니다. 이 혼합 체인에서는 세 단계의 검색을 거쳐 수많은 테이블 중 한두 개의 테이블을 선별하고, 선별된 테이블에 대한 설명 정보를 사용자에게 제공합니다.

다음으로 테이블과 같이 정형화되어 있지 않은 형태인 로그 데이터를 탐색하는 기능인 ‘로그 데이터 활용 안내 답변’ 기능에 대해 설명하겠습니다.

3.4 로그 데이터 활용 안내 답변

(1) 제공 정보

로그 데이터 활용 안내 답변 기능은 사용자의 질문을 분석하여 로그 체커에 있는 방대한 로그 데이터를 효과적으로 탐색하고 활용할 수 있도록 돕습니다. 예를 들어, 사용자가 "가게 상세 페이지 관련 로그에 대해 알려줘"와 같은 질문을 하면, 물어보새는 가게 상세 페이지를 의미하는 ‘ShopDet’과 같은 특정 로그 단어를 추출하여 관련 로그를 찾고, 원하는 데이터를 조회할 수 있도록 로그 구조와 의미 등 안내 답변을 제공합니다.

이 기능은 로그 데이터에 익숙하지 않은 구성원이나 익숙하지 않은 도메인의 로그를 찾아야 하는 구성원, 또는 새 로그를 개발하는 구성원이 필요한 로그 정보를 빠르게 찾고 이해할 수 있도록 도와줍니다.

(2) 사전 데이터 가공

로그 데이터 활용 안내 답변 기능은 앞서 설명한 다른 기능과는 달리 테이블의 DDL 정보를 사용하지 않고, 로그 체커의 데이터를 사용합니다. 아래는 로그 체커 데이터의 예시입니다. Screen Name, Group, Event, Type은 각각 ‘로그 발생 지면’, ‘로그 발생 지면 내 하위 영역’, ‘로그를 통해 발생하는 이벤트 정보’, ‘로그 유형’을 의미합니다.

로그 이름 로그 설명 Screen Name Group Event Type 새롭게 정의된 로그 설명
가게 상세 > 쿠폰 받기 배포 일자 기록 ShopDet Cpn CpnDown Click 가게 상세 쿠폰 다운로드 클릭
배민스토어 > 가게카드 노출 배포 앱 버전 기록 Store SellerCard SellerCard Imp 배민스토어 셀러 카드 노출
그림5. 로그 체커 데이터 예시

테이블 DDL 정보에는 칼럼명과 칼럼에 대한 설명이 함께 포함되어 있습니다. 반면, 로그 체커에는 ‘로그 이름’과 ‘로그 설명’이 있지만 로그를 설명하기 위해 만든 플랫폼이 아니다 보니 DDL에 있는 칼럼 설명처럼 자세한 설명이 작성되어 있지 않았습니다. 로그 데이터 활용 안내 답변 기능을 구현하기 위해서는 새로운 접근 방법이 필요했고 ‘로그 이름’을 그대로 사용하는 것이 아닌 로그 체커의 고유 조합 값인 Screen Name, Group, Event, Type을 바탕으로 ‘로그 설명’을 새롭게 만들기로 했습니다. 하지만, ‘로그 설명’을 만들기 전 몇 가지 문제를 해결해야 했습니다.

첫 번째는 로그 체커 영문 단어의 한글 번역 문제입니다. 사용자의 질문을 이해하기 위해서는 각 로그별 한글 설명이 필요합니다. 로그 체커 내 한글 정보인 ‘로그 이름’과 ‘로그 설명’을 그대로 활용하면 좋겠지만, ‘로그 이름’은 하나의 로그를 설명하기엔 정보가 부족하고, ‘로그 설명’은 운영을 위한 설명이 기록되어 있어 사용할 수 없었습니다. 이 문제를 해결하기 위해 로그 이름을 세부 단어로 분리한 후 각 단어를 번역한 ‘로그 용어 사전’을 만들었습니다.

두 번째는 우아한형제들에서만 사용하는 단어 정의 문제입니다. 일반적으로 ‘가게’라는 단어는 ‘Shop’, ‘Store’ 등 다양하게 번역될 수 있습니다. 그러나 사내에서 사용하는 단어로 ‘가게’는 ‘Shop’이며, ‘Store’는 ‘배민스토어’를 의미합니다. 이처럼 번역만으로 해결할 수 없는 단어를 보정해 줄 ‘로그 용어 보정 사전’을 추가했습니다.

마지막으로 축약 단어 문제입니다. ‘ShopDet’와 같이 축약된 단어가 ‘Shop Detail’과 같다고 인식할 수 있는 방법이 필요했습니다. 앞서 만든 ‘로그 용어 사전’의 영단어와 고유 조합 값의 항목들을 유사도 기반으로 연결했습니다. ‘Shop Detail’은 가장 유사도가 높은 ‘ShopDet’와 연결되어 가게 상세에 대한 단어임을 인지할 수 있습니다.

위의 세 가지 단계를 거쳐 ‘로그 설명’을 새롭게 만들었습니다. 생성된 ‘로그 설명’은 사용자의 질문에 대한 로그 매핑 데이터로 사용됩니다. 그림5와 같이 새롭게 정의된 로그 설명으로 등록되며, 신규로 등록된 로그도 동일한 과정을 거쳐 매주 업데이트합니다.

(3) 기능 구현 방법

로그 데이터 활용 안내 답변 기능은 두 개의 주요 체인으로 구성되어 있습니다. 이 기능의 핵심은 기존의 복잡한 검색 알고리즘을 LLM으로 대체하여 더 유연하고 손쉽게 구현할 수 있다는 점입니다.

첫 번째는 로그 단어 체인입니다. 로그 단어 체인은 사용자 질문과 로그 시스템 특화 용어를 연결해 주는 역할을 합니다. 우선, 사용자의 질문과 미리 구축된 로그 용어 사전의 단어 간 유사도를 계산하여 유사도가 높은 로그 단어들을 선별합니다. 이후, LLM을 활용하여 선별된 단어들 중 사용자 질문과 가장 연관성이 높은 로그 단어를 최종 선정합니다. 이 과정에서 LLM은 복잡한 로직 없이도 문맥을 이해한 결과를 제공합니다.

두 번째는 로그 검색 체인입니다. 로그 검색 체인은 벡터 스토어에 저장되어 있는 로그 정보 중 사용자가 원하는 로그만 선별해서 가져오는 역할을 합니다. 로그 단어 체인에서 선별된 단어를 기반으로 벡터 스토어에서 연관된 로그들을 검색합니다. 검색된 로그 중 LLM을 활용하여 사용자 질문과 가장 연관성이 높은 로그를 선정합니다. 허위 생성을 줄이기 위해 LLM에게 로그를 구분할 수 있는 고유 키값만 출력하도록 지시했습니다. 그리고 LLM이 출력한 고유 키값들을 바탕으로 벡터 스토어에서 최종 로그를 검색하여 제공합니다. 이 방법을 통해 선별된 최종 로그 정보를 누락 없이 정확하게 제공할 수 있습니다.

그림6. 물어보새 로그 데이터 활용 안내 답변 예시

이렇게 LLM을 활용한 검색 방식은 기존의 알고리즘 기반 검색보다 더 유연하고 구현이 용이합니다. 복잡한 검색 로직을 개발하는 대신, LLM의 자연어 이해 능력을 활용하여 사용자의 의도를 파악하고 관련성 높은 로그를 찾을 수 있도록 구현할 수 있습니다. 구현된 로그 데이터 활용 안내 답변 기능은 그림6과 같이 정형화된 출력 형태에 맞춰 사용자에게 답변을 제공합니다.

4. 물어보새의 향후 계획

지금까지 Text-to-SQL 기반 쿼리문 생성 기능과 다양한 데이터 탐색 기능에 대해 살펴보았습니다. 물어보새 기능의 핵심 특징은 사용자의 질문을 이해하고, 질문 유형에 따라 필요한 데이터와 프롬프트가 실시간으로 개인화되어 동적으로 변경된다는 점입니다. 앞으로도 이러한 부분을 더욱 강화하기 위해 새로운 기능과 기술을 지속적으로 도입할 계획입니다.

구체적으로 앞으로 개발 예정인 지식 생성 단계가 있습니다. 지식 생성은 데이터를 탐색하고 시각화하며, 분석된 정보를 바탕으로 실행 가능한 사업 전략과 기획 방안을 제안하는 단계를 의미합니다. 이를 구현하기 위해서는 정보 획득 단계의 성능 개선과 기능별 연계가 필수적입니다. 따라서 Text-to-SQL 성능 개선과 기존의 단일 기능이 아닌 여러 기능을 결합한 AI 에이전트를 도입하는 방안을 검토하고 있습니다. AI 에이전트는 사람의 개입 없이 특정 작업을 수행하는 자율 지능형 시스템을 의미합니다.

또한, 다양한 Data Discovery 기능을 개발할 예정입니다. 사내에서 제공 중인 BI Portal 서비스를 보다 잘 활용할 수 있도록, 질문과 연결하여 문제 해결에 필요한 대시보드도 제안할 계획입니다.

이러한 기능들이 개발되면 구성원의 업무 효율을 높일 수 있는 새로운 기반이 마련될 것입니다. 앞으로 물어보새의 활용 단계는 1단계부터 5단계로 나눌 수 있을 것으로 예상됩니다.

  • 1단계: 물어보새가 구성원의 업무를 지원합니다. 데이터를 이해하고 추출하며, 참고 자료를 제공합니다. 이 단계에서는 구성원의 역량이 중요합니다.

  • 2단계: 물어보새가 구성원의 일부 업무를 대신합니다. 데이터 생성 및 검증을 수행하며, 생성된 데이터를 신뢰할 수 있습니다.

  • 3단계: 구성원과 물어보새가 협업합니다. 데이터 탐색 및 분석을 함께 수행하고, 물어보새는 의사결정에 참고할 정보를 생성합니다.

  • 4단계: 물어보새가 데이터 기반의 의사결정을 제안합니다. 의사결정에 직접 활용될 수 있는 지식을 제공합니다.

  • 5단계: 물어보새가 최적의 의사결정을 수행합니다. 데이터 기반 의사결정을 자동화하여 최적의 결과를 도출합니다.

그림7. 물어보새 활용 단계


5. 물어보새 2부를 마치며

AI 데이터 분석가 물어보새는 앞으로 더 똑똑하고 빠른 의사결정을 내릴 수 있도록 지속적으로 진화할 예정입니다. 또한, 정규 조직을 신설하여 데이터 분석 분야뿐만 아니라 조직 내 다양한 업무를 이해하고, 다양한 질문에 대답함으로써 지식을 공유하고 확장할 수 있는 새로운 분야도 개척해갈 계획입니다. 이를 통해 사내 업무 생산성을 비약적으로 향상시킬 수 있는 우아한형제들만의 서비스로 발전할 것으로 기대하고 있습니다. 앞으로 우아한형제들의 물어보새 서비스가 발전하는 모습을 기대해 주시며, 지속적인 관심 부탁드립니다.

지금까지 우아한형제들 AI 데이터 분석가 ‘물어보새’였습니다.