아마존 노바 마이크로와 아마존 베드로크 온디맨드 추론을 활용한 비용 효율적인 커스텀 텍스트-투-SQL

Amazon Nova Micro는 AWS Bedrock에서 제공하는 경량 파운데이션 모델로, 이번 게시물에서는 이를 커스텀 SQL 방언(dialect) 생성용으로 파인튜닝하는 두 가지 접근법을 다룹니다. 일반적으로 Text-to-SQL 작업은 GPT-4나 Claude 같은 대형 모델로 프롬프트 엔지니어링하는 방식이 주류지만, 조직마다 사용하는 DB(Redshift, Athena, 커스텀 DW 등)의 SQL 문법이 미묘하게 달라 범용 모델이 잘못된 쿼리를 생성하는 경우가 많습니다. Nova Micro를 타겟 방언 데이터셋으로 파인튜닝하면 소형 모델임에도 해당 방언에 특화된 성능을 낼 수 있고, Bedrock의 온디맨드 추론(on-demand inference)을 활용해 프로비저닝 처리량을 따로 예약하지 않고도 호출 단위 과금으로 운영할 수 있다는 것이 핵심입니다.

실무적 파급 효과는 비용 구조에 있습니다. 기존에는 파인튜닝된 커스텀 모델을 서빙하려면 Provisioned Throughput을 시간당 고정 요금으로 예약해야 해서 트래픽이 불규칙한 사내 분석 도구, BI 어시스턴트, 자연어 검색 같은 워크로드에는 ROI가 나오지 않았습니다. 온디맨드 추론이 커스텀 파인튜닝 모델에도 열리면서, 하루 수백~수천 쿼리 수준의 내부 도구에서도 "우리 회사 SQL 방언에 맞춘 전용 모델"을 합리적 비용으로 붙일 수 있게 됐습니다. 특히 대형 범용 모델을 프롬프트로 길게 유도하는 것보다, 작은 전용 모델을 짧은 프롬프트로 호출하는 쪽이 레이턴시·토큰 비용·정확도 모두에서 유리한 지점이 분명히 존재합니다.

한국 개발자 관점에서 주목할 점은 두 가지입니다. 첫째, 사내 데이터 어시스턴트나 자연어 쿼리 기능을 기획 중이라면 "GPT-4급 범용 모델 + 정교한 프롬프트" 외에 "Nova Micro급 소형 모델 + 도메인 파인튜닝" 경로를 실제 PoC에서 비교해볼 가치가 생겼습니다. 품질 평가 시 execution accuracy(쿼리를 실제 실행해 결과가 일치하는지)와 exact match를 함께 측정하고, 팀이 쓰는 DW의 함수·예약어·JOIN 문법이 학습 데이터에 충분히 포함돼 있는지 검증해야 합니다. 둘째, 파인튜닝 데이터셋 구축이 사실상 프로젝트의 품질을 결정합니다. 실제 운영 쿼리 로그에서 민감정보를 마스킹해 (질문, SQL) 페어를 만들고, 스키마 정보를 프롬프트에 어떻게 주입할지(전체 DDL vs. 관련 테이블만 선별) 설계하는 것이 성능 차이를 크게 만듭니다. AWS에 이미 락인된 조직이라면 Bedrock 위에서 폐쇄망 요건까지 맞추면서 도입할 수 있다는 점도 실무 의사결정에서 무시 못 할 요소입니다.