Text-to-SQL 1차 개선
기존 방식의 문제점
확장성 부족
•
데이터베이스 스키마가 하드코딩되어 있음
•
테이블 변경, 추가, 삭제 시마다 워크플로우 재작성 필요
•
프롬프트 업데이트만으로도 번거로움
동적 스키마 가져오기
데이터베이스에서 스키마 정보 추출
•
로컬 db setting에서 create table 정보 확인
•
PostgreSQL 쿼리로 스키마 정보 가져오기
•
강의 자료에 제공된 쿼리 사용 (암기 불필요)
쿼리 실행 및 처리
•
PostgreSQL에서 쿼리 실행 후 스키마 정보 획득
•
여러 항목에 대한 루프 처리 방식 변경
•
한 번에 전체 정보를 처리해야 함
코드 블록을 통한 스키마 처리
루프 처리 로직
•
코드 블록 추가하여 처리
•
input all에서 이미 루프 실행 중
•
스키마를 문자열로 추가하면서 루프 진행
•
줄바꿈 처리 포함
JavaScript 문법 처리
•
코드는 반드시 객체 배열을 반환해야 함
•
큰 괄호와 중괄호로 감싸기
•
key와 value가 같을 때 JavaScript 문법 적용
•
입력 26개에서 출력 1개로 변경
LLM 연결 수정
•
채팅 입력이 직접 연결되지 않아 define below로 변경
•
item 대신 first 사용 (문법 오류 수정)
•
스키마 부분을 동적으로 가져오도록 수정
툴 vs 워크플로우 선택 기준
개인적 견해
•
요즘 툴 개발에 집중하고 있음
•
툴을 잘 사용하는 것이 에이전트 개발과 AI 활용의 올바른 방향
•
하지만 이번에는 툴을 전혀 사용하지 않음
툴이 강력한 경우
•
패턴이 명확하지 않을 때
•
예시: 사내 서비스 (수집 PT 대체)
◦
리서치 툴
◦
오피스 문서 검색 툴
◦
다양한 MCP 지원
•
사용자 의도를 알 수 없는 경우 (시장 조사, 웹 검색, 문서 비교, 시각화 등)
Text-to-SQL의 경우
•
패턴이 너무 명확함
•
질문 → 쿼리 변환 → DB 접근의 고정된 흐름
•
에이전트로 개발 시 불필요한 토큰 비용 발생
◦
스키마 툴, 쿼리 변환 툴, 쿼리 실행 툴 필요
◦
AI가 고정된 값들을 호출해야 함
•
개발자가 직접 호출 시 토큰 비용 없이 DB 통신 비용만 발생
•
AI 추론 과정 생략으로 시간 절약 및 속도 향상
서비스 특성에 따른 선택
•
서비스 복잡도에 따라 에이전트 vs 워크플로우 선택
•
여러 데이터베이스나 복잡한 테이블 구조 시 에이전트 활용 가능
•
툴로 스키마 분석을 에이전트에게 요청하는 방식도 고려
•
정답은 없으며 서비스 타입에 맞는 방식 선택 필요
