Inner Loop 엔지니어링으로 본 Deep Insight Chatbot – 대화형 분석 챗봇의 4가지 설계 결정

AWS Korea 기술 블로그가 공개한 Deep Insight Chatbot은 "반나절에 만드는 CSV 분석 챗봇"과 "분석가가 매일 쓰는 생산성 도구"를 가르는 4가지 설계 결정을 다룬다. 데이터 보호, 속도, 신뢰성, 비용이라는 네 가지 요구사항을 중심으로 DuckDB 샌드박싱, 세션 기반 OLAP 엔진, SQL 투명성, Bedrock 프롬프트 캐싱을 결합해 운영 가능한 대화형 분석 도구를 만드는 방법을 설명한다.

핵심 포인트

LLM은 SQL만 생성하고 실행은 격리된 DuckDB 환경에서만 처리해 CSV 데이터가 AWS 계정 밖으로 유출되지 않도록 설계했다.
세션마다 DuckDB를 메모리에 상주시켜 OLAP 쿼리를 수백 밀리초 내에 처리, 분석가의 반복 탐색 흐름을 유지한다.
생성된 SQL을 항상 사용자에게 노출하고 직접 수정·재실행할 수 있게 해 신뢰성과 투명성을 확보한다.
Bedrock Prompt Caching으로 2턴째부터 입력 토큰의 약 90%를 캐시 가격으로 처리해 멀티턴 비용을 대폭 줄인다.
웰컴 질문을 LLM 호출 없이 스키마 휴리스틱으로 생성하고, 후속 질문을 같은 응답에 임베드해 추가 API 호출을 제거한다.

상세 정리

배경: 분석 챗봇을 빠르게 프로토타입하는 건 쉽지만, 실제 운영 도구로 만들기 위해서는 데이터 보호·속도·신뢰·비용 네 가지를 동시에 해결해야 한다.
설계 결정 1 (데이터 보호): LLM이 직접 데이터를 처리하지 않고 SQL만 생성, 실행은 DuckDB 샌드박스 내에서만 이뤄져 CSV가 AWS 계정 외부로 나가지 않는다. 환각이 발생해도 잘못된 SQL만 실행되며 데이터 유출이 차단된다.
설계 결정 2 (속도): 세션마다 DuckDB 인스턴스를 메모리에 상주시켜 pandas나 SQLite 대비 빠른 OLAP 쿼리를 제공, 분석가가 반복적으로 질문을 던지는 탐색 흐름을 끊지 않는다.
설계 결정 3 (신뢰성): 생성된 SQL을 UI에 항상 노출하고 사용자가 직접 수정·재실행할 수 있게 한다. 샌드박스 격리 덕분에 임의 SQL 실행도 안전하게 허용할 수 있다.
설계 결정 4 (비용): 멀티턴 대화에서 입력 토큰이 누적되는 문제를 Bedrock Prompt Caching으로 해결, 2턴째부터 약 90% 토큰을 캐시 가격으로 처리한다.
비용 추가 최적화: 웰컴 메시지와 초기 질문 제안을 스키마 휴리스틱으로 생성(LLM 호출 0회), SUGGESTIONS 마커로 후속 질문을 같은 응답에 임베드해 추가 호출을 제거한다.
아키텍처 구조: Outer Loop(자동 배치 분석)와 Inner Loop(대화형 탐색)가 같은 보안 원칙 위에 독립 인프라로 분리돼 있어 두 모드를 동시에 또는 단독으로 사용할 수 있다.
도메인 지식 주입: column_definitions.json으로 컬럼 의미를 LLM에 주입해 도메인별 맥락을 SQL 생성에 반영한다.
한계: 현재 구조는 단일 테이블 최적화이며, 멀티 테이블 환경에서는 스키마 라우팅, FK 정보 추가, 2단계 SQL 생성 등의 추가 설계가 필요하다.
오픈소스: GitHub aws-samples/sample-deep-insight에 공개돼 있고 AWS Workshop으로도 제공된다.