AI 에이전트로 스프레드시트와 데이터베이스를 질의하는 방법
AI와 구조화된 데이터의 만남: 문제와 해결책
AI 에이전트가 구조화된 데이터를 이해하고 분석할 수 있는 능력은 게임 체인저라고 할 수 있어요. 🤖 기존의 대형 언어 모델(LLM)은 자연어를 이해하는 데 뛰어나지만, 정량적 분석이나 구조화된 데이터를 다루는 데는 한계가 있었죠. 특히, 데이터를 단순히 텍스트로 제공하면 계산이나 분석이 제대로 이루어지지 않았어요.
이 문제를 해결하기 위해 등장한 것이 바로 Query Tables입니다. 이 기능은 AI 에이전트가 SQL 쿼리를 실행해 구조화된 데이터를 분석하고, 정확한 답변을 제공할 수 있도록 도와줍니다.
문제: 정량적 분석에서의 의미 검색의 한계
먼저, 우리가 해결하려는 문제를 이해하는 것이 중요해요. 의미 검색(semantic search)은 비구조화된 텍스트에서 관련 정보를 찾아내는 데는 유용하지만, 정량적 분석에서는 다음과 같은 한계가 있어요:
- 불완전한 데이터 접근: 의미 검색은 데이터의 일부만 가져오므로 전체 데이터를 분석하기 어렵습니다.
- 계산 능력 부족: 데이터를 모두 가져오더라도 LLM은 계산이나 집계를 수행할 수 없습니다.
- 관련성 vs. 완전성: 의미 검색은 관련성을 최적화하지만, 정량적 분석은 데이터의 완전성이 중요합니다.
"사용자들이 CSV 파일, Notion 데이터베이스, Google Sheets에 대해 정량적 질문을 할 때, 에이전트는 전체 데이터를 '볼 수' 없거나 필요한 계산을 수행할 수 없어서 종종 불완전하거나 부정확한 답변을 제공했습니다."
초기 단계: CSV 파일과 SQLite
초기 개념화
처음에는 사용자들이 CSV 파일을 Dust에 업로드하고 싶어 했어요. 하지만 이 데이터를 단순히 텍스트로 처리하면 두 가지 큰 문제가 발생했죠:
- 작은 파일만 처리 가능: 텍스트로 처리하면 파일 크기에 제한이 생겼습니다.
- 정확한 분석 불가: LLM이 원시 텍스트 데이터를 분석하는 데 어려움을 겪었습니다.
그래서 우리는 SQLite를 사용해 데이터를 메모리 내 데이터베이스로 변환하고 SQL 쿼리를 실행하는 방식을 도입했어요. 이 선택은 다음과 같은 이유에서 이루어졌습니다:
- 간단함: SQLite는 가볍고 추가 인프라가 필요 없습니다.
- 보안성: 메모리 내 데이터베이스는 사용자 데이터를 격리합니다.
- 성능: 초기 테스트에서 충분히 빠른 성능을 보였습니다.
- 익숙함: SQL은 데이터 분석에 널리 사용되는 언어입니다.
기술적 구현
이 시스템은 다음과 같은 과정을 거칩니다:
- CSV 파일을 파싱하고 스키마를 추론합니다.
- 메모리 내 SQLite 데이터베이스를 생성합니다.
- 데이터를 데이터베이스에 로드합니다.
- 에이전트가 SQL 쿼리를 생성하고 실행합니다.
- 결과를 사용자에게 반환합니다.
"2MB 크기의 CSV 파일을 처리하는 데 걸리는 시간은 1초도 채 되지 않았습니다. 파일 읽기: 14ms, 스키마 추론: 162ms, 데이터 삽입: 약 600ms, 쿼리 실행: 15ms."
또한, 데이터베이스를 캐싱하여 초기 쿼리 이후 몇 분 동안 데이터베이스를 유지함으로써 후속 질문에 빠르게 응답할 수 있도록 했어요. 이 방식은 성능과 자원 관리를 모두 고려한 최적의 선택이었죠.
확장: 연결된 데이터 소스로의 도전
연결된 데이터의 과제
CSV 파일을 처리하는 데 성공한 후, 사용자들은 Notion 데이터베이스, Google Sheets, Office 365 스프레드시트 등 연결된 데이터 소스를 질의하고 싶어 했어요. 하지만 이 데이터들은 지속적으로 변경되며, 수동으로 업로드하기에는 비효율적이었죠.
이 과정에서 다음과 같은 새로운 도전 과제가 생겼습니다:
- 데이터 동기화: 데이터를 최신 상태로 유지하는 방법
- 스키마 탐지: 다양한 소스에서 스키마를 자동으로 감지하고 매핑하는 방법
- 계층적 구조: 스프레드시트 내 여러 시트를 처리하는 방법
- 대규모 데이터 성능: 더 크고 복잡한 데이터셋에서 성능 유지
Notion 데이터베이스
Notion 데이터베이스는 일관된 속성을 가진 페이지들의 집합으로, Query Tables와 잘 맞는 구조를 가지고 있었어요. 하지만 Notion의 유연한 속성 타입(텍스트, 숫자, 날짜 등)을 SQL 데이터 타입으로 변환하는 로직을 개발해야 했습니다.
Google Sheets와 Office 365
Google Sheets와 Office 365는 또 다른 도전을 안겨줬어요:
- 시트 계층 구조: 하나의 파일에 여러 시트가 포함될 수 있음
- 데이터 품질: 병합된 셀, 다중 레벨 헤더, 임베디드 차트 등으로 인해 기계가 읽기 어려운 형식
- 헤더 감지: 헤더가 포함된 행을 자동으로 감지
- 타입 추론: 셀 값에서 데이터 타입을 추론
통합 데이터 소스 추상화
우리는 모든 데이터 소스를 단일 테이블 형식으로 추상화하는 아키텍처를 유지했어요. 데이터가 CSV, Notion, Google Sheets 어디에서 오든, 다음과 같은 공통 구조를 가집니다:
- 고유 ID
- 이름과 설명
- 스키마(열과 데이터 타입)
- 원본 URL
"이 통합 추상화 덕분에 사용자는 CSV 파일, Notion 데이터베이스, Google Sheets 데이터를 단일 SQL 쿼리로 결합할 수 있습니다. 이는 수작업으로는 거의 불가능한 작업이죠."
엔터프라이즈 데이터 웨어하우스로 확장
Snowflake와 BigQuery
다음 단계는 Snowflake와 BigQuery 같은 엔터프라이즈 데이터 웨어하우스와의 연결이었어요. 이 데이터 웨어하우스는 테라바이트 이상의 데이터를 포함하며, 복잡한 권한 모델과 방화벽 뒤에 위치해 있어 새로운 접근 방식이 필요했죠.
우리는 데이터를 SQLite로 가져오는 대신, 원격 데이터베이스 패턴을 채택했어요:
- 메타데이터 동기화: 데이터 자체가 아닌 테이블, 스키마, 관계에 대한 메타데이터를 동기화
- 원격 쿼리 실행: 쿼리를 원격 데이터베이스에서 직접 실행
- 결과 제한: 반환되는 데이터 양을 제한
- 권한 검증: 쿼리 실행 전에
EXPLAIN명령어로 접근 권한을 확인
JIT 테이블: 쿼리 결과도 테이블로
쿼리 결과를 즉석 테이블(JIT, Just-In-Time)로 처리하는 기능은 다단계 데이터 분석을 가능하게 합니다. 예를 들어, Snowflake에서 쿼리한 결과를 Google Sheets 데이터와 결합해 추가 분석을 수행할 수 있어요.
"모든 쿼리 결과를 다음 작업의 입력으로 사용할 수 있게 함으로써, 사용자는 대화 내에서 복잡한 분석 워크플로를 구축할 수 있습니다."
미래: Salesforce와 그 너머
Salesforce 통합
현재 개발 중인 Salesforce는 또 다른 독특한 도전을 제공합니다:
- 객체 지향 데이터 모델: 테이블 대신 객체를 사용하며, 객체 간 관계가 존재
- SOQL 쿼리 언어: 표준 SQL과 다른 Salesforce 고유의 쿼리 언어
- 혼합 데이터 타입: 구조화된 데이터와 긴 텍스트 필드가 혼재
우리는 구조화된 데이터는 SOQL로, 긴 텍스트 필드는 의미 검색으로 처리하는 방식을 결합하고 있어요.
결론: 통합 추상화의 힘
Query Tables 에이전트 도구의 가장 큰 강점은 통합 추상화 계층이에요. 데이터가 CSV, Notion, Google Sheets, Snowflake 어디에 있든, 에이전트는 동일한 인터페이스로 데이터를 다룰 수 있습니다.
"우리는 구조화된 데이터를 어디에 있든, 어떤 형식이든 AI 에이전트가 접근 가능하게 만드는 데 전념하고 있습니다."
이러한 접근 방식은 데이터를 이해하고 분석하는 새로운 세대의 AI 에이전트를 가능하게 하며, 데이터를 누구나 활용할 수 있는 강력한 도구로 만들어줍니다. 🚀