데이터베이스 쿼리에 관한 사실은 이렇습니다. 그것은 인지적 부하 (cognitive overhead)를 유발합니다.

"가장 급여가 높은 부서는 어디인가?"라는 질문에 답해야 할 때, 당신은 다음 과정을 거쳐야 합니다:

1. 스키마 (schema) 기억하기
2. 어떤 테이블들을 조인 (join)해야 하는지 파악하기
3. 올바른 SQL 작성 (또는 찾기)
4. 실행하기
5. 결과 해석하기

데이터베이스 규모가 충분히 크다면, 인덱스 (indexes), 쿼리 플랜 (query plans), 그리고 실수로 N+1 문제를 만들지는 않았는지도 함께 고민해야 합니다.

단순한 쿼리라면 괜찮습니다. 하지만 데이터베이스를 넘나들며 데이터를 다양한 각도에서 살펴보는 탐색적 분석 (exploratory analysis)을 수행할 때는 인지적 부하가 빠르게 쌓입니다.

만약 데이터베이스에 영어로 질문만 할 수 있다면 어떨까요?

우리가 해결한 문제

저는 SQL, NoSQL, 그리고 벡터 데이터베이스 (vector databases)를 위한 범용 데이터베이스 GUI인 Pilotbase를 구축해 왔습니다. 초기 단계에서 한 가지 의문이 생겼습니다. 사용자의 스키마를 이해하고 대신 쿼리를 작성해 줄 수 있는 AI 에이전트 (AI agent)를 추가한다면 어떨까? 하는 점이었습니다.

문제는 단순히 멋진 데모에 그치지 않고, 실제로 유용하게 만드는 것이었습니다.

쿼리 작성 AI는 다음과 같은 능력이 필요합니다:

1. 스키마 이해 (테이블, 컬럼, 타입, 관계)
2. 올바른 데이터베이스 선택 (여러 데이터베이스에 연결되어 있는 경우, 필요한 데이터가 어느 것에 있는가?)
3. 의도를 쿼리로 번역 (일상적인 영어에서 SQL, MongoDB aggregation 등으로 번역)
4. 파괴적인 작업 전 경고 (DROP TABLE을 조용히 실행해서는 절대 안 됨)
5. 로컬 LLM과 작동 (모든 팀이 데이터를 OpenAI로 보내고 싶어 하지는 않음)

구축 방법: LangGraph + ReAct

우리는 에이전트 방식의 LLM 워크플로우 (agentic LLM workflows)를 구축하기 위한 프레임워크인 LangGraph와 ReAct (Reasoning + Acting) 패턴을 사용했습니다.

에이전트는 몇 가지 도구 (tools)를 가지고 있습니다:

• list_databases — 연결된 데이터베이스 목록을 보여줍니다
• describe_table — 특정 테이블의 스키마 (schema)를 가져옵니다
• execute_query — SQL, 집계 파이프라인 (aggregation pipelines) 등을 실행합니다
• ask_clarification — 불확실한 경우 사용자에게 확인 질문을 합니다

실제 예시가 어떻게 진행되는지 살펴보겠습니다:

사용자 질문: _"총 지출액 기준 상위 10명의 고객을 보여주고, 제품 카테고리별로 세분화해 주세요."

에이전트의 사고 과정:

1. "총 지출액 기준 상위 고객을 찾아야 함" → list_databases + describe_table
2. "customers, orders, product categories 테이블을 조인(join)해야 함" → 추가적인 스키마 탐색
3. _"카테고리별로 그룹화하고 지출액을 합산하는 SQL 쿼리를 작성하겠음"
4. "실행하기 전에 확인을 요청해야 함" → 경고 및 질문
5. 사용자 승인 → 실행 후 결과를 반환하고 수행한 작업을 설명함

에이전트의 설명: _"order_id와 product_id를 기준으로 customers, orders, products를 조인하고, 카테고리별로 그룹화하여 sum(order_amount)로 고객 순위를 매겼습니다. 결과에 따르면 Alice는 전자제품에 $50K, 생활용품에 $30K를 지출했습니다..."

ReAct가 효과적인 이유

ReAct는 단순한 프롬프트 엔지니어링 (prompt-engineering)과는 다릅니다. ReAct는 다음과 같은 특징을 가집니다:

• 반복적 (Iterative) — 에이전트가 생각하고, 행동을 취하고, 결과를 관찰한 뒤 조정할 수 있습니다.
• 투명함 (Transparent) — 에이전트의 추론 과정을 실시간으로 확인할 수 있습니다.
• 안전함 (Safe) — 파괴적인 작업을 수행하기 전에 확인을 요청할 수 있습니다.
• 조립 가능함 (Composable) — 전체 흐름을 다시 작성하지 않고도 새로운 도구 (tools)를 추가할 수 있습니다.

데이터베이스 쿼리에서 이러한 특징은 매우 중요합니다. 에이전트는 다음과 같은 일을 할 수 있습니다:

• 잘못된 테이블을 선택했을 경우 우아하게 실패 처리 (fail gracefully)
• 이전 단계로 돌아가 스키마를 다른 방식으로 탐색
• 의도가 모호할 경우 사용자에게 명확한 질문을 던짐

로컬 LLM: 데이터를 어디로도 전송하지 않음

기본적으로 Pilotbase는 오픈 소스 모델을 로컬에서 실행하는 방법인 Ollama를 사용합니다.

Mistral이나 Gemma와 같은 모델을 로컬 머신에서 실행할 수 있으며, 에이전트(Agent)가 해당 모델과 직접 통신합니다. 귀하의 데이터베이스 스키마(Schema)와 쿼리(Query)는 네트워크를 절대 벗어나지 않습니다.

대신 OpenAI나 다른 호스팅된 API를 사용하고 싶다면 설정(Config)만 변경하면 됩니다. 하지만 보안 요구 사항이 엄격한 팀(의료, 금융, 국방 등)에게는 로컬 전용(Local-only) 방식이 타협할 수 없는 필수 조건입니다.

AI 에이전트가 실제로 절약해 주는 것들

테스트 결과, 가장 큰 이점은 다음과 같습니다:

1. 탐색적 쿼리 (Exploratory queries) —