티오더 Text2SQL 에이전트 ‘티스푼’ 구축 사례

티오더는 30만 대 이상의 태블릿과 월 2,500만 명 이상의 사용자를 바탕으로 쌓인 주문·매장·광고 데이터를 전사 구성원이 직접 조회할 수 있도록 **Text2SQL 에이전트 ‘티스푼’**을 만들었다.

핵심 목표는 자연어 질문을 SQL로 바꾸되, 바로 실행하지 않고 Human-in-the-Loop 이중 승인으로 안전을 확보하는 것이었다. 사용자는 Slack에서 봇을 @멘션해 질문하고, 에이전트는 먼저 질문 의도를 이해한 뒤 1차 승인에서 계획을 보여준다. 이후 생성된 SQL을 다시 보여주고 2차 승인에서 실행 여부를 확인하며, 버튼은 Block Kit으로 제어해 중복 클릭도 막았다.

구성은 LangGraph StateGraph 기반 워크플로우로 짰다. 추론과 임베딩은 Amazon Bedrock의 Claude 모델이 맡고, SQL 검증과 실행은 Amazon Athena, 벡터 검색은 Amazon S3 Vectors, 결과 저장과 대용량 내보내기는 Amazon S3를 사용했다. S3 Vectors는 메타데이터 필터 검색만으로도 충분한 정밀도를 얻어, 월 5달러 미만의 비용으로 운영할 수 있었다.

검색 설계는 단순 유사도 검색 대신 4-Stage 파이프라인으로 나눴다.

• Stage 1: 질문과 유사한 스키마를 찾아 관련 테이블을 확정
• Stage 2: 확정된 테이블 범위 안에서 쿼리 패턴, JSON 필드, 크로스 테이블 패턴을 검색
• Stage 3: 패턴이 참조하는데 빠진 테이블 스키마와 쿼리 패턴을 백필
• Stage 4: 비즈니스 용어 사전으로 도메인 정의와 enum 값을 보강

이 방식은 "더 많이 가져오기"보다 "빠진 의존성을 정확히 채우기"에 초점을 맞췄다. 특히 크로스 테이블 쿼리에서 한 테이블 스키마가 누락되면 LLM이 해당 패턴을 활용하지 못하므로, 참조 관계를 추적해 컨텍스트를 보강했다.

SQL 파이프라인에서는 Athena의 EXPLAIN으로 구문 검증을 하고, 실패하면 에러를 분석해 추가 RAG 검색 후 재생성하는 루프를 최대 3회까지 돌렸다. 같은 에러가 반복되면 즉시 에스컬레이션했고, 새 턴이 시작되면 상태를 계층별 수명(RETRY, TURN, QUERY, SESSION)에 따라 초기화해 과거 실패가 다음 질의에 영향을 주지 않게 했다.

시행착오도 구체적이었다. 의도 분류는 few-shot 예시를 추가해 일관성을 **70%에서 90%**로 끌어올렸고, 날짜 추론 오류는 current_date를 시스템이 KST 기준으로 고정 주입해 해결했다. 또 체류시간 같은 계산에서 cross-table few-shot이 있어도 스키마가 빠지면 모델이 못 쓰는 문제가 있어, Stage 3 백필로 누락된 테이블 스키마와 패턴을 보완했다.

결국 이 프로젝트의 교훈은, 프롬프트 자체가 아니라 컨텍스트 공급과 실행 제어가 Text2SQL 품질을 결정한다는 점이다. 모델이 알아서 잘 하길 기대하기보다, 필요한 지식을 구조화해 검색 가능하게 만들고, 무엇을 보고 판단했는지 사람이 검증할 수 있게 해야 실운영에 넣을 수 있다.