당근페이의 Amazon Bedrock 기반 Text-to-SQL로 완성하는 데이터 혁신, Part 1: 브로쿼리 개요와 아키텍처

이 블로그는 2025 Seoul Summit에서 “Amazon Bedrock 기반Text-to-SQL로 완성하는 데이터 혁신:당근페이의 핀테크 성공 전략”의 주제로도 발표되었으며, 세션에서 다루지 못했던 세부 내용에 대해서도 추가로 소개합니다.

블로그는 당근페이 내부 Text-to-SQL 챗봇인 브로쿼리(Broquery)에 대해 총 2부에 걸쳐 소개하고자 합니다.

1부에서는 브로쿼리의 기획 배경과 전반적인 아키텍처를 소개합니다.
2부에서는 Text-to-SQL의 정확도를 좌우하는 요소인 ‘컨텍스트’, 즉 메타데이터 수집 및 관리 방법을 중점적으로 설명합니다.

당근페이는 4천만 명 이상이 사용하며, MAU(Monthly Active Users) 2천만 이상인 국내 대표 지역 기반 커뮤니티 플랫폼 ‘당근’의 간편결제 서비스입니다. 사용자 간 직거래와 지역 커머스에서 안전하고 간편한 금융 경험을 제공하며, 지역 생활 금융의 새로운 표준을 만들어가고 있습니다.
당근페이는 2025년 3월 당근머니 하나통장을 출시하고, 4월에는 편의점택배 예약 서비스를 오픈하며 사용자들의 일상 속으로 빠르게 스며들고 있습니다.

더 편리한 서비스를 제공하기 위해 당근페이 내부에서는 업무 효율성과 혁신을 위한 다양한 노력이 진행 중이며, 그중 중요한 측 중 하나가 데이터를 생성형 AI로 혁신하는 시도입니다. 이 과정들은 금융규제 샌드박스 지정에 앞서 안전한 개발 환경에서 이뤄지고 있습니다.

생성형 AI 활용 배경

일반적인 비즈니스 환경에서는 마케터, 개발자, 데이터 관리자 등 다양한 직군이 존재하며, 이들 모두가 시스템에 자유롭게 접근하긴 어렵습니다.
마케팅 데이터나 업무 실적 데이터 등을 조회하려면 보통 데이터 관리자에게 별도 요청을 하거나, 보안 승인을 받아야 하며, 처리된 결과물들은 CSV나 Excel 파일 형태로 전달됩니다. 이후 요청자가 추가 분석을 위해 필터링이나, 피벗 등을 직접 수행해야 하며, 데이터가 부족할 경우 이 과정은 반복됩니다.

당근페이에서도 상황은 유사했습니다. 한 동료가 엑셀 작업에 어려움을 겪는 모습을 보고, “어떻게 하면 이 과정을 더 쉽게 만들 수 있을까?”라는 문제의식에서 본 프로젝트가 출발하게 되었습니다.

문제를 정의하면 다음과 같습니다.

비개발 직군의 데이터 활용 진입 장벽

데이터 접근이 개발팀에 의존
평균 1~3일의 분석 대기 시간
반복적인 개발 리소스 소모

조직 전체의 리터러시 향상 필요

SQL 학습 장벽 및 데이터 구조 이해의 한계
단순 조회조차 복작한 절차 요구
누구나 쉽게 데이터를 활용할 수는 없을까?

이러한 문제를 해결하고자, Text-to-SQL 기반 AI 데이터 분석봇의 개발을 결정했고, 다음과 같은 효과를 기대했습니다.

비개발 직군의 쉬운 데이터 접근
개발 리소스 절감 및 조직 전체의 데이터 활용 역량 향상

Text-to-SQL이란?

Text-to-SQL은 말 그대로 자연어(Natural Language)로 작성된 문장을 SQL(Structured Query Language) 쿼리로 자동 변환해주는 기술입니다.
예를 들어 사용자가 “지난달 가장 많이 팔린 상품은 뭐야?”라고 입력하면, 시스템이 해당 질문을 적절한 SQL 쿼리로 변환해 데이터베이스에서 필요한 정보를 조회해줍니다.

즉, SQL을 모르는 사용자도 자연어만으로 원하는 데이터를 조회할 수 있어 마케팅, 기획, 영업 등 비개발 부서의 데이터 활용도를 획기적으로 향상시킬 수 있습니다. 또한 반복적인 데이터 요청을 자동화해 분석가나, 엔지니어의 리소스 부담을 줄일 수 있습니다.

Text-to-SQL on Spider는 Spider 데이터셋을 기반으로 여러 Text-to-SQL 모델/방법론들의 성능을 평가하기 위해 사용되는 대표적인 벤치마크입니다. 다양한 도메인의 복잡한 데이터베이스 스키마에 대해 모델이 얼마나 정확하게 쿼리를 생성할 수 있는 지 측정한 결과들을 볼 수 있고 이를 참고해서 각자의 비즈니스에 맞게 성능을 더 높일 수 있는 시도를 해볼 수 있습니다.

브로쿼리(Broquery) 소개

브로쿼리는 ‘브로콜리’를 모티브로 한 캐릭터로, 당근페이 내부에서 사용하는 AI 기반 데이터 분석 봇입니다.

여기에는 두 가지 의미가 담겨있습니다

데이터를 더 쉽고 건강하게 다루자
모든 구성원에게 친근한 ‘브로(Bro)’처럼 다가가, 데이터 관련 질문(쿼리)’을 해결해주자

당근페이 구성원이라면 누구나 브로쿼리에게 자연어로 질문하고, 기술 장벽 없이 필요한 데이터를 바로 얻을 수 있게 되었습니다.

<브로쿼리 요청 수행 및 결과 예시 (테스트 데이터)>

예시에서 보이듯, 일반 사용자가 Slack에서 브로쿼리에게 자연어로 질문을 입력하면 브로쿼리는 1분 이내에 요약된 답변, SQL 쿼리, 필요 시 시각화 결과까지 제공합니다.

브로쿼리 구축 시 고려한 5가지 핵심 요구사항

브로쿼리를 설계하기 전, 다음과 같은 5가지 핵심 요구 사항을 정의했습니다. 이들은성공적 수행을 위한 핵심 기준이기도 했습니다.

접근성
- 데이터 전문가가 아닌 일반 구성원도 직관적으로 데이터를 탐색할 수 있어야 합니다.
사용자의 진짜 의도 파악
- 단순히 키워드 매칭을 넘어서, 질문의 맥락과 의미를 이해해 진짜 의도를 파악해야 합니다.
대화 문맥 인식
- 사용자와 브로쿼리가 여러 차례 질문-답변이 오갈 경우, 대화 흐름 속 문맥을 자연스럽게 이어가야 합니다.
잘못된 SQL의 점검 및 개선
- 항상 완벽한 쿼리를 생성하는 것은 어렵기 때문에, 자체적으로 SQL 오류를 탐지하고 보정할 수 있어야 합니다.
정확성
- 편의성과 대화 능력도 중요하지만, 잘못된 데이터를 기반으로 의사결정이 내려져선 안 되므로, 높은 신뢰도가 필수입니다.

이러한 요구사항을 바탕으로 브로쿼리의 아키텍처 설계가 시작되었습니다.

상세 아키텍처

<주요 구성 요소>

브로쿼리는 다음과 같은 주요 컴포넌트로 구성되어 있습니다.

사용자와 직접 소통하는 Slack 인터페이스, 대화 기록 및 피드백을 관리하는 Amazon DynamoDB
시스템의 두뇌 역할을 하는 Amazon Bedrock 기반 에이전트, 컨텍스트 정보를 찾아주는 Amazon OpenSearch 기반 RAG 시스템
데이터의 구조와 의미를 담은 Metadata 플랫폼, 다양한 외부 도구와 유연한 연동을 위한 MCP 서버
실제 데이터를 저장하는 Amazon Redshift, Agent들의 복잡한 플로우를 오케스트레이션하는 LangGraph

<브로쿼리 전체 아키텍처 다이어그램>

아키텍처의 주요 흐름은 다음과 같습니다.

Slack 인터페이스 + DynamoDB
‘접근성’과 ‘문맥 인식’을 높이는데 기여합니다. 자연어로 질문하고 지난 대화 내용을 기반으로 깊이 있는 질문을 이어갈 수 있습니다.
에이전트 (Agent)
모든 과정을 지휘하는 핵심입니다. 사용자의 질문을 받으면 어떤 정보가 필요하고 어떤 단계를 거쳐야 할지 판단합니다. 이때 Agent는 사용자 질문으로부터 의도를 파악하고 SQL을 생성하는 핵심적인 역할을 수행합니다. 하지만 정확한 답변, 정확성을 위해 다양한 정보를 포함한 ‘컨텍스트’가 필요합니다.
MCP 서버 (Multi-Context Provider)
MCP는 특정 데이터를 담는 저장소가 아니라, 내부 API, 비즈니스 컨텍스트, 데이터 디스커버리 도구 등과 표준화된 프로토콜로 연동되는 통합 허브입니다. 기존에는 각 시스템마다 별도의 연동이 필요했지만, MCP를 통해 표준 방식으로 연결함으로써 개발 복잡성을 줄이고 확장성과 유지 보수성을 크게 개선할 수 있었습니다. 이 구조는 브로쿼리를 단순 데이터 분석 도구가 아닌 여러 시스템과 유기적으로 협력하며 복잡한 질문에 답하고, 나아가 업무 자동화까지 수행할 수 있는 지능형 에이전트로 발전시킬 수 있는 기반이 됩니다.
Metadata Store + RAG 시스템
어떤 데이터를 어디서 어떻게 조회할지 판단하려면 기술 메타데이터가 필요합니다. Metadata Store는 Redshift 등 다양한 소스로부터 수집된 정보를 중앙에서 관리합니다. 또한 소스코드, 위키, 데이터베이스에서 수집된 데이터를 증강하여 유의미한 메타데이터를 제공합니다. 그리고 OpenSearch와 Titan Embeddings 기반의 RAG 시스템은 사용자 질문과 의미적으로 관련된 테이블, 컬럼, 용어를 정확하게 찾도록 돕습니다.

위에서 언급한 내용에 더해 SQL이 완벽하지 않을 수 있기 때문에, 스스로 점검하고 개선하는 “자가 점검(Self-Reflection)” 메커니즘도 정확성을 높이기 위한 중요 요소로 고려되었습니다.

브로쿼리는 여러 전문 컴포넌트들이 각자의 역할을 수행하며 유기적으로 협력하는 구조입니다. 2번과 같이 LangChain과 LangGraph 프레임워크를 활용해서 오케스트레이션을 효과적으로 구현하고 있습니다.

LangGraph 기반 Agentic 워크플로우

사용자의 질문 유형이나 대화의 흐름에 따라 필요한 컴포넌트와 정보가 달라지기 때문에, 복잡한 상호작용을 매끄럽게 조율하고 관리하는 오케스트레이션이 매우 중요합니다.

<Agentic 워크플로우 다이어그램>

브로쿼리의 워크플로우는 사용자의 자연어 질문에서 시작됩니다.
Agent는 사용자의 질문을 받은 후, 필요 시 DynamoDB에서 이전 대화 기록을 조회하여 질문의 문맥을 파악합니다. 예를 들어 “동일한 기간의 송금 유저 수는?”이라는 질문이 들어오면, 문맥에서 “동일한 기간”에 대해 이해합니다.

그다음, Agent는 사용자의 진짜 의도를 분석합니다. 질문이 단순 정보 요청인지, 데이터 분석이 필요한지, 혹은 일반적인 대화인지 판단한 뒤, 그에 맞는 처리 흐름으로 분기합니다.

예: 날씨 질문이라면 “General Question SubGraph”로 이동
예: 데이터 분석이 필요하면 “Query Generation SubGraph”로 이동

스키마 링킹(Schema Linking)

정확한 SQL 생성을 위한 핵심 재료, 즉 “기술 메타데이터”를 확보하는 매우 중요한 단계입니다. 단순히 정보를 찾는 것을 넘어 가장 정확하고 관련성 높은 정보를 찾아 정제하는 과정을 거칩니다. 여기에서 크게 두 가지 핵심 기술이 활용됩니다.
필요한 기술 메타데이터 후보군을 최대한 캡처하면서 관련성이 높은 정보를 효율적으로 찾기 위해 OpenSearch를 활용한 하이브리드 검색을 사용합니다.

<하이브리드 검색>

하이브리드 검색이란 키워드 기반 텍스트 검색과 의미 기반의 벡터 검색을 결합한 기술입니다. 구체적인 코드나 정책명이 포함된 핀테크 데이터에서 하이브리드 검색은 강력한 접근 방식이 될 수 있습니다. 하지만 검색을 통해 얻은 초기 후보군에 관련성이 낮거나 중요도가 낮은 정보가 여전히 포함될 수 있다는 고려 요소가 존재합니다.
그러한 한계를 극복하기 위해 “Reranker”를 사용합니다. Reranker는 1차로검색된 상위 결과 목록을 입력받아 사용자의 원본 질문과 각 후보 문서 간의 관련성을 다시 평가합니다. 즉, Reranker는 핵심 필터와 같은 역할을 수행합니다. 이를 통해 RAG 시스템 전체의 성능을 한 단계 더 끌어올릴 수 있습니다.

MCP 기반 비즈니스 컨텍스트 보강

하이브리드 검색과 Reranker를 통해 기술 메타데이터가 정제된 후, MCP 서버를 통해 회사 내부 규칙, 업무 맥락 등 실질적인 비즈니스 컨텍스트도 함께 보강합니다.

잠깐 요약하면, “(1) 하이브리드 검색으로 넓게 찾고, (2) Reranker로 정밀하게 걸러내고, (3) MCP로 비즈니스 컨텍스트까지 보강”하는 다단계 컨텍스트 정제를 통해 LLM이 최상의 성능을 발휘할 수 있도록 합니다.

SQL 생성 및 Self-Correction

정제된 컨텍스트를 바탕으로, Amazon Bedrock 기반 LLM이 Text-to-SQL 변환을 수행합니다.
이때 생성된 SQL은 곧바로 실행되지 않고, 사전 검증(Self-Reflection) 단계에서 문법 오류나 실행 오류를 탐지하여 수정합니다. 이를 통해 실행 가능한 최적의 SQL을 생성하게 됩니다.

실행 및 시각화

최종 SQL로 Amazon Redshift에서 실행되며, 결과는 필요시 사용자의 이해를 돕기 위해 표나 차트 등 시각화 형태로 제공됩니다. 모든 결과 데이터를 종합하여 최종 답변이 생성되고 Slack 인터페이스를 통해 응답됩니다.

워크플로우는 여러 단계와 조건 분기, 재시도나 수정과 같은 복잡한 로직이 포함됩니다. LangGraph는 상태를 가지고 순차적 또는 조건적으로 실행되는 복잡한 워크플로우를 그래프 구조로 효과적으로 구현하고 관리할 수 있는 도구입니다.
각 단계를 노드(Node)로, 단계 간의 이동을 엣지(Edge)로 표현하여 전체 흐름을 명확하게 구축하고, 필요에 따라 특화된 서브그래프(SubGraph)를 모듈처럼 호출하여 재사용성과 효율성을 높일 수 있습니다.
LangGraph 기반의 정교한 워크플로우를 통해 브로쿼리는 다양한 사용자 질문에 대해 보다 안정적이면서도 정확하고 효율적으로 대응할 수 있게 되었습니다.

브로쿼리의 동작 과정에 대해 주요한 내용 위주로 간단하게 요약하면 다음과 같습니다.

브로쿼리는 LangGraph 기반의 분기형 Agentic 워크플로우로 구성되어 있으며, 다음과 같은 기술 요소로 동작합니다.

질의 이해 및 분석 (Intent Analysis)
- LLM을 통해 자연어 질문 분석
- SQL 생성 여부 판단 및 적절한 SubGraph로 분기
컨텍스트 보강 및 검색 (Retrieval-Augmented Generation)
- Amazon OpenSearch + Titan Embeddings 기반 하이브리드 검색 (Lexical + Semantic Search)
- MCP 서버를 통한 비즈니스 컨텍스트 보강
- 스키마 정보, 용어사전, 샘플 쿼리 등을 메타데이터로 활용
SQL 생성 및 검증 (SQL Generation + Validation)
- LLM을 활용한 SQL 생성
- 내부 규칙 기반의 Self-Reflection 단계에서 오류 탐지 및 수정
실행 및 시각화
- Amazon Redshift에서 SQL 실행
- 결과 데이터는 표/차트로 시각화 후 Slack을 통해 사용자에게 제공
- 사용자 피드백은 Amazon DynamoDB에 기록되어 후속 개선에 반영

마무리

아무리 강력한 모델과 정교한 워크플로우를 구성하더라도, 정확하고 풍부한 컨텍스트가 전달되지 않으면 잘못된 결과가 나올 수 있습니다.
따라서 이어지는 2부에서는 정확도에 직접적인 영향을 미치는 메타데이터 수집 및 관리 전략을 중점적으로 다룰 예정입니다.

2부 바로가기 : Part 2: 데이터 수집과 관리, 향후 계획

AWS 기술 블로그