사내 LLM 데이터 에이전트 플랫폼

문제

데이터를 보려면 SQL을 쓸 줄 알아야 했다. 그래서 실제 질문은 대부분 데이터를 다루는 사람에게 몰렸고, 그 사람의 시간이 병목이 됐다. 질문 자체는 대체로 단순했다 — 어떤 지표가 지금 얼마인지, 지난주와 뭐가 다른지.

설계·구현·배포·운영을 단독으로 수행했다.

3-tier 데이터 라우팅 위에 RAG 지식베이스를 얹었다. 스키마 문서 730건(95테이블·635컬럼)과 실사용 쿼리 로그를 자동 승격하는 학습 루프를 붙였다.
아키텍처 전환을 A/B 실측으로 결정했다. LLM이 질의를 단일 라벨로 분류해 라우팅하는 방식은 정확도가 0.86 → 0.69로 회귀해 폐기했다. 각 능력을 도구로 노출하고 LLM이 직접 고르게 하는 방식은 baseline과 동률이면서 조합 질의 5/5를 통과했다 — 기존 구조로는 불가능하던 것이다. 모호한 질문에 되묻는 비율도 5/6 vs 0/6이었다.

그래서 채택 근거를 “정확도”가 아니라 능력 확장으로 못박고, 단일 질의 정확도가 5pp 손해라는 사실까지 같이 기록했다. 채택안의 단점을 적어두지 않으면 나중에 그 손해가 원인 불명의 버그로 돌아온다.
fail-closed 비식별화를 설계했다. 마스킹이 적용되지 않은 상태에서는 외부 LLM으로 전송하는 것 자체를 차단한다. 행 단위 선마스킹과 정규식 백스톱의 2중 방어라, 컬럼 맥락 없이는 못 잡는 식별자까지 걸린다.

사내 전 구성원이 쓴다. 접점을 4개로 넓혔다 — 원격 MCP 게이트웨이(SSO로 각자의 AI 클라이언트에서), Slack 봇, REST API, 앱 API.

주기적으로 이상을 감지해 원인 분석까지 붙여 알리는 능동 이상탐지도 얹었다. 질문을 기다리는 도구에서 먼저 말을 거는 도구가 됐다.