당근페이의 Amazon Bedrock 기반 Text-to-SQL로 완성하는 데이터 혁신, Part 2: 데이터 수집과 관리, 향후 계획

지난 1부에서는 전반적인 아키텍처와 동작 방식에 대해서 소개했습니다. 이번 2부에서는 브로쿼리 답변 정확도에 중요한 영향을 미치는 메타데이터의 수집 및 관리하는 방법과 향후 계획에 대해 다룹니다.

1부 다시보기 : Part 1: 브로쿼리 개요와 아키텍처

데이터 수집

<데이터 수집 구조>

1부에서 언급한 바와 같이, 충분하고 적절한 컨텍스트를 전달하기 위해서는 양질의 데이터가 필수적입니다. 브로쿼리가 활용 가능한 데이터를 크게 두 가지로 분류했습니다.

사용자가 실제로 분석하려는 분석 데이터
분석 데이터를 둘러싼 설명 정보, 메타데이터

메타데이터 분류

브로쿼리의 성능과 답변의 질을 좌우하는 메타데이터는 아래와 같이 세 가지 유형으로 구분되어 체계적으로 관리됩니다.

비즈니스 메타데이터: 주로 비즈니스 용어나 맥락 정보로 표현되고, 이는 데이터를 이해하고 활용하는데 필요한 설명 정보입니다. 당근페이는 전사적으로 합의된 비즈니스 용어 정의, 특정 지표, 정책에 대한 맥락 정보, 데이터 자산의 담당자 또는 소유자 정보를 비즈니스 메타데이터로 정의했습니다. 또한 개인 식별 정보(PII) 혹은 비즈니스 민감 정보, 접근 정책 제어 정보 등 매우 중요한 보안 관련 정보도 여기에 포함됩니다.
기술 메타데이터: 데이터의 물리적인 구조와 관련된 정보입니다. 데이터베이스의 ER 다이어그램(ERD), 테이블/컬럼 상세 정보, 샘플 쿼리 등이 여기에 해당합니다. 이 정보들은 데이터베이스 카탈로그, dbt와 같은 데이터 모델링 도구 또는 개발자들이 작성한 문서 등 다양한 소스로부터 수집됩니다.
운영 메타데이터: 데이터가 언제, 어떻게 생성되고 변경되었는지, 그 처리 과정과 관련된 정보입니다. 데이터의 흐름을 보여주는 데이터 계보(Data Lineage), 데이터 처리 배치 작업 로그(ETL Job Log), 데이터 접근 기록(Access Log) 등이 포함됩니다. 이 정보들은 데이터 파이프라인 모니터링 시스템이나 로깅 시스템에서 자동으로 수집되며, 데이터의 최신성이나 신뢰도를 판단하고, 문제가 발생했을 때 원인을 추적하는 데 중요한 단서를 제공합니다.

이와 더불어 분석의 대상이 되는 원본 데이터(Raw Data)도 중요합니다. 다양한 내부 데이터 소스로부터 실시간 스트리밍 또는 주기적인 배치 데이터 형태로 수집되며, 정제 과정을 거쳐 메인 데이터 스토어에 저장됩니다. 이처럼 다양한 곳에서 수집된 원본 데이터와 세 가지 핵심 메타데이터는 목적에 맞게 저장되고 관리됩니다. 브로쿼리는 이 저장소들을 일종의 지식 기반(Knowledge Base)처럼 활용하며, Amazon OpenSearch 기반의 RAG 시스템이 이들 정보르 검색하여 사용자 질문에 적합한 컨텍스트를 Agent에게 제공합니다.

데이터 관리

<스키마 정보 관리 구성>

당근페이는 메타데이터의 일관성과 최신성을 유지하기 위해 내부 데이터 도구를 구축하여 적극 활용하고 있습니다. 주요 관리 흐름은 다음과 같습니다.

데이터 연동 자동화 도구를 통해 다양한 소스의 데이터베이스 테이블을 Data Warehouse(DW)로 쉽게 연동할 수 있도록 지원합니다. 현업 부서나 개발팀 담당자는 웹 기반 UI를 통해 필요한 테이블을 DW로 직접 연동할 수 있습니다.
연동 과정에서는 dbt를 기반으로소스 테이블의 메타데이터가 자동으로 추출되어 YAML 프로퍼티 파일 형태로 저장됩니다.
이 메타데이터는 이후 Ingestion Pipeline을 통해 중앙 메타데이터 저장소로 수집되며,
데이터 거버넌스 포탈을 통해 사용자들이 포털 페이지에서 테이블 및 컬럼 정보를 직접 조회하고 관리할 수 있도록 제공됩니다.

<프로퍼티 파일: staging.yaml>

dbt의 YAML 파일에서는 각 테이블과 컬럼에 대해 사람이 이해할 수 있는 설명, 데이터 품질 규칙, 관련 메타 정보 등을 코드화하여 명시하고 관리합니다. 이 방식은 Git을 통한 버전 관리와 협업을 가능하게 해주며, 데이터 구조와 설명이 함께 관리되어 변경 추적 및 일관성 유지가 수월합니다.

<데이터 거버넌스 Admin 화면 예시 (테스트 데이터)>

DW에 저장된 메타데이터는 거버넌스 시스템으로 유입되어 중앙에서 관리됩니다. 사용자들은 포털을 통해 메타데이터를 조회하거나 필요에 따라 수정할 수 있으며, 일관된 용어 체계와 표준화된 설명을 통해 데이터 관리의 품질을 유지합니다. 에이전트가 자동으로 용어 설명을 제안하여 구성원이 용어의 일관성을 유지할 수 있도록 돕습니다.

<스키마 정보 관리>

실무적으로 상태 코드나 유형 코드와 같은 ENUM 값들은 종종 DB보다는 애플리케이션 소스 코드에 명시되어 있습니다. 이에 따라 당근페이는 내부 코드 저장소나 기술 Wiki 등을 정보원으로 삼아, ENUM 타입 컬럼의 정확한 설명 정보를 증강하는 프로세스를 도입했습니다. 이 과정은 브로쿼리의 컨텍스트 정합성을 높이고, 최신 변경 사항도 반영될 수 있도록 합니다.

<샘플쿼리 활용과 관리>

복잡한 분석 요구에 대해 단순한 메타데이터만으로 SQL을 생성하기에는 한계가 있습니다. 이를 보완하기 위해 “자연어 질문 – SQL 쿼리” 쌍으로 구성된 샘플 쿼리를 적극적으로 자산화하고 있습니다. 이를 위해 브로쿼리는 도메인 전문가가 직접 등록할 수 있는 인터페이스를 제공하며, 등록된 샘플 쿼리는 LLM이 복잡한 표현이나 구조를 학습할 수 있도록 돕습니다.
LLM은 예시들을 통해 복잡한 SQL 패턴 (윈도우 함수, 셀프 조인 등), 특정 자연어 표현 (전월 대비 증가율)과 SQL 구문 간의 매핑 관계, 자주 사용되는 분석 로직 등을 효과적으로 학습할 수 있습니다. 그 결과 LLM이 새로운 질문 유형을 받았을 때 few-shot prompting 성능이 크게 향상될 수 있었습니다.
실제 테스트 결과 샘플 쿼리 유무에 따라 정확도가 90% 이상 차이가 났습니다. 따라서 Text-to-SQL 문제를 해결할 때 샘플 쿼리를 자산화하는 것은 장기적 관점에서 기업에게 매우 중요합니다.

향후에는 충분한 샘플 쿼리를 기반으로 에이전트를 Fine-Tuning하여, 더 복잡하고 정교한 SQL을 생성할 수 있도록 발전시킬 계획입니다.

<용어 사전과 비즈니스 컨텍스트, 최신성 및 일관성을 위한 토큰화>

샘플 쿼리가 부족한 상황에서도 정확한 쿼리를 생성하기 위해 용어 사전(Glossary) 구축에 집중했습니다. 예를 들어 MAU (월간 활성 사용자), CPR (고객 유지율) 등 핵심 비즈니스 지표에 대한 명확한 정의와 집계 기준, 약어, 조건 등을 포함해 상세하게 기록하고 있습니다.
용어에 대한 표준 명칭, 모든 구성원이 동일하게 이해할 수 있는 명확한 설명과 자주 사용되는 약어 등을 정의합니다. 이는 전사 데이터 기반 커뮤니케이션의 기초가 되면서 LLM이 정확한 쿼리를 만들어낼 수 있는 근간이 됩니다.
그리고 단순히 용어의 이름과 기본 뜻만 나열하는 것을 넘어서, 비즈니스의 맥락과 구체적인 조건까지 포함하는 포괄적인 용어 사전을 구축하고 관리하고 있습니다. 예를 들어 “MAU”라는 용어 항목에 “최근 30일 이내에 앱을 한 번 이상 실행한 고유 사용자 수”라는 설명과 함께 “로그인 여부 기준인지”, “특정 OS 사용자만을 포함하는 지”, “집계 시점” 등 MAU를 계산하는데 필요한 모든 세부적인 조건과 비즈니스 합의 내용을 명시적으로 기술합니다.

또한, 테이블과 컬럼명을 Tokenizing하여 메타데이터의 최신성을 유지하며 변경에도 유연하게 대응할 수 있도록 설계했습니다.

이처럼 구조화된 용어사전과 컨텍스트 정보는 LangGraph 워크플로우 내에서 Semantic Validation이나 Multi-hop Validation 기법에 활용되며, 브로쿼리 에이전트가 질문의 의미를 보다 깊이 있게 이해하고 정확한 쿼리를 생성하는 데 핵심적인 역할을 합니다.

성능 개선과 정확도 향상을 위한 고민

데이터 기반을 탄탄히 갖추는 것 외에도, 브로쿼리 에이전트의 응답 성능과 정확도를 높이기 위한 별도의 노력이 필요합니다. 특히 집중하고 있는 개선 영역은 다음과 같습니다:

Retrieval 최적화
사용자 질문에 대한 최적의 컨텍스트를 찾아주는 검색 정확도와 효율성을 높이는 데 집중하고 있습니다. Hybrid Search, Keyword Boosting, ANN Parameter Tuning 등이 해당됩니다.
Supervised Fine Tuning (SFT)
당근페이 데이터셋과 특정 질문 유형에 특화된 SQL 생성 능력을 갖도록 LLM 성능을 개선하는 방안도 탐구하고 있습니다. 또한 Text-to-SQL 리더보드에 제시된 논문들을 통해 다양한 아이디어를 얻고 있습니다.
비즈니스 컨텍스트 고도화
용어 사전 등의 비즈니스 맥락 정보를 워크플로우 내에서 더 정교하게 검증하고 반영하는 방법을 연구합니다. (Multi-hop Semantic Validation)
Evaluation 체계 고도화
개선을 위해 시도한 결과/효과를 측정하고 지속적으로 관리하기 위한 평가 체계를 고도화 하는 과정도 중요하게 여기고 있습니다. RAGAS, LLM as a Judge, Retrieval Metrics와 Generation Metrics를 통해 평가 체계를 구축하고 발전시켜가고 있습니다.

브로쿼리 도입효과 및 AWS 구축 장단점

브로쿼리를 내부에 적용하는 과정에서 당근페이에 가져온 효과와 Lesson & Learn을 정리해보았습니다.

브로쿼리 도입 효과

의사결정 속도 향상: 누구나 직접 데이터를 조회함으로써 의사결정 속도가 향상되었고, 빠른 인사이트 도출도 가능해졌습니다.
데이터 접근성 및 활용성 증가: SQL을 몰라도 자유롭게 데이터를 조회하고 분석할 수 있어서 데이터 활용성이 증가되었습니다.
데이터 리터러시(Literacy) 강화: 데이터를 직접 다루는 경험을 통해 많은 구성원들의 분석 역량도 자연스럽게 향상될 것으로 기대하고 있습니다.
엔지니어 리소스 절감: 반복 요청 업무가 줄어 엔지니어가 서비스 개발 집중 등 본연의 업무에 집중하게 되어 조직의 생산성 향상 가능성이 열렸습니다.
데이터 중심 문화 정착: 자율적 데이터 활용 경험을 통해 데이터 중심으로 협업 및 의사결정 문화가 변화되고 있습니다.

AWS 기반 Text-to-SQL 구축 장점

최신 AI 모델의 빠른 활용: Bedrock을 통해 Claude, DeepSeek, Llama 등 최신 모델을 활용하며 빠른 실험과 교체가 유연했습니다.
운영 효율성과 확장성: DynamoDB, OpenSearch 등 완전 관리형 서비스로 자동 확장 및 안정적인 운영이 가능했습니다.
효율적인 데이터 파이프라인: Redshift, MSK, S3 등과 Seamless하게 연동되어 수집부터 분석, 모니터링까지, 효율적인 데이터 파이프라인 구성이 가능했습니다.
정확한 SQL 생성을 위한 RAG 최적화: OpenSearch 기반 벡터 검색구조로 정확도 높은 RAG 시스템 구축이 가능했습니다.
빠른 MVP 개발, 낮은 진입 장벽: 복잡한 인프라 없이 빠르게 프로토타입을 개발하면서 반복적인 실험과 검증이 가능했습니다.

다만, 고려 사항도 존재했습니다. 내용은 아래와 같습니다.

모델 커스터마이징 제약: Bedrock의 API 기반 호출 방식은 완전한 모델 커스터마이징에 제한을 느꼈습니다.
비용 이슈: 트래픽 증가시 예상치 못한 비용 증가 가능성이 있었습니다.
AWS 서비스 의존성: 의존도 증가로 인한 장기 아키텍처 유연성 저하가 우려되었습니다.

따라서 위 내용들을 감안하면서 AWS의 장점을 극대화하도록 시스템을 설계하는 것이 중요합니다.

Next Steps

앞으로 브로쿼리가 나아갈 방향은 다음과 같습니다:

MCP 기반 툴 확장: 단순 쿼리 응답을 넘어 외부 툴과 연동하는 스마트 데이터 도우미로 발전시킬 계획입니다.
SFT 학습 데이터 확보: 전용 학습 데이터 기반 모델 튜닝을 통해 쿼리 생성 정확도를 높이고자 합니다.
사용자 피드백 기반 정교화: 사용자 피드백을 체계적으로 수집하고 반영하여 쿼리 생성 정확도와 사용자 경험을 지속적으로 개선할 예정입니다.
데이터 영속성 확보: 지식 베이스의 지속적인 성장과 영속성을 위해 메타데이터 관리 문화를 만들어 나가고 있습니다.
고도화된 기능 확장: 자동 리포트, 쿼리 최적화 제안, 데이터 품질 진단 및 알림 기능 등 데이터 분석 업무 패러다임 전환을 위한 부가 기능 확장도 준비 중입니다.

2부에서 다룬 내용들을 간단하게 요약하면 다음과 같습니다.

메타데이터 및 데이터 카탈로그 연동

브로쿼리는 단순 LLM 모델 호출을 넘어서, 내부 MCP를 통해 기술/운영/비즈니스 메타데이터를 통합 관리합니다.

테이블 및 컬럼 정보: dbt Property YAML 기반 테이블 메타정보 수집
샘플 쿼리: 브로쿼리 학습용 “정답 쿼리”를 수집하고 OpenSearch에 인덱싱
용어 사전: 용어, 약어, 동의어 매핑과 비즈니스 설명 포함
ENUM 관리: 컬럼별 ENUM 값 정의와 유효성 관리, 소스 기반 정보 추출
데이터 계보 및 접근 로그: ETL/Access 로그 기반 데이터 계보 추적

이를 통해 단순 자연어 처리에 그치지 않고, 조직 지식과 데이터 간 맥락을 연결함으로써 정확한 SQL 생성을 실현합니다.

성능 최적화를 위한 전략

정확도와 응답 속도 향상을 위해 다음의 전략들이 적용되었습니다.

OpenSearch Hybrid Search 튜닝: 키워드 부스팅, ANN 파라미터 튜닝을 통한 후보 문서 질의 최적화
후보 SQL 선택 (Candidate Selection): Llama, Qwen 등을 통한 Supervised Fine-Tuning 기반 모델 적용 실험
정확도 평가: RAGAS 및 LLM-as-a-Judge 등 테스트셋 평가

이 외에도 Retrieval 단계에서 Business Context 기반 Multi-hop Semantic Matching을 통해 문맥에 부합하는 데이터만 선택하도록 구성되어 있습니다.

AWS 서비스 기반 구축의 장점

Amazon Bedrock: Claude, Llama, DeepSeek 등 최신 모델을 API 기반으로 손쉽게 교체/활용 가능
Amazon OpenSearch: 벡터 기반 하이브리드 RAG 구성에 최적화된 검색 플랫폼
Amazon Redshift: 대용량 SQL 쿼리 처리 최적화
Amazon DynamoDB: 질의 히스토리 및 사용자 피드백 저장을 위한 완전관리형 NoSQL

결론

브로쿼리는 Amazon Bedrock을 포함한 AWS 생태계를 기반으로 자연어와 데이터 간의 장벽을 허물며, 조직 전체의 데이터 활용 문화를 혁신하고 있습니다. 생성형 AI, 벡터 검색, 메타데이터 통합 아키텍처가 결합된 브로쿼리는 당근페이의 데이터 중심 문화 정착을 가속화하고 있으며, 이 사례가 생성형 AI 기반 데이터 분석 자동화에 관심 있는 기업에게 실질적이며 재현 가능한 벤치마크가 되기를 기대합니다.

AWS 기술 블로그