데이터헤럴드 무료

-
개발사 데이터헤럴드 주식회사
공식 웹사이트 https://www.dataherald.com/

Dataherald는 기술 지식이 없는 사용자도 SQL 문을 작성하지 않고도 대화를 통해 데이터베이스에 직접 쿼리할 수 있도록 하는 기업 수준의 자연어를 SQL AI로 변환하는 엔진입니다.

데이터헤럴드 제품 인터페이스

데이터헤럴드

Dataherald의 핵심 매개변수 및 통계

Dataherald는 공식적으로 기업 수준의 자연어를 SQL로 변환하는 엔진으로 자리매김하고 있습니다. 핵심 가치는 데이터 팀이 SQL 문을 작성할 필요 없이 기술적인 지식이 없는 사용자도 일상적인 대화를 통해 관계형 데이터베이스에 직접 쿼리할 수 있도록 하는 것입니다. 기존 BI 도구와 근본적인 차이점은 미리 설정된 대시보드나 고정된 보고서 템플릿에 의존하지 않고 사용자 의도를 실시간으로 분석하고 쿼리문을 동적으로 생성하며 여러 라운드의 대화를 지원하여 요구 사항을 점진적으로 개선한다는 것입니다.

프로젝트 공공정보
공식 포지셔닝 엔터프라이즈급 자연어를 SQL 엔진으로 변환
핵심역량 NL2SQL, 다중 라운드 대화 컨텍스트, 복잡한 SQL 생성(JOIN/하위 쿼리/집계/창 함수)
지원되는 데이터베이스 PostgreSQL, MySQL, BigQuery, Snowflake, Databricks, MS SQL Server, ClickHouse, MariaDB, Redshift
벡터 저장 솔방울, 아스트라, 크로마
배포 방법 셀프 호스팅(Docker Compose), 클라우드 호스팅(Enterprise Edition)
입력방법 자연어(주로 영어)
출력 형식 SQL 문 + 쿼리 결과 + CSV 내보내기
오픈 소스 라이센스 아파치-2.0
GitHub 스타 ~3,600
GitHub 포크 ~264
코드 기여자 19
최신 버전 v1.0.3(2024-04-30, GitHub 릴리스)
총 릴리스 9개 버전
핵심 언어 Python(58.5%), TypeScript(39.3%)
시스템 구성요소 엔진, 엔터프라이즈 API, 관리 콘솔, Slackbot

배포 아키텍처: Dataherald는 엔진(핵심 NL2SQL 엔진), 엔터프라이즈(사용자/조직/인증 관리), 관리 콘솔(관리 인터페이스) 및 Slackbot(Slack 통합)의 4가지 독립 구성 요소를 포함하는 마이크로서비스 아키텍처를 채택합니다. 각 구성 요소는 Docker Compose를 통해 균일하게 조정되어 요청 시 분할 배포를 지원합니다.

폭넓은 데이터베이스 적용 범위: v0.0.1부터 v1.0.3까지 Dataherald는 주류 OLTP(MySQL, PostgreSQL, SQL Server), OLAP(ClickHouse, Redshift) 및 클라우드 데이터 웨어하우스(BigQuery, Snowflake, Databricks)를 포괄하는 9가지 유형의 관계형 데이터베이스와 3가지 유형의 벡터 스토리지를 점차적으로 통합했습니다. 이는 단일 유형의 데이터베이스만 지원하는 NL2SQL 솔루션과의 주요 차이점입니다.

반복 리듬: 첫 번째 공개 릴리스 v0.0.1(2023-08), v1.0.0(2024-01), v1.0.3(2024-04), 이후 GitHub 커밋 빈도가 크게 감소하여 현재 유지 관리 기간에 있습니다. 선택할 때 커뮤니티 활동과 장기적인 지원 위험을 평가해야 합니다.

Dataherald의 사용자 및 시장 인지도

Dataherald의 시장 인지도는 주로 오픈 소스 커뮤니티 피드백 및 기업 PoC 검증에 반영됩니다. 해당 관계자는 구체적인 수익 데이터, 유료 고객 수 또는 SLA 약속 세부 정보를 공개하지 않았습니다.

GitHub 커뮤니티 인기도: 3,600개 이상의 별과 264개의 포크로 NL2SQL 오픈 소스 트랙에서 중간 수준에 속합니다. 유사한 프로젝트 비교: SQLChat에는 약 4,000개의 별이 있고, Vanna는 약 12,000개의 별이 있으며, DB-GPT는 약 14,000개의 별이 있습니다. Dataherald는 핵심 추론 엔진만 제공하는 대부분의 프로젝트보다 엔터프라이즈 수준 제공 형태에 더 가까운 4가지 구성 요소(엔진 + 엔터프라이즈 + 관리 콘솔 + Slackbot)의 완전한 세트를 제공하는 것이 특징입니다.

엔터프라이즈 검증 시나리오: 공식 문서와 GitHub README에 강조된 일반적인 사용 사례에는 SaaS에 내장된 Q&A 기능, Slack 기반 자연어 계산 로봇, 비즈니스 팀을 위한 셀프 서비스 계산 포털이 포함됩니다. 이러한 사용 사례는 소규모 및 마이크로 팀보다는 데이터 웨어하우스에 투자했지만 분석 인력이 부족한 중견 기업 및 대기업을 대상으로 합니다.

생태적 협력: 이 프로젝트는 관찰 가능성을 위해 LangSmith를 통합하고 Pinecone/Astra/Chroma 3개 벡터 데이터베이스를 스키마 컨텍스트 저장소로 지원하며 주류 LLM 서비스(OpenAI GPT 시리즈 Anthropic Claude, 자체 호스팅 모델)와 연결할 수 있습니다. 이는 모델에 구애받지 않고 단일 AI 공급업체에 묶이지 않도록 설계되었음을 보여줍니다.

채택 전제 조건: Dataherald의 진정한 가치 릴리스를 위해서는 기업이 이미 ① 구조화된 관계형 데이터 자산, ② 명확한 스키마 문서 또는 골든 쿼리 샘플(골든 SQL), ③ IT 팀이 추가 자체 호스팅 인프라를 기꺼이 유지해야 합니다. 그 중 어느 하나도 없으면 착지 효과가 크게 감소합니다.

Dataherald의 비용 이점

Dataherald의 비용 구조는 "C측/개인 사용자", "API/개발자 통합", "기업/민영화 배포"의 세 가지 수준에서 별도로 검토할 필요가 있습니다.

C 클라이언트/개인 사용자:

  • 명시적 비용: 오픈 소스 커뮤니티 에디션은 완전 무료이며 Apache-2.0 라이선스를 통해 임의 사용, 수정 및 재배포가 허용됩니다. 개별 개발자는 자신의 서버에 대한 운영 비용만 부담하면 됩니다(Docker Compose 모드에서 4개의 컨테이너 실행, 예상 최소 구성은 4코어 및 8G 메모리입니다).
  • 숨겨진 비용: LLM API 키(예: OpenAI, Anthropic)를 직접 구성해야 하며, LLM 통화 요금은 토큰으로 청구됩니다. 스키마 스캐닝 + SQL 생성을 포함한 일반적인 쿼리는 약 2,000~8,000개의 토큰을 소비하며 이는 쿼리 복잡성에 따라 증가합니다. 호출이 자주 발생하는 시나리오에서는 LLM API 오버헤드가 인프라 비용을 빠르게 초과할 수 있습니다.

API/개발자 통합:

  • REST API 레이어: 엔진 및 엔터프라이즈 구성 요소의 오픈 소스 버전은 개발자가 자신의 애플리케이션에 무료로 통합할 수 있는 완전한 RESTful API(프롬프트, sql-세대, nl-세대, 미세 조정 및 기타 엔드포인트 포함)를 제공합니다.
  • 조정 비용: Dataherald는 Golden SQL을 기반으로 하는 미세 조정(Finetuning)을 지원하지만 미세 조정 프로세스는 OpenAI 교육 크레딧을 소비하고 고품질 질문-SQL 쌍 샘플을 준비해야 합니다. 권장되는 샘플 수는 50~200개이며, 한 번의 미세 조정 비용은 수십 달러 정도입니다.
  • 암시적 통합 비용: 각 데이터베이스 연결에 대한 스키마 설명을 수동으로 구성하고(또는 자동 스캔을 실행하고) Golden SQLs 샘플 라이브러리를 유지 관리하고 LLM 생성 SQL이 기대치를 충족하지 못하는 숨겨진 논리를 처리해야 합니다. 이러한 엔지니어링 노력은 API 호출 자체 비용보다 더 큰 경우가 많습니다.

기업/개인 배포:

  • Enterprise Edition 가격: Enterprise Edition의 공식 가격은 공개되지 않았습니다. 업계 관행에 따르면 구독제를 채택한 것으로 추측된다. 청구 차원에는 일반적으로 데이터베이스 연결 수, API 호출 할당량 및 사용자 시트 SLA 수준이 포함됩니다. Enterprise Edition의 추가 가치에는 SSO 통합, 감사 로깅 및 전용 SLA 지원이 포함됩니다.
  • 인프라 비용: 프라이빗 배포에서는 기업이 제한된 MongoDB 데이터베이스, 벡터 데이터베이스 및 네트워크 구성을 실행하기 위해 Docker를 관리해야 합니다. 하루 1,000개의 쿼리라는 중간 로드에서 월간 인프라 비용은 미화 100~500달러(클라우드 호스트 + 벡터 스토리지 + 대역폭)로 추산됩니다.
  • 인적 운영 및 유지 관리 비용: 시스템 유지 관리, Golden SQL 관리 및 쿼리 품질 모니터링을 담당하려면 Docker 및 LLM 호출에 익숙한 개발 또는 운영 및 유지 관리 인력이 최소 한 명 이상 필요합니다. 이러한 숨겨진 비용은 일반적으로 인프라 비용의 3~5배입니다.

비용 비교: NL2SQL 오픈 소스 솔루션

솔루션 오픈 소스 라이센스 배포 복잡성 데이터베이스 범위 미세 조정 지원 엔터프라이즈 기능 커뮤니티 활동
데이터헤럴드 아파치-2.0 중형(4개 구성요소 Docker) DB 9종 + 벡터 저장 3종 ✅ 내장된 미세 조정 API ✅ 관리 콘솔 + Slackbot + Enterprise 중간(별 3.6,000개)
반나 MIT 낮음(Python 라이브러리) 주로 SQLite/PG 지원 ✅ DDL 문서를 통해 교육 ❌ 없음 높음(12,000개 별)
SQL채팅 MIT 낮음(노드 라이브러리) 주로 MySQL/PG 지원 ❌ 없음 ❌ 없음 중간(별 4,000개)
DB-GPT 아파치-2.0 높음(다중 구성 요소) 다중 DB ✅ 지원 ✅ 완전한 엔터프라이즈 기능 높음(14,000개 별)

비용 차이의 주요 특징:

  • Dataherald는 오픈 소스 NL2SQL 솔루션(관리 콘솔 Slack 통합, 멀티 테넌시, 감사 로그 준비)에서 가장 완벽한 엔터프라이즈급 패키지를 제공하며, 처음부터 구축하는 대신 "즉시 사용 가능한" 기능이 필요한 팀에 적합합니다.
  • 이미 LLM API 크레딧이 있고 배포 복잡성에 대한 허용치가 낮은 경우 Vanna(단일 Python 라이브러리 설치) 또는 SQLChat(Node.js 패키지)을 사용하면 초기 시작 비용이 더 낮습니다.
  • DB-GPT는 기능적 완성도와 커뮤니티 규모 측면에서 앞서지만 배포 복잡성도 더 높으며 주로 중국 시나리오에 최적화되어 있어 Dataherald의 영어 우선 포지셔닝과 다릅니다.

Dataherald의 주요 기능

  • 자연어 SQL(NL2SQL): "지난 분기 지역별 판매 순위"를 입력하면 엔진이 자동으로 집계 의도를 인식하고 GROUP BY 및 ORDER BY가 포함된 SQL 문을 생성합니다. 핵심 메커니즘은 LLM을 통해 사용자 질문을 데이터베이스 스키마에 매핑한 다음 대화 컨텍스트를 결합하여 실행 가능한 SQL을 합성하는 것입니다. 기존 BI 도구와의 차이점은 미리 설정된 보고서 구조가 없으며 사용자가 쿼리 차원을 자유롭게 설명할 수 있다는 것입니다.

  • 다단계 대화 문맥 보존: 첫 번째 쿼리 결과(예: "동중국만 보기" 또는 "월별로 표시하도록 변경" 등)를 기반으로 계속 질문합니다. 엔진은 선주문 SQL의 필터 조건 및 집계 논리를 유지하고 WHERE 절 또는 GROUP BY 필드만 증분적으로 수정합니다. 이것이 비즈니스 사용자에게 실질적인 가치는 전체 요구사항을 한 번에 설명할 필요가 없고, 사람과 대화하듯이 쿼리의 범위가 점차 좁아질 수 있다는 것입니다. 단일 분석 작업의 대화형 라운드는 일반적으로 1라운드에서 3~5라운드로 확장되지만 각 라운드는 의미상 일관성을 유지합니다.

  • 데이터베이스 스키마 자동 인식: 엔진은 데이터베이스 테이블 구조, 필드 이름, 필드 유형, 기본 및 외래 키 관계를 자동으로 검색하고 SQL 생성 시 필드 별칭 및 관련 키를 자동으로 일치시킵니다. 스키마 스캔 결과는 MongoDB 및 벡터 데이터베이스에 저장됩니다. SQL을 생성할 때 LLM은 사용자 질문과 관련된 테이블과 필드만 컨텍스트로 검색하여 전체 스키마가 프롬프트에 채워지고 토큰 확장이 발생하는 것을 방지합니다.

  • 질의 결과에 대한 자연어 설명(NL 생성): 생성된 SQL 문 및 실행 결과에 대해 "이 SQL에 대해 어떤 필터링이 수행되었는지, 어떤 차원이 집계되었는지, 정렬 기준이 무엇인지" 설명하기 위해 엔진이 자동으로 자연어 설명을 생성합니다. 비기술적인 사용자를 위한 이 기능의 핵심 가치는 SQL을 이해하지 못하더라도 쿼리 로직이 올바른지 이해할 수 있어 AI가 생성한 결과에 대한 신뢰를 구축할 수 있다는 것입니다.

  • 골든 SQL 관리 및 모델 미세 조정: 검증된 "질문-SQL" 쌍을 Golden SQL 컬렉션에 저장하고 이러한 샘플을 기반으로 GPT 시리즈 모델을 자동으로 미세 조정(Finetuning)하도록 지원합니다. 유사한 비즈니스 쿼리에 대한 미세 조정 모델의 정확도가 크게 향상되었습니다. 이는 "사용할수록 더 정확한" 메커니즘입니다. 초기 단계에서는 일반적인 LLM 지식에 의존하며, 회사가 독점 쿼리 샘플을 축적함에 따라 정확도는 점차 90% 이상으로 수렴됩니다.

  • 중간 단계 시각화(스트리밍): v1.0.2에 도입된 스트리밍 엔드포인트는 스키마 검색부터 SQL 합성, 결과 실행까지 SQL 생성의 중간 추론 단계를 보여줌으로써 사용자와 개발자가 AI 사고 체인을 볼 수 있도록 하여 디버깅과 신뢰 구축을 촉진합니다.

  • Slack 통합 쿼리 로봇: Slackbot 컴포넌트를 통해 사용자는 Slack 채널의 데이터베이스에 직접 자연어를 사용하여 질문할 수 있으며, 로봇은 쿼리 결과 또는 CSV 파일을 반환합니다. 이는 기술적인 배경 지식이 없는 운영, 마케팅 및 영업 팀에게 특히 유용합니다. 일상적인 작업 흐름에서 데이터 수집을 완료하기 위해 BI 도구를 열 필요가 없습니다.

  • CSV 내보내기 및 파일 저장: 쿼리 결과를 CSV로 직접 내보내고 S3에 저장할 수 있습니다(AWS 자격 증명 구성). 이는 Excel 또는 Google Sheets의 후속 2차 분석에 적합합니다. API 응답 페이로드가 너무 커지는 것을 방지하기 위해 숫자가 50줄을 초과하면 자동으로 파일 저장소를 사용합니다.

Dataherald의 모델 및 버전 진화

Dataherald의 버전 기록은 프로토타입 검증에서 기업 기능 개선, 생태 확장에 이르는 진화 경로를 명확하게 반영합니다. 다음은 GitHub 릴리스 공개 정보를 기반으로 컴파일되었습니다.

메인라인 출시

버전 출시일 핵심 변경 사항 이정표
v0.0.1 2023-08 초기 버전, 기본 NL2SQL 쿼리 기능 프로젝트 승인, MVP 검증
v0.0.2 2023-09-14 RESTful 엔드포인트 재구성, MongoDB 컬렉션 이름 표준화, db_connection_id 연관 도입 신속한 프로토타이핑에서 표준화로 전환하는 API 구조 마무리
v0.0.3 2023-09-26 LLM 자격 증명은 SSH 연결 최적화 및 비동기 스키마 스캐닝을 지원합니다 엔터프라이즈 연결 기능이 향상되고 스캔 성능이 최적화되었습니다
v0.0.4 2023-10-07 끝점 이름 바꾸기 ObjectId 외래 키 NL 생성 분할 API 의미 명확화, 1.0 준비
v0.0.5 2023-10-26 llm_api_key 필드 단순화된 S3 CSV 저장, 오류 코드 시스템 단순화된 구성 및 향상된 관찰 가능성
v0.0.6 2023-11-14 CSV 생성 플래그 S3 인증서 구성 가능 향상된 데이터 내보내기 기능
v1.0.0 2024-01-17 Finetuning API, Prompt/SQL-Generation/NL-Generation 3단계 분할 Golden SQL 수집 아키텍처 성숙도 이정표
v1.0.1 2024-03-05 ClickHouse는 MariaDB 공식 지원, 엔드포인트 새로 고침, 오류 코드 개선을 지원합니다 데이터베이스 범위 확장
v1.0.2 2024-04-04 MS SQL Server, Astra/Pinecone 서버리스 지원 스트리밍 중간 단계 LangSmith 통합 생태학적 연계 및 가시성 강화
v1.0.3 2024-04-30 Redshift 지원, 다중 스키마 지원(PG/BigQuery/Snowflake/Databricks) 엔터프라이즈 다중 스키마 시나리오에 적합한 최신 버전

진화론적 맥락의 해석

1단계: 프로토타입 검증(v0.0.1-v0.0.2): 처음 두 버전은 주로 "자연어에서 SQL까지"의 엔드투엔드 프로세스를 완료했습니다. v0.0.2의 RESTful API 리팩토링은 모든 후속 엔터프라이즈 기능의 기반을 마련합니다.

2단계: 엔터프라이즈 연결 기능 구축(v0.0.3-v0.0.6): SSH 연결을 점차적으로 완료하고 S3 스토리지로 CSV 내보내기를 지원하는 여러 데이터베이스, 오류 코드 시스템 및 기타 기업에 필요하지만 핵심이 아닌 AI 기능입니다. 이 단계에서는 Dataherald 팀이 기업에서 NL2SQL을 구현하는 데 장애물이 AI 정확성뿐만 아니라 데이터 연결성, 운영 및 유지 관리 관찰 가능성이라는 점을 인식하고 있음을 보여줍니다.

3단계: 1.0 아키텍처 성숙도(v1.0.0): v1.0.0은 원래의 단일 "질문 → 답변" 프로세스를 프롬프트(문제 이해) → SQL 생성(SQL 합성) → NL 생성(결과 해석)의 3단계 파이프라인으로 분할하고 Finetuning API를 도입하는 주요 아키텍처 변경입니다. 3단계 분할을 통해 각 섹션을 독립적으로 최적화, 캐시 및 감사할 수 있으며 이는 엔터프라이즈 수준 배포를 위한 주요 설계 결정입니다.

4단계: 생태학적 확장 및 유지 관리(v1.0.1-v1.0.3): 스트리밍 엔드포인트를 통해 관찰 가능성을 향상시키는 동시에 데이터베이스 범위(ClickHouse, MariaDB, SQL Server, Redshift) 및 벡터 스토리지 옵션(Astra, Pinecone 서버리스) 확장에 중점을 둡니다. v1.0.3 이후 프로젝트는 낮은 활성 유지 관리 기간에 진입했으며 새로운 기능 버전이 출시되지 않았습니다.

후보자 확인 및 커뮤니티 기여

메인라인 릴리스 외에도 Dataherald는 버그 수정, 문서 개선 및 사소한 기능 향상을 다루는 Pull Requests 및 Issues를 통해 19명의 기여자의 참여를 유도합니다. 그러나 전반적으로 프로젝트의 핵심 개발은 팀 내부에서 주도하고 커뮤니티 기여자는 주로 문서화 및 주변 기능에 중점을 둡니다.

버전 전략 평가: Dataherald의 버전 명명은 의미론적 버전 사양(SemVer)을 따르지만 v0.0.1에서 v1.0.3까지 8개월밖에 걸리지 않고 정체되었습니다. 선택할 때 현재 기능이 요구 사항을 충족하는지 여부, 커뮤니티 포크 또는 자체 유지 관리의 위험을 기꺼이 수용할지 여부를 평가해야 합니다.

Dataherald의 기술적 장점

Dataherald의 기술적 이점은 단일 알고리즘의 혁신에 있는 것이 아니라 엔지니어링 아키텍처 설계, 즉 LLM의 NL2SQL 기능을 구현, 관찰 및 반복 가능한 엔터프라이즈 수준 시스템으로 캡슐화하는 방법에 있습니다.

3단계 파이프라인 아키텍처

Dataherald는 자연어 쿼리 처리를 세 가지 독립적인 단계로 나눕니다.

사용자 입력 → [프롬프트] → [SQL 생성] → [NL 생성] → 사용자 출력
                 ↓ ↓
           스키마 벡터 검색 Golden SQL 일치
  • 프롬프트 단계: 사용자 자연어 입력을 받고 대화 기록(있는 경우)과 벡터 데이터베이스에서 검색된 관련 스키마 정보를 결합하여 LLM 친화적인 프롬프트로 조합합니다. 핵심 최적화는 전체 데이터베이스 스키마를 한 번에 주입하는 대신 벡터 유사성 검색을 통해 사용자의 문제와 가장 관련성이 높은 테이블과 필드만 선택함으로써 토큰 소비를 크게 줄이고 LLM의 주의를 분산시키는 것을 줄이는 것입니다.
  • SQL 생성 단계: 조립된 프롬프트를 LLM으로 보내 SQL을 생성합니다. Golden SQLs 미세 조정 모델이 구성된 경우 먼저 미세 조정 모델을 사용하여 정확도를 높이세요. 그렇지 않으면 일반 모델로 돌아갑니다. v1.0.2에 도입된 스트리밍 엔드포인트를 사용하면 디버깅 및 신뢰 구축에 중요한 SQL 생성의 중간 추론 단계(LLM의 사고 체인, 필드 일치 프로세스 JOIN 조건 선택)를 실시간으로 볼 수 있습니다.
  • NL 생성 단계: 자연어를 사용하여 생성된 SQL 및 실행 결과에 대해 "이 쿼리가 수행한 작업"을 사용자에게 설명합니다. 이는 과소평가되었지만 매우 가치 있는 설계입니다. 기술 지식이 없는 사용자는 일반적으로 SQL을 읽을 수 없지만 자연어 해석을 통해 쿼리 논리가 올바른지 신속하게 판단하고 결과를 수락할지 여부를 결정할 수 있습니다.

스키마 인식 및 벡터 검색의 협업

Dataherald의 스키마 처리 메커니즘은 Dataherald와 간단한 프롬프트 래퍼 사이의 핵심 구분선입니다.

  1. 자동 스캐닝: POST /api/v1/table-descriptions/sync-schemas 엔드포인트의 비동기 백그라운드 작업을 통해 데이터베이스를 스캔하여 테이블 이름, 필드 이름, 필드 유형, 설명, 기본 및 외래 키 관계를 얻습니다.
  2. 스키마 벡터화 저장: Embedding 모델을 이용하여 테이블 및 필드 설명 정보(이름 + 설명)를 벡터화하고 Pinecone/Astra/Chroma 벡터 데이터베이스에 저장합니다.
  3. 런타임 검색: 사용자가 질문을 하면 먼저 질문에 임베딩을 수행하고 벡터 라이브러리에서 Top-K 관련 테이블과 필드를 검색한 다음 이러한 컨텍스트만 LLM 프롬프트에 삽입합니다.
  4. 증분 캐싱: 스캔 결과는 MongoDB에 캐시되어 전체 재구성이 아닌 증분 업데이트를 지원합니다. POST /api/v1/table-descriptions/refresh 엔드포인트(v1.0.1에 도입됨)는 모든 데이터를 다시 검색하지 않고도 테이블 목록을 효율적으로 새로 고치도록 설계되었습니다.

이 메커니즘의 엔지니어링적 중요성은 엔터프라이즈 데이터베이스에 수백 개의 테이블과 수천 개의 필드가 있는 경우가 많다는 것입니다. 이들 모두가 LLM 컨텍스트에 주입되면 토큰 소비가 허용되지 않고 LLM이 심각하게 산만해질 것입니다. 벡터 검색 + 동적 주입은 정확성과 비용을 모두 고려하여 3~8개 테이블 내에서 각 쿼리의 스키마 컨텍스트를 제어합니다.

반복을 통해 종료된 Golden SQL

Dataherald의 미세 조정 메커니즘은 지속적인 최적화 프로세스로 구성됩니다.

비즈니스 쿼리 → SQL 생성 → 수동 검토 → Golden SQL에 저장 → 모델 미세 조정 → 정확도 향상
                                                      ↑
                                              주기적으로 미세 조정 트리거
  • 골든 SQL 컬렉션: 검증된 "자연어 질문 ← 표준 SQL" 쌍을 저장합니다. 각 쌍에는 질문, sql, db_connection_id 및 메타데이터가 포함되어 있습니다.
  • 미세 조정 프로세스: 'POST /api/v1/finetuning'을 호출하여 미세 조정 작업을 생성하면 엔진이 OpenAI 미세 조정에 필요한 데이터 세트 형식으로 Golden SQL을 자동으로 포맷하여 제출합니다. Fine-tuning이 완료된 후 GET /api/v1/finetuning/{id}를 통해 상태를 조회할 수 있습니다. 상태가 SUCCEEDED이면 SQL 생성에 사용할 수 있습니다.
  • 실제 결과: 공식 문서에 따르면 미세 조정된 모델은 독점 비즈니스 도메인에서 SQL 생성의 정확성을 크게 향상시킵니다. 정확한 값은 공개되지 않지만 논리적으로 합리적입니다. 일반 모델은 "매출액"이 SUM(금액)이라는 것을 이해할 수 있지만 기업별 "순매출액 = SUM(금액)-SUM(할인)-SUM(반품)"을 이해하지 못합니다. 미세 조정 후 모델은 이러한 비즈니스 규칙을 학습할 수 있습니다.

모델 독립성 및 교체 가능성

Dataherald는 아키텍처 수준에서 기본 LLM의 추상화를 유지합니다. 엔진은 구성 인터페이스를 통해 다양한 모델에 액세스하며 단일 OpenAI 공급업체에 바인딩되지 않습니다. 공식 지원에는 GPT-4/GPT-3.5, Claude 시리즈 및 자체 호스팅 모델(OpenAI API 형식과 호환되는 로컬 배포를 통해)이 포함됩니다. 이 설계는 기업 조달에 실질적인 가치가 있습니다. GPT-4를 사용하여 PoC 검증 정확도의 상한을 수행하고 온라인에 접속한 후 자체 호스팅 모델로 전환하여 추론 비용을 줄이고 데이터 주권을 제어할 수 있습니다.

다중 테넌시 및 권한 격리

엔터프라이즈 구성 요소는 조직 전체의 사용자 관리, 역할 권한 및 데이터베이스 연결 격리를 제공합니다. 각 데이터베이스 연결은 읽기 전용 모드(UPDATE/DELETE/DDL 문 생성 방지) 및 데이터 둔감화를 지원하는 독립적인 LLM API 키로 구성될 수 있습니다. 이러한 메커니즘은 다중 부서 또는 다중 고객 시나리오에서 반드시 필요합니다. 서로 다른 부서는 인증 범위 내의 테이블과 데이터만 쿼리할 수 있습니다.

데이터헤럴드 사용 방법

Dataherald는 개발자 API 통합에서 비즈니스 팀 Slack 상호 작용에 이르기까지 다양한 사용 시나리오를 다루는 여러 입구 및 통합 방법을 제공합니다.

배포 항목 비교

입구 대상자 시동 방법 전제조건
엔진 API(코어 엔진) 개발자 Docker Compose가 엔진 서비스를 실행합니다 Docker, MongoDB, LLM API 키
엔터프라이즈 API(전체 기능) 개발자/IT 관리자 Docker Compose는 4가지 서비스를 모두 실행합니다 Docker, MongoDB, 벡터 데이터베이스 LLM API 키
관리 콘솔(관리 인터페이스) 데이터 분석가/관리자 Enterprise, 브라우저 액세스로 출시 엔터프라이즈 API 실행
슬랙봇 비즈니스 팀 Enterprise, Slack 앱 구성 출시 Enterprise API + Slack 앱 권한
REST API 개발자 엔진/엔터프라이즈 엔드포인트 직접 호출 배포된 API 기본 URL

신속한 배포 및 시작(자체 호스팅)

최소 구성 요구 사항(PoC 수준):

``배쉬

1. 저장소 복제

자식 클론 https://github.com/Dataherald/dataherald.git cddataherald

2. 상황별 변수 구성(각 서비스 디렉터리의 .env.example 참조)

최소한 구성이 필요함: OPENAI_API_KEY, MONGODB_URI

3. 원클릭으로 모든 서비스 시작

./docker-run.sh


위 명령은 Engine(포트 80), Enterprise(포트 81), Admin Console(포트 3000) 및 Slackbot을 시작하고 Docker 네트워크를 자동으로 생성합니다. 시작 후 'http://localhost:3000'을 통해 관리 콘솔에 접근할 수 있습니다.

### API 호출 예시

**데이터베이스 연결 생성**:

``배쉬
컬 -X POST http://localhost:80/api/v1/database-connections \
  -H "콘텐츠 유형: 애플리케이션/json" \
  -d '{
    "alias": "production_db",
    "connection_uri": "postgresql://user:password@host:5432/mydb",
    "llm_api_key": "<YOUR_LLM_API_KEY>"
  }'

스키마 동기화:

``배쉬 컬 -X POST http://localhost:80/api/v1/table-descriptions/sync-schemas \ -H "콘텐츠 유형: 애플리케이션/json" \ -d '{"db_connection_id": "<연결_ID>"}'


**자연어 쿼리 시작**:

``배쉬
컬 -X POST http://localhost:80/api/v1/prompts/sql- Generations \
  -H "콘텐츠 유형: 애플리케이션/json" \
  -d '{
    "db_connection_id": "<연결_ID>",
    "question": "지난 분기 지역별 매출 순위"
  }'

미세 조정된 모델:

``배쉬 컬 -X POST http://localhost:80/api/v1/finetuning \ -H "콘텐츠 유형: 애플리케이션/json" \ -d '{ "db_connection_id": "<연결_ID>", "golden_sql_ids": ["", ""] }'



### 일반적인 사용 프로세스

1. **초기화**: 서비스 배포 → 데이터베이스 연결 생성 → 스키마 동기화 → 스캔 상태가 SYNCHRONIZED인지 확인합니다.
2. **검증**: 몇 가지 기본 쿼리(간단한 SELECT, 조건부 필터링)를 제출하여 생성 품질 및 실행 정확성을 확인합니다.
3. **샘플 축적**: 빈도가 높은 비즈니스 쿼리의 경우 검증된 Question-SQL 쌍을 Golden SQL에 저장합니다.
4. **미세 조정**: 수직 도메인 정확도를 향상시키기 위해 50개 이상의 샘플을 축적한 후 미세 조정이 트리거됩니다.
5. **온라인으로 전환**: 관리 콘솔 역할 권한 구성 → 비즈니스 팀에 공개 → 쿼리 로그 및 오류율 모니터링.
6. **반복**: 정기적으로 쿼리 로그를 검토하고, Golden SQL에 새로운 쿼리 패턴을 추가하고, 계속해서 미세 조정합니다.

### 프리셋 노트

- 사용자의 데이터베이스 테이블 및 필드 이름이 영어가 아닌 경우(예: 중국어) Dataherald의 스키마 스캐닝 및 LLM 이해가 크게 감소합니다. 이는 현재 버전의 주요 언어 제한 사항 중 하나입니다.
- 프로덕션 사용자의 경우 먼저 읽기 전용 모드를 활성화한 다음 SQL 생성으로 인해 예기치 않은 UPDATE/DELETE 작업이 발생하지 않는지 확인한 후 권한을 완화하는 것이 좋습니다.
- 대규모 라이브러리의 경우 스키마 자동 검색에 몇 분이 걸릴 수 있습니다. v1.0.1에 도입된 '/refresh' 엔드포인트는 증분 업데이트 시간을 크게 단축할 수 있습니다.

## Dataherald의 제품 가격

Dataherald의 가격 시스템은 오픈 소스 커뮤니티 버전과 기업 상용 버전의 두 가지 경로로 나뉩니다. Enterprise 버전의 공식 가격은 공개되지 않았습니다.

**오픈 소스 커뮤니티 에디션(Apache-2.0)**:

- **요금**: 완전 무료이며 사용자 수, 쿼리 양 또는 데이터베이스 연결에 제한이 없습니다.
- **콘텐츠 포함**: 엔진(핵심 엔진) + Enterprise(멀티 테넌트 API) + Admin Console(관리 인터페이스) + Slackbot(Slack 통합)의 모든 소스 코드.
- **적용 조건**: Docker Compose를 실행하고 MongoDB, 벡터 데이터베이스, LLM API Key를 직접 구성하려면 자체 서버 또는 클라우드 호스트가 필요합니다.
- **상업적 사용 제한**: Apache-2.0 라이센스는 무료 사용 및 수정을 허용하지만 제품을 SaaS 서비스로 직접 재배포하는 것은 허용되지 않습니다(라이센스 조건에 따름).

**Enterprise Edition(가격 미공개)**:

- **포함 예정**: SSO(SAML/OIDC) 통합, 감사 로그, 전용 SLA 지원, 우선순위 기술 지원, 엔터프라이즈급 배포 가이드.
- **과금 차원 추측**: 데이터베이스 연결 수 + 월간 API 호출 수 + 사용자 시트 수를 기반으로 하는 결합 구독 모델입니다. 유사한 오픈소스 상용화 프로젝트(예: N8n, Appsmith)를 참고하면 기업용 버전의 연간 요금은 $5,000-$50,000 범위일 수 있지만 이는 업계 추론일 뿐이며 공식적인 견적이 우선합니다.
- **구입방법**: 견적 및 체험판을 받으시려면 공식 영업팀에 문의하셔야 합니다. 공식 웹사이트에서는 셀프 서비스 구매 입구를 제공하지 않습니다.

**LLM 통화 요금(Dataherald 제품 요금과 별도)**:

- 이는 Dataherald 사용에 대한 추가 비용이며 사용자가 선택한 LLM 제공업체 및 통화량에 직접적으로 의존합니다.
- GPT-4의 일반적인 NL2SQL 쿼리는 약 2,000~5,000개의 토큰(입력 스키마 + 질문)을 소비하며 가격은 GPT-4 기준으로 약 $0.01~0.03/회입니다. 빈도가 높은 시나리오(일 평균 10,000회)에 대한 월 LLM 요금은 $3,000-$9,000입니다.
- GPT-3.5-Turbo 또는 자체 호스팅 모델을 사용하면 빌드 정확도를 희생하면서 이 비용을 10~30배까지 줄일 수 있습니다.
- 일반적으로 Dataherald의 자체 인프라 비용을 초과하는 LLM 호출 비용을 예산 모델에 예약하는 것이 좋습니다.

## Dataherald의 응용 시나리오

### 시나리오 1: 사업팀이 직접 데이터를 수집합니다.

**작업 설명**: 시장 운영, 영업 관리, 재무 분석과 같은 비기술 팀은 데이터 웨어하우스에서 보고서를 자주 얻어야 합니다. 기존 프로세스에서는 ① BI 도구에서 보고서 신청 → ② 데이터 웨어하우스 팀의 일정 대기 → ③ 주문형 세부 정보 반복 전달 → ④ 정적 보고서 획득이 필요합니다. Dataherald는 이를 다음과 같이 단순화합니다. 사용자는 Slack 또는 관리 콘솔에서 직접 자연어로 질문하고 쿼리 결과를 즉시 얻습니다.

**실제 소득**:

- 단일 쿼리 주기가 평균 4~6시간에서 1~3분(공제)으로 단축됩니다.
- 데이터 팀은 반복적인 "SQL 작성-SQL 수정"에서 해방되어 데이터 모델링 및 거버넌스에 집중합니다.
- 비즈니스 팀은 일정을 기다리지 않고 자유롭게 데이터를 탐색할 수 있으며 의사결정 응답 속도가 향상됩니다.

**구현 검증의 초점**: 비즈니스 사용자가 "보고를 기다리는" 습관을 바꾸고 자연어로 적극적으로 질문할 의향이 있는지 여부; 1세대 일반 쿼리의 정확도가 70%+에 도달하는지 여부(이 값보다 낮으면 사용자가 포기하게 됩니다).

### 시나리오 2: SaaS 제품 내장 데이터 Q&A 기능

**작업 설명**: CRM, ERP, 프로젝트 관리 등 데이터 집약적인 SaaS 제품에서는 최종 사용자가 복잡한 필터링 인터페이스를 탐색하는 대신 자연어를 통해 제품 내 데이터를 쿼리할 수 있기를 바랍니다. Dataherald의 엔진 API는 제품의 "데이터 분석 보조" 기능으로 내장될 수 있습니다.

**실제 소득**:

- 사용자 학습 비용 절감 - 필터 구문을 배울 필요 없이 모국어로 질문하여 데이터를 얻을 수 있습니다.
- 제품에 미리 설정된 보고서의 개발 및 유지 관리 작업이 줄어듭니다. 동적 생성이 고정 보고서를 대체합니다.
- 사용자 끈적임과 데이터 활동을 개선하여 수동적 보기를 능동적 및 수동적 탐색으로 전환합니다.

**구현 검증의 초점**: 멀티 테넌트 데이터 격리가 정확하게 달성될 수 있는지 여부(테넌트 A의 사용자는 SQL 주입을 통해 테넌트 B의 데이터를 볼 수 없음) 높은 동시성(예: SaaS의 피크 시간)에서 엔진의 응답 성능이 허용 가능한 범위 내에 있는지 여부.

### 시나리오 3: 데이터 분석 가속화 - 복잡한 쿼리 뼈대 생성

**작업 설명**: 전문 데이터 분석가는 다중 테이블 JOIN, 창 기능 및 하위 쿼리가 필요한 복잡한 분석 요구 사항에 직면할 때 Dataherald를 사용하여 SQL 뼈대를 신속하게 생성한 다음 이를 기반으로 미세 조정하고 최적화합니다.

**실제 소득**:

- 특히 익숙하지 않은 테이블 구조의 경우 SQL 쓰기 효율성이 2~3배 증가할 것으로 예상됩니다(수동으로 스키마 정의를 확인할 필요가 없음).
- 저수준 구문 오류 감소 - JOIN 조건 오류, GROUP BY 누락, 집계 함수 오용 등을 AI 생성을 통해 방지할 수 있습니다.
- 분석가는 SQL 구문 디버깅보다는 데이터 분석 및 비즈니스 해석에 더 집중할 수 있습니다.

**구현 검증의 핵심 포인트**: 복잡한 쿼리(4개 이상의 테이블 JOIN, 재귀적 CTE, 동적 PIVOT)에 대한 Dataherald의 생성 품질. 현재 버전은 매우 복잡한 쿼리에 대한 안정성이 제한되어 있으므로 분석가는 생성된 결과를 완전히 신뢰하기보다는 검토하고 수정할 수 있는 SQL 기능이 필요합니다.

### 시나리오 4: Slack 내장 데이터 작업

**작업 설명**: 기업은 Slackbot 구성 요소를 통해 일상 업무 통신 채널에 데이터베이스 쿼리 기능을 포함시킵니다. 경영진이 채널을 통해 '이번 주 신규 고객 수'를 직접 물었고, 로봇이 해당 데이터를 답변해줬다. 운영 스태프가 '지역별 분포'를 물었고, 맥락은 일관되게 유지됐다.

**실제 소득**:

- 데이터 수집 시 마찰이 전혀 없습니다. Slack을 떠나지 않고도 계산, 분석, 공유의 전체 프로세스를 완료할 수 있습니다.
- 쿼리 결과 및 대화 기록은 Slack 채널에 자연스럽게 저장되어 추적 가능한 데이터 토론 이력을 형성합니다.
- 기업 내에서 "데이터 섬" 효과를 줄입니다. 기술이 아닌 역할은 공개 채널에서 데이터 대화를 보고 데이터 쿼리 동작을 미묘하게 학습하고 모방합니다.

**구현 검증의 핵심 포인트**: 긴 대화 컨텍스트를 유지하는 Slackbot의 능력; Slack 채널에 표시되는 민감한 데이터의 규정 준수 위험(PII 필드를 필터링해야 하는지 여부)

## Dataherald의 적용 가능한 그룹

### 핵심 적응 군중

- **데이터 분석가**: Dataherald를 사용하여 SQL 뼈대를 빠르게 생성하고 작업 중복을 줄이며 데이터 통찰력에 더 많은 시간을 할애할 수 있습니다. 적응을 위한 전제 조건은 분석가가 SQL 감사 기능을 갖추고 AI가 생성한 불완전한 SQL을 수정할 수 있다는 것입니다. 부적합한 시나리오: 복잡한 쿼리에 대해 엄격한 품질 요구 사항이 있고 SQL 오류를 허용할 수 없는 프로덕션 시나리오입니다.

- **사업운영/마케팅/영업팀**: 데이터팀에 대한 의존성을 없애고 자연어를 통해 직접 데이터 보고서를 얻습니다. 적응을 위한 전제 조건은 기업의 데이터 모델이 상대적으로 표준화되어 있고(필드 이름이 명확하고 주석이 달려 있음) 쿼리 요구 사항이 복잡한 다단계 분석보다는 주로 집계된 보고서(합계, 개수, 순위, 추세)를 기반으로 한다는 것입니다. 부적합한 시나리오: 매우 높은 데이터 정확성(예: 재정 조정)이 필요한 상황 또는 쿼리 언어가 중국어이고 테이블/필드 이름도 중국어인 상황입니다.

- **IT/데이터 엔지니어**: Dataherald 시스템의 배포, 유지 관리 및 Golden SQL 샘플 관리를 담당합니다. 적응을 위한 전제 조건은 팀이 Docker 운영 및 유지 관리 기능을 갖추고 있으며 스키마 구성, 샘플 축적 및 모델 미세 조정의 지속적인 최적화에 시간을 투자할 의향이 있다는 것입니다. 적용 불가 시나리오: 정규 운영 및 유지 관리 인력이 없는 팀, 데이터베이스가 오래된 시스템(필드 이름이 의미가 없고 주석이 없음)이거나 데이터 업데이트 빈도가 매우 높으며(분당 레벨) 실시간 스키마 인식이 필요한 팀입니다.

- **SaaS 제품 관리자/기술 리드**: 데이터 분석 기능을 제공하기 위해 Dataherald를 자체 제품에 내장하는 것을 평가합니다. 적응의 전제는 제품의 데이터 시나리오가 주로 미국/유럽 영어 시장의 쿼리 중심 사용자를 위한 것이라는 것입니다. 적용할 수 없는 시나리오: 중국 시장을 대상으로 하는 제품(데이터 테이블 이름과 필드 이름이 중국어인 경우 정확도가 크게 떨어짐) 또는 고급 권한 감사 및 다계층 데이터 격리가 필요한 제품.

### 부적합한 경계와 전제조건

- **언어 제한**: Dataherald의 스키마 스캐닝 및 NL 생성은 영어를 주요 작업 언어로 사용합니다. 기본 LLM은 중국어 입력을 처리할 수 있지만 전체 시스템의 스키마 필드 설명, 오류 메시지 및 관리 인터페이스는 영어로 설계되었습니다. 중국어 테이블 이름과 필드 이름이 있는 시나리오에서는 DB-GPT와 같은 중국어 최적화 솔루션을 우선적으로 사용하는 것이 좋습니다.
- **데이터베이스 단편화**: 기업의 데이터베이스가 50개 이상의 독립 인스턴스에 분산된 경우 각 인스턴스에는 별도의 연결 및 스키마 검색 구성이 필요하며 유지 관리 비용은 선형적으로 증가합니다. 핵심 데이터 웨어하우스에만 액세스하는 것이 좋으며, 엣지 데이터베이스에는 여전히 전통적인 방법이 필요합니다.
- **모델 종속성 위험**: Dataherald는 단일 모델을 바인딩하지 않지만 SQL 생성 품질은 선택한 LLM의 기능에 따라 크게 달라집니다. GPT-3.5-Turbo와 같은 저가 모델을 선택하는 경우 복잡한 쿼리의 정확성이 생산 요구 사항을 충족하지 못할 수 있습니다. GPT-4를 선택하면 추론 비용이 예산 부담이 될 수 있다. PoC 단계에서는 여러 모델 조합을 동시에 테스트하는 것이 좋습니다.
- **데이터 보안 감사**: Enterprise 구성 요소는 기본 인증 및 다중 테넌트 지원을 제공하지만 공무원은 SOC2/GDPR과 같은 규정 준수 인증 정보를 공개하지 않습니다. 금융, 의료 등 규정 준수가 강한 산업에서는 구매하기 전에 영업팀과 규정 준수 조건을 확인해야 합니다.

## 요약 및 전망

Dataherald는 엔터프라이즈 수준 NL2SQL 트랙에서 고도로 설계된 오픈 소스 솔루션을 제공합니다. 핵심 가치는 3단계 파이프라인 아키텍처 스키마 인식 벡터 검색 및 Golden SQL 폐쇄형 미세 조정 메커니즘에 있습니다. 이러한 디자인은 단순한 LLM 프롬프트 래퍼와 구별됩니다.

**현재 장점**:
- 광범위한 데이터베이스 범위(관계형 데이터베이스 9종 + 벡터 스토리지 3종)로 오픈 소스 NL2SQL 솔루션을 선도합니다.
- 엔터프라이즈 수준 제공 형태에 가까운 완전한 구성 요소(엔진 + 엔터프라이즈 + 관리 콘솔 + Slackbot)입니다.
- 단일 LLM 공급업체에 얽매이지 않는 모델 독립적 설계로 비용 및 시나리오에 따른 전환이 가능합니다.
- Golden SQLs + Finetuning이 형성하는 "사용할수록 정확해진다"는 관계로 독점 비즈니스 영역의 정확성을 지속적으로 향상시킵니다.

**현재 제한사항**:
- 프로젝트는 v1.0.3부터 낮은 활성 유지 관리 기간에 들어갔습니다. 반년 이내에는 새로운 기능 버전이 없으며 커뮤니티 기여는 주로 미미한 수준으로 유지됩니다. 모델을 선택할 때 장기적인 유지 관리 위험을 평가해야 하며, 필요한 경우 포크 자체 유지 관리 계획을 유지해야 합니다.
- 중국어 자연어 지원 부족 - 스키마 스캐닝 및 필드 설명 NL 생성이 주로 영어로 되어 있어 중국어 테이블 이름/필드 이름의 시나리오 적용이 제한됩니다.
- 매우 복잡한 SQL(5개 이상의 테이블로 JOIN, 재귀적 CTE, 동적 PIVOT, 다중 레벨 하위 쿼리 중첩)의 생성 품질이 충분히 안정적이지 않아 분석가의 2차 검토가 필요하며 완전히 자동화할 수 없습니다.
- 기업용 버전 가격, SLA 약정, 규정 준수 인증(SOC2/GDPR) 등 주요 비즈니스 정보는 공식적으로 공개되지 않았습니다. 기업은 구매하기 전에 판매 채널을 통해 하나씩 확인해야 합니다.

**업계 전망**: NL2SQL은 "사용 가능"에서 "사용 용이"로 이동하고 있으며 Dataherald가 대표하는 엔지니어링 경로(스키마 인식 + 미세 조정 폐쇄 + 다중 구성 요소 협업)가 올바른 방향입니다. LLM의 기본 기능이 지속적으로 향상됨에 따라(예: SQL 생성에서 DeepSeek-V4 및 GPT-5와 같은 새로운 모델의 진행) NL2SQL의 정확도 병목 현상이 점차 완화될 것입니다. 그때쯤이면 충분한 엔지니어링 준비를 갖춘 Dataherald와 같은 중간 계층 플랫폼이 직접적인 이점을 얻게 될 것입니다. 그러나 전제는 프로젝트가 유지 관리 리듬을 재개할 수 있다는 것입니다. 그렇지 않으면 커뮤니티 활동이 더 높은 대안(예: DB-GPT, Vanna)에 의해 기능과 생태학이 추월될 것입니다.

**조달/채택 위험 평가**: Dataherald를 "핵심 데이터 인프라"가 아닌 "중요하지 않은 경로 데이터 쿼리 가속기"로 도입하는 것이 좋습니다. 먼저 오픈 소스 버전을 사용하여 소규모 영역(1-2개의 비즈니스 팀 및 5-10개의 핵심 테이블)에서 2-4주 동안 PoC를 수행하고, ① 영어 쿼리의 정확도가 70% 이상에 도달하는지, ② 자체 데이터베이스에서 스키마 스캐닝 및 벡터 검색 성능, ③ 미세 조정 후 효과 향상을 검증하는 데 중점을 둡니다. PoC가 통과된 후에는 더 넓은 범위의 비즈니스 시나리오로 확장될 수 있는지, 엔터프라이즈 버전 지원 서비스가 필요한지 여부를 평가할 것입니다. 프로젝트가 장기간 동안 활성 유지 관리로 복귀하지 않는 경우 마이그레이션 대상으로 보다 활발한 커뮤니티를 중심으로 대안 평가의 우선순위를 정하는 것이 좋습니다.

관련 도구: github-copilot, <a href="https://www.aistarmap.com/ko-KR/aitool/cursor" target="_self" class="tool-link"><img src="https://res.aistarmap.com/uploads/images/tools/zh-CN/cursor/logo_1785767163.svg" alt="커서" class="tool-logo" style="width: 20px; height: 20px; margin-right: 5px; vertical-align: middle;">커서</a>

버전 정보

  • 안정적인 릴리스 ：첫 번째 안정 버전은 다중 라운드 대화 컨텍스트, 복잡한 JOIN 및 하위 쿼리 생성을 지원합니다. 아직 공식적인 정확한 날짜는 없습니다.
  • 베타 ：베타 테스트 버전은 기본 Text-to-SQL 쿼리를 지원하며 공식적인 정확한 날짜는 아직 없습니다.

사용자 후기

  • 후기를 불러오는 중...