Text-to-SQL로 다가가는 데이터 민주화

1. 들어가며

1. 이 포스트에서 다루는 내용

• 누구에게 도움이 될까요?
• 자사 데이터를 AI와 연동하고 싶은 데이터 엔지니어
• Text2SQL 기술의 실무 적용을 고민하는 AI/ML 엔지니어
• 데이터 접근성 개선을 원하는 CTO, 데이터팀 리더
• AI Agent 아키텍처 설계에 관심 있는 개발자

• 어떤 인사이트를 얻을 수 있나요?
• 이론적인 Text2SQL을 넘어선 실제 운영 환경에서의 고려사항
• MCP(Model Context Protocol)를 활용한 AI-데이터 연동의 새로운 접근법
 

2. 왜 중요한가요?

• 수백 개의 테이블 중에서 적절한 데이터를 찾아야 하고

• 비용 폭탄을 방지하면서도 유연한 쿼리를 허용해야 하며

• 개발자가 아닌 사용자도 안전하게 사용할 수 있어야 합니다.

2. 프로젝트 배경(Pain point 분석)

• 복잡한 SQL 쿼리 작성이 필요하고

• 데이터 구조와 비즈니스 로직에 대한 도메인 지식이 필요하며

• AI 도구와의 연동이 기술적으로 제한적이었습니다

3. 문제 정의(Action planning)

1. 다양한 직군의 데이터 분석 니즈와 접근성 문제

• 마케터: "이번 달 채용 공고 조회수가 높은 업종 TOP 10을 알고 싶어요"

• 콘텐츠 에디터: "최근 리뷰가 많이 달린 회사들의 특징을 분석해 주세요"

• 기획자: "사용자 행동 패턴을 보고 새로운 기능 아이디어를 얻고 싶어요"

2. 데이터 분석 요청 처리의 비효율성

• 요구사항 해석의 어려움: "~~할 수 있지 않을까요?"와 같은 모호한 요구사항

• 실시간 대응의 한계: 급하게 필요한 데이터도 대기 시간 필요

• AI 도구 활용의 제약: ChatGPT로 SQL을 생성해도 실제 데이터 접근은 별도 과정 필요

3. 데이터 접근의 안전성과 비용 관리

• 비용 폭탄의 위험: 잘못된 쿼리 하나로 수십만 원의 비용 발생 가능

• 권한 관리의 복잡성: 직군별로 다른 데이터 접근 권한 필요

• 실수 방지의 어려움: 개발자가 아닌 사용자의 실수로 인한 장애 가능성

4. 자연어와 데이터 분석 간의 격차

• 복잡한 SQL 작성 (JOIN, 집계, 필터링 등)

• 적절한 테이블과 컬럼 찾기

• 비즈니스 로직 구현 (예: "높은 연봉"의 기준 정의)

4. 핵심 요구 사항

1. 원활한 AI 통합

• Cursor AI, Claude, ChatGPT 등에서 직접 BigQuery 데이터 접근

• 자연어 명령으로 복잡한 데이터 분석 수행

2. 강력한 비용 관리

• 실행 전 비용 예측 및 사용자 승인 플로우

3. 직관적인 데이터 탐색

• 스키마 자동 탐색 및 테이블 추천

• 샘플 데이터 미리보기 및 시각화

• 파티션 정보 및 최적화 제안

4. 고급 분석 기능

• 자연어를 SQL로 자동 변환

• 쿼리 성능 최적화 및 대안 제안

• 데이터 품질 분석 및 비즈니스 임팩트 해석

5. 기술 스택 및 아키텍처

5. 1. 핵심 기술 스택

- Python 3.10+ (FastMCP)
- Google Cloud BigQuery SDK
- FastMCP (MCP 프로토콜 서버)
- LangGraph (AI Agent 워크플로우 오케스트레이션)
- TextEmbedding via GCP Vertex AI

5. 2. 사용 기술 소개

1. MCP(Model Context Protocol)

사용자 → ChatGPT → "BigQuery에서 데이터를 가져와주세요"
ChatGPT → "죄송하지만 직접 데이터베이스에 접근할 수 없습니다"

사용자 → MCP 클라이언트 → MCP 서버 → DataSource → 실제 데이터 반환

2. LangGraph: AI Agent의 두뇌 구조

1. 분석 단계: "리뷰", "IT 회사", "급여" 키워드 추출

2. 계획 단계: 필요한 테이블들 식별 (회사 정보, 리뷰 데이터, 급여 데이터)

3. 실행 단계: 각 테이블에서 데이터 조회

4. 검증 단계: 데이터 품질 확인, 결과 검토

5. 재계획: 필요시 추가 데이터 수집 또는 분석 방법 조정

3. AI Agent와 Agentic 구조

• 자율성(Autonomy): 사용자가 모든 단계를 지시하지 않아도 스스로 판단

• 도구 사용(Tool Use): 외부 시스템과 상호작용 가능

• 계획 수립(Planning): 복잡한 작업을 단계별로 분해

• 피드백 학습(Feedback Loop): 결과를 보고 접근 방법 개선

사용자: "우리 회사 마케팅 성과를 분석해줘"

일반 AI: "죄송하지만 귀하의 회사 데이터에 접근할 수 없습니다"

AI Agent:
1. 마케팅 관련 테이블 탐색 → 광고 지출, 전환율, 매출 데이터 발견
2. 적절한 기간 설정 → 최근 3개월 데이터로 결정
3. 데이터 조회 및 분석 → SQL 쿼리 실행
4. 시각화 및 인사이트 도출 → 그래프 생성, 트렌드 분석
5. 개선 제안 → 데이터 기반 추천사항 제시

5. 3. 아키텍처 설계

1. 초기 설계 (단순한 구조)

• 순차 실행: 각 단계가 완료되어야 다음 단계 진행

• 단일 경로: 모든 요청이 동일한 4단계를 거침

• 에러 시 전체 실패: 한 단계에서 실패하면 처음부터 다시 시작 / 에러 반환

• 상태 관리 없음: 이전 단계의 정보를 다음 단계에서 충분히 활용하지 못함

2. 현재 아키텍처 (문제 해결 후 발전된 구조)

6. 초기 구축 이후 문제 해결

6. 1. 초기 테스트에서 발생한 주요 문제들

1. 대용량 쿼리 남발 문제 💸

• 한 번의 실수로 큰 비용 발생

• 테스트 단계에서만 예상치 못한 비용 누적

# 다단계 비용 검증 시스템
def validate_query(query):
    # 1. Dry Run으로 비용 예측
    cost_estimate = estimate_cost_with_dryrun(query)
    
    # 2. 비용별 차등 대응 (현실적인 임계값)
    if cost_estimate > 5.0:  # $5 이상 승인 필요 (약 0.8TB)
        return request_user_approval()
    elif cost_estimate > 1.0:  # $1 이상 경고 (약 160GB)
        return show_cost_warning()
    elif cost_estimate > 0.1:  # $0.1 이상 알림 (약 16GB)
        return show_cost_info()
    
    # 3. 자동 LIMIT 추가로 안전장치
    if "LIMIT" not in query.upper():
        query = add_default_limit(query, 1000)
    
    return validated_query

2. 엉뚱한 테이블 탐색 문제 🔍

• "연봉 정보"를 요청했는데 user_salary_temp (테스트 테이블) 발견

• Description이 없는 테이블들로 인한 잘못된 매칭

• 파티션 테이블 (salary_20201002, salary_20210315 등)을 개별 테이블로 인식

# 벡터 검색 기반 스마트 테이블 탐색
def search_relevant_tables(user_query):
    # 1. 사용자 쿼리 임베딩
    query_embedding = embed_text(user_query)
    
    # 2. 테이블 메타데이터 벡터 검색
    # (description + schema 정보가 미리 임베딩되어 저장됨)
    similar_tables = vector_db.similarity_search(
        query_embedding, 
        top_k=10
    )
    
    # 3. 테스트/임시 테이블 필터링
    excluded_patterns = ['temp_', 'test_', 'backup_']
    filtered_tables = filter_production_tables(similar_tables)
    
    # 4. 비즈니스 중요도로 재정렬
    prioritized_tables = rank_by_business_priority(filtered_tables)
    
    return prioritized_tables

6. 2. Agentic 구조로의 전환 과정

단순 구조의 한계점 인식

1. 복잡한 분석 작업 처리 불가:
• "최근 3개월 IT업계 상위 10% 회사의 리뷰 트렌드 분석" 같은 다단계 요청
• 여러 테이블 JOIN이 필요한 복합 분석 시나리오

2. 워크플로우 롤백 불가능:
• SQL 생성 단계에서 실패 → 테이블 탐색부터 다시 시작
• 비용 검증 실패 → 전체 프로세스 재시작 (이미 찾은 테이블 정보 손실)
• 중간 결과 활용 불가로 인한 비효율성

3. 조건부 로직 구현의 한계:
• 비용이 높으면 → 샘플링으로 재시도
• 테이블을 못 찾으면 → 키워드 변경하여 재탐색
• 이런 "if-then" 로직을 순차 구조로는 구현 불가

사용자: "최근 3개월 IT업계 연봉 상위 10% 회사의 리뷰 점수 분석해줘"

기존 시스템의 처리:
1. 테이블 탐색 → companies, reviews, salaries 발견 ✅
2. SQL 생성 시도 → reviews 테이블에 salary 컬럼이 없음을 발견 ❌
3. 전체 실패 → "SQL 생성 실패" 메시지만 반환

문제점:
- 이미 찾은 3개 테이블 정보 모두 손실
- salaries 테이블과 reviews 테이블을 JOIN하면 되는데 로직 시도 불가
- 대안적인 접근법(테이블 관계 재분석, 다른 JOIN 방식 시도) 불가능
- 사용자는 처음부터 다시 요청해야 함

Agentic 구조의 장점

• 책임 분리:
• 단일 프롬프트로 모든 작업을 처리할 때 발생하는 복잡성과 예측 불가능성을 해결
• 각 도구가 특정 영역에 집중함으로써 프롬프트 최적화가 용이해짐

• 확장성과 유지보수성:
• 새로운 기능 요구사항에 대해 독립적인 도구 추가로 대응 가능
• 특정 도구의 수정이 다른 컴포넌트에 미치는 영향을 최소화
• 도구별 독립적인 테스트 환경 구축으로 품질 관리 효율성 향상

• 성능 최적화:
• 병렬 처리를 통한 전체 응답 시간 개선
• 도구별 캐싱 전략 적용으로 리소스 효율성 증대
• 성능 병목 지점에 대한 선택적 최적화 가능

• 재사용성: 각 Tool들을 다른 컨텍스트에서도 활용 가능

각 Tool의 역할과 책임

1. Data Explorer Tool

사용자 요청: "{user_query}"에 대해 관련 테이블을 찾아주세요.

분석 과정:
1. 키워드 추출 및 비즈니스 용어 매핑
2. 벡터 유사도 검색으로 후보 테이블 발견
3. 테스트/임시 테이블 제외 필터링
4. 비즈니스 중요도 점수 계산
5. 상위 5개 테이블 추천 및 JOIN 관계 분석

출력 형식: 테이블명, 관련도 점수, 추천 이유, JOIN 가능 테이블

2. Query Generator Tool

다음 정보를 바탕으로 BigQuery SQL을 생성해주세요:

사용자 요청: "{user_request}"
선택된 테이블: {selected_tables}
테이블 스키마: {table_schemas}

생성 규칙:
1. BigQuery 문법 준수 (표준 SQL)
2. 성능 최적화: WHERE 절 우선 적용, 적절한 LIMIT 사용
3. JOIN 필요 시 적절한 키 활용
4. 복잡도에 따라 템플릿 또는 동적 생성 선택

출력: SQL 쿼리, 신뢰도 점수, 쿼리 설명, 복잡도 수준

3. Query Validator Tool

다음 SQL 쿼리를 종합적으로 검증해주세요:
{generated_sql}

검증 항목:
1. 보안 검사: SQL Injection 패턴, 위험한 명령어 탐지
2. 권한 검증: 사용자 접근 권한 내 테이블/컬럼 사용 여부
3. 비용 예측: Dry Run 기반 정확한 처리 비용 계산
4. 성능 분석: 실행 시간, 리소스 사용량 예측

비용 임계값:
- $5 이상: 승인 필요
- $1 이상: 경고 표시
- $0.1 이상: 정보 제공

출력: 안전성 여부, 예상 비용, 승인 필요 여부, 경고사항, 최적화 제안

4. BigQuery Executor Tool

검증된 SQL 쿼리를 BigQuery에서 실행하고 결과를 처리해주세요:
{validated_sql}

실행 절차:
1. 승인 필요 시 사용자 확인 대기
2. BigQuery 클라이언트로 쿼리 실행
3. 실행 메타데이터 수집 (비용, 시간, 행 수)
4. 결과 데이터 사용자 친화적 포맷팅
5. 에러 발생 시 기술적 메시지를 일반 사용자 언어로 변환

성능 모니터링:
- 실행 시간 추적
- 리소스 사용량 기록
- 실행 히스토리 저장

출력: 실행 상태, 포맷된 결과, 메타데이터, 인사이트 제안

5. Orchestrator Agent

사용자 요청을 전체 워크플로우를 통해 처리해주세요:
"{user_request}"

처리 단계:
1. Data Explorer → 관련 테이블 탐색 및 추천
2. Query Generator → 자연어를 SQL로 변환
3. Query Validator → 보안 및 비용 검증
4. BigQuery Executor → 안전한 쿼리 실행
5. 결과 통합 → 인사이트 생성 및 최종 답변

각 단계별 실패 처리:
- 테이블 미발견 → 키워드 확장 제안
- 낮은 신뢰도 → 명확화 요청
- 검증 실패 → 보안 이슈 설명
- 실행 오류 → 사용자 친화적 에러 메시지

출력: 최종 분석 결과, 인사이트, 실행 메타데이터, 개선 제안

6. 3. LangGraph 도입과 State 관리

• n8n: 시각적 워크플로우 구성이 가능하지만 복잡한 에이전트 간 상태 공유와 동적 조건부 로직 처리에 제약 → GUI 기반 설정의 한계

• LlamaIndex: RAG 파이프라인에 특화되어 있고 최근 워크플로우 기능도 추가되었지만, 학습 비용 대비 효율성 고려

• LangGraph: 에이전트 간 상태 공유와 조건부 플로우에 최적화

• 🔄 상태 기반 워크플로우: 각 에이전트 간 컨텍스트 공유 용이

• 🌊 조건부 플로우: 동적인 분기 처리 및 에러 복구 지원

• 🔍 디버깅 지원: 각 단계별 상태 추적 및 시각화 가능

• 🚀 확장성: 새로운 에이전트 추가 시 기존 플로우 영향 최소화

LangGraph State 관리 구조

LangGraph 도입 후 개선 효과

• 상태 추적 개선: 각 단계별 상태가 명확하게 관리되어 디버깅 용이

• 조건부 플로우: 동적인 분기 처리로 복잡한 비즈니스 로직 구현

• 에러 복구: 단계별 실패 시 적절한 복구 전략 적용

• 성능 모니터링: 각 노드별 실행 시간 및 성능 메트릭 수집

• 확장성: 새로운 에이전트 추가 시 기존 플로우에 미치는 영향 최소화

7. 실행 결과

8. 향후 발전 방향

1. AI 기능 강화

• Business Glossary 구축 : 더 정교한 비즈니스 용어 및 정책 이해
• ex)멤버십 : 멤버십 상품은 크게 2가지로 나뉩니다.(개인멤버십, 기업멤버십)
• ex) 매출 지표 : 멤버십 매출 == 개인멤버십 매출 + 기업멤버십 매출
→ 위와 같은 형태로 비즈니스 지표에 대한 정의, 산출식 등을 LLM Context로 제공해 줌으로써, 더 정확한 매칭이 가능하도록 구현할 예정입니다.

• 자동 인사이트 생성: 데이터에서 자동으로 비즈니스 인사이트 추출
• 매출에 대한 추출 요청 → 알아서 추이를 분석하고, 비즈니스 플랜 등을 제안해주는 기능.
 

2. 실행 시간 단축

• 현재는 복잡한 요청의 경우 최대 5분까지 소요되는 경우가 존재하나, 이를 개선하여 1분대에 사용자에게 답변을 줄 수 있는 시스템을 구축하고자 합니다.

3. 고급 시각화

• 자동 차트 생성: 데이터 특성에 맞는 최적 시각화 제안

• 대화형 대시보드: 실시간 데이터 탐색 인터페이스

• 보고서 자동 생성: 정기 보고서 템플릿 및 자동화

9. 마치며